Seguridad y arquitectura

Cuatro compromisos guían las decisiones técnicas de la plataforma:

• El modelo de IA no consulta bases de datos directamente ni genera datos: invoca funciones tipadas y devuelve la respuesta con su fuente.
• Cuando los datos no soportan la respuesta, el sistema se abstiene explícitamente en lugar de inferir.
• Cada operación queda registrada en logs append-only: argumentos, resultado, duración y responsable.
• Los datos personales tratados con autorización del titular se anonimizan antes que se eliminan en duro, preservando la integridad referencial de los registros de auditoría.

La arquitectura está diseñada para mantener al modelo de lenguaje fuera del camino crítico del dato:

• Tool-calling determinístico: el modelo IA recibe respuesta de funciones tipadas (Python). No genera SQL, no consulta tablas directamente, no escribe en producción.
• Sin text-to-SQL: las consultas a bases de datos productivas pasan por funciones revisadas en código y testeadas — el modelo elige qué función llamar, no cómo consultar la base.
• Composer testeable: la lógica de orquestación entre tools, base de datos y respuesta final está separada del modelo y cubierta por tests automatizados.
• Fail-loud por diseño: si una herramienta no puede responder con evidencia, no inventa una salida — falla de forma observable y queda registrado.

El proveedor del modelo de lenguaje y su región de inferencia dependen de la versión del producto:

Los datos del cliente — bases internas, documentos, históricos — permanecen en la infraestructura descrita en la sección 6. Lo que viaja al proveedor de LLM son los prompts construidos por el orquestador de Alicanto y la respuesta estructurada que devuelve el modelo.

Controles disponibles hoy en la versión pública:

• Autenticación con contraseña + Google OAuth (OpenID Connect).
• Contraseñas hasheadas con Argon2id (sin costo computacional fijo, parámetros ajustables ante avance de hardware).
• MFA TOTP obligatorio: códigos de 6 dígitos cada 30 segundos, secretos cifrados con Fernet (AES-128-CBC + HMAC-SHA256), protección anti-replay y diez recovery codes hasheados con Argon2.
• Tokens de acceso de 15 minutos, refresh tokens de 30 días con rotación y detección de reutilización.
• Cookies HttpOnly + Secure + SameSite=Lax (prefijo __Host- en producción) para tokens; tokens nunca expuestos a JavaScript.
• Protección CSRF por double-submit cookie + SameSite.
• Sin telemetría de terceros en el cliente (sin Google Analytics, sin Mixpanel, sin pixels de tracking).

Controles enterprise:

• SSO corporativo SAML 2.0 / OIDC contra el directorio del cliente (Azure AD, Okta, Google Workspace, Keycloak): disponible bajo contrato.
• Roles configurables por institución y audit log de accesos.
• Provisión y des-provisión automática vía SCIM: disponible bajo contrato.

• Cifrado en tránsito: TLS 1.2+ obligatorio en todos los servicios; HSTS con max-age de un año e includeSubDomains en producción.
• Cifrado en reposo: AES-256 gestionado por Google Cloud sobre Cloud SQL (PostgreSQL) y Cloud Storage; cifrado del filesystem en Cloud Run.
• Hash de contraseñas: Argon2id.
• Cifrado simétrico de secretos sensibles a nivel aplicación (semillas TOTP, tokens de larga vida): Fernet (AES-128-CBC + HMAC-SHA256) con claves rotables.
• Gestión de secretos: Google Secret Manager con acceso mediado por Workload Identity Federation. Las claves de firma JWT, de cifrado TOTP, de hashing de tokens y las API keys de terceros nunca se persisten en código ni en variables de entorno locales.
• Rotación de credenciales: los secrets de Secret Manager pueden rotarse sin redeploy; los tokens largos se hashean (HMAC) antes de almacenarse en base de datos.

Controles enterprise:

