Cuando una persona presenta un documento digital de otro país, comprobar que el documento es auténtico es solo el comienzo.

Supongamos que Inés, una contadora brasileña, se muda a Montevideo y necesita hacer un trámite en un portal público uruguayo. Tiene una identidad digital emitida por Brasil y un título universitario digital emitido por una universidad brasileña.

Uruguay puede comprobar la firma. Pero antes de aceptarlos necesita saber algo más: ¿quién está detrás de esa firma y por qué debería confiar en esa institución?

También necesita saber si la forma en que Brasil verificó la identidad de Inés alcanza para Uruguay y cómo pueden intercambiar información los sistemas de ambos países.

Hasta ahora, buena parte de ese trabajo se resolvía con acuerdos entre instituciones y gobiernos, integraciones específicas y listas de autoridades reconocidas. Las credenciales verificables permiten llevar una parte de esa confianza a la infraestructura digital. Ahí es donde aparece Propia.

En abril explicamos cómo un organismo puede verificar una credencial sin consultar al organismo que la emitió. Ahora vamos un paso más allá: qué necesita saber un gobierno para aceptar una credencial emitida fuera de su sistema y cómo esa confianza puede convertirse en algo que los sistemas consultan directamente.

1. Primero hay que saber quién puede emitir

Empecemos por el título de Inés.

Su universidad puede emitir una credencial digital que diga que obtuvo el título de contadora. La universidad firma esa credencial digitalmente con una clave que controla.

Cuando Inés la presenta en Uruguay, el organismo puede comprobar que la firma es válida y que el documento no fue modificado.

Pero eso todavía no responde una pregunta fundamental:

¿cómo sabe Uruguay que esa clave pertenece realmente a una universidad autorizada para emitir títulos?

La respuesta tradicional es un acuerdo o una lista de confianza. Uruguay puede mantener una lista de universidades brasileñas que reconoce, o los dos países pueden acordar qué autoridades son válidas.

El problema aparece cuando este modelo tiene que crecer. Hay más países, más instituciones, más emisores y más claves. Mantener relaciones de confianza una por una se vuelve difícil.

Propia plantea convertir esa información en una capa de confianza que los sistemas puedan consultar directamente.

En lugar de que cada verificador tenga que mantener su propia lista, Propia propone un registro público donde se pueda comprobar qué emisores están reconocidos y qué credenciales están habilitados a emitir.

Así, cuando Uruguay recibe el título de Inés, puede verificar no solo que la firma es correcta, sino también que la institución que firmó está reconocida como un emisor válido.

2. Después hay que saber qué significa “verificada”

La identidad de Inés presenta otro problema.

Brasil y Uruguay pueden tener procedimientos diferentes para comprobar quién es una persona. Un país puede verificar una identidad completamente online y otro puede requerir una comparecencia presencial, documentos oficiales o datos biométricos.

Por eso no alcanza con decir que Brasil “verificó” a Inés. Uruguay necesita saber qué controles tuvo que superar.

Los sistemas de identidad resuelven esto mediante niveles de garantía. Cada nivel representa un conjunto de requisitos que una persona tuvo que cumplir para que el sistema considere confiable su identidad.

Cuando dos países quieren reconocer identidades entre sí, tienen que establecer qué niveles aceptan.

Uruguay y Brasil ya lo hicieron. Según Agesic, Uruguay considera el nivel más alto de Brasil, llamado oro, equivalente a su propio nivel avanzado.

Eso permite que una persona con una identidad brasileña de nivel oro acceda a más de 400 servicios digitales uruguayos, bajo las condiciones de garantía acordadas entre ambos países.

En este caso, el reconocimiento sigue siendo un acuerdo entre gobiernos. Propia resuelve otra parte del problema: la confianza en las credenciales y en quienes las emiten.

Su modelo propone registros públicos que permiten comprobar quién está autorizado a emitir, qué clave controla ese emisor y cuál es el estado de una credencial.

El resultado es que la confianza deja de depender solamente de una integración directa entre el sistema que emitió el documento y el sistema que lo recibe.

3. Finalmente, los sistemas tienen que poder hablar

Hay una tercera pieza: incluso si Uruguay sabe quién emitió la credencial y confía en ese emisor, los sistemas tienen que poder intercambiarla.

Ahí entran los protocolos de interoperabilidad.

Cuando Inés inicia sesión utilizando su identidad brasileña, los sistemas de ambos países necesitan reglas comunes para pedir y entregar la información necesaria.

Su título universitario puede seguir un recorrido diferente. Inés puede tenerlo guardado en una wallet y presentarlo directamente al organismo uruguayo.

En ese caso, la wallet y el organismo necesitan protocolos compatibles para solicitar, recibir y verificar la credencial.

Entre los estándares más utilizados están OpenID4VCI, para emitir credenciales, y OpenID4VP, para presentarlas. En septiembre, la OpenID Foundation publicó las primeras implementaciones que pasaron sus pruebas públicas.

Sovra trabaja sobre estos estándares para que las credenciales puedan circular entre wallets, emisores y verificadores sin que cada integración tenga que inventar sus propias reglas. SovraID permite emitir y verificar credenciales, SovraWallet permite que las personas las almacenen y presenten, y Propia aporta la capa de confianza para verificar a los emisores y sus credenciales.

Cómo funciona con Sovra

Volvamos al título de Inés.

1. La universidad emite la credencial.
   Con SovraID, la universidad emite el título como una credencial digital firmada con su propia clave. Su estado puede actualizarse posteriormente, por ejemplo si necesita ser revocada.

2. Inés guarda la credencial.
   La almacena en SovraWallet, donde ella controla sus credenciales y decide cuándo presentarlas.

3. Uruguay recibe y verifica el título.
   El organismo inicia la presentación mediante un código QR y verifica criptográficamente la firma de la credencial. No necesita llamar a la universidad para comprobar el documento cada vez que Inés lo presenta.

4. Uruguay verifica la confianza en el emisor.
   Ahí entra Propia. El organismo puede consultar sus registros para comprobar que la universidad está autorizada para emitir esa credencial, que la clave asociada al emisor sigue siendo válida y está bajo su control.

La diferencia es importante.

La verificación de la credencial responde “¿el documento es auténtico?”. Propia agrega “¿por qué debería confiar en quien lo emitió?”.

Y lo hace sin convertir esa capa de confianza en una base de datos de personas. Los registros no necesitan guardar los datos personales de Inés ni registrar dónde presentó su título.

De acuerdos entre sistemas a infraestructura de confianza

Para que Inés pueda hacer el trámite en segundos, distintas piezas tienen que funcionar juntas: su identidad tiene que ser reconocida, la institución que emitió su credencial tiene que ser confiable y los sistemas tienen que poder intercambiar y verificar esa información.

Los acuerdos entre gobiernos siguen siendo importantes porque determinan qué identidades y qué autoridades reconoce cada país. Pero no todo tiene que resolverse mediante una integración directa entre cada par de sistemas. Una arquitectura como Propia permite llevar una parte de esa confianza a una infraestructura abierta y consultable, sin que cada organismo tenga que construir y mantener sus propias listas e integraciones.

Ese es el cambio: la credencial puede viajar con la persona, mientras que la información necesaria para confiar en ella puede estar disponible para quien tiene que verificarla.

Para seguir leyendo

• [PODCAST] Ep. 11 con Héctor Saravia: cómo el registro de Perú eligió quedar fuera de cada verificación de su DNI digital.

• Billeteras de credenciales digitales: qué cambia cuando entran en producción: lo que necesita una billetera de gobierno cuando sus documentos empiezan a circular hacia otras instituciones.

Sigamos la conversación

Nuestro centro de conocimiento en sovra.io/knowledge explica en lenguaje simple las credenciales verificables, los registros de confianza y los estándares de identidad digital, desde los conceptos básicos hasta los sistemas que ya están en funcionamiento.

¿Cómo decide tu país qué identidades extranjeras acepta? Respóndenos y cuéntanos. Leemos cada respuesta, y si alguien de tu equipo trabaja en interoperabilidad, reenvíale esta edición.

Suscríbete a The Identity Brief, publicado cada semana.

Perú ya emite su documento de identidad, el DNId, como credencial verificable: una versión del DNI firmada digitalmente que vive en una billetera en el celular llamada Perú Pass, y que cualquiera puede comprobar sin contactar a la oficina que la emitió. La billetera ya salió en Android con 63 millones de credenciales entre DNI, partidas de nacimiento y actas de matrimonio.

En la práctica, el DNId tiene el mismo valor legal que el DNI físico y es gratuito durante 2026. Para usarlo, el ciudadano muestra desde Perú Pass un código QR que se genera en el momento, elige qué datos compartir y, si pierde el celular, puede revocarlo en línea. Ya hay más de 22 instituciones que lo aceptan en programas de vivienda, becas, inclusión financiera y transporte, y según CDPI sirve incluso para renovar la licencia de conducir o entrar a Machu Picchu. La norma además deja la puerta abierta a otras billeteras que cumplan los mismos estándares, no solo a la del Estado.

En este episodio de Sovra Podcast, Lucas Jolías conversa con Héctor Saravia, Director de Certificación y Servicios Digitales de RENIEC. Antes de llegar al registro en 2023, Héctor pasó años en el sector privado intentando usar el DNI electrónico con sus clientes, así que conoce el problema desde el otro lado del mostrador: sabe lo que un banco necesita de un documento porque durante mucho tiempo fue quien lo pedía.

Lo que vas a escuchar

1. Por qué el DNI con chip no alcanzó. Perú tiene un DNI electrónico con chip desde 2013, pero casi nadie lo usó: el DNI tradicional se siguió emitiendo y era más barato. Además, bancos y empresas nunca recibieron las herramientas para leer el chip, así que para confirmar la identidad de un cliente seguían consultando a RENIEC. Héctor lo describe como un modelo de desconfianza, en el que el registro queda en el medio de cada trámite y los datos de los ciudadanos terminan copiados en muchas empresas, casi siempre desactualizados.

2. Cómo arrancó el proyecto. En 2024 el equipo empezó a estudiar otros modelos, como el europeo eIDAS 2 y el de India, pero no tenía presupuesto para construir algo nuevo. El giro llegó en un evento en El Salvador, donde Héctor conoció a Manuel Aguilera, del Centre for Digital Public Infrastructure (CDPI), una organización que ayuda a los países a implementar estos sistemas. Manuel contó su parte de la historia en nuestra conversación con Manuel Aguilera. De ese encuentro salió un piloto sobre Inji, la herramienta de código abierto de MOSIP para emitir credenciales, con el apoyo de Co-Develop y de la plataforma filantrópica VélezReyes+. El Estado puso el equipo de personas, y el proyecto tardó unos ocho meses, sobre todo por los controles de seguridad internos de RENIEC.

3. La prueba en la Amazonía. Para probar el DNId en condiciones reales, el equipo viajó en avión, en auto y en lancha río arriba hasta una zona de la selva sin conectividad, con su propia antena satelital. Ahí trabajan productores de cacao que le venden a compradores suizos, y esos compradores les entregan una credencial verificable que prueba que su tierra no fue deforestada. El sector de microfinanzas también usa su propia billetera de credenciales en la zona, y la idea era ver si el DNId funcionaba junto a ella. El obstáculo fue identificar a los productores, porque la verificación de huella fallaba: el trabajo a mano y el cordel de pesca les habían gastado las huellas. El equipo la reemplazó por biometría facial, los productores recibieron su DNId en el celular y las dos billeteras funcionaron juntas.

4. La decisión clave: la verificación no pasa por RENIEC. RENIEC emite el DNId y la prueba de autenticidad viaja dentro de la credencial, así que un banco o un comercio puede verificarla por su cuenta, sin consultar al registro. Héctor lo resume diciendo que RENIEC queda “ciego y sordo” cada vez que alguien muestra su DNI digital. Con eso se recupera la privacidad del documento físico, porque el registro nunca supo cuándo mostraste tu DNI para comprar una botella de vino, y se respeta el consentimiento que exige la ley de protección de datos personales. Explicamos cómo funciona en detalle en verificar sin consultar al emisor.

5. Qué cambia para bancos y comercios. Si RENIEC ya no responde cada consulta, la prueba de cada verificación queda en manos de quien verifica y en la billetera del ciudadano. Es lo que más cuesta explicar, y por eso RENIEC organiza bootcamps para verificadores. A cambio, el costo baja: un amigo de Héctor del sector financiero calcula que podría reducir al menos un 80% sus costos de verificación, porque pasa de pagar consultas todo el tiempo a hacer una integración una sola vez. Los trámites también se simplifican: si alguien se muda o se casa, RENIEC revoca la credencial anterior y emite una nueva, sin imprimir otra tarjeta. Lo explicamos en cómo funciona la revocación.

6. Cómo se sostiene el modelo. RENIEC cobra por las consultas, así que un sistema sin consultas obliga a buscar otros ingresos. La apuesta de Héctor es sumar verificadores: una lista de confianza que el ciudadano pueda reconocer, transacciones más rápidas para quienes estén en ella y una convocatoria abierta para que empresas de tecnología lleven la verificación a sus propios clientes. Una segunda fase, con apoyo del Banco Interamericano de Desarrollo (BID), apunta a una versión 2.0 del DNId.

Frases destacadas

“Nos encantó ese concepto de que nosotros seamos ciegos y sordos cada vez que haya una presentación de un DNI digital. Eso es lo que crearía realmente un sistema de confianza, porque nadie está metiéndose entre mi verificador y yo.”

“Ahora la carga de la prueba ya no va a estar en RENIEC, va a estar en el propio verificador y en la billetera del ciudadano.”

“El DNI digital es la solución, les vamos a hacer una biometría facial. Y nos fuimos a la selva y funcionó.”

“No perdamos el miedo al open source. Te puede dar un poco más de soberanía también a ti como país.”

Sobre el invitado

Héctor Saravia es Director de Certificación y Servicios Digitales de RENIEC, la institución que administra la identidad, el registro civil y el padrón electoral de Perú. Asumió el cargo en febrero de 2023, después de una larga trayectoria en el sector privado trabajando con clientes que querían construir sobre el DNI electrónico. Su dirección lideró el proyecto del DNI digital y de Peru Pass junto a MOSIP, CDPI, Co-Develop y VélezReyes+. Su mirada es valiosa porque estuvo en los dos lados del mostrador: sabe lo que una empresa necesita de un documento de identidad y hoy dirige el área del Estado que lo emite.

Más de Sovra

• 🎧 [PODCAST] Ep. 9: LATAM tiene todo para ganar en infraestructura digital (con Manuel Aguilera) · el lado de CDPI en esta historia: cómo Brasil e India construyeron rieles compartidos y por qué la región puede reutilizarlos.

• 🎧 [PODCAST] Ep. 10: Cómo 24 jurisdicciones argentinas construyen una agenda digital común (con Mauro Solano) · la reutilización como argumento presupuestario, contada desde las provincias.

• 📖 La Privacidad No Se Negocia · cómo un verificador comprueba una credencial sin contactar al emisor, la propiedad sobre la que RENIEC construyó su diseño.

• 📖 El ciclo de vida completo de una credencial verificable · emisión, presentación, estado y revocación, los pasos detrás del ejemplo del cambio de domicilio.

Sigamos la conversación

Conocé los estándares y los componentes detrás de estas ideas en sovra.io/knowledge, nuestro centro de conocimiento sobre identidad digital y credenciales verificables. En Sovra construimos esta capa para gobiernos: SovraID para emitir y verificar credenciales, SovraWallet para el lado del ciudadano y SovraGov para los servicios que se construyen encima. Entre todos los despliegues, ese stack ya atiende a más de 8 millones de ciudadanos, con más de 1,5 millones de identidades en más de 20 gobiernos.

