Cómo evitar errores frecuentes en proyectos de Ciencia de Datos

Introducción: un resultado técnicamente correcto también puede ser un fracaso

Objetivos, datos, método, validación y decisiones son cinco elementos que deben encajar para que un proyecto de Ciencia de Datos resulte útil. Si uno falla, un análisis impecable o un modelo con métricas aparentemente excelentes puede terminar aportando poco valor, consumiendo recursos o induciendo a conclusiones equivocadas.

Los errores frecuentes en proyectos de Ciencia de Datos no se limitan a escribir código incorrecto. Aparecen antes de abrir un entorno de Python: al formular una pregunta imposible de responder, aceptar datos sin conocer su origen o prometer una precisión que todavía no se ha comprobado. También aparecen después de terminar el análisis, cuando nadie utiliza el resultado, cambian los procesos o no existe una persona responsable de mantenerlo.

Un proyecto puede fracasar sin presentar una sola excepción en la ejecución. Por ejemplo, un modelo que anticipa retrasos de entrega puede mostrar una exactitud del 95 % y, sin embargo, ser inútil si prácticamente todos los pedidos llegan a tiempo, si utiliza información conocida únicamente después de la entrega o si sus avisos llegan cuando ya no es posible intervenir.

Esta guía explica cómo prevenir los errores que afectan al conjunto del proyecto: desde el planteamiento del problema hasta la explotación de resultados. Está dirigida tanto a perfiles técnicos como a responsables de operaciones, profesionales que quieren ampliar sus competencias y pequeñas empresas que necesitan trabajar con datos sin construir soluciones desproporcionadas.

La idea principal es sencilla: un proyecto fiable no es aquel que nunca encuentra problemas, sino aquel que los detecta pronto, demuestra qué puede concluir y sabe cuándo no debe automatizar una decisión.

Índice de contenidos

Dónde se originan los errores de un proyecto de Ciencia de Datos

La Ciencia de Datos combina conocimiento del problema, preparación de información, estadística, programación e interpretación. Los fallos se propagan entre estas actividades: un error pequeño al definir la unidad de análisis puede multiplicar registros; una fecha mal interpretada puede introducir información futura; una métrica inadecuada puede hacer que el equipo elija el peor modelo para el negocio.

Conviene distinguir cinco momentos en los que suelen aparecer los problemas:

• Planteamiento: la pregunta es ambigua, no existe una acción posible o se desconoce qué significaría tener éxito.
• Obtención y preparación: los registros no representan la realidad que se pretende estudiar, presentan errores o proceden de sistemas con definiciones incompatibles.
• Análisis y modelado: se confunde una relación estadística con una explicación, se evalúa mal el resultado o se aprovecha información que no estaría disponible en el uso real.
• Entrega: las conclusiones no responden a las necesidades de quien debe decidir, no indican incertidumbre o resultan imposibles de repetir.
• Operación: el modelo envejece, cambia el origen de los datos, nadie supervisa sus errores o las recomendaciones no encajan con el proceso de trabajo.

El propósito de esta guía no es repetir un manual completo de limpieza de datos, arquitectura o documentación. Es proporcionar una visión transversal de los puntos de fallo y de los controles que los previenen. Para profundizar en un aspecto concreto, puede consultarse, por ejemplo, cómo documentar completamente un proyecto de Ciencia de Datos.

Prevenir antes que reparar

El coste de un error suele aumentar cuando se descubre tarde. Modificar una pregunta durante una reunión inicial es sencillo; descubrir que la variable objetivo estaba mal definida después de entrenar, desplegar y utilizar un modelo puede obligar a rehacer gran parte del trabajo. Por eso resulta práctico introducir controles de salida entre fases: nadie da por válida una etapa hasta que sus supuestos y evidencias esenciales están claros.

Error 1. Empezar con una tecnología en lugar de una decisión concreta

«Queremos utilizar inteligencia artificial con nuestras ventas» describe una intención tecnológica, no un problema de análisis. No permite elegir los datos necesarios, definir el éxito ni comprobar si el proyecto mejora algo. El mismo defecto aparece en solicitudes como «hacer un cuadro de mando completo» o «predecir el comportamiento de nuestros clientes» sin especificar qué decisión depende de ese conocimiento.

Cómo reconocer el problema

Una definición incompleta suele carecer de alguno de estos elementos: persona que decidirá, acción disponible, momento en que se toma la decisión, variable observable y criterio de comparación. Si el equipo no puede explicar para qué servirá un resultado, probablemente ha comenzado demasiado pronto.

