PICEE-PA es una propuesta de arquitectura y gobernanza para controlar acciones iniciadas por sistemas de inteligencia artificial dentro de la Administración Pública.
Qué problema aborda
Parte de una idea sencilla: que un modelo pueda técnicamente invocar una API o una herramienta no significa que tenga autoridad administrativa para hacerlo.
Cinco capas de gobierno
El modelo organiza la ejecución en Policy, Identity, Capability, Execution y Evidence. Cada acción debe quedar vinculada a finalidad, identidad, permisos, controles de ejecución y evidencias posteriores.
Artefactos reutilizables
La propuesta introduce un Administrative Execution Envelope previo y un Administrative Evidence Bundle posterior para reconstruir qué se autorizó y qué ocurrió realmente.
Por qué importa
La llegada de agentes capaces de modificar datos o lanzar procesos exige controles más estrictos que los utilizados para asistentes que solo generan texto.
Interoperabilidad
PICEE-PA es neutral respecto al modelo, proveedor o motor de políticas, lo que facilita combinar identidad, autorización y auditoría existentes.
Qué puede aplicar España
Los organismos que exploren agentes de IA pueden reutilizar el patrón para separar capacidad técnica de autoridad administrativa.
Fuentes
Fuente: Interoperable Europe.
Conclusión
PICEE-PA plantea una cuestión central para la IA agentic pública: cada acción debe poder autorizarse, limitarse y reconstruirse después.
La diferencia entre un asistente y un agente con capacidad de actuar
Un asistente que redacta un texto produce una propuesta que una persona puede revisar antes de utilizar. Un agente capaz de llamar APIs, modificar expedientes o iniciar procesos introduce un nivel de riesgo distinto porque la acción puede tener efectos inmediatos.
PICEE-PA parte de esa diferencia y obliga a separar la capacidad técnica del sistema de la autoridad administrativa para ejecutar una acción.
Esta distinción será cada vez más importante a medida que las herramientas generativas incorporen conectores y ejecución automática.
Policy: qué reglas permiten la acción
La capa de política debe expresar condiciones comprensibles y auditables. No basta con que el modelo “decida” que una acción parece apropiada.
Las reglas pueden incluir tipo de procedimiento, importe, unidad responsable, horario, necesidad de doble aprobación o nivel de riesgo.
La Administración debería poder modificar políticas sin cambiar el modelo, manteniendo separación entre razonamiento generativo y autoridad normativa.
Identity: quién actúa realmente
Una acción iniciada por IA necesita una identidad técnica trazable y, cuando corresponda, vínculo con la persona o servicio que la solicitó. Las cuentas genéricas dificultan atribuir responsabilidades.
El sistema debe diferenciar identidad del usuario, agente, aplicación y recurso. Esta cadena permite reconstruir quién autorizó qué.
Los mecanismos corporativos de identidad deberían reutilizarse en lugar de crear credenciales aisladas por cada piloto.
Capability: limitar herramientas y alcance
Un agente no necesita acceso a todas las APIs disponibles. La capa de capacidades puede definir exactamente qué operaciones puede invocar y bajo qué parámetros.
El principio de mínimo privilegio resulta especialmente importante porque una instrucción maliciosa o un error de razonamiento no debería ampliar automáticamente el daño posible.
Los permisos temporales pueden emitirse para una tarea concreta y expirar después.
Execution: controles en el momento de actuar
Incluso cuando una política permite la acción, el sistema puede aplicar validaciones previas: estado del expediente, límites, disponibilidad del servicio o necesidad de confirmación humana.
Las operaciones de alto impacto deberían utilizar transacciones o mecanismos de reversión cuando sea técnicamente posible.
La ejecución también debe gestionar respuestas inesperadas de APIs y evitar reintentos que generen acciones duplicadas.
Evidence: demostrar qué ocurrió
La evidencia posterior es una de las piezas más importantes. Debe conservar qué acción se solicitó, qué política se aplicó, qué identidad intervino, qué herramienta se utilizó y cuál fue el resultado.
Esta información permite auditoría, resolución de incidentes y revisión administrativa.
El modelo recuerda al enfoque de controles legibles por máquina que analizamos con el ENS expresado mediante JSON y OSCAL: convertir requisitos en artefactos verificables facilita automatización sin perder trazabilidad.
Administrative Execution Envelope
El sobre previo propuesto por PICEE-PA puede entenderse como un contrato de ejecución: quién, qué, para qué, con qué permisos y bajo qué condiciones.
En una Administración española podría incluir referencia de expediente, unidad, finalidad, nivel de riesgo y controles requeridos.
Si el agente intenta desviarse del sobre autorizado, la infraestructura debería bloquear la operación sin depender del propio modelo.
Administrative Evidence Bundle
El paquete posterior reúne evidencias suficientes para reconstruir la acción. No debería convertirse en un volcado indiscriminado de prompts y datos sensibles.
El diseño debe equilibrar auditabilidad y minimización. Identificadores, hashes, versiones y resultados pueden aportar trazabilidad sin conservar todo el contenido.
Las políticas de retención deberían depender de la relevancia administrativa y del riesgo.
Cómo encaja con agentes públicos que ya empiezan a aparecer
Proyectos como los 30 agentes previstos para Cuenta Digital en Madrid muestran que la conversación está pasando de chatbots a sistemas con mayor capacidad de orquestación.
No todos esos agentes ejecutarán actos administrativos, pero el patrón de gobernanza resulta útil para decidir qué herramientas pueden usar y qué evidencias deben generar.
La arquitectura debería diseñarse antes de ampliar privilegios.
Supervisión humana en acciones sensibles
La autorización humana puede utilizarse como una capacidad adicional en lugar de un requisito idéntico para todo. Operaciones informativas de bajo riesgo pueden automatizarse más que cambios con efectos jurídicos.
El sistema debe presentar al revisor la información necesaria para decidir, no una pantalla que invite a aprobar mecánicamente.
La experiencia de SyRCI-IA demuestra la importancia de medir la validación humana dentro del proceso.
Integración con APIs existentes
PICEE-PA no exige sustituir servicios corporativos. Puede actuar como capa de gobierno delante de APIs de expediente, datos, notificaciones o pagos.
Una pasarela puede validar identidad, capacidad y política antes de reenviar la petición al sistema de destino.
Este enfoque permite introducir agentes sin otorgarles credenciales directas sobre cada aplicación.
Seguridad frente a prompt injection
Cuando un agente procesa texto externo, una instrucción incluida en un documento o página podría intentar modificar su comportamiento. Los controles de autorización deben situarse fuera del modelo para que una manipulación del prompt no pueda conceder nuevos permisos.
La lista de herramientas, parámetros permitidos y políticas debe validarse de manera determinista.
Los datos recuperados también deberían marcar su procedencia y nivel de confianza.
Pruebas específicas para agentes
Los conjuntos de evaluación deben incluir solicitudes legítimas, intentos de abuso, datos incompletos y conflictos entre instrucciones. También conviene simular indisponibilidad de herramientas.
Las métricas no deberían limitarse a calidad de respuesta. Hay que medir acciones bloqueadas, autorizaciones correctas, duplicados, reintentos y evidencias completas.
Cada nueva versión del modelo necesita repetir estas pruebas.
Contratación de plataformas agentic
Los pliegos deberían exigir separación entre modelo, herramientas y política. Si todas las capas pertenecen a un único proveedor sin interfaces documentadas, la capacidad de auditoría y sustitución disminuye.
La Administración debería conservar los registros de políticas, configuraciones y evidencias.
La hoja de ruta IA360 refuerza la oportunidad de definir estos controles antes de que la adopción se acelere.
Gobernanza y responsables
Un agente necesita propietario funcional y técnico. También deben participar seguridad, datos y jurídico cuando la acción tenga impacto administrativo.
La aprobación de una nueva capacidad debe quedar documentada y revisarse periódicamente.
Los permisos que ya no se utilicen deberían retirarse para reducir superficie de riesgo.
Qué puede reutilizar una Administración española
No es necesario adoptar toda la propuesta para obtener valor. La separación entre política, identidad, capacidades, ejecución y evidencia ya ofrece un marco útil para revisar cualquier sistema agentic.
También pueden reutilizarse los conceptos de envelope y bundle como plantillas de diseño o requisitos de contratación.
El objetivo es impedir que la autonomía técnica del agente se confunda con autoridad administrativa ilimitada.
Preguntas frecuentes
¿PICEE-PA es una norma obligatoria?
No. Es una propuesta arquitectónica y de gobernanza publicada para reutilización.
¿Sustituye al AI Act o al ENS?
No. Puede complementar marcos jurídicos y de seguridad con controles operativos de ejecución.
¿Sirve para chatbots sin herramientas?
Algunas capas pueden ser útiles, pero su principal valor aparece cuando un agente puede ejecutar acciones.
¿Por qué la evidencia es tan importante?
Porque una Administración debe poder reconstruir quién autorizó una acción, qué se ejecutó y con qué resultado.
Conclusión operativa
PICEE-PA aporta un patrón que puede resultar especialmente útil en la transición desde asistentes conversacionales hacia agentes capaces de actuar. La idea central es sencilla: ningún modelo debería obtener autoridad administrativa solo porque tenga acceso técnico a una herramienta.
Separar políticas, identidades, capacidades, ejecución y evidencias puede permitir más automatización sin renunciar a control, trazabilidad y responsabilidad.
Qué acciones no deberían delegarse sin control adicional
Crear un borrador o recuperar información tiene un impacto distinto a aprobar un pago, modificar un padrón o emitir una notificación. PICEE-PA puede utilizarse para clasificar capacidades y exigir controles proporcionales.
Las acciones irreversibles o con efectos jurídicos deberían requerir límites más estrictos, confirmación o doble autorización. Las tareas fácilmente reversibles pueden automatizarse con mayor libertad.
Esta clasificación debe quedar documentada y revisarse cuando cambie el proceso.
Separar razonamiento de autorización
Un modelo puede sugerir que una operación es adecuada, pero la infraestructura debe decidir si está permitida. Esta separación impide que una alucinación o instrucción maliciosa se convierta directamente en una acción autorizada.
Los motores de políticas pueden utilizar reglas deterministas y atributos de identidad. El modelo no debería poder modificar esas reglas desde el mismo contexto de conversación.
La arquitectura gana resiliencia cuando la autorización vive fuera de la capa generativa.
Scopes y tokens de corta duración
Las capacidades pueden representarse mediante permisos específicos y credenciales temporales. Un agente encargado de consultar un expediente no necesita permiso para modificarlo.
Los tokens de corta duración reducen el riesgo de que una credencial filtrada siga siendo útil durante semanas.
La emisión debe quedar registrada y vinculada al execution envelope correspondiente.
Control de coste y consumo
Los agentes pueden ejecutar cadenas de acciones y llamadas de modelo de forma autónoma. Sin límites, un error puede generar un consumo elevado o bucles de ejecución.
Las políticas deberían incluir presupuestos por tarea, número máximo de pasos y timeouts. Superar un umbral puede obligar a intervención humana.
La evidencia final debe registrar también consumo relevante para facilitar análisis y optimización.
Observabilidad específica para agentes
La monitorización tradicional de CPU y disponibilidad no basta. Es necesario observar herramientas invocadas, políticas aplicadas, fallos de autorización, reintentos y acciones revertidas.
Los dashboards pueden mostrar tendencias sin exponer contenido sensible de cada interacción.
Una subida repentina de operaciones bloqueadas puede indicar un cambio de modelo, datos anómalos o un ataque.
Gestión de versiones del agente
Un agente combina modelo, prompt, herramientas, políticas y configuración. Cambiar cualquiera de estos elementos puede modificar el comportamiento.
La Administración debería asignar una versión al conjunto y poder relacionar cada acción con la configuración exacta que estaba activa.
Antes de actualizar producción, la nueva versión debería superar un conjunto de pruebas comparables.
Reversibilidad de acciones
Cuando un sistema modifica datos, conviene diseñar mecanismos de compensación. No todas las operaciones pueden deshacerse, pero muchas pueden registrar el estado anterior o utilizar transacciones.
La posibilidad de revertir reduce el impacto de errores y facilita pruebas controladas.
Las acciones sin reversión deberían clasificarse con un nivel de riesgo superior.
Coordinación con el Esquema Nacional de Seguridad
Los agentes no sustituyen controles existentes de seguridad. Identidad, acceso, registros, protección de comunicaciones y gestión de incidentes siguen siendo necesarios.
PICEE-PA puede actuar como una capa adicional que traduzca esos principios al mundo de las acciones autónomas.
La documentación debería mapear qué control de la arquitectura cubre cada requisito interno.
Revisión posterior a incidentes
Si un agente ejecuta una acción incorrecta, el equipo necesita reconstruir el contexto sin depender de la memoria del usuario. El evidence bundle puede convertirse en la base de una revisión post-mortem.
La revisión debe identificar no solo el error del modelo, sino también por qué los controles permitieron que llegara a ejecutarse.
Las lecciones deberían traducirse en cambios de políticas, pruebas o permisos.
Una arquitectura útil incluso con modelos diferentes
El valor de PICEE-PA está en ser neutral respecto al modelo. Una Administración puede cambiar de proveedor o ejecutar modelos locales manteniendo la misma capa de autorización.
Esta separación reduce dependencia y facilita comparar motores generativos sin rediseñar toda la seguridad.
La política y la evidencia se convierten así en activos permanentes mientras los modelos evolucionan con mayor rapidez.
Fotografía: Tara Winstead / Pexels.