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.

Desde el equipo

[PLACEHOLDER — confirmar con el equipo antes de enviar: trabajo de convergencia entre credenciales verificables del W3C y mDL ISO 18013-5 en el roadmap de SovraWallet, progreso en el alineamiento del perfil OpenID4VP, conversaciones de piloto de mDL, o un hito de despliegue específico de la semana. Usar únicamente datos verificados.]

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.

Esta semana cerró el Internet Identity Workshop en Mountain View con una pregunta que no existía hace cinco años: ¿qué significa verificar a un agente? Cuando un asistente de IA reserve tu vuelo, presente tu declaración de impuestos a través del portal de una autoridad fiscal, o transfiera fondos en tu nombre, la institución del otro lado no tiene forma criptográfica de saber si el agente está realmente autorizado a actuar por ti — ni si alguien le otorgó ese permiso.

Esa brecha es hoy la capa faltante en la infraestructura de identidad digital con AI. Y se resuelve con las mismas primitivas que ya funcionan para los ciudadanos: una billetera, una credencial verificable, y un verificador que no necesita al emisor presente.

Qué hace realmente una billetera “Know Your Agent”

La misma arquitectura que entrega a un ciudadano una credencial verificable se extiende naturalmente a sujetos no humanos. Las especificaciones W3C Verifiable Credentials y Decentralized Identifier fueron diseñadas sin suponer que el holder sea una persona.

Una credencial Know Your Agent responde criptográficamente a cuatro preguntas:

1. ¿Quién es el principal? El humano (o institución) que delegó la autoridad. Su DID es la raíz de confianza.

2. ¿Quién es el agente? La IA, identificada por su propio DID — versionado, con huella del modelo, atestada en tiempo de ejecución cuando es posible.

3. ¿Qué alcance se otorgó? Una autorización específica y acotada: reservar vuelos por menos de dos mil dólares, leer el calendario pero no escribir, presentar formularios solo ante el Ministerio de Salud.

4. ¿Por cuánto tiempo? Una expiración con plazo definido. Revocable instantáneamente por el principal.

El agente presenta la credencial como una licencia de conducir digital. El verificador comprueba la firma localmente. La criptografía viaja con la credencial.

Un recorrido concreto

Una ciudadana — llamémosla María — quiere que un asistente de IA gestione su declaración de impuestos. El flujo:

Emisión. María abre su SovraWallet y autoriza una credencial de agente para su asistente fiscal. Especifica el alcance: presentar el formulario 720 ante X Entidad, leer documentos fiscales únicamente, sin transferencia de fondos, expira en 30 días. La credencial está firmada con la clave de María (ella es el emisor de su propia delegación), almacenada en el runtime del agente, y su billetera conserva el handle de revocación.

Acción. El asistente de IA se conecta con la Entidad. El verificador de la Entidad — corriendo la misma lógica de verificación SovraID que cualquier otro verificador institucional — recibe la credencial. Comprueba: firma válida contra el DID público de María; el alcance coincide con la acción solicitada; no expirada; no revocada. La verificación ocurre localmente. La decisión es sub-segundo.

Auditoría. Cada acción que toma el agente queda registrada con una referencia criptográfica a la autorización firmada por María. Si algo sale mal, el rastro de auditoría no se reconstruye desde los logs del servidor — se deriva de la credencial misma, inmutable y firmada.

Revocación. María abre SovraWallet y toca revocar. La siguiente verificación falla en todas partes de inmediato. Sin llamadas a una autoridad central. Sin coordinación entre proveedores. La credencial deja de ser válida, y la criptografía lo impone. Las mismas primitivas de divulgación selectiva que permiten a un ciudadano revelar solo su edad en un bar permiten al agente de María revelar solo el alcance que necesita.

¿Por qué ponerlo en la billetera?

Porque la autoridad del agente es una extensión de la identidad del humano, no un sistema separado. La delegación vive en el mismo lugar que la identidad raíz. Esto otorga divulgación selectiva limpia, revocación instantánea, y cero infraestructura nueva para las instituciones que ya usan el verificador.

Este es el dividendo arquitectónico de haber construido la identidad ciudadana como infraestructura y no como producto: cuando aparece una nueva categoría de sujeto — agentes, organizaciones, dispositivos — los rieles no necesitan reemplazarse. Nuestra postura sobre privacidad es lo que hace posible esta extensión.