Leemos cada respuesta: contanos cómo funciona la verificación en tu país hoy, ¿cada control sigue volviendo al registro? Y reenviale esta edición a alguien que trabaje en identidad en un registro civil o en un banco.

Suscribite a The Identity Brief, publicado semanalmente.

🎧 Escuchá el episodio completo en YouTube

Una billetera de credenciales digitales puede parecer simple desde el punto de vista de la persona: el Estado emite un documento, la persona lo guarda en el teléfono y lo presenta cuando lo necesita.

Pero detrás de ese gesto hay una infraestructura compleja. Cuando una credencial sale del sistema que la emitió, otro organismo, un banco o una universidad tiene que poder reconocer quién la emitió, verificar que es auténtica y comprobar que sigue vigente.

Ese es el circuito que operamos en Sovra. SovraID emite credenciales verificables. SovraWallet permite a las personas guardarlas y presentarlas. SovraGov gestiona los trámites que las producen. Y Propia, construida con LambdaClass y Aligned, aporta una capa pública de confianza para que esas credenciales puedan reconocerse entre sistemas, sin exponer datos personales ni registrar su uso. Todo esto se apoya en SovraChain.

En Nuevo León, esto ya está en producción. La billetera NLínea permite llevar documentos oficiales en el teléfono y presentarlos como credenciales digitales, dentro de un ecosistema estatal con más de 700 trámites y servicios.

La billetera se integra con el Expediente Único de NLínea, de modo que documentos como actas, permisos y contratos pueden pasar del trámite a un formato que la persona conserva en su dispositivo. El documento ya no queda solamente dentro de la ventanilla digital: también acompaña al ciudadano.

Acá te dejamos un video realizado por el gobierno de Nuevo León para mostrar su funcionamiento:

Qué cambia después de la emisión

La primera etapa es conseguir que los documentos lleguen a la billetera. La siguiente es conseguir que sean útiles fuera de ella.

En Nuevo León, el punto de partida son los documentos que ya forman parte del Expediente Único. A medida que se incorporan nuevos documentos y nuevos puntos de verificación, la misma credencial puede participar en más trámites y servicios.

Eso también cambia la lógica de las integraciones. En lugar de que cada organismo tenga que reconstruir el documento o consultar nuevamente al sistema que lo generó, la credencial puede llevar consigo la información necesaria para ser verificada. Para que esto funcione entre sistemas distintos, Propia aporta los registros públicos necesarios para reconocer autoridades, claves y estado de las credenciales.

El lanzamiento es el comienzo

Que NLínea esté en producción marca un cambio concreto: los documentos oficiales pueden llegar al teléfono de una persona y volver a presentarse desde ahí.

El paso siguiente es que esos documentos puedan ser aceptados en más lugares, sin obligar a la persona a volver al trámite original cada vez que necesita demostrar algo.

Por eso, el despliegue de una billetera no se mide solamente por cuántos documentos puede guardar. También por qué tan lejos pueden viajar esos documentos una vez que están en manos de la persona.

Sigamos la conversación

Si tu institución está trabajando en arquitecturas modulares de servicios, no dudes en ponerte en contacto.

Conceptos explicados en lenguaje simple: sovra.io/knowledge.

Suscribite a The Identity Brief, se publica semanalmente.

Para seguir leyendo

• El ciclo completo de una credencial verificable

• Cómo funciona una licencia de conducir cuando vive en el teléfono

• Qué mantiene verificable un documento cuando cambia la institución que lo emitió

• Dentro de Propia: tres registros públicos de confianza

La Lotería de Río Negro y la Lotería La Neuquina registran digitalmente sus resultados para que cualquier persona pueda comprobar que el documento publicado es exactamente el que fue emitido después del sorteo. La Lotería de San Juan será la próxima en incorporarse. Río Negro también extendió el sistema a la certificación de premios de monto alto.

Desde Sovra implementamos Sovra Trace en estos sistemas, una capa de certificación que permite registrar estos documentos y convertir los certificados de premio en credenciales digitales verificables: documentos firmados por una institución que pueden comprobarse sin tener que volver a consultar al emisor.

El documento de cada sorteo

Todas las noches, las loterías provinciales hacen sus sorteos y publican un extracto, (la lista oficial de los números ganadores). En Argentina, donde la quiniela se juega todos los días, ese documento se convierte en la referencia para revisar resultados, pagar premios y resolver reclamos.

Río Negro fue la primera lotería de Sudamérica en certificar sus resultados de esta manera y opera el sistema desde 2024. La Neuquina cuenta además con un verificador público, por lo que comprobar un sorteo no requiere pedir acceso a la institución. La Lotería de San Juan incorporará el mismo sistema próximamente.

La idea es sencilla: si alguien necesita comprobar un resultado mañana, dentro de un año o dentro de diez, puede hacerlo por su cuenta.

Cómo funciona la certificación

El extracto es un archivo. Antes de publicarlo, el sistema calcula una huella digital, llamada hash. Es una especie de identificador del archivo: si el contenido no cambia, la huella es siempre la misma. Si alguien cambia un número, una palabra o una coma, la huella cambia.

La lotería registra esa huella en SovraChain, junto con la fecha y la hora. El extracto completo sigue estando publicado por la propia lotería. En la red pública queda la huella y el momento en que fue registrada.

Para verificarlo, cualquiera puede descargar el extracto, calcular nuevamente su huella y compararla con la que quedó registrada. Si coinciden, el archivo es exactamente el mismo que se registró originalmente.

Registrar esa huella en una red pública agrega algo que una base de datos propia no puede garantizar por sí sola: el registro no depende de la infraestructura de la institución. Si con los años cambia el sistema, cambia el proveedor tecnológico o se reorganiza el organismo, el registro externo sigue existiendo y puede ser consultado por terceros.

Qué permite comprobar

La certificación tiene un alcance concreto: permite comprobar que el resultado publicado es el mismo que fue registrado y que ese registro ya existía en una fecha determinada.

La seguridad del sorteo sigue dependiendo de la máquina utilizada, los controles técnicos, el protocolo y los funcionarios responsables. Esta capa verifica lo que ocurre después: que el resultado que llegó al público no fue modificado respecto del que quedó registrado.

Si una lotería necesita corregir un resultado, registra una nueva versión con su propia huella y su propia fecha. La versión anterior no desaparece, por lo que el historial completo queda registrado y puede consultarse.

De un sorteo a un certificado de premio

Río Negro extendió el mismo mecanismo a los premios de monto alto, en juegos como Quini 6, Loto 5, Telebingo Patagónico y Pozo de la Quiniela. La persona que gana recibe un certificado y puede presentarlo ante un banco, una escribanía o un registro de la propiedad, que pueden comprobarlo por su cuenta, sin tener que comunicarse con la lotería.

El documento funciona entonces como una credencial verificable, igual que un título universitario, una matrícula profesional o una licencia de conducir digital.

Qué cambia cuando el documento es verificable

Al final, el problema es bastante simple: un documento oficial debería poder seguir demostrando lo que decía cuando fue emitido, aunque pasen los años y cambien los sistemas que lo rodean.

Río Negro ya lo aplica a resultados y certificados de premios. Neuquén, a sus resultados. San Juan está incorporándose al mismo esquema. Tres loterías, distintos usos y una misma necesidad: que la prueba quede registrada y pueda ser verificada por terceros cuando haga falta.

La confianza deja de depender de que alguien recuerde dónde estaba el documento, qué sistema lo guardaba o a quién había que llamar para comprobarlo. La prueba simplemente queda ahí.

Sigamos la conversación

Si tu institución está trabajando en arquitecturas modulares de servicios, no dudes en ponerte en contacto.

Conceptos explicados en lenguaje simple: sovra.io/knowledge.

Suscribite a The Identity Brief, se publica semanalmente.

Para leer esta semana

• Lotería de Río Negro: la ampliación de la certificación a premios de monto alto en Quini 6, Loto 5, Telebingo Patagónico y Pozo de la Quiniela.

• Lotería La Neuquina: su verificador público y las preguntas frecuentes sobre cómo comprobar un sorteo.

• Cómo funciona una licencia de conducir digital: qué cambia cuando una credencial puede llevarse en una billetera y verificarse directamente.

• El ciclo de vida de una credencial verificable: cómo se emite, se presenta y se revoca una credencial digital.

• Los tres registros públicos de Propia: cómo se comprueba la autoridad del emisor, el control de sus claves y el estado de una credencial.

• Por qué construir una infraestructura pública de confianza en abierto: el razonamiento detrás de Propia y su modelo de infraestructura abierta.

Bogotá empezó a construir su SuperApp, una plataforma única desde la que la ciudadanía va a acceder a los trámites, servicios y beneficios del Distrito.

Desde Sovra ejecutamos la capa de identidad: la billetera ciudadana, la emisión de credenciales digitales verificables, documentos digitales firmados por una institución que se pueden comprobar sin llamar a quien los emitió (cómo se emite, se presenta y se revoca una credencial de principio a fin), y el protocolo abierto que las sostiene.

Una plataforma común para un Distrito diverso

Bogotá cuenta con 62 entidades distritales y más de 1.400 trámites. Integrar esa diversidad requiere una arquitectura capaz de incorporar nuevos servicios sin que cada uno tenga que resolver otra vez los mismos problemas tecnológicos.

Por eso la SuperApp se plantea como una plataforma modular. Cada servicio puede funcionar como una MiniApp, un módulo que se integra al ecosistema mediante APIs y SDK estandarizados y que hereda capacidades comunes de autenticación, seguridad, analítica y experiencia de usuario.

Este enfoque permite que la plataforma evolucione de forma progresiva. La primera versión no necesita contener todos los trámites del Distrito para empezar a generar valor: puede incorporar capacidades concretas, ponerlas en operación y sumar nuevos servicios a medida que el ecosistema crece.

La arquitectura también contempla un orquestador de servicios, encargado de coordinar los flujos entre los módulos de la plataforma, la billetera digital y los sistemas de cada entidad. Así, la integración se vuelve una capacidad compartida en lugar de una serie de conexiones aisladas.

Cómo está construido

La SuperApp se apoya en estándares abiertos que permiten que distintas instituciones emitan, compartan y verifiquen credenciales digitales de forma segura. Desde Sovra, integramos esta infraestructura para que la identidad pueda utilizarse en diferentes servicios, sin depender de una única plataforma.

El proyecto también se enmarca en la normativa distrital sobre interoperabilidad y autenticación digital, permitiendo que las entidades se conecten bajo reglas comunes y que la solución crezca con nuevos servicios.

El control de la persona sobre sus datos se traduce en presentación voluntaria, consentimiento explícito, revocación y trazabilidad. La plataforma integra además Chatico, cumple WCAG 2.1 AA o superior, e incorpora validación biométrica con prueba de vida y autenticación presencial para población vulnerable.

Así, la identidad digital se convierte en una infraestructura pública útil para más personas, independientemente del dispositivo o sus condiciones de conectividad.

Credenciales verificables para acceder a oportunidades

El primer módulo operativo estará enfocado en la inclusión económica. A través de credenciales verificables, las instituciones podrán emitir información digital confiable que las personas podrán conservar en una wallet y presentar cuando necesiten acceder a un programa, servicio u oportunidad.

Este modelo permite reducir la repetición de trámites, facilitar la validación de información y dar a los ciudadanos mayor control sobre sus datos.

Una infraestructura preparada para crecer

La solución se basa en estándares abiertos de identidad autosoberana y credenciales verificables, con APIs, privacidad desde el diseño y capacidad de incorporar nuevos emisores, verificadores y casos de uso. También contempla la futura portabilidad de credenciales entre Bogotá y Cali.

Es el mismo tipo de apuesta arquitectónica que atravesaron, cada uno a su manera, Estonia, India y Dinamarca: cómo hacer que la identidad de una persona funcione entre instituciones, no solo dentro de una.

Con Sovra, la SuperApp de Bogotá incorpora una infraestructura de confianza que conecta instituciones, servicios y ciudadanos, y hace posible una experiencia digital más simple, interoperable y centrada en las personas.

Sigamos la conversación

Si tu institución está trabajando en arquitecturas modulares de servicios o en credenciales verificables para programas sociales, conversemos. Ponete en contacto con nuestro equipo.

Para entender mejor estos conceptos, visitá sovra.io/knowledge, donde los explicamos en lenguaje simple.

Y si querés seguir estas conversaciones, suscribite a The Identity Brief. Publicamos una nueva edición cada semana.

Vale la pena leer esta semana

• Presentamos Propia: por qué construimos infraestructura de verificación compartida en lugar de integraciones puntuales.

• sovra.io/case-studies: los otros gobiernos que ya corren este mismo stack de identidad en producción.

• El Índice de Identidad de Latinoamérica: dónde está parada hoy la identidad digital en la región.

• La transformación digital de Bogotá se acelera con respaldo de CAF: el relato oficial del Distrito sobre el programa.

• Verifiable credentials, explained: la explicación técnica del Centre for Digital Public Infrastructure sobre cómo funcionan estas credenciales.

Hace una semana publicamos Propia, una capa pública de confianza para credenciales digitales verificables, y contamos por qué la estamos construyendo como infraestructura abierta.

En resumen: hoy las instituciones vuelven a comprobar las mismas cosas una y otra vez. Las credenciales verificables permiten que una institución pueda confiar en una credencial que otra ya emitió. Pero para hacerlo necesita poder responder tres preguntas: ¿quién la emitió?, ¿estaba autorizado para hacerlo? y ¿sigue siendo válida?

Propia hace que esas respuestas estén disponibles públicamente y puedan ser verificadas por cualquiera.

Para entender cómo funciona, sigamos una situación concreta: alguien llega al mostrador de una empresa de alquiler de autos y muestra su licencia de conducir digital en el teléfono.

Qué puede comprobar el mostrador

El verificador, en este caso la persona detrás del mostrador, necesita comprobar cinco cosas:

• Integridad. La credencial no fue modificada después de ser firmada.

• Autoridad del emisor. La institución que la emitió estaba autorizada para emitir ese tipo de credencial.

• Vínculo con el titular. La persona que la presenta es quien recibió la credencial.

• Validez temporal. La credencial todavía está dentro de su período de validez.

• Estado. La credencial no fue suspendida ni revocada.

La firma digital permite comprobar que la credencial fue firmada por una determinada clave y que no fue modificada. Pero eso no alcanza para saber si esa clave pertenece a un emisor autorizado, si sigue siendo la clave válida de esa institución o si la credencial continúa vigente.

Esas son las preguntas que responden los registros públicos de Propia.

1. Registro de emisores: quién puede emitir qué

El primer registro responde una pregunta simple: ¿quién está autorizado a emitir una determinada credencial?

Una autoridad de transporte puede estar autorizada a emitir licencias de conducir en una jurisdicción, pero no títulos universitarios ni licencias en otra.

Esa autorización depende del marco de confianza correspondiente, es decir, las reglas que determinan qué instituciones pueden emitir y bajo qué condiciones.

Propia registra esas autorizaciones para que cualquiera pueda verificarlas.

La autoridad de gobernanza es quien puede modificar este registro. Esto es importante: tener una clave criptográfica no significa tener autoridad para emitir una credencial. Un registro donde cualquiera pudiera anotarse como emisor solo demostraría que controla una clave, no que está legalmente autorizado a emitir.

Leer el registro es abierto, y todos sus cambios quedan registrados y pueden auditarse.

2. Registro de identificadores: quién controla las claves

Las instituciones cambian de claves. Pueden reemplazar un dispositivo, cambiar al responsable de firmar o recuperar el control de un identificador. Eso no debería invalidar las credenciales que ya emitieron.

