Gobierno proactivo: servicios que llegan al ciudadano primero

Un ciudadano no debería tener que descubrir que tiene derecho a una ayuda. No debería enterarse, tres meses tarde, de que su pensión estaba mal calculada, ni hacer cola para renovar un documento que el propio Estado sabía que caducaba. El gobierno reactivo espera a que alguien pida. El gobierno proactivo actúa antes de que haga falta pedir. Esa diferencia, que parece de matiz, es en realidad la frontera entre una administración que administra trámites y una que administra vidas.

Mi tesis es sencilla y defendible: la próxima gran ventaja competitiva de un gobierno digital no será tener más trámites en línea, sino tener menos trámites en total, porque el sistema ya sabe lo que el ciudadano necesita y actúa primero. No se trata de digitalizar la fila; se trata de eliminarla. Los gobiernos que lo consigan no ganarán una encuesta de satisfacción más alta —ganarán algo más valioso: confianza institucional, que es la moneda que sostiene todo lo demás que un Estado necesita hacer, desde cobrar impuestos hasta pedir sacrificios en una crisis.

¿Qué significa exactamente que un gobierno sea "proactivo"?

Un servicio proactivo es aquel que el Estado inicia usando datos que ya posee, sin exigir al ciudadano una solicitud, un formulario o una visita. La definición operativa es corta: si el ciudadano tiene que empezar el trámite, el servicio es reactivo; si el Estado lo empieza por él, es proactivo. Entre ambos extremos hay un espectro útil de tres niveles.

• Reactivo puro: el ciudadano debe enterarse del derecho, reunir los documentos y presentar la solicitud, casi siempre en persona o mediante un formulario complejo.
• Asistido o prellenado: el Estado prepara el trámite con los datos que ya tiene —una declaración de impuestos precompletada, por ejemplo— pero el ciudadano debe revisarla y confirmarla.
• Proactivo pleno: el Estado detecta el evento vital (nacimiento, cumplir 65 años, cambio de domicilio) y activa el beneficio o la obligación automáticamente, notificando después.

Dinamarca ilustra el segundo nivel desde hace años: la agencia tributaria danesa, Skattestyrelsen, envía a la mayoría de los asalariados una declaración de la renta ya calculada con los datos que empleadores y bancos han reportado; el contribuyente solo debe actuar si algo está mal. Estonia va un paso más allá, en el tercer nivel: cuando nace un hijo, el registro civil comparte el evento a través de la plataforma de intercambio de datos X-Road y el trámite de la prestación familiar se inicia sin que ningún progenitor presente una solicitud, tal como documenta el propio programa de gobierno digital del país en e-estonia.com. Esa es la diferencia entre "hacerlo fácil" y "hacerlo innecesario".

¿Por qué la mayoría de los servicios públicos siguen siendo reactivos?

No es por falta de voluntad política; es por arquitectura institucional. Tres barreras explican el estancamiento, y ninguna se resuelve solo con presupuesto.

La primera es el silo de datos. Cada agencia construyó su propio sistema, con su propio identificador de ciudadano, y compartir un campo entre dos ministerios sigue siendo, en muchos países, un proyecto de años. La segunda es el diseño legal heredado: leyes redactadas en la era del papel exigen "solicitud del interesado" como requisito formal, aunque hoy sería técnicamente trivial actuar de oficio. La tercera, la más incómoda, es cultural: durante décadas la solicitud del ciudadano ha servido como mecanismo de control de gasto. Si el trámite es difícil, menos gente lo reclama, y el presupuesto rinde más. Esto tiene nombre en economía del comportamiento: es sludge, el término que Richard Thaler acuñó para describir la fricción diseñada —a veces deliberadamente— que desincentiva una acción que en teoría es un derecho. Reducir el sludge en servicios públicos no es una mejora cosmética de experiencia; es una decisión distributiva, porque quienes más sufren la fricción administrativa suelen ser quienes menos capacidad tienen de superarla: personas mayores, con baja alfabetización digital o en situación de vulnerabilidad.

Cada formulario que un ciudadano vulnerable no logra completar no es un caso perdido: es un fracaso de diseño con nombre y apellido.

¿Qué principios de economía conductual explican por qué la proactividad funciona?

Dos mecanismos hacen que un servicio proactivo funcione mejor que uno reactivo, incluso cuando el beneficio final es idéntico.

El primero es el poder del default, la opción que se aplica si nadie hace nada. La arquitectura de elección —el concepto que Richard Thaler y Cass Sunstein desarrollaron en su libro Nudge (2008)— demuestra que la opción predeterminada casi siempre gana, no porque la gente sea perezosa, sino porque interpreta el default como la recomendación implícita del sistema. Un trámite proactivo convierte el beneficio en el default: se activa a menos que el ciudadano decline. Un trámite reactivo hace lo contrario: exige acción explícita para acceder al mismo derecho. La diferencia en tasa de adopción entre ambos diseños, documentada repetidamente en programas de pensiones y ahorro, se cuenta en decenas de puntos porcentuales.