Cómo corregirlo

Conviene transformar una petición general en una pregunta operativa. Por ejemplo:

• Petición imprecisa: analizar los retrasos de los trabajos de mantenimiento.
• Pregunta útil: identificar, al confirmar una orden de trabajo, cuáles tienen mayor riesgo de retrasarse más de dos días.
• Acción posible: revisar anticipadamente las órdenes de mayor riesgo y reasignar recursos cuando exista margen operativo.
• Comparación: enfrentar el método propuesto con la regla que actualmente utiliza el responsable de planificación.
• Límite: no considerar como éxito un aviso que llega después de la fecha en que ya no puede modificarse la planificación.

Antes de construir nada, hay que comprobar si una tabla ordenada, una regla de negocio o una revisión periódica resolverían el problema. En proyectos modestos, la solución más útil puede no necesitar aprendizaje automático. Este criterio también resulta relevante al aplicar Ciencia de Datos en una microempresa sin sobredimensionar la solución.

Control preventivo: elaborar una ficha de una página que identifique decisión, usuario, frecuencia, acción, restricciones, resultado esperado y alternativa actual. Si no puede completarse, no hay todavía un proyecto suficientemente definido.

Error 2. Dar por supuesto que existen datos suficientes y utilizables

Disponer de miles de filas no garantiza poder responder a una pregunta. Puede faltar la variable que se pretende explicar, no existir registros anteriores a un cambio de proceso o conservarse únicamente los casos que terminaron correctamente. También es frecuente disponer del dato en un sistema al que el equipo no tiene acceso legítimo.

Comprobar la cobertura real

La viabilidad requiere algo más que localizar un fichero. Para cada fuente hay que conocer:

• Periodo: desde cuándo se conserva información fiable y con qué frecuencia se actualiza.
• Cobertura: qué clientes, operaciones, zonas o clases de casos están representados y cuáles faltan.
• Unidad de observación: si cada fila representa un pedido, una línea de pedido, una incidencia o una interacción.
• Resultado observado: cuándo se sabe realmente si una operación fue satisfactoria, tardía o fallida.
• Accesibilidad y legitimidad: permisos de consulta, restricciones de uso y responsables de la información.

El sesgo de selección suele pasar inadvertido

Supongamos que se intenta estudiar por qué determinados clientes abandonan un servicio, pero el fichero solo contiene clientes activos. Un análisis sobre esos registros puede describir a quienes permanecen, no explicar de manera fiable el abandono. Si faltan precisamente los casos problemáticos, el tamaño del fichero no soluciona el sesgo.

Algo similar sucede cuando se estudia la rentabilidad utilizando exclusivamente proyectos cerrados: los proyectos cancelados, en disputa o aún abiertos pueden tener un comportamiento muy diferente.

Control preventivo: realizar una exploración de viabilidad con una muestra trazable, un diccionario mínimo, recuentos por periodo y una relación explícita de ausencias. El proyecto debe poder detenerse o redefinirse si los datos no permiten contestar con rigor.

Error 3. Confundir volumen de datos con calidad de información

Los datos incorrectos no se vuelven fiables por acumularse. Fechas mal importadas, importes en monedas diferentes, estados ambiguos, identificadores reutilizados y cambios de criterio en una misma columna pueden distorsionar cualquier análisis. A menudo el mayor peligro no es un valor claramente absurdo, sino uno que parece creíble.

Las cuatro preguntas mínimas sobre calidad

1. ¿Está completo lo imprescindible? La ausencia de un dato puede ser tolerable para un informe y crítica para otro.
2. ¿Es coherente? Dos fuentes no deberían dar fechas de cierre incompatibles sin una explicación verificable.
3. ¿Tiene significado estable? Una categoría como «terminado» puede haber cambiado de definición durante el periodo estudiado.
4. ¿Representa el momento correcto? Un registro actualizado hoy no demuestra qué información estaba disponible hace seis meses.

Por qué no basta con borrar nulos y duplicados

Eliminar automáticamente todas las filas incompletas puede introducir sesgos si los datos faltan con mayor frecuencia en un tipo de cliente o de operación. Sustituir todos los valores ausentes por cero confunde «sin actividad» con «actividad desconocida». Borrar duplicados por coincidencia de nombre puede fusionar personas o empresas distintas. Ninguna de estas decisiones es neutral.

