Qué se rompe cuando conectas más de un sistema de IA en tu empresa

TL;DR

Un solo sistema de IA es manejable: sabes qué datos toca y quién lo revisa. En cuanto conectas un segundo, aparecen tres fallos que por separado no existían: no saber quién hizo qué, permisos que se cuelan sin que nadie los haya concedido, e instrucciones escondidas que llegan de fuera y se ejecutan como si fueran órdenes. Este artículo explica los tres y qué hacer antes de que lleguen a producción.

Un sistema de IA es fácil de vigilar. El segundo, no

Cuando tienes un único agente de IA trabajando en un proceso, la seguridad es casi de sentido común: sabes qué datos ve, qué puede escribir y quién revisa lo que hace. Si algo falla, hay un solo sitio donde mirar.

El problema no nace ahí. Nace en el momento en que ese agente empieza a hablar con un segundo sistema: otro agente, un CRM, un buzón de correo, una herramienta externa. En ese instante deja de haber un único punto que vigilar y aparece algo nuevo: una cadena. Y una cadena falla donde se juntan los eslabones, no dentro de cada uno.

Esto es exactamente lo que describe el OWASP Top 10 para LLM (Large Language Models, los modelos de lenguaje que hacen funcionar a los agentes de IA), el catálogo de referencia del sector sobre riesgos de seguridad en sistemas de inteligencia artificial. Y señala tres fallos muy concretos que solo aparecen al conectar sistemas de IA entre sí.

¿Qué es la trazabilidad y por qué se pierde al conectar sistemas?

El primer fallo es no saber quién hizo qué. Con un agente solo, si algo cambia en tus datos, sabes que fue él. Con dos o tres agentes pasándose trabajo entre sí, una acción final —por ejemplo, una factura modificada o un correo enviado— puede ser el resultado de tres decisiones distintas, tomadas por tres sistemas distintos, y ninguno de ellos guarda por sí solo el recorrido completo.

Es como una oficina donde cada empleado lleva su propio cuaderno de quién le pidió qué. Funciona mientras cada uno trabaja solo. En cuanto empiezan a pasarse tareas entre ellos sin un registro común, llega un momento en que algo sale mal y nadie puede reconstruir, cuaderno en mano, quién tocó qué primero.

La trazabilidad —el registro de qué sistema hizo qué acción, sobre qué dato, y en qué orden— no es un lujo técnico: es lo que separa responder "¿qué pasó aquí?" en el momento de tener que reconstruirlo a mano durante días.

¿Qué son los permisos heredados en agentes de IA encadenados?

El segundo fallo es más sutil. OWASP lo llama excessive agency, permisos excesivos: cuando un agente de IA recibe más capacidad de la que su tarea concreta necesita.

Esto pasa mucho al conectar sistemas: para que el agente A pueda hablar con el sistema B, alguien le da acceso a B. Pero rara vez ese acceso se recorta a "solo lo necesario". Es más rápido darle las llaves completas que fabricar una llave a medida. Y cada vez que se añade una conexión nueva, el agente acumula un poco más de alcance del que nadie repasa.

Es como pasarle a un empleado nuevo el mismo llavero que tenía el anterior, sin revisar qué puertas necesita abrir de verdad. Con una sola persona y un solo llavero no pasa nada. Con cinco personas heredando llaveros durante años, nadie sabe ya qué puerta abre cada llave, ni quién debería tenerla.

Un agente con permisos heredados que nadie ha revisado es, exactamente, esto: un llavero que ha ido creciendo sin que nadie lo audite.

¿Qué es el prompt injection y por qué cambia al conectar sistemas?

El tercer fallo es el que OWASP sitúa como riesgo número uno para aplicaciones con IA: el prompt injection, o inyección de instrucciones. Ocurre cuando una orden escondida dentro de un contenido —un correo, un documento, una página web— se ejecuta como si fuera una instrucción legítima, en lugar de tratarse como el simple texto que es.

Con un solo agente leyendo únicamente lo que tú le escribes, el riesgo es bajo. El problema crece cuando ese agente empieza a leer contenido que viene de fuera —un correo de un cliente, un documento adjunto, una web— y ese contenido pasa, sin filtro, a un segundo sistema con permisos propios.

Es como el chico de los recados que lleva una carpeta de un departamento a otro. Si alguien mete una nota dentro de esa carpeta pidiendo "fírmalo y envíalo ya", el segundo departamento puede no distinguir esa nota del resto de instrucciones legítimas que llegan con la carpeta. La instrucción entró escondida, y el sistema que la recibió no tenía forma de saber que venía de fuera.

El error típico: auditar cada pieza por separado

El error que vemos con más frecuencia es revisar cada sistema por separado —el agente A es seguro, el sistema B es seguro— y dar por hecho que el conjunto hereda esa seguridad. No la hereda. La seguridad de una cadena se mide en los puntos donde se conecta, no en cada eslabón por separado.

Una forma sencilla de comprobar si tu empresa tiene este punto ciego: ¿podrías dibujar en una servilleta qué pasa exactamente cuando entra un correo, desde que llega hasta que un sistema actúa por él? Si no puedes trazar esa línea sin dudar, ahí está tu punto ciego.

En Digital Transformations pasamos un checklist basado en el OWASP Top 10 para LLM por cada agente antes de llevarlo a producción —revisando específicamente estos tres puntos: quién hizo qué, qué permisos hereda y qué entra sin filtrar desde fuera—, con los datos alojados en la UE.

Si estás construyendo o ya tienes varios sistemas de IA trabajando juntos en tu negocio, merece la pena mirarlo con orden antes de que la cadena crezca más. La guía de Equipos Digitales explica cómo se monta un equipo de agentes que escala sin estos puntos ciegos, desde el primer nodo hasta el conjunto completo: https://www.digitransformations.com/equipos-digitales

¿Hablamos? https://www.digitransformations.com/equipos-digitales

Contenido desarrollado con apoyo de la IA y supervisado por el equipo editorial de Digital Transformations