Guía del piloto BICSA

Esta guía es un borrador operativo. Los datos locales son sintéticos y los criterios jurídicos, comerciales y de SLA requieren aprobación antes de conectar el corpus.

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 sintética por cédula y otra 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;
• los resultados identifican fuente, documento, fecha, coincidencia e identificador trazable;
• 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.

Paso a datos realesCopiar enlace

La aceptación técnica con datos sintéticos no autoriza uso productivo. La activación del corpus requiere revisar el esquema en Contabo, documentar cobertura y actualización, calibrar identidad y ambigüedad, aprobar la base jurídica y ejecutar pruebas con casos controlados.