La limpieza debe justificarse según la pregunta analítica. Conviene conservar el conjunto original, registrar transformaciones y medir cuánto cambia la población después de cada operación. En cómo detectar errores frecuentes en los datos empresariales se desarrollan reglas específicas para identificar inconsistencias; aquí lo importante es no dar por bueno un resultado analítico sin conocer las correcciones aplicadas.

Control preventivo: establecer verificaciones de calidad por campo crítico, revisar muestras manualmente y comparar recuentos antes y después de transformar la información. Toda eliminación significativa debe contar con una justificación.

Error 4. Integrar fuentes de datos sin respetar su granularidad y su contexto

Al combinar bases de datos se producen errores especialmente difíciles de detectar porque las consultas pueden ejecutarse sin fallar y generar tablas aparentemente razonables. El caso típico consiste en cruzar una tabla de pedidos con otra de líneas de pedido y una tercera de incidencias, sin considerar que un pedido puede tener varias líneas y varias incidencias.

Un ejemplo de multiplicación silenciosa

Un pedido tiene tres líneas y dos incidencias. Si ambas tablas se unen directamente por identificador de pedido, pueden aparecer seis filas. Sumar el importe del pedido sobre esas filas multiplicaría su valor, aunque el código SQL sea sintácticamente correcto.

El error no se arregla aplicando indiscriminadamente DISTINCT: podrían existir registros legítimos que comparten valores. Hay que definir primero la unidad del análisis y agregar cada fuente al nivel adecuado antes de combinarla con las demás.

El significado temporal también importa

Además de las claves, es necesario alinear fechas: la fecha de creación de una factura, la de prestación del servicio, la de pago y la de contabilización no son equivalentes. Una variación mensual puede deberse a utilizar una u otra. En un mismo proyecto conviene fijar por escrito qué fecha gobierna cada indicador y por qué.

Las técnicas para construir una integración robusta merecen un tratamiento propio, como el de la integración de Ciencia de Datos con bases de datos empresariales. El control transversal consiste en comprobar que la unión mantiene la población, la unidad de análisis y las reglas del negocio.

Control preventivo: verificar cardinalidades, claves sin correspondencia, duplicaciones y totales reconciliados. Cualquier diferencia relevante debe explicarse antes de interpretar resultados.

Error 5. Utilizar información que todavía no existiría cuando se toma la decisión

La fuga de información (data leakage) aparece cuando el modelo utiliza, directa o indirectamente, datos que no estarían disponibles en el momento real de predicción. Es uno de los motivos por los que un sistema puede funcionar de forma extraordinaria durante las pruebas y fallar al implantarse.

La información futura puede entrar sin que nadie la vea

Si se pretende anticipar el incumplimiento de un plazo cuando comienza un servicio, no puede utilizarse como variable el número final de reclamaciones, la fecha de cierre ni el tiempo real de ejecución. Esas variables contienen información posterior al instante en el que se exige la predicción.

También existe fuga cuando la normalización, imputación de valores ausentes o selección de variables se calcula utilizando la totalidad de los datos antes de separar entrenamiento y prueba. De esa forma, la muestra reservada para evaluar deja de ser realmente independiente.

Reconstruir el momento de decisión

Una técnica útil consiste en definir un instante de corte para cada predicción: «¿Qué sabía la organización exactamente cuando debía decidir?». Cada variable debe superar esa pregunta. Es conveniente distinguir tres momentos:

• Momento del evento: cuándo ocurrió un hecho en el mundo real.
• Momento de registro: cuándo quedó almacenado en el sistema.
• Momento de disponibilidad: cuándo podía consultarlo efectivamente el proceso de análisis.

Una fecha de evento antigua no significa necesariamente que el dato estuviera disponible entonces: pudo incorporarse semanas después. Para ciertos casos, esta distinción es decisiva.

Control preventivo: documentar para cada variable su origen, fecha de disponibilidad y justificación; separar el conjunto de evaluación antes de ajustar transformaciones y revisar manualmente las variables con mayor capacidad predictiva.

Error 6. Evaluar el modelo con una división de datos que no representa su uso real

Separar filas aleatoriamente entre entrenamiento y prueba no siempre ofrece una evaluación válida. Si se intenta predecir ventas del próximo trimestre, utilizar datos posteriores para entrenar y anteriores para evaluar produce una situación distinta de la que tendrá el modelo en producción. Si existen varias observaciones de un mismo cliente, distribuirlas sin control entre ambos conjuntos puede hacer que el modelo reconozca al cliente en vez de generalizar.

Elegir la estrategia según el problema

