Por qué tus proyectos IA mueren en el mes 3

TL;DR

La mayoría de proyectos IA en PyMEs no mueren por falta de tecnología, mueren por falta de mantenimiento planificado. El costo de sostener un sistema IA equivale al 20-30% del costo original de construcción cada año, y casi ningún equipo lo presupuesta antes de lanzar. Este problema es especialmente visible en equipos de Latinoamérica y España, donde los ciclos de aprobación de presupuesto son más lentos y la deuda técnica se acumula sin visibilidad ejecutiva.

El mes 3 no es una coincidencia

Hay un patrón demasiado consistente en equipos de toda Latinoamérica y España: el proyecto IA arranca bien, el equipo lo usa con entusiasmo durante las primeras semanas, y hacia el mes 3 el uso cae en picada. Para el mes 5, nadie lo menciona en las reuniones.

No es mala suerte. Es un modo de fallo estructural que casi siempre tiene las mismas 4 causas. Este artículo las descompone una por una y propone decisiones concretas que deben tomarse antes del lanzamiento, no después de que el problema ya sea visible.

Vale la pena subrayar que este patrón no es exclusivo de equipos sin experiencia técnica. Lo repiten equipos con buenos desarrolladores, buenos presupuestos iniciales y buenas intenciones. El fallo no está en la capacidad del equipo, está en cómo se estructura la fase de operación después del go-live.

La novedad tiene fecha de vencimiento

Cuando un equipo despliega su primer chatbot interno o su primer clasificador de tickets, la curva de adopción inicial parece validar todo. Los primeros 30 días son fáciles: hay curiosidad, hay voluntad de probar, hay paciencia para los errores.

El problema llega cuando el sistema comete el mismo error por tercera vez y el equipo ya no tiene paciencia para reportarlo. La experiencia de usar una herramienta nueva se normaliza rápido; la experiencia de usar una herramienta que falla se vuelve molestia activa.

Sin mejora continua visible, la curva de adopción se invierte exactamente cuando la novedad se agota, que en la mayoría de equipos ocurre entre la semana 6 y la semana 12. Esto aplica tanto en Ciudad de México como en Madrid o Buenos Aires: la psicología del usuario no cambia con la geografía.

Hay una consecuencia directa que los equipos subestiman: cuando la adopción cae, los datos de retroalimentación también caen. El sistema deja de recibir señales útiles sobre sus errores justo cuando más las necesita para mejorar. Es un ciclo que se autorefuerza hacia abajo.

La forma de romper ese ciclo no es hacer campañas internas de relanzamiento. Es tener un mecanismo de mejora activo desde el día 1, con alguien responsable de actuar sobre los errores antes de que el equipo los reporte como molestia general.

Sin dueño, el sistema se degrada solo

El error más común en PyMEs de Latinoamérica y España no es técnico, es organizacional: nadie tiene el proyecto IA como responsabilidad principal. El que lo construyó tiene otras 8 prioridades. El CEO asume que “ya está funcionando”. El equipo de operaciones no sabe qué revisar.

Un sistema IA sin dueño designado acumula deuda silenciosamente. Los prompts se vuelven obsoletos cuando cambia el proceso interno. Los datos de entrada cambian de formato y nadie actualiza el parser. Los umbrales de confianza que funcionaban en diciembre ya no son válidos en marzo.

La solución no es contratar a alguien nuevo. Es definir, antes de lanzar, quién tiene 2-4 horas semanales dedicadas a revisar métricas del sistema, leer los casos donde falló y decidir qué ajustar. Si esa persona no existe en el organigrama antes del lanzamiento, el proyecto tiene fecha de expiración.

Una práctica útil que equipos en España y Chile han adoptado: crear un documento de “pasaporte del sistema” que registra quién es el dueño, cuáles son las métricas de salud, cuándo fue la última revisión y cuáles son los umbrales de alerta. Ese documento vive en el mismo lugar donde vive el resto de la documentación operativa del equipo, no en la cabeza del desarrollador que lo construyó.

El drift de modelos que nadie detecta

Gartner estima que entre el 60% y el 80% de los proyectos de IA en empresas medianas no tienen ningún mecanismo de monitoreo activo una vez desplegados. Eso significa que el equipo solo se entera de que algo salió mal cuando un cliente se queja o cuando alguien revisa a mano una muestra de outputs.

El model drift tiene 2 formas principales en proyectos PyME:

La primera es el data drift: los datos que entran al sistema cambian con el tiempo (nuevos productos, nuevos clientes, nuevo lenguaje del sector) y el modelo empieza a producir respuestas que ya no son relevantes. En mercados de Latinoamérica esto ocurre con frecuencia cuando hay cambios regulatorios, modificaciones en catálogos de productos o variaciones estacionales en el comportamiento del cliente.

La segunda es más peligrosa porque es invisible: el drift de comportamiento del modelo base. Cuando usas la API de un proveedor como OpenAI o Anthropic, el modelo subyacente puede cambiar aunque uses el mismo nombre de endpoint. GPT-4o de enero y GPT-4o de octubre no se comportan idénticamente en todos los casos.

Sin un conjunto de pruebas de regresión que el equipo corra mensualmente, el sistema se puede estar comportando diferente desde hace semanas y nadie lo sabe. El equipo no nota el cambio gradual, del mismo modo que no nota que el café de la oficina está cada vez menos cargado hasta que alguien lo compara con uno de afuera.

La implementación mínima viable de monitoreo para una PyME no requiere herramientas costosas. Consiste en un archivo de 20-30 casos de prueba con input y output esperado, un responsable que los corre una vez al mes y un canal donde se reportan las desviaciones. Eso solo ya pone al equipo en el 20-30% superior de la industria en términos de madurez operativa.

