En el módulo 11 llevamos el producto al mundo: lo lanzamos y logramos que la gente lo adoptara de verdad, no que solo lo probara. Ese fue, para casi todos los cursos de producto, el final feliz. Aquí no. Un producto de software tradicional, una vez lanzado y adoptado, entra en mantenimiento: se parcha, se le agregan funciones, pero su lógica no se pudre sola. Un producto de IA sí. La regla que aprendió de los datos de hace seis meses describe un mundo que ya cambió, y nadie apretó un botón para que empeorara: empeoró solo, callado, mientras el panel seguía verde. Este módulo — el último — trata de la parte del oficio que no tiene fecha de término: cuidar un sistema que se degrada por su cuenta y decidir, con la cabeza fría, cuándo renovarlo y cuándo apagarlo.

La tesis del módulo

Un producto de IA no tiene fecha de fin: el mundo cambia, los datos derivan y el modelo que era excelente hace seis meses hoy miente con la misma confianza de antes. Operar un producto de IA no es mantenerlo: es un compromiso permanente de medir, corregir y decidir cuándo renovar. El dueño de producto que cree haber “terminado” ya tiene un producto que se está pudriendo sin que nadie lo mire.

La mejora continua guiada por datos

Operar bien no es esperar a que algo se rompa. Es correr, sin parar, un bucle que ya conoces por partes de módulos anteriores: producir → medir → aprender → mejorar. El producto sirve a usuarios reales (producir), sus métricas de negocio y de modelo cuentan qué está pasando (medir, con el árbol de KPI del módulo 7), esos números revelan dónde está el cuello de botella (aprender), y se prioriza la corrección que más lo mueve (mejorar, con la disciplina de priorización del módulo 6).

La palabra clave es guiada por datos: en operación, las mejoras no se eligen por intuición ni por la petición más ruidosa, se eligen por lo que los datos de producción dicen que está fallando. Y la priorización no se apaga cuando el producto está en el aire — al contrario, es cuando más importa, porque ahora cada mejora compite no solo con otras mejoras, sino con el trabajo de sostener lo que ya existe.

        EL BUCLE DE MEJORA CONTINUA

   ┌──────────┐   sirve a    ┌──────────┐
   │ PRODUCIR │ ───────────► │  MEDIR   │
   │ en prod  │  usuarios    │ KPI/eval │
   └──────────┘              └────┬─────┘
        ▲                         │ señala
        │ se prioriza y           ▼
        │ se lanza          ┌──────────┐
        │                   │ APRENDER │
   ┌────┴─────┐   revela    │ cuello   │
   │ MEJORAR  │ ◄────────── │ de bot.  │
   └──────────┘             └──────────┘

El bucle no tiene salida dibujada a propósito: no termina. El día que deja de girar, el producto empieza a envejecer.

La deriva: cómo se degrada un producto en silencio

Aquí está el enemigo propio de la IA, el que no existe en el software normal. La deriva (drift, el desajuste progresivo entre el mundo que el modelo aprendió y el mundo real de hoy) es la razón por la que un producto de IA se pudre solo. Viene en dos sabores y conviene distinguirlos, porque se arreglan distinto:

Deriva de datos (data drift): cambian los datos de entrada. Empiezan a llegar consultas sobre productos que no existían cuando se entrenó, en una jerga nueva, de un tipo de usuario que antes no estaba. El modelo sigue haciendo lo mismo, pero sobre un mundo que ya no reconoce.
Deriva de concepto (concept drift): cambia la relación entre la entrada y la respuesta correcta. Lo que ayer era una transacción normal hoy es un patrón de fraude; lo que ayer era una buena recomendación hoy molesta. La pregunta es la misma, pero la respuesta correcta cambió bajo los pies del modelo.