Si estás construyendo sistemas donde agentes de IA actúan en nombre de humanos — y aún no has resuelto cómo verificarlos criptográficamente — nos gustaría escuchar con qué te estás encontrando. El próximo mes publicamos un brief técnico más extenso sobre credenciales de agentes, y tus restricciones del mundo real lo van a moldear.

The Identity Brief lo escribe el equipo de Sovra. Construimos infraestructura de identidad digital verificable para gobiernos e instituciones. Nuestra billetera, emisor y verificador son de código abierto y compatibles con los estándares W3C.

La mayoría de las descripciones de identidad digital se enfocan en un paso a la vez. Emisión. Almacenamiento. Verificación. Esta edición recorre todos ellos, en orden, para hacer visible el ciclo de vida completo como un sistema único.

En nuestro sitio web publicamos un recorrido demo como esquema estructural del mismo flujo. Esta edición es la capa de análisis: qué requiere cada paso, por qué importa cada uno y cómo se conectan entre sí.

El ciclo de vida en seis pasos

Paso 1 — El ciudadano solicita una credencial

El proceso comienza cuando un ciudadano — o una entidad que actúa en su nombre — solicita una credencial a una autoridad emisora. Un ministerio, un registro civil, un organismo de habilitación, una universidad pública. La solicitud puede llegar a través de un portal digital, una aplicación móvil o en persona.

En este punto ya hay una decisión arquitectónica tomada, aguas arriba, antes de que se complete cualquier formulario: si el sistema producirá una credencial verificable — un objeto de datos criptográficamente portable y en manos del ciudadano — o un registro de base de datos con una interfaz digital. La consecuencia de esa decisión se manifiesta a lo largo de los pasos siguientes.

Paso 2 — La autoridad verifica la identidad y la elegibilidad

La autoridad emisora confirma que el ciudadano solicitante es quien dice ser y que cumple con los requisitos de elegibilidad para la credencial.

La infraestructura para este paso es madura — registros civiles, sistemas de empadronamiento biométrico, antecedentes previos, intercambio de datos entre organismos cuando está autorizado. La lógica es sólida: verificar en profundidad una sola vez, para que el ciudadano no tenga que demostrar su identidad desde cero en cada uso posterior.

La inversión del Paso 2 rinde a lo largo de todo el ciclo de vida porque la credencial que produce está diseñada para viajar de forma independiente. Eso es lo que los siguientes pasos hacen posible.

Paso 3 — La autoridad firma criptográficamente la credencial

La credencial se firma con la clave privada de la autoridad emisora. La firma vincula el contenido de la credencial a la identidad criptográfica del emisor. Cualquiera que tenga la clave pública correspondiente del emisor puede verificar la credencial más tarde sin necesidad de contactarlo.

Paso 4 — La credencial se entrega a la billetera del ciudadano

La credencial firmada se entrega a la billetera digital del ciudadano — SovraWallet o cualquier billetera compatible con el estándar W3C. El ciudadano la tiene. Puede portarla, presentarla y gestionarla. La autoridad emisora no conserva una copia viva vinculada a cada uso posterior.

Este paso es el que hace que la credencial esté en manos del ciudadano y no del emisor. El ciudadano lleva consigo la prueba misma. Desde este momento, la credencial está en posesión del ciudadano como un instrumento que él controla.

Paso 5 — El ciudadano presenta la credencial ante un verificador

Cuando el ciudadano necesita probar algo — ante un banco, un organismo gubernamental, un empleador, un proveedor de salud — presenta la credencial desde su billetera. El mecanismo de entrega suele ser un código QR, un toque NFC o un deep link. El ciudadano decide qué comparte y cuándo.

Como la credencial misma es criptográficamente autocontenida, el verificador no necesita una relación previa con el emisor. No necesita conocerlo de antemano. No necesita una integración de API con la base de datos del emisor. Necesita la credencial y la clave pública del emisor.

Paso 6 — El verificador confirma criptográficamente

El verificador recibe la credencial, obtiene la clave pública del emisor desde el registro público y verifica la firma criptográfica de forma local. La verificación es una operación matemática: la firma es válida o no lo es. Sin llamadas al emisor. Sin integración institucional. Sin intercambio de APIs.

Esto es lo que el estándar del W3C fue diseñado para habilitar. Junto con el paso 3, el paso 6 completa el arco criptográfico que hace que la credencial sea genuinamente portable: válida entre instituciones, entre administraciones, a lo largo del tiempo.