El segundo mecanismo es la aversión a la pérdida. Un ciudadano que descubre tarde que perdió un plazo —para renovar un subsidio, para reclamar una devolución— no solo pierde el beneficio; siente que algo suyo le fue arrebatado, y esa emoción se traduce en desconfianza hacia la institución completa, no solo hacia el trámite específico. El Behavioural Insights Team del gobierno británico, creado en 2010 dentro del Cabinet Office, documentó un efecto relacionado en su trabajo sobre cartas de recordatorio fiscal: modificar el mensaje para apelar a la norma social —indicar que la mayoría de los contribuyentes ya habían pagado— cambió el comportamiento sin cambiar ni el importe ni el plazo, tal como recoge su informe de 2012 Applying Behavioural Insights to Reduce Fraud, Error and Debt, publicado por el Cabinet Office. El principio general se traslada bien a la proactividad: anticipar un evento y actuar antes de que se convierta en pérdida evita la reacción emocional que erosiona la confianza.

¿Cómo se ve un servicio proactivo bien diseñado en la práctica?

La proactividad no es un eslogan tecnológico; es un rediseño del momento en que el Estado interviene. Tres patrones se repiten en las implementaciones que funcionan.

El primero es el trigger de evento vital: el sistema no espera una solicitud, espera un hecho verificable —nacimiento, defunción, cambio de estado civil, jubilación— que ya está registrado en algún punto de la administración, y lo usa como disparador. Francia trabajó esta lógica bajo el programa de simplificación conocido como "Dites-le-nous une fois" (dínoslo una sola vez), impulsado dentro del choque de simplificación administrativa de la pasada década, con el principio de que ningún dato ya declarado a una agencia debía volver a pedirse en otra.

El segundo patrón es la notificación con opción de salida, no de entrada: el ciudadano recibe la comunicación de que el beneficio ya fue activado y puede rechazarlo o corregirlo, en vez de recibir un formulario que debe completar para activarlo. El tercero es la reversibilidad visible: todo trámite proactivo debe mostrar con claridad cómo deshacerlo, porque la confianza en la automatización depende tanto de lo que el sistema hace como de lo fácil que es corregirlo si se equivoca.

Vale la pena notar que ninguno de estos patrones requiere inteligencia artificial avanzada. Requiere algo más difícil de conseguir: acuerdos de interoperabilidad entre agencias, una base legal que permita actuar de oficio y un mandato político que priorice el derecho del ciudadano sobre el ahorro presupuestario que genera la fricción. La tecnología es la parte fácil del problema.

¿Cómo construye un equipo de gobierno un servicio proactivo, paso a paso?

El error habitual es empezar por la tecnología. El orden correcto empieza por el evento vital y termina por la plataforma.

1. Mapear los eventos vitales, no los trámites. En vez de inventariar formularios, identifique los momentos de la vida del ciudadano —nacer, cumplir una edad, perder un empleo, mudarse— que hoy disparan múltiples trámites dispersos en distintas agencias.
2. Auditar qué datos ya existen. Antes de pedir un solo dato nuevo, verifique cuántos de los campos que su formulario exige ya están registrados en otra base del propio Estado. La regla de "dínoslo una sola vez" empieza aquí.
3. Resolver la base legal. Identifique qué norma exige explícitamente "solicitud del interesado" y evalúe si puede modificarse para permitir actuación de oficio con opción de rechazo. Sin este paso, ningún prototipo técnico sobrevive a la revisión jurídica.
4. Diseñar el momento del trigger. Defina qué evento activa el servicio, quién lo verifica y con qué margen de error se puede vivir —un falso positivo en una notificación de beneficio es mucho menos costoso que uno en una obligación fiscal.
5. Construir la notificación, no solo el backend. El ciudadano necesita un mensaje claro, en el canal que realmente usa, que explique qué pasó, por qué y cómo revertirlo. Esta pieza suele delegarse al final del proyecto; debería diseñarse primero.
6. Pilotar con un evento de bajo riesgo. Empiece por un trámite donde el error sea reversible y barato —una renovación documental, no una pensión— para aprender sin exponer al ciudadano a un daño real.
7. Medir abandono evitado, no solo satisfacción. El indicador que importa no es cuánto le gustó el trámite al ciudadano; es cuántos ciudadanos elegibles habrían quedado fuera bajo el modelo reactivo y ahora están dentro.

Este es, en esencia, un ejercicio de diseño de servicios aplicado a la maquinaria pública: rediseñar el recorrido completo del ciudadano a través de agencias que nunca se hablaron entre sí, en vez de pulir cada trámite por separado.

¿Qué riesgos hay que resolver antes de activar un servicio proactivo?

La proactividad mal gestionada genera una objeción legítima: si el Estado actúa sin que yo lo pida, ¿qué tan bien vigilado está el uso de mis datos? Tres riesgos concretos merecen respuesta explícita, no una promesa genérica de "seguridad".

