Buenas prácticas para mantener proyectos de Ciencia de Datos durante años

Introducción

Un proyecto de Ciencia de Datos puede funcionar perfectamente el día de su entrega y resultar difícil de utilizar seis meses después. Los datos cambian, los modelos envejecen, las versiones dejan de coincidir, la calidad de las entradas se deteriora y el mantenimiento termina dependiendo de alguien que recuerda cómo se hizo todo.

Este problema afecta tanto a un sistema predictivo construido con Python como a un análisis recurrente en SQL, un cuadro de indicadores o un conjunto de scripts que transforma archivos cada semana. El riesgo no es solamente que algo deje de ejecutarse: también puede seguir funcionando y ofrecer resultados cada vez menos fiables sin avisar.

Mantener un proyecto durante años significa conservar su utilidad, explicar sus resultados, detectar cambios y poder intervenir sin reconstruirlo desde cero. Para conseguirlo no hace falta implantar una infraestructura desproporcionada. Hace falta acordar qué se debe preservar, quién se ocupa de ello y qué comprobaciones demuestran que el proyecto continúa siendo válido.

Esta guía se centra en la etapa posterior al desarrollo inicial: cómo mantener operativos los análisis y modelos, evolucionarlos con seguridad y decidir cuándo deben revisarse o retirarse. La elección inicial del problema y la construcción del proyecto tienen un tratamiento distinto; aquí el protagonista es su vida útil.

Índice de contenidos

Qué significa mantener un proyecto de Ciencia de Datos

No basta con conservar un repositorio de código. Un proyecto útil conecta un objetivo empresarial con unas fuentes, reglas de preparación, cálculos, modelos, resultados y decisiones. Si cualquiera de esas piezas cambia sin control, el resultado puede perder sentido aunque la aplicación siga abierta.

Conviene distinguir cuatro dimensiones del mantenimiento:

• Mantenimiento técnico: conservar la ejecución, resolver fallos, actualizar dependencias y mantener la compatibilidad del entorno.
• Mantenimiento de datos: verificar disponibilidad, estructura, procedencia, significado, frescura y calidad de las entradas.
• Mantenimiento analítico: comprobar que las hipótesis, métricas, reglas y modelos siguen siendo adecuados al fenómeno que se estudia.
• Mantenimiento funcional: confirmar que el resultado continúa ayudando a una decisión real y que alguien lo utiliza correctamente.

Estas dimensiones no siempre avanzan juntas. Un informe puede ejecutarse a diario, tener datos completos y, sin embargo, dejar de medir el concepto que necesita la dirección. Un modelo puede mantener su precisión media y producir peores resultados en un segmento relevante de clientes. También puede ocurrir lo contrario: un cálculo modesto, bien documentado y revisado, puede seguir aportando valor durante años.

La primera buena práctica es tratar cada entrega relevante como un activo operativo con ciclo de vida, no como una tarea cerrada en la fecha de publicación.

Crear un inventario pequeño, pero suficiente para intervenir

Un proyecto se vuelve frágil cuando nadie puede responder rápidamente a preguntas básicas: ¿qué genera este resultado?, ¿de dónde salen sus datos?, ¿cuándo se actualizó?, ¿quién conoce sus límites?, ¿qué proceso depende de él?

La ficha mínima del proyecto

Una ficha de una o dos páginas puede bastar para un análisis sencillo. Lo importante es que esté accesible y se mantenga junto con la solución o desde un punto de referencia conocido.

Separar propiedad funcional y ejecución técnica

Quien mantiene el código puede confirmar que un proceso termina sin errores, pero no siempre puede determinar si una previsión sigue siendo comercialmente útil. Esa validación debe corresponder a quien entiende la decisión asociada. En equipos pequeños, una misma persona puede asumir ambos papeles; aun así, conviene documentar las dos responsabilidades.

Para profundizar en el significado, procedencia y responsables de la información, resulta útil distinguir esta ficha operativa de la documentación de los datos empresariales. La primera permite mantener un proyecto concreto; la segunda explica los datos que pueden alimentar muchos proyectos.

Reproducibilidad: poder explicar y repetir un resultado antiguo

