Imagina dos empresas del mismo tamaño, con un equipo técnico parecido.

La primera ha dado acceso a un agente de IA a su correo, a su ERP y a su carpeta de documentación de proyectos, para que resuma incidencias y prepare informes de seguimiento. Lo hizo porque ahorraba horas de trabajo repetitivo y mejoraba la gestión de los proyectos.

Nadie se paró a decidir qué puede tocar ese agente de IA, quién revisa lo que hace, ni qué pasa si alguien consigue manipular sus instrucciones.

La segunda ha dado al agente las mismas tareas, pero con un acceso recortado a lo estrictamente necesario, una identidad propia distinta de la de cualquier persona del equipo, un registro de cada acción que ejecuta y un botón claro para detenerlo. Si algo falla, lo sabe en minutos y puede pararlo.

Las dos empresas están automatizando lo mismo. Solo una de las dos ha pensado en qué pasa si ese agente se convierte, sin que nadie lo busque, en una puerta de entrada para hackers.

No es alarmismo, porque la Agencia Española de Protección de Datos (AEPD) publicó el 28 de septiembre un aviso titulado «IA ofensiva: cuando la inteligencia artificial acelera el riesgo para la protección de datos», en el que advierte de que los agentes de IA están permitiendo automatizar la búsqueda de vulnerabilidades, acelerar intrusiones y ejecutar ciberataques con mayor rapidez. Esa publicación llegó solo dos semanas después de que la propia AEPD informara de la primera brecha notificada en España presuntamente ejecutada mediante un agente de IA.

Esto no significa que la IA sea peligrosa en sí misma. Significa que cada permiso que le dais a un agente para trabajar pasa a formar parte de vuestra superficie de ataque, igual que pasaría con cualquier empleado nuevo o cualquier integración que conectéis a vuestros sistemas.

La pregunta no es si vuestra empresa va a usar agentes de IA para automatizar tareas. La pregunta es si, cuando lo hagáis, vais a decidir antes qué gestiona ese agente y quién responde por ello, o si lo vais a descubrir el día que algo salga mal.

Lo que cambia con un agente de IA (y lo que no)

Dar acceso a una herramienta de IA no es distinto, en el fondo, de dar acceso a un proveedor externo o a un nuevo empleado: cuanto más pueda tocar, más daño puede hacer si algo falla, y más interesante se vuelve como objetivo.

Lo que cambia es la velocidad: un agente puede actuar de forma continua, sin que nadie esté mirando en ese momento, y puede recibir instrucciones manipuladas sin que se note a simple vista.

Esto hace que ocho medidas, ninguna nueva ni exclusiva de la IA, se vuelvan especialmente importantes en cuanto conectáis un agente a un proceso real:

• Mínimo privilegio: que el agente solo pueda tocar lo que necesita para esa tarea concreta, nunca todo lo que tiene a su alcance la persona que lo configuró.
• Identidad separada: que el agente tenga su propio usuario y sus propios permisos, no los de la persona que lo puso en marcha.
• Verificación garantizada: doble verificación en cualquier acceso que el agente use para conectarse a vuestros sistemas.
• Logs: un registro de cada acción que ejecuta, con fecha y motivo, no solo del resultado final.
• Segmentación: que un fallo o una manipulación en un proceso no le dé acceso automático a otros sistemas de la empresa.
• Lista de herramientas autorizadas: que el agente solo pueda usar las integraciones que vosotros habéis aprobado, no cualquier cosa a la que pueda conectarse.
• Aprobación de acciones sensibles: que enviar un email a un cliente, mover dinero o modificar un documento contractual pase siempre por una persona antes de ejecutarse.
• Procedimiento de parada: que exista una forma conocida y rápida de detener al agente si algo no va como se esperaba.

Ninguna pyme necesita implementar las ocho a la vez ni contratar un departamento de ciberseguridad para empezar. Necesita decidir, antes de dar acceso a un agente, cuáles de estas ocho aplican a ese caso concreto.

Una plantilla para no delegar a ciegas

Antes de dar a un agente de IA una responsabilidad real —no una tarea puntual, sino algo que va a hacer de forma continua—, conviene responder nueve preguntas sobre esa responsabilidad. Le llamamos el Always-On Workflow Canvas:

1. Responsabilidad: ¿de qué tiene que estar pendiente el agente, en una frase?
2. Trigger: ¿qué dispara su actuación — un email, una fecha, un cambio en un sistema?
3. Fuentes: ¿qué puede consultar para hacer su trabajo, y qué le queda explícitamente prohibido?
4. Cadencia: ¿actúa cada hora, cada día, cada semana, o solo cuando ocurre algo concreto?
5. Acciones: ¿qué puede hacer realmente — leer, proponer, ejecutar?
6. Aprobación: ¿en qué punto necesita el visto bueno de una persona antes de seguir?
7. Evidencia: ¿qué debe quedar registrado para poder demostrar, después, qué hizo y por qué?
8. KPI: ¿qué resultado del negocio tiene que mejorar gracias a esto? No cuánto trabaja, sino qué consigue en relación a productividad, ahorro de costes, reducción de horas, aumento de las ventas, etc.
9. Kill switch: ¿cómo se detiene, y quién puede hacerlo en el momento en que haga falta?

Rellenar este canvas antes de poner en marcha un agente —no después de que algo falle— es lo que separa a la primera empresa del ejemplo de la segunda. No añade semanas de trabajo. Añade una hora de conversación antes de pulsar «activar».

Esto no sustituye al seguimiento del protocolo de gestión de datos, a una auditoría de seguridad ni al asesoramiento en materia de protección de datos: es un primer filtro de sentido común antes de dar acceso real a un agente.

Para procesos que toquen datos de clientes, contratos o información sensible, conviene revisarlo con quien sea la persona responsable, interna o externa, en vuestra empresa.

Si después de leer esto no tienes claro qué puede tocar cada herramienta de IA que usáis, ni quién respondería si algo fallara, ese es exactamente el punto de partida de la auditoría para tu plan de acción de gobernanza y buen uso de la IA. Empieza aquí

Imagen: Magnific