La Junta de Andalucía está preparando un conjunto de nuevas arquitecturas y normas corporativas para ordenar el desarrollo de agentes de inteligencia artificial, servidores MCP, aplicaciones móviles y software en Python. Las iniciativas fueron detalladas el 11 de septiembre por el portal de Desarrollo de Servicios Digitales.
El paquete todavía está en fase de definición y validación. Las arquitecturas, normas y guías deberán pasar por grupos de trabajo y posteriormente por el Comité Técnico de Arquitectura antes de su aprobación y publicación como recursos corporativos.
La novedad es relevante porque la Administración empieza a tratar los agentes de IA como una capacidad que necesita reglas de arquitectura, trazabilidad y reutilización, no como experimentos aislados.
Una Arquitectura de Referencia Multiagente
La Agencia Digital de Andalucía está definiendo cómo deben estructurarse las soluciones basadas en múltiples agentes y cómo se integran con arquitecturas corporativas.
Un sistema multiagente puede repartir tareas entre componentes especializados.
Sin normas comunes, cada proyecto puede crear patrones incompatibles y difíciles de auditar.
Norma específica para agentes de IA
Además de la arquitectura, se prepara una norma para agentes.
Una norma corporativa puede definir identidad, permisos, datos, supervisión y registro.
Estos elementos son centrales en modelos como PICEE-PA, que separan razonamiento y autorización.
Norma para servidores MCP
La Junta también trabaja en criterios para servidores MCP, un protocolo utilizado para conectar modelos y agentes con herramientas o fuentes.
El objetivo declarado es construir, publicar y reutilizar estas capacidades de forma controlada y trazable.
La gestión de MCP se vuelve importante porque un conector puede dar acceso a acciones reales.
Catálogo de herramientas autorizadas
Una arquitectura corporativa puede mantener un catálogo de servidores y capacidades aprobadas.
Esto evita que cada equipo despliegue conectores sin conocer seguridad o responsable.
El inventario debe incluir versiones y permisos.
Identidad de agentes
Los agentes deberían actuar con identidades técnicas separadas y permisos mínimos.
No es recomendable reutilizar credenciales personales o de administradores.
La trazabilidad exige saber qué agente ejecutó cada acción.
Supervisión humana
La arquitectura debe diferenciar acciones que pueden automatizarse y aquellas que requieren confirmación.
Una lectura de datos no tiene el mismo riesgo que modificar un expediente.
Los umbrales deben definirse por caso de uso.
Registro de prompts, modelos y herramientas
Andalucía ya trabaja con PAD para catalogar activos de IA, lo que puede complementar estas normas.
Conocer modelo, prompt y herramienta facilita reproducir resultados.
La noticia se conecta con otras iniciativas autonómicas de gobernanza de IA.
Arquitectura de Referencia de Movilidad
El paquete incluye una arquitectura común para aplicaciones móviles.
La Junta pretende definir criterios que reduzcan diferencias entre proyectos.
Esto puede facilitar mantenimiento y seguridad.
Guías para Android, iOS y Flutter
La arquitectura se complementará con norma de desarrollo móvil y guía práctica para Android, iOS y Flutter.
El objetivo es que los equipos compartan decisiones sobre navegación, seguridad y ciclo de vida.
Las guías deben actualizarse con versiones de plataformas.
Una norma corporativa para Python
La Junta está dando los últimos retoques a una norma de desarrollo Python.
Será aplicable a nuevos desarrollos y al mantenimiento de productos.
La norma relacionará Python con arquitectura, seguridad, observabilidad y requisitos transversales.
Dependencias y paquetes
Python dispone de un ecosistema enorme de librerías. La norma puede ayudar a controlar fuentes, versiones y vulnerabilidades.
Fijar dependencias y utilizar repositorios aprobados reduce riesgo de cadena de suministro.
El Threat Landscape 2026 insiste en la importancia de las dependencias.
Observabilidad desde el diseño
Los nuevos componentes deberían producir logs, métricas y trazas de forma estándar.
Esto facilita soporte en sistemas distribuidos.
Los datos de observabilidad deben protegerse.
Reutilización entre proyectos
Una norma para MCP y agentes tiene sentido si las capacidades pueden reutilizarse.
Un conector bien gobernado puede servir a varios casos sin duplicar desarrollo.
La reutilización debe acompañarse de acuerdos de servicio.
Control de cambios
Los agentes pueden cambiar comportamiento cuando cambia el modelo o el prompt.
La arquitectura debería versionar configuraciones y registrar modificaciones.
Esto permite volver atrás si una actualización degrada resultados.
Entornos de prueba separados
Los agentes no deberían probarse directamente sobre sistemas de producción.
Los entornos controlados permiten simular acciones y validar permisos.
Los datos de prueba necesitan protección equivalente cuando son reales.
Evaluaciones de riesgo
La norma puede clasificar casos por impacto y definir controles proporcionales.
Un agente de documentación tiene un riesgo distinto a uno con capacidad de ejecutar trámites.
El enfoque se alinea con la gobernanza de IA basada en riesgo.
Contratación tecnológica
Las normas corporativas pueden incorporarse a pliegos para que proveedores entreguen soluciones compatibles.
Esto reduce dependencia de implementaciones propietarias.
La CNMC ha subrayado el valor de portabilidad e interoperabilidad en contratación tecnológica.
Comunidad de desarrolladores
La Junta invita a los equipos a participar en su comunidad de desarrolladores.
La consulta interna puede detectar casos que la norma inicial no contempla.
Una arquitectura útil evoluciona con experiencia real.
Aprobación pendiente
Es importante precisar que las normas todavía no son recursos corporativos aprobados.
Pasarán por grupos de trabajo y CTA.
Los equipos deben consultar la versión oficial cuando se publique.
Fuente oficial
El avance fue publicado por la Junta el 11 de septiembre de 2026.
La relevancia del proyecto está en anticiparse al crecimiento de los agentes. Definir arquitectura antes de que existan decenas de implementaciones incompatibles puede evitar una nueva generación de deuda tecnológica pública.
Un registro corporativo de agentes
Cuando una Administración empieza a desplegar agentes en distintas áreas, necesita conocer cuáles existen, quién los mantiene y a qué sistemas acceden. Un registro corporativo puede incluir finalidad, propietario, modelo utilizado, herramientas conectadas y nivel de riesgo.
Este inventario reduce el llamado shadow AI y facilita revisar configuraciones cuando cambia un proveedor o una política interna.
PAD puede convertirse en el punto de apoyo para mantener esta información de forma estructurada.
Catálogo de servidores MCP autorizados
Los servidores MCP actúan como puente entre modelos y herramientas. Precisamente por eso deben someterse a controles equivalentes a los de cualquier integración crítica.
Un catálogo aprobado puede indicar qué servidor está disponible, qué acciones expone, qué datos consume y quién responde por su mantenimiento.
La reutilización será más segura si los equipos consumen capacidades ya revisadas en lugar de desplegar conectores nuevos sin coordinación.
Permisos por herramienta y por acción
Un agente no debería recibir acceso global a una aplicación por comodidad. Lo adecuado es limitar cada herramienta a las operaciones estrictamente necesarias.
Leer información, crear un borrador o ejecutar una modificación definitiva son acciones con riesgos distintos.
La arquitectura puede incorporar niveles de autorización y requerir confirmación humana para determinados cambios.
Protección frente a prompt injection
Los agentes que consultan documentos o páginas externas pueden recibir instrucciones maliciosas incrustadas en el contenido. Este riesgo, conocido como prompt injection, debe tratarse como una superficie de ataque.
Las herramientas conectadas no deberían ejecutar automáticamente cualquier instrucción generada por el modelo.
Separar contexto no confiable, validar parámetros y aplicar listas de acciones permitidas reduce exposición.
Memoria y retención de contexto
Algunos agentes conservan historial o memoria para mejorar continuidad. En el sector público, esta función debe diseñarse con reglas claras de retención y protección de datos.
No toda conversación necesita almacenarse y no todos los usuarios deberían compartir memoria.
La arquitectura debería distinguir contexto temporal de información persistente y definir cómo se elimina o audita.
Evaluación de modelos antes de incorporarlos
La norma puede exigir pruebas mínimas de precisión, seguridad y comportamiento antes de habilitar un modelo en producción.
Los casos de uso necesitan conjuntos de prueba representativos y escenarios deliberadamente adversos.
Un modelo adecuado para resumen puede no serlo para extracción de datos o generación de decisiones.
Portabilidad entre proveedores de modelos
El uso de interfaces comunes y prompts versionados puede facilitar sustituir un modelo por otro. Esta capacidad reduce dependencia y permite comparar coste, latencia y calidad.
La portabilidad nunca será perfecta porque los modelos responden de forma diferente, pero una arquitectura desacoplada disminuye el esfuerzo.
La Administración debería evitar introducir lógica crítica dentro de una función exclusiva de un proveedor cuando exista alternativa razonable.
Observabilidad específica para agentes
Los sistemas multiagente necesitan más que logs técnicos tradicionales. Conviene registrar qué agente tomó cada paso, qué herramienta utilizó, cuánto tardó y qué resultado obtuvo.
Estas trazas permiten investigar errores y optimizar flujos.
La información debe almacenarse de forma proporcional para no convertir la observabilidad en un nuevo repositorio de datos sensibles.
Coste por ejecución
Los modelos generativos introducen costes variables por uso. Un agente que encadena varias llamadas puede multiplicar consumo sin que el usuario lo perciba.
La arquitectura puede establecer presupuestos, límites y alertas por servicio.
Medir coste por tarea permite comparar automatización con alternativas tradicionales y evitar sorpresas presupuestarias.
Pruebas de recuperación y degradación
Un servicio público no puede depender de que todos los agentes y modelos estén disponibles en todo momento. Los sistemas deberían definir qué ocurre si falla una herramienta, el proveedor de IA o la red.
En algunos casos puede continuarse con un proceso manual; en otros será necesario detener la acción.
La degradación controlada debe formar parte de las pruebas antes de producción.
Desarrollo Python con seguridad de dependencias
La nueva norma de Python puede establecer entornos virtuales, fijación de versiones, revisión de paquetes y análisis de vulnerabilidades.
Estas prácticas son especialmente importantes porque muchas librerías de IA evolucionan con rapidez.
La Administración debería mantener repositorios aprobados y procedimientos para responder cuando una dependencia queda comprometida.
Movilidad y agentes en una misma arquitectura corporativa
La coincidencia temporal de normas de movilidad, Python y agentes muestra una estrategia más amplia: reducir excepciones y ofrecer patrones comunes a los equipos.
Una app móvil puede consumir un servicio con IA, pero cada capa necesita responsabilidades claras.
Separar experiencia de usuario, lógica de negocio y capacidades de IA facilita mantenimiento y seguridad.
Gobernanza de prompts y skills reutilizables
Los prompts y skills que se reutilizan entre proyectos pueden convertirse en activos corporativos. Para ello necesitan propietario, versión, pruebas y documentación de finalidad.
Una modificación aparentemente pequeña puede cambiar el comportamiento de varios agentes. El control de cambios debe permitir saber qué versión estaba activa en cada momento.
PAD puede aportar un catálogo común para evitar que cada equipo mantenga copias desconectadas.
Pruebas rojas antes de aprobar un agente
Los proyectos deberían incluir escenarios adversos antes de producción: instrucciones manipuladas, datos incompletos, herramientas no disponibles o intentos de acceder a funciones no autorizadas.
Estas pruebas ayudan a comprobar que las barreras de permisos funcionan incluso cuando el modelo responde de forma inesperada.
La seguridad de un agente debe evaluarse por el conjunto de modelo, herramientas y arquitectura, no por el modelo aislado.
Un modelo operativo para mantenimiento
Después del despliegue alguien debe revisar costes, errores, cambios de modelo y nuevas vulnerabilidades. La norma puede exigir un responsable operativo y una cadencia de revisión.
Sin esa figura, los agentes corren el riesgo de quedar en producción con configuraciones obsoletas.
La gobernanza madura empieza cuando la Administración planifica el mantenimiento antes de aprobar el caso de uso.
Separar agentes experimentales de agentes de producción
La arquitectura puede establecer estados claros para cada agente: laboratorio, piloto, producción y retirado. Cada fase debería tener requisitos distintos de datos, permisos, monitorización y soporte.
Un prototipo no necesita la misma disponibilidad que un servicio ciudadano, pero tampoco debería recibir acceso real a sistemas críticos por comodidad. El paso a producción debe ser una decisión explícita respaldada por pruebas.
Esta separación permite experimentar sin convertir cada prueba en una nueva dependencia permanente.
Plan de retirada y revocación
Cuando un agente deja de utilizarse, deben revocarse credenciales, desactivar servidores MCP exclusivos y decidir qué logs o memoria se conservan. La baja forma parte del ciclo de vida y debería estar documentada desde el alta.
Un inventario de activos ayuda a detectar agentes abandonados que siguen manteniendo permisos.
La gobernanza será más sólida si cada caso tiene no solo responsable de lanzamiento, sino también condiciones claras para su retirada.
Revisión periódica de permisos y herramientas
Los permisos de un agente no deberían mantenerse indefinidamente por haber sido aprobados una vez. Una revisión periódica puede confirmar que sigue necesitando cada herramienta y retirar accesos que han dejado de utilizarse.
Este control reduce privilegios acumulados y mantiene la arquitectura alineada con la finalidad real del servicio.
Fotografía: Stanislav Kondratiev / Pexels.