Los ciclos de deprecación que nadie calcula

OpenAI publica su política de deprecación de modelos en su documentación oficial (disponible en platform.openai.com/docs/deprecations): los modelos reciben típicamente un aviso de 6 meses antes de ser retirados, pero las actualizaciones intermedias ocurren con mucha mayor frecuencia.

El problema no es solo que el modelo viejo deja de funcionar. Es que migrar a una versión nueva requiere trabajo real: ajustar prompts, volver a evaluar outputs, actualizar integraciones. Para un equipo de 3 personas con otras prioridades, ese trabajo tarda semanas en hacerse y meses en planificarse.

Un proyecto construido en 2025 sobre un modelo específico puede requerir entre 40 y 80 horas de trabajo de ajuste en 2026 solo para mantenerse funcionando al mismo nivel de calidad. Si ese trabajo no estaba en el presupuesto, se pospone. Y cuando se pospone el tiempo suficiente, el proyecto muere.

Este punto es especialmente crítico para equipos en España que trabajan con proveedores europeos sujetos a los requisitos del AI Act de la Unión Europea. Los ciclos de actualización regulatoria añaden una capa adicional de trabajo que tampoco suele aparecer en el presupuesto inicial.

El presupuesto de mantenimiento que no aparece en ningún plan

El estándar que cita la industria de MLOps es claro: el mantenimiento anual de un sistema de IA en producción cuesta entre el 20% y el 30% del costo original de construcción.

Tabla de referencia: costo de mantenimiento anual según inversión inicial

Costo de construcción	Mantenimiento anual (20%)	Mantenimiento anual (30%)
$5.000	$1.000	$1.500
$15.000	$3.000	$4.500
$40.000	$8.000	$12.000
$75.000	$15.000	$22.500

Esos números incluyen tiempo de revisión de outputs, actualizaciones de prompts, migraciones de modelo, ajuste de integraciones cuando cambia alguna API externa y el costo de herramientas de monitoreo.

Lo que no incluyen: el costo de reconstruir el sistema desde cero cuando se abandona durante 8 meses y ya no hay contexto para retomarlo. En proyectos donde el desarrollador original ya no está en el equipo, ese costo de reconstrucción puede superar al costo inicial.

Casi ningún founder en Latinoamérica o España incluye esta línea en el presupuesto inicial. El proyecto se aprueba con el costo de build, el mantenimiento se asume implícitamente como “lo que sea que cueste”, y cuando llega la primera factura real de mantenimiento en el mes 6, la decisión más fácil es dejar de invertir.

Hay una forma sencilla de evitar esta situación: presentar el presupuesto del proyecto IA como un número de 2 años, no de un año. Si el build cuesta $15.000 y el mantenimiento anual cuesta $3.000-$4.500, el costo real del proyecto para el año 1 y el año 2 es entre $21.000 y $24.000. Ese es el número que debe aprobarse, no solo el de construcción.

Cómo planificar para sobrevivir al mes 3

Hay 3 decisiones que deben ocurrir antes del día de lanzamiento, no después.

Primero, define las métricas de salud del sistema: tasa de error, confianza promedio de las predicciones, tiempo de respuesta, y un mínimo de 20 casos de prueba que el equipo puede correr manualmente cada mes para detectar degradación. Estas métricas deben estar documentadas y ser visibles para el responsable del negocio, no solo para el equipo técnico.

Segundo, asigna presupuesto de mantenimiento en el plan financiero del año. Si el build costó $12.000, reserva $2.400 como mínimo para el año siguiente. Sin esa línea en el presupuesto, el mantenimiento siempre compite con prioridades más urgentes y siempre pierde. En equipos de Latinoamérica donde los presupuestos se aprueban anualmente, esta reserva debe estar en el plan antes de que cierre el año fiscal anterior.

Tercero, revisa la política de deprecación del proveedor que usas y pon una alerta en el calendario para evaluar migraciones 3 meses antes de cualquier fecha anunciada. Si el proveedor no publica fechas claras, agenda una revisión trimestral de versiones como parte del calendario operativo estándar.

Lo que diferencia a los proyectos que sobreviven

Los proyectos IA que siguen funcionando 18 meses después del lanzamiento tienen 3 características comunes: un dueño con tiempo real asignado, un presupuesto de mantenimiento aprobado antes del go-live y un conjunto de pruebas de regresión que se corren de forma regular.

No son proyectos con tecnología más sofisticada. No son proyectos con presupuestos más grandes. Son proyectos donde alguien tomó decisiones de operación antes de que la urgencia del lanzamiento las hiciera invisibles.

En Latinoamérica y España, donde muchos equipos están construyendo su primer sistema IA en producción, estas decisiones operativas son menos intuitivas que las decisiones técnicas. El ecosistema habla mucho de qué modelo usar y poco de cómo sostenerlo. Este artículo es un intento de inclinar esa conversación.

Conclusión

Los proyectos IA en PyMEs de Latinoamérica y España no mueren por tecnología mala, mueren por planificación incompleta. El mes 3 es el momento donde la novedad se agotó, el dueño nunca fue designado formalmente y el presupuesto de mantenimiento no existía. Calcular el 25% del costo de build como reserva anual de operación antes de aprobar cualquier proyecto IA es la decisión más barata que puede tomar un equipo hoy. No requiere más tecnología. Requiere una conversación diferente antes de lanzar.

¿Necesitas ayuda para construir esto?

Kreante acompaña a PyMEs y founders en Latinoamérica y España que quieren reemplazar SaaS caro con IA personalizada. Hemos shipped 265+ proyectos (60% LowCode/AI, 70% B2B) en US, Europa y LatAm.

Agenda una llamada de 30 minutos con Kreante