Lo que los seis pasos producen en conjunto

Una credencial que ha completado los seis pasos puede ser:

• Portable a cualquier lugar — vive con el ciudadano, no en una base de datos institucional

• Verificable en cualquier lugar — por cualquier verificador con acceso a la clave pública del emisor, sin necesidad de contactarlo

• Portable entre administraciones — ninguna organización en particular necesita seguir operativa para que la credencial siga siendo válida

• Presentable de forma selectiva — el ciudadano decide qué comparte y cuándo

• Criptográficamente resiliente — la firma no puede falsificarse y la revocación es una operación criptográfica

Estas propiedades son las que hacen que una credencial verificable sea cualitativamente distinta de un documento digital. Son las que el estándar del W3C fue diseñado para entregar. Y son las que la arquitectura de seis pasos produce cuando se implementa de extremo a extremo.

Sobre este tema: ediciones anteriores

En marzo publicamos un análisis en profundidad sobre qué pasa después de que se emite una credencial verificable — el ciclo de vida descendente: presentación, divulgación selectiva y revocación. Esta edición es la compañera ascendente: cómo se produce la credencial en primer lugar. Juntas, las dos piezas describen el arco completo.

The Identity Brief es una publicación semanal de Sovra — el Stack de Identidad Digital para el Mundo Institucional.

Los gobiernos de América Latina llevan años digitalizando. Más plataformas, más portales, más aplicaciones. Pero digitalización e infraestructura no son lo mismo. Se pueden digitalizar todos los servicios de gobierno y seguir dejando a los ciudadanos cargando documentos en papel, porque nadie construyó la capa compartida que hace que las credenciales sean portátiles, verificables y reutilizables entre instituciones.

La Infraestructura Pública Digital no es una tecnología nueva. Es una forma diferente de pensar sobre lo que los gobiernos construyen y quién puede construir encima. Pensá en los semáforos: un protocolo común que todos entienden, donde las reglas son compartidas y el sistema funciona porque todos los actores — públicos, privados, sociedad civil — operan sobre el mismo estándar.

En este episodio de Sovra Podcast, Lucas Jolias conversa con Aura Cifuentes, Directora para América Latina y el Caribe en Co-Develop, el fondo filantrópico que acelera la adopción de DPI en el Sur Global. Aura trae una perspectiva poco común: ocho años dentro de gobiernos latinoamericanos (incluyendo la dirección de Gobierno Digital en Colombia), seguidos de un paso al lado del ecosistema, donde hoy financia y acompaña los mismos proyectos que antes impulsaba desde adentro.

Lo que vas a escuchar

• DPI es un cambio de mentalidad, no una etiqueta tecnológica: Aura desglosa la Infraestructura Pública Digital en tres palabras que pesan por separado. Infraestructura significa capas compartidas sobre las que otros pueden construir, no plataformas aisladas. Pública significa lo que genera valor público, no necesariamente lo que construye el sector público solo. Digital significa basada en datos, reutilizable y abierta. El cambio es de gobiernos que construyen sistemas cerrados a gobiernos que construyen protocolos comunes — como semáforos — que todo el ecosistema usa. Para profundizar en DPI como concepto, consultá la sección de DPI en la Base de Conocimiento de Sovra.

• El modelo catalítico de Co-Develop: Co-Develop es un fondo filantrópico que ayuda a los gobiernos a poner el primer ladrillo. Su rol es catalítico: financiar un piloto, demostrar que funciona, y dejar que el gobierno lo escale con socios locales. El portafolio es intencionalmente diverso — sector privado, sociedad civil, academia, investigadores — porque la DPI debe ser segura, inclusiva y multiactor por diseño. Si un proyecto solo sobrevive con filantropía, nunca fue infraestructura. Esto se alinea con el enfoque de Bienes Públicos Digitales: herramientas de código abierto diseñadas para ser adoptadas y adaptadas entre países.

• PIX como caso de estudio de DPI: El sistema de interoperabilidad de pagos de Brasil es uno de los ejemplos más claros de DPI bien hecha. No importa qué billetera digital uses, qué banco tengas ni si sos una fintech. Escaneás un QR y pagás. PIX funciona porque es una infraestructura compartida con un foro de gobernanza (PIX Forum) que incluye voces diversas — gobierno, sector privado, sociedad civil — para discutir prevención de fraude, innovación y mejoras. El mismo modelo aplicado a identidad digital significaría verificar una vez y usar esa identidad en todos lados, entre instituciones y fronteras. Este es el enfoque de Identidad Reutilizable que Sovra viene construyendo, y la razón por la que los estándares de interoperabilidad como OpenID4VC y DIDComm importan.

