Documentación técnica destinada al equipo de DevOps del cliente corporativo: despliegue de componentes, configuración de base de datos, almacenamiento de objetos, autenticación móvil, validación post-deploy y matriz de entregables.
Cada componente cuenta con una guía de implementación específica, que incluye despliegue, configuración y validación. Seleccione un componente para acceder a su guía detallada.
Servicio principal de verificación de identidad: Java 21, despliegue en Kubernetes, health checks, secretos, métricas y control de acceso por rol.
Ver guíaMotor primario PostgreSQL 17 con aislamiento multi-tenant (RLS) y opción de replicación hacia SQL Server 2022. Scripts DDL, migraciones y respaldos.
Ver guíaBucket privado compatible con S3 para documentos e imágenes de verificación: credenciales, política de ciclo de vida y URLs firmadas.
Ver guíaPanel de administración para el cliente: revisión de operaciones, políticas de verificación, reprocesos, deduplicación de perfiles y auditoría.
Ver guíaBiblioteca de captura de documento y selfie, verificación de vida (liveness), flujos de enrolamiento y verificación, y autenticación por token.
Ver guíaServicio Python de análisis biométrico: OCR de documento, coincidencia facial y detección de presentación (PAD) con modelos ONNX optimizados.
Ver guíaModelo de lenguaje visual de respaldo cuando el worker ONNX no alcanza el umbral de confianza: Qwen en Dell GB10 (edge) y Gemini en la nube.
Ver guíaVerificación automática contra listas de sanciones y personas expuestas políticamente (PEP) durante el enroll. El gate es regulatorio y fail-closed: un acierto nunca se aprueba en silencio y los datos personales no salen de la infraestructura del cliente.
Cleared. La identidad extraída por OCR (nombres, apellido, fecha de nacimiento y número de documento; fuente MRZ preferida sobre visual) no coincide con las listas. El flujo biométrico y documental continúa.
HIT. Coincidencia por encima del umbral de match (default 0,8). Outcome rejected — override regulatorio, independiente del resto de criterios.
No disponible + requerido. Si el screening no puede
ejecutarse y está marcado como obligatorio, la sesión pasa a
revisión humana (manual_review). Nunca se
aprueba en silencio. Si no es obligatorio, solo queda
auditoría.
Criterio aml_pep_screening en
GET /v1/policies/{version}/thresholds
(13 criterios en políticas de enroll). Toggle y umbral vía
GET/PUT /v1/admin/aml-pep-config
(enabled, required,
matchThreshold 0–1). Deshabilitado: el flujo
queda intacto. El criterio no lo evalúa el motor de decisión;
el gate vive en el servicio de verificación, solo en enroll.
Atributos sys_aml_pep_* en el detalle de la
sesión: proveedor, referencia de fuente, estado
(cleared · hit ·
unavailable), marca de tiempo, score, cantidad
de matches, lista, nombre coincidente, tipo de match y error.
Permite reconstruir cada veredicto sin reconsultar las listas.
Laboratorio: catálogo sintético embebido (registros de demostración). Producción: archivo JSON montado en la infraestructura del cliente con datos licenciados SEPRELAD / OFAC / UE / ONU. El matching es on-prem; la PII no sale de la red del cliente.
El índice cívico de demostración (OpenSanctions) es CC-BY-NC: uso no comercial. Un despliegue comercial requiere licencia o token del proveedor. Fail-closed, on-prem y sin envío de PII fuera de la infra del cliente.
Verificación del enrolamiento contra el servicio de identidad de la autoridad (CISEF). A diferencia de un criterio interno, el gate no lo puntúa el motor de decisión: el motor resuelve primero con los criterios locales y el veredicto CISEF se compone después. Una indisponibilidad del servicio externo no rechaza un enrolamiento localmente válido.
Responde y valida. El veredicto local del motor se mantiene sin cambios: el enrolamiento continúa su curso.
Responde y no valida. Rechazo real
(rejected): es el veredicto de la autoridad, no una
puntuación local.
No disponible + requerido. Un enrolamiento que iba a
aprobarse se degrada a revisión humana
(manual_review), nunca a rechazo automático. Si el
gate no es obligatorio, queda únicamente el registro de
auditoría.
Los criterios cisef_* se filtran siempre del
motor de decisión, con la misma paridad que el screening
AML/PEP: el motor puntúa solo criterios locales. Si el motor ya
rechazó localmente, no se consulta al servicio externo.
El gate aplica únicamente al flujo de enrolamiento.
El gate se administra desde la sección Umbrales del Web Admin.
El parámetro required (por defecto verdadero)
define si la indisponibilidad degrada a revisión humana o queda
solo en auditoría. El cambio es de configuración, sin rebuild
del API.
Atributos sys_cisef_status
(pass · fail ·
unavailable · disabled) y
sys_cisef_error en el detalle de la sesión. Permite
distinguir un rechazo de la autoridad de una indisponibilidad
técnica, sin reconsultar el servicio.
El flujo de verify es un flujo corto sin documento: los criterios documentales y CISEF son propios del enrolamiento y no se evalúan allí. El motor aplica a cada flujo únicamente los criterios que le corresponden.
La aplicación móvil del cliente se autentica contra la API con credenciales de máquina emitidas por el backend. Los tokens JWT tienen una vigencia limitada y pueden revocarse en cualquier momento.
Emisión de credenciales. El backend genera un par client_id / client_secret por entorno del cliente. El secreto se entrega por canal seguro y se almacena únicamente en el servidor de la aplicación.
Intercambio por JWT. La app intercambia las credenciales en el endpoint de token y recibe un JWT firmado con un TTL de 15 a 30 minutos.
Revocación y rotación. El backend puede revocar tokens o credenciales ante incidentes; la rotación de secretos se realiza de forma programada y auditada.
Inventario de todo lo que recibe el cliente por componente: artefactos, scripts, credenciales, documentación y estado de cada entrega.
Abrir matrizLista de verificación formal para validar el entorno del cliente tras el despliegue, componente por componente, con progreso interactivo.
Abrir checklist