Trate un plano de control de IA como un activo de nivel cero cuando pueda cambiar identidades de agentes, permisos de herramientas, políticas, flujos de trabajo, controles de aprobación, comportamiento de auditoría o rutas de recuperación en toda la empresa. Si alguien lo compromete, puede alterar lo que muchos agentes tienen permitido hacer, no solo lo que dice un modelo.
Aquí utilizo «nivel cero» como analogía de riesgo para la dirección, no como una clasificación formal y específica de IA. El modelo de acceso empresarial de Microsoft asigna el nivel 0 al plano de control de identidad porque puede controlar indirectamente los demás planos. Yo extendería esa lógica al plano de control de IA únicamente cuando su radio de impacto sea comparable. Una interfaz de chatbot sin herramientas ni administración privilegiada no alcanza automáticamente esa categoría.
Esta visión del plano de control conecta el problema de identidad que plantean los agentes de IA, los derechos de decisión que exige la IA agéntica y el reto de descubrir agentes en la sombra no autorizados. El denominador común es la autoridad: ¿quién o qué puede concederla, modificarla, observarla y revocarla?
Defina el activo antes de protegerlo
El plano de control de IA no es un único producto. Es el conjunto de componentes que decide cómo se crea un agente, qué política se le aplica, qué identidad utiliza, a qué herramientas y datos puede acceder, cuándo debe aprobar una acción una persona, qué se registra y cómo se desactiva o restaura el flujo de trabajo.
Según la arquitectura, puede incluir:
- el registro de agentes, el orquestador y las definiciones de los flujos de trabajo;
- la emisión de identidades, la delegación, los secretos y el intercambio de tokens;
- el enrutamiento de modelos y herramientas, las listas de permitidos y los puntos de aplicación de políticas;
- las fuentes de recuperación de información, la configuración de memoria y los límites de datos;
- los controles de aprobación para acciones de impacto;
- los procesos de evaluación, supervisión y auditoría; y
- los controles de despliegue, versionado, reversión, revocación y recuperación.
No llame nivel cero a todo este conjunto por comodidad. Identifique qué componentes pueden cambiar la autoridad en toda la empresa o eludir un control. Proteja esas rutas con el máximo nivel de garantía. Mantenga la administración específica de cada carga de trabajo en un plano inferior cuando no pueda influir en el sistema de control compartido.
Ese límite importa. Si todos los componentes de IA se consideran críticos, la organización terminará gastando demasiado en proteger activos de escaso impacto o rebajando discretamente el significado de la clasificación.
Por qué funciona la analogía
Las cargas de trabajo tradicionales suelen ejecutar una lógica definida de antemano por los ingenieros. Un agente puede elegir herramientas y acciones durante la ejecución. El modelo no es el punto final donde se aplica el control, pero el sistema que lo rodea puede convertir su salida en llamadas a API, cambios de código, operaciones financieras, cambios de identidad o acceso a datos sensibles.
La arquitectura Zero Trust de NIST describe el motor y el administrador de políticas como componentes empresariales esenciales porque la comunicación con los recursos depende de sus decisiones. Advierte que los cambios de configuración en esos componentes deben registrarse y auditarse, y que una interrupción puede afectar a las operaciones de la empresa. Una plataforma de IA que centraliza decisiones sobre permisos, políticas y enrutamiento de herramientas merece la misma atención arquitectónica.
El conjunto de amenazas va mucho más allá de la inyección de prompts. El Top 10 de OWASP para aplicaciones agénticas de 2026 incluye el secuestro de objetivos del agente, el uso indebido de herramientas, el abuso de identidades y privilegios, la ejecución inesperada de código, la comunicación insegura entre agentes y los agentes maliciosos. No todos esos riesgos nacen en el plano de control, pero un plano débil puede amplificarlos a través de muchos flujos de trabajo.
Mantenga la autoridad fuera del modelo
La primera regla de diseño es sencilla: el modelo puede proponer una acción, pero una política determinista debe autorizar la operación concreta. No pregunte al modelo si su propia solicitud es segura para después tratar su respuesta como un control de acceso.
Evalúe la identidad efectiva, el contexto delegado del usuario o servicio, el recurso de destino, la acción, la clasificación de los datos, el estado del flujo de trabajo y las consecuencias. Leer un documento público no equivale a cambiar el destino de un pago, aunque ambas solicitudes lleguen a través del mismo agente.
Utilice identidades de carga de trabajo diferenciadas en lugar de una cuenta de servicio compartida o las credenciales de larga duración de la persona patrocinadora. Limite el acceso a la tarea y al recurso, y ajuste la vigencia de la credencial a la acción. Las seis pruebas de diseño de identidad para agentes de IA ofrecen un punto de partida práctico para el patrocinio, la delegación acotada, la procedencia y el control del ciclo de vida.
Este campo todavía está madurando. En febrero de 2026, el National Cybersecurity Center of Excellence de NIST publicó un documento conceptual centrado en aplicar a los agentes de software e IA prácticas de identificación, autorización, auditoría y no repudio. Es una señal útil: conviene aplicar desde ahora principios de identidad consolidados, sin fingir que todas las normas específicas para agentes ya están resueltas.
Proteja la ruta administrativa
Un plano de control no debería administrarse desde la misma ruta cotidiana que se utiliza para el correo, la navegación web y las tareas generales de productividad. Separe la administración privilegiada, exija autenticación robusta, utilice elevación temporal de privilegios y supervise tanto al administrador como el estado de su dispositivo.
Los cambios en el plano de control necesitan un historial de versiones, revisión por pares proporcional a sus consecuencias y un vínculo auditable entre la solicitud y el despliegue. Proteja los repositorios de políticas, los registros de agentes, los catálogos de herramientas, los secretos y la configuración del registro frente a cambios unilaterales o invisibles. Un administrador de plataforma que pueda modificar permisos y borrar las pruebas forma parte de la ruta de máximo riesgo, sea cual sea su cargo.
Busque también formas de control indirecto. Un sistema de compilación, un servicio de copias de seguridad, una credencial de despliegue, un agente de supervisión o un marketplace de plugins pueden heredar la sensibilidad del plano de control si permiten sustituir políticas, alterar paquetes de agentes, restaurar una configuración insegura o ejecutar con privilegios equivalentes.
Diseñe la revocación antes que la autonomía
La revocación debe funcionar en el nivel donde se ejerce la autoridad. Cerrar una ventana de chat no basta si pueden continuar los flujos programados, las credenciales en caché, las llamadas a herramientas en cola o los agentes secundarios.
Para cada flujo de trabajo con consecuencias, compruebe si la organización puede:
- desactivar un agente sin detenerlos todos;
- revocar credenciales activas y accesos delegados;
- bloquear de forma centralizada una herramienta o una clase de acción;
- detener el trabajo en cola y en curso cuando el destino lo permita;
- conservar pruebas para la investigación;
- pasar a un modo manual seguro o de solo lectura; y
- restaurar una versión de política y flujo de trabajo cuyo buen estado esté comprobado.
No todas las acciones externas se pueden deshacer. Un pago enviado, un registro eliminado o un secreto divulgado pueden ser irreversibles. Por eso los controles de aprobación deben responder a las consecuencias, no a la novedad. Las decisiones de alto impacto sobre finanzas, identidades, producción, datos de clientes o ámbitos regulados pueden necesitar la intervención de una persona o un paso de verificación controlado por separado, aunque las acciones de bajo impacto sigan siendo autónomas.
Construya una traza única de extremo a extremo
Las pruebas de la actividad de un agente suelen quedar repartidas entre la interfaz de usuario, el gateway del modelo, el orquestador, el proveedor de identidad, el motor de políticas, la herramienta y la aplicación de destino. Asigne un identificador de correlación al flujo de trabajo y conserve contexto suficiente para reconstruir la instrucción, la identidad del agente, la autoridad delegada, la decisión de autorización, la solicitud a la herramienta, el resultado y el cambio de estado resultante.
El objetivo no es capturar el razonamiento privado del modelo ni volcar prompts sensibles en todos los registros. Es poder responder preguntas operativas: ¿qué inició la acción? ¿Qué principal la ejecutó? ¿Qué política la permitió? ¿Qué cambió? ¿Se puede revocar el acceso? ¿Quién es responsable de la recuperación?
El registro también debe sobrevivir al incidente que pretende explicar. Si el mismo plano de control puede reescribir en silencio tanto la política como el historial de auditoría, la ruta de pruebas no tiene independencia suficiente para ese nivel de riesgo.
Pida pruebas de control, no una etiqueta de producto
Una revisión ejecutiva puede apoyarse en cinco preguntas:
| Pregunta | Pruebas que debe solicitar |
|---|---|
| ¿Qué puede cambiar este plano de control? | Un mapa de identidades, políticas, herramientas, datos, flujos de trabajo y sistemas posteriores |
| ¿Quién puede administrarlo? | Roles nominativos, rutas de acceso privilegiado, reglas de elevación y la revisión de acceso más reciente |
| ¿Dónde se aplica la autorización? | Una ruta de llamada a herramientas que muestre la política fuera del modelo y el comportamiento de denegación |
| ¿Con qué rapidez se puede revocar la autoridad? | Resultados de un ejercicio de desconexión de agente, token, herramienta y flujo de trabajo |
| ¿Podemos recuperarnos e investigar? | Una ruta de restauración probada y pruebas de auditoría correlacionadas y protegidas |
Empiece por el flujo de trabajo que tenga mayor autoridad sobre dinero, identidades, producción, datos de clientes o decisiones reguladas. Sígalo desde la instrucción, pasando por la política y la ejecución de la herramienta, hasta la recuperación. Las carencias mostrarán si la próxima inversión debe destinarse a identidad, aislamiento, aplicación de políticas, observabilidad o resiliencia.
El plano de control se convierte en nivel cero por aquello que puede controlar. Protéjalo de acuerdo con esa autoridad y mantenga la clasificación lo bastante acotada para que conserve su significado.
