> For the complete documentation index, see [llms.txt](https://docs.griaule.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.griaule.com/gbs/es/aplicaciones/trust.md).
# Trust
## 1. Visión general de la herramienta
Trust es una herramienta de GBS utilizada para resolver conflictos entre datos biométricos o biográficos que requieren intervención humana. En estas situaciones, un especialista analiza los perfiles involucrados y elige si debe mantener, fusionar o rechazar alguno de ellos. Las decisiones afectan directamente la base de datos, y las transacciones en cola solo se reprocesan después de que el caso se haya resuelto. La herramienta se utiliza en diferentes contextos, como:
* **Emisión de identidades**: cuando hay intentos de registro con datos inconsistentes;
* **Sistemas bancarios:** garantizar que la autenticidad y la unicidad de cada cliente o titular de cuenta estén aseguradas, y su identidad correctamente verificada;
* **Elecciones**: para garantizar la unicidad del votante.
### 1.1 ¿Qué resuelve Trust en la práctica?
Trust fue creado para tratar **inconsistencias que comprometan la integridad de la base de datos única**, como:
* Una misma persona intentando registrarse con **documentos y nombres diferentes**;
* **Biometrías coincidentes** asociadas con datos biográficos conflictivos;
* **Actualizaciones de registro incorrectas**, que divergen de la identidad original.
### 1.2 ¿Cuáles son los principales beneficios de usar Trust?
Usando Trust, podrá tener:
* **Confiabilidad de la base:** asegura que solo perfiles legítimos y consistentes permanezcan, evitando duplicidades y fraudes.
* **Transparencia y trazabilidad:** todas las acciones quedan registradas, permitiendo auditorías y garantizando confianza en las decisiones.
* **Agilidad operativa:** interfaz intuitiva, con flujos bien definidos que facilitan el trabajo de los analistas.
* **Seguridad en las decisiones:** ofrece comparaciones detalladas entre datos biométricos y biográficos, apoyando decisiones técnicas y fundamentadas.
* **Integración con otras herramientas:** se conecta con Intelligence para acceso rápido al historial de transacciones.
## 2. Conceptos esenciales
En esta sección, encontrará los principales conceptos y estructuras que componen el funcionamiento de Trust. Ayudan a entender cómo el sistema organiza la información, cómo se detectan y tratan los conflictos, y cuál es el papel de los usuarios y de los permisos en el proceso de decisión.
### 2.1 Perfil
El perfil representa a una persona única en la base de datos. Cada perfil reúne datos biográficos y biométricos consolidados y validados.
La base garantiza que no existan dos perfiles con la misma clave o biometrías, asegurando la unicidad. Los perfiles existentes se comparan con los datos recibidos en un nuevo registro para verificar posibles conflictos con las reglas de la base.
### 2.2. Inconformidad
En el contexto de Trust, una inconformidad es una situación en la que los datos de un nuevo registro o de una actualización no coinciden con la información ya registrada en la base. Esto puede ocurrir, por ejemplo, cuando:
**1. Biometrías iguales con claves diferentes (las mismas biometrías)**\
Esta situación ocurre en transacciones de *alta* (registro) cuando dos personas, con el mismo tipo de clave (como CPF), pero con valores diferentes, presentan biometrías idénticas (huella y facial), lo que puede indicar duplicidad de registros.
**2. Biometrías diferentes con la misma clave**\
Ocurre en transacciones de *actualización* (actualización), cuando dos personas comparten una misma clave (el mismo número de CPF, por ejemplo), pero presentan biometrías distintas. Esto sugiere una posible inconsistencia o suplantación de identidad.
**3. Biometrías inconclusas**\
Pueden ocurrir tanto en *alta* como en *actualización*, en dos escenarios principales:
* Cuando hay una modalidad biométrica igual (por ejemplo: huellas) y otra diferente (por ejemplo: rostro), lo que puede indicar un intento de fraude o la existencia de gemelos idénticos.
* Cuando la calidad de las biometrías es tan baja que ni el sistema ni los peritos pueden concluir si son iguales o diferentes.
**4. Inconformidad de actualización**\
Las biometrías registradas durante la actualización son diferentes de las anteriores, lo que indica una posible suplantación de identidad o un error en el proceso.
**5. Inconformidad de registro**\
Las biometrías proporcionadas ya existen en la base, pero están asociadas a otro perfil, lo que puede indicar duplicidad o intento de fraude.
#### Tipos de inconformidad
Estos conflictos impiden que el sistema apruebe automáticamente la entrada de los datos. Por eso, la inconformidad debe analizarse manualmente en Trust, para decidir qué hacer con los perfiles involucrados, si deben fusionarse, rechazarse o mantenerse separados.
El sistema puede detectar diferentes tipos de inconformidad:
* **Biométrica**: cuando hay un análisis biométrico pendiente en el grupo (por ejemplo, las huellas o el rostro de la transacción coinciden con los de otro perfil).
* **Biográfica**: cuando hay un análisis biográfico pendiente en el grupo (ya se han realizado todos los análisis biométricos)
* **Mixta**: ocurre cuando hay un conflicto simultáneo entre datos biométricos y biográficos.
### 2.3 Grupo de inconformidad (o grupo)
En Trust, el grupo es la unidad central de análisis. Está formado por todos los perfiles y transacciones relacionados con una misma inconformidad, originada por una transacción que intenta ingresar en la base de datos. Esa transacción se compara con los perfiles existentes y, cuando hay conflicto, todos los involucrados se reúnen en un único grupo para facilitar la visualización y el tratamiento. El grupo se analiza de forma conjunta, permitiendo al especialista entender el caso completo antes de decidir qué debe ocurrir en la base.
### 2.4 Transacción
En el contexto de Trust, una transacción es el intento de insertar o actualizar datos en la base del GBDS. Puede referirse tanto al registro de una nueva persona como a la actualización de datos de una persona ya existente en la base.
Cada transacción contiene información biométrica (como huellas y rostro) y biográfica (como nombre, CPF, fecha de nacimiento) de una persona. El sistema evalúa si la clave proporcionada (por ejemplo: CPF, Título Electoral) ya existe en la base para determinar si la transacción es una actualización o un nuevo registro.
Existen dos formas principales de transacción:
* **Registro:** Cuando se agrega una nueva persona a la base.
* **Actualización:** Cuando se envía una nueva transacción para una persona que ya estaba registrada en la base.
### 2.5 Transacciones en espera de resolución
Son transacciones que entran en conflicto con un perfil ya involucrado en un grupo de inconformidad aún no resuelto. Por este motivo, no pueden tratarse de inmediato y quedan en estado de espera hasta que el grupo anterior se finalice.
Después de la resolución del grupo que causó el bloqueo, estas transacciones se reprocesan automáticamente. En ese momento, pueden ser aceptadas directamente o generar un nuevo grupo de inconformidad, según el resultado de la duplicación.
### 2.6 Comparación biométrica
La funcionalidad de comparación biométrica permite al operador visualizar lado a lado los pares de biometrías (rostro y huellas) entre la transacción y el perfil en análisis. Cada par se presenta con un borde coloreado, que indica el resultado de la comparación realizada por el sistema:
* **Verde:** alta similitud entre las biometrias
* **Rojo:** baja similitud entre las biometrías
* **Gris:** resultado inconcluso
### 2.7 Confirmación del tratamiento
Elección realizada al final del análisis de un grupo, definiendo qué ocurrirá con los perfiles y con la transacción entrante. Las principales decisiones son:
* **Rechazar transacción**
* **Fusionar perfiles**
* **Mantener los perfiles como distintos**
### 2.8 Jerarquía y permisos
Los usuarios tienen diferentes niveles de permiso según la organización a la que están vinculados, y eso afecta lo que pueden visualizar y decidir dentro del sistema Trust.
Solo los usuarios con permisos adecuados pueden realizar determinadas modificaciones, ya que algunas acciones requieren validación por una organización superior, lo que garantiza mayor seguridad y gobernanza en las decisiones que afectan a múltiples instituciones.
### 2.9 Conflicto biométrico
El conflicto biométrico ocurre cuando la biometría presentada en una transacción (como huellas o rostro) difiere de la biometría ya registrada para la misma clave o coincide con la biometría de otro perfil existente en la base con otra clave. Esta inconsistencia puede indicar un error de registro, una duplicidad o incluso un intento de fraude. Los conflictos biométricos están entre los principales motivos que generan inconformidades y exigen análisis manual.
### 2.10 Decisión biométrica
La decisión biométrica es la conclusión sobre la similitud entre dos biometrías. Puede tomarse automáticamente por el sistema, con base en el score de comparación, o manualmente por peritos. Scores muy altos indican biometrías compatibles, mientras que scores muy bajos indican biometrías diferentes. Cuando el score está en un rango intermedio (inconcluso), es necesaria la evaluación por peritos. La decisión biométrica orienta el tratamiento de la inconformidad, indicando si los datos son de la misma persona o no.
### 2.11 Análisis biométrico
El análisis biométrico es el proceso de evaluación visual de las biometrías involucradas en una inconformidad. Solo ocurre cuando las biometrías quedan en una zona inconclusa (ni con un score muy alto ni muy bajo). En ese caso, peritos comparan las huellas o las imágenes faciales para determinar si pertenecen a la misma persona. El análisis se realiza de forma independiente por más de un perito y exige consenso para continuar con el tratamiento. Las decisiones posibles son: biometría compatible, incompatible o inconclusa.
## 3. Flujo operativo
Esta sección describe paso a paso el funcionamiento de la herramienta Trust, reflejando el flujo real de trabajo de los usuarios en el análisis y tratamiento de inconformidades. Incluye la lógica de detección, los criterios que definen los posibles flujos y las decisiones que impactan la base de datos.
### 3.1 Pantalla inicial
Esta es la pantalla que da acceso a los análisis disponibles para un usuario. La información mostrada varía según los permisos del usuario (tipos de análisis que puede realizar) y la organización a la que está vinculado.
En la parte superior de la pantalla, hay botones que llevan al siguiente análisis disponible. La elección del análisis a realizar sigue la lógica de priorización definida por las configuraciones del sistema; el operador no selecciona qué transacción va a analizar, sino que trata la siguiente de la cola.
También se muestran contadores que indican cuántos análisis siguen disponibles para ese usuario.
### 3.1.2 Detección de la inconformidad
El sistema Trust detecta una inconformidad cuando una transacción de registro o actualización entra en conflicto con los datos consolidados en la base. La verificación se realiza mediante algoritmos que evalúan la consistencia entre los datos recibidos y los datos existentes, considerando información biométrica (como huellas y rostro) y biográfica (como nombre, fecha de nacimiento y número de documentos).
#### Criterios de detección para registros y actualizaciones
La transacción puede representar:
* **Un nuevo registro**, cuando la clave de identificación (por ejemplo, CPF o Título Electoral) aún no existe en la base.
* **Una actualización**, cuando la clave ya está registrada en la base y se realiza una nueva transacción con las mismas claves.
La lógica de detección de inconformidades varía según el tipo de transacción:
* En el caso de **registro**, los datos enviados se comparan con todos los perfiles existentes en la base, buscando similitudes biométricas que indiquen duplicidad.
* En el caso de **actualización**, los datos de la transacción se comparan con los datos del perfil de origen. Si hay inconsistencia (por ejemplo, la biometría enviada fuera de otra persona), se genera una inconformidad.
#### Algoritmos de detección
La base utiliza algoritmos de matching que comparan los datos de la transacción con los perfiles existentes. Para la biometría, se utilizan umbrales definidos de similitud para determinar si hay o no coincidencia. En caso de duda o incertidumbre, el sistema no toma la decisión automáticamente; el análisis se deriva a operadores humanos, con el apoyo de herramientas de análisis facial y de análisis de huellas.
**Ejemplos de situaciones que generan inconformidades:**
* Un nuevo registro tiene huellas que coinciden con las de un perfil ya existente, aunque los datos biográficos sean diferentes.
* Una actualización intenta alterar la biometría (por ejemplo, el rostro) de un perfil, pero la nueva biometría no corresponde al perfil de referencia con las mismas claves.
Estas situaciones impiden la entrada automática de la transacción y activan los flujos de análisis manual por especialistas.
### 3.1.3 Posibles flujos de análisis a partir de la inconformidad
Después de la detección de la inconformidad, el sistema puede derivar el grupo generado a diferentes tipos de análisis biométrico y biográfico:
* **Solo análisis facial**: si el conflicto es facial y no hay indicios de problema en las huellas.
* **Solo análisis de huellas**: si el conflicto es exclusivamente en las huellas.
* **Análisis facial y de huellas**: si se detectan inconsistencias en ambas modalidades biométricas.
* **Análisis facial y/o de huellas, pero sin necesidad de comparación de datos o imagen**: en algunos casos, incluso cuando se requiere análisis biométrico, el análisis biográfico no se habilita, por ausencia de conflicto en los datos biográficos.
El análisis biográfico solo se presenta si el sistema identifica divergencias en los datos biográficos. Si los datos biográficos son compatibles y no hay riesgo de alteración del contenido de la base, la etapa de análisis biográfico puede no ocurrir.
### 3.2. Acceso a la cola de análisis
Después de la detección de una inconformidad, el grupo correspondiente se deriva para análisis por operadores habilitados. El sistema organiza y pone a disposición estos análisis mediante una interfaz específica, que permite el acceso controlado y ordenado a las inconformidades pendientes de tratamiento.
### 3.2.1 Organización de la cola (priorización y asignación)
La priorización de los análisis sigue reglas que consideran, entre otros factores, el tiempo de espera de la inconformidad y el estado actual del grupo. Hay un panel de administrador que permite configurar reglas de prioridad para determinados grupos o tipos de transacciones.
La asignación de los análisis puede ocurrir de dos formas:
* **Distribución automática**: el sistema entrega directamente un análisis disponible al usuario, según su permiso y alcance organizativo.
* **Selección manual:** el usuario elige libremente qué inconformidad va a analizar; actualmente, este tipo de selección solo es posible en el panel de administrador, mediante una búsqueda directa por la clave de la persona involucrada.
### 3.2.2 Cómo recibe el usuario un análisis
Al acceder a la pantalla de análisis, el sistema puede presentar automáticamente un grupo disponible, según la lógica de distribución. Alternativamente, el operador puede utilizar los recursos de búsqueda y filtros en el panel de administrador para seleccionar el análisis que desea tratar. Los permisos de la organización a la que está vinculado el operador determinan qué grupos estarán visibles o disponibles para tratamiento.
#### 3.2.3 Interfaz de acceso: análisis en cola de prioridad y panel de análisis asignados
La interfaz de acceso a Trust permite al operador elegir el tipo de inconformidad que se tratará, dentro de los grupos específicos a los que tiene acceso. Los principales recursos de esta interfaz incluyen:
* **Análisis de las inconformidades en orden de prioridad**, que incluyen:
* **Análisis de huellas**: comparación de huellas dactilares para verificar si pertenecen a la misma persona.
* **Análisis de rostros**: comparación de imágenes faciales cuando hay incertidumbre en la coincidencia automática.
* **Análisis biográfico**: evaluación de conflictos entre datos como nombre, fecha de nacimiento y filiación.
* **Aprobación pendiente**: casos ya tratados que esperan confirmación final por un segundo operador.
* **Panel de análisis asignados:** cada operador tiene un panel con los análisis que ya le están asignados, es decir, aquellos en los que inició el análisis biográfico, pero aún no concluyó el tratamiento. Ese panel permite retomar casos pendientes y garantiza que una misma inconformidad no sea tratada por más de un operador.
### 3.3. Análisis biométricos
La etapa de análisis biométrico implica la verificación de similitud entre registros faciales y dactilares detectados por el sistema como posibles coincidencias. Los análisis se dividen en dos interfaces distintas: **análisis de rostros** y **análisis de huellas**. Cada una tiene flujos propios y criterios específicos de evaluación.
### 3.3.1. Análisis de rostros
#### Criterio de visualización en el análisis de rostros (umbral de incertidumbre)
Un caso se deriva a tratamiento manual siempre que el score de similitud facial entre dos imágenes se encuentra en un rango de incertidumbre, es decir, dentro de un intervalo en el que el sistema no tiene suficiente confianza para tomar una decisión automática. La lógica es evitar falsos positivos o negativos en casos de baja o media confiabilidad.
#### Modal de comparación biométrica facial
Al hacer clic en el botón **Análisis de rostros** de la pantalla inicial de Trust, el sistema selecciona automáticamente el primer caso de la cola y abre un modal de comparación, que muestra lado a lado las imágenes faciales de los dos perfiles que se están comparando, sin indicar, sin embargo, a qué perfil pertenecen.
**Funcionamiento de la interfaz**
La interfaz del análisis facial presenta los pares de imágenes faciales a comparar. Después del análisis, el operador debe indicar su decisión mediante los tres botones en la parte inferior de la pantalla, o mediante las teclas de acceso rápido correspondientes:
* **Rostros diferentes - rojo (tecla A)**
* **No puedo decidir - gris (tecla S)**
* **Mismos rostros - verde (tecla D)**
La decisión del operador se registra y se utiliza en las etapas siguientes del flujo.
Una vez indicada la decisión, el caso se cerrará y el siguiente caso se mostrará automáticamente en la pantalla del operador. Si ya no hay más casos por tratar, el mensaje correspondiente se mostrará en la pantalla.
Para volver a la pantalla inicial, basta hacer clic en el logotipo de Trust en la esquina superior izquierda o en **Análisis**. El caso que eventualmente esté abierto sin una decisión volverá a la cola de análisis para ser asignado a otro operador.
**Cuando marcar como inconcluso**
La opción de marcar el análisis como inconcluso debe usarse cuando el operador no pueda determinar con seguridad si las imágenes faciales corresponden a la misma persona, incluso después de una observación detallada en el modal de comparación. Este botón sirve para indicar que la decisión no puede tomarse con base en los datos presentados.
### 3.3.2. Análisis de huellas
#### Modal de comparación biométrica de huellas
Al hacer clic en el botón **Análisis** **de huellas** de la pantalla inicial, el sistema selecciona automáticamente el primer caso de la cola y abre un modal de comparación, que muestra lado a lado las imágenes de las huellas dactilares de los dos perfiles que se están comparando, sin indicar, sin embargo, a qué perfil pertenecen.
**Funcionamiento de la interfaz**
La interfaz del análisis de huellas presenta los pares de imágenes de huellas dactilares a comparar. Después del análisis, el operador debe indicar su decisión mediante los tres botones en la parte inferior de la pantalla, o mediante las teclas de acceso rápido correspondientes:
* **Huellas diferentes - rojo (tecla A)**
* **No puedo decidir - gris (tecla S)**
* **Mismas huellas - verde (tecla D)**
La decisión del operador se registra y se utiliza en las etapas siguientes del flujo.
Una vez indicada la decisión, el caso se cerrará y el siguiente caso se mostrará automáticamente en la pantalla del operador. Si ya no hay más casos por tratar, el mensaje correspondiente se mostrará en la pantalla.
Para volver a la pantalla inicial, basta hacer clic en el logotipo de Trust en la esquina superior izquierda o en **Análisis**. El caso que eventualmente esté abierto sin una decisión volverá a la cola de análisis para ser asignado a otro operador.
#### Reglas de fusión biométrica
El sistema considera múltiples factores para determinar si las biometrias pertenecen a la misma persona:
* **Umbral de similitud**: scores de comparación entre huellas.
* **Calidad de las biometrías**: las biometrías de baja calidad pueden dificultar la decisión y justificar un estado inconcluso.
* **Cantidad de dedos con "hit"**: el número de dedos coincidentes es un factor relevante para la toma de decisión. La concordancia en pocos dedos puede ser suficiente o no, dependiendo de la calidad y del score.
Es importante destacar que no siempre estarán disponibles los 10 dedos para análisis en Trust. El sistema solo envía para verificación manual los pares de huellas cuya comparación automática no fue concluyente. Es decir, los dedos con buena calidad y score muy alto (indicando fuerte similitud) o muy bajo (indicando fuerte diferencia) son clasificados automáticamente por el sistema, sin necesidad de revisión manual. Por eso, el operador puede visualizar solo algunos pares, como 6 o 7 dedos, dependiendo de la calidad de las biometrías y del rendimiento de la comparación inicial.
**Cuando marcar como inconcluso**
Al igual que en el análisis facial, el botón de inconcluso debe usarse cuando, tras observar las huellas en el modal de comparación, el operador no logra afirmar con seguridad si las huellas dactilares son de la misma persona o no.
### 3.4. Análisis biográfico
Después de la etapa de análisis biométrico (facial y/o de huellas), el sistema puede derivar el perfil a la etapa de análisis biográfico, dependiendo de las características de la inconformidad. El análisis biográfico se realiza con base en la comparación entre los datos biográficos de la transacción (registro o actualización) y los datos del perfil de la base que está siendo comparado.
#### Cómo visualizar y comparar
**Los datos biográficos entre perfiles**
La interfaz presenta los datos biográficos de la transacción y los datos biográficos del perfil de la base, permitiendo que el operador compare ambos conjuntos de información. Esta visualización busca evidenciar convergencias y divergencias en los datos, como nombre, fecha de nacimiento, filiación, entre otros.
{% hint style="info" %}
Durante el análisis biográfico, también es posible visualizar las biometrias (facial y dactilares) de los perfiles involucrados. Esto ayuda al usuario a tomar una decisión más fundamentada, en caso de que sea necesario revisar la correspondencia biométrica ya analizada anteriormente.
{% endhint %}
#### Tratamiento de la inconformidad
En la **Análisis Biográfico** se muestra el tipo de transacción porque cada tipo de transacción tiene situaciones específicas que generan inconformidades:
* Registro - La inconformidad se genera cuando los perfiles del grupo presentan biometrias iguales y claves biográficas diferentes.
* Actualización - La inconformidad se genera cuando los perfiles del grupo presentan biometrias diferentes o inconclusas y claves biográficas iguales.
Cada perfil listado en la pantalla tiene una tarjeta con acciones específicas, según el tipo de coincidencia biométrica:
* Para perfiles con las mismas biometrias, están disponibles las siguientes acciones:
* **Decisión de base**: permite rechazar o fusionar el perfil con la transacción entrante.
* **Comparar biometrias:** abre un modal con la comparación detallada de las biometrias.
* **Ver perfil en Intelligence:** redirige al perfil en Intelligence.
{% hint style="info" %}
Haga clic en "Ver perfil en Intelligence" para comprobar todos los datos de registro de una persona específica.
{% endhint %}
* Para perfiles con biometrias inconclusas, las acciones disponibles son:
* **Decisión de base:** permite rechazar, fusionar o mantener por separado (utilizado en casos de falso positivo).
* **Comparar biometrias:** abre un modal con la comparación detallada de las biometrias.
* **Ver perfil en Intelligence:** redirige al perfil en Intelligence.
En el modal de comparación biométrica, se muestran los resultados de similitud entre las biometrias de la transacción entrante y del perfil seleccionado, con el siguiente código de colores:
* **Verde:** biometrias iguales
* **Rojo**: biometrias diferentes
* **Gris**: resultado inconcluso
Es posible seleccionar una biometría específica haciendo clic directamente sobre ella o utilizando el desplegable de selección de índice. Las biometrias de la transacción entrante se muestran a la izquierda y las del perfil seleccionado a la derecha. A partir de la versión 1.1.0 de Trust, estas posiciones se invirtieron: la biometría del perfil seleccionado pasó a mostrarse a la izquierda, mientras que la de la transacción entrante pasó a aparecer a la derecha.
Después de realizar la comparación biométrica, el operador será dirigido a una pantalla en la que se mostrarán los datos biográficos de los perfiles involucrados, destacando los datos divergentes. Estos datos deben analizarse para que se mantengan los valores correctos en el perfil final.
En la pantalla de confirmación, se muestran:
* **Perfiles que serán fusionados**
* **Perfiles que serán rechazados**
* **Datos biográficos seleccionados para el perfil resultante**
* **Campo para comentario con la justificación de las decisiones**
Si existen transacciones en cola de espera por el grupo en análisis, se muestran en la sección Transacciones bloqueadas. Después del tratamiento, si ya no hay más grupos bloqueando, la transacción se reprocesa automáticamente.
#### Acciones disponibles según el tipo de análisis (registro o actualización)
Las acciones disponibles en la pantalla de análisis biográfico varían según el tipo de transacción que generó la inconformidad:
* **Para transacciones de registro**:
* **Rechazar**
* **Mantener por separado**
* **Fusionar**
* **Para transacciones de actualización**:
* **Rechazar**
* **Mantener** (solo uno de los perfiles)
* **Fusionar**
{% hint style="info" %}
Estas acciones deben elegirse con base en la información biográfica y biométrica disponible en la pantalla.
{% endhint %}
#### Selección de las claves que compondrán el perfil final
El usuario puede seleccionar, si hay divergencia, qué claves deben prevalecer en el perfil final. Para cada clave divergente, es posible elegir si el valor que se mantendrá es el de la transacción o el del perfil de la base. Esta funcionalidad es especialmente importante en casos de fusión, donde el sistema permite que el operador componga el perfil unificado con los datos más correctos o completos.
#### Reglas para habilitar el botón "Confirmar tratamiento"
El botón **"Confirmar tratamiento"** solo se habilita cuando se han tomado todas las decisiones obligatorias:
* Se registró la decisión sobre la relación entre los perfiles (fusionar, mantener separado o rechazar).
* Todos los campos divergentes tuvieron un valor elegido por el operador (transacción o base).
* Se insertó una **justificación textual**, explicando la decisión tomada.
Solo después de cumplir estos requisitos el sistema permite concluir el análisis y registrar el tratamiento de la inconformidad.
**Acciones disponibles según el tipo de transacción**
**Para transacciones de registro**
* **Rechazar**: se utiliza cuando hay un intento de fraude o cuando la transacción no debe insertarse en la base.
* **Fusionar**: se utiliza cuando la transacción corresponde a un perfil ya existente en la base y los datos deben consolidarse.
* **Mantener por separado**: se utiliza cuando la biometría fue marcada como inconclusa y el operador identificó que en realidad son biometrías diferentes.
**Para transacciones de actualización**
* **Rechazar**: se utiliza cuando los datos enviados para actualización no pertenecen al perfil en cuestión, o configuran un intento de fraude.
* **Fusionar**: se utiliza en casos de biometría inconclusa, cuando la decisión es consolidar los datos de la transacción al perfil existente.
#### Cuándo usar cada decisión
La elección de la acción depende del análisis conjunto de las biometrias (facial y dactilares) y de los datos biográficos. Por ejemplo:
* Si la biometría confirma que los perfiles son de la misma persona y los datos biográficos son compatibles, la acción indicada es **fusionar**.
* Cuando las biometrias y los datos biográficos divergen, el sistema recomienda **mantener** (en registros con claves diferentes) o **rechazar** (en actualizaciones con clave igual).
* Cuando no hay suficiente certeza, especialmente en casos de biometría inconclusa, se puede optar por **mantener por separado** (para registro) o **fusionar** con reservas (para actualización), según el contexto.
La decisión siempre debe ser **fundamentada** con base en las evidencias presentadas por la interfaz.
#### Cómo insertar una justificación
Antes de confirmar el tratamiento, el operador debe **rellenar un campo de justificación**, explicando los motivos de la decisión. Esta justificación sirve como base de auditoría y debe presentar, de forma objetiva, los elementos que sustentan la conclusión tomada (por ejemplo: divergencia de datos biográficos, coincidencia biométrica, evidencia de intento de fraude, etc.).
#### Qué ocurre al confirmar el tratamiento
Al hacer clic en **"Confirmar tratamiento"**, el sistema:
* **Actualiza el estado de la inconformidad** a resuelta.
* **Registra la decisión y la justificación**.
* **Ejecuta las acciones correspondientes a la decisión**:
* Si es **fusión**, los datos de la transacción se consolidan en el perfil existente.
* Si es **rechazo**, la transacción se descarta y se registra como inválida.
* Si es **mantener por separado** o **mantener**, los perfiles siguen siendo distintos y no se fusionan.
Además, el sistema puede activar mecanismos automáticos, como el **reprocesamiento de transacciones anteriormente bloqueadas**, si la resolución de la inconformidad permite la continuidad de flujos dependientes.
### 3.6. Validación por Otras Organizaciones
La **validación por otras organizaciones** es necesaria cuando hay presencia de **múltiples organizaciones** responsables de tratar y validar las inconformidades de perfiles. En escenarios donde un perfil pertenece a otra organización, existe la necesidad de un análisis de una instancia superior para confirmar la veracidad de una transacción. La pendiente generada se dirige a una organización superior a las involucradas para una evaluación final. Esta funcionalidad es configurable, pudiendo estar habilitada o no en el entorno del cliente.
#### Cuando la validación es necesaria
La validación por otras organizaciones ocurre en los siguientes casos:
* Cuando una **inconformidad** se detecta en un perfil que pertenece a otra organización, el sistema activa la necesidad de validación por parte de las otras organizaciones involucradas.
* Cuando el análisis de una transacción exige **confirmación externa** o **revisión** de otra organización, especialmente en situaciones que involucran decisiones con altos riesgos o en las que hay **divergencias** en las biometrias o en los datos biográficos.
#### Cómo se genera y se asigna la pendiente
La **pendiente** de validación se genera automáticamente por el sistema, que, al identificar que una inconformidad debe ser verificada por otra organización, **crea una pendiente** asociada a la transacción en cuestión. La asignación de una pendiente ocurre de acuerdo con el flujo de trabajo configurado para cada organización, y el sistema irá **enviar la pendiente a la organización responsable** o al operador que debe realizar la validación.
* **Pendiente asignada**: Tan pronto como se crea la pendiente, ella es **asignada al operador o a la organización** que debe validarla.
#### Lo que ve en la interfaz el primer operador que la trató
Cuando el **primer operador** trata la inconformidad, podrá ver en la interfaz una indicación de que **otras organizaciones necesitan validar** la transacción o inconformidad. La interfaz ofrece un **estado de pendiente**, con información sobre qué organización u operador debe completar la validación.
* El operador también podrá ver el **detalle** de la inconformidad, con las evidencias y datos asociados a la transacción que debe ser validada.
* Si el operador no tiene permiso para finalizar el proceso, verá la opción de **derivar la pendiente** a la organización responsable para la conclusión de la validación.
#### Qué ocurre si la pendiente es aprobada o rechazada
Dependiendo de la decisión tomada por la organización que recibió la pendiente, ocurre lo siguiente:
* **Si la pendiente es aprobada**: El sistema **finaliza el proceso** y la transacción es tratada conforme a las decisiones anteriores, como **fusión** o **mantenimiento separado**. El estado de la inconformidad se actualiza a resuelto, y el perfil de la base se actualiza conforme al tratamiento aprobado.
* **Si la pendiente es rechazada**: Si la otra organización no valida la transacción, el grupo volverá a la etapa de análisis biográfico y se asignará a un nuevo investigador.
### 3.7. Finalización del Proceso
La **finalización del proceso** de tratamiento de inconformidades ocurre cuando todas las etapas de análisis y decisión se completan, dando como resultado la **actualización de la base de datos** y el posible reprocesamiento de transacciones. Este proceso es crítico para garantizar que la información de la base esté siempre actualizada y correcta, reflejando todas las decisiones de tratamiento tomadas durante el análisis.
#### Actualización automática de la base
Tras la conclusión de todos los tratamientos de inconformidad, el sistema realiza la **actualización automática de la base de datos**. Esto incluye:
* **Inclusión o actualización de perfiles**: Cuando una inconformidad se resuelve, los datos biográficos y biométricos de los perfiles afectados se actualizan en la base, conforme a las decisiones tomadas (unificación, mantenimiento separado, rechazo, etc.).
* **Eliminación de transacciones**: Si una transacción fue rechazada, se elimina de la base de datos o se marca como inválida, según la política de la organización.
El proceso de actualización automática se realiza sin necesidad de intervención manual, garantizando agilidad y precisión en las modificaciones realizadas en la base de datos.
#### Reprocesamiento de transacciones anteriormente bloqueadas
En algunos casos, las transacciones pueden haber sido inicialmente **bloqueadas** debido a inconformidades no resueltas. Después del tratamiento de estas inconformidades y de la toma de decisión, el sistema realiza el **reprocesamiento** de esas transacciones bloqueadas.
* **Reevaluación de las transacciones**: Las transacciones que fueron bloqueadas pueden ser reevaluadas con base en la nueva información o en las decisiones de tratamiento tomadas. Si la inconformidad se resolvió y la transacción ahora se considera válida, será procesada e integrada a la base de datos.
* **Impacto en las transacciones bloqueadas**: El reprocesamiento puede generar la actualización de los perfiles involucrados, dependiendo de la decisión tomada durante el análisis (por ejemplo, unificación de perfiles o separación de datos).
#### Posibilidad de generar nuevas inconformidades a partir de la resolución
Después de la resolución de una inconformidad, existe la **posibilidad de que se generen nuevas inconformidades**. Esto puede ocurrir en los siguientes casos:
* **Cambio de estado del perfil**: La resolución de una inconformidad puede llevar a **nuevas verificaciones** de datos que, a su vez, pueden generar nuevas inconformidades. Por ejemplo, al unificar dos perfiles, pueden surgir divergencias adicionales entre los datos biográficos o biométricos, resultando en una nueva inconformidad.
* **Reprocesamiento de transacciones anteriores**: Como parte del reprocesamiento de transacciones bloqueadas, pueden detectarse nuevas inconformidades en perfiles o transacciones que antes no presentaban problemas evidentes.
* **Cambios en los criterios de validación**: La actualización de la base y el reprocesamiento de transacciones también pueden llevar a una **reevaluación de los criterios de similitud** y de fusión, lo que puede generar nuevas inconformidades cuando el sistema detecta diferencias adicionales.
Este ciclo continuo de análisis y tratamiento de inconformidades garantiza que la base de datos esté siempre en conformidad con los estándares de calidad y seguridad.
### 3.8. Panel del Administrador
El **Panel del Administrador** es una interfaz dedicada al seguimiento y la gestión de las inconformidades registradas en el sistema. Permite realizar búsquedas específicas, la visualización detallada de cada inconformidad, además de la priorización y, en algunos casos, el propio tratamiento directamente desde la interfaz.
#### Búsqueda de Inconformidades (Búsqueda de transacción)
En el panel, es posible realizar búsquedas por inconformidades a partir de **claves específicas**, como CPF, RG, título de elector, entre otras. La búsqueda devuelve una **lista de inconformidades** que corresponden a la clave informada. Al hacer clic en una de las inconformidades listadas, el sistema muestra su **página de detalles**.
#### Estado de las Inconformidades
Cada inconformidad puede estar en uno de los siguientes **estados**, de acuerdo con su etapa en el flujo de tratamiento:
* **Análisis biométrico**: pendiente de análisis biométrico en algún grupo.
* **Análisis biográfico**: todos los análisis biométricos han sido concluidos, y hay pendiente de análisis biográfico.
* **Aprobación pendiente**: el análisis biográfico fue realizado y espera aprobación de una organización superior.
* **En procesamiento**: la inconformidad está siendo procesada por ABIS, sin necesidad de acción por parte del usuario.
* **Aceptado**: la inconformidad se resolvió y la transacción fue aceptada en la base de datos.
* **Rechazado**: la inconformidad se resolvió y la transacción fue rechazada.
* **Error**: ocurrió un error al procesar la inconformidad en ABIS.
* **Bloqueado**: la transacción está vinculada a un grupo aún no resuelto. Es necesario tratar las inconformidades relacionadas para que la transacción pueda desbloquearse.
* **Reenviado para procesamiento**: las inconformidades que bloqueaban la transacción se resolvieron, y esta fue reenviada a ABIS con un nuevo identificador de transacción.
#### Detalles de la Inconformidad
En la **página de detalles** de una inconformidad, el sistema presenta:
* El **estado actual** y su descripción.
* Los **perfiles involucrados** en el grupo.
* Las **acciones disponibles** que varían según el estado.
A partir de la versión 1.1 de Trust, es posible derivar perfiles que están en análisis biométrico para análisis biográfico por medio de la pantalla “Detalles de Inconformidad”. Luego, se puede realizar el tratamiento de la inconformidad. En estos casos, el sistema asigna el resultado del análisis biométrico como *INCONCLUSIVO*.
#### Inconformidades Bloqueadas
Para inconformidades en los estados **Bloqueado** o **Reenviado para procesamiento**, la interfaz no muestra directamente los perfiles conflictivos. En su lugar, se listan las **inconformidades que están bloqueando la transacción**, y el operador puede acceder a ellas haciendo clic sobre cada elemento.
Al **priorizar una transacción bloqueada**, el sistema también **prioriza automáticamente** todas las inconformidades relacionadas que están bloqueando la transacción, asegurando que reciban tratamiento más rápidamente.
Esta funcionalidad permite una actuación más eficiente del equipo administrativo, garantizando agilidad en la resolución de casos críticos y mayor control sobre el flujo de tratamiento de las inconformidades.
### 3.9. Informes
*Verificar disponibilidad en el entorno implantado.*
Trust también ofrece una herramienta de visualización de gráficos y métricas sobre el historial de transacciones e inconformidades del entorno. Estos datos permiten extraer información útil sobre el tratamiento de inconformidades, ayudando a supervisores y coordinadores a mejorar la operación de los usuarios de Trust.
Actualmente, el sistema pone a disposición dos categorías de informes:
* Transacciones
* Inconformidades
Cada categoría cuenta con pestañas de dashboard que presentan métricas y gráficos específicos.
En la categoría *Transacciones*, hay una única pestaña de dashboard:
* General
Ya en la categoría *Inconformidades*, están disponibles las siguientes pestañas de dashboard:
* General
* Análisis Biométrico
* Análisis Biométrico - Comparación por usuario:
* Análisis Biográfico
* Análisis Biográfico - Comparación por usuario
#### Aplicación de filtros
Todos los dashboards cuentan con una serie de filtros que impactan directamente en los datos utilizados en el cálculo de las métricas y en la generación de las visualizaciones.
Los filtros disponibles pueden variar entre los dashboards, pero algunos ejemplos son:
* **Período:** define el intervalo de fechas considerado en los datos.
* **Label de origen:** corresponde al *label* de la transacción en el GBDS.
* **Ciudad de origen:** corresponde a la ciudad de origen de la transacción en el GBDS.
* **Tipo de transacción:** indica el tipo de operación en el GBDS (registro o actualización).
* **Tipo de biometría:** especifica la modalidad biométrica del dato (rostro o huella digital).
* **Usuario:** corresponde al usuario asociado a los datos filtrados.
#### Tooltips de métricas
Las métricas y gráficos muestran *tooltips* al pasar el cursor del ratón sobre los elementos del dashboard. Estos *tooltips* pueden proporcionar descripciones de las métricas o detallar valores e información específica presentada en el gráfico.
## 4. Casos de Uso Comunes
Esta sección presenta ejemplos reales o simulados de uso de la herramienta Trust. Los ejemplos ayudan a consolidar la comprensión del sistema y a orientar las decisiones de los usuarios.
#### Perfiles con la misma biometría y nombres diferentes: ¿qué hacer?
El sistema puede identificar una inconformidad entre dos perfiles con **biometría considerada idéntica**, pero **datos biográficos divergentes**, como diferencias en el nombre. Este es el caso típico de cambio de nombre después del matrimonio.
El analista usó Trust para:
* Verificar la coincidencia biométrica por medio del modal de comparación;
* Evaluar las divergencias biográficas directamente en la pantalla de análisis;
* Consultar el historial de transacciones de cada perfil en Intelligence.
El análisis manual identificó que el único cambio fue del apellido de soltera al apellido de casada. Con base en las evidencias, la decisión fue **rechazar el perfil de referencia y aceptar el perfil entrante**.
#### Un perfil con biometría igual, pero datos biográficos divergentes: ¿qué priorizar?
En análisis biográficos de registro con biometrias idénticas, Trust permite comparar los datos biográficos entre los perfiles del grupo. Cuando hay divergencias, el analista debe elegir, campo por campo, qué información compondrá el perfil resultante.
Este proceso ocurre después de seleccionar una acción de base (como "unificar"), y antes de confirmar el tratamiento. Trust muestra lado a lado los datos biográficos divergentes, y el analista selecciona la información correcta con base en los datos disponibles y en el historial de transacciones accesible a través de Intelligence.
Obs: La funcionalidad de selección de campos depende de la adecuada integración con el sistema donde se almacenan los datos biográficos. Si no es posible actualizar los datos biográficos, la selección de campos estará deshabilitada.
#### Sospecha de fraude
Trust fue diseñado para tratar casos de sospecha de fraude. Un ejemplo involucra a una persona que intenta obtener un nuevo documento con información biográfica diferente. El sistema detectó la coincidencia biométrica y generó la inconformidad para análisis.
A partir de las evidencias, como el historial de transacciones y el origen de los registros, el analista puede rechazar el perfil sospechoso, justificando su decisión en la pantalla de confirmación. Si el grupo está bloqueando alguna transacción, esta se reprocesará automáticamente tras la finalización del tratamiento.
## 5. FAQ
Esta sección reúne dudas frecuentes. El objetivo es ayudar al usuario a tomar decisiones más seguras, evitar errores comunes y entender el impacto de sus acciones en el sistema.
### 1) ¿Qué ocurre si rechazo el perfil incorrecto?
Al rechazar una transacción o marcar un perfil como inválido, el sistema registra esa decisión y puede bloquear definitivamente ese registro. Si se trata de un rechazo incorrecto, la consecuencia puede ser la pérdida de un dato legítimo o la necesidad de intervención por parte de otro organismo con permiso superior.
{% hint style="info" %}
Antes de rechazar, verifique con atención todos los datos biográficos, históricos y biometrias disponibles. Cuando haya dudas, utilice el recurso de pendiente para revisión por otro responsable.
{% endhint %}
### 2) ¿Puedo deshacer una decisión?
No. Una vez que la decisión se registra y confirma, **no puede deshacerse directamente** por el usuario. Esto garantiza trazabilidad y seguridad en las acciones.
Sin embargo, dependiendo del flujo de la organización, un perfil impactado puede ser tratado nuevamente dentro del proceso de análisis de pendientes.
### 3) ¿Cómo interpretar un match inconclusivo?
Un match se considera inconclusivo cuando el score biométrico está en una zona intermedia, es decir, ni lo suficientemente alto para afirmar con seguridad que los perfiles son de la misma persona, ni lo suficientemente bajo para descartar la relación.
En estos casos:
* Verifique si la imagen (facial o digital) tiene suficiente calidad.
* Analice los datos biográficos en paralelo.
* Utilice los recursos de zoom y comparación lado a lado en el modal.
* Si la incertidumbre persiste, documente la duda en la justificación y opte por **rechazar el perfil entrante**. De este modo se evita una actualización indebida y se permite que las biometrias se vuelvan a recopilar, ocasionando eventualmente un match más acertado.
### 4) ¿Cómo tratar perfiles que parecen legítimos, pero no coinciden?
Estos casos son comunes y pueden involucrar variaciones legítimas o intentos de fraude. Analice con atención el historial de los perfiles, las biometrias y los datos principales. Si hay evidencias claras de que se trata de la misma persona, unifique los registros con los datos correctos.
### 5) ¿Cuáles son las buenas prácticas para investigar y documentar una decisión?
Evalúe siempre el conjunto de información: datos biográficos, historial y biometrias. Preste especial atención a los campos divergentes, como nombre, documentos y fecha de nacimiento. Use los filtros para comprender el contexto de la transacción y, si es necesario, involucre a otras organizaciones mediante pendiente. Al registrar la decisión, sea claro y objetivo en la justificación —esto ayuda en la trazabilidad y en auditorías futuras. Priorice la precisión, incluso en casos aparentemente simples.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.griaule.com/gbs/es/aplicaciones/trust.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
