Implantar sistemas de IA multiagente en una pyme puede aportar una automatización útil: varios asistentes especializados colaboran para clasificar información, preparar respuestas, consultar documentación o coordinar tareas. Pero esa misma capacidad de actuar en cadena introduce riesgos que no existen, o son mucho menores, cuando se usa un único asistente para redactar un texto.

Un sistema multiagente no debe entenderse como “varias herramientas de IA trabajando solas”. Es una arquitectura conectada a datos, documentos, correo, CRM, ERP y otras aplicaciones de la empresa. Por tanto, el riesgo no depende solo de si el modelo responde bien o mal. Depende de qué información puede consultar, qué acciones puede ejecutar, quién valida esas acciones y si la empresa puede reconstruir lo ocurrido tras un incidente.

Para una pyme, el objetivo no debería ser conseguir la máxima autonomía desde el primer día. Debe ser automatizar tareas concretas con un nivel de control proporcional al impacto que tendría un error.

Dónde están los principales riesgos de un sistema multiagente

El primer riesgo es el acceso excesivo a datos y sistemas. Un agente que prepara informes puede necesitar consultar pedidos, datos de clientes o documentación interna. No necesita, sin embargo, modificar precios, exportar toda la base de datos comercial o acceder al buzón completo de dirección. Cuando se conceden permisos amplios “por si acaso”, un fallo del sistema se convierte rápidamente en un problema de seguridad o confidencialidad. Este principio resulta especialmente importante al proteger el CRM, el ERP y la facturación, como se explica en esta guía sobre seguridad de los agentes de IA en reservas conectadas al CRM.

Esto es especialmente relevante porque los agentes no solo leen información. En muchos proyectos se conectan a herramientas reales: crean tickets, actualizan fichas, envían correos, gestionan pedidos o lanzan flujos internos. La pérdida de información confidencial puede producirse en las respuestas, en registros de actividad, en la memoria que conserva el sistema o en una acción mal ejecutada. Los riesgos de exponer datos de clientes y permitir accesos indebidos también se observan en aplicaciones sectoriales, como la seguridad de los agentes de IA en las reservas de hotel.

El segundo riesgo es el uso indebido de herramientas. Una aplicación tradicional ejecuta una orden concreta. Un agente interpreta una instrucción y decide qué llamada hacer a una herramienta. Si interpreta mal una petición, recibe una orden ambigua o genera una respuesta incorrecta, puede utilizar una herramienta válida en un contexto inadecuado. Por ejemplo, un asistente diseñado para actualizar un pedido podría cambiar un dato maestro de cliente si sus permisos y validaciones no están bien definidos.

También hay que considerar la manipulación mediante contenido externo. Un correo, un documento adjunto o una página web pueden contener instrucciones ocultas o redactadas para inducir al sistema a ignorar sus reglas de trabajo. Si un agente lee ese contenido y lo toma como una instrucción legítima, puede acabar solicitando datos, enviando información o llamando a herramientas que no debería. En una arquitectura con varios agentes, el problema puede propagarse: un agente contaminado entrega una conclusión errónea a otro, y el segundo la transforma en una acción.

El tercer riesgo es el fallo en cascada. Un agente puede resumir mal un contrato; otro utiliza ese resumen para preparar una respuesta al cliente; un tercero envía el correo. Cada componente puede haber hecho algo aparentemente razonable, pero el resultado final es incorrecto. La coordinación entre agentes añade eficiencia, pero también multiplica las dependencias y hace más difícil detectar dónde se originó el error.

Por último, muchas pymes infravaloran la falta de trazabilidad. Si no se registra qué agente consultó qué datos, qué decisión tomó, qué herramienta utilizó, con qué parámetros y cuál fue el resultado, no se puede investigar un incidente ni corregir el proceso. Un sistema que no permite reconstruir sus acciones no está preparado para procesos comerciales, financieros, legales o de atención al cliente con impacto real. Mantener un inventario de agentes, accesos y responsables es una base necesaria para gobernar estos sistemas.

Los controles que una pyme debe exigir antes de dar autonomía

El control más importante es el principio de mínimo privilegio: cada agente debe tener acceso únicamente a los datos, aplicaciones y acciones indispensables para su función. No conviene crear una cuenta genérica con acceso a todo el CRM, ERP y correo corporativo para que la compartan varios agentes.

En la práctica, esto implica separar permisos de lectura y modificación. Un agente puede consultar el estado de un pedido sin poder cancelarlo. Puede preparar un borrador de correo sin capacidad para enviarlo. Puede analizar facturas sin autorización para aprobar pagos. Esta separación reduce de forma drástica el impacto de un error o una manipulación.

Cada agente debe tener además una identidad técnica propia. Así se puede saber qué componente realizó una acción, revocarle el acceso si es necesario y evitar que una credencial comprometida dé acceso a todo el sistema. Los permisos deben limitarse por herramienta, tarea y contexto, no solo por departamento.

El segundo control imprescindible es la aprobación humana en acciones críticas. Hay decisiones que un sistema puede proponer, pero no debería ejecutar por sí solo: pagos, altas o bajas de proveedores, modificaciones de datos maestros, descuentos fuera de política, borrados, comunicaciones externas sensibles o compromisos contractuales.

La aprobación debe ser real, no una notificación que nadie revisa. La persona responsable tiene que ver qué propone el sistema, sobre qué información se basa y qué consecuencia tendrá aprobarlo. Si no hay tiempo para esa revisión, el proceso no está suficientemente preparado para automatizarse.

