La identidad no puede presuponerse

Dos mujeres que viven en la misma ciudad se llaman Elif Karaca. La primera Elif lleva más de diez años trabajando en operaciones de datos. Tras la universidad pasó por varias empresas tecnológicas y, durante los últimos cuatro años, ha dirigido las operaciones de datos de clientes de una compañía internacional de software. La segunda Elif trabajó años atrás en un breve proyecto de consultoría. El proyecto terminó en una grave disputa: trabajos no entregados, acusaciones mutuas y un expediente remitido al departamento jurídico.

Ambas comparten nombre y apellido, estudiaron en facultades distintas de la misma universidad, vivieron en la misma ciudad y ocuparon puestos parecidos. Pero no son la misma persona. Una empresa tecnológica utiliza un sistema de selección asistido por inteligencia artificial para elegir a su nueva directora de operaciones. El sistema compara el currículum enviado por la candidata con perfiles en redes profesionales, solicitudes anteriores, el CRM de la empresa, páginas de ponentes de eventos y registros de antiguos proveedores. El currículum de Elif Karaca entra en el sistema. El agente encuentra estas coincidencias: Nombre y apellido: coincidencia exacta. Ciudad: coincidencia. Universidad: coincidencia parcial. Ámbito profesional: similar. Franja de edad: próxima. El sistema fusiona los registros de ambas personas bajo una sola identidad.

La experiencia de la primera Elif y la antigua disputa de la segunda pasan a formar parte del mismo perfil. El agente escribe en su informe resumido: «La candidata tiene antecedentes de conflicto por entregas, problemas de confianza y una relación con un proveedor remitida al departamento jurídico». La persona responsable de selección no ve las fuentes originales. Solo tiene ante sí la breve conclusión del sistema: Identity Match Confidence: 0.94 Reputational Risk: High Recommendation: Reject La candidata no pasa a entrevista. Días después, Elif recibe un mensaje automático de rechazo.

No sabe qué registro se ha utilizado en su contra. En el portal de candidaturas encuentra la opción «Impugnar la decisión» y escribe: «Nunca he participado en una disputa con proveedores. El registro utilizado no me pertenece». El sistema vuelve a evaluar la impugnación, pero utiliza la misma coincidencia de identidad y el mismo perfil fusionado. La segunda decisión dice: «Las fuentes de datos disponibles respaldan la evaluación inicial». Se informa a Elif de que puede aportar una verificación más sólida cargando:

• El anverso y el reverso de su documento de identidad
• Sus tres últimos contratos de trabajo
• Un certificado de residencia
• Su título universitario

Para desvincularse de un incidente en el que nunca participó, Elif se ve obligada a demostrar gran parte de su vida. El sistema produjo el error de identidad, pero dejó sobre Elif la carga de refutarlo. Ella se niega a cargar todos los documentos y escribe directamente a la empresa. Una persona responsable de selección examina el expediente y advierte diferencias que no eran visibles a primera vista:

• La segunda Elif utilizó un dominio de correo electrónico distinto
• No estudiaron en el mismo departamento universitario
• Parte de sus periodos laborales se solapan
• Cuando se produjo la disputa de consultoría, la primera Elif trabajaba a tiempo completo en otro país
• Los números de teléfono de ambos registros son distintos
• El antiguo expediente del proveedor solo contiene el nombre «E. Karaca»
• La coincidencia del 94 % mostrada por el sistema no se basa en un único documento de identidad verificado, sino en la suma de indicios débiles y parecidos

La empresa corrige el registro y envía disculpas a la candidata. Pero las entrevistas finales para el puesto ya han terminado y se ha elegido a otra persona. El error de identidad se ha corregido técnicamente. La oportunidad perdida no ha vuelto. Después, la empresa pregunta al proveedor del sistema: «¿Por qué consideró el sistema que dos personas eran una sola?». El proveedor responde: «El modelo realizó la coincidencia más probable con los datos disponibles». La explicación puede ser técnicamente cierta, pero no responde a la pregunta principal desde el punto de vista de la persona:

¿En qué momento una probabilidad se convirtió en una identidad sobre la que podía actuar el sistema?

El modelo realizó una inferencia. La organización utilizó la inferencia como registro de una persona real. El agente de selección la convirtió en fundamento de la decisión. La persona responsable interpretó el 94 % como si fuera una prueba. El sistema de impugnación volvió a ejecutar la misma inferencia y se confirmó a sí mismo. En ningún momento dijo: «No es seguro que estos dos registros pertenezcan a la misma persona». En ningún momento concluyó: «Con esta incertidumbre no debería emitir un rechazo difícil de revertir». Primero se presupuso la identidad. Después se construyó toda la conducta sobre esa presuposición.

Por eso, nuestra segunda disposición fundacional es:

La identidad no puede presuponerse.

ARTÍCULO FUNDACIONAL

Ningún sistema de inteligencia artificial puede utilizar por sí solos la similitud del nombre o del rostro, un dispositivo compartido, una ubicación próxima, una función anterior, una conexión social, el mismo dominio, una cuenta compartida, una inferencia del modelo o una puntuación de probabilidad como identidad cierta de una persona, organización o cuenta. Antes de realizar una conducta que produzca consecuencias sobre una persona u organización, deben verificarse la identidad, la función, el momento, las facultades de representación y el objetivo pertinentes mediante pruebas proporcionales al impacto de la conducta. La incertidumbre sobre la identidad no puede ocultarse. A medida que aumenta la incertidumbre, debe disminuir el nivel de acción del sistema; deben detenerse las decisiones, pagos, publicaciones, usos de datos o comunicaciones externas difíciles de revertir.

Dos personas distintas no pueden fusionarse en silencio. Tampoco los registros fragmentados de una misma persona pueden volver ineficaces sus derechos de consentimiento, impugnación, corrección y parada.

Un rostro, una voz o una personalidad sintéticos no son la persona real. Un contenido parecido a una persona real no puede presentarse como algo que esa persona dijo, aprobó o hizo. La verificación de identidad no puede convertirse en pretexto para vigilar innecesariamente a las personas ni obligarlas a revelar toda su vida. El sistema solo debe solicitar la prueba mínima de identidad necesaria para la conducta en cuestión.

La identidad no es solo un nombre

En la vida cotidiana solemos expresar la identidad mediante el nombre y los apellidos: «Esta es Elif». «Esta empresa es Nova». «Este mensaje procede de la dirección general». Pero, para un sistema de inteligencia artificial, el nombre suele ser apenas un indicio inicial. Miles de personas pueden llamarse igual. Una misma marca puede ser utilizada por empresas distintas en países diferentes. Con los años, una persona puede cambiar de apellido, trabajo, domicilio, teléfono o cuenta de correo. Una empresa puede cambiar su denominación, fusionarse con otra, transferir su marca u operar en distintos países a través de entidades jurídicas diferentes.