El registro de identificadores permite saber qué claves controla cada institución y bajo qué reglas pueden cambiar.

Así, una credencial vinculada a un identificador estable puede seguir siendo válida aunque cambie la clave que lo controla. Si está vinculada directamente a una clave de dispositivo, puede ser necesario emitirla de nuevo.

Propia puede trabajar con DIDs u otros identificadores compatibles, siempre que su control pueda verificarse de forma independiente.

3. Registro de estado: qué sigue vigente

Una licencia puede ser válida hoy y ser suspendida o revocada mañana.

El registro de estado permite que el emisor publique ese cambio. El verificador puede consultar si la credencial sigue vigente sin tener que preguntarle al emisor cada vez que se presenta.

El estado también puede mantenerse en caché para funcionar con conectividad limitada, siempre que exista una regla clara sobre cuánto tiempo sigue siendo confiable.

Y hay una diferencia importante: el registro muestra si una credencial está vigente, pero no registra dónde ni cuándo fue presentada.

La misma lógica, en otros mostradores

El alquiler de autos es solo un ejemplo. Un gobierno puede emitir una credencial de identidad, una universidad usarla para emitir un título y un colegio profesional verificar ambos antes de emitir una matrícula. Después, un empleador, un banco o un organismo público puede verificar las credenciales que necesita.

Cada institución aplica sus propias reglas, pero puede construir sobre una verificación que otra ya hizo, sin acceder a sus bases de datos ni pasar por un operador central.

Ahí aparece la composabilidad: las credenciales se convierten en piezas reutilizables de procesos institucionales, reduciendo verificaciones, manejo de documentos, revisión de fraude e integraciones.

Qué datos no se publican

Para que esta infraestructura sea pública, también importa qué información no se publica.

Las credenciales, sus claims y los datos personales permanecen bajo el control del holder. Los registros de Propia no contienen nombres, direcciones, fechas de nacimiento, fotografías, números de documento ni datos biométricos.

Tampoco registran qué credencial se presentó, dónde ni cuándo.

Lo que sí queda en el registro público es lo que cualquier verificador necesita para comprobar una credencial: quién puede emitirla, qué claves controla ese identificador y si sigue vigente.

Así, distintos verificadores pueden consultar el mismo estado público sin que cada presentación tenga que pasar por el emisor o por un operador central.

Por qué hacerlo como infraestructura pública

Si estos registros fueran una base de datos administrada por una empresa, esa empresa controlaría su disponibilidad, las actualizaciones y el estado que conserva.

Propia usa blockchain para evitar esa dependencia de un operador central.

Ethereum funciona como capa de settlement: registra los compromisos del estado aceptado y permite verificar que las actualizaciones siguieron las reglas del protocolo.

Para operar a escala, Propia propone una Layer 2 validium, que agrupa muchas actualizaciones antes de asentarlas en Ethereum y utiliza pruebas de validez para verificar que fueron ejecutadas correctamente. Los datos necesarios para reconstruir ese estado permanecen fuera de Ethereum, lo que reduce costos pero hace que su disponibilidad sea una responsabilidad de cada despliegue.

Blockchain no crea la autoridad institucional. Un gobierno sigue decidiendo quién puede emitir una credencial, y una universidad sigue siendo responsable de sus títulos. Propia representa ese estado de confianza; no lo crea.

El objetivo

El objetivo no es poner la identidad en una blockchain, sino separar los datos privados de una credencial del estado público necesario para verificarla.

Los estándares hacen que las credenciales puedan viajar entre sistemas. Propia agrega los registros públicos que permiten verificar quién puede emitirlas, qué claves controla cada identificador y si siguen vigentes.

Así, una verificación puede convertirse en un insumo para otra institución, en lugar de volver a empezar de cero.

Sigamos la conversación

Si tu institución está trabajando en emisión, verificación o revocación de credenciales digitales, respondé este correo y contanos dónde se pone difícil.

Suscribite a The Identity Brief, que se publica semanalmente.

Para seguir leyendo

• El whitepaper de Propia: la especificación completa del protocolo.

• The full lifecycle of a verifiable credential: cómo funciona una credencial desde su emisión hasta su revocación.

• How the mobile driver’s license works: qué hay detrás de una licencia de conducir digital.

• W3C Verifiable Credentials Data Model 2.0: el estándar de credenciales sobre el que se apoya el modelo.

Propia es una capa pública de confianza para credenciales digitales verificables, desarrollada en colaboración entre Sovra, LambdaClass y Aligned.

El whitepaper se encuentra publicado en inglés en propia.id/whitepaper. Versión en español disponible acá:

Propia Whitepaper (Español)

540KB ∙ PDF file

Download

Descargá el whitepaper de Propia y conocé su arquitectura y propuesta para la verificación abierta de credenciales digitales.

Download

El whitepaper describe cómo funciona Propia. Este artículo explica por qué creemos que hace falta.

Por qué estamos publicando Propia

A medida que los gobiernos digitalizan identidad, licencias, títulos, registros y otros documentos oficiales, aparece un problema que no se resuelve solamente con mejores credenciales: cada institución necesita una forma confiable de saber quién puede emitirlas, bajo qué autoridad y si siguen siendo válidas.

Hoy, esa confianza suele resolverse mediante consultas directas, integraciones entre sistemas o acuerdos entre instituciones. Es un modelo que puede funcionar en pequeña escala, pero que se vuelve cada vez más difícil de sostener cuando participan cientos de organismos, distintos proveedores y múltiples jurisdicciones.

Propia parte de una tesis sencilla: las instituciones no necesitan compartir sus bases de datos ni adoptar las mismas reglas para poder confiar unas en otras. Necesitan una infraestructura común que permita verificar esa confianza de forma independiente.

A partir de esa idea, Propia propone una arquitectura abierta para que gobiernos e instituciones puedan mantener su propia autoridad y sus propios sistemas, mientras comparten una forma común de verificar emisores, credenciales y estado.

El problema de fondo

Las instituciones verifican los mismos hechos una y otra vez. Una persona que ya fue identificada por el Estado puede tener que presentar información similar ante una universidad, un banco, un empleador o cualquier otro organismo, y cada verificación puede requerir nuevas integraciones, consultas al emisor y copias de datos.

Las credenciales verificables permiten reutilizar esa verificación. Una institución autorizada puede comprobar un hecho y emitir una credencial firmada que luego puede ser presentada ante otros verificadores, quienes pueden comprobar su autenticidad, el emisor y su estado actual sin volver a consultar al emisor en cada ocasión.

Pero para que esto funcione a escala queda una pregunta fundamental: ¿cómo sabe un verificador que una institución está autorizada para emitir una determinada credencial y que esa autorización sigue vigente?

Una infraestructura común, sin centralizar la autoridad

Los estándares abiertos ya definen cómo emitir, firmar y presentar credenciales. Lo que no resuelven por sí solos es cómo verificar quién está autorizado a emitirlas, bajo qué reglas, qué claves controla y cuál es su estado actual.

Propia proporciona esa infraestructura común. Las credenciales y los datos personales permanecen entre emisores, titulares y verificadores, mientras el estado público permite comprobar de forma independiente las autorizaciones, las claves y el estado de las credenciales.

Esto reduce la dependencia de consultas directas al emisor, evita integraciones duplicadas y permite que una institución pueda utilizar una credencial emitida por otra sin acceder a sus sistemas internos.

Interoperabilidad sin perder soberanía

Una jurisdicción no necesita adoptar las reglas de otra para que sus credenciales puedan verificarse fuera de sus fronteras. Un gobierno puede emitir una credencial de identidad, una universidad utilizarla para emitir un título y un organismo regulador utilizar ambas para emitir una habilitación, mientras cada institución mantiene sus propios criterios y responsabilidades.

La infraestructura común permite que esas credenciales puedan componerse en procesos de otras instituciones sin crear una nueva integración para cada relación.

Diseñada como infraestructura abierta

Una infraestructura que puede permanecer en uso durante décadas no debería depender de un proveedor, una aplicación o una administración.

Por eso Propia plantea especificaciones e implementación abiertas, verificación independiente, derecho de salida y gobernanza transparente. La blockchain se utiliza para hacer verificable el estado común de los registros, no para almacenar credenciales ni datos personales.

El código se publica próximamente: cualquiera podría auditarlo, ejecutarlo y comprobar por sí mismo que la implementación cumple con lo especificado.

Propia se publica como una propuesta abierta, no como un producto cerrado. Queremos discutirla, mejorarla y construir sobre ella junto a los gobiernos, organismos públicos, universidades, reguladores y proveedores que van a emitir y verificar las credenciales del futuro.

Ponete en contacto!

Para seguir leyendo

• El ciclo de vida completo de una credencial verificable — emisión, presentación y revocación, de punta a punta.

• Cómo una credencial verificable sobrevive a su emisor — el problema de continuidad que atienden los registros.

• Cómo funciona la licencia de conducir móvil — el perfil ISO 18013-5 en la práctica.

• Muchos de estos conceptos explicados en lenguaje simple: sovra.io/knowledge.

Cuando un gobierno empieza a diseñar un programa de identidad digital, los mismos casos aparecen una y otra vez: Estonia como modelo, India como prueba de escala, los países nórdicos como ejemplo de un sistema que la gente usa todos los días.

Los tres funcionan. Y, sin embargo, toman decisiones muy distintas sobre casi todo lo que importa: quién emite la identidad, quién opera la infraestructura, quién la financia y qué ocurre con quien decide no usarla.

Ahí está lo interesante. No hay un modelo único que copiar. Cada país decidió qué problema resolver primero, y esa decisión terminó definiendo el resto del sistema.

Por eso, entender qué priorizó cada uno puede ser mucho más útil que intentar importar cualquiera de estos modelos entero.

Estonia: el Estado emite y el Estado opera las vías

Estonia convirtió la identidad en una obligación estatal y construyó la capa de intercambio a la medida. La cédula electrónica es obligatoria para ciudadanos y residentes desde 2002, y la tiene cerca del 99% de la población. Alrededor del 90% de los estonios usa servicios digitales de manera habitual, el 98% de las declaraciones de impuestos se presenta online y prácticamente todo el catálogo de servicios públicos está disponible las 24 horas.

Lo que menos se copia, y más importa, es X-Road: la capa de intercambio que permite a los organismos consultar directamente los registros de los demás, con cada consulta registrada y atribuible. Gracias a eso el principio de una sola vez se vuelve exigible en lugar de quedar en declaración: si la agencia tributaria le consulta al registro de población, nadie tiene que llevar un certificado de un mostrador a otro. Hoy X-Road está desplegado en más de veinte países, y es el componente más fácil de trasladar de todo el modelo estonio.

La apuesta: un país chico y con alta confianza institucional puede imponer una credencial estatal y aun así conseguir adopción casi universal.

Lo que costó: obligar sale caro en términos políticos, y es justamente la pieza que peor se exporta. Además da por sentado un registro de población lo bastante prolijo como para construir encima, que es un punto de partida mucho más exigente de lo que parece.

La lección que sí se traslada es arquitectónica antes que política, y la conversamos con Gustavo Giorgetti en nuestro episodio sobre el federalismo como ventaja de interoperabilidad: si X-Road funciona no es porque Estonia sea centralizada, sino porque la capa de intercambio transporta institucionalidad. Las provincias argentinas están armando ecosistemas equivalentes sin un Estado unitario que los imponga.

India: primero la escala, después las capas

India invirtió el orden. En vez de arrancar por una credencial y un marco legal, arrancó por la base más grande posible de identidad única y verificable, y dejó todo lo demás como capas para sumar después. Aadhaar ya cubre a más de 1.440 millones de residentes, y la autenticación corre a un volumen sin antecedentes: más de 27.000 millones de operaciones en un solo ejercicio fiscal.

Esa base terminó siendo el piso de India Stack: pagos (UPI, que movió 21.700 millones de operaciones solo en enero de 2026), circulación de documentos sin papel (DigiLocker, eSign) y datos compartidos con consentimiento. El criterio de diseño es tratar la identidad como infraestructura y no como producto: una vía pública sobre la que construyen servicios privados, y por eso la capa de pagos escaló como escaló.

La apuesta: llegar a todos con la credencial más liviana posible rinde más que una credencial más completa que alcanza a menos gente.

Lo que costó: los debates de privacidad y exclusión que arrastra una base biométrica centralizada siguen abiertos, y buena parte del trabajo posterior consistió en agregarle consentimiento, minimización y límites de propósito a un sistema que no nació con eso. Cuando la escala va antes que la gobernanza, la gobernanza se termina instalando a los golpes.

La lección que sí se traslada es la disciplina de capas: identidad, pagos e intercambio de datos como vías separadas sobre las que puede construir cualquiera. Manuel Aguilera, del Centre for Digital Public Infrastructure, planteó exactamente eso para la región en por qué América Latina tiene todo para ganar si deja de construir sola, y PIX en Brasil es la prueba más clara de que el modelo por capas funciona acá.

Dinamarca: los bancos ya estaban ahí

Dinamarca se hizo otra pregunta: ¿dónde prueba la gente quién es, todas las semanas, sin que haya que insistirle? La respuesta fue el home banking, así que el sistema danés nació como alianza público-privada con los bancos. MitID tiene unos 5,5 millones de usuarios registrados, cerca del 87% de los adultos daneses lo usa al menos una vez por semana y la app promedió 3,3 millones de usuarios activos por mes en junio de 2026. Sirve para impuestos, historia clínica y servicios públicos, y también para banca y seguros privados: por eso se usa todas las semanas y no una vez al año.

Ahora Dinamarca está dando el paso siguiente. En junio de 2026 lanzó AltID, una de las primeras billeteras oficiales de identidad digital de la Unión Europea, que guarda la cédula y un certificado de edad en el propio dispositivo y no en un repositorio central. La adopción recién arranca —unas 230.000 descargas a fines de julio, cerca del 4% de la base de MitID— y lo que importa es hacia dónde va, porque mueve la prueba de edad y de identidad al teléfono, con el dato en manos del ciudadano. De ese cambio hablamos en nuestra edición de junio sobre verificación de edad sin exponer la identidad.

La apuesta: la adopción viene detrás de la utilidad cotidiana, así que el camino más corto a una identidad nacional pasa por donde la gente ya está.

Lo que costó: compartir la gobernanza con instituciones privadas, y depender de un sector bancario lo bastante concentrado y cooperativo como para sentarse en la mesa como una sola contraparte. Donde hay cientos de instituciones dispersas, esa alianza es mucho más difícil de armar.

Qué sirve en América Latina y qué no

✅ Sirve: la capa de intercambio. Los tres sistemas funcionan porque los organismos se consultan entre sí en lugar de mandar al ciudadano a hacer de cadete. Es el componente de mayor valor, cuesta mucho menos en términos políticos que una credencial nacional obligatoria, y una provincia o un municipio puede empezar sin esperar una ley nacional.

✅ Sirve: pensar la identidad como infraestructura por capas. Tratar identidad, pagos e intercambio documental como vías separadas sobre las que construyen servicios privados fue lo que convirtió la inversión india en un ecosistema. Brasil consiguió el mismo efecto con PIX.

✅ Sirve: diseñar para el uso cotidiano. La lección danesa es la más barata de aplicar y la que más se pasa por alto. Una credencial que se usa una vez al año para impuestos nunca llega a ser infraestructura, así que conviene preguntarse temprano a qué trámite semanal puede engancharse el sistema.

❌ No sirve: copiar la obligatoriedad. La adopción estonia se apoya en una obligación legal y en un nivel de confianza institucional que no se consigue por decreto. Copiar la obligación sin la confianza deja los costos de cumplimiento y ninguna de las ventajas.

