El Public Sector Tech Watch de Interoperable Europe presentará el 22 de septiembre de 2026 resultados de una encuesta con más de 4.000 personas de cinco países de la UE sobre cómo percibe la ciudadanía el uso de inteligencia artificial por parte de los gobiernos.
La sesión parte de una cuestión central para la adopción de IA pública: una tecnología puede mejorar eficiencia y, al mismo tiempo, deteriorar confianza si se percibe como injusta, opaca o inadecuada para una determinada función.
Qué se ha publicado y por qué merece atención
El evento reúne investigación del Joint Research Centre y una discusión con expertos de administraciones, ciudades, privacidad y tecnología. Su objetivo es conectar evidencia sobre percepción ciudadana con decisiones de diseño.
En el sector público, este tipo de iniciativa debe analizarse más allá del anuncio. Su impacto depende de cómo se integra con procesos existentes, qué datos utiliza, qué responsabilidades crea y qué capacidad tiene la organización para mantenerla con el paso del tiempo.
Impacto en la Administración Pública
La legitimidad de un servicio público no depende únicamente de precisión técnica. Las personas necesitan comprender cuándo interviene un sistema automatizado, qué datos utiliza y cómo pueden pedir revisión.
La transformación digital aporta valor cuando reduce fricción, mejora trazabilidad y permite prestar servicios de forma más coherente. Un proyecto tecnológico que no modifica el proceso puede terminar digitalizando ineficiencias ya existentes.
Por eso resulta útil separar la capa tecnológica de la capa organizativa. La primera incluye aplicaciones, infraestructura, modelos y APIs; la segunda define quién decide, quién valida, cómo se mide el servicio y qué ocurre cuando hay una excepción.
Datos e interoperabilidad
La percepción puede cambiar según el tipo de información utilizada y el contexto. Los proyectos deberían documentar fuentes y explicar por qué se necesitan determinados datos.
Las Administraciones deberían conservar control sobre la información y capacidad de moverla entre sistemas. APIs documentadas, formatos reutilizables, identificadores consistentes y metadatos son elementos que reducen integraciones ad hoc y dependencia de proveedor.
La interoperabilidad no es solo técnica. Dos organismos pueden intercambiar archivos y seguir sin entenderse si utilizan definiciones distintas. La dimensión semántica, las reglas de negocio y las responsabilidades sobre calidad forman parte del mismo problema.
Seguridad, privacidad y continuidad
La confianza depende también de que la Administración proteja datos y responda ante incidentes. Un servicio útil pero inseguro puede perder aceptación rápidamente.
La seguridad debe diseñarse desde el inicio. Gestión de identidades, mínimo privilegio, monitorización, actualización, copias y respuesta a incidentes son capacidades básicas que deben ajustarse a la criticidad del servicio.
Cuando el proyecto trata datos personales o información sensible, debe quedar claro qué finalidades existen, quién accede y durante cuánto tiempo se conserva. La automatización nunca elimina estas obligaciones.
Gobernanza y supervisión
Las decisiones sobre uso de IA deberían incluir evaluación de impacto y criterios sobre cuándo el beneficio justifica automatizar una tarea.
Un proyecto público necesita responsables funcionales y técnicos, un procedimiento para aprobar cambios y métricas que permitan saber si el resultado mejora realmente el servicio. Sin esta gobernanza, una prueba útil puede convertirse en una herramienta difícil de mantener.
La supervisión humana debe ser real cuando exista IA o automatización. La persona responsable necesita contexto para revisar resultados y capacidad para corregirlos.
Contratación y sostenibilidad
Los contratos deben exigir mecanismos que permitan explicar, registrar y evaluar el funcionamiento del sistema, además de métricas técnicas.
La contratación debería contemplar documentación, portabilidad, niveles de servicio, seguridad, subcontratación y reversibilidad. También conviene evitar requisitos excesivamente ligados a una marca o producto si el objetivo puede expresarse mediante capacidades y estándares.
El coste total no termina con la implantación. Mantenimiento, almacenamiento, soporte, formación, auditoría y futuras migraciones deben entrar en la evaluación.
Riesgos y límites
La confianza no debe convertirse en una campaña de comunicación que oculte problemas. Si un sistema es inapropiado para un uso, explicarlo mejor no elimina el riesgo.
Otro riesgo es escalar demasiado pronto. Los pilotos deben probarse con escenarios reales, excepciones y usuarios diversos antes de convertirse en servicios masivos. La calidad media puede ocultar errores relevantes en casos poco frecuentes.
Qué debería revisar una entidad pública
- Objetivo de servicio y métricas de éxito.
- Datos, fuentes y responsables.
- Arquitectura e integraciones.
- Seguridad y protección de datos.
- Supervisión humana y trazabilidad.
- Condiciones de contratación y reversibilidad.
- Plan de operación, mantenimiento y soporte.
- Pruebas con usuarios y casos de excepción.
- Capacidad de reutilización por otras entidades.
- Evaluación periódica de impacto y coste.
Qué pueden aprender otras Administraciones
Las conclusiones pueden ayudar a administraciones españolas a diseñar encuestas, pruebas de usuario y evaluaciones antes de desplegar asistentes o automatizaciones.
La reutilización puede consistir en software, pero también en modelos de datos, cláusulas, métricas, guías o patrones de arquitectura. Compartir conocimiento reduce duplicidades y permite que entidades con menos recursos adopten prácticas ya probadas.
Qué habrá que observar
Será relevante revisar los resultados completos de la encuesta y las diferencias entre países y tipos de uso.
La evaluación posterior al lanzamiento es tan importante como la inicial. Tecnología, proveedores y necesidades cambian, por lo que las decisiones deben revisarse periódicamente.
Preguntas frecuentes
¿Quién impulsa la iniciativa?
El webinar está organizado dentro del Public Sector Tech Watch de Interoperable Europe, con participación del Joint Research Centre.
¿Cuál es el objetivo principal?
Analizar cómo perciben los ciudadanos la IA en el sector público y qué implica para el diseño y despliegue de servicios.
¿Qué papel tiene la interoperabilidad?
Permite conectar el proyecto con sistemas y datos existentes, reducir duplicidades y conservar capacidad de evolución. Incluye aspectos técnicos, semánticos y organizativos.
¿Qué debe evitar una Administración?
Dependencias innecesarias, automatización sin supervisión, datos sin gobernanza y proyectos sin un responsable operativo claro.
Fuente oficial
La información principal procede de Interoperable Europe. Las cifras y características concretas se atribuyen a esa publicación.
Lecturas relacionadas
Puede ampliarse el contexto con nuestros análisis sobre ENS legible por máquina, gobierno del dato, IA en el sector público europeo y código abierto e interoperabilidad.
De la estrategia al servicio público concreto
Uno de los retos más habituales en proyectos de transformación es pasar de principios generales a decisiones operativas. Para confianza ciudadanos IA Administración, la organización debería traducir objetivos como eficiencia, confianza o innovación en casos de uso concretos, responsables y métricas. Sin esta capa, la estrategia corre el riesgo de quedarse en una declaración difícil de evaluar.
Una cartera priorizada ayuda a concentrar recursos. Los proyectos pueden clasificarse por impacto, dificultad, riesgo y disponibilidad de datos. Esto permite empezar por casos donde el beneficio puede medirse y reservar los usos más sensibles para fases posteriores con mayor madurez.
Gobernanza de la inteligencia artificial y automatización
Cuando una Administración incorpora IA, conviene mantener un inventario de sistemas y casos de uso. Este registro puede incluir finalidad, unidad responsable, proveedor, modelo utilizado, fuentes de datos, nivel de supervisión y fecha de última revisión. La visibilidad evita que surjan herramientas no controladas en distintas unidades.
La gobernanza debe ser proporcional. Un asistente interno para resumir documentos no requiere exactamente el mismo procedimiento que una aplicación que influye en un trámite ciudadano. Definir niveles de riesgo permite aplicar controles adecuados sin bloquear usos de bajo impacto.
Preparar datos y documentos antes de automatizar
Muchos proyectos fallan porque intentan automatizar información desordenada. Antes de desplegar IA o analítica conviene revisar fuentes, duplicidades, permisos y vigencia. Un modelo no corrige automáticamente un repositorio con documentos contradictorios o desactualizados.
La Administración debería identificar qué fuentes son oficiales y cómo se actualizan. En sistemas que generan respuestas, resulta útil poder vincular cada resultado a la documentación de origen para facilitar revisión y corregir errores.
Diseño centrado en usuarios
La tecnología pública debe probarse con las personas que realmente utilizarán el servicio. Empleados y ciudadanía pueden encontrar barreras que no aparecen en pruebas técnicas: lenguaje confuso, pasos innecesarios, accesibilidad deficiente o respuestas difíciles de interpretar.
Los pilotos deberían recoger datos cualitativos y cuantitativos. Tiempo de tarea, abandonos, errores y satisfacción permiten entender si la innovación reduce fricción o simplemente traslada trabajo a otro punto del proceso.
Confianza y explicación
La confianza se construye con comportamiento consistente y mecanismos de recurso, no únicamente con mensajes institucionales. Cuando un sistema automatizado interviene de forma relevante, el usuario debería poder conocerlo y saber cómo obtener ayuda o revisión humana.
Explicar no significa publicar todos los detalles del algoritmo. Significa ofrecer información suficiente sobre finalidad, datos utilizados, límites y responsabilidades para que el ciudadano pueda comprender qué papel tiene la tecnología.
Capacitación interna
Los empleados públicos necesitan formación adaptada a sus funciones. Quien revisa resultados de IA debe conocer fallos frecuentes, criterios de validación y reglas sobre información sensible. Quien contrata tecnología necesita comprender aspectos de portabilidad, modelos, datos y dependencia.
La formación continua es importante porque herramientas y marcos cambian rápidamente. Una sesión puntual puede quedar obsoleta en pocos meses si no existe un canal para actualizar prácticas.
Cómo decidir si un piloto pasa a producción
Antes de escalar, la entidad debería exigir resultados mínimos definidos de antemano. Precisión, tiempo ahorrado, reducción de carga, coste, seguridad y aceptación de usuarios son criterios posibles. Un piloto no debería pasar a producción solo porque técnicamente funciona.
También hay que revisar la capacidad operativa. Soporte, monitorización, incidencias, actualización de fuentes y presupuesto recurrente deben estar resueltos. La fase estable necesita una organización distinta a la del experimento.
Contratación preparada para cambios tecnológicos
El mercado de IA cambia con rapidez. Un contrato demasiado ligado a un modelo concreto puede quedar obsoleto. Resulta más sostenible definir capacidades, métricas, interfaces y condiciones de sustitución, manteniendo bajo control de la Administración los datos y la lógica del servicio.
La reversibilidad debe probarse. Exportar documentación al final de un contrato no sirve de mucho si el nuevo proveedor no puede reconstruir configuraciones, historiales o integraciones.
Ética aplicada y no solo declarativa
Hablar de uso responsable exige convertir valores en controles verificables. Revisar sesgos, accesibilidad, proporcionalidad, supervisión y efectos sobre colectivos concretos son ejemplos de decisiones operativas que pueden documentarse y auditarse.
La evaluación ética debe conectarse con el caso de uso real. No todos los sistemas presentan los mismos riesgos, y aplicar un cuestionario idéntico a cualquier herramienta puede generar burocracia sin mejorar la protección.
Medir impacto público
Los indicadores deberían relacionarse con el servicio: tiempo para completar un trámite, consultas resueltas, incidencias, coste por expediente o calidad percibida. El número de usuarios o de modelos desplegados mide actividad, pero no necesariamente mejora.
La revisión periódica permite retirar soluciones que no aportan valor y concentrar recursos en las que sí funcionan. En ese sentido, Más de 4.000 europeos opinan sobre IA en la Administración: la confianza entra en el diseño del servicio puede ser más útil como punto de partida para una conversación de gestión que como fin en sí mismo.
Una hoja de ruta práctica para los próximos doce meses
Una entidad que quiera aplicar aprendizajes relacionados con confianza ciudadanos IA Administración puede empezar con un inventario de iniciativas existentes y seleccionar un único caso donde el problema esté bien definido. Antes de ampliar alcance conviene fijar una línea base con tiempos, costes, errores y satisfacción. Esta comparación permite separar una mejora real de una percepción inicial positiva.
Durante los primeros meses deberían documentarse arquitectura, fuentes, permisos, dependencias y responsables. La organización necesita saber qué elementos controla directamente y cuáles dependen de proveedores o infraestructuras externas. Esta información será clave cuando aparezcan cambios de versión, incidencias o nuevas obligaciones.
En una segunda fase puede evaluarse la reutilización. Si el proyecto ha generado modelos de datos, conectores, guías, pruebas o cláusulas útiles, conviene publicarlos internamente y valorar si otras unidades pueden aprovecharlos. Reutilizar conocimiento reduce el coste de repetir decisiones y ayuda a construir una arquitectura más coherente.
Finalmente, la revisión anual debería comprobar si el servicio sigue justificando su coste, si han cambiado los riesgos y si existe una alternativa mejor. La transformación digital pública es un proceso continuo: mantener una solución por inercia puede ser tan perjudicial como sustituirla demasiado pronto. El objetivo es conservar capacidad de decisión y evidencia suficiente para adaptar el servicio cuando sea necesario.
Cómo incorporar la confianza a la evaluación de un servicio de IA
La confianza puede medirse de forma más concreta de lo que parece. Una Administración puede preguntar a los usuarios si comprendieron cuándo intervino la IA, si supieron cómo pedir ayuda, si percibieron el resultado como justo y si volverían a utilizar el servicio. Estas preguntas deben combinarse con datos operativos como errores, reclamaciones, abandonos y solicitudes de revisión.
También conviene comparar distintos tipos de uso. La ciudadanía puede aceptar con facilidad una IA que orienta sobre documentación y, al mismo tiempo, mostrar más reservas cuando la tecnología participa en decisiones que afectan a ayudas, sanciones o derechos. Tratar todos los casos como equivalentes impide diseñar controles proporcionales.
La investigación con más de 4.000 participantes puede aportar una referencia útil, pero cada Administración debería validar sus propios servicios con usuarios reales y contextos locales. La confianza no es una propiedad permanente: puede aumentar con una experiencia consistente o deteriorarse rápidamente tras errores, falta de explicación o incidentes de seguridad.
Fotografía: Hamdi Kılınç / Pexels.