• Predicción de acontecimientos futuros: utilizar cortes temporales y, cuando corresponda, validación con ventanas sucesivas.
• Generalización a clientes, máquinas o proyectos nuevos: agrupar observaciones relacionadas para evitar que una misma entidad aparezca a ambos lados de la evaluación.
• Clases poco frecuentes: comprobar que las particiones contienen casos suficientes para interpretar las métricas; en contextos adecuados puede ser útil la estratificación, siempre sin vulnerar la estructura temporal o por grupos.
• Series con observaciones muy próximas: considerar si hace falta un intervalo de separación entre entrenamiento y prueba para evitar solapamientos informativos.

La pregunta fundamental no es «¿cuántas filas hemos reservado?», sino «¿el conjunto de prueba reproduce la situación que enfrentaremos después?». Un porcentaje fijo de prueba no sustituye este razonamiento.

Mantener una prueba final verdaderamente independiente

Si se revisan decenas de modelos y se escoge el que mejor puntuación obtiene sobre el mismo conjunto de prueba, esa prueba deja de ser una evaluación final imparcial: se ha utilizado indirectamente para optimizar decisiones. Conviene disponer de una estrategia de validación para comparar alternativas y reservar una evaluación final que no se consulte reiteradamente.

Control preventivo: registrar antes del modelado cómo se dividirán los datos, cuál será la unidad de independencia y qué condiciones futuras representa la prueba.

Error 7. Suponer que el algoritmo más sofisticado es la mejor solución

Un equipo puede dedicar semanas a perfeccionar un modelo mientras una regla bien diseñada ofrece resultados parecidos, es más comprensible y requiere mucho menos mantenimiento. La sofisticación técnica es una característica, no una medida de utilidad.

Comparar siempre con una referencia sencilla

Antes de entrenar un modelo complejo, conviene establecer una línea base (baseline): el comportamiento actual, una regla establecida por especialistas o una predicción sencilla. Si el problema consiste en anticipar retrasos, la referencia podría ser la proporción de retrasos por tipo de servicio y carga de trabajo, calculada únicamente con información disponible en el momento adecuado.

La nueva técnica debe justificar lo que añade: más aciertos relevantes, menos errores costosos, menor tiempo de respuesta o una capacidad operativa que el método anterior no tenía. Las pequeñas mejoras en una puntuación no compensan necesariamente un aumento considerable de costes, dependencia o dificultad de explicación.

Considerar el coste completo de la solución

Además de entrenar, habrá que revisar los datos, actualizar dependencias, corregir fallos, explicar resultados, supervisar cambios e incorporar nuevas reglas del negocio. En entornos pequeños, estos costes recurrentes pueden pesar más que la inversión inicial.

Control preventivo: establecer una comparación explícita frente a la solución vigente y una alternativa simple; aprobar la complejidad adicional solo cuando aporte una mejora relevante y sostenible.

Error 8. Celebrar una métrica elevada que no refleja el objetivo del proyecto

Las métricas resumen comportamientos, pero ninguna representa por sí sola la utilidad de una solución. Elegirlas únicamente porque son conocidas puede ocultar errores importantes, sobre todo cuando los casos de interés son poco frecuentes.

El problema de la exactitud aparente

Supongamos 200 órdenes de servicio, de las cuales 10 terminan con un retraso importante. Un sistema que predice «sin retraso» para todas las órdenes acertaría 190 de 200: 95 % de exactitud. Sin embargo, detectaría cero retrasos, que son precisamente los casos en los que se quería intervenir.

En un escenario así conviene estudiar, entre otras cosas, la proporción de alertas correctas (precisión), la proporción de casos problemáticos identificados (recall o sensibilidad), los falsos positivos, los falsos negativos y la estabilidad del resultado entre periodos. No existe una única métrica adecuada para todos los problemas.

Traducir los errores a consecuencias operativas

La organización debe distinguir qué ocurre cuando el sistema:

• no avisa de un retraso que finalmente se produce;
• avisa de un retraso que no se produce;
• emite tantos avisos que el equipo deja de atenderlos;
• identifica un problema, pero demasiado tarde para actuar.

En ocasiones interesa identificar el mayor número posible de riesgos; en otras, limitar las falsas alarmas es imprescindible para no colapsar la actividad. También hay que comprobar si las probabilidades están bien calibradas: que los casos a los que se asigna, por ejemplo, una probabilidad próxima al 30 % presenten el evento aproximadamente con esa frecuencia en una muestra suficientemente amplia y representativa.

