Cómo mantener y actualizar un sistema de IA en producción

Por qué esto se hace mal casi siempre

La mayoría de empresas trata un sistema de IA como si fuera una impresora: se instala una vez y se asume que sigue funcionando igual para siempre. No es así. Un sistema de IA en producción tiene tres fuentes de cambio que un software tradicional no tiene: el modelo detrás puede cambiar sin que nadie lo toque, el comportamiento de los usuarios cambia el tipo de preguntas o tareas que le piden, y el costo de cada interacción puede subir sin que ninguna alarma se dispare.

El resultado típico: el sistema funciona bien los primeros tres o cuatro meses, alguien deja de revisarlo porque “ya está andando”, y seis meses después alguien nota que las respuestas empeoraron, que el gasto mensual se triplicó, o que la única persona que entendía cómo estaba armado renunció y nadie puede tocarlo sin miedo a romperlo.

Esta guía es la última del ciclo: asume que ya hiciste el diagnóstico, ya corriste el piloto y ya escalaste el sistema a toda la empresa. Ahora el problema cambia de naturaleza: ya no es implementar, es sostener algo vivo que depende de un proveedor externo que no te avisa cuando cambia las reglas.

Qué significa mantener un sistema de IA en producción

Esto no es soporte técnico reactivo (arreglar cuando algo truena). Es un ciclo formal con cuatro componentes: revisión periódica de calidad y costo, un protocolo para cuando el proveedor cambia el modelo o la API, gestión activa del conocimiento para no depender de una sola persona, y un criterio explícito para decidir cuándo el sistema ya cumplió su vida útil y toca rediseñarlo en vez de seguirlo parchando.

La diferencia entre una empresa que mantiene bien su sistema y una que no, se nota en el momento exacto en que algo externo cambia: la primera lo detecta en días porque tiene señales, la segunda lo detecta en semanas porque un cliente o un empleado se quejó.

El ciclo de mantenimiento, paso a paso

1. Define una cadencia de revisión fija, no esperes a que truene

El mantenimiento de IA no funciona con revisión “cuando haya tiempo”. Necesita una cadencia fija con tres niveles de profundidad.

• Revisión semanal (15-20 minutos): revisar el panel de métricas básico: volumen de uso, tasa de error o de escalamiento a humano, y alertas de costo.
• Revisión mensual (1-2 horas): muestreo manual de conversaciones o decisiones del sistema, comparación contra el mes anterior, revisión de quejas o casos raros que el equipo reportó.
• Revisión trimestral (medio día): evaluación completa contra los KPIs originales del proyecto, revisión de costos acumulados versus presupuesto, y decisión explícita de seguir, ajustar o rediseñar.

2. Monta un tablero de señales, no solo de logs

Los logs sirven para depurar un caso puntual, no para saber si el sistema está saludable. Para eso se necesita un tablero con métricas que se puedan ver en un vistazo.

• Porcentaje de respuestas o decisiones aceptadas sin corrección humana.
• Tasa de escalamiento a un humano: si sube, algo empeoró en la calidad o cambió el tipo de casos.
• Costo por interacción o por token, con alerta automática si se desvía más de un porcentaje razonable del promedio histórico.
• Latencia de respuesta: un modelo más lento puede ser señal de que el proveedor cambió algo en su infraestructura.

3. Ten un protocolo escrito para el día que el proveedor cambia el modelo

Los proveedores de IA actualizan sus modelos y APIs con frecuencia, y no siempre lo comunican con la anticipación que uno esperaría. Cuando eso pasa, el sistema puede empezar a fallar sin que nadie haya tocado una línea de configuración.

• Fija la versión del modelo cuando el proveedor lo permita, en vez de apuntar siempre a “la última”.
• Antes de aceptar una actualización de modelo o API, corre el mismo set de casos de prueba (evals) que usaste al lanzar el sistema, y compara resultados.
• Si detectas una caída de calidad después de un cambio del proveedor, ten un plan B: volver a la versión anterior si es posible, o ajustar el prompt o la arquitectura mientras se investiga.
• Suscríbete a los canales de changelog o notas de versión del proveedor: es la única alerta temprana real que existe.

4. Actualiza documentación y conocimiento en cada cambio, no al cierre del año

El riesgo más silencioso de un sistema de IA maduro es que termine viviendo solo en la cabeza de una persona. Cuando esa persona se va, el conocimiento se va con ella.

