SAP: por qué los agentes de IA fallan sin contexto

Un problema de contexto, no de inteligencia

El 80,9% de los equipos técnicos ya tiene agentes de IA en pruebas o en producción, pero solo el 14,4% los desplegó con aprobación completa de seguridad y TI, según el informe State of AI Agent Security 2026 de Gravitee, recogido por TechTimes. Para un founder que está armando su primer flujo de agentes, la lectura es directa: el cuello de botella dejó de ser el modelo y pasó a ser el contexto con el que ese modelo decide.

VentureBeat publicó el análisis de Irfan Khan, presidente y chief product officer de SAP Data & Analytics, que apunta a algo más incómodo: dos agentes pueden mirar exactamente el mismo dato y llegar a conclusiones opuestas. No porque uno esté mal calibrado, sino porque el dato viaja sin la política, el proceso y la prioridad que le daban sentido en su sistema de origen.

¿Por qué dos agentes con los mismos datos deciden distinto?

Khan lo plantea sin rodeos: «Si accedes a un dato desde un entorno de origen y no tiene el contexto, la probabilidad es que vayas a tomar una decisión mal informada». Y agrega el punto que más incomoda a quien diseña sistemas: un usuario humano compensa esa falta con años de conocimiento institucional, pero un agente arranca sin esa historia a menos que la empresa se la entregue.

Según el análisis de VentureBeat, cuando varios agentes operan sin una semántica de negocio compartida aparecen tres fallos concretos:

• La misma cifra lleva a conclusiones distintas según el área que la lea, porque cada función interpreta el número con su propio criterio.
• Agentes que funcionan bien por separado producen un resultado equivocado en conjunto. Cada uno cumple su tarea; el sistema falla igual.
• La precisión se degrada a medida que se acumulan datos, porque el volumen no corrige la falta de significado.

El ejemplo que da la nota es difícil de ignorar: un agente de compras negocia plazos de pago más largos para mejorar el margen, un agente de tesorería retrasa pagos para cuidar la liquidez y un agente de compliance los retiene hasta que pasen todas las validaciones. Los tres hacen bien su trabajo. El resultado combinado es que los proveedores críticos empiezan a postergar a la empresa, y ningún sistema interno marca nada como roto.

El fallo de coordinación en los sistemas multiagente

Hay un segundo problema, más estructural: casi ningún proceso de negocio corre en un solo agente de punta a punta. Un agente de entrada de pedidos le pasa la tarea a otro que revisa inventario, que a su vez deriva a un tercero que genera la solicitud de compra o descuenta stock. Si esos pasos se ejecutan fuera de orden, un agente puede descontar una cuenta antes de que otro confirme que la mercadería existe. La tarea se completa, pero el resultado es incorrecto.

Khan lo compara con algo cotidiano: «Es casi como repartir una tarea entre 20 personas para resolver algo de un cliente y después darte cuenta de que nadie convocó una reunión de equipo. Nadie llevó un registro de dónde estabas ni en qué punto del proceso te encontrabas».

La causa de fondo, según el artículo, es histórica. Durante años las empresas extrajeron registros de sus sistemas de origen para centralizarlos en plataformas de datos, y en ese traslado separaron el dato de las políticas, los procesos y el contexto donde había nacido. La separación entre almacenamiento y cómputo permitió escalar cada capa por separado, pero también multiplicó los lagos de datos, los archivos planos y los almacenes de objetos, cada vez más lejos de su significado original.

La «memoria de empresa»: el activo que casi nadie documentó

La propuesta de SAP pasa por lo que Khan llama company memory: los KPIs, las prácticas operativas y el conocimiento acumulado que la empresa quiere que sus agentes apliquen de forma consistente. Su analogía es la de un anciano de la aldea al que uno consulta antes de decidir. «No existe algo así en el mundo agéntico, así que consideremos eso la memoria de empresa», dice.

El punto clave es que no se trata solo de dar acceso a los datos, sino de codificar también las restricciones. Un agente necesita saber no únicamente qué quiere lograr, sino qué no debe hacer nunca y qué condiciones deben cumplirse antes de actuar, como confirmar disponibilidad antes de autorizar un envío. En la plataforma de IA de negocio de SAP, el agent harness y el agent hub cumplen ese rol de capa de control.

La buena noticia, según la fuente, es que buena parte de ese contexto ya existe dentro de la empresa: procesos, datos maestros, reglas operativas y políticas de gobernanza son años de conocimiento acumulado. El desafío es hacerlo viajar junto con los datos que consumen los agentes.

El mercado ya se está moviendo

El interés no es teórico. Gartner reportó que las consultas de organizaciones sobre sistemas multiagente crecieron un 1.445% entre el primer trimestre de 2024 y el segundo de 2025, y ubicó a los sistemas multiagente entre las diez tendencias tecnológicas estratégicas de 2026, según TechTarget.

Los proveedores están respondiendo. En su conferencia SAP TechEd, el 27 de octubre, SAP anunció el Ontology Manager dentro de SAP Business Data Cloud, un Knowledge Graph ampliado y un SAP Enterprise AI Gateway para centralizar autenticación, políticas y auditoría de tráfico de IA, según el comunicado de la compañía. La apuesta declarada es una capa de contexto construida sobre más de 50 años de experiencia en procesos e industrias.

SiliconANGLE recoge una distinción útil del directivo de SAP Ted Way: «Los protocolos abiertos necesitan puertas gobernadas». La compañía también permite que los agentes disparen flujos de n8n, automatización determinística que sigue reglas exactas de principio a fin y no puede alucinar, pensada para procesos regulados o sensibles.

El respaldo financiero también aparece: SAP reportó un current cloud backlog de 24.100 millones de euros, un crecimiento de ingresos cloud del 26% y espera cerrar 2026 en el extremo superior de su rango de 25.800 a 26.200 millones de euros, según ad-hoc-news. La disponibilidad general de las nuevas capacidades de lakehouse y de las funciones de datos de Reltio está prevista para el primer trimestre de 2027.

¿Qué significa esto para tu startup?

No necesitas ser una empresa de 50 años para que este problema te golpee. Si ya tienes dos agentes tocando el mismo proceso, ya tienes el riesgo.

• Documenta la semántica antes de conectar agentes. Define en un glosario qué significa cada métrica clave para tu negocio: qué cuenta como «cliente activo», qué es un «pago vencido», qué margen se mide y cómo. Si dos áreas discuten esa definición, tus agentes también lo harán.
• Codifica restricciones, no solo objetivos. Para cada agente, escribe explícitamente qué no puede hacer nunca y qué condiciones deben cumplirse antes de actuar. Esa lista suele ser más valiosa que el prompt.
• Usa automatización determinística en los pasos sensibles. Si un proceso exige una secuencia exacta por cumplimiento o regulación, no lo dejes a criterio del modelo: resuélvelo con lógica de reglas y reserva al agente para decidir cuándo dispararlo.
• Asigna un dueño y trazabilidad a cada agente. Quién lo creó, quién aprobó sus permisos, qué versión corre y qué decidió en cada paso. Sin eso, cuando algo salga mal no vas a poder reconstruir qué pasó.
• Empieza por un proceso acotado y medible. El error típico es desplegar agentes en paralelo en cinco áreas y descubrir después que ninguno comparte supuestos con los demás.

El contexto no es un detalle de implementación: es el activo que separa un piloto vistoso de un sistema que aguanta producción. Como resume Khan en VentureBeat, «nadie tiene escasez de datos, pero el dato contextual es el verdadero premio».