❌ No sirve: centralizar biometría ahora y gobernar después. Arreglarlo más tarde sale caro y el costo político se acumula. La región tiene la ventaja de llegar cuando esa lección ya está aprendida, y la generación actual de estándares permite esquivarla: una credencial que porta el ciudadano, que se presenta de a partes, con el emisor verificable y sin amontonar datos personales en ningún lado.

Lo verdaderamente nuevo es que ninguno de estos tres modelos hace falta copiarlo. Los tres se construyeron antes de que las credenciales verificables maduraran como estándares ratificados, y cada uno resolvió con centralización o con obligación legal lo que hoy se resuelve con criptografía. Una jurisdicción que arranca hoy puede tener el “una sola vez” estonio sin la obligatoriedad estonia, y el alcance indio sin la base central india, porque la credencial viaja con el ciudadano y cualquier oficina la verifica por su cuenta. De ese efecto acumulativo hablamos en cómo se potencian entre sí las capas de un stack de confianza.

Vale la pena leer esta semana

El plazo de la billetera de identidad digital europea es la historia a seguir de acá a fin de año. Cada Estado miembro tiene que ofrecer al menos una billetera certificada antes del 24 de diciembre de 2026, y las evaluaciones actuales ubican a menos de un tercio en condiciones de cumplirlo. AltID, en Dinamarca, es uno de los primeros casos en vivo, así que su curva de adopción es hoy el mejor dato público disponible sobre cómo responde la gente cuando le ofrecen una billetera de verdad.

El Digital Government Outlook 2026 de la OCDE, primera edición del informe, mide a 36 países con la misma progresión por etapas que ilustran estos tres casos: el Digital Government Index promedio subió de 0,61 a 0,70 entre 2023 y 2025, con el 74% de los componentes centrales de infraestructura pública digital ya implementados. Su recomendación principal —exigir o incentivar con fuerza el uso de bloques compartidos en lugar de proyectos aislados por organismo— es la lección arquitectónica estonia convertida en política pública.

La Base de Conocimiento de Gobierno Electrónico de la ONU sigue siendo la mejor forma gratuita de ubicar a cualquier país contra dos décadas de datos comparables antes de decidir de qué modelo conviene tomar prestado.

Continuá la conversación

Más sobre credenciales verificables, gestión documental e infraestructura pública digital, con casos y arquitecturas de referencia, en sovra.io/knowledge.

Si en tu jurisdicción están eligiendo entre estos modelos ahora mismo, respondé este mail y contanos hacia cuál los están empujando y por qué.

Suscribite a The Identity Brief, sacamos ediciones todas las semanas.

Un acto administrativo, una resolución, un permiso o una notificación, es la unidad de trabajo del Estado. Si el término te resulta nuevo, hace poco publicamos una guía sobre qué es un expediente electrónico y cómo se implementa.

Cuando presentamos la arquitectura de registros estructurados y firmados sobre la que está construido GDE2 de SovraGov, explicamos por qué los gobiernos deberían dejar atrás el PDF como formato nativo.

En esta edición vamos un paso más abajo: qué se almacena realmente, dónde vive esa información, cómo se busca, cómo se verifica y qué hace posible que el sistema funcione a escala de gobierno.

El acto como texto firmado

En GDE2, un acto administrativo se almacena como texto estructurado firmado, no como un PDF. Cada acto es un documento Markdown liviano con el contenido, sus metadatos y una firma digital separada del documento.

La firma se calcula sobre una versión normalizada del texto, de modo que cualquier modificación invalida la firma. Los funcionarios firman desde su billetera de identidad digital utilizando la misma infraestructura de certificados X.509 que los gobiernos ya utilizan.

El documento con validez legal es el texto firmado. Cuando una norma requiere un PDF, GDE2 lo genera a demanda. El PDF pasa a ser una representación; el texto firmado sigue siendo el original.

Dónde vive la información

GDE2 utiliza PostgreSQL 18 para almacenar los metadatos, el estado del expediente, la trazabilidad y el hash SHA256 de cada acto. El documento firmado se guarda en un almacenamiento de objetos y se referencia mediante ese hash. El PDF solo se genera cuando hace falta.

Todas las operaciones se ejecutan dentro de una única transacción. Escribir el acto, registrar la firma, actualizar el expediente y vincular documentos ocurre todo junto o no ocurre en absoluto.

El resultado es un registro confiable donde el contenido y los metadatos pueden consultarse directamente.

Una búsqueda que lee todo el archivo

Como los actos administrativos están almacenados como texto, su contenido completo puede indexarse y buscarse de forma nativa. Encontrar cláusulas, montos o expedientes relacionados lleva segundos, incluso sobre años de archivo.

GDE2 también incorpora búsqueda semántica, que recupera documentos por significado y alimenta al asistente de redacción con antecedentes y normativa relevante.

Una verificación que no depende del sistema original

Un documento administrativo no debería depender de que el sistema que lo creó siga existiendo para poder ser verificado.

Cada acto en GDE2 incorpora una firma digital CAdES sobre un hash SHA256. Cualquier persona con el documento, la firma y la cadena de certificados puede comprobar su integridad y autoría de manera independiente.

Cuando se requiere una prueba de existencia a largo plazo, el acto firmado también puede anclarse en SovraChain mediante una marca de tiempo verificable públicamente.

Esto permite que el documento conserve sus propiedades de confianza incluso cuando cambian las plataformas tecnológicas.

La verificabilidad independiente resulta especialmente importante en un país federal, donde cada jurisdicción toma sus propias decisiones tecnológicas. Lo conversamos con Mauro Solano al analizar cómo las 24 jurisdicciones argentinas construyeron una agenda digital compartida: un documento que cualquier sistema puede verificar por sí mismo es, por definición, un documento interoperable.

Diseñado para operar a escala de gobierno

Los sistemas públicos tienen una característica particular: no funcionan con una carga constante. Los picos de demanda aparecen alrededor de vencimientos, campañas o eventos específicos.

GDE2 está diseñado para soportar millones de operaciones concurrentes sin perder capacidad de respuesta.

El entorno de ejecución aísla fallas, ejecuta tareas secundarias de forma independiente y mantiene toda la infraestructura versionada y reproducible. Esto permite despliegues más confiables y previsibles.

Pero una arquitectura no se valida solo en un diagrama.

Por eso medimos GDE2 sobre expedientes reales de producción, comparando las mismas operaciones bajo ambos modelos.

El resultado fue consistente: 10 veces más rendimiento, con los mismos actos administrativos, las mismas firmas digitales y la misma validez jurídica, pero sobre una base mucho más eficiente.

Sigamos la conversación

La transformación central de GDE2 no es solamente reemplazar PDFs. Es cambiar la unidad fundamental del sistema: pasar de archivos que se almacenan a documentos que pueden entenderse, buscarse y verificarse.

Cuando un acto administrativo nace como información estructurada, el Estado puede hacer más con los mismos datos: mejorar la búsqueda, automatizar procesos, aplicar inteligencia artificial con contexto y construir interoperabilidad entre jurisdicciones.

Ese es el cambio de arquitectura detrás de GDE2.

Más sobre firmas digitales, credenciales verificables y anclaje en blockchain en sovra.io/knowledge.

Si estás evaluando la modernización de tu sistema documental o de expedientes, contáctanos.

Suscríbete a The Identity Brief, publicado todos los jueves.

En la mayoría de los países federales, los servicios que marcan la vida diaria de un ciudadano dependen de gobiernos subnacionales. En Argentina, salud, educación y seguridad están en manos provinciales, lo que significa que la calidad de la administración provincial impacta de manera directa en cómo viven decenas de millones de personas. Cuando la conversación gira hacia la transformación digital, sin embargo, la atención suele concentrarse en plataformas nacionales, y el nivel de gobierno más cercano a esos sistemas críticos suele ser el último en recibir coordinación, financiamiento o una hoja de ruta compartida.

Las provincias argentinas decidieron construir esa coordinación por su cuenta. FederAI reúne a las 23 provincias y la Ciudad de Buenos Aires alrededor de una agenda común de transformación digital, convocada desde el tercer sector con la academia, organismos internacionales y el ecosistema govtech en la misma mesa. Su premisa toma la lógica central de la infraestructura pública digital: los sistemas fundamentales para prestar servicios, identidad, intercambio de datos y pagos, funcionan mejor y cuestan menos cuando se construyen para ser compartidos, la tesis que nuestro Ep. 9 con Manuel Aguilera exploró a escala regional.

En este episodio de Sovra Podcast, Lucas Jolías conversa con Mauro Solano, Director Ejecutivo de Espacios Políticos y coordinador de la secretaría técnica de FederAI. Politólogo que pasó años dentro de la administración de la provincia de Buenos Aires, dirigió el INAP (Instituto Nacional de la Administración Pública) durante más de tres años y lideró el programa de Estado y Gobierno de CIPPEC, Mauro conoce la capacidad provincial desde adentro, desde el nivel nacional y desde la sociedad civil. Ese triple punto de vista hace que su relato de la transformación subnacional sea inusualmente concreto: habla en mesas de trabajo, estándares y ciclos de quince días antes que en manifiestos.

Lo que vas a escuchar

1. Por qué las provincias son donde la transformación digital más importa

El punto de partida de Mauro es estructural: los grandes sistemas públicos que más afectan la vida de las personas, salud, educación y seguridad, son responsabilidad provincial en Argentina. Que esas administraciones funcionen bien o mal recae directamente sobre los ciudadanos. Su carrera volvió una y otra vez a las provincias, desde la secretaría de modernización bonaerense que lanzó las primeras guías de trámites y sistemas de pago, hasta una red federal de capacitación construida desde el INAP que conectó a los responsables de innovación y empleo público de todas las jurisdicciones. Esa red fue la semilla de lo que hoy es FederAI.

2. Un espacio de coordinación sin primus inter pares

Argentina tuvo consejos federales donde las provincias alineaban su agenda de modernización, primero el COFEFUP (Consejo Federal de la Función Pública) y luego el COFEMOD. Cuando ese espacio dejó de funcionar, las provincias quedaron sin lugar de encuentro. FederAI recrea la función con otra arquitectura: convocado desde el tercer sector, cada jurisdicción se sienta como propietaria en pie de igualdad de la agenda, y la secretaría técnica trabaja detrás de escena para que sean las propias provincias las que definan las prioridades. La membresía también es deliberadamente más amplia, con la Universidad de Buenos Aires, el laboratorio de inteligencia artificial y desarrollo humano de la UNSAM, CAF, el CLAD, el sector privado y el ecosistema govtech. Una coordinación multisectorial de este tipo sigue siendo rara en América Latina, y funciona con un ritmo de trabajo concreto: reuniones cada quince días, entregables puntuales, quick wins.

3. Construir lo que está debajo de la IA

Las tres primeras mesas de trabajo surgieron de lo que las provincias efectivamente pedían: interoperabilidad e integrabilidad, inteligencia artificial y simplificación administrativa. Lo valioso es la secuencia. Todos los gobiernos querían hacer algo con IA, y el primer movimiento del grupo fue mirar la capa de abajo: gobernanza de datos, interoperabilidad y la forma en que se diseñan los trámites. Después llegaron dos mesas más, una que fusionó simplificación con identidad digital (donde participa Sovra) y otra de ciberseguridad junto a la Fundación Sadosky. Es la misma dependencia que mapeamos en What Agentic Government Requires: la inteligencia en la superficie presupone infraestructura debajo.

4. La advertencia: no tecnologizar la buropatología

La frase más filosa de Mauro nombra un modo de falla que todo veterano de la modernización conoce. Si un estado agrega tecnología a procesos que funcionan mal, solo consigue que la disfunción corra más rápido. La simplificación, en su planteo, viene antes que la automatización: revisar cómo administra el estado antes de cablearle inteligencia encima. Las mesas de trabajo tratan los mejores y peores experimentos provinciales con IA como material de aprendizaje compartido, para que cada jurisdicción pueda ver cuándo conviene un caso de uso, y con qué resguardos, antes de gastar.

5. La reutilización cambia la conversación presupuestaria

La objeción clásica a la innovación pública es que no hay plata. La respuesta de la DPI es la reutilización. Hoy varias provincias construyeron cada una su propio sistema de identidad digital, y un ciudadano validado en una provincia arranca de cero en la siguiente, una experiencia que el Ep. 8 con Gustavo Giorgetti recorrió a nivel del intercambio de datos. Infraestructura compartida significa que la inversión de la provincia A se convierte en el punto de partida de la provincia B, en lugar de su gasto duplicado. Mauro enmarca el argumento de fondo en clave constitucional: el federalismo argentino se fundó en pactos preexistentes entre provincias, y acordar estándares mínimos de identidad digital, pagos e intercambio de datos honra esa lógica original. El ciudadano nunca debería cargar con la complejidad institucional, porque en todas las encuestas la conclusión es la misma: para el ciudadano, el estado es uno solo.

6. Las dos tensiones de los próximos años

Consultado sobre hacia dónde van las provincias, Mauro primero aclara lo heterogéneos que son sus puntos de partida, y después nombra dos tensiones compartidas. La primera es transformarse en medio de la aceleración: los estados provinciales acumularon capas de administración patrimonial, burocracia weberiana y nueva gerencia pública, y hoy enfrentan ciudadanos cuyas expectativas las fijaron interacciones mucho más ágiles con el sector privado y el tercer sector. La segunda es la brecha creciente de confianza entre ciudadanía y estado, visible en cualquier encuesta nacional o internacional. Su argumento optimista es que ambas tensiones se pueden atacar con el mismo movimiento, usando la infraestructura pública digital como diagonal, un catalizador que mejora capacidades y reconstruye legitimidad a la vez. Debajo de eso, señala la cuestión del talento: cómo los estados provinciales atraen, retienen y forman personas para un mundo donde el cambio es la constante.

Citas destacadas

“Los grandes sistemas de gestión pública que afectan la vida de los ciudadanos, salud, educación y seguridad, están en manos de las provincias. Es ahí donde se juega gran parte de la suerte de la vida de las personas.”

“No estaríamos haciendo otra cosa que tecnologizar la buropatología: hacer que lo que funciona mal lo haga además más rápido con la tecnología.”

“Las provincias se encuentran convocadas desde el tercer sector sin un primus inter pares. Todas en pie de igualdad, todas igual de propietarias de la agenda.”

“Para el ciudadano, el estado es uno solo. Es muy difícil pretender que ande pensando si se enfrenta al estado municipal, provincial o nacional, y qué credencial llevar para cada uno.”

“En esa necesidad de transformarse y de achicar esa brecha, la infraestructura pública digital es una oportunidad enorme para tomar una diagonal, hacer de catalizador y empezar a resolver esas dos tensiones a la vez.”

Sobre el invitado

Mauro Solano es Director Ejecutivo de Espacios Políticos y coordina la secretaría técnica de FederAI, el foro que reúne a las 23 provincias argentinas y la Ciudad de Buenos Aires alrededor de una agenda común de transformación digital. Politólogo, pasó años en la administración de la provincia de Buenos Aires trabajando en modernización del estado, dirigió el INAP durante más de tres años, donde creó el programa federal de capacitación pública, y lideró el programa de Estado y Gobierno de CIPPEC. Su mirada es distintiva porque manejó la maquinaria que hoy ayuda a coordinar: lee la transformación subnacional como una cuestión de capacidades, secuencia y confianza entre pares, anclada en lo que los equipos provinciales pueden ejecutar de verdad.

Más de Sovra

• 🎧 [PODCAST] Ep. 9: América Latina tiene todo para ganar en infraestructura digital (con Manuel Aguilera) — la versión regional de este argumento: la DPI como rieles compartidos que toda la economía reutiliza.

