Los pilotos de IA no mueren por el modelo: mueren en la frontera del ERP

Hay dos números del informe de MIT NANDA que casi nunca se citan juntos, porque el titular se llevó otro. El 60% de las organizaciones evaluó herramientas de IA empresarial a medida o de proveedor. El 20% llegó a piloto. El 5% llegó a producción.

La caída de sesenta a veinte se explica sola: se evalúa mucho más de lo que se prueba. La interesante es la otra. Entre el piloto y producción se pierden tres de cada cuatro proyectos que ya habían demostrado que funcionaban.

Los propios autores escriben que la brecha «no parece estar impulsada por la calidad del modelo ni por la regulación, sino que parece determinada por el enfoque», y señalan que las soluciones a medida se atascan por «complejidad de integración y falta de encaje con los flujos de trabajo existentes». Gartner llegó al mismo sitio por otro camino cuando predijo en junio de 2025 que más del 40% de los proyectos de IA agéntica se cancelarían antes de acabar 2027: su analista lo atribuye a organizaciones «cegadas» ante la complejidad del despliegue, con proyectos que se atascan antes de llegar a producción.

Esta pieza va de dónde está exactamente esa frontera y de las cuatro preguntas que hay que contestar para cruzarla. No de la ingeniería del paso a producción, que ya tratamos, sino de algo más estrecho y más terco: el punto en el que un agente deja de leer un fichero y empieza a hablar con el sistema donde vive vuestro negocio.

El piloto funcionaba porque no cruzaba nada

Casi todos los pilotos que he visto trabajan sobre una exportación. Un CSV, una carpeta con doscientos documentos copiados, una base de pruebas de hace seis meses. Datos quietos, sin permisos, sin concurrencia, sin nadie más escribiendo a la vez y sin consecuencias si algo sale mal.

Eso no es un atajo del equipo: es la forma sensata de probar una hipótesis. El problema es lo que se concluye del resultado. Cuando el piloto sale bien, la conclusión que se saca es «el modelo sirve para esto». Y es cierta. Pero la pregunta que decidía el proyecto nunca se llegó a hacer, porque la exportación la esquivaba entera.

Producción significa leer el sistema vivo. Con su modelo de permisos, sus campos a medias, sus registros duplicados, su histórico de decisiones que nadie documentó y otras personas modificándolo mientras el agente lo lee. Todo lo que hacía fácil el piloto es, literalmente, la ausencia de esa frontera.

La frontera tiene tres grados, y se cruzan de uno en uno

El error de planificación más caro es tratar «conectar con el ERP» como una sola cosa. Son tres, con costes y aprobadores distintos, y meterlas en la misma fase es lo que hace que un proyecto de ocho semanas se convierta en uno de ocho meses.

La regla práctica que sale de esa tabla es aburrida y funciona: no mezcléis los tres grados en la misma fase. Semanas en lectura, con el agente proponiendo y un humano ejecutando, enseñan más sobre el sistema real que cualquier análisis previo — y cuando llega el momento de escribir, ya sabéis qué campos están sucios, qué permisos faltan y qué excepciones aparecen de verdad.

Pregunta 1 · ¿Con qué identidad actúa?

Es la primera que hay que contestar y la que más veces se contesta por accidente, en una reunión técnica de veinte minutos, eligiendo la opción que desbloquea el desarrollo.

Hay dos atajos y los dos salen caros. El primero es suplantar a un empleado: el agente usa las credenciales de una persona, normalmente las de quien impulsa el proyecto. Funciona el primer día y rompe la traza para siempre — a partir de ese momento el registro del sistema dice que esa persona hizo cosas a las tres de la mañana, y cuando alguien audite el proceso no habrá forma de separar lo que hizo ella de lo que hizo el agente.

El segundo es heredar una cuenta de servicio que ya existía. Es peor de lo que parece, porque esas cuentas se crearon hace años para integraciones que ya nadie recuerda y suelen acumular más permisos que cualquier humano del equipo. El agente no recibe el permiso que necesita: recibe todo lo que esa cuenta arrastraba.

El desorden de fondo está medido. El informe de la Cloud Security Alliance sobre identidades no humanas sitúa la mediana en 45 identidades no humanas por usuario humano en una empresa normal, y hasta 144 en entornos nativos de nube. Pero la cifra que de verdad describe el problema no es esa: es que el 51% de las organizaciones declara no tener una propiedad clara de las identidades de IA, y el 16% ni siquiera registra cuándo se crea una.

Conviene decir de dónde salen esos números: ese informe agrega investigación publicada por terceros en lugar de medir directamente, así que sirve para dimensionar el desorden, no como censo. La dirección, en cambio, coincide con lo que se ve en cualquier proyecto: nadie sabe cuántos accesos automáticos tiene abiertos su empresa.

