Automatizar trámites públicos sin excluir al ciudadano

Un trámite automatizado solo es defendible si cumple tres condiciones: existe una vía alternativa atendida por personas, la decisión puede explicarse en lenguaje comprensible, y el expediente queda trazado de extremo a extremo. Si falta cualquiera de las tres, la automatización no elimina el coste del trámite: lo traslada al ciudadano.

Este artículo desarrolla cómo se diseñan esas tres condiciones desde el principio, no como parche posterior.

---

¿Qué es la exclusión digital y por qué es un problema de cumplimiento?

Definición. Exclusión digital administrativa es la situación en la que una persona con derecho reconocido a una prestación o a un trámite no puede ejercerlo porque el único canal disponible le resulta inaccesible.

Las causas no son las que suelen citarse en las presentaciones. Rara vez es «falta de cultura digital» en abstracto. En la práctica son cuatro y todas tienen solución de diseño:

Causa	Manifestación concreta
Barrera de identificación	El trámite exige un certificado digital que solo se obtiene con otro trámite igual de complejo
Barrera de dispositivo o conectividad	El formulario no funciona en móviles antiguos o requiere subir archivos pesados
Barrera de accesibilidad	Formularios sin etiquetas, sin contraste suficiente o inutilizables con lector de pantalla
Barrera de comprensión	El trámite es accesible técnicamente y su lenguaje no es comprensible para su destinatario

La última es la más frecuente y la menos medida. Un formulario perfectamente accesible en términos técnicos sigue excluyendo a buena parte de sus destinatarios si está escrito en jerga administrativa.

Y esto no es un debate de política pública: es exposición. Una administración que digitaliza un trámite y deja fuera a un colectivo concreto acumula reclamaciones, recursos y, en el peor caso, una resolución que la obliga a rehacer el procedimiento entero. Sale más caro que haberlo diseñado bien.

¿Qué exige la norma cuando una administración decide de forma automatizada?

Tres capas normativas se superponen aquí, y conviene no mezclarlas.

Procedimiento administrativo. En España, el artículo 41 de la Ley 40/2015, de Régimen Jurídico del Sector Público, define la actuación administrativa automatizada como aquella realizada íntegramente por medios electrónicos sin intervención directa de un empleado público. Y exige algo muy concreto que se olvida con frecuencia: determinar previamente el órgano competente para la definición de especificaciones, programación, mantenimiento, supervisión y control de calidad del sistema, y el órgano responsable a efectos de impugnación. Es decir: antes de automatizar hay que decir por escrito a quién se recurre. Los países de América Latina cuentan con normas propias de procedimiento administrativo electrónico con exigencias equivalentes en espíritu; el análisis debe hacerse sobre la norma aplicable en cada jurisdicción, no por analogía.

Protección de datos. El artículo 22 del Reglamento General de Protección de Datos reconoce el derecho a no ser objeto de una decisión basada únicamente en tratamiento automatizado que produzca efectos jurídicos o afecte significativamente a la persona. Cuando la decisión está permitida por alguna de las excepciones, subsisten garantías: intervención humana, expresión del punto de vista del interesado e impugnación de la decisión.

Regulación de IA. El Reglamento (UE) 2024/1689 sobre inteligencia artificial clasifica determinados usos en el ámbito de servicios públicos esenciales dentro de las categorías de mayor exigencia. La clasificación concreta de un sistema depende de su finalidad real, no de cómo se le llame internamente, y esa evaluación se hace caso por caso.

Accesibilidad. En el ámbito del sector público europeo, el Real Decreto 1112/2018 traspone los requisitos de accesibilidad de sitios web y aplicaciones móviles, e incorpora algo especialmente relevante aquí: un mecanismo por el que cualquier persona puede comunicar un incumplimiento y solicitar la información excluida. La accesibilidad deja de ser una recomendación técnica y pasa a ser un derecho con vía de reclamación.

---

Condición 1: la vía alternativa que de verdad funciona

Casi todas las administraciones dicen tener una. Casi ninguna la tiene en el sentido útil del término.