Si se comparan costes económicos, deben especificarse los supuestos utilizados. No basta con declarar que «cada falso negativo cuesta 500 euros» sin explicar cómo se ha estimado ese coste.

Control preventivo: acordar antes de entrenar una métrica principal, varias métricas de seguridad y un criterio de utilidad relacionado con decisiones reales. Comparar los resultados por periodos y segmentos relevantes, no solo mediante un promedio global.

Error 9. Interpretar una asociación estadística como una causa demostrada

Encontrar que los proyectos con más reuniones presentan mayor probabilidad de retraso no demuestra que las reuniones provoquen el retraso. Puede ocurrir lo contrario: los proyectos que empiezan a fallar requieren más reuniones. También podría existir una tercera variable, como la complejidad del encargo, que influya tanto en reuniones como en retrasos.

Describir, predecir y explicar no son la misma tarea

• Descripción: identificar qué patrones muestran los registros disponibles.
• Predicción: estimar qué resultado es probable en casos nuevos, dentro de los límites de validación establecidos.
• Inferencia causal: estudiar qué cambiaría si se modificara una intervención concreta manteniendo bajo control explicaciones alternativas.

Un modelo puede ser útil para priorizar casos aun cuando no identifique sus causas. El error aparece al convertir una relación observada en una recomendación de intervención sin evidencia suficiente.

Cómo reducir conclusiones precipitadas

Conviene identificar posibles factores de confusión, comprobar el orden temporal, considerar explicaciones alternativas y, cuando se busca medir el efecto de una intervención, diseñar una evaluación apropiada. Los experimentos aleatorizados pueden ser útiles en determinados contextos; cuando no resultan viables, hacen falta métodos observacionales bien justificados y límites expresos sobre lo que permiten concluir.

Control preventivo: diferenciar en cada informe los hallazgos descriptivos, las predicciones y las afirmaciones causales. Utilizar verbos como «se asocia» cuando no se ha demostrado un efecto.

Error 10. Obtener un buen resultado que nadie puede reproducir

Es relativamente fácil llegar a una cifra convincente mediante una sucesión de operaciones manuales, ficheros temporales y cuadernos de análisis que solo entiende su autor. El problema aparece cuando otra persona necesita verificar el resultado, corregir una transformación o actualizarlo con información nueva.

Qué debería poder reconstruirse

• La versión de los datos utilizada o una referencia estable a la extracción y sus filtros.
• El significado de las variables, sus unidades y las reglas de tratamiento.
• El código, las dependencias y la configuración relevante.
• Las particiones de entrenamiento, validación y prueba, cuando existan.
• Los supuestos adoptados y los experimentos descartados.
• El resultado final, su fecha, las limitaciones y la persona que lo aprobó.

Documentar decisiones, no solo comandos

Guardar un script no explica por qué se eliminaron determinados registros, por qué se eligió una métrica o qué riesgos se aceptaron. Una documentación útil permite entender el razonamiento y detectar cuándo una regla deja de ser válida.

El control de versiones del código no sustituye el control de versiones de datos, esquemas y parámetros. Tampoco es adecuado incluir secretos, contraseñas o datos personales sin necesidad en repositorios de trabajo. Para el ciclo documental completo puede ampliarse la información en la guía sobre documentación de proyectos de Ciencia de Datos.

Control preventivo: pedir que una persona distinta del autor reproduzca una ejecución representativa siguiendo las instrucciones disponibles. Si no puede hacerlo, la entrega todavía no está cerrada.

Error 11. Considerar la seguridad y la privacidad como un trámite posterior

Un análisis no justifica copiar indiscriminadamente bases de clientes, historiales de actividad o información sensible a un ordenador personal, una carpeta compartida o un servicio externo. Incluso cuando los datos se utilizan con una finalidad legítima, deben existir límites de acceso, conservación y reutilización.

Riesgos prácticos que suelen subestimarse

• Exportaciones completas cuando bastaría una muestra reducida o información agregada.
• Ficheros temporales que permanecen meses en directorios de trabajo o copias de seguridad no controladas.
• Conjuntos llamados «anónimos» que conservan identificadores indirectos suficientes para reidentificar personas.
• Permisos compartidos entre usuarios que no necesitan consultar los registros originales.
• Información confidencial incorporada a cuadernos, informes, registros de ejecución o servicios de terceros sin evaluación previa.

Minimizar desde el diseño

