Interoperable Europe celebrará el 22 de septiembre un webinar centrado en cómo perciben los ciudadanos el uso de inteligencia artificial por parte de los gobiernos.
La sesión se apoya en una encuesta realizada en cinco países de la UE con más de 4.000 participantes.
Qué está confirmado y por qué importa
El encuentro analizará si la IA puede reforzar o deteriorar la confianza pública según cómo se diseñe y utilice.
La novedad es relevante para las Administraciones porque afecta a confianza, gobernanza y adopción de IA en el sector público. El interés no está únicamente en la herramienta o anuncio, sino en los principios de arquitectura, gobernanza, interoperabilidad, seguridad y operación que pueden reutilizarse en otros organismos.
Conviene separar hechos confirmados de expectativas. La fuente institucional permite conocer el alcance anunciado, pero la adopción real dependerá de decisiones posteriores, recursos, contratación y capacidad interna.
Qué puede aportar al sector público
Para las Administraciones, la percepción ciudadana es una variable operativa: una herramienta puede ser técnicamente correcta y aun así fracasar si se percibe como injusta, opaca o innecesaria.
La digitalización pública genera valor cuando reduce fricción, mejora calidad o permite prestar servicios con mayor continuidad. Para ello, cada iniciativa debería asociarse a procesos concretos, usuarios identificados y métricas definidas antes de la implantación.
Una buena práctica consiste en comenzar con casos limitados, medir resultados y ampliar únicamente lo que demuestra utilidad. Esta aproximación reduce el riesgo de convertir una iniciativa estratégica en una plataforma extensa con poca adopción.
Arquitectura y modularidad
Los sistemas de IA deberían integrarse en procesos donde quede claro qué parte automatiza la tecnología y qué decisiones siguen siendo humanas.
Una arquitectura sostenible separa datos, integración, lógica de negocio, analítica y presentación. Esta división facilita sustituir componentes, evita bloqueos innecesarios y permite que distintos proveedores participen en capas diferentes.
La Administración debería conservar bajo su control modelos de datos, identificadores, credenciales principales y reglas de negocio. Las herramientas pueden cambiar; el conocimiento estructural debe permanecer en la organización.
Los entornos de desarrollo, pruebas y producción deberían estar separados y contar con control de versiones y capacidad de reversión.
Datos y trazabilidad
La evaluación de confianza requiere datos de uso y percepción, pero debe evitar recopilar más información personal de la necesaria.
Cada fuente necesita propietario, frecuencia de actualización, calidad esperada, finalidad y reglas de acceso. Saber qué dato es autoritativo evita discrepancias entre aplicaciones y reduce el trabajo de reconciliación.
El linaje —origen, transformaciones, versión y fecha— ayuda a explicar resultados, investigar incidencias y mantener confianza. Esta trazabilidad es especialmente importante cuando los datos alimentan modelos, automatizaciones o decisiones transversales.
La calidad debe revisarse de forma continua. Completitud, duplicados, coherencia y actualidad son indicadores que permiten detectar degradaciones antes de que afecten a usuarios.
Interoperabilidad técnica y semántica
Las guías y patrones reutilizables pueden ayudar a comparar prácticas entre organismos y países.
Las APIs documentadas, los formatos abiertos y los identificadores estables facilitan integrar nuevos servicios sin depender de desarrollos exclusivos. La interoperabilidad semántica es igual de importante: dos sistemas pueden intercambiar un campo y entenderlo de manera diferente.
Los contratos de interfaz deberían incluir versiones, errores esperados y periodos de transición. Cuando una API cambia, los consumidores necesitan tiempo para probar la nueva versión antes de que desaparezca la anterior.
Las pruebas deben cubrir datos incompletos, servicios no disponibles, cambios de versión y respuestas inesperadas. Una integración que solo funciona en condiciones ideales no es suficiente para producción.
Seguridad y privacidad
La confianza también depende de seguridad, control de acceso y protección frente a usos no previstos.
La seguridad debe incluir identidad, mínimo privilegio, segmentación, registros, actualización, copias y respuesta ante incidentes. Los proveedores externos también deben formar parte del modelo de responsabilidades.
Las cuentas técnicas, certificados y secretos de API necesitan propietario, fecha de renovación y mecanismo de revocación. Los permisos creados para un piloto no deberían mantenerse indefinidamente cuando cambia el alcance.
Cuando existen datos personales o empresariales sensibles, la minimización debería aplicarse desde el diseño: utilizar solo lo necesario, limitar accesos y evitar copias sin finalidad.
Contratación pública y reversibilidad
Los contratos deberían exigir explicabilidad operativa, métricas y soporte para revisión humana.
Los pliegos deberían exigir portabilidad, documentación, interfaces, niveles de servicio, inventario de componentes y condiciones de salida. La reversibilidad no debe ser una cláusula abstracta: conviene probar exportaciones y restauraciones durante el contrato.
La dependencia tecnológica también puede ser dependencia de conocimiento. Si solo un proveedor entiende la configuración o las integraciones, la Administración pierde capacidad de decisión aunque formalmente posea los datos.
La modularidad permite renovar componentes con ciclos tecnológicos distintos sin volver a licitar o reconstruir todo el servicio.
Pruebas, pilotos y aceptación
Los pilotos deberían incluir evaluación con usuarios y no limitarse a métricas técnicas.
Los pilotos deberían utilizar usuarios y datos representativos. También conviene probar casos límite, caídas, errores y volúmenes altos para conocer el comportamiento fuera del escenario ideal.
Automatizar parte de la batería de pruebas reduce el coste de cada actualización y permite detectar regresiones. La evidencia generada puede utilizarse para aceptar entregas con criterios objetivos.
Antes de escalar, la entidad debería responder tres preguntas: qué problema se resolvió, cuánto mejoró y qué coste recurrente introduce la solución.
Operación y soporte
Las incidencias relacionadas con resultados de IA necesitan canales de revisión y escalado.
Todo servicio necesita un responsable funcional, un responsable técnico y un canal de incidencias. Los problemas deberían clasificarse entre datos, integración, infraestructura, seguridad y uso para dirigirlos al equipo correcto.
Los cuadros operativos deben mostrar disponibilidad, latencia, errores, calidad y consumo, con responsables y umbrales claros. Acumular métricas sin un proceso de respuesta genera ruido y no mejora la operación.
Las copias y procedimientos de recuperación deben ensayarse. Una copia que nunca se ha restaurado es una hipótesis, no una garantía.
Capacitación y transferencia de conocimiento
Los empleados deben saber explicar el papel del sistema y actuar ante resultados dudosos.
Los usuarios funcionales necesitan comprender límites y excepciones; los equipos TIC, arquitectura y resolución de incidencias; contratación y dirección, costes, dependencia y criterios de aceptación.
La documentación debe mantenerse junto con las versiones. Diagramas, configuraciones, procedimientos y ejemplos de integración son activos operativos que deberían permanecer disponibles aunque cambie el equipo o el proveedor.
La transferencia de conocimiento debería formar parte de los entregables contractuales.
Coste total y sostenibilidad
La carga de supervisión y revisión debe incluirse en el coste total.
El coste total incluye infraestructura, almacenamiento, conectividad, soporte, licencias, personal, monitorización, auditorías y futuras migraciones. Estas partidas deben evaluarse junto al coste inicial.
También conviene modelar crecimiento. Más usuarios, documentos, integraciones, datasets o consultas pueden aumentar el consumo de forma significativa.
La sostenibilidad incluye capacidad para retirar funciones con poco uso. Mantener módulos por inercia aumenta complejidad, coste y superficie de riesgo.
Cómo medir resultados
Confianza, satisfacción, reclamaciones, precisión y carga de revisión son indicadores útiles.
Las métricas de actividad —usuarios, transacciones, datasets o integraciones— sirven para seguir adopción, pero no demuestran por sí solas impacto. Deben combinarse con tiempo ahorrado, reducción de errores, disponibilidad, coste, satisfacción o calidad.
También conviene medir cuánto tarda en incorporarse un nuevo usuario, organismo o caso de uso. Si cada ampliación requiere mucho trabajo específico, la reutilización puede ser menor de la esperada.
La metodología debería definirse antes de empezar y mantenerse estable para poder comparar periodos.
Gobernanza del cambio
Los cambios de modelo o política deberían comunicarse y volver a evaluarse.
Las actualizaciones, nuevas integraciones o cambios de política necesitan responsables, pruebas y posibilidad de reversión. Una hoja de ruta compartida ayuda a coordinar equipos internos y proveedores.
Documentar por qué se tomó una decisión técnica reduce dependencia de personas concretas y facilita auditorías posteriores.
La gobernanza debería revisar periódicamente permisos, componentes y servicios sin uso para evitar acumulación de deuda técnica.
Qué puede reutilizar una Administración española
Las Administraciones españolas pueden reutilizar metodologías de evaluación de confianza antes de escalar IA.
La reutilización no siempre consiste en copiar una solución completa. Puede aprovecharse una especificación, una metodología, un modelo de datos, una cláusula contractual, una batería de pruebas o un patrón de gobernanza.
Antes de adoptar, conviene comparar el contexto propio con el original: volumen, usuarios, legislación, infraestructura, capacidad operativa y criticidad del servicio.
Los componentes reutilizables deberían acompañarse de documentación y licencias claras para reducir el coste de adopción.
Riesgos y límites
Un sistema eficiente puede perder legitimidad si la ciudadanía no entiende su uso o considera que invade ámbitos inadecuados.
Otro riesgo es convertir una solución común en un nuevo punto de dependencia. La arquitectura necesita redundancia, documentación y mecanismos de salida.
La estandarización tampoco debería bloquear necesidades legítimas. Los perfiles comunes pueden admitir extensiones documentadas siempre que se mantenga compatibilidad en el núcleo.
La automatización puede trasladar carga a la revisión si los resultados son poco fiables. El ciclo completo debe medirse.
Qué habrá que observar
Habrá que observar los resultados detallados del estudio y las recomendaciones posteriores al webinar.
La evolución se comprobará con adopción real, incidencias, costes y capacidad de reutilización. Los anuncios y pilotos son un punto de partida, no una prueba automática de impacto.
También conviene observar cómo se relaciona esta iniciativa con otras políticas europeas de interoperabilidad, identidad, datos, IA, ciberseguridad y soberanía digital.
Preguntas frecuentes
¿Quién impulsa esta iniciativa?
Public Sector Tech Watch e Interoperable Europe.
¿Es obligatoria para todas las Administraciones?
No. Es una iniciativa de análisis y aprendizaje.
¿Qué aporta principalmente?
Aporta evidencia sobre percepción ciudadana y confianza ante el uso de IA en gobierno.
¿Qué debería comprobarse antes de adoptarla?
Compatibilidad, seguridad, datos, licencias, documentación, costes de mantenimiento y capacidad de salida.
Fuentes
La información principal procede de Interoperable Europe.
Lecturas relacionadas
Puede ampliarse contexto con nuestros análisis sobre código abierto, gobierno del dato, interoperabilidad semántica y IA pública europea.
La confianza debe medirse con situaciones concretas
Preguntar si una persona “confía en la IA” ofrece poca información si no se define el caso de uso. La percepción puede cambiar mucho entre un sistema que resume documentos, uno que recomienda una ayuda o uno que interviene en una decisión administrativa.
Los estudios con ciudadanos deberían describir claramente finalidad, datos, supervisión y consecuencias para obtener respuestas útiles para el diseño.
Transparencia comprensible
La confianza no aumenta necesariamente con más información técnica. Las Administraciones necesitan explicar qué hace el sistema, qué no hace, qué datos utiliza y cómo puede una persona cuestionar un resultado.
Una ficha breve y clara puede ser más útil para el usuario que una documentación extensa orientada a especialistas.
Supervisión y capacidad de recurso
La percepción pública también depende de saber que existe una vía humana cuando el sistema falla. Los servicios deberían indicar cómo escalar una incidencia y quién es responsable.
La supervisión debe ser real: una persona necesita tiempo, información y autoridad para modificar el resultado.
Participación antes del despliegue
Incorporar usuarios en pruebas tempranas puede detectar preocupaciones de privacidad, lenguaje o accesibilidad antes de que el sistema llegue a producción.
Este enfoque es especialmente útil en servicios dirigidos a colectivos diversos o con consecuencias relevantes.
Qué debería publicar una Administración
Además de métricas técnicas, los organismos pueden compartir tasas de error, revisiones humanas, incidencias y cambios introducidos tras feedback. Esta transparencia permite evaluar evolución y no solo promesas iniciales.
Los resultados agregados deben proteger la privacidad y evitar exponer información sensible de usuarios.
Cómo utilizar los resultados europeos
Las más de 4.000 respuestas ofrecen una señal sobre expectativas ciudadanas, pero cada Administración debe validar conclusiones en su propio contexto. Cultura, tipo de servicio y nivel de riesgo pueden modificar la percepción.
La principal lección es incorporar confianza y experiencia como métricas de diseño, no tratarlas como un asunto de comunicación posterior.
Evaluaciones periódicas, no una encuesta única
La percepción ciudadana puede cambiar cuando aumenta la familiaridad con la tecnología o aparecen incidentes públicos. Repetir evaluaciones con una metodología comparable permitiría observar evolución en el tiempo.
También conviene segmentar por tipo de servicio y experiencia previa para entender dónde aparecen mayores dudas y qué elementos de diseño ayudan a reducirlas.
La comparación temporal permitirá distinguir tendencias estables de reacciones puntuales.
Ese seguimiento ayudará a mejorar el diseño.
Fotografía: Alex Knight / Pexels.