Implantar sistemas de IA multiagente en una empresa es útil: varios asistentes especializados clasifican información, preparan respuestas y coordinan tareas. Pero esa capacidad de actuar en cadena introduce riesgos que no existen cuando solo se usa un asistente para redactar textos.
La clave: un sistema multiagente no son «varias IA trabajando solas». Es una arquitectura conectada a su CRM, su ERP, su correo y sus documentos. El riesgo no depende de si el modelo responde bien, sino de qué puede consultar, qué puede ejecutar, quién lo valida y si usted puede reconstruir lo ocurrido.
Los cuatro riesgos de la IA multiagente en una empresa
- Acceso excesivo. Un agente que prepara informes necesita consultar pedidos, no modificar precios ni exportar la base comercial. Los permisos «por si acaso» convierten un fallo en una fuga. Aplica igual al proteger el CRM y la facturación, como se explica en esta guía sobre seguridad de los agentes de IA en reservas conectadas al CRM.
- Uso indebido de herramientas. Un agente interpreta una instrucción y decide qué herramienta llamar. Si interpreta mal, puede usar una herramienta válida en el contexto equivocado: actualizar un pedido y acabar tocando un dato maestro de cliente.
- Manipulación por contenido externo. Un correo o un PDF pueden llevar instrucciones ocultas que induzcan al agente a saltarse sus reglas. Con varios agentes, uno contaminado pasa la conclusión errónea al siguiente, que la convierte en acción. Se ve igual en el sector hotelero: seguridad de los agentes de IA en las reservas de hotel.
- Fallo en cascada y falta de trazabilidad. Un agente resume mal un contrato, otro redacta la respuesta, un tercero la envía. Cada paso parece razonable; el resultado no lo es. Sin registro de qué agente consultó qué y con qué parámetros, no hay forma de investigarlo.
Los controles mínimos antes de dar autonomía
- Mínimo privilegio. Separe lectura de escritura. Consultar un pedido sin poder cancelarlo. Redactar un borrador sin poder enviarlo. Analizar facturas sin aprobar pagos.
- Identidad propia por agente. Nada de una cuenta genérica compartida. Así sabe quién hizo qué y puede revocar un acceso sin tumbar el resto.
- Aprobación humana real en pagos, borrados, datos maestros, descuentos fuera de política y comunicaciones sensibles. Real significa que la persona ve qué se propone, sobre qué información y con qué consecuencia. Si nadie tiene tiempo de revisarlo, ese proceso todavía no está listo para automatizarse.
- Lista de acciones permitidas. En lugar de intentar prohibir todo lo peligroso, defina qué puede hacer cada agente y deje fuera el resto.
- Compartimentación. La memoria del agente comercial no se mezcla con la de finanzas. Los agentes que leen fuentes externas van aislados de los que operan sobre sistemas internos. Si valora ejecución local, pesa también la privacidad y la licencia: Muse Glimmer y los agentes de IA locales.
- Registros completos: petición, fuentes, agente, herramienta, parámetros, resultado y quién aprobó. Y revisarlos periódicamente, no solo cuando algo falla.
IBM insiste en proteger justo el punto donde el sistema pasa de recomendar a ejecutar, la llamada capa de acción. Puede ampliarlo en su análisis sobre seguridad en sistemas de IA que actúan mediante herramientas.
Cómo empezar sin convertir el piloto en un incidente
- Elija una tarea repetitiva y de bajo riesgo: clasificar solicitudes, localizar documentación aprobada, preparar borradores. No empiece por pagos ni por cambios en el ERP.
- Limite el piloto a uno o dos agentes y un objetivo concreto. «Mejorar operaciones» no es un objetivo: «clasificar incidencias y proponer asignación» sí.
- Pruebe con casos difíciles antes de producción: instrucciones ambiguas, documentos contradictorios, intentos de manipulación, herramientas caídas. Pruebe cadenas completas, no componentes sueltos.
- Valide las fuentes. Políticas, tarifas y procedimientos aprobados. No una nota interna sin responsable ni contenido web sin verificar.
- Tenga un plan de parada y reversión: quién apaga el sistema, qué acciones se deshacen y cómo se avisa a los afectados.
Cuándo no conviene desplegar todavía
Son señales claras de que aún no toca:
- No hay un responsable de negocio y otro técnico asignados.
- Nadie sabe explicar qué datos consulta cada agente ni qué pasa cuando falla.
- Un agente puede enviar correos o ejecutar transacciones sin revisión.
- Varias funciones comparten las mismas credenciales.
- No hay registros detallados, o el sistema consulta fuentes externas sin filtro.
Lo que vemos en la práctica
Casi siempre el problema no es la IA. Aparece una cuenta genérica —«info@» o «admin@»— que usan tres personas y está conectada a varias herramientas; nadie recuerda quién la creó. Mientras solo entran personas, aguanta. En cuanto se conecta un agente, deja de saberse quién hizo qué.
El otro patrón: «esto ya lo tenemos automatizado», y al pedir detalle nadie sabe explicar qué hace ese proceso ni con qué datos. Automatizar algo que nadie sabe describir no lo mejora: lo hace más rápido y más difícil de revisar. Por eso el orden importa — primero claridad, después IA.
Empiece con poca autonomía, permisos reducidos y revisión humana. Amplíe solo cuando tenga evidencia de que el sistema es fiable, trazable y reversible.
