Seguridad y confianza
Seguridad y confianza, por diseño.
Los datos empresariales viven en entornos regulados. La postura de seguridad de Fligoo está diseñada para esos entornos — no adaptada a ellos. Cada capa, desde el acceso a la inferencia, está construida para que el audit trail responda las preguntas que va a hacer un equipo de compliance, riesgo o due diligence de M&A.
Un stack de seguridad de cuatro etapas a lo largo de la implementación.
La seguridad se secuencia en el deployment, no se pega al final. Cada etapa es observable, auditable y alineada al framework de políticas existente del cliente.
01
Stage
Setup de la capa de seguridad
Túneles VPN o gateways de conexión segura al ambiente del cliente; cifrado de extremo a extremo en tránsito y en reposo; acceso basado en roles (RBAC); alineación con SOC 2, GDPR y políticas específicas del cliente.
02
Stage
Acceso e integración de datos
Múltiples caminos seguros de integración — servidores API y MCP, uploads SFTP de archivos estructurados, acceso directo de solo lectura a base de datos e integración de buckets cloud vía IAM y URLs firmadas. El mapeo de schema se automatiza donde es posible.
03
Stage
Selección de datos
Mapas de datos pre-definidos para servicios financieros con priorización incorporada por caso de uso. Los clientes no modifican sus sistemas — nosotros nos adaptamos a ellos. Las herramientas de auto-discovery exponen señales relevantes en perfil de cliente, nivel de cuenta, engagement, uso de producto y datos comportamentales.
04
Stage
Movimiento y procesamiento de datos
Framework modular de ingesta con conectores plug-and-play (Salesforce, Snowflake, Redshift, BigQuery, S3, Azure Blob, GCP), procesamiento event-driven y reglas de descarte — cambio mínimo del lado del cliente.
Autenticación y acceso
Identidad, MFA y acceso basado en roles enforced en todos lados.
Autenticación basada en JWT
Tokens stateless y tamper-evident, scoped por servicio y por rol.
MFA vía TOTP
Contraseñas time-based one-time exigidas para acceso humano a superficies sensibles.
Role-Based Access Control (RBAC)
Permisos modelados por rol y scoped a los datos, modelos y herramientas que cada rol legítimamente necesita.
Acceso de query con scope por perfil
Los perfiles de query de base de datos angostan el scope de tablas por rol — analistas, ML engineers y operadores ven solo lo que su trabajo requiere.
Cifrado de extremo a extremo y un perímetro endurecido.
Los datos se cifran en reposo y en tránsito, se mueven sobre canales VPN o URLs firmadas y nunca se replican fuera del perímetro acordado.
En tránsito
TLS para canales de API y base de datos directa; URLs firmadas para transferencia de buckets cloud; túneles VPN para caminos de conexión directa.
En reposo
Cifrado cloud-native sobre data lake, artefactos de modelos y logs de auditoría — keys gestionadas en el KMS del cliente donde se requiera.
Perímetro
Acceso de solo lectura donde sea posible; sin write-back a sistemas origen a menos que el caso de uso lo requiera y el cliente lo apruebe.
Compliance
SOC 2, GDPR y políticas específicas del cliente.
SOC 2
Prácticas operativas alineadas a los controles SOC 2 sobre seguridad, disponibilidad, integridad de procesamiento, confidencialidad y privacidad.
GDPR
Minimización de datos, limitación de propósito, derechos del titular y fronteras processor-controller soportadas en el diseño.
Alineación con política del cliente
Los engagements se acotan para honrar políticas de seguridad de la información, reglas de residencia de datos y requisitos de auditoría de cada cliente.
Guardrails de IA
Confiabilidad y safety enforced a lo largo del ciclo de vida del modelo.
El mismo framework de guardrails de cuatro capas documentado en la página de plataforma se aplica a cada deployment — datos, modelo, output y sistema.
01
Datos
Validación de schema, detección de drift, filtrado de PII y chequeos de atributos sensibles antes de que los datos entren a entrenamiento o inferencia.
02
Modelo
Ajustes de fairness, ruido de privacidad diferencial donde aplica y chequeos de estabilidad que flaggean inestabilidad antes de que llegue a producción.
03
Output
Chequeos de toxicidad y compliance de política sobre cada predicción; metadata de explicabilidad adjunta a cada score.
04
Sistema
Engine de política, log de auditoría, SLA de retraining y readiness para rollback — la recuperación es un procedimiento conocido, no una improvisación.
Guardrails operativos
Restricciones aplicadas en la frontera de la base de datos y la inferencia.
Las superficies de IA generativa — incluyendo cualquier acceso en lenguaje natural a datos empresariales — operan dentro de límites explícitos y por capas.
Ejecución SQL en dos etapas
Patrón show-then-run: las queries se validan y explican antes de ejecutarse.
Limitación de resultados
Los result sets se topean en la capa de aplicación (FETCH FIRST 1000 ROWS ONLY) sin importar la intención de la query.
Límites de complejidad de query
Joins topeados en dos; SELECT * deshabilitado; cláusulas WHERE requeridas; ejecución index-aware preferida.
Preview de complejidad LLM-as-a-Judge
El patrón EXPLAINSQL permite al modelo evaluar la complejidad de la query y el probable impacto de performance antes de correrla.
Validación sintáctica
Cada query generada se parsea y valida contra la gramática permitida antes de llegar al engine de base de datos.
Timeouts agresivos
Timeouts cortos de query aseguran que las operaciones runaway se interrumpan mucho antes de afectar cargas de producción.
Auditabilidad y lineage
Trazabilidad total — de la ingesta de datos a la recomendación del modelo.
Lineage de datos
Catálogo y versión de cada dataset entrando al pipeline, con métricas de calidad y descarte logueadas.
Trazabilidad de modelos
MLflow + model registry + Bitbucket — cada training run, hash de dataset y configuración de features es reproducible.
Justificación a nivel de predicción
Top drivers y contrafactuales adjuntos a cada recomendación, para que los equipos de auditoría puedan responder al "¿por qué?".
Auditoría de sesgo
Auditorías de fairness sobre atributos protegidos con resultados logueados junto a la model card.
Residencia de datos
Federated learning donde los datos no pueden salir del perímetro.
Cuando la regulación, las restricciones de partnership o la tolerancia al riesgo prohíben el movimiento de datos, los modelos fundacionales pueden entrenarse federadamente. Solo los aprendizajes — nunca los datos crudos, nunca las features — cruzan la frontera.
¿Listos para volver la IA una línea medible en tu P&L?
Diseñamos, desplegamos y operamos IA empresarial junto a tu equipo.