La respuesta que funciona es sosa: identidad propia, nominal, con el permiso mínimo del proceso concreto y con un dueño humano con nombre. Y una fecha de caducidad, porque la integración que nadie renueva es la que sigue viva tres años después de que el proyecto se cancelara. Cómo se acotan esos permisos cuando el agente además usa herramientas lo desarrollamos al hablar de inyección de prompts: la seguridad de un agente está en lo que puede hacer, no en lo que se le pide.

Pregunta 2 · ¿Qué queda escrito, y en qué registro?

Todo sistema de registro serio tiene traza de auditoría. El problema no es que falte: es que hay dos y no se juntan.

El registro del ERP anota qué pasó: qué cuenta modificó qué campo, cuándo, con qué valor anterior. Es lo que necesita un auditor financiero y lleva décadas resuelto. El registro del agente anota por qué: qué se le pidió, qué documentos leyó, qué razonamiento siguió, con qué confianza. Y vive en otro sistema, con otro formato, otra retención y a menudo otro proveedor.

Cuando alguien pregunte «¿por qué este pedido se aprobó solo?», la respuesta está repartida entre los dos y unirla es trabajo manual, a menos que se haya diseñado antes. Lo barato es un identificador de correlación que viaje del uno al otro; lo caro es reconstruirlo seis meses después con capturas de pantalla.

El Reglamento Europeo de IA lo convierte en obligación para los sistemas de alto riesgo: su artículo 12 exige que permitan «el registro automático de acontecimientos (registros) a lo largo del ciclo de vida del sistema», con capacidad de registro suficiente para identificar situaciones de riesgo y facilitar la vigilancia posterior a la comercialización. No todos los procesos de una empresa caen en esa categoría —conviene mirarlo caso por caso y no asumir lo peor— pero el diseño que satisface la obligación es el mismo que hace falta para poder explicarse ante un cliente enfadado. La pieza sobre diseñar agentes que pasen una auditoría desarrolla esa capa.

Pregunta 3 · ¿Qué pasa en la siguiente actualización?

Esta es la que nunca aparece en el caso de negocio, y es la que convierte un proyecto cerrado en un pasivo permanente.

Odoo, que es el ERP más extendido en el mid-market español, lo dice en su propia documentación con una claridad que se agradece: «si un cambio introducido por una versión nueva rompe una personalización, es responsabilidad del mantenedor de tu módulo a medida hacerlo compatible con la nueva versión de Odoo». Y más arriba, en la página de actualización: «si tu base de datos contiene módulos a medida, no se puede actualizar hasta que exista una versión de esos módulos para la versión de destino».

Léelo otra vez pensando en vuestro agente. La integración que estáis a punto de aprobar entra en esa categoría. No es que se pueda romper: es que bloquea la actualización del ERP hasta que alguien la arregle. Y esa misma frase, con otro nombre y otra letra pequeña, está en las condiciones de cualquier sistema de registro serio — la propia documentación de Odoo, cuando enumera qué probar antes de actualizar, empieza por «integraciones con software externo (EDI, API, etc.)».

La consecuencia práctica no es técnica, es de presupuesto y de gobierno: quien aprueba la integración está aprobando también su mantenimiento en cada versión mayor, durante los años que dure. Si esa línea no está en el caso de negocio, el caso de negocio está incompleto, y el día que llegue la factura la conversación será sobre por qué nadie lo dijo.

Aquí hay una decisión de arquitectura con consecuencias largas: cuanto más se apoya la integración en el modelo interno del sistema —tablas, campos, módulos a medida—, más se rompe. Cuanto más se apoya en su interfaz pública y estable, menos capacidad tiene, pero sobrevive a las versiones. No hay respuesta correcta; hay una elección que conviene hacer con los ojos abiertos y dejar escrita.

Pregunta 4 · ¿Y si el sistema está equivocado?

Las tres primeras preguntas tienen dueño: alguien de sistemas, alguien de proceso, alguien de presupuesto. Esta cuarta no tiene dueño y es la que más dinero cuesta.

Un agente que lee el CRM asume que el CRM tiene razón. No tiene forma de no asumirlo: es su única fuente. Un humano que ve una fecha de renovación imposible o un contacto con el cargo de hace tres empleos levanta la ceja y pregunta. El agente lo usa, construye encima una respuesta impecable y la deja escrita.

El modo de fallo, por tanto, no se parece a un error. No hay excepción, no hay traza roja, no hay alerta. Hay una salida plausible construida sobre un dato falso, y firmada por un proceso automático, que es justo lo que le da autoridad ante quien la lee.

