Guía del piloto BICSA

Esta guía describe el piloto controlado. La infraestructura y el corpus real están conectados, pero la API solo publica causas que hayan superado la política automática de evidencia, cobertura y confianza. Los casos insuficientes responden como no concluyentes; los criterios jurídicos, comerciales y de SLA aún requieren aprobación antes de ampliar el canario.

AltaCopiar enlace

1. Resillia crea la organización BICSA desde administración.
2. Asigna el primer usuario con rol owner mediante invitación cerrada.
3. El propietario invita a administradores o miembros adicionales desde Configuración → Miembros.
4. Resillia define estado, cuota, retención, precio, vigencia de claves, tipos y finalidades permitidos.
5. Un propietario o administrador de BICSA genera la primera clave rsl_test_…; el secreto completo se muestra una sola vez.

Validación técnicaCopiar enlace

La aceptación automatizada local se ejecuta con:

pnpm --filter @repo/scripts verify:person-search-pilot

El comando crea una credencial efímera, consulta la API, verifica ledger y cuota, revoca la credencial, confirma el rechazo y elimina los datos de prueba incluso si la ejecución falla.

• importar la colección Postman o el contrato OpenAPI;
• realizar una consulta controlada por cédula, otra por RUC y una exploratoria por nombre;
• conservar requestId y X-Request-Id en los logs de integración;
• comprobar que una clave revocada o vencida recibe 401;
• comprobar que una regla no habilitada recibe 403;
• confirmar que cuota, historial y unidades facturables aparecen solo en la organización BICSA.
• descargar el reporte CSV mensual y reconciliar el total con el consumo por credencial.

Criterios de aceptación propuestosCopiar enlace

• las credenciales y resultados de una organización no son accesibles desde otra;
• una consulta válida genera exactamente una unidad facturable;
• el límite mensual no puede superarse con solicitudes simultáneas;
• el historial nunca almacena el nombre o la cédula completos;
• cada causa publicada identifica rol, estado, decisión, efecto vigente y fuentes trazables;
• ninguna mención sin consolidar se presenta como causa confirmada;
• las respuestas técnicas cumplen el contrato OpenAPI acordado.

Operación y soporteCopiar enlace

Para el piloto se propone un único contacto operativo por cada parte, registro de incidentes por requestId y ventana de mantenimiento previamente comunicada. Disponibilidad, tiempos de respuesta, soporte y créditos de servicio se definirán en un SLA separado después de medir el entorno DEV.

Ampliación del canario realCopiar enlace

La conexión técnica al corpus no autoriza por sí sola el uso para decisiones. Antes de ampliar el piloto deben aprobarse la muestra de calibración, los umbrales de identidad, rol, estado y efecto económico, la base jurídica por finalidad, el procedimiento de rectificación y retiro, y las pruebas de carga y recuperación.