Lo que hace a la deriva tan peligrosa — más que cualquier bug — es cómo falla. Un bug de software lanza una excepción, tira un error 500, se cae y alguien recibe una alerta a las tres de la mañana. La deriva no hace nada de eso. El modelo sigue respondiendo, sigue rápido, sigue con su tono seguro de siempre. Solo que ahora se equivoca más. No hay excepción que atrapar porque, desde el punto de vista del código, todo funciona: la degradación vive en la calidad de las respuestas, no en su disponibilidad.

     DEGRADACIÓN SILENCIOSA vs. MONITOREADA

 calidad
   ▲
   │████ lanzamiento (ambos parten igual)
   │    ╲
   │     ╲___ con monitoreo: se detecta y corrige
   │     ╱   ╲___╱ ╲___╱  (se sostiene arriba)
   │    ╱
   │   ╲          sin monitoreo: cae y nadie
   │    ╲___         se entera hasta el reclamo
   │        ╲___
   │            ╲______
   └────────────────────────────────► tiempo
     hoy      +3 meses      +6 meses

La única defensa es no confiar en que alguien “se dará cuenta”. Se detecta con monitoreo de las distribuciones de entrada (¿están llegando datos distintos a los del entrenamiento?) y con evals online (evaluaciones en producción: medir la calidad real de las respuestas sobre tráfico vivo, no sobre un banco de laboratorio). Esta es la disciplina que en este sitio tiene un curso entero: qué es MLOps existe en gran parte para atacar este problema. Aquí basta con que, como dueño de producto, sepas exigirlo: si nadie está midiendo la deriva, tu producto se está degradando y tú serás el último en saberlo.

Cuándo reentrenar o cambiar de modelo

Detectar la deriva es la mitad; la otra mitad es decidir qué hacer, y esa decisión es de producto, no técnica. Hay tres gatillos (triggers, señales que disparan la decisión de renovar el modelo):

Deriva medida. El monitoreo muestra que la calidad cayó bajo el umbral aceptable. Es el gatillo clásico: el mundo se movió, el modelo se quedó, hay que reentrenar (volver a ajustar el modelo con datos frescos y actuales).
Nuevo modelo del proveedor. Si el producto se apoya en un modelo de un tercero (como vimos en build vs. buy vs. API), aparece una versión mejor, más barata o más rápida. El gatillo aquí no es que algo falle, es una oportunidad: migrar puede subir la calidad o bajar el costo sin tocar tu lógica.
Cambio de requisitos. El negocio pide algo que el modelo actual no da: un idioma nuevo, un dominio nuevo, una latencia menor. El modelo era bueno para el problema de ayer; el problema cambió.

Ninguno de los tres se actúa por reflejo. Renovar tiene un costo-beneficio real: reentrenar cuesta datos, cómputo y tiempo de equipo; migrar de modelo cuesta re-validar todo el sistema. La pregunta no es “¿hay un modelo mejor?”, es “¿la mejora justifica el costo y el riesgo de tocar algo que funciona?”.

Y hay un riesgo que la gente subestima siempre, propio de apoyarse en modelos de terceros: el proveedor puede cambiar el modelo por debajo sin que tú migres nada. Actualiza su versión, y comportamientos que ayer funcionaban hoy cambian. Eso es una regresión (regression, un empeoramiento de algo que antes funcionaba, provocado por un cambio) que tú no provocaste y que puede pasar en silencio — el mismo tipo de sorpresa que en red teaming hace que un jailbreak que el modelo resistía en marzo lo deje pasar en junio sin que nadie tocara una línea. Por eso el ciclo offline↔online del módulo 7 no es opcional: tu suite de evals es lo único que atrapa una regresión del proveedor antes de que la atrape un cliente.

Gestión del ciclo de vida del producto

Renovar el modelo no es reemplazarlo a ciegas. La gestión del ciclo de vida (lifecycle management, gobernar el producto a lo largo de sus versiones y cambios) tiene tres herramientas que conviene nombrar:

Versiones. Cada modelo, cada prompt, cada conjunto de reglas tiene una versión identificable, para poder decir con precisión “el problema apareció con la versión 4.2” y para poder volver atrás. Un producto de IA sin versionado no puede diagnosticar nada.
Experimentos A/B en producción (A/B testing, mostrar la versión nueva a una fracción de usuarios y la vieja al resto, para comparar sus métricas reales). El modelo nuevo no se lanza a todos de golpe: se lanza a un 5% y se mira si su north star sube y sus guardrails aguantan, antes de darle el 100%. Es la forma de renovar sin apostar el producto entero a una corazonada.
La deuda que se acumula. Con cada incidente se agrega un parche: una regla al prompt, una excepción en el código, un filtro para tapar un caso raro. Cada parche resolvió algo real, pero juntos forman una capa de deuda (technical debt, atajos acumulados que abaratan hoy y encarecen mañana) que nadie diseñó y que a nadie le pertenece. Prompts de 800 líneas llenos de “nunca hagas X” son deuda pura. Parte de operar es pagarla: cada tanto, refactorizar el prompt y las reglas en vez de seguir apilando parches.