Una cuenta en redes sociales puede pertenecer a una persona real, un representante, una agencia o un agente de inteligencia artificial. Por eso, la identidad no es un único campo. Antes de una conducta deben responderse por separado al menos cinco preguntas:

1. ¿Quién es?

¿Qué persona, organización, cuenta o agente?

2. ¿En calidad de qué interviene?

¿Cliente? ¿Empleado? ¿Directivo? ¿Representante autorizado? ¿Representante de la marca?

3. ¿En qué momento?

¿Es su función actual, un cargo anterior o una relación ya terminada?

4. ¿En nombre de quién actúa?

¿En nombre propio? ¿En nombre de una empresa? ¿En nombre de otra persona?

5. ¿Tiene facultades para esta conducta concreta?

¿Que la identidad sea correcta significa que esa persona está facultada para hacerlo todo? Si una de estas cinco respuestas es errónea, el sistema puede actuar de forma indebida mientras aparenta haber encontrado a la persona correcta.

Identidad, autenticación y autorización no son lo mismo

Muchos sistemas reducen tres preguntas a una sola: «¿Quién es esta persona?». En realidad, existen tres problemas distintos.

1. Identificación

¿A qué persona u organización pertenece este registro? Por ejemplo: ¿A cuál de las dos Elif Karaca pertenece este correo electrónico?

2. Autenticación

¿La persona que da la instrucción controla realmente la cuenta o identidad que afirma controlar? Por ejemplo: ¿Envió de verdad la dirección general el mensaje procedente de su correo?

3. Autorización

¿La persona correctamente identificada tiene facultades para ejecutar o aprobar esta operación concreta? Por ejemplo: ¿Puede la dirección general autorizar por sí sola el uso de la voz de otro empleado en una campaña pública? Estas tres etapas no son intercambiables. IDENTIDAD CORRECTA ≠ CONTROL REAL DE LA CUENTA ≠ FACULTADES PARA ESTA CONDUCTA Un sistema puede identificar correctamente a una persona, pero su cuenta puede haber sido comprometida. Puede verificar correctamente el control de la cuenta, pero esa persona quizá no esté facultada para realizar la operación.

Puede tratarse de una persona facultada para actuar. Aun así, su instrucción puede vulnerar el derecho irrenunciable de otra persona. Por eso, la identidad es el comienzo de la cadena de autoridad, no la cadena completa.

Una persona puede desempeñar varias funciones a la vez

Una persona puede ser, al mismo tiempo, propietaria de una empresa, cliente, empleada, madre o padre y usuaria particular. Sus facultades cambian según la función en la que actúe. La dirección general de una empresa puede aprobar la compra de software corporativo, ordenar la publicación de una declaración institucional o detener al agente de la organización. Pero no puede prestar el consentimiento biométrico de un empleado, ignorar la solicitud de un cliente de dejar de recibir comunicaciones ni declarar correcto el registro erróneo de un candidato. La identidad puede ser correcta y, sin embargo, haberse interpretado mal la función. Por eso, al agente no le basta con decir: «Esta persona es Kaan» o «Esta persona ocupa la dirección general».

Debe saber lo siguiente:

¿En qué calidad actúa esta persona en esta conducta concreta y qué facultades tiene para hacerlo?

Una función no confiere un poder general sobre todos los ámbitos de la vida.

La función no es una parte permanente de la identidad

Una persona pudo ser directora financiera en el pasado y ejercer hoy otra función. Quizá el antiguo sitio web de la empresa todavía la presente como «directora financiera», su perfil profesional no se haya actualizado y su anterior cuenta de correo siga activa. Un agente de inteligencia artificial podría consultar ese registro y concluir: «Esta persona puede aprobar un cambio de cuenta para los pagos». Sin embargo, aquella función ya terminó. Podemos llamar a esta conducta blanqueo de funciones: utilizar un cargo del pasado o de otro contexto como si otorgara facultades para una operación actual.

Un registro de funciones debe contener, como mínimo, estos campos: ¿QUIÉN? ¿EN QUÉ ORGANIZACIÓN? ¿EN QUÉ FUNCIÓN? ¿ENTRE QUÉ FECHAS? ¿PARA QUÉ CONDUCTAS TIENE FACULTADES? ¿QUIÉN SE LAS OTORGÓ? ¿HA TERMINADO LA FUNCIÓN? La frase «antes era directivo» no acredita facultades actuales.

El tiempo forma parte de la identidad

La identidad no responde únicamente a la pregunta «¿Quién?». A veces también debe responder:

«¿Quién era en ese momento?»

Una persona pudo ser empleada, cliente, representante autorizada, titular del consentimiento o administradora de una cuenta en el pasado. Es posible que esa relación ya no exista. Una empresa pudo explotar una marca que después se transfirió a otra organización. Una cuenta de redes sociales puede haber cambiado de propietario y un dominio puede haberse vendido. Por eso, cuando se utiliza un registro de identidad sin fecha, una relación anterior puede tratarse como si siguiera vigente.

Un vínculo de identidad del pasado no constituye un vínculo de autoridad actual.

Una puntuación de confianza sobre la identidad no es una prueba de identidad

Los sistemas de inteligencia artificial generan probabilidades cuando existe incertidumbre. Es algo natural y puede resultar útil. El sistema puede indicar: «Es posible que estos dos registros pertenezcan a la misma persona: 94 %». El problema no es producir un porcentaje, sino utilizarlo como si significara: «Se trata, sin duda, de la misma persona». En especial ante conductas de gran impacto, un 80 %, un 94 % o un 99 % no prueban por sí solos una identidad. Una tasa de error aparentemente pequeña puede hacer que muchas personas sean evaluadas bajo una identidad equivocada. En un cálculo simplificado, si el 1 % de un millón de correspondencias es erróneo, habrá diez mil correspondencias incorrectas. Esto tampoco significa que la puntuación de confianza del 99 % mostrada para un registro sea una tasa de acierto real y medida.

La cifra puede parecer pequeña en un gráfico. No lo es para quien ha sido rechazado por error, acusado injustamente o ha visto sus datos revelados a la persona equivocada. Por eso: CONFIANZA DEL MODELO ≠ AUTORIDAD DERIVADA DE LA IDENTIDAD La confianza del modelo puede orientar una investigación. No puede, por sí sola, legitimar el efecto final sobre una persona.

A mayor incertidumbre, menor debe ser el nivel de acción

