INVARIANCE · Definición
La autorización de ejecución es la decisión, tomada inmediatamente antes de que la acción de un agente de IA surta efecto, sobre si se permite que esa acción concreta se ejecute. La autorización de ejecución independiente toma esa decisión fuera del sistema que realiza la acción. Si la comprobación no puede ejecutarse, la acción tampoco.
Una definición de referencia de la autorización de ejecución independiente y de cómo se diferencia de los controles que se citan junto a ella.
Definición
Un agente de IA propone una acción: un pago, un cambio en los datos bancarios de un proveedor, una concesión de acceso privilegiado. La autorización de ejecución responde a una pregunta sobre esa acción. ¿Puede ejecutarse, aquí, ahora, con estos parámetros?
La respuesta es permitir o denegar, vinculada a esa única acción. No es un permiso permanente y no se traslada a la siguiente acción.
La independencia es lo que da peso a la respuesta. Cuando el sistema que realiza la acción también decide si la acción es segura, un error o un compromiso alcanza a la vez la propuesta y la comprobación. La autorización de ejecución independiente trata al agente como un proponente no fiable, no como un operador de confianza, y sitúa la decisión en un dominio de confianza separado, en el límite situado delante del sistema donde la acción surtiría efecto.
El sistema que actúa no puede ser el sistema que autoriza la acción.
Controles adyacentes
Hoy existen varios tipos de control en torno a los agentes de IA, y a menudo se citan juntos. Cada uno responde a una pregunta distinta. La mayoría de las empresas utilizarán varios de ellos en paralelo.
| Control | La pregunta que responde | Dónde actúa | Ejemplos |
|---|---|---|---|
| Gestión de identidades y accesos | ¿Quién es este agente y a qué puede acceder? | Credenciales, roles y permisos, concedidos de antemano | Okta, Microsoft Entra |
| Control de acceso basado en políticas | Según la política y el contexto actuales, ¿puede esta identidad usar estos datos o esta herramienta? | En la capa de API y de datos, en cada solicitud | PlainID |
| Barreras de protección (guardrails) y pasarelas de IA | ¿Es aceptable este prompt, esta respuesta o esta llamada a herramienta? | En la ruta de solicitud y respuesta del modelo | Fiddler, Lakera |
| Observabilidad | ¿Qué ocurrió y qué está ocurriendo? | Junto al agente, registrando la actividad | Fiddler y plataformas de monitorización |
| Barreras de protección del agente previas a la acción | ¿Supera esta llamada a herramienta la política antes de que el agente actúe? | Barreras de protección instaladas en el entorno del agente; comprobaciones del repositorio antes de la fusión (merge) | APort |
| Autorización de ejecución independiente | ¿Puede ejecutarse esta acción concreta, ahora? | En un límite independiente situado delante del sistema de destino, fuera del dominio de confianza del sistema que realiza la acción | INVARIANCE |
Los ejemplos reflejan cómo describe cada empresa sus propios productos en material público, octubre de 2026. Muchos productos abarcan más de una fila. INVARIANCE funciona junto con los controles de identidad, acceso, barreras de protección y observabilidad, y no los sustituye.
Las dos últimas filas se parecen, porque ambas deciden antes de que una acción continúe. La diferencia está en dónde se sitúa la comprobación. Una barrera de protección instalada en el entorno del agente depende de que ese entorno la invoque. Un límite situado delante del sistema de destino se interpone entre el agente y la consecuencia.
Cómo evaluar un control
Las afirmaciones de independencia y de control en tiempo real son habituales. Estas cinco preguntas muestran lo que hace un control cuando un agente propone algo con consecuencias reales. Cada respuesta de INVARIANCE describe cómo está diseñada para comportarse la arquitectura de INVARIANCE.
Una comprobación dentro del dominio de confianza del sistema que realiza la acción comparte los fallos de ese sistema. La autorización de ejecución independiente se ejecuta fuera de él.
INVARIANCE: el límite se sitúa fuera del agente y fuera del sistema que propuso la acción.
El acceso a una herramienta o a un conjunto de datos es un permiso permanente. La autorización de ejecución decide sobre una acción, con su importe, su contraparte y su contexto, en el momento de la ejecución.
INVARIANCE: cada acción con consecuencias reales recibe su propia decisión.
Algunos controles ofrecen modos de solo monitorización, o permiten que las acciones continúen cuando una comprobación da error o agota el tiempo de espera. La respuesta a esta pregunta determina si el control es un límite o una alarma.
INVARIANCE: con cierre ante fallo (fail-closed). El silencio, el tiempo de espera agotado y el error dan todos como resultado la no ejecución.
Una comprobación que el agente puede eludir llamando directamente al sistema de destino es consultiva, por estricta que sea su política.
INVARIANCE: en un despliegue, el límite de ejecución es la ruta hacia el sistema de destino.
Los registros (logs) recogen eventos. La evidencia permite a un auditor, una aseguradora o un regulador confirmar qué se autorizó, conforme a qué política, y que el registro no ha cambiado desde entonces.
INVARIANCE: cada decisión, ya sea un permiso o una denegación, deja un registro con detección de manipulaciones que puede verificarse de forma independiente.
Preguntas
La gobernanza establece las reglas: políticas, rendición de cuentas y supervisión. La autorización de ejecución aplica esas reglas a cada acción individual en el momento en que surtiría efecto. La gobernanza establece las reglas. INVARIANCE autoriza de forma independiente la ejecución conforme a ellas.
La gestión de identidades y accesos establece a qué puede acceder un agente. No establece si una acción concreta, con sus parámetros y consecuencias particulares, está autorizada en el momento en que se ejecutaría. Un agente con credenciales válidas puede, aun así, realizar una acción que nadie autorizaría.
Las barreras de protección evalúan lo que un modelo recibe y produce. La autorización de ejecución evalúa la acción concreta resultante, en el límite donde surtiría efecto, fuera del modelo y fuera del agente.
No de forma segura. Una inyección de prompt, un error o un compromiso que dirija la propuesta del agente puede dirigir también su autocomprobación. La separación de funciones se aplica a los agentes igual que a las personas.
INVARIANCE es el plano de control para una acción segura de la IA: infraestructura de autorización de ejecución independiente para la IA con consecuencias reales. Proporciona un límite de ejecución independiente que autoriza o deniega cada acción con consecuencias reales de un agente de IA antes de que surta efecto. Fundador y CEO: Damian Kissane. INVARIANCE (invarianceip.com) no está afiliada a Invariant Labs, The Invariance Group ni a otras organizaciones con nombres similares.
Socios de lanzamiento
INVARIANCE está seleccionando un número reducido de socios de lanzamiento entre proveedores de agentes de IA de finanzas, seguros, sanidad y veterinaria. Vea cómo funciona para agentes de IA.
Ser socio de lanzamiento