• La apertura genuina de América Latina: Aura ve una región en un momento crítico. Los gobiernos están genuinamente dispuestos a adoptar DPI — no porque los donantes se lo dijeron, sino porque el legado de gobierno digital maduró lo suficiente como para reconocer qué funciona y qué hay que reconstruir. El sector privado está organizado y proactivo, ofreciendo experiencia y soluciones probadas. La sociedad civil pasó de la incidencia en datos abiertos a moldear activamente la gobernanza de DPI. Y la coordinación multiactor está sucediendo orgánicamente, como en Colombia, donde el Banco de la República ya está conversando con el sector privado sobre infraestructura compartida sin presión externa.

• La brecha de adopción que nadie está cerrando: Esta es la verdad dura de la conversación. Los países lanzaron identidades digitales. Tienen la tecnología. Pero en 2026, Aura todavía viaja a países donde todo es físico. Los ciudadanos presentan documentos en papel porque los validadores institucionales — públicos y privados — no aceptan Credenciales Verificables de forma fluida, orgánica. La brecha no es tecnológica. Se trata de casos de uso reales que mejoren la vida de los ciudadanos de forma medible. Sin eso, la identidad digital se convierte en “una herramienta muy linda en el laboratorio” que no cambia nada en la práctica. Es el mismo desafío de adopción que abordó el despliegue de NLínea en Nuevo León al digitalizar más de 120 servicios con impacto medible: 80% más rápido, 30% menos burocracia.

• “Empujamos la solución sin pensar en el problema”: Una de las observaciones más afiladas del episodio. Los gobiernos invirtieron fuerte en emitir identidad digital. Pero la pregunta de si los ciudadanos realmente se benefician — si la adopción es real, si los casos de uso resuelven fricción — muchas veces queda en segundo plano. Aura argumenta que hay que invertir la secuencia: empezar por el problema del ciudadano y después construir la infraestructura que lo resuelve. Esto hace eco del principio detrás del enfoque de Sovra: primero el beneficio ciudadano, después la tecnología.

• Sobrevivir las transiciones políticas: Los proyectos de DPI toman tiempo. Son ambiciosos, a veces costosos, y necesitan sobrevivir cambios de gobierno. Uruguay es el ejemplo regional de políticas de Estado que persisten entre administraciones — un caso explorado en profundidad en el Ep. 5 con Juan Pablo Garcia. Aura ve más gobiernos reconociendo que si el país es una democracia, la infraestructura tiene que durar más que cualquier gobierno. El desafío es convertir proyectos de gobierno en infraestructura de Estado, y eso requiere la gobernanza multiactor que hace resiliente a la DPI frente a ciclos políticos.

• Desaprender es más difícil que aprender: El trabajo de Co-Develop no solo implica enseñar nuevos enfoques a los gobiernos, sino ayudarlos a desaprender los viejos. El paso a tecnología abierta, estándares abiertos y coordinación de ecosistema requiere dar un paso atrás respecto a cómo se hizo la digitalización en la última década — una progresión mapeada en la sección Evolución de la Identidad Digital de la Base de Conocimiento, de centralizada a federada a centrada en el usuario a auto-soberana. El código abierto trae sesgos y preconceptos que hay que abordar. El proceso es iterativo, co-creativo e incómodo, pero Aura lo ve como el único camino hacia infraestructura que dure.

Citas clave

“La DPI es un cambio de mentalidad. Es una aproximación a una digitalización diferente. Cuando hablamos de gobierno, se trata de construir capas sobre las que el sector privado pueda construir.”

“Empujamos la solución sin pensar en el problema. Estamos en 2026 y sigo viajando a países donde todo sigue siendo físico.”

“Si los proyectos solo sobreviven con filantropía, nunca fueron infraestructura. El gobierno tiene que liderar, o arrancamos mal.”

Sobre la invitada