Es el mismo mecanismo del que hablábamos a propósito de los tests generados: un sistema que sólo puede aprender del estado actual describe ese estado, no lo juzga. Un CRM sucio no produce un agente que falla; produce un agente que miente con confianza. Y por eso la preparación mínima de los datos no es una fase previa opcional: es lo que fija el techo de lo que se puede automatizar sin supervisión.

El orden, que importa más que las respuestas

Ninguna de las cuatro preguntas tiene una respuesta universal: dependen del sistema, del sector y de cuánto riesgo esté dispuesta a asumir la dirección. Lo que sí es transferible es la secuencia.

Un proceso antes que una plataforma. La tentación es montar la capa de integración buena, la que servirá para todo. Es más caro y más lento, y sobre todo aplaza el aprendizaje: hasta que un proceso no llega a producción, todo lo que sabéis del sistema real son suposiciones. Empezad por uno concreto y aburrido — de los aburridos hay bastantes documentados, y comparten que el coste actual se puede medir sin discutirlo.

Lectura antes que escritura. No por prudencia genérica, sino porque durante esas semanas el agente os enseña gratis qué campos están sucios, qué permisos faltaban y qué excepciones existen de verdad y no en el diagrama. Ese conocimiento no se puede comprar y no aparece en ningún análisis previo.

La ruta de excepción antes que el camino feliz. Quién recibe el caso dudoso, con qué contexto llega y en cuánto tiempo tiene que resolverse para que el proceso no se atasque. Si no sabéis contestar quién recibe la excepción, el proceso no está listo, por bien que funcione la demo. Es la parte que decide la adopción y la que casi siempre se diseña la última.

Y el permiso mínimo desde el primer día, aunque frene una semana. Ampliar permisos es una conversación de diez minutos; reducirlos, cuando ya hay procesos colgando, es un proyecto. Es la misma lógica que aplicamos al mínimo exigible de gobernanza: lo barato es ponerlo antes.

Lo que esto no es

No es un argumento contra los agentes. El mismo informe de MIT documenta que el 5% que cruza extrae valor real y medible, y que quienes lo consiguen no lo hacen con mejores modelos sino exigiendo personalización sobre procesos concretos y evaluando por resultado de negocio en vez de por benchmark.

Tampoco es un argumento a favor de montar un programa de integración de nueve meses antes de tocar nada. Sería el error contrario y tiene el mismo final: el proyecto se muere de gobierno en lugar de morirse de técnica.

Y conviene tratar las cifras con la misma honestidad con la que sus autores las publicaron, que es más de la que se ve en casi todas las presentaciones que las citan. El informe de MIT se presenta como hallazgos preliminares, no está revisado por pares, sus 153 respuestas se recogieron en cuatro congresos —un sitio donde nadie presume de fracasos, y donde acude quien ya está en la conversación— y advierte en sus propias páginas que sus números son «direccionalmente correctos, basados en entrevistas individuales más que en información oficial de las compañías» y que «pueden no representar patrones más amplios del mercado». Añado una comprobación que casi nadie hace al citarlo: la página oficial de Project NANDA en el MIT Media Lab no aloja el informe, pese a que su investigador principal figura entre los cuatro autores. Nada de esto lo invalida, pero fija para qué sirve: para describir una forma, no para calcular un ROI ni para llevarlo a un comité como si fuera un censo. La forma, en cualquier caso, coincide con lo que se ve en cada proyecto: el modelo casi nunca es el problema, y la frontera casi siempre lo es.

Si vuestra empresa ya tiene gente usando IA por su cuenta —y las tiene—, esta conversación ya está ocurriendo sin vosotros, con datos que salen del sistema por el portapapeles y sin ninguna de las cuatro respuestas escritas. Contestarlas no es burocracia previa: es lo que separa un piloto que impresiona de un proceso que se queda.

Preguntas frecuentes

¿Por qué el piloto funcionaba y el despliegue no?

Porque el piloto casi nunca cruza la frontera. Trabaja sobre una exportación, un conjunto de documentos copiados a una carpeta o una base de pruebas: datos quietos, sin permisos, sin concurrencia y sin consecuencias. Producción significa leer el sistema vivo, con su modelo de permisos, sus registros a medias y otras personas escribiendo a la vez. Todo lo que hacía fácil el piloto es la ausencia de esa frontera. El informe de MIT NANDA lo mide en la caída: el 60% de las organizaciones evaluó herramientas de IA empresarial, el 20% llegó a piloto y sólo el 5% a producción — y los autores escriben que la brecha no parece venir de la calidad del modelo ni de la regulación, sino del enfoque.

¿Con qué identidad debería actuar un agente sobre el ERP o el CRM?