Conviene definir qué campos son estrictamente necesarios, qué transformación reduce riesgos sin perjudicar el objetivo, durante cuánto tiempo conservarlos y quién puede acceder a cada versión. Se deben aplicar controles técnicos proporcionados, como permisos por rol, cifrado cuando corresponda, gestión separada de credenciales y procedimientos de eliminación verificables.

Si se tratan datos personales, habrá que determinar la base jurídica y las obligaciones aplicables, incluidas las del Reglamento General de Protección de Datos (RGPD) cuando corresponda. La seudonimización reduce riesgos, pero no convierte automáticamente los datos en anónimos. Tampoco sustituye otras obligaciones de seguridad o protección de datos.

Control preventivo: incluir en la aprobación inicial una revisión del uso permitido de los datos, la necesidad de cada campo, el destino de los ficheros y el procedimiento de supresión. Un resultado valioso no compensa un tratamiento indebido de información.

Error 12. Comunicar un resultado sin explicar para quién sirve ni dónde deja de ser fiable

Un informe técnicamente sólido puede fracasar si la persona destinataria solo recibe gráficos, coeficientes o métricas sin contexto. También puede fracasar por el motivo opuesto: ofrecer conclusiones excesivamente rotundas para facilitar su lectura.

Empezar por la decisión, no por el algoritmo

Una presentación útil debería contestar, en este orden:

1. Qué se analizó: población, periodo y problema operativo.
2. Qué se encontró: hallazgos relevantes y comparación con la situación anterior.
3. Con qué confianza: incertidumbre, tamaño de muestra, posibles sesgos y límites de generalización.
4. Qué puede hacerse: acciones razonables, responsables y condiciones para probarlas.
5. Qué no puede afirmarse: asuntos que los datos no resuelven, hipótesis pendientes y riesgos de una interpretación excesiva.

Un ejemplo de comunicación deficiente sería: «Nuestro modelo tiene un 87 % de rendimiento». ¿Qué significa rendimiento? ¿Respecto a qué referencia? ¿En qué periodo? ¿Con qué coste de errores? ¿Puede mejorarse la operación gracias a él?

Una formulación más útil sería: «En la muestra de evaluación correspondiente al trimestre más reciente, el método detectó 28 de 40 retrasos importantes y generó 35 alertas que no acabaron en retraso. Antes de aplicarlo de forma general, comprobaremos si el equipo puede revisar ese volumen de avisos». Las cifras son ilustrativas; lo importante es hacer visible tanto el beneficio como el coste operativo.

La construcción de narrativas y visualizaciones orientadas a responsables de negocio se trata con mayor detalle en cómo presentar resultados de Ciencia de Datos a directivos.

Control preventivo: revisar el informe con una persona que no haya desarrollado el análisis. Debe poder explicar qué decisión se propone, qué evidencia la respalda y qué limitaciones acompañan a esa evidencia.

Error 13. Confundir la puesta en producción con el final del proyecto

Una solución puede funcionar al instalarse y deteriorarse meses después. Cambian los hábitos de los clientes, los sistemas de origen, las campañas, los precios, los procesos internos o la manera de registrar incidencias. Un modelo que aprendió relaciones del pasado no garantiza que esas relaciones sigan siendo útiles.

Tres niveles de supervisión diferentes

• Operativo: comprobar si llegan los datos, si el proceso se ejecuta y si los resultados se entregan a tiempo.
• Calidad de información: detectar cambios de esquema, campos vacíos, distribuciones inusuales y discrepancias con los sistemas originales.
• Calidad de decisión: medir si continúan siendo útiles las alertas o predicciones, una vez conocidos los resultados reales y teniendo en cuenta el retraso con que se observan.

No todo cambio estadístico implica que haya que reentrenar

Puede cambiar la distribución de una variable sin que empeore la utilidad del sistema. También puede empeorar el resultado aunque los campos mantengan distribuciones parecidas. Por eso los controles de deriva o drift deben relacionarse con consecuencias verificables, no tratarse como un botón automático de reentrenamiento.

Además de monitorizar, conviene decidir cómo se revierten cambios, qué versión se utilizó en cada periodo, cuándo se bloquea una automatización y qué ocurre si una fuente crítica deja de estar disponible. En soluciones que influyen en decisiones importantes, la revisión humana puede seguir siendo necesaria.

Cuando el análisis alimenta procesos automáticos, es especialmente pertinente revisar los riesgos descritos en la integración de Ciencia de Datos con procesos de automatización. Para ampliar el ciclo de mantenimiento, puede consultarse buenas prácticas para mantener proyectos de Ciencia de Datos durante años.