Aura Cifuentes es Directora para América Latina y el Caribe en Co-Develop, el fondo filantrópico que acelera la adopción de Infraestructura Pública Digital en el mundo. Antes de unirse a Co-Develop, pasó ocho años en el sector público colombiano, donde fue Directora de Gobierno Digital en el Ministerio de Tecnologías, diseñó la primera política de innovación pública del país en el Departamento Nacional de Planeación, y lideró iniciativas de transparencia desde la Presidencia de la República. Es magíster en Administración Pública de Columbia University y Sciences Po, y profesional en Gobierno y Relaciones Internacionales de la Universidad Externado de Colombia. Su trabajo se sitúa en la intersección de modernización estatal, datos abiertos y los modelos de gobernanza multiactor que hacen sostenible a la DPI.

Recursos

🎧 Escuchá el episodio completo en YouTube

📚 Explorá los conceptos: Infraestructura Pública Digital | Bienes Públicos Digitales | Identidad Reutilizable | Credenciales Verificables | Evolución de la Identidad Digital | Casos de Uso Reales

🌐 Seguí a Sovra: LinkedIn | X | YouTube

✉️ Suscribite: sovra.substack.com

🔗 Más info: sovra.io

Más de Sovra

Episodios del podcast:

• Ep. 6: Identidad descentralizada desde Buenos Aires al mundo — Cómo QuarkID llevó la identidad auto-soberana a escala de gobierno (con Pedro Alessandri)

• Ep. 5: Identidad digital desde Uruguay al mundo (con Juan Pablo Garcia)

• Ep. 4: De 9 horas a un click — Cómo Salta construyó identidad digital reutilizable (con Martin Guemes)

• Ep. 3 | Ep. 2 | Ep. 1

Reportes y artículos:

• ¿Qué es un DID? El componente base de la identidad digital portátil

• El colapso silencioso de la verificación de identidad

• Tres cosas que resaltan al rankear los sistemas de identidad de LATAM

• ¿Qué pasa después de que se emite una Credencial Verificable?

Casos de estudio:

• NLínea: Cómo Nuevo León construyó la mejor ventanilla digital de LATAM

• IDDI Salta: Identidad digital reutilizable para 1.4M de ciudadanos

Todo sistema de identidad digital necesita una forma de decir “esta persona sos vos.” Las direcciones de email lo hacen para internet. Los números de teléfono lo hacen para telecomunicaciones. Los números de documento lo hacen para servicios públicos.

Todos estos identificadores tienen algo en común: los controla otra entidad. Google controla tu email. Una telco controla tu número de teléfono. Una agencia de gobierno controla tu número de documento. Si cualquiera de esas organizaciones cambia de criterio, tu identificador puede ser revocado, reasignado o dado de baja.

Los Identificadores Descentralizados, o DIDs, funcionan de manera diferente. Un DID lo controla quien tiene la clave criptográfica asociada. En la práctica, eso significa que lo controlás vos.

Esta edición explica qué es un DID a nivel técnico, cómo habilita la identidad digital portátil, y por qué importa para los 8 millones de ciudadanos que ya usan infraestructura de credenciales verificables en América Latina.

Si sos nuevo en credenciales verificables, nuestra edición anterior ¿Qué pasa después de que se emite una Credencial Verificable? cubre el ciclo de vida de la credencial. Esta edición va una capa más profundo: el identificador que hace a las credenciales portátiles.

Un DID en tres partes

Un DID es un URI (Identificador Uniforme de Recurso) que sigue una estructura específica definida por el W3C (World Wide Web Consortium). Se ve algo así:

Cada DID tiene tres componentes.

El esquema siempre es “did.” Esto le indica a cualquier sistema que lo que sigue es un Identificador Descentralizado.

El método describe cómo se puede buscar el DID. Diferentes métodos DID usan diferente infraestructura para la resolución. did:web usa servidores web estándar. did:key es autocontenido, con la clave pública embebida directamente en el identificador. did:ethr usa la blockchain de Ethereum como registro. El método determina los supuestos de confianza: ¿en quién se depende para buscar este identificador?

El identificador específico del método es único para el sujeto del DID. Combinado con el método, provee un identificador globalmente único que puede resolverse para obtener más información sobre el sujeto.

La especificación W3C DID Core, ahora en versión 1.1, estandariza este formato para que cualquier sistema que implemente la spec pueda resolver cualquier DID, independientemente del método. Podés explorar cómo se conectan estos conceptos en la Base de Conocimiento de Sovra.

Qué pasa cuando se busca un DID

Cuando un sistema resuelve un DID, recupera un DID Document. Es un objeto de datos estructurado, típicamente en formato JSON o JSON-LD, que contiene todo lo necesario para interactuar de forma segura con el sujeto del DID.

Un DID Document incluye:

Claves públicas (listadas bajo verificationMethod). Son las claves criptográficas públicas asociadas al DID. Cuando alguien firma un documento con la clave privada de su DID, cualquier verificador puede usar la clave pública del DID Document para confirmar que la firma es auténtica.

Endpoints de servicio. Son URLs o direcciones donde se puede interactuar con el sujeto del DID. Para un ciudadano, esto podría ser el endpoint de su wallet digital. Para una institución, podría ser la URL de su servicio de emisión de credenciales.

Métodos de autenticación y aserción. Definen cómo el sujeto del DID prueba que controla el DID (autenticación) y cómo hace claims verificables (aserción). Ambos referencian las claves públicas listadas en el documento.

El DID Document es esencialmente un documento de identidad legible por máquinas. Dice: estas son las claves que controlo, así se verifican mis firmas, y así me contactan. Cualquier sistema que resuelva el DID puede usar esta información para verificar credenciales, autenticar solicitudes o establecer comunicación segura.

Por qué importa la portabilidad

Los identificadores tradicionales están atados a la institución que los emitió. Si te mudás de país, tu número de documento se queda atrás. Si cambiás de proveedor de email, perdés tu dirección. Cada identificador vive en el silo de la organización que lo controla.

Un DID viaja con la persona. Porque el identificador lo controla la clave criptográfica del titular, y el DID Document puede ser resuelto por cualquiera, el mismo identificador funciona en cualquier sistema que implemente el estándar.

Así se ve en la práctica. Un gobierno en Argentina emite una credencial verificable, un documento digital firmado sobre un ciudadano, vinculado al DID del ciudadano. Esa credencial vive en la wallet del ciudadano en su celular.

Cuando el ciudadano presenta esa credencial en un banco en México, el banco resuelve el DID del ciudadano, recupera el DID Document, encuentra la clave pública relevante, y verifica la firma de la credencial. El proceso completo toma menos de un segundo, no requiere comunicación con el gobierno argentino, y no necesita ningún acuerdo bilateral entre las dos instituciones.

El DID es el ancla universal que hace esto posible. El formato de credencial (W3C Verifiable Credentials) provee la estructura de datos. El DID provee el identificador que conecta todo.

Si querés entender qué pasa después de que se emite una credencial y cómo funciona el flujo de verificación en detalle, nuestra edición anterior ¿Qué pasa después de que se emite una Credencial Verificable? recorre el ciclo de vida completo.

DIDs en producción

Esto ya funciona a escala nacional. En Sovra, 8 millones de ciudadanos en Argentina, México y Colombia usan DIDs como base de sus credenciales verificables. Más de 50 millones de verificaciones y 100 millones de llamadas API se procesaron a través de esta infraestructura, cada una resolviendo un DID y verificando una firma criptográfica en menos de un segundo. Podés ver los despliegues en detalle en nuestros casos de uso.

Un link que vale la pena leer

In an AI Rush, Sell Trust — Chuy Cepeda, Chief of Strategy de Sovra, sobre por qué las empresas que van a ganar la era de la IA son las que venden infraestructura de confianza verificable, y qué significa eso para gobiernos e instituciones evaluando su próximo paso.

The Identity Brief es el newsletter semanal de Sovra sobre identidad digital, credenciales verificables e infraestructura de confianza. Suscribite para recibirlo cada jueves.

En varias jurisdicciones de América Latina, una misma persona repite este proceso cinco o seis veces en un solo mes entre salud, educación, impuestos y registro civil. No porque la información no exista en formato digital, sino porque los sistemas que la almacenan nunca fueron diseñados para comunicarse entre sí.

Esta edición explica cómo las credenciales verificables resuelven ese problema a nivel de arquitectura, y por qué gobiernos de toda la región ya están implementando este enfoque.

Cómo las credenciales verificables cambian la arquitectura

Una credencial verificable es una pieza de información firmada digitalmente por una institución: un certificado digital que lleva prueba criptográfica de quién lo emitió y qué dice.

Cuando un gobierno emite una credencial verificable a un ciudadano (constancia de domicilio, licencia profesional, situación fiscal), esa credencial queda en la billetera digital del ciudadano. El ciudadano la controla. Decide cuándo presentarla y ante quién.

El cambio está en la verificación. Cuando otra oficina de gobierno necesita verificar esa credencial, no necesita llamar al organismo emisor. No necesita acceder a la base de datos original. Verifica la firma criptográfica de forma matemática. Si la firma es válida, la credencial es auténtica, en segundos, sin conexión a internet si es necesario, sin depender de que el sistema emisor esté disponible.

