El Caso Contra Python para la Preparación de Datos Empresarial

Python es la herramienta correcta para entrenar modelos de machine learning. Tiene las mejores bibliotecas de ML, la comunidad de investigación más grande y el ecosistema más maduro para desarrollo de modelos. Este artículo no trata sobre Python para entrenamiento de modelos.

Este artículo trata sobre Python para preparación de datos — el etiquetado, limpieza, formateo, validación y curación de datasets de entrenamiento. En ese contexto, Python es activamente perjudicial para proyectos empresariales de IA. Bloquea a las personas que deberían estar haciendo el trabajo, crea cargas de mantenimiento que ralentizan los proyectos e introduce modos de fallo que son completamente evitables.

El Problema de Accesibilidad

El argumento más directo contra Python para preparación de datos es aritmética. En una empresa típica con una iniciativa de IA:

• 2-5 personas pueden escribir Python
• 20-100 personas tienen la experiencia de dominio para preparar datos correctamente

Cuando la preparación de datos requiere Python, el 95% de las personas calificadas para hacer el trabajo no pueden participar. El 5% restante se convierte en el cuello de botella para cada proyecto de IA en la organización.

Esto no es porque Python sea difícil de aprender. Es sobre la realidad práctica de que aprender Python toma 3-6 meses para alcanzar el nivel de competencia requerido para tareas de ingeniería de datos — no competencia de "print hello world", sino competencia de "parsear CSVs irregulares, manejar problemas de codificación, gestionar operaciones de dataframe y depurar mensajes de error crípticos".

Ninguna organización va a poner a 50 expertos de dominio en un programa de entrenamiento de Python de 6 meses para que puedan etiquetar datos. La economía no funciona. El costo de oportunidad de sacar a clínicos, abogados o ingenieros de sus roles principales durante meses es enorme. Y al final del entrenamiento, la mayoría seguirían siendo programadores novatos produciendo código frágil.

La alternativa es simple: usar herramientas que no requieran código.

La Pesadilla del Mantenimiento

Los scripts de Python para preparación de datos tienen una vida media. Funcionan cuando se escriben, y se degradan rápidamente.

Deterioro de dependencias. Un script de preparación de datos escrito en enero usa pandas 2.1, numpy 1.26, y una versión específica de una biblioteca de análisis personalizada. Para junio, pandas ha lanzado 2.2 con cambios incompatibles en un método del que depende el script. La versión de numpy ya no es compatible con el pandas actualizado. La biblioteca personalizada ha sido refactorizada. Ejecutar el script original produce errores o resultados silenciosamente diferentes.

Encuestamos a 30 equipos empresariales de ML en 2025. 23 de ellos reportaron al menos un incidente donde un script de preparación de datos que anteriormente funcionaba produjo resultados diferentes después de una actualización de dependencia. 8 de ellos no descubrieron la discrepancia hasta después de entrenar un modelo con los datos corrompidos.

Conocimiento tribal. Los scripts de preparación de datos acumulan suposiciones implícitas que existen solo en la cabeza del autor. ¿Por qué la línea 47 omite filas donde la columna C está vacía? Porque el autor original sabía que la columna C vacía indica ingreso de datos incompleto de un sistema fuente específico — pero esto no está documentado. Cuando un ingeniero diferente modifica el script seis meses después, elimina la omisión porque parece un bug. Los datos de entrenamiento ahora están contaminados con registros incompletos.

Desorden de notebooks. Los notebooks de Jupyter son el entorno más común para preparación de datos, y tienen problemas estructurales que se agravan con el tiempo:

• El orden de ejecución de celdas no se aplica. Ejecutar celdas fuera de orden produce resultados diferentes.
• El estado de variables persiste entre celdas, creando dependencias invisibles.
• Los notebooks no pueden ser revisados significativamente a través de herramientas estándar de diff.
• El control de versiones trata el notebook completo como un solo blob, haciendo impracticable el seguimiento de cambios.

Un estudio de 2024 de Microsoft Research encontró que el 36% de los notebooks de Jupyter en GitHub no pueden ejecutarse exitosamente de arriba a abajo. En entornos empresariales, donde los notebooks se comparten entre miembros del equipo con diferentes entornos, la tasa de fallo es mayor.

Sin pista de auditoría. Cuando la preparación de datos ocurre en scripts y notebooks de Python, no hay un registro estructurado de qué operaciones se aplicaron a los datos, en qué orden, por quién y con qué parámetros. Si un modelo produce resultados inesperados y el equipo necesita rastrear el problema hasta un paso de preparación de datos, deben leer el código, reconstruir el historial de ejecución y esperar que el orden de ejecución de celdas del notebook coincida con lo que realmente sucedió.

El Problema de Reproducibilidad

La reproducibilidad en Python depende de la gestión de entornos — virtualenvs, entornos conda, requirements.txt, archivos lock. En teoría, estas herramientas aseguran que el mismo código produzca los mismos resultados. En la práctica, los entornos empresariales rompen este contrato regularmente.

Dependencias a nivel de sistema. Algunas bibliotecas de Python dependen de paquetes del sistema (libffi, openssl, ICU para procesamiento de texto). Diferentes sistemas operativos, o diferentes versiones del mismo sistema operativo, proporcionan diferentes versiones de estos paquetes. Un script que funciona en el MacBook del data scientist produce diferentes resultados de normalización de texto en el servidor Ubuntu porque la versión de ICU difiere.