Control preventivo: definir antes del despliegue quién recibirá alertas, qué indicadores se revisarán, qué umbrales requieren investigación y cómo se suspende o revierte el sistema.

Error 14. Repartir tareas técnicas sin asignar la responsabilidad del resultado

En algunos proyectos se conoce quién prepara la tabla y quién entrena el modelo, pero nadie responde de la definición del indicador, de aceptar los datos, de autorizar una intervención o de revisar su efecto. El problema no se soluciona añadiendo reuniones: se soluciona estableciendo responsabilidades verificables.

Cuatro funciones que deben quedar cubiertas

• Responsable del problema: valida la necesidad, define las decisiones posibles y juzga la utilidad.
• Responsable de la información: confirma origen, significado, permisos de uso y calidad de los datos.
• Responsable técnico: garantiza la ejecución, trazabilidad y validación de los métodos empleados.
• Responsable de operación: supervisa la adopción, las incidencias y el mantenimiento después de la entrega.

Estas funciones no requieren cuatro puestos de trabajo. En una microempresa pueden recaer sobre una o dos personas; lo que importa es que ninguna quede sin cubrir y que los límites de responsabilidad sean explícitos.

La aceptación no debe basarse en impresiones

«El panel ha quedado bien» o «el modelo parece acertar bastante» son criterios demasiado débiles. Es preferible establecer pruebas observables: reproducibilidad, coherencia de totales, comportamiento en un periodo independiente, tiempos de entrega, límites de acceso y capacidad del usuario para interpretar correctamente una alerta.

Control preventivo: acordar quién aprueba cada entrega y qué evidencia necesita para hacerlo. Ningún proyecto debería depender de que una sola persona recuerde todas las decisiones.

Caso práctico: cómo evitar una cadena de errores al anticipar retrasos de servicio

Imaginemos una empresa de mantenimiento que quiere identificar órdenes con alto riesgo de finalizar fuera del plazo comprometido. Recibe unos cientos de órdenes mensuales y conserva información de solicitudes, asignaciones, materiales e incidencias. El objetivo es ayudar a planificación, no sustituir el criterio del responsable.

El ejemplo es hipotético y no representa resultados de una implantación real. Sirve para observar cómo decisiones aparentemente menores pueden comprometer un proyecto entero.

Primera versión: una solución convincente, pero equivocada

Un analista reúne tres años de información, cruza órdenes y reclamaciones, elimina filas incompletas, divide aleatoriamente el fichero y entrena un modelo. Obtiene métricas excelentes y presenta un gráfico de importancia de variables. Sin embargo, al revisar el proceso se descubre lo siguiente:

• La tabla de incidencias multiplicó algunas órdenes durante la combinación.
• La variable «número total de reclamaciones» solo se conoce una vez concluido el servicio.
• Las filas de la misma orden quedaron repartidas entre entrenamiento y prueba.
• Se eliminaron casos sin fecha de cierre, que incluían precisamente órdenes abiertas y posiblemente problemáticas.
• La única métrica presentada fue la exactitud, sin contabilizar los retrasos no detectados.
• Nadie había determinado cuántas alertas podía revisar diariamente el responsable.

El error no está necesariamente en el algoritmo. Está en que el experimento no representa la decisión real que pretende apoyar.

Segunda versión: rehacer el proyecto desde el instante de decisión

1. Definir la predicción: al confirmar una orden, estimar si finalizará con más de dos días de retraso respecto al compromiso vigente en ese instante.
2. Definir la unidad: una fila por orden y por instante de evaluación, no una fila por línea de trabajo ni por incidencia.
3. Reconstruir el contexto: utilizar la carga prevista, la categoría del servicio, el plazo comprometido y los materiales conocidos en ese momento.
4. Definir el resultado: aplicar una regla estable sobre cumplimiento, contemplando cancelaciones, reprogramaciones y casos cuyo resultado todavía no se conoce.
5. Auditar los registros: medir ausencias y exclusiones; no suprimir silenciosamente órdenes abiertas o históricamente difíciles.
6. Evaluar cronológicamente: entrenar con periodos anteriores y reservar un periodo posterior para comprobar generalización, evitando filtraciones entre observaciones relacionadas.
7. Comparar con lo existente: contrastar frente al procedimiento manual y frente a una regla sencilla.
8. Medir utilidad: revisar retrasos detectados, falsas alarmas, anticipación del aviso y carga diaria de trabajo.
9. Probar en paralelo: durante un periodo inicial, generar avisos sin modificar automáticamente la planificación y recoger la valoración del responsable.
10. Decidir continuidad: desplegar, ajustar o descartar el sistema según resultados observables y costes de mantenimiento.