Una credencial emitida por un gobierno municipal puede ser verificada por un gobierno provincial, una agencia federal o incluso una institución privada, todo sin compartir bases de datos ni construir integraciones a medida.

¿Querés verlo en acción? Probá la experiencia interactiva de SovraGov — recorré el proceso de emisión y verificación de credenciales en tiempo real.

Cómo funciona en la práctica

Un ciudadano recibe una credencial verificable de su gobierno local que confirma su identidad y domicilio, almacenada en su billetera digital en el celular.

Cuando necesita acceder a un servicio de salud administrado por el gobierno provincial, presenta la credencial desde su billetera. El sistema de salud verifica la firma criptográfica contra la clave pública del gobierno municipal. Si coincide, el ciudadano queda verificado. Sin formularios. Sin esperas. Sin llamadas entre oficinas.

La misma credencial sirve para inscripción educativa, trámites impositivos, apertura de cuenta bancaria o cualquier servicio que necesite confirmar la identidad de la persona. Cada verificador confirma la autenticidad de forma independiente con la misma prueba matemática. El ciudadano nunca pierde el control de sus datos.

El efecto red: por qué escala

Esta arquitectura se vuelve más poderosa a medida que más instituciones participan. Cada nuevo gobierno que emite credenciales verificables le agrega valor a la billetera de cada ciudadano. Cada nuevo verificador hace que la credencial sea más útil.

En América Latina, múltiples jurisdicciones están implementando esta infraestructura de forma simultánea. Un gobierno estatal redujo los pasos burocráticos un 30 por ciento. Un municipio digitalizó más de 100 servicios ciudadanos en cuestión de meses. La tecnología es la misma en todos los casos porque está construida sobre estándares abiertos (W3C Verifiable Credentials y Decentralized Identifiers), lo que significa que las credenciales de una implementación son verificables por cualquier otra.

La infraestructura de credenciales entre gobiernos sirve a todo el ecosistema, porque cada institución que se suma hace que las credenciales de todas las demás sean más útiles.

Discutimos este tema en profundidad en el Sovra Podcast #03 — Luis Papagni: Evolución de la transformación digital en América Latina

Quién se beneficia y cómo

Los ciudadanos pasan de demostrar su identidad en cada puerta a verificarse una vez y usar esa verificación en todos lados. Una sola billetera reemplaza decenas de cuentas, contraseñas y visitas presenciales.

Los gobiernos dejan de mantener sistemas de identidad costosos y redundantes. Se apoyan en credenciales emitidas por otras instituciones de confianza, reduciendo costos, tiempos de procesamiento y errores manuales.

El sector privado — bancos, fintechs, aseguradoras, empleadores — puede verificar credenciales emitidas por gobiernos sin construir integraciones directas con bases de datos gubernamentales.

Hacia dónde va esto

La verificación de credenciales entre gobiernos ya está en funcionamiento en varias jurisdicciones de América Latina, con más planificadas para 2026. El enfoque funciona. La variable pendiente es qué tan rápido crece la red.

Cada gobierno que se suma hace que la billetera sea más útil. Cada tipo de credencial que se agrega (registro civil, educación, salud, licencias profesionales) hace que la infraestructura sea más completa. Cada implementación hace que la siguiente sea más fácil y más valiosa.

Para los millones de ciudadanos de la región que ya interactúan con alguna forma de identidad digital gubernamental, el camino hacia una credencial única y reutilizable es más corto de lo que la mayoría piensa.

Para profundizar

• Cómo funcionan las credenciales verificables: la guía completa — Guía técnica de 25 secciones sobre VCs, DIDs, pruebas de conocimiento cero y divulgación selectiva

• Casos de uso gubernamentales para identidad reutilizable — Identidad ciudadana, beneficios sociales, licencias, documentos fiscales, verificación entre organismos

• W3C Verifiable Credentials Data Model v2.0 — El estándar abierto detrás de la interoperabilidad entre gobiernos

• Probá la experiencia interactiva de SovraGov — Recorré el proceso de emisión y verificación en tiempo real

Si esta edición te resultó útil, compartila con alguien. Cuantas más personas entiendan esta arquitectura, más rápido se adopta.

Subscribe now

