Determinista. On-premise. Auditable de extremo a extremo.
Liquid se diseñó desde el día cero para entrar a bancos regulados sin pasar por revisión SARLAFT extraordinaria. Tres principios: la decisión es estadística (no LLM), los datos no salen del perímetro, cada acción es trazable al dato y regla que la disparó. Este documento es el que comparten con CTO/CISO antes del security review formal.
Principios de diseño
D
Determinismo
La decisión la toma un motor de reglas inspeccionable sobre outputs de modelos estadísticos clásicos (Prophet). El LLM solo traduce — nunca decide.
O
On-premise
El stack completo corre dentro del perímetro del banco. No hay llamadas API a servicios externos. Llama 3.1 deployment local, sin OpenAI, sin Anthropic, sin nada que mande tokens afuera.
R
Read-only
Liquid solo lee del aggregator y del core bancario. Nunca escribe transacciones, mueve fondos ni autoriza operaciones. Esto saca a Liquid del scope de cualquier auditoría transaccional.
A
Auditable
Cada alerta, recomendación y acción tiene un linaje: dato origen → regla aplicada → umbral disparado → output → recipient. Todo log inmutable, exportable, firmable.
Topología de despliegue
Diagrama del despliegue típico en infraestructura del banco. Todo dentro del DMZ interno del banco — sin internet egress excepto para reportes de licencia (heartbeat opcional).
Sistemas del banco / consumidoresComponente LiquidLLM (solo interpretación)Flujo de datos read-only / outputs
Flujo de datos · capa por capa
Cinco pasos del pipeline. En cada uno: qué pasa, qué datos cruzan, qué controles aplican.
Paso01
Ingestión read-only del aggregator y core. Liquid consume vía API REST autenticada cada 5 minutos: transacciones del día, estado de cupos, eventos de cash-in / cash-out. No tiene credenciales de escritura.
read-onlyTLS 1.3API key + IP allowlist
Paso02
Almacenamiento on-prem encriptado. Postgres + Timescale en infraestructura del banco. AES-256 at rest. Backups encriptados con KMS del banco. Retención configurable (defecto 24 meses). PII pseudonimizada al cargar.
AES-256 at restPII pseudonimizadaBackups 30d
Paso03
Procesamiento estadístico determinístico. Prophet calcula forecasts diarios/horarios por corresponsal. Min-max calcula cupos óptimos. TSP resuelve rutas. Todo es matemática clásica reproducible — mismo input = mismo output, siempre.
determinísticoreproducibleCPU-only
Paso04
Motor de reglas + interpretación. El rules engine evalúa condiciones (SI cupo < 25% Y forecast agotamiento < 3h → SMS). Llama 3.1 traduce el output a español natural solamente para el dashboard y reportes. La decisión ya fue tomada por la regla.
inspeccionableLLM solo interpretaoverrideable
Paso05
Acciones y registro inmutable. Liquid emite alertas a SMS/WhatsApp del banco, agenda rutas Brinks vía API, y genera reportes SARLAFT. Cada acción se loguea con: dato origen + regla + timestamp + recipiente + status. Log inmutable, exportable, firmable.
No certificado. Diseño alineado a controles ISO. Certificación evaluada para 2027.
○ Roadmap
Cumplimiento regulatorio (Colombia)
SARLAFT
Compatible
Circular Básica Jurídica · Cap. IV
Liquid no procesa transacciones — solo monitorea patrones y alerta sobre anomalías estadísticas. Esto encaja en "herramientas de detección" del SARLAFT, no en "sistemas transaccionales". Los reportes ROS se generan en formato SFC, listos para el oficial de cumplimiento del banco.
Habeas Data
Cumple
Ley 1581 de 2012 · Decreto 1377
Datos personales pseudonimizados al ingestar. Política de privacidad y DPA (Data Processing Addendum) provistos por contrato. Derecho a rectificación/eliminación implementado vía API. El banco mantiene el rol de Responsable; Liquid el de Encargado.
Circular Externa 008/2024 SFC
Compatible
Uso de IA en servicios financieros
El LLM (Llama 3.1) no toma decisiones críticas — solo interpreta y comunica outputs ya generados por el motor estadístico y de reglas. La SFC requiere "explicabilidad" — Liquid es 100% explicable por diseño: cada decisión rastreable a una fórmula y un umbral.
Circular Externa 029/2022 SFC
Compatible
Riesgos tecnológicos y ciberseguridad
Liquid se alinea a los controles del Anexo I (gobierno, gestión, monitoreo y respuesta a incidentes). El despliegue on-premise simplifica el cumplimiento — no hay terceros gestionando datos del banco.
PCI DSS
N/A
Liquid no toca PAN
Liquid no procesa, almacena ni transmite Primary Account Numbers (PAN). Está fuera del scope de PCI DSS. Los datos manejados son agregados operativos: cupos, transacciones (sin tarjeta), saldos por corresponsal.
Outsourcing financiero
Compatible
Circular Externa 005/2019 SFC
Al ser despliegue on-premise sin terceros gestionando infra crítica, Liquid no se clasifica como "outsourcing de servicios críticos". Notificación a SFC suficiente — no requiere aprobación previa.
Respuesta a incidentes · SLA
Cuatro niveles de severidad con tiempos de respuesta contractuales. Incumplimiento genera créditos automáticos según el SLA del tier.
Sev 1
Crítico — sistema down
Sistema no disponible o pérdida de datos. Equipo on-call respondiendo, comunicación cada hora.
SLA: 15 min respuesta · 4h resolución
Sev 2
Alto — funcionalidad degradada
Feature crítico no funciona, workaround disponible. Engineer asignado, update cada 4h.
SLA: 1h respuesta · 24h resolución
Sev 3
Medio — bug no bloqueante
Bug que no afecta operación crítica. Tracking en sistema, fix en próximo release.
¿Qué pasa si Llama 3.1 alucina y le dice algo incorrecto a un operador?
La capa LLM tiene acceso solo a outputs ya generados por el motor estadístico y el rules engine. No le pasamos el dataset completo ni le pedimos que decida. Si alucina sobre un número, el dashboard muestra el dato fuente al lado — el operador verifica en 1 segundo. Y nunca tomamos acción solo basados en texto del LLM; las acciones se disparan desde reglas determinísticas.
¿Cómo manejan model drift de Prophet con el paso del tiempo?
Re-entrenamiento automático nocturno con ventana móvil de 90 días. Métrica de drift (KL divergence sobre la distribución de errores) monitoreada continuamente — si supera umbral, alerta al equipo de Liquid + al banco. Re-baseline manual disponible vía dashboard.
¿Qué sucede si su equipo accede a datos del banco para soporte?
Por defecto, no hay acceso remoto. Si se requiere troubleshooting profundo, el banco aprueba una sesión just-in-time vía bastion host del banco, con grabación de pantalla. Todos los accesos se loguean en el SIEM del banco y se reportan en el audit log mensual.
¿Cuál es el plan si Liquid (la empresa) cierra mañana?
Tres mitigaciones contractuales: uno, source escrow — código fuente y modelos custom depositados con tercero (ej. Iron Mountain). Dos, la documentación completa de reglas activas y modelos se exporta mensualmente al banco. Tres, deployment 100% on-prem — si Algorithm-IA desaparece, el sistema sigue corriendo en infra del banco indefinidamente con el último release.
¿Pueden integrar con nuestro SIEM y herramientas de DLP existentes?
Sí. Liquid emite logs estructurados (JSON) compatibles con Splunk, ELK, Sumo Logic, Datadog, Sentinel. Para DLP, las salidas (SMS, reports, dashboard) pueden enrutarse vía gateways del banco para inspección. Acoplamiento estándar — sin instalar agentes propietarios.
Transparencia: lo que no tenemos hoy
Como startup, somos honestos sobre el roadmap de madurez. SOC 2 Type II: en curso, certificación Q4 2026. ISO 27001: alineados al control set, certificación evaluada 2027. BAA / HIPAA: no aplica (no manejamos PHI), no en roadmap.
Mientras tanto operamos con controles equivalentes documentados, pen tests trimestrales por tercero, y revisiones de seguridad por solicitud del cliente. Para bancos donde SOC 2 es bloqueante, recomendamos esperar Q1 2027 — o avanzar con un piloto que no toque datos de producción mientras tanto.