• 🎧 [PODCAST] Ep. 8: De Estonia a Argentina (con Gustavo Giorgetti) — la capa de interoperabilidad en la práctica: cómo las provincias argentinas se federaron con X-Road.

• 📖 What Agentic Government Requires — la dependencia que descubrieron las mesas de Mauro: la IA en la superficie necesita infraestructura debajo.

• 📖 The Full Lifecycle of a Verifiable Credential — la mecánica de emitir una vez y verificar en todas partes, el patrón del que depende la reutilización de identidad entre provincias.

Sigamos la conversación

Explorá los estándares y componentes detrás de estas ideas en sovra.io/knowledge, nuestro hub de identidad digital y credenciales verificables. Sovra construye la capa que esta conversación señala todo el tiempo: SovraID para credenciales verificables que permiten que la validación de una provincia viaje a la siguiente, y SovraGov para la capa de servicios encima. Entre despliegues, ese stack ya sirve a 8M+ ciudadanos con 1.5M+ identidades en 20+ gobiernos.

Leemos todas las respuestas, así que contanos cómo funciona la coordinación entre jurisdicciones donde operás. Reenviá esta edición a alguien que trabaje en gobierno provincial o estadual.

Suscribite a The Identity Brief, publicado todos los jueves.

🎧 Escuchá el episodio completo en YouTube

The Identity Brief es publicado semanalmente por Sovra, el Digital Identity Stack para el mundo institucional.

Un expediente electrónico es el conjunto ordenado de todas las actuaciones de un trámite público — solicitudes, informes técnicos, dictámenes jurídicos, resoluciones — en formato digital estructurado, firmado digitalmente y con trazabilidad completa.

Tiene la misma validez legal que su equivalente en papel, con una diferencia operativa central: los sistemas pueden buscarlo, verificarlo y operar sobre él en segundos. El Banco Interamericano de Desarrollo estimó en El fin del trámite eterno que un trámite presencial cuesta hasta 40 veces más que el mismo trámite completado en línea. Cerrar esa brecha es exactamente para lo que están construidas plataformas como SovraGov Gestión de Expedientes 2, que hoy opera en implementaciones que sirven a más de 8 millones de ciudadanos en más de 20 gobiernos.

Digitalizado y digital son dos cosas distintas

Escanear un expediente en papel produce una colección de imágenes: el archivo se puede abrir, pero ningún sistema puede leer qué contiene, quién firmó qué, ni en qué estado está el trámite.

Un expediente electrónico nace digital: cada actuación es un documento estructurado que los sistemas pueden interpretar, cada firma es una firma digital verificable criptográficamente y cada movimiento queda registrado. Esa distinción — el expediente como documento estructurado y firmado, no como contenedor de imágenes — es lo que separa un archivo digitalizado de un gobierno digital.

La regla práctica: el pasado se escanea, el futuro nace electrónico.

Expediente electrónico vs. gestor documental

Un gestor documental almacena y recupera archivos. Un sistema de expediente electrónico hace algo más estricto: garantiza la secuencia ordenada de las actuaciones, preserva una cadena de firmas ininterrumpida entre organismos y expone el estado de cada trámite a otros sistemas. Si en su evaluación hay gestores documentales genéricos, esta es la línea divisoria a testear: ¿puede el sistema decirle — programáticamente — en qué estado está un trámite, quién firmó cada paso y demostrar que nada fue alterado?

Cómo implementar un expediente electrónico: los cuatro pasos

1. Marco normativo

Antes que la tecnología, la validez: una norma (decreto, ley provincial u ordenanza) que reconozca al expediente electrónico y a la firma digital como equivalentes al papel. La mayoría de los países de la región ya tiene legislación de firma digital vigente; el trabajo suele ser adherir o reglamentar, más que legislar desde cero.

2. Estructura documental y firma

Definir el formato de cada actuación (un documento estructurado con metadatos: tipo, fecha, autor, organismo) y el esquema de firma — el estándar habitual es firma electrónica avanzada en cada actuación. Este paso determina todo lo que viene después: un formato bien elegido mantiene el expediente buscable, auditable y automatizable por décadas.

3. Interoperabilidad

Un expediente cruza organismos: mesa de entradas, revisión técnica, área legal, firma final. La implementación necesita un mecanismo para que sistemas distintos lean y agreguen actuaciones sin romper la cadena de firmas — APIs públicas documentadas y un registro único de trámites.

4. Migración gradual

Las implementaciones que funcionan arrancan con dos o tres trámites de alto volumen, prueban el circuito completo (ingreso digital → tramitación → resolución firmada → notificación) y expanden desde ahí. El papel histórico se digitaliza como archivo consultable; el flujo nuevo nace electrónico desde el día uno. La guía de transformación digital del BID recomienda exactamente esta secuencia: marco, piloto, escala.

SovraGov GDE 2 cubre los cuatro pasos de fábrica — firmas con validez legal, documentos estructurados, APIs entre organismos y un circuito piloto probado. Véalo en vivo en una demo de 30 minutos →

Preguntas frecuentes

¿Un PDF firmado es un expediente electrónico? Un PDF firmado es un documento electrónico válido, pero un expediente es más que un documento: es la secuencia ordenada de todas las actuaciones con su trazabilidad. Cuando esa secuencia vive en carpetas de PDFs, los sistemas no pueden operar sobre ella; el expediente electrónico la estructura para que sí puedan.

¿Tiene la misma validez legal que el papel? Sí, en las jurisdicciones con legislación de firma digital vigente — la enorme mayoría de la región hoy. La validez surge de la norma más la firma verificable, el mismo principio detrás del ciclo de vida de una credencial verificable.

¿Cuánto tarda una implementación? Un piloto que cubra dos o tres trámites de alto volumen puede estar operativo en meses, no en años; expandir al inventario completo de trámites es gradual y depende del volumen y la normativa de cada organismo.

¿Qué pasa con los expedientes en papel existentes? Se digitalizan como archivo histórico consultable. La regla práctica: el pasado se escanea, el futuro nace electrónico.

¿Hay que reemplazar los sistemas existentes? No. La capa de interoperabilidad (paso 3) existe precisamente para que los sistemas existentes lean y agreguen actuaciones vía APIs. Reemplazar es opcional; integrar es el requisito.

Agendar una demo

Vea a SovraGov GDE 2 correr un circuito de expediente en vivo — del ingreso digital a la resolución firmada — en 30 minutos. Es la misma plataforma que hoy opera para más de 8 millones de ciudadanos con más de 20 gobiernos.

Agendar una demo →acá

¿Todavía no está evaluando? Más guías y explicaciones en sovra.io/knowledge.

Suscribite a The Identity Brief — se publica semanalmente.

▶ Esta pieza incluye videos de producto cortos. ¿Preferís verlo en vivo? Agendá una demo y te mostramos el recorrido completo.

Cada resolución, notificación y pase interno es un documento. Sin embargo, en la mayoría de los gobiernos esos documentos siguen siendo PDFs: archivos pensados para imitar el papel, pesados de almacenar, difíciles de buscar y costosos de procesar o verificar con el paso del tiempo.

Sovra GDE2 — Gestión Documental propone un modelo distinto. Cada acto administrativo nace como un documento de texto estructurado y firmado digitalmente: liviano, completamente buscable, legible tanto para personas como para sistemas, y vinculado criptográficamente con su autor mediante una identidad digital verificable.

Ese cambio tiene consecuencias importantes. Los archivos ocupan mucho menos espacio, la búsqueda funciona sobre el contenido real de los documentos, la IA puede asistir en la redacción y el análisis, y cada documento firmado sigue siendo verificable incluso cuando el sistema que lo generó ya no existe.

Qué hace diferente a GDE2

En lugar de generar archivos binarios, GDE2 almacena cada acto administrativo como texto estructurado (Markdown), junto con sus metadatos y una firma digital independiente (detached). El documento es el texto; la firma lo acompaña.

Esto habilita cuatro capacidades fundamentales:

• Búsqueda profunda. Buscá dentro del contenido completo de cada documento, no solo por número o metadatos.

• Archivos mucho más livianos. El texto estructurado reduce significativamente el espacio de almacenamiento frente a los formatos tradicionales.

• Versionado y automatización sencillos. Comparar versiones, extraer información o automatizar procesos deja de depender de herramientas especializadas.

• Una plataforma preparada para escalar. Diseñada para soportar grandes volúmenes de trabajo sin degradar la experiencia de uso.

Un flujo de trabajo familiar

El módulo de documentos fue pensado para que cualquier operador pueda empezar a usarlo desde el primer día. La experiencia recuerda a una bandeja de correo: borradores, enviados, pendientes de firma y firmados.

Creá un documento desde una plantilla, asigná revisores y firmantes, enviá documentos a firma de forma individual o masiva y seguí cada paso mediante una traza completa de auditoría.

IA que entiende el expediente

El asistente integrado ayuda a redactar comunicaciones y actos administrativos utilizando como contexto tanto el expediente como la normativa aplicable, recuperando y citando automáticamente los artículos relevantes.

Cada borrador sigue el circuito habitual de revisión y firma. La IA asiste; la decisión sigue siendo humana.

Además, la plataforma es independiente del proveedor de IA. Puede utilizar servicios administrados o modelos abiertos ejecutándose completamente dentro de la infraestructura del propio organismo.

Firma digital con identidad verificable

Un documento público debe seguir siendo confiable muchos años después de haber sido emitido.

Por eso GDE2 utiliza firmas digitales CAdES sobre el contenido del documento, con certificados X.509, manteniendo plena equivalencia jurídica con la firma de un PDF.

La autenticación y la firma se realizan mediante SovraID y SovraWallet, utilizando identificadores descentralizados (DID) y credenciales verificables. De forma opcional, los documentos también pueden anclarse en SovraChain, permitiendo verificar su integridad y autoría incluso cuando el sistema original ya no está operativo.

Construido para gobiernos

GDE2 — Gestión Documental es uno de los servicios insignia de SovraGov, junto a Ventanilla, con la identidad funcionando como capa transversal debajo de ambos. La infraestructura sobre la que está construido ya opera a escala institucional: más de 8M de ciudadanos alcanzados, más de 1,5M de identidades, y más de 20 gobiernos, con SovraID habiendo emitido más de 10M de credenciales detrás de más de 50M de verificaciones y más de 100M de llamadas de API. En el programa “Burocracia Cero” de Nuevo León, los trámites digitalizados corrieron 80% más rápido con aproximadamente 30% menos de burocracia.

La forma más fácil de entender GDE2 es verlo con tus propios documentos. Agendá una demo y recorremos juntos el modelo documental, la búsqueda, el asistente de IA y el flujo de firma, de punta a punta.

Sigamos la conversación

Para la biblioteca completa de explicaciones sobre identidad, credenciales e infraestructura institucional, visitá sovra.io/knowledge.

Respondé con las preguntas que te dejó — leemos cada respuesta, y las preguntas de los lectores dan forma a las próximas ediciones. Si un colega que trabaja en gestión documental o gobierno digital lo encuentra útil, reenviáselo.

Suscribite a The Identity Brief — se publica todas las semanas.

Durante la mayor parte de la historia de la web, confirmar la edad de un visitante significaba marcar un botón que decía “Soy mayor de 18”. Ese botón no pedía nada y no probaba nada, y un conjunto creciente de leyes hoy lo considera insuficiente.

En marzo de 2026 entró en vigor el ECA Digital de Brasil — el Estatuto da Criança e do Adolescente Digital, Lei 15.211/2025 — y, según el Senado de Brasil, exige mecanismos confiables de verificación de edad en cada acceso, dejando expresamente de lado la simple autodeclaración (vedada a autodeclaração) para contenido no apropiado para menores. La obligación alcanza a redes sociales, juegos, apps y mensajería, tiendas de aplicaciones, sistemas operativos y plataformas de video, y pide que los sistemas operativos y las tiendas de aplicaciones transmitan una señal de edad confiable a las aplicaciones a través de una interfaz segura.

La ley es deliberadamente neutral respecto de la tecnología — fija el requisito y deja abierto el método. Esa es la parte interesante para quien construye sistemas de identidad, porque los métodos obvios entran en tensión entre sí. Pedirle a cada usuario que suba un documento de identidad a cada sitio satisface la ley y crea exactamente el tipo de registro vinculado a la identidad que los regímenes de protección de datos buscan evitar. Las propias instituciones de Brasil notaron esta tensión: como recoge el análisis legal reunido por Migalhas, el Ministerio Público Federal y la autoridad de protección de datos ANPD señalaron enfoques que preservan la privacidad construidos sobre credenciales verificables, y la ANPD estableció principios mínimos — proporcionalidad, exactitud, protección de datos — que un método conforme debería cumplir.

Esta edición trata sobre la arquitectura que responde bien la pregunta: cómo una billetera digital puede establecer que alguien tiene edad suficiente sin revelar quién es ni cuándo nació.

Tres formas de responder la misma pregunta

Hay, a grandes rasgos, tres formas de confirmar que un visitante es mayor de 18, y difieren enormemente en lo que revelan.

La primera es la autodeclaración — el viejo botón. No revela nada porque no verifica nada.

La segunda es la presentación de documento: el usuario sube un pasaporte o una licencia de conducir, o se somete a un escaneo facial, a menudo a través de un proveedor externo. Esto verifica de forma efectiva, y además transfiere un registro de identidad completo — nombre, número de documento, fecha de nacimiento completa, fotografía — a una parte que solo necesitaba saber una cosa. Cuando ese registro se conserva, se convierte en un activo permanente que hay que proteger.

La tercera es una credencial de divulgación selectiva. El usuario tiene una credencial emitida por una autoridad de confianza — un organismo de identidad del gobierno, por ejemplo — dentro de una billetera digital, y la billetera libera solo el atributo que una interacción dada requiere. Ante la pregunta de si su titular es mayor de 18, la billetera responde esa pregunta, y solo esa pregunta. Este es el modelo en torno al cual se organizaron los organismos de estándares, y la versión fundacional es la que cubrimos en nuestra edición del 23 de abril sobre el ciclo de vida completo de una credencial verificable: una credencial se emite una vez, la tiene la persona y se presenta muchas veces, decidiendo el titular cada vez cuánto compartir.

Cómo una billetera prueba “mayor de 18” — y cómo una prueba de conocimiento cero va más allá

La divulgación selectiva ya reduce lo que se comparte de un documento entero a un solo campo. Las pruebas de conocimiento cero lo reducen todavía más: permiten a una billetera probar una afirmación sobre un atributo sin revelar el atributo mismo.

Una prueba de conocimiento cero, como explicó con una licencia de conducir nuestra edición de febrero sobre pruebas de conocimiento cero, descansa en dos propiedades. La solidez significa que el titular no puede producir una prueba válida de una afirmación falsa — una persona menor de 18 no puede generar una prueba de que es mayor de 18. El conocimiento cero significa que la prueba no revela nada más allá de la verdad de la afirmación. Aplicado a la edad, la billetera prueba el predicado “la fecha de nacimiento es de hace más de 18 años” y devuelve un sí verificable, mientras la fecha de nacimiento permanece en la billetera. La Electronic Frontier Foundation, al describir el mismo mecanismo, señala que una persona puede confirmar que está por encima de un umbral sin mostrar un documento de identidad ni siquiera revelar su edad exacta.

Esto ya no es teórico. En julio de 2025, Google liberó como código abierto una implementación de prueba de conocimiento cero para verificación de edad, publicada bajo licencia abierta en github.com/google/longfellow-zk, diseñada para funcionar con el formato de documento móvil ISO mDoc y con W3C Verifiable Credentials, de modo que un titular pueda probar que es mayor de cierta edad sin revelar su fecha de nacimiento ni su identidad.

Los estándares por debajo, y la UE como referencia en funcionamiento