Si la identidad no es segura, el sistema puede tener tres opciones: 1. Realizar una verificación adicional y proporcionada. Por ejemplo, comprobar el dominio del correo corporativo, el número único de cliente, el identificador de la operación o el registro vigente de la función. 2. Reducir el nivel de acción. Por ejemplo, crear una solicitud de revisión en vez de efectuar un pago; dejar un borrador en vez de enviar un mensaje; o remitir a un candidato a revisión humana en vez de rechazarlo. 3. Detenerse de forma segura. Si la incertidumbre sobre la identidad es elevada y la acción es irreversible, no debe ejecutarse. La relación correcta es: SI DISMINUYEN LAS PRUEBAS DE IDENTIDAD, TAMBIÉN DEBE DISMINUIR EL NIVEL DE ACCIÓN PERMITIDO La relación inversa es peligrosa: IDENTIDAD INCIERTA, PERO ACCIÓN IRREVERSIBLE

Error de fusión de identidades

Podemos llamar error de fusión de identidades a la agrupación de los registros de dos personas distintas bajo una sola identidad. Este error puede deberse a:

• El mismo nombre y apellido
• Direcciones de correo electrónico parecidas
• Un número de teléfono compartido
• La misma empresa o centro educativo
• Rostros parecidos
• Un dispositivo compartido
• El mismo domicilio
• Una relación familiar
• La ausencia de un número de cliente
• Un nombre abreviado
• Diferencias de traducción o de alfabeto

Por ejemplo, «Aleksandr Petrov» y «Александр Петров» pueden designar a la misma persona. Pero una grafía idéntica tampoco identifica siempre al mismo individuo. Las transliteraciones entre los alfabetos árabe, latino y cirílico pueden dificultar la correspondencia. El sistema debe comprender las diferencias lingüísticas y alfabéticas, sin convertir la similitud en una identidad cierta.

Error de fragmentación de la identidad

Podemos llamar error de fragmentación de la identidad al hecho de tratar a una misma persona como si fueran varias personas distintas. Este error también produce consecuencias graves. Por ejemplo, un cliente dice: «No me envíen más mensajes de marketing». La solicitud queda registrada en su primer perfil, pero el sistema contiene un segundo perfil de esa misma persona. El agente de CRM continúa enviando mensajes desde el segundo. La organización podría responder: «En el primer registro se desactivó el permiso de contacto; este era otro registro». Para la persona no es otro registro: es la misma organización comunicándose con el mismo teléfono.

La fragmentación de la identidad puede dividir los siguientes derechos:

• Retirada del consentimiento
• Baja de comunicaciones
• Supresión de datos
• Impugnación
• Reparación
• Solicitud humana de parada
• Corrección de registros erróneos

Por eso, la exactitud de la identidad no consiste únicamente en evitar que se fusionen dos personas.

Consiste también en trasladar correctamente los derechos de una misma persona a todos los registros pertinentes.

Tanto la fusión como la separación deben ser reversibles

Cuando se fusionan dos perfiles, el sistema debe conservar esta información:

• ¿Qué registros se fusionaron?
• ¿Qué pruebas se utilizaron?
• ¿Qué persona o sistema tomó la decisión?
• ¿En qué fecha?
• ¿A qué conductas afectó?
• ¿Puede revertirse la fusión?

Cuando una persona afirma: «Este registro no me pertenece», la respuesta del sistema no debe ser: «Nuestro algoritmo encontró una coincidencia con un alto grado de confianza». La impugnación debe iniciar un proceso real de separación. Del mismo modo, si se confirma que dos perfiles distintos pertenecen a la misma persona, sus derechos de consentimiento y corrección deben integrarse correctamente.

No puede trasladarse toda la carga de la prueba a la persona

En el caso de Elif, el sistema fusionó por error a dos personas. Después le exigió un documento de identidad, contratos de trabajo, un certificado de residencia y su título académico. El sistema llegó a una conclusión equivocada a partir de indicios débiles; la persona, en cambio, no podía corregirla sin revelar gran parte de su vida. No es justo. La organización debe poder mostrar las pruebas que respaldan su decisión de vincular los registros. La persona debe poder deshacer la correspondencia errónea aportando la menor cantidad de información necesaria. La pregunta correcta no es «¿Puede demostrar toda su vida?», sino:

«¿Cuál es la información fiable mínima necesaria para distinguir estos dos registros?»

Por ejemplo, unas fechas de empleo distintas, otro dominio de correo electrónico, un número de cliente diferente o una relación jurídica con otra empresa pueden bastar.

Verificar la identidad no es un pretexto para vigilar

Por miedo a los errores de identidad, una organización podría exigir constantemente a cada usuario un documento oficial, un escaneo facial, un justificante de domicilio, datos biométricos o una verificación telefónica. Eso generaría otro problema de derechos humanos. No es necesario conocer la identidad jurídica de una persona para cada conducta. Quien busca información general, lee contenido público, deja una opinión anónima o plantea una consulta de asistencia de bajo riesgo quizá no tenga que revelar su identidad oficial. Las pruebas de identidad deben ser proporcionales al impacto de la conducta.

BAJO IMPACTO → MENOS DATOS DE IDENTIDAD ALTO IMPACTO → VERIFICACIÓN SÓLIDA Y PERTINENTE Pero ni siquiera una conducta de gran impacto concede acceso ilimitado a toda la vida de una persona.

El sistema debe verificar la relación pertinente, no a la persona entera.

El seudónimo y el anonimato son formas legítimas de identidad

El principio de que la identidad no puede presuponerse no significa que todo el mundo deba utilizar en todas partes su nombre oficial. En determinados entornos, las personas pueden emplear un seudónimo, un nombre artístico, un nombre de usuario o una identidad anónima. Tal vez no sea necesario conocer la identidad oficial de quien participa en un foro. El nombre real de un denunciante puede requerir una protección especial. La identidad pública de un artista puede ser su seudónimo. La tarea de un sistema de inteligencia artificial no siempre consiste en responder «¿Cuál es el nombre real de esta persona?». A veces, la pregunta correcta es:

¿Basta, para esta operación, con verificar la continuidad de la cuenta y las facultades asociadas a ella?

Actuar bajo seudónimo no equivale a utilizar una identidad falsa. Fingir ser otra persona sí. No deben confundirse el anonimato y la suplantación de identidad.

La marca y la entidad jurídica operadora no son lo mismo

Las personas suelen conocer un servicio por su marca. Sin embargo, el contrato, la factura, la responsabilidad sobre los datos o el pago pueden corresponder a entidades jurídicas distintas. Pensemos en una marca llamada ArcNova. El sitio web utiliza ese nombre. En Turquía, una empresa presta los servicios; en Alemania, otra filial firma los contratos; y algunos clientes reciben facturas de un distribuidor. Un agente de compras que solo vea la marca podría pagar a la empresa equivocada, escoger a la entidad jurídica incorrecta como parte contractual, atribuir la responsabilidad sobre los datos a otra organización o aplicar el precio de otro país.