Una tabla de aceptación que evita discusiones vagas

La lección del ejemplo es que detectar errores temprano suele aportar más valor que afinar indefinidamente el modelo. Una evaluación honesta puede concluir que los datos actuales no justifican automatizar nada; esa conclusión también evita una inversión equivocada.

Lista de comprobación para prevenir errores antes de cada entrega

Una buena lista no pretende garantizar que nunca habrá fallos. Sirve para que los problemas más previsibles no dependan exclusivamente de la memoria o experiencia del analista. Puede utilizarse como control breve al cerrar cada fase.

Antes de empezar

• La pregunta identifica una decisión, un responsable y un momento de actuación.
• Se ha descrito cómo se resuelve el problema actualmente.
• Existe una alternativa más sencilla con la que comparar.
• Se han determinado los datos imprescindibles y sus permisos de uso.
• Están definidos los resultados que harían detener o replantear el proyecto.

Antes de analizar y modelar

• La unidad de análisis es inequívoca y las uniones no multiplican registros.
• Se conoce la cobertura temporal y el alcance de las fuentes.
• Los campos críticos cuentan con controles de calidad y reglas documentadas.
• Las transformaciones no eliminan sistemáticamente casos de interés.
• Se han identificado las variables disponibles en el instante real de decisión.
• La partición de evaluación refleja la utilización futura del resultado.

Antes de aceptar los resultados

• Se ha comparado el método con una referencia simple.
• Las métricas representan errores y consecuencias relevantes.
• Se han examinado resultados por periodos y segmentos pertinentes.
• Se distingue entre asociación, predicción e inferencia causal.
• Los supuestos, los límites y las exclusiones son visibles.
• Otra persona puede reproducir los cálculos esenciales.

Antes de utilizar el sistema de forma continuada

• El destinatario entiende qué significa cada salida y cómo actuar.
• La utilización de datos y los accesos cumplen los requisitos aplicables.
• Se han definido responsables de incidencias, seguimiento y actualización.
• Existen comprobaciones de ejecución, calidad y desempeño real.
• Hay un procedimiento para suspender, revisar o revertir la solución.

No todas las comprobaciones tendrán la misma importancia en un análisis puntual y en un sistema automático de alto impacto. Lo razonable es adaptar la exigencia al riesgo, pero no eliminar controles críticos únicamente para acelerar la entrega.

Señales de alerta: cuándo hay que detenerse antes de continuar

Además de la lista de comprobación, existen síntomas que indican que una decisión técnica requiere revisión inmediata. No todos tienen la misma gravedad: unos afectan a la exactitud de una cifra y otros pueden invalidar la finalidad completa del proyecto.

Una regla de priorización útil

Conviene atender primero los problemas que pueden volver inválido el resultado o producir daños, después los que alteran materialmente su utilidad, y por último los de presentación y eficiencia. Mejorar el diseño visual de un informe no sirve de mucho si los datos de partida están duplicados.

El trabajo preventivo tampoco tiene que convertirse en burocracia: en un proyecto pequeño puede bastar una ficha de objetivo, un registro de transformaciones, unas cuantas pruebas automatizadas y una revisión de resultados con la persona responsable. El nivel de control debe crecer con el impacto de las decisiones.

Preguntas frecuentes sobre errores en proyectos de Ciencia de Datos

Conclusión: la fiabilidad se construye con controles, no con promesas

Evitar errores frecuentes en proyectos de Ciencia de Datos requiere mirar más allá del algoritmo. Hay que comprobar que la pregunta está conectada con una decisión real, que la información representa correctamente el fenómeno estudiado, que las variables están disponibles a tiempo y que la evaluación reproduce las condiciones en las que se utilizará el resultado.

También es necesario comparar con soluciones sencillas, escoger métricas coherentes con el coste de equivocarse, distinguir predicción de causalidad, documentar las decisiones y explicar incertidumbres. Si un sistema pasa a formar parte de la operativa, necesitará responsables, controles de seguridad, seguimiento y capacidad de reversión.

La práctica profesional no consiste en obtener siempre un modelo sofisticado. Consiste en saber cuándo los datos justifican una conclusión, cuándo una solución es útil y cuándo conviene detenerse. Esa disciplina protege recursos, facilita el aprendizaje del equipo y convierte los análisis en una base más sólida para decidir.