Una situación frecuente es recibir esta pregunta: «¿Por qué el informe de marzo daba una cifra diferente de la que aparece ahora?». La respuesta no debería depender de buscar archivos entre carpetas o de recordar qué biblioteca estaba instalada aquel día.

Para reproducir razonablemente un resultado hay que relacionar, como mínimo, los siguientes elementos:

1. Código: versión exacta de scripts, consultas, funciones y reglas de cálculo.
2. Datos: versión, fecha de corte o instantánea identificable de las entradas utilizadas.
3. Configuración: parámetros de ejecución, umbrales, filtros, semillas aleatorias y variables no secretas.
4. Entorno: versiones de lenguaje, bibliotecas y componentes necesarios.
5. Artefacto y evaluación: modelo entrenado o salida generada, junto con sus métricas y validaciones.

Guardar solamente el archivo .py no reconstruye una ejecución si después cambiaron las tablas de origen o los parámetros. Tampoco es suficiente conservar un modelo sin conocer la transformación que se aplicó a sus datos.

Un registro de ejecución que se pueda leer

El siguiente ejemplo es una ficha ilustrativa, no una configuración universal. Sus identificadores se crean para mostrar qué relaciones conviene registrar:

proyecto: prevision_demanda
version_codigo: v1.8.2
corte_datos: 2026-09-30
snapshot_datos: ventas_2026_09_cierre
version_esquema: ventas_v3
version_entorno: python-env-2026-09
configuracion: produccion_v4
modelo: demanda_2026_10_v2
validacion: informe_validacion_2026_10
responsable: equipo_analitica

En un proyecto avanzado, este registro puede automatizarse con herramientas de seguimiento de experimentos, almacenamiento de artefactos y control de versiones de datos. En otro más sencillo, un archivo estructurado y un procedimiento riguroso pueden resolver la necesidad inicial.

Qué debe entrar y qué no en Git

El control de versiones es adecuado para código, pruebas, documentación y configuraciones sin secretos. Los grandes conjuntos de datos, las copias operativas y los artefactos voluminosos suelen necesitar almacenamiento y versionado específicos. No deben introducirse contraseñas, tokens ni datos personales por comodidad, ni en el repositorio ni en los registros de experimentos.

La reproducibilidad absoluta, bit a bit, puede no ser posible si intervienen operaciones no deterministas, hardware diferente o servicios externos cambiantes. El objetivo práctico consiste en conservar evidencias suficientes para reconstruir el procedimiento y justificar sus resultados dentro de tolerancias definidas.

Tratar las fuentes de datos como contratos que pueden cambiar

Una fuente aparentemente estable puede cambiar de nombre de columna, formato de fecha, codificación, unidad de medida o significado empresarial. El proceso puede fallar de inmediato o, peor aún, aceptar la modificación y producir cifras incorrectas.

Por eso resulta útil acordar un contrato de datos: un conjunto de expectativas verificables sobre lo que recibe el proyecto. No tiene por qué ser un documento jurídico ni una tecnología compleja. Puede ser una especificación que exprese:

• Qué campos son obligatorios y cuáles pueden faltar.
• Qué tipos, unidades, zonas horarias e identificadores se admiten.
• Qué representa cada fila y cuál es la granularidad de los registros.
• Qué valores y rangos son plausibles, con excepciones justificadas.
• Cuál es la frecuencia de actualización y qué retrasos se toleran.
• Qué sucede cuando la entrada incumple el contrato.

Comprobar contenido, no solo formato

Un fichero puede tener todas las columnas correctas y contener información poco fiable. Por ejemplo, una columna de importe puede pasar todas las validaciones de tipo numérico mientras una parte de las cifras cambia de euros a céntimos. Del mismo modo, las fechas pueden ser válidas sintácticamente y corresponder a meses equivocados.

Los controles deben combinar estructura, valores, relaciones y significado. Conviene revisar la tasa de nulos, duplicados, categorías nuevas, cambios bruscos de distribución, fechas imposibles y correspondencia entre totales de origen y destino. Si el proyecto utiliza datos de diversas aplicaciones, hay que comprobar además que las uniones no multipliquen registros indebidamente.

