GNBiometrics — Checklist de Validación Post-Deploy

API Core — Quarkus

El Pod del API Core está en estado Running y con readiness OK. kubectl get pods; comprobar /q/health/ready → 200

El endpoint /api/v3/health responde 200 desde la red interna. Verificar también /q/health/live

La API es accesible solo por HTTPS y la ruta pública está limitada a /api/v3.

Los Secrets (credenciales BD, JWT, S3) están inyectados y no figuran en logs.

Métricas Prometheus disponibles en /q/metrics e integradas al monitoreo del cliente.

Flujo de prueba enroll + verify completado con datos sintéticos en el entorno sandbox.

El endpoint GET /v1/admin/aml-pep-config responde 200 y GET /v1/policies/{version}/thresholds lista el criterio aml_pep_screening (13 criterios en enroll). PUT acepta enabled / required / matchThreshold. Gate enroll-only.

El gate CISEF post-motor está activo y visible en Umbrales del Web Admin (marca Requerido). Con required = verdadero, una indisponibilidad del servicio de la autoridad debe degradar el enrolamiento a revisión humana — nunca a rechazo automático.

El detalle de una sesión de enroll registra los atributos de auditoría sys_cisef_status (pass · fail · unavailable · disabled). Verificable forzando una sesión de prueba y consultando el detalle de la operación.

El flujo verify aprueba con coincidencia facial válida y no muestra criterios documentales ni de CISEF en el resultado. Verify es un flujo corto sin documento: solo se evalúan los criterios que le corresponden.

Base de Datos

Las migraciones Flyway se aplicaron sin errores y el esquema gnb está completo. Comprobar versión de migración = última del release

RLS multi-tenant habilitado y probado: el usuario de app solo ve los datos de su entorno.

Respaldo programado configurado y restauración de prueba ejecutada con éxito (PG17 o SQL Server 2022).

Cifrado en tránsito (TLS 1.2+) verificado entre API y base de datos.

Los scripts DDL del motor elegido por el cliente coinciden con la matriz de entregables.

Almacenamiento — Ceph RGW

El bucket gnb-verificaciones-<entorno> existe y es privado (sin lectura pública).

Subida y descarga de un objeto de prueba OK con las credenciales de la API (S3).

URL presignada generada por el Web Admin vence a los 5 minutos y no es reutilizable.

Regla de ciclo de vida aplicada: objetos con fecha de expiración correcta (90 días por defecto).

Versioning habilitado y verificado con un borrado/restauración de prueba.

Web Admin

El Web Admin responde por HTTPS y está protegido por Cloudflare Access (sin sesión → 302 a cloudflareaccess.com).

Inicio de sesión contra el directorio del cliente + segundo factor funcionando con cuenta de prueba.

Los roles operador/administrador limitan correctamente las acciones (prueba con ambos perfiles).

Búsqueda de operación, detalle y reproceso funcionan contra datos sintéticos.

El registro de auditoría registra la sesión de prueba (quién, qué, cuándo).

SDK Móvil

APK (Android) e IPA/XCFramework (iOS) entregados y compilando en el entorno del cliente.

Captura de documento (frente/dorso) y selfie con guía de encuadre funcionando en dispositivo real.

Verificación de vida (liveness) responde correctamente ante foto estática (debe rechazar).

Flujo completo enroll + verify completado desde la app contra el entorno sandbox.

El recibo firmado P-256 se genera y su firma se valida contra la clave pública entregada.

Sin datos biométricos retenidos en el dispositivo tras finalizar la operación.

Core de Visión — Worker ONNX

El worker responde en /v1/document/analyze y /v1/biometrics/verify (red interna).

Prueba con set de imágenes de referencia: OCR/MRZ, face match y PAD devuelven criterios esperados.

Latencia de inferencia dentro del objetivo acordado (p95 documentado en la entrega).

La versión del modelo ONNX queda registrada en los resultados generados.

Fallback VLM

Qwen-VL operativo en el Dell GB10 y alcanzable desde el API Core (red interna).

Prueba de degradación: imagen de baja confianza activa el fallback y devuelve evaluación complementaria.

Las imágenes enviadas al VLM se anonimizan y se eliminan tras la respuesta.

El modo nube (Gemini) solo está habilitado si el cliente lo autorizó por escrito.

Con el VLM caído, el servicio continúa operando y las verificaciones se marcan para revisión manual.

Auth Token Móvil

Emisión de client_id / client_secret por entorno completada y entregada por canal seguro.

Intercambio client-credentials → JWT funciona; el token expira según el TTL configurado (15–30 min).

El SDK renueva el token automáticamente antes de la expiración (prueba de sesión larga).

Revocación verificada: un token revocado recibe 401 y una credencial revocada invalida todos sus tokens.

El client_secret no existe en el binario ni en el almacenamiento de la app (solo backend).

Emisión y revocación registradas en auditoría con timestamp y actor.

Screening AML/PEP (Fase 1)

Migración V12 aplicada: tabla identity.aml_pep_config con RLS y criterio aml_pep_screening sembrado en políticas de enroll. No aplica a políticas de verify.

Configuración del tenant piloto: enabled=true, required=true, matchThreshold=0.8 (o los valores acordados con el cliente).

Enroll de prueba cleared: identidad sintética limpia → screening pasa y el flujo biométrico continúa. sys_aml_pep_status=cleared en el detalle de la sesión

Enroll de prueba HIT: coincidencia con lista de demostración → outcome rejected (override regulatorio). Nunca se aprueba un hit, aunque el resto de criterios pasen

Con screening no disponible y required=true, la sesión queda en revisión humana (nunca se aprueba en silencio).

Rastro de auditoría sys_aml_pep_* presente en el detalle de la sesión (proveedor, estado, score, lista, nombre coincidente).

Listas de producción: archivo JSON licenciado (SEPRELAD / OFAC / UE / ONU) montado; el catálogo sintético de laboratorio no se usa en el entorno del cliente. OpenSanctions civic = CC-BY-NC, no comercial. Comercial requiere licencia.

Matching on-prem: la PII del titular no sale de la infraestructura del cliente. Flag enabled=false deja el flujo intacto.

Cierre de la validación

Todas las incidencias detectadas quedaron registradas y con responsable asignado.

Acta de conformidad del entorno firmada por el responsable del cliente y por ParaguayDev.