Cuando algo falla: ordenar la atención del Estado
Digitalizar un trámite es pedirle a una persona que confíe en el sistema. Cuando ese sistema falla, hoy el ciudadano termina moviendo información entre organismos. Ordenar la atención no significa una mesa de ayuda única: significa que las que ya existen funcionen como una red.
En La infraestructura invisible planteaba una idea que para mí es central cuando hablamos de transformación digital del Estado: ordenar no significa centralizar. No necesitamos que todos los sistemas estén en el mismo lugar, que usen la misma tecnología o que una única organización controle toda la infraestructura. Necesitamos algo bastante más difícil: que distintas capacidades, organismos y sistemas puedan funcionar como un conjunto.
Esa discusión no termina en la infraestructura tecnológica. Hay otra parte del Estado que necesita exactamente el mismo proceso de ordenamiento: la atención ciudadana.
En los últimos años construimos herramientas muy importantes. Mi Argentina se convirtió en la puerta de acceso a documentos, credenciales y servicios; TINA permitió empezar a conversar con el Estado desde una lógica mucho más simple; el Sistema Nacional de Turnos ordenó buena parte de la atención presencial; TAD digitalizó una enorme cantidad de trámites, y los organismos desarrollaron portales, aplicaciones, mesas de ayuda y canales propios. Todo eso fue un avance enorme. Pero cuanto más digitalizamos el Estado, más fuerte aparece una pregunta que todavía no terminamos de resolver: ¿qué pasa cuando algo falla?
Digitalizar también es hacerse cargo
Cuando le decimos a una persona que ya no necesita ir a una oficina porque puede hacer el trámite en forma digital, no estamos solo cambiando un canal. Le estamos diciendo confiá en este sistema: entrá por TAD, consultá a TINA, usá Mi Argentina, sacá el turno, presentá la documentación y seguí el expediente desde tu casa.
El problema aparece cuando algo no funciona. Una credencial que no aparece, un trámite que no avanza, un turno que desaparece, una integración que devuelve información equivocada, un dato sin actualizar, dos sistemas que informan cosas distintas. Para el ciudadano hay un solo problema: el Estado no está resolviendo lo que necesita. Adentro, en cambio, puede haber cinco organismos, tres aplicaciones, dos bases de datos y varias integraciones involucradas. Y ahí la aparente simplicidad digital empieza a desarmarse.
El ciudadano no conoce nuestro organigrama
Una persona no debería necesitar saber cómo está organizado el Estado para poder usarlo. Si quiere una habilitación, cobrar una prestación, renovar un documento o saber en qué está su trámite, no debería importarle qué subsecretaría administra el sistema, qué organismo genera el dato o qué dirección mantiene la API. Para esa persona existe algo mucho más simple: el Estado.
Sin embargo, cuando aparece un problema, muchas veces le trasladamos toda nuestra estructura administrativa. "Ese dato lo administra otro organismo." "Nosotros solamente mostramos la información." "Generá un reclamo en este otro sistema." Cada una de esas respuestas puede ser técnicamente correcta, pero para el ciudadano todas significan lo mismo: resolvelo vos.
El ciudadano como cadete del Estado
Hay una escena que se repite constantemente. Alguien inicia un trámite, le piden un documento que emite otro organismo, lo consigue, lo descarga y lo vuelve a subir. Después surge un inconveniente, llama, le dicen que consulte con otra dependencia, consulta, y vuelve con la respuesta al punto de partida. La administración terminó usando al propio ciudadano para mover información entre distintas partes del Estado: un cadete institucional involuntario.
La digitalización puede reducir esa situación, pero también puede reproducirla a la perfección. Podemos reemplazar la ventanilla por una pantalla y dejar intacta la burocracia: en lugar de caminar entre edificios, el ciudadano navega entre portales, formularios, correos, chats y números de reclamo. Eso no es necesariamente transformación digital. A veces es simplemente burocracia digitalizada.
Buzones sin dueño
Hay una versión de este problema que casi nadie mira: las casillas de correo. Cada organismo, dirección, programa o campaña publicó alguna vez una dirección de contacto en su sitio web. Muchas siguen ahí aunque nadie las lea, aunque el área ya no exista o aunque la persona que las respondía se haya ido hace años. Para el ciudadano, en cambio, cada una de esas direcciones es una promesa del Estado de que alguien lo va a escuchar.
Cuando esa promesa no se cumple, la persona hace lo lógico: busca otra puerta. Le escribe a otra casilla, a la cuenta del ministerio en redes sociales, al perfil personal de un funcionario, a cualquier dirección que encuentre, o a diez al mismo tiempo con copia a todas. El mismo problema termina multiplicado en lugares que no se conocen entre sí, sin que nadie lo siga de punta a punta. Algunos mensajes se pierden, otros se responden dos veces con respuestas distintas, y el Estado ni siquiera se entera de cuántas personas tienen el mismo inconveniente.
Eso también es parte del ordenamiento. Cada canal publicado tiene que tener un responsable y estar conectado al sistema, o directamente dejar de existir. Y lo que llegue por fuera de los canales formales, sea un correo perdido o un mensaje en redes, debería poder convertirse en un caso en lugar de quedar en la bandeja de alguien.
Cuando la puerta de entrada funciona demasiado bien
Hay además una paradoja: cuanto mejor funciona una plataforma transversal, más problemas termina recibiendo. TINA es un buen ejemplo. La gente le escribe porque la reconoce como una puerta del Estado, aunque lo que plantea no tenga nada que ver con TINA: una credencial que genera otro organismo, un trámite de otra jurisdicción, una base desactualizada, una integración caída. Para el ciudadano eso es irrelevante; le preguntó al Estado.
Y TINA no es solamente un asistente automático. Detrás hay operadores humanos que toman la conversación cuando el flujo automático no alcanza, y que reciben muchos de estos problemas que en realidad se originan fuera de TINA. Ahí empieza un enorme trabajo invisible de esos operadores y de los equipos de soporte: entender qué pasó, averiguar qué organismo puede resolverlo, conseguir un contacto, mandar un correo, llamar, preguntar en un grupo, encontrar a alguien que conozca a alguien, hacer seguimiento, insistir. Muchas veces el problema finalmente se resuelve. Pero hay algo que debería preocuparnos: funcionó porque las personas hicieron funcionar al sistema, no porque existiera un sistema para hacerlo.
La interoperabilidad humana
En tecnología hablamos todo el tiempo de interoperabilidad: APIs, estándares, identidad, datos, protocolos. Pero cuando algo falla, toda esa arquitectura suele terminar dependiendo de una tecnología mucho más antigua: la agenda de contactos. "Conozco a alguien ahí." "Mandámelo que averiguo." "Le escribo al responsable."
Esa red humana es valiosísima, y probablemente sea una de las razones por las que muchas cosas funcionan todos los días. Pero no puede ser nuestra arquitectura de soporte, porque entonces la calidad de la respuesta depende de quién recibió el problema y de a quién conoce. Podríamos llamarla interoperabilidad humana, y cuando se vuelve indispensable, generalmente significa que todavía falta infraestructura.
Ordenar tampoco significa centralizar la atención
La respuesta no debería ser una gigantesca mesa de ayuda nacional. Los organismos tienen conocimientos, competencias, equipos y sistemas propios, y tienen que conservar la responsabilidad sobre los servicios que prestan. Es la misma lógica que planteábamos para la infraestructura tecnológica: no necesitamos centralizar la atención; necesitamos interoperarla.
Interoperar la atención significa que un organismo pueda recibir un problema, identificar que le corresponde a otro, trasladarlo internamente con toda su historia y seguir sabiendo qué pasó. No significa que todos atiendan todo, sino que ninguna persona tenga que empezar de nuevo cada vez que cruza una frontera administrativa.
Una Red Nacional de Atención Ciudadana
Ese podría ser el próximo paso: una Red Nacional de Atención Ciudadana. No implica crear una gran mesa de ayuda centralizada ni reemplazar los sistemas que ya utiliza cada organismo. La propuesta es construir una infraestructura común de interoperabilidad para que herramientas distintas puedan intercambiar casos, estados, derivaciones y trazabilidad.
Trazabilidad común. Resolución distribuida.
Cada organismo sigue resolviendo lo que le corresponde; lo que se comparte es el seguimiento. El principio es sencillo: el ciudadano plantea el problema una vez, y a partir de ahí empieza el trabajo interno del Estado. Si el caso entró por Mi Argentina pero le corresponde a otro organismo, se deriva. Si empezó en TINA, conserva su identidad aunque después intervengan otras áreas. Si arrancó en forma presencial y sigue en forma digital, mantiene la misma trazabilidad. Si para resolverlo tienen que participar tres organismos, el ciudadano no genera tres reclamos: para él existe un único caso. Detrás, el Estado puede tener toda la complejidad que necesite. La complejidad sigue existiendo; la diferencia es que dejamos de trasladársela al usuario.
¿Qué debería compartir esta infraestructura?
- un catálogo común de servicios y organismos responsables;
- un identificador único de caso;
- estados y prioridades comunes;
- reglas de derivación y escalamiento;
- el historial del caso;
- la documentación asociada;
- el responsable actual del caso;
- niveles de servicio;
- APIs y eventos para integrar las herramientas existentes;
- una vista para que el ciudadano pueda seguir el estado de su caso.
No se trata de que todos utilicen el mismo software. Se trata de que todos puedan hablar el mismo idioma.
Una infraestructura, muchas puertas
También hay que evitar confundir sistema de atención con canal de atención. TINA puede ser un canal; Mi Argentina, TAD, un portal institucional, un teléfono, una oficina o WhatsApp pueden ser otros. Las puertas pueden ser muchas; lo que importa es lo que pasa detrás. Si alguien empieza por TINA y después llama por teléfono, el operador tiene que poder ver ese caso. Si empezó en una oficina, tiene que poder continuar en forma digital. Y si un problema afecta a miles de personas, tiene que poder identificarse como un incidente común y no como miles de consultas aisladas. Eso es infraestructura.
Puertas para todos
Pensar en muchas puertas obliga a pensar en quién puede usar cada una. Una persona ciega, alguien con una discapacidad motriz, una persona sorda o un adulto mayor que no se lleva bien con las pantallas no acceden al Estado de la misma manera, y son justamente quienes más sufren cuando el sistema los convierte en cadetes: cada derivación y cada formulario extra les cuesta mucho más que al resto.
La conversación por voz y otras formas de atención accesible pueden cambiar mucho ese escenario. Pero hay que tener cuidado: una puerta accesible que da al mismo laberinto no resuelve nada. Por eso la accesibilidad no puede ser un atributo de un canal, sino un criterio de diseño del sistema. El caso debería poder registrar, con el consentimiento de la persona, cómo necesita ser atendida, para que cada organismo que lo tome respete esas condiciones sin volver a preguntarlas. Y siempre debería existir la posibilidad de llegar a una persona.
El caso como unidad básica
El corazón de la Red debería ser un Caso Único: un identificador que sobreviva a los cambios de canal, de organismo y de sistema. No el mensaje, ni el correo, ni el ticket de una herramienta determinada, sino el caso. Un caso puede atravesar canales y organismos, acumular intervenciones y documentación, derivarse, escalarse, cerrarse y reabrirse, relacionarse con otros casos y, cuando corresponda, vincularse con la identidad de una persona, un trámite, un servicio o una credencial.
Pasar de "ticket" a "caso" parece un cambio menor, pero cambia completamente la lógica. El ticket pertenece a una mesa de ayuda. El caso pertenece a un problema que el Estado tiene que resolver.
Estado-ciudadano y Estado-Estado
Hay una segunda dimensión: los problemas de atención no existen solo entre el ciudadano y el Estado, sino también dentro del propio Estado. Un organismo consume la API de otro, una provincia usa una plataforma nacional, un municipio tiene problemas con una integración, un sistema deja de recibir datos, un operador necesita soporte sobre una plataforma transversal. Y de nuevo aparecen los correos, los teléfonos, los grupos de WhatsApp y los contactos personales.
La Red debería contemplar ambas realidades: un circuito Estado-ciudadano, para acompañar los problemas de las personas, y un circuito Estado-Estado, para organizar la asistencia, los incidentes y las integraciones entre organismos. Y el segundo no es un agregado del primero, es su condición: para que el Estado pueda darle una respuesta integrada al ciudadano, primero tiene que poder darse soporte a sí mismo.
Antes que software, responsabilidades
Antes de conectar mesas de ayuda hay que conectar responsabilidades.
El problema no es solamente tecnológico. Antes de integrar sistemas hay que poder responder quién es responsable de cada servicio, quién recibe un caso, quién puede derivarlo y quién tiene la obligación de llevarlo hasta su resolución.
Eso exige construir un catálogo de servicios del Estado. No un organigrama, sino un mapa operativo: quién presta cada servicio, quién administra sus datos, quién mantiene el sistema, quién atiende el primer nivel, quién recibe un escalamiento, qué integraciones usa y qué debería pasar cuando falla.
Los ciudadanos piensan en servicios: renovar el documento, acceder a una prestación, obtener la matrícula, saber en qué está el expediente. El Estado, en cambio, muchas veces sigue pensando en direcciones, subsecretarías y coordinaciones. Una infraestructura de atención tiene que poder traducir entre esas dos formas de mirar al Estado.
La inteligencia artificial viene después
Todo esto abre, naturalmente, una enorme oportunidad para la inteligencia artificial. Puede clasificar consultas y sugerir el área responsable, detectar casos similares e incidentes masivos, asistir a los operadores y hasta permitir que TINA acompañe automáticamente el seguimiento de un caso. También puede trabajar sobre casos individuales: resumir los antecedentes, sugerir una derivación o detectar documentación faltante. En ese uso tiene que operar siempre respetando permisos, finalidad, seguridad y trazabilidad: ver solo lo que puede ver quien atiende, usarlo solo para resolver ese caso y dejar registro de lo que hizo.
Pero aparece otra vez un principio importante: la inteligencia artificial no puede ordenar una organización que todavía no decidió cómo quiere funcionar. Primero hay que definir responsabilidades, procesos, interoperabilidad, información y niveles de servicio. Después, la tecnología puede multiplicar nuestra capacidad.
Tampoco se trata de reemplazar a las personas. La experiencia de TINA muestra que el modelo que funciona combina automatización y operadores humanos: el asistente resuelve lo que puede, y cuando no alcanza, alguien toma la conversación. Lo que el sistema tiene que garantizar es que ese pase, del asistente al operador y del operador al organismo que corresponde, ocurra sin que la persona tenga que volver a contar su problema desde el principio. El caso tiene que viajar con toda su historia.
La mesa de ayuda como sensor
Hay algo todavía más interesante. Las mesas de ayuda acumulan probablemente la información más valiosa para entender dónde falla el Estado. Cada reclamo cuenta una historia: un formulario difícil, un proceso que no se entiende, una integración que falla, un servicio mal explicado. Hoy esa información queda dispersa en herramientas, casillas y conversaciones que nadie mira en conjunto.
Si cada caso registra el servicio, el canal, los organismos por los que pasó, cuánto tardó, cuántas veces se derivó y cómo se resolvió, el Estado empieza a producir, como subproducto de su funcionamiento diario, una base de evidencia que ninguna encuesta podría igualar. Con ella se puede saber qué servicios generan más consultas, qué trámites provocan abandono, qué organismos tardan más y qué problemas se eliminarían cambiando un proceso en lugar de contratando más operadores. Es gestionar con evidencia en el sentido más literal.
Ahí la inteligencia artificial encuentra su uso más potente. Ningún equipo humano puede leer todo el volumen de conversaciones, llamadas y correos que recibe el Estado; un modelo sí puede agrupar causas que se repiten con distintas palabras, detectar un incidente cuando empieza y no cuando ya explotó, y señalar el paso exacto de un trámite en el que la gente se traba. Para este análisis general alcanza con datos anonimizados o agregados: lo que interesa es el patrón, no la persona.
Pero la idea de fondo es de gestión: la Red no sirve solo para resolver reclamos, sino para detectar qué servicios están mal diseñados. Hoy el diseño y la atención viven en mundos separados: unos construyen el trámite y otros atienden las consecuencias. Si la atención produce evidencia, cada rediseño debería empezar mirando qué casos genera ese servicio y terminar midiendo si esos casos bajaron. La atención mejora el diseño de los servicios, y el mejor caso es el que nunca tuvo que existir.
La atención también es infraestructura pública digital
Durante mucho tiempo pensamos la transformación digital como construcción de sistemas. Después entendimos que necesitábamos infraestructura común. La atención es la pieza que completa esa secuencia:
infraestructura → datos → interoperabilidad → identidad → servicios → atención → evidencia → IA/agentes
La atención también forma parte de la infraestructura digital del Estado. Los problemas que llegan a los canales de atención generan evidencia. Esa evidencia permite detectar fallas recurrentes, rediseñar servicios y, con el tiempo, incorporar IA y agentes que ayuden a anticipar problemas, clasificar casos y asistir en su resolución.
No estamos proponiendo centralizar la atención del Estado. Estamos proponiendo que toda la atención del Estado pueda funcionar como una red interoperable. No se trata de eliminar las responsabilidades distribuidas, sino de hacerlas visibles y conectarlas. No se trata de que el ciudadano entienda cómo funciona el Estado, sino de que el Estado entienda el problema del ciudadano.
La infraestructura invisible también debería servir para esto: para que, cuando algo falle, la persona no tenga que averiguar de quién es la culpa; para que pueda entrar por cualquier puerta, su problema tenga una identidad y el Estado pueda moverlo internamente hasta dar con quien debe resolverlo. Y para terminar, de una vez por todas, con una de las formas más absurdas de burocracia: usar al ciudadano como mecanismo de interoperabilidad entre las distintas partes del Estado.