La mejora de la calidad de los datos antes de automatizar aborda las validaciones y decisiones que deben acompañar a los datos de entrada. En un proyecto de Ciencia de Datos, esas reglas deben ejecutarse de nuevo cada vez que se recibe información relevante, no solo durante la preparación inicial.

Planificar qué hacer ante una ruptura

Si falla una validación crítica, no siempre conviene continuar usando el último dato como si fuera actual. La respuesta puede consistir en detener la publicación, marcar el resultado como provisional, mantener una versión anterior con su fecha visible o solicitar una revisión humana. La elección depende del riesgo de la decisión; debe estar escrita antes de que aparezca la incidencia.

Diseñar pruebas que detecten fallos técnicos y resultados engañosos

En Ciencia de Datos hay errores que producen una excepción clara y otros que generan una tabla convincente, pero equivocada. Una estrategia de pruebas duradera debe cubrir ambos.

Cuatro capas útiles de verificación

1. Pruebas unitarias: comprueban pequeñas transformaciones, cálculos, reglas de fechas, unidades y tratamiento de casos límite.
2. Pruebas de contrato: validan el esquema y las condiciones mínimas de cada fuente.
3. Pruebas de integración: ejecutan el recorrido completo con un conjunto controlado y comprueban los resultados esperados.
4. Pruebas analíticas: comparan distribuciones, métricas, segmentos y resultados con una referencia razonable.

Para un informe, una prueba analítica puede consistir en reconciliar totales con el sistema de referencia. Para una predicción, puede comparar el modelo nuevo con un método simple: la última observación, una media histórica o una regla empresarial conocida.

La prueba debe definir qué diferencia resulta aceptable. No basta con afirmar que «el modelo parece funcionar». Tampoco conviene imponer una tolerancia universal: un error de dos unidades puede ser irrelevante en una previsión agregada y crítico en otra situación.

Evitar que la validación incluya información del futuro

Cuando los datos tienen dimensión temporal, la evaluación debe respetar qué información estaba disponible en el momento de la predicción. Mezclar registros futuros en el entrenamiento o calcular transformaciones con información del conjunto de prueba produce estimaciones artificialmente favorables. En series temporales, es habitual evaluar mediante cortes cronológicos y repetir la prueba en varios periodos.

También deben comprobarse los procesos de preparación: si una variable cambia de significado entre entrenamiento y uso real, una métrica histórica favorable no garantiza un buen funcionamiento.

Un conjunto pequeño de casos de referencia

Conviene conservar entradas representativas con resultados esperados: un caso normal, uno incompleto, uno con valores extremos, uno con categorías nuevas y otro que deba bloquearse. Ese conjunto de referencia permite detectar regresiones al actualizar código, bibliotecas o reglas de negocio.

Los datos de prueba deberían ser sintéticos o estar adecuadamente desidentificados cuando exista riesgo de exponer información personal o confidencial.

Monitorizar tanto la ejecución como la utilidad del resultado

«La tarea programada ha terminado correctamente» es una señal necesaria, pero insuficiente. Una solución mantenible debe ofrecer una visión de su estado técnico y de la calidad de lo que entrega.

Establecer alertas útiles y no una fábrica de avisos

Una alerta debe tener destinatario, gravedad, evidencia y acción posible. Si todas las anomalías generan un correo urgente, pronto se deja de prestar atención a los avisos. Es preferible separar incidencias que impiden operar de cambios que requieren observación.

Los umbrales deben proceder del comportamiento normal del proyecto y del impacto de equivocarse. Por ejemplo, una tasa de nulos que normalmente ronda el 0,5 % y sube al 6 % merece investigación; esos porcentajes son solo un ejemplo, no reglas generales aplicables a cualquier conjunto de datos.

Es útil registrar por ejecución el identificador del proceso, fecha y hora, versión de código, fuente y corte de datos, número de registros, validaciones superadas, advertencias, resultado y duración. Los registros permiten diagnosticar incidencias, pero no deberían contener secretos ni filas personales completas.

Reconocer cuándo un modelo sigue ejecutándose, pero ha dejado de ser fiable

