El cementerio de los pilotos: seis razones por las que se cancelan los proyectos agénticos

Las demos mejoran cada mes. Cualquiera puede levantar en una tarde algo que parece un agente autónomo, y el entusiasmo en el consejo es real. En la superficie, la adopción parece estar acelerándose.

Solo que los números de debajo cuentan una historia más dura. Cerca del 60% de las empresas no reporta valor medible de la IA (BCG), alrededor del 1% se considera madura en IA (McKinsey QuantumBlack), y se proyecta que cerca del 40% de los proyectos de IA agéntica se cancelen antes de 2027 (Thoughtworks). Eso es un cementerio, y lo llamativo es lo poca variedad que hay en las causas de muerte. Los proyectos no fracasan de mil maneras creativas. Fracasan de unas seis, y cada una es evitable si diseñas para ella antes de empezar.

Aquí están las seis, y qué hacer en su lugar.

Razón 1: escalaron una automatización de portátil, no una arquitectura

La causa de muerte más común es confundir una demo que funciona con un sistema de producción. Un script hecho por alguien del equipo pasa la demo, alguien declara la victoria, y el plan pasa a ser "escalemos esto".

Pero una automatización de portátil y un agente en producción están separados por un abismo que escalar no cruza. La automatización nunca tuvo que gestionar identidad, privilegio mínimo, drift, auditoría ni entradas no confiables, porque en una máquina nada de eso estaba en alcance. Escalar el script solo escala los cimientos que le faltan.

Cómo evitarlo. Trata la demo como evidencia de que la idea tiene mérito, no como el sistema. Antes de escalar, pregunta qué necesita la cosa que el portátil nunca le dio: una identidad, una frontera alrededor de lo que lee, un registro de lo que decide. Si eso falta, no estás escalando un sistema, estás escalando un pasivo.

Razón 2: el agente no podía alcanzar el contexto que necesitaba

El segundo cementerio es más silencioso, porque el agente funciona a la perfección, solo que no ve lo suficiente para importar. Su contexto vive repartido entre el CRM, el core, el repositorio documental y la persona que conoce la única excepción. La organización nunca construyó la capa que permite a un agente alcanzar ese contexto con seguridad.

Así que el proyecto se parte en dos malas opciones. O el agente queda demasiado aislado para ser útil, o se conecta con credenciales amplias y permanentes que el comité de seguridad no va a aprobar. Los dos caminos llevan a la cancelación.

Cómo evitarlo. Reserva presupuesto para la capa de contexto como trabajo de verdad, no como fontanería. El agente debería alcanzar tus sistemas a través de capacidades tipadas y con nombre, actuar bajo su propia identidad de privilegio mínimo y ser estructuralmente incapaz de tratar datos no confiables como una instrucción. Si esa capa no está en el plan, la elección del modelo es irrelevante.

Razón 3: no pudo pasar el comité de seguridad

Muchos pilotos mueren no en producción sino en la revisión de homologación, y el hallazgo es casi siempre el mismo: el agente corre bajo el token personal de quien lo hizo, con acceso permanente a producción. Eso es una llave maestra, y ningún comité de seguridad serio lo aprueba.

El proyecto era técnicamente impresionante y estructuralmente inaprobable. El equipo optimizó para "¿funciona?" y nunca preguntó "¿pasa la revisión?", que en una empresa regulada es la pregunta que de verdad controla la entrada en producción.

Cómo evitarlo. Diseña para el comité de seguridad desde el primer día, no como último obstáculo. Cada agente corre bajo su propia identidad no humana, con credenciales de corta duración y privilegio mínimo y una allow-list de salida explícita, así que no hay secreto estático que robar y la identidad solo puede hacer las pocas cosas para las que se acotó. Mapea cada riesgo agéntico a un control con nombre y comprobable, para que el comité apruebe un control, no una garantía.

Razón 4: la gobernanza de TI no podía gobernar un sistema que se desvía

Algunos proyectos pasan el comité de seguridad y se cancelan unos meses después, cuando la gobernanza descubre que no tiene forma de sostener la cosa. El comité de cambios se construyó para software determinista: misma entrada, misma salida, entregas con control de cambios. No tiene mecanismo para un sistema que cambió porque un modelo se actualizó de noche y nadie entregó nada.