Qué no es una vía alternativa:

• Un teléfono que deriva al mismo formulario web.
• Una oficina que exige cita previa que solo puede pedirse por internet.
• Un correo electrónico a un buzón sin plazo de respuesta comprometido.
• Un PDF descargable que hay que presentar por el canal digital.

Qué sí lo es. Una vía alternativa válida cumple cuatro requisitos acumulativos:

1. Es accesible por un canal distinto de aquel que constituye la barrera. Si la barrera es la identificación digital, la alternativa no puede requerir identificación digital.
2. Tiene los mismos plazos y los mismos efectos. Si por la vía alternativa el expediente tarda el triple, no es una alternativa: es una penalización.
3. Está atendida por personas con capacidad de resolver. No de registrar la solicitud y derivar.
4. Se anuncia en el mismo punto en que aparece la barrera, no en una página de ayuda a tres clics.

El cuarto punto es el más barato de implementar y el que casi nadie hace. En el momento exacto en que el sistema rechaza a alguien —certificado no válido, navegador no compatible, documento no aceptado— es cuando hay que ofrecer la alternativa, no en un apartado de preguntas frecuentes.

Condición 2: explicabilidad de la decisión

Definición. Una decisión automatizada es explicable cuando la administración puede indicar qué datos concretos del expediente se utilizaron, qué criterio se aplicó sobre ellos y qué habría cambiado el resultado, en un lenguaje que el destinatario entienda.

Tres niveles, y hay que tenerlos los tres:

Nivel	Destinatario	Contenido
Explicación al interesado	Ciudadano	Qué datos suyos se usaron, qué regla se aplicó, qué habría cambiado el resultado y cómo recurrir
Explicación técnica	Órgano de control y auditoría	Especificación del sistema, versiones, reglas, datos de entrada, registro de la ejecución concreta
Explicación de gobierno	Responsable del procedimiento	Por qué se automatizó, qué riesgos se evaluaron y quién responde

La explicación al interesado tiene un criterio de calidad medible: si tras leerla la persona no sabe qué hacer a continuación, no es una explicación. «Su solicitud no cumple los requisitos establecidos» no explica nada. «Su solicitud no cumple el requisito de residencia porque el dato de empadronamiento consultado con fecha de tal día indica un municipio distinto» sí, porque señala el dato concreto que se puede rebatir.

Un punto que conviene fijar por escrito antes de construir nada: si el sistema no puede explicar una decisión, esa decisión no se automatiza. Es una restricción de diseño, no una aspiración. Y descarta de entrada ciertos enfoques técnicos para determinadas fases del procedimiento, por muy buen rendimiento que ofrezcan.

Condición 3: trazabilidad del expediente

Aquí es donde la ingeniería aporta lo que la norma exige pero no describe.

Un expediente automatizado debe permitir reconstruir, meses o años después, la secuencia completa: qué entró, qué versión del sistema lo procesó, qué se decidió, quién intervino y qué se comunicó. El registro mínimo:

Elemento	Qué se registra
Entrada	Documentos y datos recibidos, con huella criptográfica de cada uno
Consultas a terceros	Qué se consultó, a qué organismo, con qué resultado y en qué instante
Versión del sistema	Identificador exacto de la versión de reglas o modelo que resolvió
Decisión	Resultado, criterio aplicado y datos determinantes
Intervención humana	Si la hubo: quién, cuándo, con qué rol y con qué veredicto
Comunicación	Qué se notificó, por qué canal y cuándo se tuvo por notificado

Dos exigencias técnicas sobre ese registro:

• Inmutabilidad. Un registro que puede editarse a posteriori no sirve ante una impugnación, que es exactamente el momento para el que existe.
• Verificabilidad independiente. La huella criptográfica de un documento permite demostrar que el archivo que hoy consta en el expediente es bit a bit el que se presentó. Cuando además esa huella se ancla en una referencia temporal externa y verificable, la prueba deja de depender de la palabra de quien custodia el sistema. Es el mismo principio que aplicamos en nuestra plataforma de certificación probatoria: huella SHA-256 del original, sello temporal anclado y verificación pública sin cuenta.