Los proyectos predictivos plantean un problema adicional: el mundo que representan puede cambiar. La demanda, los hábitos de compra, la estacionalidad, las condiciones económicas o las políticas de una organización no permanecen necesariamente iguales a los datos utilizados al entrenar el modelo.

Deriva de los datos y cambio de la relación que se intenta aprender

La deriva de datos aparece cuando cambian las características estadísticas de las entradas respecto a la referencia elegida. Por ejemplo, los pedidos comienzan a concentrarse en categorías que antes eran minoritarias.

El cambio de concepto se produce cuando se altera la relación entre las variables de entrada y el resultado que se desea estimar. Por ejemplo, un patrón histórico de ventas deja de funcionar después de un cambio estructural en la política comercial.

Ambas situaciones requieren análisis, pero ninguna justifica por sí sola entrenar de nuevo automáticamente. Puede haber cambios legítimos que no reduzcan la utilidad y una distribución aparentemente estable que oculte errores por segmentos.

Evaluar cuando se conoce el resultado real

Un modelo que predice cancelaciones no puede medir su precisión real hasta conocer cuáles sucedieron. Por eso deben registrarse las predicciones y vincularse, cuando proceda, con los resultados observados posteriormente. Si las etiquetas llegan con retraso, la evaluación también debe reconocerlo.

Además de una métrica global, conviene revisar grupos o periodos relevantes. Un error medio aceptable puede ocultar un desempeño deficiente en productos poco vendidos, clientes nuevos o determinadas temporadas.

Decidir si recalibrar, volver a entrenar, cambiar de método o retirarlo

Ante una degradación, el orden razonable es investigar la fuente, comprobar que el objetivo sigue siendo válido y comparar alternativas. Algunas incidencias se corrigen reparando una transformación; otras requieren ajustar umbrales o recalibrar; otras justifican reentrenamiento o rediseño. A veces, una regla sencilla sustituye con ventaja a un modelo difícil de mantener.

Un modelo no debe reentrenarse solo porque haya transcurrido un número fijo de semanas. La frecuencia de revisión puede ser periódica, pero la decisión de sustituirlo debe sustentarse en evidencia y una evaluación adecuada.

Actualizar sin perder la posibilidad de volver a una versión fiable

La evolución es inevitable: aparecen nuevas variables, cambian bibliotecas, se modifican consultas y se incorporan nuevos destinatarios. El objetivo del control de cambios no es impedir estas mejoras, sino evitar que una modificación razonable interrumpa una solución que ya era útil.

Flujo mínimo de cambio

1. Describir el motivo: qué problema se corrige, qué mejora se espera y qué salidas pueden verse afectadas.
2. Preparar una versión aislada: desarrollar y probar sin sobrescribir el entorno operativo.
3. Ejecutar pruebas: repetir los casos de referencia y comparar resultados con la versión vigente.
4. Revisar impacto: contrastar métricas técnicas y funcionales con criterios de aceptación.
5. Desplegar con control: anotar versiones, fecha, responsable y mecanismo de reversión.
6. Observar: comprobar las siguientes ejecuciones y decidir si se confirma el cambio.

Según el riesgo, la comparación puede hacerse en un entorno de pruebas, mediante ejecuciones paralelas sin efecto sobre el proceso real o con una implantación gradual. Una previsión usada solo como orientación no exige necesariamente los mismos controles que una salida que activa decisiones automáticas de alto impacto.

Qué significa poder volver atrás

Conservar el modelo o el código anterior no basta si ya se cambió de forma incompatible el esquema de la base de datos, las variables utilizadas o las reglas de transformación. Una estrategia de reversión debe contemplar código, configuración, artefactos y compatibilidad de datos. Los cambios de esquema merecen un plan específico de migración y, cuando sea posible, una etapa de compatibilidad.

Para los proyectos que reciben información mediante servicios externos, algunas precauciones son comunes a las descritas en el mantenimiento a largo plazo de integraciones mediante APIs; aquí, además, hay que comprobar el significado estadístico de los cambios recibidos.

Incorporar seguridad y privacidad al mantenimiento habitual

