Identificar no es autenticar. Y esa diferencia cambia todo.
Durante años, el Estado digitalizó trámites sobre una idea simple: si alguien entra con su usuario y contraseña, es quien dice ser y puede hacer lo que pide. Esa idea ya era imprecisa para las personas. Con agentes de inteligencia artificial actuando en nuestro nombre, deja de funcionar.
Imaginemos a una persona que le pide a un asistente de inteligencia artificial que renueve un beneficio previsional, consulte sus cuentas bancarias y le avise si vence algún impuesto. No es ciencia ficción: los agentes ya consultan sistemas, completan formularios y ejecutan tareas. La pregunta es cómo se presenta ese agente frente al organismo que tiene que atenderlo. Aunque existen mecanismos de delegación, en muchos servicios la respuesta más común sigue siendo la peor: con el usuario y la contraseña de la persona. Para el sistema, quien opera es el ciudadano. Si el agente usa las mismas credenciales, no hay manera confiable de distinguir que fue un agente, qué agente fue, quién lo autorizó ni para qué.
Ese escenario obliga a separar tres preguntas que durante mucho tiempo tratamos como una sola. Una cosa es saber quién es el ciudadano. Otra es saber qué agente está actuando en su nombre. Y una tercera es comprobar que ese agente está autorizado para realizar esa operación. Para responderlas hay que volver a una distinción básica que la digitalización del Estado fue borrando.
Tres funciones que no son lo mismo
Identificar es establecer quién es una persona y contrastarlo con una fuente confiable, como hace el RENAPER cuando emite un documento. Autenticar es comprobar que quien intenta ingresar a un sistema corresponde a esa identidad declarada, mediante una contraseña, un código o una validación biométrica. Autorizar es definir qué puede hacer esa persona una vez adentro, porque estar correctamente identificado y autenticado no habilita a consultar cualquier dato ni a realizar cualquier operación. Son funciones distintas y cada una necesita sus propios mecanismos de confianza.
En la práctica, muchos servicios digitales tienden a resolver estas funciones de manera poco diferenciada: quien entra con la credencial correcta suele quedar identificado, autenticado y autorizado a la vez. Mientras del otro lado había siempre una persona, el atajo era tolerable. Cuando puede haber un programa actuando por delegación, se convierte en un problema de seguridad y de responsabilidad.
Un Estado con identidad y muchas puertas de entrada
Argentina tiene una base de identificación construida durante décadas alrededor del RENAPER, que emite el DNI y valida la identidad de las personas. Sobre esa base, distintos organismos desarrollaron sus propias credenciales, como la clave fiscal de ARCA, la Clave de la Seguridad Social de ANSES o la cuenta de Mi Argentina, cada una con distintos niveles de validación. Autenticar, la plataforma de autenticación central del Estado, nació para ordenar ese mapa: conecta esos proveedores con las aplicaciones y, desde la Resolución 216/2018, también pueden usarla empresas y entidades privadas. Fue un paso importante. Avanzamos en integrar distintas puertas de entrada, pero todavía tenemos pendiente construir un ecosistema de identidad verdaderamente interoperable: una misma persona sigue usando varias credenciales con un mismo Estado, y muchas veces tiene que volver a acreditar lo que otra institución ya conoce.
La identidad digital debería funcionar como una infraestructura transversal y no como algo que cada organismo resuelve por su cuenta. Eso no implica una única aplicación ni una gran base de datos con toda la información personal, sino estándares interoperables que permitan reconocer identidades y establecer relaciones de confianza entre instituciones, con la protección de datos personales como condición de diseño.
Y tiene que ser proporcional al riesgo. Consultar información pública no es lo mismo que modificar datos personales o autorizar una operación financiera. Marcos como los niveles de garantía de eIDAS en Europa o la guía de identidad digital del NIST en Estados Unidos se organizan alrededor de esa idea: más control donde hay más riesgo, sin convertir cada interacción en un obstáculo.
Lo que aprendimos con Finanzas Abiertas
Cuando en la SICyT tuvimos a cargo el proyecto del Sistema de Finanzas Abiertas en Mi Argentina, el problema central no fue técnico en el sentido estrecho: fue resolver cómo una persona autoriza a un tercero a acceder a su información financiera de manera explícita, acotada y revocable. Eso exigió trabajar a la vez sobre identidad, autenticación y consentimientos, y entender que el consentimiento no es un casillero que se marca una vez, sino una relación con alcance, plazo y posibilidad de retirarse.
Esa experiencia ofrece un antecedente concreto para pensar uno de los grandes desafíos de los agentes de inteligencia artificial: cómo otorgar, limitar, verificar y revocar permisos cuando un tercero actúa en nuestro nombre. Un consentimiento en finanzas abiertas permite autorizar a un tercero a acceder a determinada información, con un alcance y un plazo definidos. Esa experiencia ofrece elementos para pensar mecanismos de delegación más amplios. Con los agentes el paso es mayor, porque ya no se trata solo de acceder a datos sino de ejecutar operaciones. Quien ejecuta la operación puede ser un software que actúa de manera autónoma, pero cuya identidad, responsabilidad y autorización deben estar vinculadas a una persona u organización. La lógica de fondo, sin embargo, es la misma.
De mostrar documentos a demostrar atributos
La otra transformación tiene que ver con qué información compartimos. Para acreditar una condición solemos presentar un documento completo, aunque quien lo recibe no necesite todos esos datos: un comercio que tiene que verificar que alguien es mayor de edad no necesita conocer su domicilio.
Las credenciales digitales verificables permiten abordar este problema de otra manera. El estándar Verifiable Credentials 2.0 del W3C define cómo emitirlas, presentarlas y verificarlas de forma interoperable, y la billetera de identidad digital que está desplegando la Unión Europea muestra que no es una discusión teórica. La identidad digital pasa así de identificar a una persona a permitirle demostrar atributos concretos, compartiendo solo lo necesario.
El mismo modelo ayuda con los agentes: una persona puede entregarle a un agente una credencial que diga qué está autorizado a hacer, sin entregarle su identidad completa. La credencial no otorga el permiso por sí sola: sirve para acreditarlo, y es el sistema que la recibe el que tiene que validar su alcance y su vigencia.
Identidades para agentes
Un agente que actúa en nombre de una persona necesita una identidad propia, distinta de la humana pero vinculada a ella mediante un mecanismo verificable de delegación. Tiene que poder identificarse como agente, demostrar quién lo controla, acreditar qué permisos recibió y operar únicamente dentro de esos límites. Y del otro lado, el sistema tiene que poder registrar qué hizo, con qué identidad, bajo qué autorización y con qué resultado, y permitir que la persona revoque esos permisos en cualquier momento.
Volviendo al ejemplo inicial: el organismo previsional debería poder distinguir entre el ciudadano, el asistente que actúa por él y el permiso específico para gestionar esa renovación y no otra cosa. El banco que recibe la consulta del mismo asistente necesita exactamente lo mismo. Si cada entidad, pública o privada, resuelve por su cuenta la identidad y los permisos de los agentes, vamos a repetir la fragmentación que hoy tenemos con las credenciales humanas. Si el agente se equivoca o es comprometido, tiene que quedar claro que fue el agente, con qué mandato, y debe ser posible cortarle el acceso sin que la persona pierda el suyo. Nada de eso es posible si el agente opera con la contraseña del ciudadano.
La discusión técnica ya está abierta: organismos de estandarización como la OpenID Foundation trabajan sobre identidad y autorización para agentes. Lo que falta es la decisión de tratarlo como infraestructura común, y no esperar a que cada organismo o cada empresa lo resuelva cuando el problema ya esté encima.
Lo que el Estado debería construir
Si la identidad digital va a sostener la próxima etapa de los servicios, públicos y privados, el Estado necesita avanzar en tres frentes, pensados desde el inicio como infraestructura para todo el ecosistema. Primero, una capa de identidad interoperable, apoyada en el RENAPER, que permita a los organismos reconocerse mutuamente y aplicar niveles de garantía proporcionales al riesgo. Segundo, un ecosistema de credenciales verificables que permita acreditar atributos sin exponer más información de la necesaria. Y tercero, un marco de identidad y delegación para agentes que defina cómo se registran, cómo se vinculan a una persona u organización, cómo se acotan sus permisos, cómo se audita lo que hacen y cómo se revocan.
Ninguno de estos frentes se resuelve solo con tecnología ni solo con normas. Requieren reglas, responsabilidades claras y supervisión, y también una infraestructura concreta, operada con criterios de servicio público, sobre la que organismos, empresas y desarrolladores puedan construir.
La transformación digital no debería medirse por la cantidad de aplicaciones disponibles ni de usuarios registrados, sino por la facilidad con que una persona puede ejercer derechos, acceder a servicios y acreditar información de manera segura. Durante años el desafío fue que pudiéramos demostrar digitalmente quiénes somos. El próximo será establecer quién puede actuar por nosotros, para qué y bajo qué condiciones. Y para eso, antes que nuevas aplicaciones, necesitamos construir confianza.