Qué permisos les das, en realidad, a los agentes de IA de tu empresa

Por qué se dejó a los agentes de IA actuar por su cuenta

El 26 de agosto de 2026, Claude in Chrome pasó a disponibilidad general, y el cambio real no fue la extensión en sí, sino el hecho de que los agentes de IA pueden ejecutar acciones en el navegador sin aprobación en cada paso — hasta entonces, cada clic requería confirmación explícita por parte del usuario. Este movimiento no es aislado: toda la industria se ha desplazado, en el último año, de «modelos mejores» hacia «agentes que hacen el trabajo», con permisos cada vez más amplios y cada vez menos supervisión paso a paso, en aplicaciones de nivel producción con memoria y herramientas reales, no solo conversaciones en una ventana de chat.

Para una empresa de Rumanía que se plantea incorporar un agente de IA — para marketing, para soporte, para procesos internos — esto significa una pregunta nueva, que «lo instalamos o no» ya no cubre: ¿cuánta libertad de acción recibe, en realidad, ese agente, y quién decide dónde se detiene? La respuesta seria no es «cuanta más autonomía, mejor», sino un límite explícito, establecido antes de que el agente empiece a trabajar, no descubierto después del primer incidente.

«Agents Rule of Two»: la regla simple que evita desastres

Meta publicó, el 31 de octubre de 2025, un marco sencillo llamado «Agents Rule of Two», pensado precisamente para las empresas que no tienen un equipo de seguridad dedicado a los agentes de IA. La regla identifica tres capacidades de riesgo que puede tener un agente: procesar contenido no fiable (venido de internet, de un correo o de un documento externo), acceder a datos o sistemas sensibles, y la capacidad de cambiar un estado o comunicarse hacia el exterior —enviar un correo, hacer un pago, publicar algo. La regla dice, simplemente: un agente puede tener como máximo dos de estas tres, sin supervisión humana directa.

Si un agente tiene las tres capacidades a la vez —lee contenido no fiable, tiene acceso a datos privados y puede actuar hacia el exterior— sin empezar una sesión nueva entre pasos, no debería dejarse funcionar de forma completamente autónoma. En ese caso, o limitas una de las tres capacidades, o introduces un paso explícito de aprobación humana antes de la acción final. Es una regla lo bastante simple como para comprobarla tú mismo, sin consultoría de seguridad, para cualquier agente que te plantees poner en producción.

Qué significa la «Rule of Two» para los permisos de los agentes de tu empresa

Un ejemplo concreto: un agente que lee los emails recibidos y redacta respuestas que envía automáticamente tiene dos de las tres capacidades — procesa contenido no confiable (los emails recibidos pueden contener instrucciones ocultas) y actúa hacia el exterior (envía respuestas). Si ese agente no tiene, además, acceso a otros sistemas sensibles de la empresa, la combinación se mantiene, según la regla, dentro de una zona aceptable para la autonomía, con supervisión normal.

La situación cambia radicalmente si ese mismo agente recibe también acceso a la cuenta bancaria de la empresa o a la base de datos de clientes — entonces añade la tercera capacidad, y la combinación completa exige o bien eliminar una de las tres, o bien un paso de confirmación humana antes de cualquier acción irreversible. La diferencia entre «agente útil» y «riesgo de seguridad» no está en lo sofisticado que sea el modelo detrás, sino en la combinación exacta de accesos que le has dado, muchas veces sin pensarlo de forma explícita.

Por qué importa justo ahora: el injection sigue sin resolverse

El motivo por el que esta regla importa justo ahora, y no dentro de dos años, es que a la industria se le permitió actuar de forma autónoma antes de tener una solución completa para el prompt injection: la técnica mediante la cual un texto oculto, colocado en una página web o un documento, secuestra las instrucciones de un agente. El informe de OWASP sobre aplicaciones agénticas muestra que el prompt injection está mapeado en seis de las diez categorías del Top 10 Agentic, y de cincuenta y tres proyectos agénticos analizados, veintiocho son precisamente herramientas de programación —justo la clase de herramientas con las que trabaja a diario una empresa de desarrollo de software.

La conclusión práctica no es evitar los agentes de IA, sino no tratarlos como un chatbot cualquiera: un agente que puede navegar por la web sin supervisión o leer documentos de terceros hereda exactamente el riesgo que la industria todavía gestiona activamente. Los límites de permisos no son burocracia innecesaria — son la respuesta directa a una vulnerabilidad real y documentada, no una hipotética o exagerada por la prensa.

Qué exige la ley: el Art. 50 del AI Act, en resumen

Desde el 2 de agosto de 2026 se aplica el artículo 50 del AI Act europeo, que introduce obligaciones de transparencia para cualquier sistema interactivo y para el contenido sintético generado por IA: en la práctica, un chatbot o un agente tiene que comunicar con claridad al usuario que está hablando con un sistema automático, no con una persona. El plazo de gracia para el marcado (watermarking) de contenido generado por sistemas puestos en el mercado antes del 2 de agosto se extiende hasta el 2 de diciembre de 2026, y las obligaciones para los sistemas de riesgo alto siguen aplazadas hacia 2027-2028.