The Identity Brief es publicado por Sovra. Construimos infraestructura de identidad reutilizable para gobiernos y ciudadanos en toda América Latina.

Read in English

Durante años, la verificación de identidad digital se apoyó en una idea simple: si el documento parece auténtico y la persona coincide con la foto, es confiable. Ese modelo funcionó mientras falsificar requería tiempo, habilidad y recursos. Esa premisa dejó de ser válida.

La IA generativa permite producir rostros sintéticos, documentos falsificados y voces clonadas con una calidad y escala que supera la capacidad de verificación convencional.

Los deepfakes ya representan uno de cada cinco intentos de fraude biométrico. Los ataques de inyección — donde medios sintéticos se insertan directamente en los sistemas de verificación, sin pasar por la cámara — crecen un 40% anual. Y una reciente filtración en Infutor expuso 676 millones de registros de identidad en Estados Unidos: el tipo de datos que vuelve la suplantación directa.

No son incidentes aislados. Representan un cambio estructural en el panorama de amenazas. Y la respuesta de gran parte de la industria ha sido invertir en mejor detección: verificaciones de vida más sofisticadas, análisis biométrico más profundo, IA entrenada para detectar IA.

El dilema de la detección

La detección de veracidad tiene una asimetría inevitable: cada mejora entrena al fraude para evadirla. El atacante solo necesita acertar una vez; el verificador debe acertar siempre.

Gartner proyecta que para 2026 el 30% de las empresas dejará de considerar la verificación facial confiable por sí sola. La biometría no desaparece, pero deja de ser suficiente como señal única.

Un modelo de verificación diferente

Existe una alternativa. Las credenciales verificables son documentos digitales firmados criptográficamente por la institución emisora cuya validez se comprueba matemáticamente, sin inspección visual ni IA. Un deepfake resulta irrelevante en un sistema que no necesita mirar rostros.

Este modelo también resuelve un segundo problema que la detección no puede: la minimización de datos. Mediante divulgación selectiva y pruebas de conocimiento cero, un titular puede demostrar atributos específicos sin revelar los datos subyacentes. Esto reduce la superficie de ataque no solo para el fraude sino también para las filtraciones de datos. No se puede robar lo que nunca se transmitió.

Dónde está sucediendo

La regulación eIDAS 2.0 de la Unión Europea exige que los 27 estados miembros ofrezcan a los ciudadanos una billetera de identidad digital antes de diciembre de 2026. La implementación de referencia ya está en fase de pruebas, con soporte para emisión de credenciales, presentación online y offline, y firmas electrónicas cualificadas.

Más de una decena de estados de EE. UU. ya aceptan licencias digitales en aeropuertos, y cerca de 18 han lanzado o están desplegando credenciales móviles construidas sobre ISO/IEC 18013-5, para más de 5 millones de ciudadanos.

En América Latina, varios gobiernos han avanzado más. El estado de Nuevo León en México desplegó identidad digital verificable en sus servicios públicos, logrando una reducción del 80% en tiempos de procesamiento y del 30% en carga burocrática. La provincia de Salta en Argentina emitió credenciales digitales verificables para 1,4 millones de ciudadanos, transformando el acceso a salud, educación y servicios administrativos — incluyendo comunidades donde la oficina gubernamental más cercana estaba a horas de viaje por carretera. El municipio de Luján de Cuyo digitalizó más de 100 servicios en meses, reduciendo requisitos en un 66% y tiempos de resolución en un 45%.

Desde el equipo

Estudiamos y construimos infraestructura de identidad todos los días. Este newsletter es donde compartimos lo que vamos aprendiendo con quienes trabajan en identidad, servicios públicos e infraestructura de confianza.
Si querés verlo en práctica, podés explorar la demo en sovra.io.

Si es tu primera vez acá: Empezá con ¿Qué pasa después de que se emite una credencial verificable? para la base técnica, o escuchá nuestro último podcast con Pedro Alessandri sobre QuarkID para una historia de implementación real.

Vale la pena leer

Deepfake Financial Fraud: The Global Regulation of AI-Driven Scams — Columbia Institute of Global Politics & Data & Society Research Institute. Un informe de política sobre el ecosistema de estafas, quién las facilita y por qué la responsabilidad debe pasar de los individuos a las instituciones. El análisis más completo del problema que hemos visto este año.

The Identity Brief es una publicación de Sovra. Construimos infraestructura de identidad reutilizable para gobiernos y ciudadanos en América Latina.

Subscribe now