Deprecación responsable

Todo producto tiene un final, incluso los exitosos. Un modelo mejor lo reemplaza, el problema de negocio desaparece, el costo deja de justificarse. La deprecación (deprecation, el retiro planificado y ordenado de un producto o versión) responsable es lo contrario de simplemente “apagar el servidor”. Apagar sin cuidado deja usuarios huérfanos (gente que dependía del producto y se queda sin salida) y datos huérfanos (información que el producto guardaba y que ahora no tiene dueño ni destino).

Retirar bien tiene una secuencia: avisar con tiempo a quienes lo usan; ofrecer un reemplazo o una salida (a dónde migrar, cómo hacer lo mismo de otra forma); exportar o migrar los datos de los usuarios antes de borrar nada; y recién entonces apagar, conservando lo que la ley o el negocio exijan retener. Un producto de IA que además guarda datos personales arrastra aquí las obligaciones de riesgo y cumplimiento: deprecar no te libera de tus deberes sobre esos datos, y en muchos casos te obliga a eliminarlos de forma verificable.

Ojo: deprecar no es admitir un fracaso. Un producto que cumplió su ciclo y se retira con orden es una historia de éxito completa. El fracaso es el producto zombi: el que nadie usa ya, nadie mantiene, sigue encendido consumiendo costo y sigue exponiendo datos, porque apagarlo “da lata” y nadie se hace cargo de la decisión.

Artefacto: la revisión periódica del producto

En operación, la herramienta central del dueño de producto no es un plan de lanzamiento: es una revisión periódica que se corre en una cadencia fija (mensual o trimestral) y que fuerza la decisión. Sin ella, un producto de IA sigue en el aire por inercia, sin que nadie pregunte si todavía debe estar. La plantilla:

REVISIÓN PERIÓDICA — Producto: Asistente de Soporte IA
Periodo: Q3 2026    Dueño: Líder de producto Soporte IA
──────────────────────────────────────────────────────
1. MÉTRICAS vs. OBJETIVO
   North star (tickets sin humano):  52%  (obj. ≥ 55%) BAJO
   Guardrail CSAT:                   4.3  (piso 4.2)   OK
   Guardrail costo/ticket:           $0.09 (techo $0.10) OK

2. SEÑALES DE DERIVA
   Data drift entradas:   +18% consultas de un tema nuevo
   Evals online calidad:  0.88 → 0.81 en 3 meses (cae)
   Veredicto: deriva confirmada en el tema nuevo.

3. INCIDENTES DEL PERIODO
   - 2 regresiones tras update del proveedor (resueltas)
   - Deuda: prompt creció de 300 a 640 líneas

4. DECISIÓN  (marcar una o varias, con dueño y fecha)
   [ ] Mantener      [x] Mejorar (refactor prompt)
   [x] Reentrenar (tema nuevo)   [ ] Migrar de modelo
   [ ] Deprecar
   Responsable: ___   Fecha compromiso: ___

Lo que hace útil a la plantilla es que la sección 4 obliga a elegir. No permite “seguir como vamos” sin marcarlo como una decisión consciente de mantener. Las cinco opciones — mantener, mejorar, reentrenar, migrar, deprecar — son el menú completo de lo que un dueño de producto puede hacer en operación, y forzarlas a una casilla evita el peor destino de un producto de IA: seguir en el aire por olvido.

Decisión	Se elige cuando…	Costo principal
Mantener	Métricas sobre objetivo, sin deriva	Bajo: solo vigilar
Mejorar	Un driver del árbol de KPI flojea	Medio: trabajo de equipo
Reentrenar	Deriva confirmada, datos frescos disponibles	Alto: datos + cómputo
Migrar	Hay modelo mejor/más barato del proveedor	Alto: re-validar todo
Deprecar	El producto ya no justifica su costo	Medio: salida ordenada