La razón por la que estas pruebas viajan entre un emisor del gobierno, la billetera de un ciudadano y un sitio web es un stack de estándares compartido, el mismo que este newsletter ha seguido a lo largo de varias ediciones. Las atestaciones de edad se expresan usando el modelo de atributos de ISO/IEC 18013-5, el estándar de Licencia de Conducir Móvil en el corazón de nuestra edición del 14 de mayo sobre cómo funciona la licencia de conducir móvil, junto con W3C Verifiable Credentials. Se presentan a un sitio web a través de la W3C Digital Credentials API y de OpenID for Verifiable Presentations (OpenID4VP), el protocolo que permite a un navegador solicitar un atributo específico y a una billetera responder con una respuesta verificable.

La referencia pública más desarrollada es la solución de verificación de edad de la Unión Europea. Según la Comisión Europea y su portal oficial de verificación de edad, la Comisión puso a disposición un blueprint el 14 de julio de 2025 y una solución lista para usar el 15 de abril de 2026, con un piloto en curso entre varios Estados miembros pioneros antes de una disponibilidad más amplia, y la solución construida sobre las mismas especificaciones que la EUDI Wallet que se despliega en la UE hacia fines de 2026. El Manual de Verificación de Edad de la Comisión documenta el stack con precisión: el modelo de datos de prueba de edad se basa en el esquema de atributos de ISO/IEC 18013-5, la presentación corre sobre la W3C Digital Credentials API y OpenID4VP, y se está agregando soporte de pruebas de conocimiento cero para que un titular pueda probar un umbral — adaptable a 13, 18, 65 y otros — sin revelar ningún atributo adicional.

Brasil y la UE llegan así a la misma respuesta arquitectónica desde puntos de partida legales distintos: una credencial que el ciudadano tiene, un único atributo liberado a pedido, y estándares abiertos por debajo para que la prueba sea portable.

Dónde encaja Sovra

Esta es la arquitectura sobre la que Sovra ya construye. La verificación de edad bien hecha es una aplicación específica de una capacidad general: un gobierno o autoridad de confianza emite una credencial verificable, el ciudadano la tiene en una billetera, y solo se libera el atributo que una interacción dada necesita. Sovra emite y verifica credenciales exactamente sobre los estándares abiertos en los que corre esta conversación — W3C Verifiable Credentials, ISO 18013-5 y OpenID4VP.

En la práctica eso se mapea a dos capas. SovraID es el lado del verificador — la infraestructura que una institución o plataforma usa para solicitar y comprobar un único atributo, como una afirmación de mayoría de edad. SovraWallet es el lado del ciudadano — donde vive la credencial y desde donde se hace la divulgación selectiva — con la integridad de la credencial anclada a través de SovraChain. Una prueba de mayor de 18 es una nueva presentación de un tipo de credencial que esta arquitectura ya está diseñada para soportar, más que un sistema separado por levantar. La forma más directa de entender la divulgación selectiva es verlo en vivo.

Para las instituciones de toda América Latina que observan cómo el marco de Brasil entra en vigor, la lectura práctica es que el camino respetuoso de la privacidad hacia el que apuntan los reguladores — credenciales verificables con divulgación selectiva — está construido sobre estándares abiertos, compartidos y ya operativos.

Para leer esta semana

• De The Identity Brief — las ediciones que fundamentan la mecánica de arriba: Zero-Knowledge Proofs Explained With Your Driver’s License (la criptografía detrás de un “sí” que no revela nada más), How the Mobile Driver’s License Works (14 de mayo, la familia de credenciales ISO 18013-5 usada para atestaciones de edad), The full lifecycle of a verifiable credential (23 de abril, el modelo emitir-tener-presentar) y What Agentic Gov Requires (21 de mayo, divulgación selectiva en un marco institucional más amplio). La base de conocimiento completa de Sovra está en sovra.io/knowledge.

• Fuentes primarias sobre las reglas — el resumen del Senado de Brasil sobre la entrada en vigor del ECA Digital y, para el debate de implementación, el análisis de Migalhas sobre la verificación de edad en el ECA Digital.

• La implementación de referencia de la UE — la página de política de verificación de edad de la Comisión Europea, el portal oficial para desarrolladores de verificación de edad y el Manual de Verificación de Edad de la UE con el stack de estándares completo.

• La criptografía y sus límites — la biblioteca de código abierto de Google longfellow-zk para verificación de edad con conocimiento cero, el W3C Verifiable Credentials Data Model 2.0 y la nota mesurada de la EFF sobre por qué las pruebas de conocimiento cero por sí solas no son una solución completa de privacidad para la identidad digital.

Continuemos la conversación

Más sobre divulgación selectiva, el stack de credenciales verificables y cómo se construye una prueba de mayor de 18 en formatos W3C e ISO 18013-5 está disponible en sovra.io/knowledge.

Si tu plataforma o institución está trabajando los requisitos de verificación de edad — en Brasil, en América Latina o alineada al modelo de la UE — y evaluando cómo podría encajar una credencial de divulgación selectiva, respondé. Leemos cada respuesta.

The Identity Brief es publicado semanalmente por Sovra, el Stack de Identidad Digital para el Mundo Institucional.

La infraestructura pública digital, o DPI, replantea una pregunta que los gobiernos vienen respondiendo mal hace dos décadas. En lugar de digitalizar cada servicio por separado, pregunta qué capas compartidas puede usar todo el mundo para construir encima. La imagen más clara es una autopista: un gobierno no la pavimenta solo para los vehículos del Estado, sino para el tránsito público y privado por igual, y lo que circula encima no pertenece todo a quien tendió la ruta. La DPI aplica esa lógica a la identidad, los pagos y el intercambio de datos, los rieles fundacionales sobre los que corre una economía digital.

En este episodio de Sovra Podcast, Lucas Jolías conversa con Manuel Aguilera, Líder Regional para América Latina y el Caribe en el Centre for Digital Public Infrastructure (CDPI), un centro de asesoría con sede en el IIIT de Bangalore, India. Sociólogo que llegó al gobierno digital desde las políticas públicas, Manuel asesora a los gobiernos manteniéndose deliberadamente agnóstico a la tecnología, sin venderles nada, y eso es justamente lo que hace valiosa su mirada: lee la IPD como una cuestión de instituciones e incentivos primero, y de tecnología después. La conversación recorre cómo tomó forma el paradigma, por qué las restricciones de India produjeron su claridad, dónde lidera realmente América Latina y qué tiene que resolver la región en los próximos cinco años.

Lo que vas a escuchar

1. DPI no es gobierno digital con otro nombre

Durante años los gobiernos digitalizaron procesos, trámites y portales. DPI agrega una capa diferente: infraestructura compartida que puede ser reutilizada por gobiernos, bancos, startups y cualquier actor de la economía digital. Manuel explica por qué el cambio más importante no es tecnológico sino conceptual: pasar de digitalizar instituciones a digitalizar mercados.

2. La lección de India: diseñar para la complejidad

La narrativa moderna de DPI nace en India, un país con cientos de idiomas, enormes desigualdades y desafíos de escala sin precedentes. Frente a esa complejidad, la apuesta no fue construir grandes sistemas centralizados sino componentes mínimos que resolvieran identidad, pagos e intercambio de datos. El resultado es una arquitectura que hoy inspira implementaciones alrededor del mundo.

3. Brasil está construyendo algunos de los casos de uso más avanzados del planeta

Pix ya transformó los pagos digitales. Pero Brasil ahora está avanzando sobre una nueva frontera: verificación de edad preservando privacidad. La nueva regulación obliga a plataformas que venden alcohol o contenido para adultos a verificar atributos de los usuarios sin exponer más información de la necesaria. Es uno de los experimentos más ambiciosos de infraestructura pública digital aplicada a internet abierta.

4. Las credenciales verificables están dejando de ser pilotos

Perú lanzará este año un DNI digital basado en credenciales verificables. Brasil avanza en la misma dirección. República Dominicana está construyendo identidades digitales para empresas. Lo que durante años fue una conversación de estándares empieza a convertirse en infraestructura nacional utilizada por millones de personas.

5. América Latina tiene un problema de integración, no de innovación

La región creó más organismos de integración que casi cualquier otra parte del mundo, pero sigue teniendo bajos niveles de comercio intrarregional. Para Manuel, la próxima etapa de DPI consiste en resolver exactamente ese problema: permitir que títulos universitarios, licencias de conducir, identidades digitales y credenciales puedan verificarse automáticamente entre países.

6. El futuro es una infraestructura regional de confianza

La pregunta ya no es si cada país tendrá identidad digital o credenciales verificables. La pregunta es si esas credenciales funcionarán más allá de las fronteras nacionales. El gran desafío de los próximos cinco años será construir las autopistas digitales que permitan mover personas, datos y servicios entre países con el mismo nivel de confianza con el que hoy funcionan dentro de cada jurisdicción.

Citas clave

“Si el gobierno va a construir una solución digital, no debería pensarla solo para los trámites estatales. Tiene que pensarla para toda la economía digital.”

“No alcanza con digitalizar el gobierno. Hay que digitalizar la economía.”

“Brasil es uno de los países que está pensando algunos de los casos de uso más avanzados de infraestructura pública digital del mundo.”

“La gran pregunta es si la transición hacia una economía digital va a ser inclusiva o si va a crear los nuevos monopolios tecnológicos.”

“América Latina tiene todo para ganar, pero necesita mejorar la integración regional.”

Sobre el invitado

Manuel Aguilera es el Líder Regional para América Latina y el Caribe en el Centre for Digital Public Infrastructure (CDPI), un centro de asesoría con sede en el IIIT de Bangalore que ayuda a los gobiernos a diseñar e implementar IPD manteniéndose deliberadamente agnóstico a la tecnología. Sociólogo con una Maestría en Administración Pública por University College London, llegó al campo desde las políticas públicas y no desde la ingeniería. Antes de CDPI cofundó Impacto Digital, una organización de civic-tech que construye tecnología para los derechos humanos en América Latina, y ha asesorado a organismos como UNESCO y la Comisión Interamericana de Derechos Humanos. Su mirada distintiva es institucional: lee la IPD como una cuestión de incentivos, neutralidad y quién puede construir, antes que como una cuestión de arquitecturas.

Más de Sovra

• 🎥 Manuel Aguilera: IPD e Interoperabilidad (Gov3 Summit 2025) — la charla del propio invitado, una profundización del argumento de interoperabilidad regional que está en el centro de este episodio.

• 🎧 [PODCAST] Ep. 8: De Estonia a Argentina (con Gustavo Giorgetti) — la capa de interoperabilidad debajo de la visión regional de Manuel, y cómo las provincias argentinas se federaron a través de X-Road.

• 🎧 [PODCAST] Ep. 7: De la digitalización a la infraestructura (con Aura Cifuentes) — la brecha de adopción a la que vuelve Manuel: identidades emitidas, papel todavía en la billetera.

• 📖 Cómo funciona la licencia de conducir móvil — el estándar de credencial detrás de “una licencia que se verifica en cualquier país”.

• 📖 El ciclo de vida completo de una credencial verificable — cómo la tecnología que Brasil está pilotando emite, custodia y verifica la confianza.

Seguí la conversación

Explorá los estándares y bloques de construcción detrás de estas ideas en sovra.io/knowledge, nuestro hub sobre identidad digital y credenciales verificables. Sovra construye la capa de infraestructura que describe esta conversación, desde SovraID para credenciales verificables hasta SovraChain para la capa de confianza debajo de la verificación transfronteriza.

Suscribite a The Identity Brief, que publicamos todos los jueves.

🎧 Escuchá el episodio completo en YouTube

El expediente es la columna vertebral de la gestión estatal. Cada resolución, cada pase y cada comunicación oficial existe dentro de uno. Son millones de actuaciones por año, en cada jurisdicción.

La primera generación de gestión documental electrónica resolvió un problema concreto: reemplazar el papel. Y lo hizo bien. En gran parte de América Latina, esos sistemas alcanzaron una madurez operativa real y se convirtieron en infraestructura crítica del Estado.

Pero la pregunta que enfrenta esta década es distinta:

¿Qué es un documento administrativo cuando nace digital?

No responder esta tiene un costo creciente. La Oficina de Rendición de Cuentas del Gobierno de Estados Unidos (GAO) documentó que el 80% del presupuesto tecnológico federal se consume en operar y mantener sistemas existentes. Los sistemas heredados terminan cobrando una renta permanente sobre la capacidad de innovar.

Nuestra respuesta se resume en tres afirmaciones:

1. La validez jurídica vive en la firma sobre el contenido; el formato es apenas un medio de representación.
Las leyes de firma digital de la región, inspiradas en el modelo UNCITRAL, y marcos como eIDAS exigen propiedades —integridad, autoría, certificación y trazabilidad—, no formatos de archivo.

2. Un documento que nace digital funciona mejor como dato firmado que como una imagen firmada.
Es más eficiente para buscar, procesar, archivar e interoperar, con exactamente la misma validez legal.

3. La integridad del documento resuelve solo la mitad del problema de confianza.
La otra mitad es demostrar quién lo firmó. Esa capa es identidad verificable.

Lo que cambia en la práctica

Menos infraestructura, más capacidad

El contenido real de un pase administrativo ocupa apenas unos pocos kilobytes. Cuando ese mismo acto se encapsula como PDF firmado, el archivo puede multiplicar su tamaño decenas de veces.

A escala estatal, esa diferencia cambia la economía completa del sistema. Una jurisdicción media puede pasar de consumir terabytes de almacenamiento por año a apenas una fracción de ese volumen. Menos almacenamiento, menos cómputo, menos servidores y menor dependencia de software especializado.

Sistemas que resisten los picos

Los sistemas administrativos viven de cierres, vencimientos y campañas. La diferencia entre una arquitectura moderna y una heredada no se ve en el promedio, sino en los momentos de máxima demanda.

Diseñado sobre tecnologías de concurrencia masiva, el sistema degrada de forma gradual ante cargas extraordinarias. Para quien trabaja en una oficina pública, esa diferencia es simple: entre “el sistema está lento” y “el sistema no funciona”.

Expedientes que pueden entenderse

Cuando el documento nace como dato estructurado, deja de ser una imagen para convertirse en información utilizable.

Eso habilita búsqueda full-text sobre todo el corpus, recuperación semántica de antecedentes relacionados, comparación entre versiones y asistencia para redactar borradores basados en normativa y expedientes reales, siempre bajo revisión y firma humana.

El expediente deja de ser un archivo para convertirse en una fuente de conocimiento institucional.

“¿Y cuando me piden el PDF?”

La arquitectura que proponemos separa el contenido de su representación visual.

Cada actuación existe como dato firmado, acompañado de sus metadatos y protegido mediante firma digital emitida por las mismas infraestructuras de certificación que operan hoy en cada país. La prueba jurídica sigue siendo la misma: integridad, autoría, certificación y trazabilidad.

Cuando un organismo o sistema externo necesita un PDF, este puede generarse a demanda. El PDF pasa a ser una representación; la evidencia jurídica permanece en la firma sobre el dato.

El resultado es un modelo más eficiente para procesar, más simple para archivar y mejor preparado para interoperar durante las próximas décadas.

No hay que tirar nada

La objeción más seria a cualquier modernización no es técnica: es el riesgo de tocar lo que ya funciona.

Por eso esta evolución no exige un reemplazo de un día para el otro. En los países federales de la región, la discusión ocurre provincia por provincia: cada jurisdicción decide su propio camino. Lejos de ser una limitación, esa diversidad permite modernizar de manera gradual y controlada —empezando por un trámite, una ventanilla, un tipo de actuación—, como conversamos con Gustavo Giorgetti en nuestro podcast.

Cómo lo construimos en Sovra