• Customer-Managed Encryption Keys (CMEK): la institución provee y controla la llave maestra para datos en reposo. Puede rotarla o revocarla en cualquier momento, deteniendo el acceso de Alicanto. Disponible bajo contrato.

Residencia — versión pública (estado actual):

• Datos en reposo: GCP región us-central1 (Iowa, Estados Unidos) — bases relacionales, almacenamiento de objetos, backups.
• Cómputo y orquestación: Cloud Run en us-central1.
• Inferencia LLM: regiones del proveedor (ver sección 3) — el prompt construido y la respuesta estructurada son lo único que viaja entre regiones.

Residencia — versión enterprise:

• Despliegues en GCP región Santiago (southamerica-west1) cuando el cliente lo requiere — datos en reposo, cómputo y orquestación.
• BYOC: en el tenant GCP del cliente, sobre la región que la institución defina como política de residencia.
• Inferencia LLM en la región Vertex acordada (sección 3).

Modelo de aislamiento — versión pública:

• Multi-tenant lógico: instancia única de Cloud SQL, schema único, aislamiento por filtros de aplicación obligatorios (cada query se filtra por identidad del usuario).
• Datos públicos compartidos (CMF, Banco Central) en mismo schema, solo lectura para todos los usuarios.
• Tokens efímeros y de propósito específico (link codes, password reset, TOTP challenges) con TTL corto y limpieza programada.

Modelo de aislamiento — enterprise: Row-Level Security en PostgreSQL o instancia dedicada por institución, según el alcance del contrato.

• Row-Level Security en PostgreSQL: el aislamiento entre tenants se aplica a nivel del motor de base de datos. Cada fila queda etiquetada con su tenant y las políticas RLS filtran automáticamente toda consulta — incluso si la aplicación contiene un error, la base no devuelve datos de otro tenant.
• Instancia dedicada por institución: cuando el alcance del contrato lo justifica (volumen, sensibilidad, requisito regulatorio), la base de datos se aprovisiona como instancia exclusiva, sin compartir cómputo ni almacenamiento con otros clientes.
• BYOC (Bring Your Own Cloud): la institución provee el proyecto GCP y Alicanto despliega dentro de ese tenant. Los datos nunca cruzan a infraestructura de Alicanto.

Cada operación significativa queda registrada en tablas append-only protegidas por triggers de base de datos que bloquean UPDATE y DELETE a nivel de motor:

• agent_actions: una fila por turno del agente — tipo de propuesta, parámetros, resultado, duración, job asociado.
• audit_events: ingestas de datos, accesos por token, ejercicios de derechos sobre datos personales, fusiones de identidades.
• messages: historial conversacional con dirección, autor, tipo, cuerpo y referencias a artefactos asociados.
• jobs: ejecuciones del worker con estado, errores y duración.

Cada respuesta del agente incluye referencia verificable a la fuente: período, identificadores, subset de registros que sostiene la respuesta. Una respuesta sin referencia rastreable no se entrega — el agente se abstiene.

El tratamiento de datos personales del sitio web público se describe en detalle en la Política de Privacidad. Para los datos personales tratados dentro del producto SaaS (donde Alicanto actúa como encargado de tratamiento de la institución cliente), las condiciones se rigen por el Acuerdo de Tratamiento de Datos (DPA) firmado con cada cliente.

• Anonimización en lugar de hard delete: al ejercer el derecho de supresión, se nulifican email, password hash, identificadores OAuth y nombre, dejando un registro tombstone que preserva la integridad de los logs de auditoría.
• Redacción de PII en feedback y telemetría: emails, RUT y números de cuenta detectados en texto libre se reemplazan por marcadores ([EMAIL], [RUT], [ACCOUNT]) antes de almacenarse.
• Retención por categoría documentada en la Política de Privacidad.
• Canal único para ejercicio de derechos: privacidad@alicantoai.cl.

Subprocesadores actuales de la plataforma (no del sitio web público; la lista del sitio está en la Política de Privacidad):