Cuidado: la revisión periódica sin dueño y sin fecha es teatro. Igual que una métrica sin responsable no dispara nada (módulo 7), una decisión de “reentrenar” sin nombre y sin plazo se evapora en el acta de la reunión. La casilla marcada solo vale si abajo hay una persona y una fecha.

Errores comunes

Creer que el producto está “terminado”. Lanzado y adoptado no es terminado: es cuando empieza la parte que dura para siempre. El producto que nadie cree que necesita cuidado es el que se está degradando ahora mismo.
No medir la deriva. Sin monitoreo de entradas ni evals online, la degradación es invisible hasta que llega el reclamo del cliente. Para entonces llevas meses perdiendo calidad y no tienes idea de desde cuándo.
Confundir “el código funciona” con “el producto funciona”. La deriva no lanza excepciones. Un panel de disponibilidad en verde no dice nada sobre la calidad de las respuestas; son dos cosas distintas y solo la segunda importa al usuario.
Migrar a cada modelo nuevo por reflejo. Un modelo más nuevo no es gratis: obliga a re-validar todo el sistema y puede traer regresiones. Se migra por costo-beneficio, no por novedad.
Ignorar las regresiones del proveedor. Si tu suite de evals no corre contra el modelo de producción de forma periódica, un cambio silencioso del proveedor te rompe el producto sin que muevas una línea, y lo descubre un cliente antes que tú.
Dejar que la deuda de parches crezca sin pagarla. Cada regla agregada al prompt resolvió algo, pero un prompt de 800 líneas es frágil e inauditable. Refactorizar la deuda es trabajo de operación, no un lujo.
No deprecar nunca. El producto zombi — encendido, sin uso, sin dueño, consumiendo costo y exponiendo datos — es más caro y más riesgoso que un retiro ordenado. Apagar bien también es hacer producto.

La frase para llevarse

“Un producto de IA no se termina, se cuida. El código puede funcionar perfecto mientras el modelo, en silencio, se equivoca cada vez más sobre un mundo que ya cambió. El oficio no es lanzarlo: es sostener, mes a mes, la unión entre el problema de negocio y una realidad técnica que no se queda quieta.”

Qué viene: cierre del curso

No viene un módulo 13. Este es el final, así que cerremos mirando el camino completo.

Empezamos preguntando si el problema era siquiera de IA — porque el error más caro es resolver con IA lo que no lo necesitaba. Convertimos ese problema en un business case con cifras. Verificamos su viabilidad: si los datos existían y si era técnicamente factible. Decidimos build, buy o API. Trazamos un roadmap realista y aprendimos a priorizar cuando todo parecía urgente. Definimos métricas y KPI para saber si de verdad funcionaba, le pusimos presupuesto y FinOps para que no explotara el costo, armamos el equipo y el modelo operativo, gestionamos el riesgo y el cumplimiento, lo lanzamos y lo hicimos adoptar, y en este último módulo aprendimos a operarlo y evolucionarlo sin que se pudra.

Doce módulos para un solo mensaje central: ser dueño de un producto de IA es unir el problema de negocio con la realidad técnica, y sostener esa unión en el tiempo. La tecnología es una parte — importante, pero una parte. La decisión es el oficio: elegir qué construir, qué financiar, qué medir, qué renovar y qué apagar. Ese cable entre el negocio y la técnica no lo tiende el modelo ni el ingeniero; lo tiendes tú, y tu trabajo es que nadie lo corte.

Felicitaciones por completar el Curso de Producto y Gestión de IA. Si quieres profundizar en la mitad técnica del cable, combínalo con los cursos de este sitio que la sostienen: Evals para las métricas y la calidad, red teaming y seguridad para el riesgo, y los cursos de GPU y RL para entender de dónde sale el costo que tanto vigilaste. Ya sabes tomar la decisión; esos cursos te muestran el terreno sobre el que se toma.

Producto de IA — Módulo 12: operar y evolucionar