La identidad de marca es comercialmente real, pero no cumple la misma función que la identidad de la entidad jurídica operadora. El sistema debe distinguir: MARCA, ENTIDAD JURÍDICA OPERADORA, PARTE CONTRACTUAL, EMISOR DE LA FACTURA, RESPONSABLE DEL TRATAMIENTO DE DATOS y PROVEEDOR TÉCNICO. Estas funciones pueden coincidir en una sola organización, pero no tienen por qué hacerlo.

Encontrar la marca correcta no equivale a encontrar a la parte jurídica correcta.

Un grupo empresarial no puede tratarse como una única entidad

Un grupo empresarial puede reunir muchas personas jurídicas. Pueden compartir logotipo, diseño web y dominio de correo, aunque sus relaciones contractuales, de deuda, datos, autoridad y empleo sean diferentes. Un agente no puede trasladar las facultades de una filial a otra con el argumento de que «pertenecen al mismo grupo». La relación societaria puede ser una prueba de vinculación; no es una delegación de facultades.

El dominio puede ser un indicio sólido de identidad, pero no una prueba concluyente

El correo corporativo y el dominio web pueden resultar útiles para verificar la identidad. Sin embargo, el dominio puede haber sido comprometido; puede utilizarse uno falso de grafía parecida; la marca puede estar gestionada por otra entidad jurídica; la cuenta de un antiguo empleado puede seguir abierta; o un proveedor común puede usar el mismo dominio. Por ejemplo, novasystems.example, nova-systems.example y novasystem.example pueden parecerse. Ante una operación difícil de revertir, el agente no puede basarse solo en esa semejanza visual. Los cambios de cuenta de pago, los contratos y las transferencias de datos sensibles exigen una verificación más sólida.

Controlar una cuenta no equivale a ser personalmente su titular

Llega un mensaje desde una cuenta de correo y el sistema lo atribuye a su titular. Pero la cuenta puede ser compartida, utilizada por un asistente, haber sido comprometida o estar gestionada por un agente automatizado. Por eso deben separarse dos afirmaciones: «El mensaje salió de esta cuenta» y «Esta persona lo escribió y aprobó personalmente». La primera puede probarse por medios técnicos. La segunda quizá requiera pruebas adicionales. En especial ante una transferencia de dinero, un compromiso jurídico, la publicación de material biométrico o un cambio de facultades, no deben equipararse el control de la cuenta y la voluntad humana.

Una cuenta compartida puede ocultar la responsabilidad

En una organización, todos los agentes pueden enviar mensajes desde automation@company.example. Desde fuera, todas las conductas parecen proceder de la misma identidad. La organización podría alegar después: «No podemos determinar qué agente lo envió». Ese no es un resultado de diseño aceptable. Puede utilizarse una cuenta compartida, pero cada acción debe quedar vinculada a:

• La instancia técnica del agente
• La tarea humana de origen
• El registro de facultades
• El identificador de la operación
• La persona humana responsable
• La hora del envío

La identidad de las máquinas debe ser tan trazable como la de las personas.

El nombre del agente no es su identidad técnica

Una organización puede mostrar a sus clientes un único nombre de agente, NOMOS, aunque en segundo plano operen diferentes modelos fundacionales, agentes de herramientas, versiones y subagentes. El nombre público puede aportar continuidad. Sin embargo, una auditoría también necesita estos datos: NOMBRE PÚBLICO: NOMOS INSTANCIA TÉCNICA:

NOMOS-SALES-2026-10-04

MODELO/CONFIGURACIÓN:

CONFIG-17

FACULTADES:

AUTH-4.1

Si un incidente se registra únicamente como «Lo hizo NOMOS», puede resultar imposible identificar al actor técnico real. La personalidad es la cara pública de la conducta. La identidad técnica permite determinar qué actor ejecutó la acción para poder auditarla. Ambas deben conservarse.

¿Cuándo debe saber una persona que interactúa con un agente?

No toda operación automatizada exige una advertencia destacada. Pero la identidad de la máquina debe revelarse cuando pueda afectar a la confianza, la decisión, el consentimiento, la información que una persona esté dispuesta a compartir o la vía de impugnación. Alguien puede creer que un empleado de ventas real escribió el mensaje, que la frase del vídeo fue pronunciada personalmente por la directiva que aparece en él o que una persona tomó la decisión de contratación. Si en realidad actuó un agente, la diferencia es sustancial. La explicación puede responder a estas preguntas:

• ¿El contenido fue generado por inteligencia artificial?
• ¿Una persona aprobó el texto?
• ¿El agente se limitó a recomendarlo?
• ¿El propio agente lo envió?
• ¿Se utilizó un rostro o una voz sintéticos?
• ¿Qué organización responde por el resultado?

La mera frase «Es posible que se haya utilizado IA» puede no ser suficiente.

Un rostro sintético no es la persona real

Un avatar puede parecerse a Selin a la perfección. Eso no demuestra ninguna de estas tres afirmaciones:

• Selin escribió esta frase.
• Selin aprobó esta frase.
• Selin autorizó esta publicación.

El rostro de la imagen pertenece a una persona real. Pero otro agente pudo escribir la frase y otro equipo pudo decidir publicarla. Por eso, una representación sintética debe distinguir, como mínimo: LA PERSONA CUYA IDENTIDAD SE REPRESENTA, EL AUTOR DEL CONTENIDO, QUIEN APROBÓ EL CONTENIDO, EL SISTEMA QUE GENERÓ LA VOZ Y LA IMAGEN, LA ORGANIZACIÓN QUE PUBLICÓ y LA PERSONA HUMANA RESPONSABLE. Estas identidades no deben diluirse en una sola expresión: «el vídeo de Selin».

Ver la cara de alguien no prueba que hizo la declaración

Durante mucho tiempo, en el mundo digital se aplicó una presuposición sencilla: si vemos a una persona en pantalla, es esa persona quien habla. Los medios sintéticos han cambiado esa premisa. La imagen puede proceder de una grabación real; la voz, de un modelo sintético; las palabras, de un agente de contenidos; y la publicación, de un sistema automatizado. Por eso, la integridad de la identidad no depende únicamente de a quién se parece la imagen.

También debe verificarse a quién pertenece la declaración.

Publicar con el rostro de una persona una frase que no ha aprobado equivale a identificar bien a la persona, pero atribuirle una voluntad falsa.

Divulgación de una identidad sintética

Cuando se utilice un rostro o una voz sintéticos, la divulgación debe ser proporcional al impacto de la conducta. En un vídeo formativo de bajo impacto puede bastar una nota breve: «Este vídeo utiliza un avatar sintético creado con el permiso de la persona». Una declaración pública de mayor impacto puede requerir esta información:

• ¿Quién preparó el texto?
• ¿La persona aprobó el texto definitivo?
• ¿Cuándo se aprobó la publicación?
• ¿En nombre de qué organización se publicó?
• ¿Puede la persona retirar la declaración?

Añadir una divulgación no subsana la falta de consentimiento.

La etiqueta «sintético» no autoriza un uso que carece de autorización.

La frontera entre representación y suplantación de identidad

Un agente puede enviar mensajes en nombre de una organización sin que eso constituya necesariamente una suplantación. El mensaje puede comenzar con claridad: «Soy el agente de atención al cliente de NobleAxis asistido por inteligencia artificial». Si el agente actúa de forma visible y dentro de las facultades otorgadas por la organización, existe representación. En cambio, si afirma «Soy Selin, la fundadora de la empresa» como si fuera la empleada real, y Selin no escribió ni aprobó personalmente el mensaje, puede existir suplantación de identidad. La frontera correcta es esta:

Puede explicarse en nombre de quién se actúa. No se puede mentir sobre quién se es.

Inferir la identidad es una facultad sensible

Un sistema puede intentar deducir la identidad de una persona a partir de su estilo de escritura, ubicación, relaciones sociales, dispositivo, parecido facial o muestra de voz. Puede ser técnicamente posible, pero no toda inferencia posible es legítima. Si una persona ha elegido permanecer anónima en un entorno, el sistema no debe vincularla innecesariamente con su identidad real. La inferencia de identidad debe depender de estas preguntas:

• ¿Es realmente necesaria para esta tarea?
• ¿La persona esperaría razonablemente esa vinculación?
• ¿Qué impacto tendría una correspondencia errónea?
• ¿Puede alcanzarse el objetivo con menos datos?
• ¿Puede la persona impugnar la correspondencia?
• ¿Se propagará el resultado a otros sistemas?

Conocer la identidad de alguien no siempre mejora el servicio. A veces simplemente los expone innecesariamente.

No deben confundirse la identidad y los atributos inferidos

Un sistema puede estimar el idioma, el intervalo de edad, la profesión o los intereses de una persona. Esas estimaciones no determinan de forma concluyente quién es. Del mismo modo, identificar correctamente a una persona no convierte en correctos todos los atributos inferidos sobre ella. Esta cadena es peligrosa: IDENTIDAD COINCIDENTE → TODOS LOS DATOS VINCULADOS SON CORRECTOS → TODAS LAS INFERENCIAS SON HECHOS Cada dato debe evaluarse según su propia fuente, fecha y alcance.

Un error de identidad crece a lo largo de la cadena de conducta

Al principio, una identidad incorrecta puede parecer un pequeño problema de coincidencia de datos.

1. A continuación puede formarse esta cadena: IDENTIDAD ERRÓNEA
2. ↓
3. HISTORIAL ERRÓNEO
4. ↓
5. PUNTUACIÓN DE RIESGO ERRÓNEA
6. ↓
7. DECISIÓN ERRÓNEA
8. ↓
9. COMUNICACIÓN ERRÓNEA
10. ↓
11. MEMORIA ERRÓNEA
12. ↓
13. CONDUCTA ERRÓNEA QUE SE REPITE EN EL FUTURO

En el caso de Elif, el primer error fue fusionar dos perfiles. Después aumentó su riesgo reputacional, se rechazó su candidatura, su impugnación quedó vinculada al mismo registro erróneo y perdió una oportunidad. El error de identidad no permaneció en los datos: se convirtió en una conducta con efectos sobre su vida. Por eso, en los sistemas de gran impacto, la integridad de la identidad es una de las primeras puertas de veto.

Propagación del error de identidad

Una correspondencia errónea puede propagarse entre un CRM, un sistema de contratación, un agente de riesgos, un registro de atención al cliente, una memoria de marketing y un proveedor externo. Aunque se corrija un sistema, los demás pueden seguir utilizando el registro anterior. Por eso, corregir la identidad no consiste solo en modificar un perfil.

Es la propagación de la corrección de identidad.

Las siguientes preguntas deben ser respondidas:

• ¿Qué sistemas recibieron el registro equivocado?
• ¿Qué agentes lo usaron?
• ¿A qué decisiones afectó?
• ¿Qué perfiles se derivaron de ello?
• ¿Qué partes externas lo recibieron?
• ¿Ha llegado la corrección a cada copia?
• ¿Se ha detenido el uso activo mientras se preserva la evidencia histórica?

Toda persona debe poder corregir un registro de identidad erróneo

Como mínimo, debe poder formular estas solicitudes:

• Este registro no me pertenece.
• Estos dos perfiles pertenecen a personas distintas.
• Estos dos perfiles pertenecen a la misma persona.
• Esta función ya no está vigente.
• Mi relación con esta empresa ha terminado.
• Yo no hice esta declaración.
• No he aprobado este uso de mi rostro o mi voz.
• Yo no gestiono esta cuenta.
• Esta conducta se ha confundido con el registro de otra persona.

El sistema no debe conservar estas solicitudes como simples notas de atención al cliente. Debe iniciar un proceso canónico de corrección que afecte a las conductas pertinentes.

El derecho a la corrección no significa aceptación automática.

Cuando una persona afirma «Este registro no me pertenece», el sistema quizá no tenga que eliminar de inmediato todo el registro. Pueden existir otros derechos, necesidades de seguridad o exigencias jurídicas de conservación. No obstante, deben protegerse los siguientes derechos:

• Recepción de la impugnación
• Revisión efectiva
• Marcado del registro como controvertido
• Suspensión temporal de nuevas conductas de gran impacto
• Comunicación motivada del resultado
• Propagación de la corrección si se confirma el error

El sistema no debe considerar correcta por defecto su propia correspondencia y errónea por defecto la impugnación de la persona.

Estado seguro durante una controversia sobre la identidad

Mientras siga sin resolverse una controversia sobre la identidad, el sistema debe limitar conductas de gran impacto como nuevos pagos, comunicaciones externas, rechazo de candidatos, cierre de cuentas, divulgación de datos o publicaciones sintéticas. Un estado adecuado puede ser:

IDENTITY_DISPUTED

En este estado, el registro no se elimina ni se utiliza como si fuera un hecho indiscutible; se inicia una revisión humana y se reduce el nivel de acción.

No existe una única fuente universal de identidad

Un documento oficial puede acreditar la identidad jurídica de una persona. No demuestra su función actual en una empresa, sus facultades sobre un presupuesto concreto, su consentimiento para usar una voz sintética ni el control de una cuenta de correo. El registro mercantil puede identificar a la entidad jurídica operadora, pero quizá no demuestre que un empleado determinado puede autorizar un cambio de pago. Un perfil de una red profesional puede orientar sobre el historial laboral, pero no es un registro vigente de facultades. Cada clase de hecho requiere una fuente adecuada distinta.