El valor de un conjunto de datos puede hacerlo sensible. La conservación de un proyecto no justifica conservar indefinidamente toda la información original, multiplicar copias de trabajo ni compartir datos reales para resolver incidencias.

• Control de acceso: conceder únicamente los permisos necesarios a personas y procesos, y revisarlos cuando cambian las funciones.
• Gestión de secretos: separar credenciales de código, notebooks, archivos exportados y registros; establecer procedimientos de renovación.
• Dependencias: revisar vulnerabilidades y compatibilidad antes de actualizar, y probar los cambios.
• Protección de información: cifrar cuando corresponda, limitar las exportaciones y evitar datos sensibles innecesarios en pruebas.
• Retención: establecer plazos justificados para datos, copias, predicciones y registros; aplicar las obligaciones legales pertinentes.
• Trazabilidad: poder conocer quién publicó una versión y quién accedió a los recursos cuando el riesgo lo requiera.

Cuando se tratan datos personales, el mantenimiento debe respetar las obligaciones aplicables de protección de datos, incluidos principios como minimización, limitación de la finalidad y conservación proporcionada. La existencia de una copia histórica o de un modelo no elimina esas obligaciones.

La seguridad tampoco se reduce al acceso a la base de datos. Un informe exportado, un notebook con resultados individuales o un repositorio mal configurado pueden ser vías de exposición tan importantes como el sistema original.

Diseñar la recuperación antes de necesitarla

Hay una diferencia esencial entre poder volver a ejecutar un análisis y poder recuperar los recursos necesarios para hacerlo. El control de versiones permite seguir cambios, pero no sustituye una política de copias de seguridad.

Según el proyecto, puede ser necesario proteger repositorios, configuraciones, documentación, catálogos, conjuntos de datos autorizados, artefactos, resultados finales y claves de acceso a los sistemas de respaldo. No todos deben copiarse del mismo modo ni con la misma frecuencia.

Restaurar un proyecto completo, no un fichero aislado

Una prueba útil consiste en preparar un entorno limpio y verificar que puede recuperarse una versión conocida, cargar sus datos permitidos, ejecutar las validaciones y generar una salida comprensible. La prueba debe registrar qué faltó, cuánto tiempo se necesitó y qué dependía de intervención manual.

Cuando una solución es crítica, conviene acordar dos objetivos distintos: cuánto tiempo puede estar indisponible y cuánta información reciente se puede admitir perder. Son las bases para decidir una frecuencia de copia y un procedimiento de recuperación proporcionados.

Si un proveedor o una fuente externa deja de estar disponible, tener una copia no garantiza poder continuar indefinidamente: también hay que analizar derechos de uso, vigencia y alternativas.

Establecer una rutina que la organización pueda sostener

Un proyecto con un manual extraordinario, pero sin tiempo asignado para revisarlo, sigue siendo vulnerable. Es mejor un calendario modesto que se cumpla a una plataforma sofisticada que nadie atienda.

Revisión por ejecución

Comprobar que los datos esperados han llegado, que pasan las validaciones críticas, que las salidas tienen fecha y que las incidencias dejan un registro. En procesos automatizados, estas verificaciones deberían producirse sin depender de que una persona abra cada archivo.

Revisión mensual o según ritmo del negocio

Inspeccionar tendencias de errores, retrasos, cambios de distribución, consumo de recursos y peticiones de los usuarios. En soluciones predictivas, revisar métricas disponibles y excepciones relevantes. Una periodicidad distinta puede ser más adecuada para procesos diarios de alto riesgo o análisis anuales.

Revisión trimestral o ligada a cambios significativos

Verificar responsables, permisos, dependencias, documentación, prueba de recuperación y correspondencia con la necesidad empresarial. Revisar asimismo los cambios previstos en las fuentes y los contratos con terceros.

Revisión de continuidad

Al menos cuando cambien los objetivos del negocio, las fuentes principales o el coste de sostener el proyecto, evaluar cuatro opciones: mantener, simplificar, rediseñar o retirar. Una solución que ya no participa en decisiones útiles no tiene por qué conservarse operativa por inercia.