También conviene definir una lista concreta de acciones permitidas. En lugar de intentar imaginar y bloquear todos los comportamientos peligrosos, la empresa debe decidir qué puede hacer cada agente y dejar todo lo demás fuera de su alcance. Por ejemplo, un agente de operaciones puede abrir una incidencia y asignarla a un equipo, pero no cerrar una reclamación de cliente ni modificar condiciones económicas.

Otro control básico es compartimentar la arquitectura. La memoria de un agente que trata consultas comerciales no debería mezclarse con la de otro que analiza información de recursos humanos o finanzas. Del mismo modo, los agentes que consultan fuentes externas deben estar aislados de aquellos que pueden operar sobre sistemas internos. Cuando se estudian alternativas de ejecución local, también es importante valorar sus implicaciones de privacidad, capacidades y licencia, como muestra este análisis de Muse Glimmer y los agentes de IA locales. IBM destaca la importancia de proteger el punto en el que un sistema pasa de recomendar una acción a ejecutarla en aplicaciones reales, la llamada capa de acción. Puede ampliar este enfoque en su análisis sobre seguridad en sistemas de IA que actúan mediante herramientas.

Finalmente, exija registros completos. Como mínimo, deberían quedar anotados la petición inicial, las fuentes consultadas, el agente que intervino, la herramienta usada, los parámetros enviados, el resultado y el responsable de la aprobación cuando corresponda. Estos registros deben revisarse periódicamente, no solo cuando algo sale mal.

Cómo desplegarlo sin convertir el piloto en un incidente

La implantación prudente empieza por procesos de bajo riesgo y alta repetición. Clasificar solicitudes internas, localizar documentación aprobada, preparar borradores para revisión humana o resumir información operativa son buenos candidatos. En cambio, automatizar pagos, decisiones de crédito, comunicaciones legales o cambios directos en el ERP no debería ser el primer caso de uso.

El primer piloto debe limitarse a uno o dos agentes y una tarea claramente definida. Si el objetivo es “mejorar operaciones”, será imposible decidir qué permisos necesita el sistema, cómo medir el resultado o cuándo debe detenerse. Si el objetivo es “clasificar incidencias entrantes y proponer su asignación”, sí puede diseñarse un flujo controlado.

Antes de pasar a producción, pruebe el sistema con situaciones deliberadamente difíciles: instrucciones ambiguas, documentos con datos contradictorios, intentos de manipular al agente, herramientas no disponibles, peticiones fuera de su función y errores de un agente que otro pueda adoptar como ciertos. No basta con comprobar que cada componente funciona de manera aislada. Hay que probar las cadenas completas de decisión y acción.

La información que alimenta al sistema también debe estar validada. Para procesos internos, conviene priorizar políticas, procedimientos, tarifas y documentos aprobados por la empresa. No es razonable permitir que un agente base una decisión comercial o contractual en contenido web no verificado, un archivo antiguo o una nota interna sin responsable conocido.

Además, debe existir un plan de parada y reversión. La empresa necesita saber quién puede desactivar el sistema, cómo se recuperan las tareas pendientes, qué acciones pueden deshacerse y cómo se informa a los afectados si se produce un incidente. La capacidad de revertir no es un detalle técnico: es la diferencia entre un error controlable y una interrupción operativa seria.

Cuándo no conviene desplegar todavía

No es recomendable poner en marcha un sistema de IA multiagente si no hay un responsable de negocio y un responsable técnico claramente asignados. Tampoco si nadie puede explicar qué datos consulta cada agente, qué permisos tiene o qué sucede cuando falla.

Son señales de alerta claras que un agente pueda enviar correos, alterar datos o ejecutar transacciones sin revisión; que varias funciones compartan las mismas credenciales; que no existan registros detallados; o que el sistema consulte contenido externo sin filtros ni validación.

La recomendación para una pyme es sencilla: empiece con poca autonomía, permisos reducidos y revisión humana. Amplíe capacidades solo cuando disponga de evidencia de que el sistema es fiable, trazable y reversible. La IA multiagente puede mejorar la productividad, pero no debe recibir autoridad operativa antes de demostrar que la empresa puede controlarla.

Lo que vemos en la práctica

En los diagnósticos nos encontramos casi siempre lo mismo, y no tiene que ver con la IA. Aparece una cuenta genérica —del tipo "info@" o "admin@"— que usan tres o cuatro personas y que además está conectada a un par de herramientas. Nadie recuerda quién la creó ni por qué tiene los permisos que tiene. Mientras solo entran personas, el problema se aguanta. En el momento en que se conecta un agente a esa cuenta, deja de saberse quién hizo qué: no hay forma de distinguir una acción del sistema de una acción de una persona, ni de retirar un acceso sin romperle el trabajo a alguien.

El otro patrón habitual es escuchar "esto ya lo tenemos automatizado" y descubrir, al pedir detalle, que nadie en la empresa sabe explicar qué hace exactamente ese proceso, con qué datos ni bajo qué condiciones se dispara. Funciona, así que nadie lo mira. Y ahí está el fondo del asunto: el problema no suele ser la IA, sino el proceso que hay debajo. Automatizar algo que nadie sabe describir no lo mejora, solo lo hace más rápido y más difícil de revisar. Por eso el orden importa: primero claridad, después IA.