Seguridad de datos y gobernanza de IA

1. Gestión de accesos

• Cada usuario (analista, admin, especialista) tiene una cuenta individual con contraseña propia; no hay usuarios compartidos.
• El acceso a rutas administrativas requiere rol de administrador verificado en cada pedido al servidor, no solo en la pantalla: se auditó específicamente que ninguna ruta de administración quede abierta a un usuario de menor privilegio.
• El inicio de sesión limita los intentos fallidos por IP y por correo, como defensa contra el rociado de contraseñas.
• Alta de usuarios controlada: nadie se autoregistra en un entorno sin una lista explícita de correos o dominios permitidos.

2. Cifrado y protección de datos

• Datos en tránsito cifrados (HTTPS/TLS) en todos los canales: aplicación web, webhooks de WhatsApp y Gmail, y llamadas al modelo de IA.
• Adjuntos (fotos, documentos) en almacenamiento cifrado, con acceso controlado por credenciales que nunca se exponen al navegador.
• Los tokens y llaves que descifran credenciales de casillas de correo están marcados de solo escritura en la plataforma de despliegue: ni siquiera quien los cargó puede volver a leerlos.

3. Aislamiento entre aseguradoras (multi-tenant)

Cada aseguradora es un tenant aislado a nivel de base de datos. Ninguna consulta del producto puede saltear el filtro por aseguradora: está reforzado con Row-Level Security de Postgres, no solo con lógica de aplicación. Es el control más crítico del sistema —una falla acá expondría datos de una cartera a otra— y por eso es el que más se prueba: en cada ciclo de control se crean datos de una aseguradora y se confirma, por cada vía de acceso (pantalla, listado, búsqueda, exportación, y las herramientas del propio agente de IA), que ninguna otra aseguradora puede verlos.

4. Subencargados de tratamiento (infraestructura)

Todos son proveedores cloud de primer nivel con sus propias certificaciones de seguridad. Ninguno recibe datos de la aseguradora para fines distintos de prestar el servicio contratado.

5. Gestión de incidentes

• Errores de la aplicación se capturan con seguimiento de errores en tiempo real (Sentry); el contenido crudo de mensajes de asegurados nunca se registra en logs de texto plano.
• Un endpoint de salud monitorea continuamente base de datos, almacenamiento, modelo de IA y canales de mensajería, y reporta caídas antes de que las note un usuario.
• Cambios de comportamiento del agente pasan por un ciclo de pruebas automatizado antes de llegar a producción.

6. Gobernanza del modelo de IA

• No se entrena ningún modelo con datos de clientes ni de asegurados, ni por Veltra ni por sus subencargados — cláusula contractual del Anexo de Tratamiento de Datos.
• Límite de decisión explícito: el modelo no determina cobertura, no acepta ni rechaza siniestros, no cuantifica daños ni liquida (art. 56, Ley 17.418). Prepara el expediente; la aseguradora decide.
• Revisión humana obligatoria en casos de severidad alta o crítica y ante cualquier indicio de datos de salud — el sistema no ingiere datos de salud en su flujo automatizado, por diseño.
• Umbral de confianza: casos por debajo de un umbral configurado se enrutan a revisión humana en lugar de auto-procesarse.
• Trazabilidad: cada resultado queda registrado con su fuente documental, nivel de confianza, versión del modelo y de las reglas aplicadas, e identidad del revisor humano.
• Validación activa, no solo documentada: el comportamiento del agente se pone a prueba con casos de ensayo completos (conversaciones enteras) antes de cada despliegue a producción, y se somete a pruebas de resistencia a instrucciones maliciosas.

7. Sobre certificaciones formales

Hoy Veltra no cuenta con certificaciones formales tipo SOC 2 o ISO 27001 propias. Los controles descritos en esta página son los que efectivamente operan en producción. Preferimos declarar esto con precisión antes que dar a entender una certificación que no existe.