• Uso ampliado de datos ("mission creep"): el dato compartido para activar una prestación puede terminar usándose para fines distintos —fiscalización, control migratorio— sin que el ciudadano lo haya consentido para ese propósito. La solución no es negar el intercambio de datos, sino limitarlo por diseño a la finalidad declarada, con auditoría independiente.
• Errores en cascada: si el dato base está mal, un sistema proactivo propaga el error automáticamente a todos los trámites que dependen de él, en vez de que un ciudadano lo detecte al rellenar un formulario. Por eso la reversibilidad visible del punto anterior no es opcional.
• Exclusión de quien no está en el sistema. La proactividad beneficia a quien ya tiene un registro digital completo. Quien vive fuera del sistema formal —sin dirección registrada, sin cuenta bancaria— queda doblemente excluido: ni recibe el trámite reactivo con facilidad ni es alcanzado por el proactivo. Todo diseño proactivo necesita un canal reactivo de respaldo, no como excepción marginal sino como parte central del servicio.

Estas tensiones entre eficiencia y privacidad no son un obstáculo técnico menor; son la discusión de fondo de cualquier estrategia de gobierno digital, y las he tratado con más detalle al abordar el equilibrio entre datos y confianza ciudadana en este análisis sobre datos y privacidad en la experiencia ciudadana. Ignorar esa tensión no la resuelve; solo la pospone hasta que estalla como escándalo público, y entonces el coste de reconstruir confianza es muchísimo más alto que el coste de haberla diseñado bien desde el inicio.

¿Cómo se mide si un servicio proactivo realmente funciona?

La métrica tradicional de gobierno digital —número de trámites disponibles en línea— mide oferta, no resultado. Un servicio proactivo necesita indicadores distintos, orientados al ciudadano que no tuvo que actuar.

La métrica central debería ser la tasa de captación de derecho (take-up rate): qué porcentaje de la población elegible efectivamente recibe el beneficio, comparado con el escenario reactivo previo. Junto a ella, dos métricas complementarias: el tiempo entre el evento vital y la activación del servicio —cuánto tarda el Estado en reaccionar al nacimiento, la jubilación, el cambio de circunstancia— y la tasa de reversión o corrección, que indica si el sistema está actuando con la precisión suficiente como para que la automatización sea confiable y no una fuente nueva de fricción. Ningún gobierno debería lanzar un programa proactivo sin antes establecer una línea base de madurez digital y de gobernanza de datos entre agencias; una evaluación estructurada, del tipo que ofrece la evaluación de madurez CX, ayuda a identificar en qué bloques —datos, procesos, gobernanza, cultura— está el verdadero cuello de botella antes de comprometer presupuesto en tecnología.

La Organización para la Cooperación y el Desarrollo Económicos incluye la proactividad y el intercambio de datos entre agencias como dimensiones explícitas dentro de sus marcos de evaluación de gobierno digital, reconociendo que la interoperabilidad —no la interfaz— es el verdadero indicador de madurez de un Estado digital.

¿Qué cambia dentro de la organización pública para sostener esto?

Ningún servicio proactivo sobrevive como proyecto piloto aislado; necesita gobernanza que cruce agencias, porque el evento vital de un ciudadano casi nunca pertenece a una sola institución. Esto exige tres cambios organizativos que suelen subestimarse.

Primero, un mandato de gobernanza transversal con autoridad real para forzar la interoperabilidad de datos entre ministerios que históricamente han competido por presupuesto y protagonismo, no colaborado. Segundo, un cambio de incentivos internos: si el desempeño de un funcionario se mide por volumen de trámites procesados, automatizarlos parece reducir su relevancia; el indicador debe migrar hacia calidad del resultado para el ciudadano. Tercero, y el más difícil, una gestión del cambio deliberada dentro de la propia administración, porque el personal que hoy tramita solicitudes reactivas necesita un nuevo rol —supervisar excepciones, resolver casos complejos, auditar el sistema automatizado— y ese tránsito no ocurre solo. Un proceso serio de gestión del cambio es tan parte del proyecto como la plataforma de datos.

Vale la pena decirlo sin rodeos: los gobiernos que traten esto como un proyecto de tecnología de la información fracasarán. Los que lo traten como una reforma de cómo el Estado entiende su relación con el tiempo del ciudadano, tendrán una oportunidad real de conseguirlo.

El siguiente umbral: de servicios que responden a Estados que anticipan

Durante dos décadas, el gobierno digital se midió por cuántos trámites subió a internet. Ese umbral ya se cruzó en la mayoría de los países serios. El siguiente umbral es distinto y más exigente: cuántos trámites logró eliminar por completo, porque el Estado actuó antes de que el ciudadano tuviera que pedir nada. Esa es la frontera donde se juega la próxima década de confianza institucional, y no la ganará quien tenga el portal más bonito, sino quien haya resuelto, agencia por agencia, la pregunta incómoda de quién comparte qué dato con quién y para qué.

Si su institución está evaluando por dónde empezar ese rediseño, en Renascence trabajamos con organismos públicos que buscan pasar de la lógica de trámite a la lógica de anticipación; puede revisar cómo abordamos estos proyectos en experiencia ciudadana y transformación digital en servicios públicos o iniciar una conversación directa a través de nuestro equipo. El ciudadano que nunca tuvo que rellenar un formulario no sabrá que lo evitó, y esa es, precisamente, la señal de que el diseño funcionó.