• Backups automáticos diarios de Cloud SQL con retención configurable; point-in-time recovery habilitado.
• Migraciones de base de datos versionadas (Goose) y ejecutadas mediante usuario DDL dedicado, separado del usuario CRUD que usa la aplicación.
• Modo mantenimiento activable durante despliegues para evitar escrituras en ventanas críticas.
• Cloud Run sin estado en disco: las instancias son efímeras; el estado vive en Cloud SQL y Cloud Storage.
• Cloud Tasks como cola desacoplada entre webhook y worker, con rate limits conservadores para proteger backends.

Controles enterprise:

• RTO/RPO documentado en el contrato según la criticidad del caso de uso.
• Ejercicios de disaster recovery con el cliente cuando la institución los exige.

• Pipeline CI/CD en GitHub Actions con autenticación contra GCP mediante Workload Identity Federation (sin credenciales de servicio de larga vida).
• Imágenes Docker construidas en cada commit con SHA único y publicadas en Artifact Registry.
• Migraciones aplicadas como Cloud Run Job aislado antes del despliegue de la aplicación.
• Code review obligatorio antes de merge a main para todo cambio que toque rutas productivas.
• Dependencias auditadas: revisión periódica de avisos de seguridad sobre paquetes utilizados.
• Secretos de despliegue (claves de servicio, tokens de terceros) inyectados al runtime desde Secret Manager, nunca commiteados.

Roadmap (sección 13):

• SAST y dependency scanning automatizados como gate en CI.
• Firma de imágenes de contenedor (Cosign / Sigstore) y verificación en despliegue.
• Programa formal de pruebas de penetración con terceros independientes.

Marcos regulatorios chilenos relevantes con los que diseñamos para alinearnos:

• Ley 19.628 sobre Protección de la Vida Privada (vigente).
• Ley 21.719 sobre Protección de Datos Personales (vigencia plena el 1 de diciembre de 2026). Aplicamos voluntariamente sus garantías más estrictas durante el régimen de transición.
• RAN 20.7 de la CMF sobre Gestión del Riesgo Operacional y la Continuidad del Negocio (con la reforma de 2027 en horizonte).
• REDEC y reportes regulatorios D10, C11, R13 — relevantes para nuestros servicios de automatización de reportería regulatoria.

Certificaciones:

• ISO/IEC 27001 (Sistema de Gestión de Seguridad de la Información): en preparación.
• SOC 2 Type II (Trust Services Criteria — Security, Availability, Confidentiality): en preparación.

Resumen consolidado de los controles disponibles bajo contrato enterprise o en horizonte de implementación. Los plazos son indicativos y se concretan en función del compromiso comercial de cada cliente:

Si descubres una vulnerabilidad en cualquiera de nuestros activos (sitio web, plataforma SaaS, infraestructura, dependencias), contáctanos a security@alicantoai.cl. Te confirmaremos recepción en un plazo razonable y coordinaremos contigo el ciclo de divulgación.

Solicitamos a la comunidad de investigación de seguridad:

• Reportar el hallazgo de forma privada antes de divulgarlo públicamente, dándonos tiempo razonable para mitigar.
• No acceder, modificar ni divulgar datos de otros usuarios; detenerse al confirmar que el hallazgo es válido.
• No realizar pruebas que degraden el servicio, generen denial-of-service, ni envíen spam a otros usuarios.
• Operar dentro del marco legal aplicable.

Reconocemos públicamente, con autorización del investigador, a quienes nos ayuden a mejorar la postura de seguridad de Alicanto. No operamos todavía un programa formal de bug bounty con compensación monetaria; cuando lo lancemos se anunciará en esta página.

Actualizamos esta página cuando cambia un control de seguridad relevante para clientes, cuando se publica una nueva certificación o cuando el roadmap avanza. La fecha visible al inicio de la página corresponde a la última actualización material; cambios menores de redacción no actualizan la fecha.

Los clientes enterprise bajo DPA son notificados de cambios materiales con razonable anticipación a través del canal acordado en el contrato.