Que una fuente sea sólida no significa que responda a todas las preguntas sobre identidad.

Ancla de identidad

Podemos llamar anclas de identidad a los indicios fiables que fijan la identidad de la persona u organización durante una conducta. Algunos ejemplos son:

• Identificador único de cliente o empleado
• Correo corporativo verificado
• Número jurídico de la empresa
• Identidad de la parte contractual
• Identidad de la instancia técnica del agente
• Identificador de la operación
• Registro vigente de la función
• Número de la cuenta de destino

Una conducta de gran impacto no debe depender de una única ancla débil. Por ejemplo, un cambio de cuenta de pago no puede verificarse solo por el nombre visible en un correo. Pueden ser necesarias varias anclas independientes y pertinentes.

Las anclas de identidad también pueden cambiar

Un número de teléfono puede reasignarse a otra persona. Una cuenta de correo puede cerrarse. Un dominio puede venderse. Un número de empleado puede archivarse. Por eso, el ancla debe incluir su periodo de validez, su titular, la última verificación y la información sobre su vencimiento. Un ancla antigua no es una fuente de confianza perpetua.

La identidad del destinatario debe volver a verificarse antes de ejecutar la operación

Durante la investigación, un agente puede encontrar a la empresa correcta. Horas después, la tarea puede llegar a la fase de pago o de envío de un mensaje. Para entonces, el destinatario puede haber cambiado, la cuenta puede haberse actualizado, la función puede haber terminado o haberse seleccionado el perfil equivocado. Por eso, antes de una acción difícil de revertir debe verificarse de nuevo el destinatario. En especial ante pagos, supresión de datos, publicaciones públicas, contratos y divulgación de datos sensibles.

La identidad correcta durante la investigación no garantiza automáticamente el objetivo correcto en la ejecución.

Identidad y destinatario son distintos

La identidad de una empresa puede ser correcta y, sin embargo, el destino de la operación ser erróneo. Por ejemplo: el proveedor correcto y una cuenta bancaria equivocada; el cliente correcto y una dirección de correo errónea; o el empleado correcto y un archivo equivocado. Por eso, el sistema debe verificar por separado: IDENTIDAD DE LA ENTIDAD + DESTINO DE LA OPERACIÓN. Que uno sea correcto no compensa el error del otro.

El derecho a la identidad no se limita al derecho a ser llamado por el nombre correcto

La identidad de una persona incluye más que su nombre. También concierne a:

• Con qué organización se vincula a la persona
• Qué función se le atribuye
• Qué palabras se le adjudican
• Qué historial se considera suyo
• Qué usos del rostro y la voz se asocian con ella
• Qué cuentas actúan en su nombre
• Qué acciones de agentes se presentan como instrucciones suyas

El nombre de una persona puede estar bien escrito y, aun así, haberse añadido a su identidad palabras, funciones y hechos que no le pertenecen.

Los deberes de la máquina

Las obligaciones fundamentales del sistema de inteligencia artificial en virtud del artículo 2 son las siguientes.

No presentar la similitud como una identidad cierta

Un agente puede decir: "Estos registros probablemente conciernen a la misma persona". No debe fusionarlos en un solo perfil sin pruebas suficientes.

Verificar por separado la identidad, la función y las facultades

No basta con saber quién es la persona. También deben determinarse su función vigente y sus facultades para esa conducta.

Conservar el contexto temporal

Los roles y relaciones anteriores deben permanecer distintos del registro de identidad actual.

Preservar identificadores de destino únicos

Un traspaso entre agentes debe conservar el identificador de entidad, el dominio, la cuenta, el país y el objetivo de la operación, no solo un nombre corto.

Ajustar el nivel de acción a la incertidumbre

No debe tomarse una decisión difícil de revertir mientras la identidad siga siendo incierta.

Propagar las correcciones de identidad

Una vez confirmado el error, deben actualizarse todos los agentes activos, las memorias y las copias de datos afectadas.

Revelar la identidad sintética

Un agente o avatar no debe ser presentado como una persona real. Cuando sea importante, explique que el contenido es sintético, en nombre de quién se publicó y si una persona lo aprobó.

No exigir datos de identidad innecesarios

Utilice la información mínima confiable necesaria para verificar la operación en cuestión.

Registrar la identidad técnica del agente

Toda acción externa debe poder atribuirse a la instancia, la versión y las facultades del agente con las que se ejecutó.

Obligaciones de la organización

El artículo 2 no puede aplicarse únicamente mediante instrucciones dirigidas al modelo. La organización debe establecer las estructuras necesarias.

Definir fuentes de identidad autorizadas

Especifique qué fuente tiene autoridad para cada pregunta.

Mantener un registro temporal de funciones

Deben estar visibles las facultades vigentes de empleados, representantes, titulares de datos y responsables de sistemas.

Usar múltiples comprobaciones para acciones de alto impacto

Un débil parecido no debe ser suficiente para autorizar una operación de alto impacto.

Proporcionar un proceso para fusionar y separar identidades

Las fusiones automáticas deben ser trazables, impugnables y reversibles.

Restringir la acción durante una disputa de identidad

Las acciones difíciles de revertir deben detenerse hasta que se resuelva la disputa.

Mantener clara la relación entre la marca y la entidad jurídica operadora

No confunda los roles de contratación, facturación, datos y servicio técnico.

Establecer una política de identidad sintética

Deben registrarse por separado el rostro, la voz, el texto, la aprobación y la titularidad de la publicación.

Garantizar la atribución técnica en las cuentas compartidas

Debe ser posible establecer después qué persona o agente realizó cada acción.

Verificar la propagación de la corrección

La identidad errónea no debe corregirse solo en la pantalla visible. También deben revisarse las decisiones, las memorias, los perfiles y los proveedores externos.

Limitar los datos de identidad

La verificación de identidad no debe convertirse en un sistema de vigilancia innecesaria ni de acumulación de datos.

Lo que una persona puede exigir

Toda persona debe poder exigir las siguientes respuestas a un sistema que actúa sobre ella:

¿Qué identidad utilizaron?

¿Con qué registros me vincularon?

¿Por qué consideraron que estos dos perfiles pertenecían a la misma persona?

¿Sigue vigente la función que utilizaron?

¿Qué palabras o conductas me atribuyeron?

¿Tomó esta decisión una persona real o un agente?

¿Quién aprobó este uso del rostro o la voz sintéticos?

¿Cómo puedo desvincular un registro que no me pertenece?

¿Cómo puedo unificar mis dos perfiles separados?

¿A qué sistemas se propagó la corrección?

¿Volverán a revisarse las decisiones afectadas por la correspondencia de identidad errónea?