La experiencia de los pipelines de datos sencillos resulta especialmente valiosa aquí: separar pasos, comprobar entradas y dejar salidas identificables facilita localizar fallos sin rehacer todo el recorrido.

Caso práctico: conservar durante años una previsión semanal de demanda

Imaginemos una pequeña distribuidora que utiliza ventas históricas, inventario y calendario comercial para estimar la demanda semanal de veinte familias de productos. Al principio, una persona ejecuta un script y envía una hoja de cálculo. La previsión parece útil y la organización decide incorporarla a su rutina de compras.

Etapa 1: hacer identificable cada previsión

Cada ejecución conserva su fecha de corte, rango de entrenamiento, versión de transformación, versión del modelo, datos utilizados y archivo de resultados. La previsión no se sobrescribe sin conservar un identificador. Así puede compararse lo que se sabía el lunes con lo que ocurrió después, sin utilizar información posterior para explicar una predicción anterior.

Etapa 2: definir controles de entrada

El proceso comprueba que las ventas no se hayan duplicado, que las devoluciones se interpreten correctamente, que los productos estén identificados y que los festivos correspondan al periodo que se va a predecir. Si una familia presenta datos incompletos, se marca como excepción en lugar de ocultar el problema mediante una cifra inventada.

Etapa 3: vigilar el desempeño real

Cuando llega la demanda observada, se calculan los errores por semana y familia de productos. Se contrastan con un método de referencia sencillo, por ejemplo la demanda de la semana equivalente anterior ajustada por un criterio explícito. También se observa si una media global buena está escondiendo errores frecuentes en familias pequeñas.

Etapa 4: controlar cambios de negocio

La empresa abre un nuevo canal de venta. No se entrena automáticamente un modelo con datos mezclados y sin análisis. Primero se comprueba si la nueva fuente tiene la misma definición de venta, si existen duplicidades y si el comportamiento exige separar segmentos. La nueva versión se compara con la vigente antes de publicarse.

Etapa 5: preparar una alternativa de continuidad

Si la previsión automática falla, el equipo dispone de una regla temporal sencilla y documentada para apoyar la planificación. La salida alternativa se etiqueta como tal y se comunica su limitación. De esta manera, una incidencia informática no se transforma automáticamente en una decisión comercial basada en números de origen incierto.

El aprendizaje del ejemplo es sencillo: la continuidad depende más de conservar contexto, controles y capacidad de respuesta que de elegir el algoritmo más sofisticado. El método predictivo puede mejorar con los años porque el proyecto permite comparar versiones sin perder su historia.

Cómo saber si el proyecto se está volviendo más mantenible

La mantenibilidad no es un atributo abstracto. Puede observarse mediante preguntas y medidas sencillas que muestren si resulta más fácil comprender, operar y modificar el sistema.

• Tiempo de diagnóstico: cuánto se tarda en localizar la causa de una ejecución fallida o un resultado anómalo.
• Tiempo de recuperación: cuánto tarda el proyecto en volver a entregar una salida fiable tras una incidencia.
• Cobertura de verificaciones: qué entradas, transformaciones y salidas críticas disponen de controles automáticos o revisiones definidas.
• Reproducibilidad comprobada: cuántas versiones relevantes pueden volver a ejecutarse o justificarse con sus evidencias.
• Dependencia personal: si una segunda persona autorizada puede ejecutar las instrucciones sin apoyo del autor original.
• Calidad del resultado: estabilidad de métricas, excepciones significativas y desviaciones respecto a la referencia elegida.
• Coste de operación: tiempo humano, infraestructura, licencias, almacenamiento y esfuerzo necesario para mantener la utilidad.

No es necesario convertir todas estas dimensiones en un cuadro de mando complejo. Una revisión breve que registre avances y problemas recurrentes puede ser suficiente. La medida decisiva es si la organización sigue obteniendo valor con un riesgo y esfuerzo razonables.

La sostenibilidad económica también cuenta: mantener un modelo muy elaborado para una decisión que podría resolverse con una regla transparente puede no ser una buena inversión. Es útil revisar este aspecto con el mismo criterio de proporcionalidad que se emplea al aplicar Ciencia de Datos a una microempresa sin sobredimensionarla.

