Donde una persona ejecuta decenas de acciones al día, un agente de IA puede ejecutar miles de recuperaciones, llamadas a herramientas y decisiones, y controles diseñados para la primera escala pueden no alcanzar a la segunda. Por eso el gobierno de agentes de IA que propone la Urbanización del Mundo Digital (DWU) trata a cada agente como un habitante con identidad cívica, es decir, con identidad verificable propia, rol declarado, jurisdicción, permisos de mínimo privilegio, patrocinador responsable, registro de actividad y un mecanismo de revocación que alguien pueda ejecutar.
En Northstar Consumer Group, el caso ficticio que sigo desde el primer post, el agente de compras no tiene ninguna de esas cosas. Prepara órdenes de compra con credenciales heredadas de un desarrollador, así que la auditoría atribuye sus consultas a esa persona y sus permisos son los del desarrollador. El asistente analítico temporal de cobranza está en la misma situación.
Lo que se rompe con una credencial prestada
Si un auditor pregunta quién creó de madrugada un borrador de orden para un proveedor nuevo, el registro señalará a un desarrollador que a esa hora dormía. La credencial heredada rompe la atribución, y también el alcance. El desarrollador tiene, con razón, permisos que la tarea no necesita (entornos de prueba, repositorios, quizá lectura amplia sobre tablas del ERP), y el agente los hereda todos, porque el mínimo privilegio se mide contra una tarea y este agente nunca tuvo una declarada.
Lo peor es la revocación. Deshabilitar la cuenta del desarrollador apaga al agente y deja sin acceso al desarrollador, y si la credencial se copió a un archivo de configuración puede que ni siquiera apague al agente. Cuando el desarrollador deje la empresa, el procedimiento de salida apagará al agente sin que nadie en Cadena de suministro sepa por qué.
Alguien va a proponer un atajo. Northstar tiene una cuenta de servicio compartida, svc-integracion, que usan varias integraciones, y mover el agente ahí parece una mejora porque lo desliga de una persona. La atribución pasa de señalar a la persona equivocada a no señalar a nadie, y el alcance se vuelve la unión de lo que necesitan todas las integraciones que comparten la cuenta.
Por qué los controles pensados para personas no alcanzan
Los controles de acceso de una empresa típica suponen un ritmo humano. La recertificación periódica descansa en que el jefe que la firma sabe qué hace su colaborador. La aprobación por transacción supone que alguien lee lo que aprueba. Y hay un control que nadie diseñó, la persona que nota que un número «se ve raro» y se detiene.
Con un agente, esos supuestos se debilitan. Nadie recertifica con criterio los permisos de algo cuya tarea no está escrita, y una aprobación por transacción, a esa densidad, se convierte en una cola que alguien vacía sin leer. Las acciones de un agente pueden ser dependientes del contexto, probabilísticas, mediadas por herramientas y parcialmente autónomas, así que el mismo agente con los mismos permisos puede decidir distinto cuando cambia lo que recupera. De ahí saco una regla propia. Los permisos de un agente se dimensionan para lo peor que podría hacer con ellos ante un contexto adverso.
Un perfil cívico para cada agente
La arquitectura zero trust (Rose et al., 2020) resuelve una parte, porque verifica explícitamente cada acceso a cada recurso y descarta que un agente sea confiable por estar dentro de la red. Esa verificación responde si esta identidad puede acceder a este recurso ahora. La identidad cívica sitúa ese acceso dentro de un patrocinio, una jurisdicción y un propósito, y con eso permite contestar las dos preguntas de un auditor tras un incidente, en nombre de quién actuó el agente y quién responde por él.
DWU llama perfil cívico al conjunto de atributos con que un agente entra a la empresa, y lo quiere ejecutable por máquina donde sea posible. Sus campos incluyen el distrito asignado (el dominio de capacidades de negocio que responde por él), los edificios permitidos (las aplicaciones y servicios que puede usar), las zonas permitidas del subsuelo, que son los productos de datos y bases de conocimiento descritos en el subsuelo de datos, y las rutas de movilidad aprobadas (las APIs, eventos y colas con contrato de integraciones punto a punto). El resto (identidad, patrocinador, autonomía, límites financieros, aprobaciones humanas, observabilidad y revocación) se entiende por su nombre.
Bajo cada grupo anoté la pieza de infraestructura pública (los servicios compartidos de identidad, políticas, auditoría y APIs que ningún sistema debería reconstruir por su cuenta) que lo haría cumplir, porque un campo que ningún punto de control lee no restringe al agente.
Lo que ya cubren NIST y zero trust
DWU presenta el perfil cívico como complemento de la gestión de riesgo de IA. La tabla resume cómo lo leo frente a los marcos que cita.
| Marco | Qué enfatiza | Qué agrega el perfil cívico |
|---|---|---|
| AI RMF 1.0 (NIST, 2023) | gobierno del riesgo de IA en todo el ciclo de vida: accountability, transparencia, medición y tratamiento | un patrocinador con nombre y un distrito donde vive esa accountability |
| NIST AI 600-1 (Autio et al., 2024) | perfil de riesgos de la IA generativa | la jurisdicción y las zonas de datos donde esos riesgos se materializan |
| Concept paper del NCCoE (Booth et al., 2026), borrador público inicial | identificación, autorización, auditoría y no repudio de agentes | patrocinio, jurisdicción y delegación acotada como atributos de esa identidad |
| Zero trust (Rose et al., 2020) | verificación explícita de cada acceso a recursos | propósito y en nombre de quién se accede |
Calidad del modelo, sesgo, alucinación, prompt injection, fuga de datos y acciones inseguras siguen siendo problemas que el perfil no resuelve. Lo que hace es situarlos. Si la página de un proveedor contiene instrucciones ocultas y el agente de compras las obedece, el perfil acota lo que puede conseguir con ellas (un borrador, en la entidad A, dentro del límite por orden, que una persona revisa) y deja escrito en nombre de quién ocurrió.
La AI Agent Standards Initiative (NIST, 2026) es trabajo emergente, y el propio marco pide revisar sus supuestos de gobierno contra los estándares que vayan apareciendo, así que espero que el esquema que propongo abajo envejezca pronto.
Cómo se vería en Northstar
El perfil del agente de compras
Así podría verse el perfil completo del agente de compras, con nombres de campo míos.
# Perfil cívico ilustrativo del agente de compras de Northstar.
# No es un estándar ni un esquema definido por DWU.
perfil_civico:
id: agente-compras
tipo_habitante: residente
rol_declarado: preparar borradores de órdenes de compra para revisión humana
estado: piloto # propuesto > piloto > productivo > suspendido > retirado
identidad:
emisor: servicio-identidad-corporativo
clase: carga-de-trabajo # identidad propia, separada de cualquier persona
credencial: vida-corta # la renueva el emisor; nunca se copia a configuración
prohibido: [credenciales-de-persona, cuentas-compartidas]
patrocinio:
patrocinador: responsable-de-compras-entidad-a
distrito: cadena-de-suministro
equipo_tecnico: automatizacion-compras
jurisdiccion:
entidades: [entidad-a]
residencia_de_datos: segun-politica-de-entidad-a
acceso:
edificios: [erp.consulta-inventario, portal-proveedores.lectura]
datos:
lee:
- maestro-proveedores
- historico-compras-entidad-a
- cotizaciones-entidad-a
- margen_bruto # producto de datos de Finanzas
- base_conocimiento_compras # de ahí recupera la política de márgenes mínimos
nunca: [datos-personales-de-empleados, margen-por-cliente]
rutas:
api-ordenes-de-compra.v2: [crear-borrador]
evento.orden-aprobada: [suscribir]
herramientas: [buscar-proveedor, pedir-cotizacion, redactar-orden]
autonomia:
nivel: prepara-y-propone
aprobacion_humana:
siempre: emitir-orden
ademas: [proveedor-nuevo, monto-sobre-limite-por-orden]
limites_financieros:
por_orden: definido-por-finanzas
acumulado_mensual: definido-por-finanzas
delegacion:
permitida_a: [agente-cotizaciones]
alcance_maximo: subconjunto-de-este-perfil
observabilidad:
registrar: [recuperaciones, llamadas-a-herramientas, borradores, delegaciones]
cada_evento_incluye: [patrocinador, cadena-de-delegacion, jurisdiccion]
alertar_si: [ruta-no-aprobada, jurisdiccion-ajena, gasto-cerca-del-limite]
revocacion:
pueden: [patrocinador, seguridad-operaciones]
mecanismo: deshabilitar-identidad-en-el-emisor
estado_consultado_por: [gateway-de-apis, motor-de-politicas] # así caen también los tokens vigentes y delegados
prueba: simulacro-periodico
revision:
cadencia: la-fija-el-patrocinador
al_cambiar_patrocinador: suspendido-hasta-reasignarEl bloque identidad lo aplica el servicio de identidad corporativo que en infraestructura antes que densidad traté como servicio compartido. acceso, con sus rutas, se vuelve un conjunto de políticas que el gateway y el motor de políticas evalúan en cada llamada con la jurisdicción (la entidad legal cuyas reglas aplican) como atributo, así que un borrador para la entidad B se rechaza aunque la identidad sea válida. Los límites financieros y la aprobación humana viven mejor en la propia API de órdenes y en su workflow, porque ahí está el monto. Un límite que solo conoce el agente es una sugerencia. Con identidad propia, la salida del desarrollador ya no apaga al agente. Si el que se va es el patrocinador, la última línea del YAML deja al agente suspendido hasta que alguien acepte el relevo.
Otros campos no los hace cumplir ninguna máquina. El rol_declarado lo redacta una persona y lo evalúa otra. Un validador en el despliegue puede comprobar que patrocinador apunta a una persona activa, y de ahí en adelante que esa persona revise de verdad lo que el agente hace depende de su tiempo y de su criterio.
Residentes y visitantes
Un agente interno persistente, con responsabilidades recurrentes, requiere un gobierno de ciclo de vida más fuerte que un asistente analítico temporal. El marco llama residente al primero y visitante al segundo. El agente de compras es un residente en potencia. Sus tareas se repiten, acumula versiones y cambios de alcance, y probablemente su patrocinador rote antes de que el agente se retire.
El asistente de cobranza es un visitante. Los analistas de Finanzas lo usan para revisar cartera vencida durante un periodo acotado, y su tarea no requiere escribir en ningún sistema. Su perfil puede ser mucho más corto si tiene algo que el del residente no necesita, una fecha de salida.
# Perfil ilustrativo de un visitante (no es un estándar).
perfil_civico:
id: asistente-analitico-cobranza
tipo_habitante: visitante
rol_declarado: analizar cartera vencida para el cierre en curso
patrocinio:
patrocinador: jefatura-de-cobranza
distrito: finanzas
jurisdiccion:
entidades: [entidad-a, entidad-b]
acceso:
datos:
lee: [cartera-por-cobrar] # sin escritura en ningún sistema
herramientas: [consultar, resumir]
rutas: {} # ninguna ruta con efectos
autonomia:
nivel: solo-lectura
delegacion: prohibida
vigencia:
expira: al-cerrar-el-analisis # fecha concreta al emitir la identidad
renovar: nueva-solicitud-con-motivo
al_expirar: [revocar-identidad, borrar-contexto-de-trabajo]La diferencia de fondo es el valor por omisión. Un residente existe hasta que alguien lo retira, y un visitante, hasta la fecha que fija su perfil.
El riesgo típico es el visitante que se queda, el asistente al que se le renueva el acceso por inercia hasta que se vuelve residente sin haber pasado por el gobierno de un residente. Eso se parece mucho a un asentamiento digital informal (una solución localmente útil que opera fuera de los controles de ciclo de vida compartidos), y el post sobre shadow IT trata qué hacer con ellos.
Delegar es subcontratar
Cuando un agente delega trabajo en otro, DWU trata esa delegación como una subcontratación que debe preservar autoridad trazable, con dos límites. Un agente no puede transferir permisos que no posee, y tampoco puede ocultar al patrocinador en cuyo nombre actúa. Supongamos, dentro del caso, que el agente de compras delega la comparación de cotizaciones en un sub-agente especializado.
Técnicamente, la credencial del sub-agente se deriva de la del agente. Su alcance es la intersección entre lo que el agente tiene y lo que la tarea necesita, su jurisdicción no se amplía y vence antes. Estas serían, a modo ilustrativo, las afirmaciones (claims) de un token delegado.
{
"sujeto": "agente-cotizaciones",
"actua_por": "agente-compras",
"patrocinador": "responsable-de-compras-entidad-a",
"cadena": ["responsable-de-compras-entidad-a", "agente-compras", "agente-cotizaciones"],
"jurisdiccion": ["entidad-a"],
"alcance": ["cotizaciones:leer"],
"vence": "antes que la credencial de agente-compras"
}Rechazar una delegación inválida exige tres comprobaciones mecánicas. Un alcance pedido que no está contenido en el del agente se rechaza, igual que una cadena que llega sin patrocinador o con uno distinto del que figura en el perfil. Y si el agente que delega fue revocado, todo lo que derivó deja de valer, que es lo que lleva la revocación hasta el último eslabón.
Si el agente de compras pidiera cotizaciones al agente de un proveedor, la cadena cruzaría la frontera del territorio, el ámbito donde Northstar tiene autoridad para fijar reglas. DWU supone esa autoridad, y entre organizaciones harían falta constructos institucionales que el marco no desarrolla.
Probar que se puede apagar
Queda la revocación, y en el agente de compras de Northstar la situación de hoy es incómoda. Lo apaga quien administre la cuenta del desarrollador, y nadie sabe cuánto tarda en dejar de actuar porque nadie sabe cuántos tokens emitidos con esa credencial siguen vigentes. En seguridad de una API sobre SAP expliqué que un token emitido vale hasta que vence y que, en esa arquitectura, la revocación efectiva depende del caché del autorizador, cuyo tiempo de vida es en la práctica el tiempo de revocación. Con delegación, ese tiempo se acumula en cada eslabón que no consulte el estado de quien le delegó.
En el primer post de la serie, la ficha del agente decía que la revocación era «inmediata». Aquí quité la palabra porque nadie la había medido, y por eso prueba: simulacro-periodico me parece el campo más importante del perfil. Un simulacro en un entorno controlado mide el tiempo real, puede encontrar credenciales que nadie recordaba y obliga al patrocinador a ejecutar la revocación en persona al menos una vez.
El caso de Grupo Diveco
Los agentes de IA de Portal Diveco, la plataforma de Grupo Diveco con la que se abre la serie, muestran cómo se puede operacionalizar parte del perfil cívico. El primero, de marzo de 2026, operaba con una identidad de servicio compartida y guardas de solo lectura. Una identidad compartida resuelve el acceso y deja sin respuesta en nombre de quién se consulta.
El segundo, de junio de 2026, superó esa etapa. Valida la identidad del usuario que lo invoca y aplica en el servidor el alcance de su perfil, es decir, los países y los universos de datos de la capa semántica común asignados a esa persona, de modo que el agente no ve nada que el usuario no pueda ver. En términos de DWU, el patrocinador es el humano que invoca y la jurisdicción son esos países y universos. Los robots de RPA, por su lado, llevan un estado activo o inactivo.
El perfil cívico completo que propone el marco (identidad propia del agente, patrocinador declarado, distrito, nivel de autonomía, registro de agentes) todavía no existe como una pieza formal, y por ahora quien responde por cada consulta es el usuario que invoca.
El paso del primer agente al segundo no prueba P4, la hipótesis sobre agentes que planteo en la sección siguiente. Es una comparación interna de una sola organización, sin datos de incidentes de autorización y con las explicaciones rivales abiertas. Como ninguno de los dos agentes tiene identidad cívica, ni siquiera es la comparación que P4 plantea.
P4 y la comparación que importa
La proposición P4 del marco convierte todo esto en una hipótesis, que el preprint deja formulada sin validación empírica todavía. Según P4, las empresas que gobiernan agentes mediante identidades cívicas acotadas por distrito (patrocinador, jurisdicción, entitlements o derechos de acceso concretos, y estado de ciclo de vida auditable) tendrían menos incidentes relacionados con autorización, y atribuirían sus incidentes más rápido, que las que gobiernan agentes de capacidad comparable con credenciales centralizadas de plataforma de restricción equivalente.
Lo que hace útil a P4 es el grupo de comparación. Contra credenciales heredadas como las de Northstar, cualquier control ganaría sin decir nada de la identidad cívica. P4 la mide contra una credencial central igual de restrictiva. Si esa credencial rinde lo mismo, el patrocinador, el distrito y el estado de ciclo de vida no agregan nada al mínimo privilegio, y esa parte del marco sobraría.
Si P4 se sostiene, los registros de agentes, los eventos de auditoría y los de incidentes mostrarían menos tiempo entre detectar una acción indebida y saber quién responde por ella, porque el patrocinador viaja en el evento. La explicación rival es seria. Quien mantiene perfiles cívicos probablemente tiene también más madurez de arquitectura o mejor talento de ingeniería, y la mejora podría venir de ahí.
Control fuerte, autonomía recortada
La tensión que acompaña a P4 es que los controles fuertes sobre agentes reducen el riesgo operativo y, a la vez, limitan la autonomía útil.
En Northstar se notaría primero en la aprobación humana. El perfil de arriba exige que una persona apruebe cada orden antes de emitirla, algo prudente en un piloto y caro cuando el agente prepara muchos borradores, porque el responsable de compras termina aprobando en bloque sin leer y la aprobación deja de controlar nada. Graduarla (siempre para proveedores nuevos o montos sobre el límite, muestreo para el resto) sería cambiar el nivel de autonomía del agente, una decisión de riesgo que alguien de Finanzas tiene que firmar.
La fricción es otro costo. Si agregar una herramienta exige modificar el perfil, validarlo y conseguir otra firma, y el trámite pesa más que el valor, la respuesta previsible es un agente nuevo, «experimental», corriendo otra vez con las credenciales de alguien. Es la reciprocidad entre baja habitabilidad y asentamientos informales.
El patrocinio tiene un costo menos visible. Pocas personas aceptan de buena gana figurar como patrocinadoras de algo que no construyeron y cuyo comportamiento no pueden predecir del todo, y en mi práctica esa firma fue a menudo lo último que se conseguía.
Quién lo apaga y en cuánto tiempo
La revocación es, para mí, la prueba más honesta de que una empresa gobierna a sus agentes. Para cada agente en producción hay dos preguntas con respuesta verificable, quién puede apagarlo y cuánto tarda en dejar de actuar desde que se decide.
El marco no dice cuánto tiempo es aceptable entre la orden de apagar y el último acto del agente, ni quién fija ese número, y cada empresa tendrá que decidirlo agente por agente. Sospecho que depende más del límite financiero y de la jurisdicción del agente que de la tecnología de identidad. Las excepciones de gobierno están entre las causas de la deuda urbana, y un agente que nadie ha probado apagar es una de ellas.
Este artículo es parte de la serie Urbanización digital, basada en el preprint Toward a Theory of Digital-World Urbanization (Rodas López, 2026), un marco conceptual cuyas ideas apliqué y refiné en la plataforma corporativa de Grupo Diveco, aunque sus seis proposiciones todavía no tienen validación empírica. Anterior: Habitabilidad digital: lo que la arquitectura no mide. Siguiente: Deuda urbana y cómo renovar la ciudad sin desalojarla.