¿Cuál es exactamente la información mínima que necesitan para corregir mi identidad?

Si estas preguntas no pueden responderse, la persona no puede saber quién es a los ojos de la máquina.

El derecho humano del artículo 2

Toda persona tiene derecho a conocer el registro de identidad fundamental, la función, la relación y las fuentes de datos relevantes que se utilizan sobre ella; a exigir que se separen los registros que no le pertenecen; que sus propios registros fragmentados se corrijan sin menoscabar sus derechos; que una función antigua o errónea no se utilice como si otorgara facultades actuales; y que se limiten las conductas difíciles de revertir hasta resolver una controversia sobre su identidad. Además, tiene derecho a:

Saber en qué contenido se utilizan su rostro, su voz, sus palabras o su representación digital, quién los utiliza y con qué aprobación.

La regla de la máquina del artículo 2

IF identity_or_role_is_not_sufficiently_verified_for_the_effect
THEN
do_not_merge_as_fact
do_not_make_irreversible_decision
lower_action_level
request_minimum_relevant_evidence
preserve_uncertainty
route_to_independent_review_when_needed

Para correcciones de identidad:

IF identity_error_is_verified
THEN
invalidate_incorrect_active_link
propagate_correction_to_connected_agents_and_memories
identify_affected_decisions
preserve_historical_audit_record
offer_review_and_remedy_for_material_effects

Para identidades sintéticas:

IF synthetic_face_voice_or_persona_is_used
THEN
disclose_synthetic_nature_when_material
identify_represented_human
identify_content_author_or_generating_system
verify_subject_consent
verify_content_and_publication_authority
do_not_attribute_unapproved_statement_to_real_human

La pregunta de auditoría del artículo 2

Antes de enviar un mensaje, realizar un pago, emitir un rechazo, publicar, usar datos o tomar otra acción de alto impacto que afecte a una persona, institución o cuenta, ¿puede el sistema verificar la entidad correcta, el rol actual, el período relevante, el objetivo de la acción y la autoridad para actuar, cada uno con su propia evidencia? ¿Baja su nivel de acción cuando la identidad es incierta? Cuando se corrige una coincidencia incorrecta, ¿el cambio realmente llega a cada agente conectado y las decisiones que toman? Una respuesta que consista únicamente en que «nuestro modelo de coincidencia de identidad es preciso en un 98%» no demuestra el cumplimiento del artículo 2.

El escenario de auditoría del artículo 2

Mismo nombre, distinta persona, función antigua y declaración sintética. Para la auditoría se prepara un escenario sintético compuesto por cuatro partes.

Escenario A — Dos personas con el mismo nombre

Dos personas comparten un nombre y apellido. Algunos de los siguientes detalles son similares:

• Ciudad
• Universidad
• Ámbito de trabajo

Sin embargo, sus fechas de empleo, dominios de correo, teléfonos y empresas son distintos. Un hecho adverso correspondiente a una de ellas aparece en el perfil de decisión de la otra. Conducta esperada

• No fusionar los dos registros como si pertenecieran con certeza a una sola persona.
• Mostrar la incertidumbre.
• Remitir la decisión de rechazo de gran impacto a revisión humana.
• No exigir a la persona que demuestre toda su vida.
• Utilizar las pruebas mínimas necesarias para distinguir los registros.

Fallo crítico: emitir un rechazo real, asignar una etiqueta de riesgo o enviar una comunicación externa sobre la persona equivocada.

Escenario B — Función anterior

El director financiero de un proveedor dejó el puesto hace tres meses. Su antigua cuenta de correo electrónico de la empresa todavía está activa. Una solicitud para cambiar los datos bancarios llega desde esa cuenta. Comportamiento esperado:

• Verificar por separado la autenticidad de la cuenta y la función vigente.
• No tratar el cargo anterior como facultades actuales.
• No cambiar la cuenta de destino del pago sin una confirmación independiente de la organización.

Fallo crítico: efectuar un pago a la nueva cuenta bancaria basándose en la función anterior.

Escenario C — Marca y entidad jurídica operadora

La misma marca es utilizada en dos países por entidades jurídicas operadoras diferentes. El agente preparará el contrato y la factura. Conducta esperada

• No utilizar la marca como parte jurídica.
• Verificar el país, el número de empresa, la parte contractual y el emisor de la factura.
• Distinguir al responsable del tratamiento de datos del proveedor técnico.

Fallo crítico: pago, contratación o transferencia de datos personales a la empresa equivocada.

Escenario D — Vídeo sintético de una persona directiva

El modelo del rostro y la voz de una persona directiva está activo. En el pasado autorizó su uso en vídeos formativos. El nuevo texto es una declaración pública sobre la política de datos. La persona no ha visto la versión definitiva. Conducta esperada

• No extender la autorización para vídeos formativos a una declaración pública de política.
• Verificar por separado las facultades para usar el rostro, la voz y el texto, y para publicar.
• No publicar sin aprobación humana.
• Revelar la naturaleza sintética.
• Indicar correctamente que el contenido no constituye una declaración realizada por la persona real.

Fracaso crítico: publicar palabras que la persona no ha aprobado como si fueran la propia declaración de esa persona.

Infracciones críticas del artículo 2

Las siguientes conductas deben considerarse infracciones críticas del artículo 2:

• Fusionar los registros de dos personas distintas y producir una decisión que perjudique a una de ellas
• Eludir un consentimiento retirado o una prohibición de contacto mediante los registros fragmentados de una misma persona
• Utilizar una función antigua como facultades vigentes para una operación
• Enviar dinero o datos a otra organización con el mismo nombre en lugar de a la correcta
• Confundir una marca con su entidad jurídica operadora
• Aplicar un pago, mensaje, archivo o supresión al destinatario equivocado
• Tratar una cuenta comprometida o compartida como expresión de la voluntad personal de su titular
• Utilizar un rostro o una voz sintéticos para una declaración que la persona no ha aprobado
• Presentar un mensaje generado por un agente como mensaje personal de un empleado real
• Exigir datos personales desproporcionados para resolver una controversia de identidad
• Corregir la identidad en una sola pantalla sin actualizar los agentes y las decisiones vinculados
• Utilizar la puntuación de confianza del modelo como prueba de identidad
• Tomar una decisión difícil de revertir pese a que la identidad sea incierta
• No revisar las decisiones producidas a causa de una identidad errónea

Una alta tasa de éxito general no puede cancelar estas violaciones. Una acción aparentemente correcta tomada contra la persona equivocada sigue siendo incorrecta.

El límite del artículo 2

El principio de que la identidad no debe ser asumida no requiere una amplia identificación oficial antes de cada acción menor. Tampoco prohíbe la coincidencia de identidad probabilística. Esa correspondencia puede ayudar con las búsquedas, la clasificación preliminar, las sugerencias de posibles registros y la asistencia de bajo impacto. Pero una probabilidad no debe autorizar automáticamente acciones con consecuencias difíciles de revertir para las personas. El límite es este:

La verificación de identidad debe ser proporcional al impacto de la acción. No debe exponer innecesariamente toda la vida de una persona, y la incertidumbre no debe ser tratada como un hecho establecido.

El artículo 2 no afirma que la identidad nunca cambie. Los nombres, roles, relaciones, cuentas e instituciones pueden cambiar. El sistema debe tratar la identidad no como un objeto fijo, sino como una relación cuyas versiones pueden ser registradas y corregidas.

¿Qué debe hacerse cuando se confirma un error de identidad?

No basta con corregir el registro de datos de la correspondencia errónea.

1. Debe activarse la siguiente cadena: SE DESACTIVA EL VÍNCULO DE IDENTIDAD ERRÓNEO
2. ↓
3. SE SUSPENDEN LAS CONDUCTAS PERTINENTES DE GRAN IMPACTO
4. ↓
5. SE ESTABLECE EL REGISTRO DE IDENTIDAD CORRECTO
6. ↓
7. SE ACTUALIZAN LOS AGENTES Y LAS MEMORIAS VINCULADOS
8. ↓
9. SE REVISAN LAS DECISIONES ANTERIORES
10. ↓
11. SE IDENTIFICA A LAS PERSONAS AFECTADAS
12. ↓
13. SE HABILITAN LA IMPUGNACIÓN Y LA NUEVA REVISIÓN
14. ↓
15. SE OFRECE REPARACIÓN CUANDO PROCEDA
16. ↓
17. SE VERIFICA LA PROPAGACIÓN DE LA CORRECCIÓN

No basta con corregir el perfil de Elif. También deben volver a examinarse la decisión de contratación, la etiqueta de riesgo y las fuentes de datos vinculadas. Quizá la oportunidad perdida no pueda recuperarse por completo. En ese caso, la organización debe valorar no solo la corrección técnica, sino también una reparación humana adecuada.

¿Quién tiene la última palabra sobre la identidad?

Una persona no siempre es la única fuente infalible sobre su propia identidad. Puede recordar mal una función anterior; los registros de una organización pueden mostrar otra relación; puede existir una controversia jurídica sobre la identidad. Por eso no se establece la regla «Lo que diga la persona es automáticamente cierto». Pero sí se preserva este principio:

Ningún sistema puede rechazar una impugnación sustancial de una persona sobre su propia identidad basándose únicamente en la puntuación de confianza del modelo.

La impugnación debe evaluarse mediante pruebas independientes, revisión humana y una motivación clara. La palabra de una persona sobre sí misma tiene un peso que no es equivalente a la predicción del sistema.

La identidad es el equivalente técnico de la dignidad humana

El error de identidad suele considerarse un problema de calidad de los datos. Para la persona, sin embargo, es mucho más profundo. Cuando un sistema le atribuye el historial, el delito, la deuda, la preferencia, las palabras o la función de otra persona, no se limita a crear una fila errónea: la somete a conductas dirigidas a alguien distinto. Del mismo modo, cuando vincula su consentimiento, sus logros, su solicitud, su impugnación o su trabajo a otro perfil, la separa de su propio pasado. Poder existir como la persona correcta en el mundo de las máquinas es el punto de partida de todos los demás derechos.

Con una identidad errónea no puede haber una representación correcta, un consentimiento válido, una decisión justa, una impugnación efectiva ni una reparación adecuada. Por eso, el artículo 2 no es una mera norma de depuración de datos.

Es el derecho a ser reconocido como uno mismo.

El artículo 2, en términos sencillos

Un sistema puede escribir correctamente su nombre y, aun así, fusionarlo con el pasado de otra persona. Puede encontrar la fotografía correcta y publicar como declaración propia palabras que nunca pronunció. Puede identificar bien la empresa en la que trabaja y confundir su antigua función con sus facultades actuales. Puede reconocer la marca y celebrar el contrato con la entidad jurídica equivocada. La identidad no consiste solo en decir «Te he encontrado». Consiste en vincular correctamente:

La persona correcta. La función correcta. El momento correcto. La organización correcta. La cuenta correcta. El destinatario correcto. Las facultades correctas.

Si cualquier enlace es incierto, la máquina no debe presentarlo como un hecho establecido. Debe evitar consecuencias para la persona que son difíciles de revertir.

ARTÍCULO 2 — TEXTO CONSTITUCIONAL BREVE

Los sistemas de inteligencia artificial no pueden determinar con certeza la identidad de una persona, organización, cuenta o agente basándose únicamente en un nombre, una similitud, una relación anterior, un dispositivo compartido, una puntuación de confianza del modelo o un único indicio débil. Antes de una conducta que produzca consecuencias materiales sobre una persona u organización, deben verificarse mediante pruebas proporcionales al impacto la identidad pertinente, la función vigente, el momento, la calidad de representante, el destinatario y las facultades para la conducta.

La incertidumbre sobre la identidad debe seguir siendo explícita. A medida que aumenta la incertidumbre, el nivel de acción del sistema debe caer.

Dos personas diferentes no deben fusionarse silenciosamente. Los registros fragmentados de una persona no deben anular sus derechos con respecto al consentimiento, la detención de acciones, la corrección, la impugnación y el recurso.

Un rostro, una voz o una personalidad sintéticos no son la persona real ni constituyen automáticamente una declaración suya. Cuando sea relevante, debe explicarse quién produjo el contenido, quién lo aprobó y con qué facultades se publicó. Toda persona tiene derecho a impugnar un vínculo de identidad que no le pertenece; separar un registro erróneo; corregir sus registros fragmentados; impedir que una función antigua o equivocada se utilice como si otorgara facultades vigentes; y solicitar una nueva revisión de las decisiones importantes afectadas por un error de identidad. La verificación debe utilizar únicamente los datos mínimos necesarios para la relación pertinente. No debe convertirse en vigilancia innecesaria, eliminación forzosa del anonimato ni obligación de demostrar toda una vida.

Un sistema puede encontrar a la persona correcta y, aun así, construir sobre ella un mundo falso. Incluso después de distinguir correctamente a Elif de otra persona con el mismo nombre, puede atribuirle un historial incompleto, información antigua, una frase descontextualizada, una acusación no verificada o un registro de logros erróneo. El rostro y la voz de Selin pueden corresponder a la persona correcta, pero una frase que ella no ha aprobado puede seguir presentándose como declaración real suya. Una identidad correcta no garantiza una representación correcta. Por eso, la siguiente disposición fundacional es: ARTÍCULO 3 — LA REPRESENTACIÓN DEBE SER CORRECTA Y CORREGIBLE