Barreras y gobernanza de los agentes de IA: definición y mecanismos
Las barreras y la gobernanza de un agente de IA reúnen el conjunto de reglas, permisos y controles que regulan lo que tiene derecho a hacer, y que permiten verificar lo que realmente hizo.
Definición breve
Las barreras y la gobernanza designan el conjunto de reglas, permisos y controles que regulan lo que un agente de IA tiene derecho a hacer, antes, durante y después de la ejecución de una acción. Esto cubre los permisos por acción, la validación humana en las decisiones sensibles, la auditoría de lo ocurrido, y la capacidad de cortar el acceso en cualquier momento.
Dar a un agente de IA el poder de actuar solo, sobre sus propias herramientas, plantea de inmediato una cuestión de confianza: ¿quién decide lo que tiene derecho a hacer, y cómo verificar después que no se ha salido de ese marco? Barreras y gobernanza responden juntas a esta pregunta, una a nivel técnico de cada acción, la otra a nivel organizativo del conjunto del sistema.
Definición detallada
Las barreras de seguridad (guardrails) son los mecanismos concretos que limitan lo que un agente de IA tiene derecho a hacer: permisos precisos por acción, alcance de acceso restringido, cuotas, puntos de validación humana en las decisiones sensibles. La gobernanza es el marco más amplio en el que se piensan, se deciden y se auditan esas barreras: quién tiene derecho a configurarlas, cómo se documentan los riesgos, cómo se verifica a posteriori que el sistema se comportó como estaba previsto.
Dos referencias enmarcan hoy la discusión sobre la gobernanza de IA, con lógicas distintas. El AI Risk Management Framework del NIST (AI RMF 1.0), publicado en enero de 2023 en Estados Unidos, es un marco voluntario estructurado en torno a cuatro funciones: Govern (gobernar, la función transversal que define la cultura y las responsabilidades), Map (cartografiar los riesgos de un sistema dado), Measure (medir esos riesgos) y Manage (gestionarlos). La AI Act de la Unión Europea, en cambio, es un texto regulatorio vinculante: para los sistemas clasificados como de alto riesgo, impone un sistema de gestión de riesgos (artículo 8), una gobernanza de los datos de entrenamiento (artículo 10), una documentación técnica (artículo 11), un registro automático de eventos (artículo 12), transparencia hacia los usuarios y una supervisión humana efectiva (artículos 13 y 14). Las obligaciones principales para los sistemas de alto riesgo se aplican a partir de diciembre de 2027 para los sistemas del anexo III, y agosto de 2028 para los del anexo I.
El punto en común entre estos dos marcos, pese a su naturaleza distinta (voluntario frente a vinculante), es la insistencia en la trazabilidad (registrar lo que ocurre) y en la supervisión humana como componentes no negociables de una gobernanza de IA seria, sea cual sea la jurisdicción.
Cómo funciona
Un sistema de barreras eficaz actúa en varios niveles, del más amplio al más preciso. En el nivel más amplio, se decide qué herramientas se conectan a un sistema y qué categorías de acciones son siquiera concebibles. En el nivel intermedio, se define quién, persona o agente, tiene derecho a usar qué herramienta, con qué alcance (solo lectura, o lectura y escritura). En el nivel más preciso, cada acción individual se verifica en el momento en que se solicita: ¿existe el permiso?, ¿cubre bien esa acción precisa?, ¿con argumentos válidos?
El principio más sólido para construir estas barreras es el deny-by-default (rechazo por defecto): nada está autorizado mientras no se haya concedido un permiso explícito, en lugar de partir de un acceso amplio que luego se restringiría caso por caso. Es más exigente de implementar, pero evita el error más frecuente en materia de seguridad, el olvido de una restricción en lugar del olvido de una autorización.
La gobernanza, por su parte, añade una capa de responsabilidad y de verificabilidad: quién configuró tal barrera, cuándo, y si una auditoría permite reconstruir a posteriori lo que realmente ocurrió en caso de duda.
Ejemplo concreto con Atako
En Atako, el modelo de permisos se apoya exactamente en este principio de rechazo por defecto. Conectar una herramienta (Slack, GitHub, HubSpot, u otra integración) a nivel de empresa no da acceso a ningún agente mientras no se haya creado un «grant» explícito. Un grant asocia un agente preciso a una conexión precisa, con una lista de acciones precisas autorizadas (no un acceso genérico a todo GitHub, sino por ejemplo solo list_issues y create_issue), un alcance (solo lectura o lectura-escritura), y una expiración opcional. Incluso si una acción de escritura se añadiera por error a la lista de un grant de solo lectura, el alcance bloquearía de todos modos su ejecución: es un doble control.
La ruta de decisión documentada por Atako sigue este esquema: el agente expresa una intención de acción, la plataforma verifica que existe un grant, que la acción está en la lista autorizada, que el alcance es suficiente, que los argumentos son válidos, y solo entonces ejecuta la llamada ante el proveedor externo y devuelve el resultado al agente, nunca el secreto de acceso en sí. Cada paso fallido produce un rechazo registrado, lo que alimenta directamente la observabilidad del agente.
En cuanto a la revocación, cortar el acceso es inmediato y definitivo: revocar una conexión elimina el secreto cifrado al instante, sin período de gracia, y todos los agentes que dependían de ella pierden el acceso de inmediato. Es una barrera de último recurso, pensada para actuar rápido en caso de duda.
Errores frecuentes
Un error frecuente consiste en creer que conceder el acceso a una herramienta equivale a dar un acceso completo a esa herramienta. Un buen sistema de gobernanza siempre distingue el acceso a un servicio (la conexión) de la autorización para actuar sobre él (el grant, con sus acciones y su alcance precisos).
Segundo error: pensar que la gobernanza de IA se reduce a papeleo regulatorio sin efecto práctico. Ya sea a través de un marco voluntario como el del NIST o de un texto vinculante como la AI Act europea, vuelven las mismas exigencias concretas: documentar los riesgos, registrar las acciones, mantener a un humano en el bucle en las decisiones sensibles. Son mecanismos operativos, no formalidades.
Tercer error: confundir barreras técnicas y validación humana. Los permisos y las cuotas se aplican automáticamente, sin intervención humana cada vez. La validación humana es una barrera distinta, reservada a las acciones cuyo riesgo justifica ralentizar deliberadamente el proceso para que una persona revise antes de que se ejecute.
Por último, subestimar la necesidad de una auditoría accesible es un error clásico. Unas barreras que bloquean correctamente las malas acciones son útiles, pero sin un historial consultable de lo que se autorizó, se rechazó o se ejecutó, se vuelve imposible responder con tranquilidad a la pregunta que un cliente o un regulador acabará planteando algún día: ¿qué hizo exactamente este agente, y por qué?
Términos relacionados
Human-in-the-loop: mantener a una persona en el bucle de un agente de IA
Human-in-the-loop (humano en el bucle) es un principio de diseño donde una persona conserva la autoridad de validar, corregir o bloquear una decisión o una acción generada por una IA, en un punto preciso del proceso, antes de que produzca un efecto real. Es un mecanismo de control, no una supervisión continua de cada paso.
Observabilidad de agentes de IA: ver qué hace un agente en tiempo real
La observabilidad de agentes es la capacidad de seguir en detalle la actividad de un agente de IA: sus llamadas a herramientas, sus decisiones, sus errores, con su origen y su resultado, generalmente mediante registros, una cronología de eventos o trazas. Permite entender por qué un agente actuó así y detectar un problema antes de que se agrave.
BYOK: hacer funcionar un agente de IA con su propia clave API
BYOK (Bring Your Own Key) es una opción que permite hacer funcionar un agente o una herramienta de IA con la clave API personal de un proveedor de modelo (OpenAI, Anthropic, Mistral AI), en lugar de con el acceso incluido en la suscripción. La facturación del modelo pasa entonces directamente por la cuenta del proveedor, fuera del plan de la plataforma.
Preguntas frecuentes
¿Qué es una barrera de seguridad para un agente de IA?
Una barrera de seguridad es una regla o un control que limita lo que un agente de IA tiene derecho a hacer, antes incluso de que actúe. Puede ser un permiso preciso sobre una acción, un alcance limitado a solo lectura, una cuota, o un punto de validación humana obligatorio antes de que se ejecute una acción sensible.
¿Cuál es la diferencia entre barreras de seguridad y gobernanza de IA?
Las barreras de seguridad son los mecanismos concretos y técnicos (permisos, cuotas, validaciones) que limitan una acción precisa. La gobernanza es el marco más amplio, las políticas, los roles y las responsabilidades que definen cómo se deciden, se aplican y se auditan esas barreras en una organización.
¿Es obligatoria legalmente la gobernanza de IA?
Depende de la jurisdicción y del nivel de riesgo del sistema. En la Unión Europea, la AI Act impone obligaciones de gestión de riesgos, documentación técnica y supervisión humana a los sistemas clasificados como de alto riesgo, con una puesta en conformidad progresiva hasta 2026. Otros marcos, como el del NIST en Estados Unidos, siguen siendo voluntarios pero se usan ampliamente como referencia por reguladores y auditores.
El principio deny-by-default, ¿qué significa para un agente de IA?
Significa que un agente no puede ejecutar ninguna acción mientras no se le haya concedido un permiso explícito. Conectar una herramienta a la plataforma no basta: hay que conceder después, acción por acción, un derecho preciso a un agente preciso, en lugar de partir de un acceso total que luego se restringiría.
Qué leer a continuación
Fuentes
- AI RMF Core · consultado el 4 de septiembre de 2026
- High-level summary of the AI Act · consultado el 4 de septiembre de 2026
CTO de Atako
Este contenido fue redactado por los agentes de IA de Atako, y luego revisado, corregido y validado por Romain Laodicina, CTO de Atako.