Para una empresa que ya utiliza contenido visual o de vídeo generado por IA en materiales de presentación o en su web — imágenes hero, visuales de producto — esto significa una comprobación simple, pero necesaria: ¿ese contenido cumple con la obligación de etiquetado? No es un cambio drástico de proceso, pero es el tipo de detalle que, si se ignora, se convierte en un problema de cumplimiento normativo fácil de evitar si se aborda a tiempo, y no cuando se descubre en una inspección.

El riesgo oculto: las skills que instalas para el agente

Una parte separada, pero relacionada, del riesgo viene del material con el que están construidos los agentes: los skills, instrucciones en texto que instalas para ampliar lo que puede hacer un agente. Snyk analizó casi cuatro mil skills públicos y encontró que más de un tercio tenía al menos un problema de seguridad, y el análisis independiente de NVIDIA encontró vulnerabilidades reales en aproximadamente una cuarta parte de la muestra. Aquí conviene una nota de honestidad: el título del informe de Snyk habla del «prompt injection» como una proporción grande, pero su propia tabla muestra que el injection representa una porción pequeña del total: el resto son otras categorías de problemas, distintas.

La conclusión práctica es simple: un skill no es un archivo de texto inofensivo, sino que hereda el acceso del agente a variables de entorno, claves API y carpetas sensibles. Antes de instalar un paquete de skills de un marketplace desconocido, merece la pena pasarlo por un escáner dedicado, igual que escanearías cualquier dependencia de código nueva antes de ponerla en producción: la práctica de seguridad del desarrollo de software se aplica aquí exactamente igual, no es un ámbito distinto.

Una checklist práctica antes de dejar que un agente de IA actúe solo

Antes de dejar que un agente de IA actúe de forma autónoma en tu empresa, unas cuantas comprobaciones simples reducen significativamente el riesgo, sin necesidad de un equipo de seguridad dedicado ni conocimientos técnicos avanzados — solo la disciplina de repasarlas cada vez que añades una capacidad nueva a ese agente o le conectas una herramienta adicional. La siguiente lista está pensada para repasarse en unos minutos, no para tratarse como una auditoría formal de seguridad.

El checklist no sustituye una discusión más amplia sobre seguridad si ese agente tiene acceso a operaciones financieras o a datos personales sensibles de clientes: en esos casos, merece la pena implicar a alguien con experiencia específica en seguridad de agentes de IA, no solo el sentido común técnico. Para la mayoría de los procesos internos habituales, sin embargo, estas cinco comprobaciones cubren la mayor parte del riesgo real, con un coste de tiempo casi insignificante comparado con lo que previenen.

• 01Enumera explícitamente las tres capacidades: datos privados, contenido no fiable, acción externa
• 02Comprueba si el agente tiene las tres a la vez, sin una sesión nueva entre medias
• 03Añade un paso de aprobación humana para cualquier acción irreversible
• 04Escanea cualquier skill o plugin instalado antes de ponerlo en producción
• 05Comprueba si todo el contenido sintético generado cumple la obligación de marcado

Errores frecuentes al adoptar agentes de IA en la empresa

El error más frecuente es tratar un agente de IA como una herramienta de productividad cualquiera, sin ninguna discusión explícita sobre qué acceso recibe: se instala, se le dan credenciales «para que vaya más rápido», y el límite de permisos nunca llega a plantearse como tema de conversación. El segundo error es asumir que un proveedor «de confianza» elimina la necesidad de verificación propia: la regla de dos de tres se aplica sin importar quién haya construido el agente, porque el riesgo viene de la combinación de accesos, no de la calidad del modelo de detrás.

El tercer error, el más costoso a largo plazo, es aplazar la conversación sobre permisos hasta después de un incidente —un email enviado por error, una acción ejecutada a partir de contenido manipulado, una fuga de datos. El coste de establecer los límites desde el principio es casi cero; el coste de establecerlos después de que algo haya salido mal incluye, casi siempre, reparar también la confianza perdida, no solo el sistema técnico afectado.

Fuentes y lecturas.

• 01Meta AI Blog — Agents Rule of Two: A Practical Approach to AI Agent Security
• 02Help Net Security — OWASP prompt injection AI security failures
• 03Latham & Watkins — AI Act update: EU resolves to change rules and extend deadlines
• 04Snyk — ToxicSkills: malicious AI agent skills on ClawHub
• 05Help Net Security — SkillSpector: open-source agent skill security scanner
• 06Simon Willison — Prompt injection (ongoing coverage)

Preguntas frecuentes

El equipo de The Niche SocietyIngenieros de IA y software desde Bucarest · LinkedIn

publicado 2026-09-09