Plan práctico de 90 días para poner orden sin detener el trabajo

Un equipo que ya tiene proyectos operativos no necesita paralizarse para implantar un sistema de mantenimiento. Puede incorporar controles por etapas, empezando por las soluciones que más afectan al negocio.

Días 1 a 30: saber qué existe y qué podría fallar

1. Seleccionar los proyectos activos y clasificar su importancia funcional.
2. Asignar responsables funcionales y técnicos, aunque coincidan en una persona.
3. Crear la ficha mínima de cada proyecto e identificar sus fuentes y salidas.
4. Registrar la última versión conocida que funciona y las dependencias principales.
5. Documentar cómo se ejecuta, dónde se ven los errores y qué hacer si falla.

Días 31 a 60: transformar supuestos en comprobaciones

1. Establecer contratos básicos de entrada y controles de calidad.
2. Añadir pruebas sobre transformaciones esenciales y casos de referencia.
3. Guardar un registro mínimo de cada ejecución con fecha y versiones.
4. Configurar avisos para los fallos críticos y las salidas desactualizadas.
5. Probar la reconstrucción de una ejecución representativa.

Días 61 a 90: preparar evolución y continuidad

1. Formalizar la revisión previa a cambios y la comparación de versiones.
2. Probar la restauración de un proyecto en un entorno controlado.
3. Definir métricas de utilidad y una cadencia de revisión sostenible.
4. Identificar proyectos que deban simplificarse, rediseñarse o retirarse.
5. Asignar tiempo real de mantenimiento en el calendario de trabajo.

Los 90 días son un ejemplo de organización del esfuerzo, no un plazo técnico obligatorio. Un solo análisis sencillo puede requerir mucho menos; una solución crítica, con varias fuentes y requisitos estrictos, puede necesitar controles más amplios desde el primer día.

Errores de mantenimiento que conviene evitar

Algunas decisiones parecen ahorrar tiempo al principio y terminan aumentando la fragilidad del proyecto:

• Guardar solo el código: impide explicar diferencias si los datos y parámetros han cambiado.
• Confiar en que una ejecución correcta implica una predicción válida: confunde disponibilidad con calidad analítica.
• Actualizar bibliotecas directamente en producción: introduce cambios difíciles de aislar.
• Automatizar reentrenamientos sin controles: puede consolidar errores recientes o reproducir sesgos.
• Usar el mismo conjunto para entrenar y evaluar: presenta resultados optimistas que no reflejan el uso futuro.
• Acumular exportaciones con datos personales indefinidamente: incrementa exposición y dificulta cumplir las obligaciones aplicables.
• Depender de una sola persona: convierte una ausencia en un riesgo operativo.
• No decidir cuándo terminar: conserva procesos sin destinatario, utilidad o propietario claro.

Para evitarlos no hace falta documentarlo todo con el mismo detalle. Es más eficaz concentrar el esfuerzo donde un fallo puede producir decisiones equivocadas, interrumpir una operación o exponer información.

Preguntas frecuentes sobre mantenimiento de proyectos de Ciencia de Datos

Conclusión: un proyecto duradero debe poder entenderse, comprobarse y recuperarse

La Ciencia de Datos no termina cuando un análisis produce su primera conclusión o un modelo alcanza una métrica satisfactoria. A partir de ese momento empieza la responsabilidad de conservar el significado de sus datos, detectar desviaciones, controlar cambios y evitar que el resultado se convierta en una caja negra.

Las prácticas fundamentales son concretas: inventariar lo que existe, atribuir responsabilidades, conservar versiones y evidencias, validar entradas, probar transformaciones, observar el resultado, gestionar actualizaciones y comprobar la recuperación. Cada una protege una parte diferente de la continuidad.

El criterio de fondo es la proporcionalidad. Una pequeña empresa puede aplicar estas prácticas con herramientas accesibles y revisiones breves; un sistema crítico necesitará más automatización, separación de entornos y control formal. En ambos casos, el éxito a largo plazo consiste en seguir tomando decisiones fiables sin depender de la memoria de quien desarrolló el proyecto originalmente.