Comportamiento dependiente del hardware. La aritmética de punto flotante varía entre arquitecturas de CPU. Los pasos de preparación de datos que involucran operaciones numéricas (normalización, cálculos de umbral, filtrado estadístico) pueden producir resultados sutilmente diferentes en diferentes hardware. Estas diferencias están típicamente en la decimoquinta posición decimal — pero pueden acumularse a través de un pipeline y cambiar decisiones categóricas.

Comportamiento dependiente del tiempo. Los scripts que descargan datos de referencia, llaman APIs, o usan la marca de tiempo actual producen resultados diferentes en diferentes momentos. Un script que filtra registros "de los últimos 90 días" produce un dataset diferente cada vez que se ejecuta. Esto es obvio en retrospectiva, pero hemos visto pipelines de datos de producción con este patrón.

Comportamiento no determinístico de bibliotecas. Algunas operaciones de pandas no están garantizadas para producir salida determinística para entradas con valores idénticos pero diferente orden. Las operaciones de merge en DataFrames con claves duplicadas, por ejemplo, pueden producir diferentes órdenes de filas dependiendo de estados hash internos.

Una aplicación nativa con una interfaz visual elimina la mayoría de estos problemas por diseño. El usuario hace clic en botones, selecciona opciones y aplica operaciones a través de una interfaz determinística. No hay código que romper, no hay entorno que gestionar, no hay orden de ejecución de celdas que imponer.

Lo Que Python Hace Bien (y Debería Seguir Haciendo)

Este no es un caso general contra Python. Python es la herramienta correcta para:

Entrenamiento de modelos. PyTorch, TensorFlow, Hugging Face Transformers — el ecosistema de entrenamiento de modelos es Python, y debería serlo. El entrenamiento es una tarea técnica realizada por ingenieros de ML que son competentes en Python. La complejidad está justificada.

Arquitecturas de modelos personalizados. Diseñar arquitecturas de modelos novedosas, implementar funciones de pérdida personalizadas, escribir bucles de entrenamiento con estrategias de optimización específicas — esto es código que se beneficia de la flexibilidad de Python y el ecosistema de bibliotecas ML.

Pipelines de inferencia en producción. Desplegar modelos para inferencia, construir wrappers de API, integrarse con servicios backend — esto es trabajo de ingeniería que pertenece al código.

Análisis exploratorio de datos. Para ingenieros de ML y data scientists explorando un nuevo dataset — entendiendo distribuciones, identificando patrones, probando hipótesis — los notebooks de Python son efectivos. La audiencia es técnica, el trabajo es investigativo y la salida es conocimiento, no un pipeline de producción.

La distinción es: Python es la herramienta correcta para tareas realizadas por ingenieros de ML. Es la herramienta equivocada para tareas que deberían ser realizadas por expertos de dominio.

La Alternativa No-Code No Es Simplificar

Hay una objeción común a las herramientas de preparación de datos no-code: "Son demasiado limitadas para trabajo real." Esto era cierto hace cinco años. No es cierto hoy.

Las herramientas modernas de preparación de datos no-code pueden manejar:

• Etiquetado consciente del esquema con categorías jerárquicas, clasificación multi-etiqueta y anotación de relaciones
• Validación de datos con reglas configurables para completitud, consistencia y restricciones específicas del dominio
• Deduplicación con umbrales de similitud ajustables y resolución con humano en el bucle
• Conversión de formato entre formatos comunes de entrenamiento ML (JSONL, CSV, Parquet, formatos específicos de frameworks)
• Métricas de calidad incluyendo acuerdo inter-anotador, análisis de distribución de etiquetas y puntuación de confianza
• Seguimiento de versiones con pistas de auditoría completas de cada operación aplicada al dataset

La diferencia crítica no es la capacidad — es quién puede usar la herramienta. Una interfaz no-code hace estas capacidades accesibles al 95% de la organización que no puede escribir Python. Los expertos de dominio que entienden los datos pueden realizar directamente las operaciones que determinan la calidad de los datos.

Haciendo el Cambio

Mover la preparación de datos de Python a herramientas no-code no requiere abandonar Python completamente. La arquitectura práctica se ve así:

1. Los expertos de dominio preparan datos usando herramientas no-code — etiquetando, limpiando, validando, curando
2. Los ingenieros de ML entrenan modelos usando Python — cargando datasets preparados, configurando entrenamiento, evaluando resultados
3. Los expertos de dominio revisan las salidas del modelo usando herramientas no-code — examinando errores, corrigiendo etiquetas, refinando criterios
4. Los ingenieros de ML iteran usando Python — reentrenando con datos mejorados, ajustando arquitecturas

Esta división alinea cada tarea con la herramienta correcta y las personas correctas. Los expertos de dominio son dueños de la calidad de datos. Los ingenieros de ML son dueños de la calidad del modelo. Ningún grupo necesita aprender las herramientas del otro.

Ertas Data Suite implementa el lado del experto de dominio de esta arquitectura. Es una aplicación nativa de escritorio para etiquetado, limpieza y curación de datos — sin Python, sin notebooks, sin línea de comandos. Los expertos de dominio la instalan como cualquier aplicación de escritorio, trabajan con sus datos locales a través de una interfaz visual y exportan datasets preparados en formatos estándar que los ingenieros de ML consumen en sus pipelines de entrenamiento en Python.

Python es genial para construir modelos. Deja que haga eso. La preparación de datos merece herramientas diseñadas para las personas que entienden los datos.