Con una propia, nominal y con el permiso mínimo del proceso concreto — nunca suplantando a un empleado ni heredando una cuenta de servicio genérica que ya existía. Suplantar rompe la traza: el registro del sistema dirá que lo hizo una persona que no estaba delante. Heredar una cuenta de servicio antigua suele dar al agente más permisos que a cualquier humano del equipo, porque esas cuentas se crearon para integraciones que ya nadie recuerda. El trabajo de la Cloud Security Alliance sobre identidades no humanas pone cifra al desorden: el 51% de las organizaciones dice no tener una propiedad clara de las identidades de IA y el 16% ni siquiera registra cuándo se crea una.

¿Es más difícil que el agente escriba que que lea?

Es otro proyecto, no el mismo proyecto un poco más grande. Leer se resuelve con permisos de consulta y una conversación técnica. Escribir abre tres frentes que no son técnicos: quién aprueba que un proceso automático modifique un registro contable o comercial, qué pasa con la escritura equivocada que nadie detecta hasta el cierre, y cómo se deshace. Y hay un tercer grado que se suele confundir con el segundo: escribir con efectos, cuando el apunte dispara un correo al cliente, un pago o un asiento. Ahí el error ya salió de vuestro edificio. La regla práctica es no mezclar los tres grados en la misma fase del proyecto.

¿Qué pasa cuando actualizamos el ERP?

Que la integración es un pasivo permanente, no un proyecto que se cierra. La documentación de Odoo lo dice sin rodeos para su propio producto: si un cambio de una versión nueva rompe una personalización, la responsabilidad de hacerla compatible es del mantenedor del módulo a medida, y una base de datos con módulos a medida no se puede actualizar hasta que exista una versión de esos módulos para la versión de destino. Esa frase, con otro nombre, está en las condiciones de cualquier sistema de registro. La consecuencia de presupuesto es la que importa: quien aprueba la integración está aprobando también su mantenimiento en cada versión mayor, y eso casi nunca aparece en el caso de negocio.

¿Y si el dato del sistema está mal?

El agente no tiene forma de saberlo, y ese es el modo de fallo más caro de todos porque no se parece a un error. Un humano que ve un campo raro pregunta; un agente que lee el mismo campo lo usa. El resultado no es una excepción visible sino una respuesta plausible construida sobre un dato falso, que además queda escrita en el sistema con la autoridad del proceso automático. Por eso la preparación de datos no es una fase previa opcional: es lo que determina el techo de lo que se puede automatizar. Y por eso conviene empezar por procesos donde el dato de entrada se pueda contrastar contra algo, no por los que dependen de campos que nadie mantiene.

¿Por dónde se empieza sin montar un programa de integración?

Por un proceso, en lectura, con la ruta de excepción escrita antes que el camino feliz. Un proceso concreto y aburrido —no el más visible— del que se pueda medir el coste actual. Sólo lectura durante las primeras semanas, para que el error sea reversible mientras se aprende cómo se comporta el sistema real. Y la ruta de excepción decidida antes de arrancar: quién recibe el caso dudoso, con qué contexto y en cuánto tiempo. Si no se sabe contestar quién recibe la excepción, el proceso no está listo para automatizarse, por mucho que el modelo funcione en la demo.

Fuentes citadas

• Challapally, A., Pease, C., Raskar, R. y Chari, P. — The GenAI Divide: State of AI in Business 2025 (MIT NANDA, julio de 2025; hallazgos preliminares sobre 300+ iniciativas públicas, 52 organizaciones entrevistadas y 153 respuestas de directivos recogidas en cuatro congresos; embudo 60% → 20% → 5% y la atribución al enfoque en lugar de a la calidad del modelo). Enlace a una copia en PDF del documento: la página oficial de Project NANDA en el MIT Media Lab no aloja el informe, aunque su investigador principal firma como autor.
• Cloud Security Alliance, AI Safety Initiative — The Non-Human Identity Governance Vacuum: AI Agents and the Fastest-Growing Unmanaged Attack Surface (20 de mayo de 2026; 45 identidades no humanas por usuario humano de mediana y hasta 144 en entornos nativos de nube; 51% sin propiedad clara de las identidades de IA, 16% sin registro de su creación. Agrega investigación publicada por terceros en lugar de medir directamente)
• Odoo — Upgrade — Odoo 19.0 documentation (documentación oficial; la responsabilidad del mantenedor del módulo a medida, el bloqueo de la actualización con módulos a medida y la lista de integraciones a probar)
• Unión Europea — Reglamento de IA, artículo 12 · Conservación de registros (registro automático de acontecimientos a lo largo del ciclo de vida del sistema para los sistemas de alto riesgo)
• Gartner — Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027 (25 de junio de 2025; Anushree Verma; costes crecientes, valor de negocio poco claro y controles de riesgo insuficientes, con organizaciones «cegadas» ante la complejidad del despliegue)