Esa combinación —cadena de custodia documentada más prueba verificable por un tercero— es el núcleo de nuestro trabajo con instituciones públicas e infraestructura crítica.

---

¿Qué aporta ISO 42001 a este diseño?

Lo que aporta un sistema de gestión de IA es que estas tres condiciones dejen de depender del criterio del equipo que construyó el trámite.

• La evaluación de impacto previa obliga a preguntarse, antes de desplegar, a quién puede perjudicar el sistema y qué pasa si se equivoca. La exclusión digital aparece ahí de forma natural; en una revisión técnica posterior, no.
• La definición de roles obliga a nombrar al responsable antes de automatizar, que es justo lo que exige el artículo 41 de la Ley 40/2015 desde otra dirección.
• El registro de eventos convierte la trazabilidad en un control auditable y no en una buena costumbre.
• La revisión periódica impide que un trámite automatizado hace tres años siga funcionando con criterios que ya nadie recuerda haber aprobado.

Los requisitos concretos de la norma, cláusula por cláusula, están desarrollados en ISO 42001: qué exige de verdad a quien usa IA, y el estado real de nuestra propia implantación —incluido lo que no está certificado por un tercero— se publica en el centro de confianza.

Errores frecuentes al automatizar un trámite

1. Automatizar el trámite tal cual está. Si el procedimiento en papel era confuso, automatizarlo produce confusión más rápida. La simplificación va antes que la automatización, siempre.
2. Medir el éxito por reducción de tiempos. El indicador que importa es la proporción de solicitantes que completan el trámite, no la velocidad de los que lo consiguen. Un sistema que resuelve en segundos para quienes ya lo tenían fácil, y deja fuera al resto, ha empeorado el servicio aunque el tiempo medio baje.
3. Tratar la vía alternativa como excepción residual. Se diseña como parte del servicio, con recursos asignados y plazos comprometidos.
4. No registrar las decisiones denegatorias con el mismo detalle que las estimatorias. Son precisamente las que se recurren.
5. Confundir supervisión con firma. Una persona que aprueba en bloque lo que resolvió el sistema no es una intervención humana efectiva; es un sello. Cómo se detecta esa degradación con datos está en observabilidad de agentes IA.
6. Publicar la declaración de accesibilidad y no volver a mirarla. Es un documento vivo con obligación de actualización.

Qué no promete un buen diseño

Ningún sistema elimina el error administrativo ni ofrece seguridad absoluta frente a un incidente. Lo que un diseño con estas tres condiciones consigue es distinto y más realista: que el error sea detectable, explicable y reversible dentro del plazo en que todavía se puede reparar el daño. Un expediente que no puede reconstruirse convierte un fallo corriente en un problema sin solución.

Lo mismo aplica a la protección de la infraestructura que sostiene el trámite, que es un trabajo aparte y continuo: nuestra práctica de protección se ocupa de esa capa, y la de compliance de la documental.

---

Qué hacer ahora

1. Elige el trámite más usado de tu organismo y comprueba, con una persona real y un dispositivo modesto, cuántas personas de cada cien lo terminan. Ese dato no suele existir y es el que cambia decisiones.
2. Localiza el punto exacto de abandono y comprueba si en ese punto se ofrece una vía alternativa. Casi nunca se ofrece.
3. Escribe la explicación de una denegación tal como la leería el interesado. Si no puedes escribirla, el sistema no está listo para resolver ese caso.
4. Verifica quién consta como órgano responsable a efectos de impugnación de cada actuación automatizada ya en marcha. Si no consta, es la primera corrección.
5. Comprueba que el registro del expediente es inmutable y que incluye la versión del sistema que resolvió.

Si necesitas revisar un procedimiento automatizado —o diseñar uno desde cero con la vía alternativa, la explicabilidad y la cadena de custodia incorporadas— escríbenos desde contacto.