Esta es la arquitectura sobre la que construimos Gestión Documental y Ventanilla dentro de SovraGov.

La identidad verificable aporta la prueba de autoría. Las credenciales verificables permiten validar firmantes institucionales. Y el anclaje criptográfico aporta prueba independiente de existencia y tiempo.

Como planteó Aura Cifuentes en nuestro podcast, el momento de infraestructura pública digital de América Latina no puede esperar. Y el expediente es uno de los lugares donde esa oportunidad se vuelve más visible.

La forma más directa de evaluar esta tesis es verla operar: probá una demo web sobre un expediente real, de principio a fin.

Sigamos la conversación

Más sobre firmas digitales, credenciales verificables y divulgación selectiva en sovra.io/knowledge.

Si estás evaluando la modernización de la gestión documental o de expedientes en tu provincia, respondé este correo. Leemos cada respuesta.

Suscribite a The Identity Brief, que se publica semanalmente.

La próxima semana comienza la Copa Mundial de la FIFA 2026 en México, Estados Unidos y Canadá. Más allá del espectáculo deportivo, el torneo pondrá a prueba una de las capacidades más exigidas de la economía digital actual: verificar la edad y la identidad de millones de personas en tiempo real.

La razón es simple: el crecimiento de las apuestas online.

Un estudio reciente de Jumio, realizado entre 8.003 personas en cuatro países, encontró que México lidera la intención de apostar durante el torneo, con un 43% de los encuestados. Además, se espera que una parte importante de esos usuarios participe por primera vez. Al mismo tiempo, el 63% de las personas consultadas teme que menores de edad accedan a estas plataformas, mientras que el 74% considera que la responsabilidad de verificar la edad recae tanto en las plataformas como en los proveedores tecnológicos que las hacen posibles.

Durante las próximas semanas, millones de personas deberán demostrar que cumplen los requisitos para participar, en cuestión de segundos y en momentos de máxima demanda. Esta edición analiza cómo hacer posible esa verificación a gran escala sin crear nuevos riesgos de privacidad en el proceso.

La forma del problema

Durante un Mundial, una plataforma de apuestas enfrenta tres desafíos simultáneos: una avalancha de usuarios nuevos, la obligación legal de verificar que cada persona es mayor de edad y elegible, y una ventana de apenas segundos antes de que un usuario abandone el proceso.

La presión es real. Para muchos aficionados, apostar ya forma parte de la experiencia de seguir un torneo internacional, y la expectativa pública es clara: impedir el acceso de menores. El verdadero desafío ocurre detrás de escena: no está en procesar apuestas, sino en verificar identidades con rapidez, precisión y seguridad cuando la demanda alcanza niveles extraordinarios.

El costo de la verificación tradicional

El enfoque más común sigue siendo pedir a cada usuario una copia completa de su documento de identidad o pasaporte, que la plataforma verifica y luego conserva para cumplir con requisitos regulatorios y de auditoría.

Esa decisión de diseño tiene consecuencias. Primero, introduce fricción en el momento más delicado del recorrido del usuario, aumentando el abandono incluso entre personas legítimas. Segundo, ofrece una protección limitada frente al uso de documentos prestados o compartidos. Y tercero, obliga a las plataformas a almacenar grandes volúmenes de información altamente sensible, convirtiéndolas en objetivos atractivos para el fraude y las filtraciones de datos.

En muchos casos, las organizaciones terminan protegiendo información que nunca necesitaron conservar.

Verificar la edad sin almacenar documentos

Existe otra forma de responder la única pregunta relevante —si una persona cumple con los requisitos de edad y elegibilidad— sin que la plataforma tenga que almacenar el documento que respalda esa información.

Una credencial verificable, emitida por una fuente confiable como un gobierno o una entidad financiera, puede permanecer en la billetera digital de la persona, bajo su control y en su propio dispositivo.

Mediante mecanismos de divulgación selectiva (SD-JWT), el usuario comparte únicamente la información necesaria para la transacción. La plataforma recibe una prueba criptográfica de que la persona cumple con la condición requerida y puede verificarla a través de una API como SovraID, sin acceder al resto de los datos de la credencial.

En lugar de almacenar una copia del documento, conserva únicamente la evidencia de que la verificación fue realizada correctamente.

Confía una vez. Úsalo en todas partes.

Para América Latina, ser sede de un evento de esta magnitud representa una oportunidad poco frecuente para demostrar que la identidad digital moderna no es una promesa futura, sino una infraestructura disponible hoy.

La tecnología ya está lista. Lo que falta es decidir cómo utilizarla.

¿Querés profundizar?

• Explorá /knowledge — ensayos primer sobre identidad verificable

• SovraWallet — la credencial que lleva el ciudadano · SovraID — la API de la confianza digital · SovraChain — el ancla de confianza verificable

• Leé el whitepaper de Sovra

• Ediciones anteriores: Cómo está hecho Sovra · Las pruebas de conocimiento cero explicadas con tu licencia de conducir · ¿Qué pasa después de emitir una credencial verificable?

• La investigación: Estudio Jumio 2026 · Análisis de Biometric Update · Infografía de Jumio

La base — SovraChain

En la base del stack se encuentra SovraChain, la infraestructura verificable construida como Based Rollup sobre Ethereum (Ethrex, de LambdaClass), operando en modo Validium para que los datos personales nunca toquen una cadena pública — solo las pruebas criptográficas. El resultado: garantías criptográficas heredadas de Ethereum L1, costos optimizados para escala nacional (~$0,0002 por transacción a 1.000+ TPS) y sin depender de un proveedor central.

La mayoría de las instituciones que adoptan Sovra — y la mayoría de los ciudadanos que llevan su identidad digital — nunca tendrán que pensar en SovraChain directamente.

SovraChain hace el trabajo de confianza para que las capas superiores puedan concentrarse en experiencia, interoperabilidad y operación.

La capa de credenciales — SovraID (la API) y SovraWallet (la app ciudadana)

Encima de SovraChain se encuentra la capa de credenciales, materializada en dos productos que comparten los mismos estándares y garantías criptográficas.

SovraID es la API de confianza digital — la plataforma que emite, gestiona y verifica credenciales para cualquier gobierno o institución. Construida sobre W3C Verifiable Credentials, ISO mDL, OpenID4VCI y OpenID4VP, permite desplegar una capa de identidad reutilizable, y la verificación funciona sin necesidad de consultar nuevamente al emisor.

SovraWallet es donde el ciudadano porta sus credenciales. Una app nativa iOS + Android, con identidad anclada en un passkey almacenado en el Secure Enclave del dispositivo (WebAuthn / FIDO2) y un wallet smart-contract en SovraChain vía EIP-7702 — para que las credenciales permanezcan en el dispositivo del ciudadano, con pruebas criptográficas generadas localmente para cada presentación. Con divulgación selectiva (SD-JWT) integrada: una persona puede demostrar lo que es cierto (elegibilidad, edad) sin exponer los datos subyacentes.

Podés probar cómo funciona este flujo con nuestra DEMO web.

La capa de IA — SovraRAG

Sobre la misma infraestructura de identidad se encuentra SovraRAG, el agente conversacional con IA para gobiernos e instituciones. Indexa el conocimiento institucional real — PDFs, espacios de Confluence, páginas web, APIs internas — y responde a ciudadanos y funcionarios con citas trazables hasta el documento original. Ya operativo en más de 7 implementaciones en producción, con cobertura multilingüe (ES/EN/PT-BR) y con soporte multicanal (sitio institucional, portal ciudadano, WhatsApp).

El principio: la IA no inventa. Si el documento no lo dice, SovraRAG tampoco. Para un gobierno que atiende 24/7, esa es la diferencia entre un chatbot y un asistente institucional.

Los cuatro módulos de gobierno — SovraGov

SovraGov es la plataforma que integra cuatro módulos sobre la misma capa de datos e identidad — para que un gobierno adopte una única plataforma y opere sobre un stack coherente entre funciones que antes vivían en sistemas desconectados:

• Ventanilla Única de cara al ciudadano. Cada trámite, cada actualización de estado, cada credencial entregada a SovraWallet — a través de un solo portal, 24/7, web, mobile y WhatsApp.

• Expedientes electrónicos, comunicaciones oficiales, actos administrativos, todo dentro de flujos de trabajo configurables. Construido sobre el stack BEAM (Elixir/Phoenix/PostgreSQL), el mismo runtime que sostiene a Discord, WhatsApp y Bet365 a escala.

• Administración presupuestaria moderna, integrada directamente con el sistema documental. Curvas de ejecución calculadas desde expedientes reales, no planillas paralelas.

• Compras públicas trazables de punta a punta. Cada paso anclado en SovraChain, públicamente verificable por cualquier ciudadano, sin intermediarios. Evaluación de licitaciones asistida por IA y ejecución contractual integrada con presupuesto.

Los cuatro módulos comparten la misma identidad, los mismos documentos y la misma cadena — para que las integraciones no tengan que construirse desde cero.

Por qué este diseño

Tres principios atraviesan el stack:

1. Reutilizar, no re-emitir. Una credencial emitida una vez puede verificarse en cualquier lugar — entre instituciones, entre servicios, a lo largo del tiempo. Los ciudadanos dejan de tener que presentar el mismo documento en cada ventanilla; las instituciones dejan de rehacer la misma capa de confianza en cada dependencia.

2. Anclada al titular, controlada por el ciudadano. La credencial vive en la wallet del ciudadano, y el ciudadano decide qué compartir. La divulgación selectiva permite confianza sin vigilancia.

3. Alineada a estándares, anclada en soberanía. Cada capa está construida sobre estándares abiertos — W3C Verifiable Credentials, ISO mDL, OpenID4VP, Ethereum L2 — para evitar dependencia de proveedores y garantizar interoperabilidad a largo plazo. Los datos son siempre propiedad del gobierno; Sovra opera como proveedor SaaS, nunca como custodio.

¿Querés profundizar en el tema?

• Página de producto SovraGov

• Documentación de desarrolladores SovraID

• Explorá /knowledge — Conceptos clave sobre identidad verificable

• Edición anterior — Agentic Gov Protocol

La conversación sobre IA en el gobierno está cambiando rápido. Hace un año, la mayoría de las discusiones se centraban en la experimentación. Hoy el foco se está desplazando hacia algo más grande: cómo los gobiernos pueden integrar la IA de manera segura en sistemas públicos reales.

Solo este año, la ITU convocó en marzo un workshop sobre identidades digitales confiables e interoperables para humanos y agentes de IA en Ginebra. En febrero, el NCCoE de NIST publicó su Concept Paper sobre identidad y autorización de software y agentes de IA, señalando que “este aumento en escala y autonomía trae tanto nuevas oportunidades como nuevos riesgos.” Y Smart City Expo World Congress 2026 abre en Barcelona este noviembre sobre las mismas preguntas.

Esta edición lee la conversación desde el lado institucional, junto a un ensayo reciente de Chuy Cepeda escrito desde el lado de quien construye agentes.

Qué van a verificar las instituciones, y qué se está construyendo para responder

Antes de que un sistema de IA pueda actuar a nombre de un ciudadano, una institución tendrá que responder cinco preguntas de identidad:

• ¿A quién representa el agente?

• ¿Quién lo autorizó, y cómo?

• ¿Sigue siendo válida la delegación?

• ¿La acción está dentro del alcance?

• ¿Quedó registrada para revisión?

No son preguntas institucionales nuevas. Los gobiernos ya evalúan versiones de ellas cada vez que un abogado, un contador o un tutor actúa a nombre de otra persona. Lo que cambia es la necesidad de expresar las respuestas en forma legible por máquina y verificable criptográficamente.

Cruzando todos estos esfuerzos, cuatro primitivas arquitectónicas se repiten como respuesta. Cada una puede ser verificada localmente por la institución, sin necesidad de volver a llamar al ciudadano en tiempo real.

• Delegación verificable — a quién representa el agente y quién lo autorizó. Una credencial que el ciudadano firma, nombrando al agente y el alcance de lo que puede hacer. Misma familia de modelo de datos que la licencia de conducir móvil.

• Vinculación de alcance — qué tiene permitido hacer el agente. El alcance queda fijado criptográficamente, apoyado en la misma mecánica de divulgación selectiva que cubrimos en nuestra edición sobre pruebas de conocimiento cero.

• Infraestructura de revocación — si la delegación sigue siendo válida. El mismo patrón de lista de estado que las credenciales verificables ya usan hoy, ahora con el ciudadano en el rol de emisor.

• Integridad del registro de auditoría — si la acción quedó registrada para revisión. El NCCoE de NIST propone adaptar estándares de identidad existentes como OAuth 2.0 y OpenID Connect a los agentes de IA.

Qué infraestructura ya existe hoy

Acá es donde Sovra encaja.

Desde hace varios años, Sovra viene construyendo exactamente la infraestructura institucional sobre la que la conversación de agentic-gov se está organizando hoy. Emisión de credenciales verificables para gobiernos a través de SovraGov. Infraestructura de verificación para instituciones a través de SovraID. Credenciales del lado del ciudadano a través de SovraWallet. Raíces de confianza on-chain a través de SovraChain. Todo construido sobre los mismos estándares abiertos en los que la conversación de agentic-gov está convergiendo — W3C Verifiable Credentials, OpenID4VP, ISO 18013-5 y eIDAS.

Los estándares siguen sin resolverse. Los modelos de gobernanza siguen evolucionando entre jurisdicciones. Pero la arquitectura de confianza sobre la que estos sistemas probablemente van a depender ya opera a escala institucional — y Sovra está posicionada para ser el fundamento donde aterricen.

Para leer esta semana

• Encuadre desde quien construye agentes — el ensayo de Chuy Cepeda sobre identidad de agentes para gobiernos, la contraparte de esta edición desde el lado de quien construye agentes.

• Desde The Identity Brief — ediciones pasadas que dan contexto a las primitivas de arriba: Cómo funciona la licencia de conducir móvil (14 de mayo, la familia de credencial a la que pertenece el patrón de delegación), Cómo una credencial verificable sobrevive a su emisor (7 de mayo, la capa de confianza que hace posible la verificación sin ida y vuelta), El ciclo de vida completo de una credencial verificable (23 de abril, la referencia fundacional), y Pruebas de conocimiento cero explicadas con tu licencia de conducir (26 de febrero, la criptografía detrás de la vinculación de alcance).

• Mirada desde otro gobierno — Government Trends 2026 de Deloitte: Agentic AI for customized service delivery, con Bürokratt de Estonia cubierto en profundidad.

• Lecturas técnicas adyacentes — Indicio: Why Verifiable Credentials Will Power Real-World AI in 2026 y la propuesta de Vitalik Buterin sobre agentes personales de IA con delegación basada en pruebas de conocimiento cero en gobernanza DAO.

Continua la conversación

Más recursos técnicos sobre el stack de credenciales verificables, incluidas implementaciones de referencia y casos de despliegue en formatos W3C y ISO 18013-5, están disponibles en sovra.io/knowledge.

Si tu institución está siguiendo la conversación de estándares de agentic-gov o evaluando cómo las credenciales de delegación podrían encajar con su infraestructura de confianza existente, escribinos. Leemos cada respuesta.

Si esta edición te resultó útil, reenviarla a una persona en gobierno o en la industria de identidad institucional es la forma más directa de hacer crecer esta comunidad.

Suscribite a The Identity Brief, publicado todos los jueves.

La mayoría de los gobiernos aborda la interoperabilidad como un problema técnico: elegir un estándar, construir la integración, conectar los sistemas. Los países que realmente lograron interoperabilidad cuentan una historia distinta. Empezaron por la capa institucional primero — quién es dueño del dato, quién tiene autoridad para compartirlo, qué codifican los estándares sobre gobernanza — y dejaron que la tecnología siguiera.