• Mantén un registro vivo (no un documento que nadie abre) de cada cambio de prompt, arquitectura o proveedor, con fecha y motivo.
• Documenta el “por qué” de cada decisión de diseño, no solo el “qué”: eso es lo que evita que alguien nuevo rompa algo sin entender para qué estaba ahí.
• Haz que al menos dos personas del equipo puedan operar y ajustar el sistema, no una sola.

Cuándo un parche ya no basta y toca rediseñar

No todo problema se arregla con un ajuste de prompt. Hay una línea donde seguir parchando un sistema cuesta más caro, en tiempo y en riesgo, que rediseñarlo desde una arquitectura distinta.

• El sistema acumula más de tres o cuatro parches “temporales” que nunca se retiraron y que ahora interactúan entre sí de forma impredecible.
• Cada cambio de proveedor obliga a reescribir buena parte de la lógica, señal de que el sistema quedó demasiado acoplado a un modelo específico.
• El caso de uso original creció tanto (más volumen, más tipos de tarea) que la arquitectura inicial, pensada para un piloto, ya no calza con la operación real.
• El costo de mantenimiento mes a mes empieza a acercarse al costo de construir de nuevo con una arquitectura más sólida.

Cuando se cumplen dos o más de estas señales al mismo tiempo, la conversación con el equipo o el proveedor deja de ser “¿qué parcheamos ahora?” y pasa a ser “¿qué versión 2 necesitamos construir?”.

Errores comunes al mantener un sistema de IA en producción

• Tratarlo como “ya quedó listo”: nadie asigna dueño al mantenimiento después del lanzamiento, y el sistema queda huérfano hasta que algo falla en público.
• No fijar versión de modelo: apuntar siempre a “la última versión disponible” del proveedor sin control, así que un cambio ajeno rompe el sistema sin previo aviso.
• Medir solo uso, no calidad: reportar “mil consultas este mes” como si fuera éxito, sin saber cuántas de esas mil dieron una respuesta correcta o útil.
• No tener eval suite: sin un set de casos de prueba fijo, no hay forma objetiva de comparar antes y después de un cambio de modelo.
• Conocimiento concentrado en una persona: cuando esa persona se va de vacaciones o de la empresa, nadie más sabe por qué el sistema está armado como está.

Cómo se ve esto en la práctica

Una empresa de logística tenía un sistema de IA que clasificaba y respondía consultas de seguimiento de envíos, en producción desde hacía más de un año. La revisión mensual mostró algo raro: el costo por interacción había subido cerca de un tercio en dos meses, sin que el volumen de consultas hubiera crecido en la misma proporción.

Al revisar el changelog del proveedor, encontraron que el modelo por defecto había cambiado de versión sin que nadie del equipo lo hubiera solicitado. La nueva versión generaba respuestas más largas, lo que subía el costo por token consumido. El protocolo que tenían escrito les permitió fijar la versión anterior mientras el equipo probaba la versión nueva contra su set de casos de prueba, ajustaba el prompt para acortar las respuestas, y recién después migraba de forma controlada.

El mismo trimestre, la revisión de conocimiento detectó que solo una persona sabía ajustar la lógica de clasificación de urgencias. Antes de que esa persona saliera de vacaciones dos semanas, el equipo documentó el criterio completo y entrenó a un segundo operador. Ninguno de los dos hallazgos habría aparecido sin una cadencia de revisión fija.

Mi criterio

Cómo saber si el mantenimiento se está haciendo bien

El mantenimiento de un sistema de IA está bien ejecutado cuando se puede responder estas preguntas sin buscar información durante media hora:

• ¿Cuál fue la última vez que se revisó la calidad de las respuestas del sistema, y qué se encontró?
• ¿Qué versión de modelo está usando el sistema hoy, y quién decidió esa versión?
• ¿Cuánto costó el sistema el mes pasado, y ese número está dentro de lo esperado?
• ¿Existe un documento actualizado, de menos de tres meses, que explique cómo está armado el sistema y por qué?
• ¿Al menos dos personas en la empresa podrían operar o ajustar el sistema si la persona principal no estuviera disponible?

Si alguna de esas preguntas se responde con “no sé” o “eso lo sabe fulano”, ahí está el próximo punto ciego del sistema.