Saltar al contenido principal
Volver al blog
AccesibilidadIA en la administración

Accesibilidad e inclusión en servicios públicos impulsados por IA

1 de mayo de 20265 min de lecturaOptimTech
Compartir:

Por qué la accesibilidad debe ser central en proyectos de IA públicos

Los proyectos de IA en la administración pública no son neutros: afectan derechos básicos (acceso a servicios, no discriminación, privacidad). Además de obligaciones generales de transparencia y protección de datos (RGPD) y requisitos emergentes del EU AI Act para sistemas de riesgo, los equipos municipales deben garantizar que la tecnología sea usable por personas con diferentes capacidades, niveles digitales, idiomas y condiciones de conectividad. Si no se diseña pensando en la inclusión, se amplían las desigualdades y se corre el riesgo de incumplimiento legal, rechazo ciudadano y costes de rectificación elevados.

Riesgos concretos a evitar

  • Exclusión digital: interfaces que requieren alta alfabetización digital o conexiones rápidas.
  • Discriminación algorítmica: modelos que funcionan peor para grupos minoritarios o vulnerables.
  • Barreras de accesibilidad: formatos no compatibles con lectores de pantalla, colores que dificultan la lectura, o ausencia de alternativas multimedia.
  • Falta de vías alternativas: dependencias exclusivas de canales digitales sin opciones telefónicas o presenciales.
  • Problemas de transparencia y recursos humanos: decisiones automatizadas sin explicación ni revisión humana.

Checklist operativo para proyectos de IA (antes, durante y después)

1. En la definición del proyecto

  • Identificar grupos de usuarios vulnerables y sus necesidades concretas (personas mayores, diversidad funcional sensorial o cognitiva, migrantes, baja alfabetización digital).
  • Requerir proveedores que demuestren experiencia en accesibilidad e inclusión y que incluyan pruebas con usuarios reales en el pliego.
  • Incluir métricas de inclusión y umbrales de aceptación en criterios de adjudicación (p. ej., tasa mínima de éxito en pruebas con usuarios con discapacidad).

2. En la gestión de datos

  • Revisar representatividad: evaluar la cobertura de atributos relevantes en los datos (edad, género, procedencia, idioma, discapacidad cuando sea legal y ético recogerlo).
  • Definir procesos de pseudonimización y minimización alineados con RGPD; evitar inferencias sensibles que puedan perjudicar a grupos vulnerables.
  • Documentar decisiones de exclusión/inclusión de datos y su impacto esperado en el servicio.

3. En el desarrollo y evaluación del modelo

  • Tests de equidad: evaluar rendimiento segmentado por grupos relevantes y documentar desviaciones. Establecer criterios de tolerancia y pasos correctores.
  • Explicabilidad operativa: diseñar salidas que permitan explicar decisiones a una persona no técnica (resúmenes simples, motivos, variables clave).
  • Fallback humano: asegurar que todas las decisiones automatizadas que afectan derechos o prestaciones tengan revisión humana accesible y fácil de solicitar.

4. En la interfaz y canales de servicio

  • Multicanalidad obligatoria: web accesible, atención telefónica con adaptaciones (lectura fácil, operadores formados), opción presencial o por correo para quienes lo necesiten.
  • Alternativas ligeras: versiones de baja banda y formatos no gráficos (texto claro, voz).
  • Pruebas de usabilidad inclusiva: sesiones con personas reales de los grupos identificados y documentación de fallos críticos.

5. En despliegue y monitorización

  • Monitoreo continuo de uso y errores por segmento de usuario; alertas si se detectan barreras nuevas.
  • Canales de feedback explícitos y visibles (formulario accesible, teléfono, buzón físico) y compromiso de respuesta en plazos concretos.
  • Registros para auditoría: conservar trazabilidad de decisiones y métricas de equidad para cumplimiento y potencial auditoría bajo EU AI Act.

Requisitos contractuales y organizativos (qué pedir al proveedor)

  • Entregables: informe de accesibilidad, reportes de pruebas de equidad, plan de mitigación de sesgos y documentación técnica que permita auditoría.
  • Pruebas de aceptación: incluir escenarios de usuarios con discapacidades y condiciones de conectividad baja como parte de la aceptación final.
  • Capacitación: formación para atención ciudadana y revisores humanos en cómo interpretar salidas del sistema y resolver incidencias de accesibilidad.
  • Mantenimiento y soporte: cláusulas sobre actualizaciones que mejoren accesibilidad y gestión de incidencias en plazos acordados.

Medición práctica: KPIs sugeridos

  • Tasa de éxito en tareas críticas por segmento (p. ej., completar un trámite) — objetivo por defecto ≥ 90% en todos los grupos.
  • Tiempo medio de resolución con y sin asistencia humana.
  • Número de peticiones de alternativa presencial por 1.000 usuarios.
  • Porcentaje de incidencias de accesibilidad resueltas en X días.
  • Desviación de rendimiento del modelo entre grupos (se debe documentar y justificar).

Ejemplo de primer plan de 90 días (municipio mediano)

  • Semana 1–2: Mapear servicios candidatos y usuarios vulnerables; definir objetivos de inclusión.
  • Semana 3–5: Incluir requisitos de accesibilidad y equidad en pliegos o acuerdos, seleccionar proveedor con experiencia.
  • Semana 6–10: Pruebas de datos y primer prototipo con pruebas de usabilidad inclusiva.
  • Semana 11–12: Ajustes, definición de KPIs y plan de despliegue multicanal.
  • Semana 13: Lanzamiento piloto con monitorización y canales de feedback activos.

Conclusión y acción recomendada

La accesibilidad y la inclusión no son añadidos: son criterios de éxito y cumplimiento. Acción inmediata recomendada para responsables municipales: revisar los proyectos de IA en curso frente a la checklist anterior y programar una auditoría rápida de 30 días sobre accesibilidad, equidad y canales alternativos. Un diagnóstico temprano reduce costes y mejora la confianza ciudadana. Soluciones como OptimGov incluyen módulos y prácticas que facilitan incorporar estas comprobaciones en procesos administrativos ya existentes, pero lo importante es arrancar con objetivos claros y mediciones concretas.

Toma clave: incorpora pruebas con usuarios reales y métricas desagregadas desde la fase de definición; exige fallback humano y canales alternativos antes de poner en producción cualquier sistema de IA que afecte a la ciudadanía.