Estonia es el ejemplo canónico: X-Road, lanzado en 2001, es descrito a menudo como una pieza tecnológica. Es más exactamente una filosofía que se implementa en software. Cuando un ciudadano consume un servicio a través de él, el sistema nombra la organización que es dueña del dato, el área dentro de esa organización, el sistema, y el servicio. Eso es soberanía digital hecha concreta a nivel de arquitectura.

En este episodio de Sovra Podcast, Lucas Jolías conversa con Gustavo Giorgetti, Fundador de ThinkNet S.A. e investigador de la Universidad de San Andrés, uno de los arquitectos detrás de los ecosistemas de interoperabilidad de Argentina en Neuquén, Mendoza, San Juan, y otras cuatro provincias. Gustavo empezó a trabajar en interoperabilidad en 2010, cuando explicar el concepto significaba cargar computadoras en un camión y demostrar físicamente data fluyendo entre sistemas sobre una mesa de reunión. Dieciséis años después, lo que él y una generación de practicantes argentinos construyeron es un modelo federal que respeta la autonomía provincial mientras habilita consultas cross-jurisdicción a escala de producción.

Lo que vas a escuchar

1. Por qué X-Road es institucional antes que técnico Los estándares que Estonia embebió en X-Road codifican gobernanza — propiedad del dato, autoridad organizacional, servicios nombrados. La tecnología es secundaria. Gustavo explica por qué los países que abordan X-Road como una selección tecnológica consistentemente fallan en capturar su valor real.

2. El modelo federal argentino y por qué escala Estonia es chica y unitaria, así que el 100% de los servicios pueden correr a través de una sola espina de interoperabilidad. Argentina es federal, con provincias autónomas. La adaptación: cada provincia corre su propio ecosistema. Siete jurisdicciones están interoperando hoy, con una federación entre seis confirmada en marzo de 2026. México y Brasil ya están replicando el patrón. “Argentina tiene más ecosistemas que ningún país del mundo,” dice Gustavo, “porque respetamos el federalismo.”

3. El primer caso de uso federado: deudores alimentarios Un deudor no puede deber en una provincia y escaparse a otra. Las consultas cross-provincia ahora pasan institucionalmente, en el background, con auditoría completa, sin copia de base de datos. La consulta recolecta información a través de las provincias federadas y devuelve un sí/no — preservando privacidad, preservando autonomía provincial, eliminando el loophole.

4. Mendoza constituye una empresa en dos horas Nueve registros públicos separados hablan entre sí detrás de un único punto de entrada para el ciudadano. Paso uno es el nombre de la empresa. Paso dos es el pago. Paso tres es operativo. Las mismas entidades legales existen, las mismas obligaciones fiscales existen, pero la experiencia colapsa en una sola interacción. Estonia lo hace en quince minutos. Mendoza es segunda en el mundo.

5. Las dos capas: back-end + front-end La interoperabilidad opera en dos capas, y la mayoría de los proyectos solo construye una. Interoperabilidad back-end es X-Road — intercambios institucionales en el background. Interoperabilidad front-end es el ciudadano cargando su propia credencial — una credencial verificable emitida por una institución, guardada en una wallet, presentada a cualquier verificador dentro o fuera del ecosistema original. Las dos compoundean: las consultas X-Road pueden disparar credenciales verificables emitidas dinámicamente en tiempo real, solo cuando el ciudadano necesita presentar una afuera del ecosistema.

6. Los agentes de IA como próxima frontera El cierre de la conversación aterriza en lo que hace esta arquitectura importante para la próxima década. A medida que los agentes de IA empiezan a actuar en nombre de ciudadanos — reservando, pagando, aplicando, verificando — necesitan una forma de probar legitimidad ante los verificadores. Las mismas credenciales verificables que anclan la identidad ciudadana se vuelven las credenciales que el agente carga. Gustavo cita al CEO de Nvidia en un evento reciente: “La data estructurada es el verdadero fundamento de la IA.” La infraestructura pública digital construida sobre estándares interoperables ES esa capa de data estructurada.

Citas clave

“Cuando usás un servicio bajo X-Road, estás usando la institucionalidad del gobierno. Eso es soberanía digital.”

“DPI es lo que está afuera de las organizaciones. La gente llega con soluciones tecnológicas para adentro de sus fronteras, pero el problema de la infraestructura pública digital está afuera — donde pasan los intercambios, donde pasan las transferencias.”

“Argentina tiene más ecosistemas que ningún país del mundo, simplemente porque respetamos el federalismo.”

“Estonia lo hace en quince minutos. Mendoza lo hace en dos horas. La única diferencia es que Mendoza tiene que esperar al boletín oficial del día siguiente — pero conceptualmente, nueve registros públicos ya están hablando entre sí detrás de un único punto de entrada.”

“Para mí, las credenciales verificables son el complemento más importante. Extienden la confianza afuera de las fronteras del ecosistema.”

Sobre el invitado

Gustavo Giorgetti es Fundador de ThinkNet S.A. e investigador de la Universidad de San Andrés en Argentina. Trabaja en gobierno digital e interoperabilidad desde 2008, con involucramiento profundo en el diseño e implementación de ecosistemas provinciales en Argentina — incluyendo el trabajo fundacional en Neuquén desde 2010, que se volvió laboratorio para lo que hoy es una red federada. En agosto de 2024 presentó ante el Caucus Digital de ParlAméricAs sobre Enfoques Clave para Salvaguardar la Identidad Digital. Su trabajo se enfoca en los frameworks institucionales y de gobernanza que determinan si la interoperabilidad técnica se traduce en infraestructura pública adoptada y durable.

🎧 Escuchá el episodio completo en YouTube

Más de Sovra

• 📖 Cómo una Credencial Verificable Sobrevive a su Emisor — la arquitectura de verificación cross-institucional

• 📖 Una Wallet para el Agente — Credenciales Know Your Agent — credenciales para agentes de IA actuando en tu nombre

• 🎧 [PODCAST] Ep. 7: De la Digitalización a la Infraestructura (con Aura Cifuentes) — la conversación sobre la que se construye este episodio

La licencia de conducir es el documento de identidad más universalmente aceptado del mundo. Casi todas las jurisdicciones emiten una, casi todos los adultos en esas jurisdicciones llevan una, y casi cualquier situación que pida identidad la acepta. Cuando los organismos de estandarización decidieron construir una credencial de identidad digital criptográficamente verificable para despliegue a escala de consumidor, eligieron el documento que ya tenía alcance global.

El resultado es la licencia de conducir móvil, conocida internacionalmente como mDL (por mobile driver’s license), definida por ISO/IEC 18013-5 y publicada en septiembre de 2021. A lo largo de una lista creciente de estados de Estados Unidos coordinados a través de AAMVA, países miembros de la UE que están implementando la EUDI Wallet, y despliegues piloto en Asia y América Latina, la mDL es el formato que llevó las credenciales verificables del whitepaper a la billetera en el teléfono.

Esta edición recorre qué es realmente una mDL, cómo está estructurada, cómo se presenta y cómo se verifica. Si todavía no leíste nuestra edición del 23 de abril sobre el ciclo de vida de la credencial verificable, es el punto de partida natural para el material que sigue.

Qué es una mDL

Una mDL es una licencia de conducir digital que vive en una aplicación de billetera en el teléfono del ciudadano, firmada por la autoridad de tránsito emisora, y estructurada para presentarse a un verificador en forma offline u online. El ciudadano tiene la credencial en su billetera. El verificador, al consultar, ejecuta una operación criptográfica contra la clave pública del emisor para confirmar que la credencial es genuina y no fue alterada.

El estándar que define todo esto es ISO/IEC 18013-5: Identificación personal, Licencia de conducir compatible con ISO, Parte 5: Aplicación de licencia de conducir móvil (mDL). El estándar especifica la estructura de datos de la credencial, el esquema de firma, los protocolos de presentación entre dispositivos, y las reglas para divulgación selectiva. Un estándar complementario, ISO/IEC 18013-7, extiende el modelo a la presentación en línea no asistida, abordando el caso en que se accede a un verificador a través de la red en lugar de cara a cara.

El objetivo arquitectónico del estándar es darle al ciudadano una licencia de conducir digital que funcione para todos los escenarios comunes que hoy cubre la tarjeta plástica, incluyendo verificación de edad en un local, prueba de identidad en un control de tránsito, y presentación en un cruce fronterizo, sin requerir que el verificador alcance al emisor en tiempo real.

Cómo está estructurada una mDL

Una mDL está codificada de forma distinta a una credencial verificable del W3C, y las diferencias son deliberadas.

Una credencial verificable del W3C es típicamente un documento JSON-LD o un SD-JWT, firmado con una suite de firmas de la familia JOSE. Una mDL está codificada en CBOR, la representación binaria concisa de objetos (Concise Binary Object Representation), y firmada con COSE, el formato CBOR para firma y cifrado de objetos (CBOR Object Signing and Encryption). La estructura que contiene la credencial firmada se llama Mobile Security Object, o MSO, y guarda los datos de la credencial junto con los metadatos requeridos para la presentación y la verificación.

La razón por la que el estándar eligió CBOR y COSE en lugar de JSON y JOSE es que las mDL fueron diseñadas para funcionar en entornos de presentación con recursos limitados: un intercambio Bluetooth a la tableta de un agente de tránsito en la calle, un toque NFC en un control de seguridad de aeropuerto, un intercambio por código QR en la puerta de un local. CBOR es significativamente más compacto que JSON, COSE es significativamente más eficiente que JOSE para firmar y verificar payloads pequeños, y la combinación mantiene el tamaño de la credencial lo suficientemente bajo como para transmitirse de forma confiable sobre protocolos de corta distancia entre dispositivos.

Dentro del MSO, una mDL contiene los mismos campos que la tarjeta plástica: nombre, fecha de nacimiento, número de licencia, número de documento, autoridad emisora, fecha de vencimiento, dirección y categorías de licencia. Cada campo se hashea de forma individual, de modo que el ciudadano puede presentar algunos y omitir otros sin invalidar la firma global del emisor. Esta es la base arquitectónica de la divulgación selectiva, que el estándar trata como capacidad por defecto y no como una extensión opcional.

Cómo se presenta una mDL

ISO 18013-5 define tres modos de presentación, cada uno para un escenario distinto que la licencia plástica cubre hoy.

La recuperación en dispositivo es el modo offline, en el que el ciudadano y el verificador intercambian la credencial directamente entre teléfonos, o entre un teléfono y un dispositivo verificador. El transporte suele ser NFC para acercamientos rápidos, o Bluetooth Low Energy para interacciones algo más extensas, con códigos QR para iniciar la conexión. No se requiere acceso a internet en ninguno de los dos extremos. El control de tránsito en la ruta es el escenario canónico para este modo, y es el escenario alrededor del cual el estándar fue diseñado con más cuidado.

La recuperación por servidor es un modo híbrido, en el que el verificador recibe un token desde el teléfono del ciudadano y usa ese token para obtener la credencial desde un endpoint de servidor que mantiene el emisor. La recuperación por servidor es útil cuando el verificador necesita contexto adicional desde el lado del emisor, aunque vuelve a introducir una dependencia de que el emisor esté disponible al momento de la presentación, una de las dependencias que el modo offline fue diseñado para eliminar.

La presentación en línea no asistida, definida en ISO 18013-7, aborda el caso en el que el verificador es un sitio web o un servicio en lugar de una persona con un dispositivo. El flujo usa un protocolo basado en OpenID para autorizar y transmitir la credencial, y es el puente que hace presentables las mDL ante e-commerce, banca, y servicios gubernamentales en línea. ISO 18013-7 es el estándar complementario hacia el cual la mayoría de los despliegues están construyendo hoy para los escenarios de verificación en línea.

Cómo se verifica una mDL

Cuando un verificador recibe una mDL, la operación de verificación tiene tres partes.

El verificador confirma que la firma del emisor sobre el MSO es válida, usando la clave pública del emisor. Esa clave pública la publica la autoridad emisora a través de un registro de confianza al que el verificador tiene acceso, típicamente mantenido por AAMVA en Estados Unidos, por autoridades nacionales en la UE bajo la EUDI Wallet ARF, y por organismos nacionales equivalentes en otros lugares. El verificador confirma que la divulgación selectiva es consistente, comparando los hashes de los campos que el ciudadano eligió revelar contra los hashes registrados en el MSO. El verificador confirma que la credencial no fue revocada, consultando el mecanismo de estado del emisor.

La divulgación selectiva merece una mirada más cercana, porque es una de las decisiones arquitectónicas que le da a la mDL su carácter operativo. Un encargado de seguridad que necesita confirmar que un ciudadano es mayor de 21 recibe la respuesta “sí” junto con la prueba criptográfica de que esa respuesta vino de la autoridad emisora, sin recibir la fecha de nacimiento del ciudadano, su nombre, ni su dirección. La misma credencial soporta a un verificador bancario que pide nombre completo y fecha de nacimiento para fines de conoce-a-tu-cliente. El ciudadano controla qué campos se liberan en cada presentación, y la estructura criptográfica del MSO garantiza que los campos retenidos no puedan inferirse a partir de los revelados.

Cubrimos las primitivas criptográficas detrás de la divulgación selectiva en nuestra edición del 26 de febrero sobre pruebas de conocimiento cero, que es la referencia para quienes quieran una mirada más profunda al funcionamiento matemático.

Dónde encaja Sovra

Sovra construye la capa institucional sobre la que operan las autoridades emisoras y los verificadores. SovraGov maneja el lado de la emisión: cómo un organismo de gobierno configura tipos de credenciales, las firma, gestiona claves, y publica sus raíces de confianza. SovraID maneja el lado de la verificación: cómo una institución verificadora se registra como contraparte, obtiene los datos de la lista de confianza, y ejecuta los chequeos criptográficos sobre las credenciales entrantes. SovraWallet guarda las credenciales del lado del ciudadano, incluyendo credenciales en formato W3C y credenciales en formato mDL ISO 18013-5 dentro de la misma billetera, presentándolas a través de OpenID4VP y a través de los protocolos de recuperación en dispositivo de ISO 18013-5 cuando el caso de uso lo requiere.

La infraestructura institucional sigue siendo la misma sin importar qué stack de credenciales use un despliegue específico. Las suites de firma difieren, la codificación difiere, los protocolos de presentación difieren, y los mecanismos de registro de confianza, el comportamiento de rotación de claves, la publicación de revocaciones y el onboarding institucional se mantienen consistentes a través de ambos formatos. A lo largo del stack en producción, se han emitido más de 10M de credenciales y procesado más de 50M de verificaciones contra esta arquitectura, abarcando múltiples formatos de credencial y múltiples contextos de presentación.

Vale la pena leer esta semana

La descripción general del estándar ISO 18013-5 es el punto de partida más autorizado para entender la especificación de mDL, aunque el estándar completo es de pago. Para una guía gratuita, la Guía de Implementación de mDL de AAMVA cubre el patrón práctico de despliegue contra el que están construyendo los estados de Estados Unidos, incluyendo la publicación de listas de confianza, el onboarding de proveedores de billetera, y la integración del verificador. Vale la pena tener ambos a mano para cualquier persona que esté evaluando un despliegue de mDL en su jurisdicción.

Continuemos la conversación

Hay más recursos técnicos sobre el stack de credenciales verificables, incluyendo implementaciones de referencia y casos de despliegue tanto en formatos del W3C como ISO 18013-5, disponibles en sovra.io/knowledge.

Si estás trabajando en un despliegue de mDL o evaluando cómo encaja con infraestructura W3C existente, respondé. Leemos cada respuesta.

Suscribite a The Identity Brief, se publica todos los jueves.