El resultado es un proyecto que parecía gobernado, porque pasó por el proceso normal, y que resulta ser ingobernable en la práctica. Pasó el gate equivocado.

Cómo evitarlo. Añade una capa de gobernanza construida para agentes junto a tu gobernanza de TI, no encima. Los agentes se ganan la autonomía en una escalera graduada controlada por evals, la monitorización de drift puede degradar a un agente automáticamente en cuanto se salga de su listón, y la unidad de gobernanza pasa a ser cada decisión, no cada entrega. La gobernanza determinista sigue haciendo aquello en lo que es buena. La capa nueva asume el drift.

Razón 5: el comité de riesgos no podía aprobar una caja negra

El quinto cementerio es un comité que sigue diciendo que no. El sistema puede funcionar, pero nadie sabe explicar, después, por qué tomó una decisión concreta. Sin eso, un comité de riesgos no puede aprobarlo, y un proyecto que no consigue aprobación no puede escalar.

Aquí es donde "el modelo es impresionante" deja de importar. El comité no está evaluando el modelo. Está evaluando si puede defender el sistema ante un regulador, y no puede defender lo que no puede inspeccionar.

Cómo evitarlo. Haz cada decisión inspeccionable antes de que se confirme. Cada una deja un registro de evidencias append-only y encadenado por hash, escrito antes de que la decisión surta efecto, así que, si la evidencia no se puede escribir, la decisión no ocurre. Las decisiones con consecuencia se resuelven en una persona, por política, y las reglas de cumplimiento son código del que tu equipo de cumplimiento es dueño y que firma. Entonces el comité está aprobando un control documentado y comprobable, que es un sí que sí puede dar.

Razón 6: apostaron a lo grande, no midieron nada y no tenían salida

La última causa de muerte es un fallo de forma del proyecto, y mata buenas arquitecturas junto a las malas. La organización se compromete de antemano con un despliegue amplio, nunca establece una línea base auditable, nunca fija un gate go/no-go, y por eso no tiene forma honesta de saber si la cosa funciona. Se acumulan meses de coste sin manera de demostrar retorno y, con el tiempo, alguien desenchufa un proyecto que podría haber estado bien, porque nadie pudo demostrar que lo estaba.

Cómo evitarlo. No apuestes la empresa para probar la arquitectura. Comprométete en cambio con una Fundación: un proceso de alta consecuencia, llevado a agente gobernado en producción en unas seis a ocho semanas, medido contra una línea base auditable, con un gate go/no-go explícito antes de que nadie se comprometa a escalar.

Una secuencia aproximada lo hace concreto. En los primeros 30 días, demuestra la frontera: levanta la capa de contexto y las identidades para ese proceso, con el agente en Sombra, proponiendo mientras las personas deciden. Entre los días 30 y 60, demuestra la gobernanza: enciende el rastro de evidencias y el punto de decisión de políticas, pasa el agente a Supervisado, y deja que el comité de riesgos inspeccione un control real en lugar de una diapositiva. Entre los días 60 y 90, demuestra el valor en el gate: mide coste por unidad, latencia, mejora de calidad y concordancia con la revisión humana contra la línea base, y decide escalar con evidencia.

Si supera el listón, escalas con pruebas. Si no, has gastado ocho semanas y has aprendido algo real sin exposición en producción, que es un resultado mucho mejor que descubrirlo después de un despliegue amplio.

El replanteamiento

Fíjate en lo que tienen en común las seis razones. Ninguna es "el modelo no era lo bastante bueno". Todas las muertes del cementerio son arquitectónicas o procedimentales: una capa que falta, una identidad inaprobable, un modelo de gobernanza que no ve el drift, una decisión no auditable, o una apuesta hecha antes de que nada estuviera demostrado.

Así que la pregunta no es "¿vamos retrasados en IA?". Es en nuestro proceso más consecuente, ¿tenemos una identidad para el agente, una frontera alrededor de lo que lee, un registro de lo que decide, una capa de gobernanza que lo vea desviarse y un gate fijado de antemano? Y, si no, ¿cuál es la Fundación más pequeña que nos dejaría averiguarlo de verdad, antes de apostar por el segundo proceso?

Si quieres una lectura honesta de dónde caería uno de tus procesos, reserva una reunión.