Explicabilidad práctica de los sistemas de IA para personal municipal

La exigencia de explicabilidad no es un deseo académico: es requisito operativo y legal cuando la IA apoya decisiones administrativas. El EU AI Act impone obligaciones de transparencia y documentación para sistemas de riesgo, el RGPD condiciona procesos automatizados que afecten a derechos de las personas, y el ENS (RD 311/2022) exige medidas de seguridad y trazabilidad en sistemas de la administración. Aquí explicamos cómo transformar esos requisitos en explicaciones prácticas que los equipos municipales y la ciudadanía puedan usar.

¿Para quién y para qué explicar?

Antes de diseñar explicaciones, define audiencias y objetivos. Al menos distingue tres perfiles:

• Ciudadanía: necesita respuestas claras, breves y orientadas a recuso/seguimiento.
• Personal técnico/operativo (gestores, interventores): requiere detalles sobre variables, versiones del modelo y límites.
• Auditoría/legal: pide trazabilidad completa: datos de entrada, transformación, versión de modelo, logs.

Diseñar para todos a la vez genera ruido. Usa explicaciones estratificadas (see next).

Patrón operativo: explicaciones estratificadas (3 niveles)

Aplicable en expedientes de subvención, evaluación de ofertas, propuestas urbanísticas, etc.

1. Nivel 1 — Resumen ciudadano (1-2 frases)

   • Qué decisión ayudó a tomar la IA y resultado.
   • Motivo principal en lenguaje no técnico.
   • Indicación de recursos para impugnar o pedir revisión.

   Ejemplo: "La propuesta A ha quedado en segundo lugar por puntuación técnica (82/100). Factores clave: experiencia del equipo y precio. Si desea más información o presentar recurso, puede hacerlo en 15 días."

2. Nivel 2 — Justificación operativa (para gestores)

   • Variables más relevantes (top 3–5) con su contribución relativa.
   • Umbrales aplicados y versión del modelo.
   • Breve nota sobre incertidumbre (p. ej. intervalos de confianza o casos donde el modelo muestra baja certeza).

   Ejemplo: "Puntuación total 82/100. Contribuciones: experiencia 40%, solución técnica 30%, precio 20%, cumplimiento administrativo 10%. Modelo v1.3 (entrenado con datos 2018–2025). Incertidumbre alta en propuestas con formatos atípicos."

3. Nivel 3 — Registro de auditoría (para auditoría y legal)

   • Datos de entrada exactos (hashes/IDs o extracto no personal), transformaciones aplicadas, versión del modelo, seed/entornos, parámetros, fecha/hora, operador humano.
   • Rationale técnico: método de explicación empleado (SHAP, LIME, reglas extraídas) y limitaciones conocidas.

   Ejemplo: "Input ID 2026-0456; variables normalizadas: precio_z, experiencia_años; transformaciones: imputación mediana; explicación generada con SHAP v0.42. Logs almacenados en repositorio X."

Métodos y cuándo elegirlos

No todos los métodos son adecuados para todos los públicos.

• Regla basada / modelos lineales: fácil de explicar cuantitativamente (coeficientes). Útil cuando la lógica debe ser transparente desde el inicio (p. ej. criterios de adjudicación).
• Explicadores locales (SHAP/LIME): adecuados para explicar decisiones puntuales en modelos complejos; requieren nivel 2–3.
• Contrafactuales sencillos: muestran qué cambios mínimos permitirían otro resultado (útil para ciudadanos que buscan recurso o mejora).
• Plantillas narrativas: combinan elementos anteriores en lenguaje natural para Nivel 1.

Elige método según riesgo, exigencia legal y capacidad operativa.

Plantillas prácticas (texto listo para usar)

• Ciudadano (rechazo/negativa): "Su solicitud ha sido denegada. Motivo principal: [motivo breve]. Si cree que hay un error, puede presentar recurso en [plazo] aportando [documentos]. Para solicitar una explicación técnica, diríjase a [contacto]."
• Gestor (evaluación interna): "Resultado: [score]. Factores clave: [X: +Y pts], [Z: -W pts]. Modelo: [id, versión]. Notas: [incertidumbre/inputs ausentes]."
• Auditoría (registro): "ID expediente, inputs (hash), transformaciones, modelo (hash), explicación (método + output), usuario que validó, timestamp."

Incorpora estas plantillas en el UI/expediente y en los pliegos cuando externalices IA.

Integración práctica y pruebas

• Prueba con usuarios reales: valida que Nivel 1 sea comprensible con tests de usabilidad (5–8 usuarios).
• Define límites de divulgación: por seguridad o privacidad, decide qué detalle técnico no se publicará pero sí quedará en el registro de auditoría.
• Automatiza generación de explicaciones pero obliga a revisión humana en decisiones sensibles (EU AI Act: sistemas de alto riesgo requieren medidas de mitigación y supervisión humana).
• Incluye en el contrato cláusulas de soporte del proveedor para generar logs y explicar resultados (SLA de explicabilidad).

Checklist rápido para equipos municipales

• Clasificar el sistema según EU AI Act (¿alto riesgo?).
• Diseñar explicaciones por audiencia (3 niveles).
• Seleccionar método de explicación adecuado.
• Preparar plantillas ciudadanas y operativas.
• Implementar logs con trazabilidad conforme a ENS y RGPD.
• Testear con usuarios y documentar resultados en el expediente.

Conclusión y acción recomendada

Toma una decisión concreta esta semana: elige un proceso piloto (p. ej. evaluación de subvenciones o scoring de solicitudes) y define las tres explicaciones (ciudadano, gestor, auditor) usando las plantillas anteriores. Documenta el método de explicación en el pliego o en el roadmap de gobernanza AI (OptimGov puede integrarlo en su diagnóstico), y programa una sesión de validación con al menos cinco funcionarios y tres usuarios finales. Esa prueba mínima te dará la evidencia práctica para cumplir transparencia, reducir recursos por reclamaciones y cumplir obligaciones legales.

Takeaway: explicabilidad no es solo técnica; es diseño de comunicación. Diseñar tres niveles de explicación, con plantillas y trazabilidad, permite cumplir EU AI Act, RGPD y ENS sin paralizar operaciones.