Por qué el 40% de los proyectos de IA fracasan (y cómo no ser parte)

Un agente nuestro reportó el mismo archivo como guardado dos semanas seguidas. El archivo no existía. Lo descubrimos auditando el pipeline, no leyendo el reporte: el reporte decía que estaba todo bien.

Esa es la versión corta de por qué fracasan los proyectos de IA. No fracasan por el modelo, sino por la ingeniería que nadie puso alrededor.

¿Por qué fracasa el 40% de los proyectos de IA?

Según Gartner, más del 40% de los proyectos de IA con agentes se va a cancelar antes de fin de 2027. Las causas que lista no incluyen al modelo: costos que escalan, valor de negocio poco claro y controles de riesgo inadecuados. Al mismo tiempo, el 74% de las empresas planea desplegar agentes en los próximos dos años. Casi todos van a intentarlo. Cuatro de cada diez se van a estrellar, y no por la idea.

La brecha está entre la demo y producción. En la demo el agente corre una vez, con datos elegidos, delante de gente que quiere que funcione. En producción corre mil veces, con datos sucios, sin nadie mirando. Todo lo que separa una cosa de la otra es ingeniería. Ya escribimos cómo detectar humo en una demo de IA. Esta nota es la que sigue: qué tiene que existir detrás para que la demo se vuelva sistema.

El modelo no es el problema

El modelo es la parte del stack que mejor funciona y la más fácil de cambiar. Claude, GPT o Gemini mejoran cada mes sin que hagas nada. Lo que no mejora solo es lo de alrededor: las pruebas, los límites, la verificación, el freno de gasto.

Esto no lo decimos solo nosotros. En agosto, OpenAI frenó dos semanas el entrenamiento de sus próximos modelos y reforzó su monitoreo con investigadores automáticos que revisan las acciones y el razonamiento de cada modelo y emiten una alerta en menos de 30 minutos ante cualquier señal preocupante. Si el laboratorio que entrena los modelos más grandes del mundo frena su propio entrenamiento para ponerle controles alrededor, tu piloto interno también los necesita.

Los equipos que ya tienen agentes en producción repiten la misma idea. El equipo de Linear, contando cómo construyó su agente interno, enumera cinco reglas y tres no tienen que ver con el modelo: mapear el workflow real antes de escribir código, darle al agente herramientas para buscar contexto en vez de meterle todo el contexto en el prompt, y medir cada salida con evals. Nada de eso es el modelo. Todo eso es ingeniería.

Las 7 reglas que nos costaron plata

Corremos agentes propios todos los días: producen video, vigilan SEO, leen tendencias, abren pull requests. Estas siete reglas no salieron de un paper. Cada una tiene una factura o una cicatriz atrás.

"Probamos y anduvo" no es una prueba. Un intento exitoso es una anécdota. Nuestro pipeline de video genera tres candidatos por escena y un juez automático elige: con un candidato, rechazamos 4 de 6 escenas; con tres, aprobamos 4 de 4. Mismo modelo, mismo prompt. La diferencia fue darle opciones al control de calidad.
Sin logs no hay producción. Si no podés reconstruir qué hizo el agente y por qué, no tenés un sistema: tenés fe. Esta línea la escribió un agente nuestro esta mañana, textual:
```
Posts nuevos: 0
PRs abiertos (draft): ninguno
Saltados (ya procesados): 1
```
Once corridas en dos semanas y casi todas terminan así. Un agente que sabe no hacer nada, y lo deja registrado, vale más que uno que inventa trabajo para justificarse.
Un agente que dice "guardado" no es un agente que guardó. La confesión del principio: dos de tres archivos semanales se perdieron después de reportarse como guardados. La regla que quedó es simple. Toda afirmación de un agente se verifica desde afuera, contra el disco, contra el sistema, contra cualquier cosa que no dependa de su propia palabra.
Correr dos veces no puede romper nada. Si el proceso se corta a la mitad y lo relanzás, no puede duplicar ni pisar lo que ya estaba hecho. En nuestro pipeline el estado vive en un manifest, y un test lee el código de cada etapa y rechaza la que intente escribir sin pasar por el lock. El lock existía hacía meses. Nadie lo llamaba. El test nació de descubrir eso.
El gasto arranca bloqueado. Nuestro cliente de APIs de video nace con el gasto deshabilitado por default. La regla costó 26 créditos: sondear un endpoint con requests reales generó videos que ni siquiera se pudieron cancelar. Hoy gastar requiere autorización explícita y cada pieza tiene un freno presupuestario.
Ningún agente mergea solo. Todo lo que toca producción pasa por una aprobación humana. En nuestro caso es literalmente un emoji en Slack: el agente propone, prepara el cambio y espera. El día que un error sale caro, queremos que la última mano haya sido de una persona.
El agente sabe apagarse. Si un prerequisito falla, termina e informa en una línea. Sin reintentos infinitos, sin procesos zombis. Un lunes se cayó la fuente de datos de nuestro motor de tendencias y el ciclo abortó limpio en cinco minutos. La versión sin fail-safe se habría quedado colgada quemando CPU toda la mañana.

¿Cómo saber si tu piloto va a llegar a producción?

Hacele tres preguntas a tu equipo o a tu proveedor: dónde están los logs de la última semana, qué pasa si el proceso corre dos veces, y dónde está el freno de gasto. Las tres tienen que tener una respuesta concreta y mostrable. Si alguna no la tiene, todavía no tenés un sistema, sino una demo con buena prensa.

Qué hacemos nosotros

Instalamos agentes en operaciones ajenas con estas mismas reglas, porque ya pagamos el precio de aprenderlas en la nuestra. El formato es un piloto de 30 días sobre un proceso tuyo real, con logs, freno de gasto y aprobación humana desde el día uno. Y al final te dejamos el root y el manual: el código es tuyo, los logs son tuyos, el freno es tuyo.

Si tenés un piloto de IA muerto en un cajón, ese es justo el que queremos ver.

Preguntas frecuentes

¿Por qué fracasan los proyectos de IA?

Según Gartner, más del 40% de los proyectos de IA con agentes se va a cancelar antes de fin de 2027, por costos que escalan, valor de negocio poco claro y controles de riesgo inadecuados. La implementación falla antes que la idea.

¿El problema es el modelo de IA?

No. Los modelos como Claude, GPT o Gemini son la parte que mejor funciona y la más fácil de cambiar. Los proyectos mueren por lo que falta alrededor: pruebas, logs, límites de gasto, verificación externa y un humano aprobando lo que sale caro.

¿Qué necesita un agente de IA para funcionar en producción?

Al menos siete cosas: pruebas con varios candidatos, logs de cada acción, verificación externa de lo que afirma, idempotencia para poder correr dos veces sin romper, freno de gasto, aprobación humana para acciones caras y un fail-safe para apagarse solo.

¿Cómo sé si mi piloto de IA va en serio?

Pedí los logs de la última semana, preguntá qué pasa si el proceso corre dos veces y dónde está el freno de gasto. Si las tres preguntas tienen respuesta concreta, va en serio. Si no, todavía es una demo.