*Borrador para revisión de abogado colombiano*
*Documento interno — no se publica*

**IALABS.APP · AGENTRIXLABS.COM.CO · S360.TECH — CORDOVA GROUP S.A.S.**

# Política de Seguridad de la Información y Protocolo de Incidentes

Versión 1.0 · Vigente desde el 22 de octubre de 2026 · Cordova Group S.A.S., NIT 901578119-7 · Sitios: ialabs.app (sitio principal), agentrixlabs.com.co y s360.tech

## 1. Objeto y alcance

1.1 Esta Política fija los controles de seguridad de Cordova Group S.A.S. («ialabs») para la Plataforma, los Sitios, las integraciones con Meta y Google y los Desarrollos a la Medida. Desarrolla el deber de seguridad de los artículos 4 (literal g), 17 (literal d) y 18 (literal b) de la Ley 1581 de 2012, la cláusula 3 y el Anexo B del Contrato de Transmisión de Datos (02) y la sección 15 de la Política de Privacidad (08).

1.2 Los controles son proporcionados a una microempresa de una o dos personas. Cada control indica si existe hoy o si es una brecha (sección 6). Lo que no existe no se presenta como cumplido ante clientes, Meta, Google ni la SIC.

1.3 Aplica a toda persona con acceso a sistemas o datos de ialabs: el representante legal, contratistas y proveedores.

## 2. Responsable de seguridad

2.1 El responsable de seguridad es **Mateo Piza Ruiz**, Representante Legal y Oficial de Protección de Datos. Aprueba accesos, cambios de proveedor y la respuesta a incidentes, y lleva la bitácora de incidentes.

2.2 Todo contratista con acceso a datos firma, antes de empezar, un acuerdo de confidencialidad y las reglas de esta Política.

## 3. Inventario de sistemas

| Sistema | Uso | Datos que contiene | Ubicación | Criticidad |
|---|---|---|---|---|
| VPS de OVHcloud con Dokploy y Traefik | Aplicación de la Plataforma, API, n8n autoalojado | Datos en tránsito y en proceso; configuración; secretos de la aplicación | Estados Unidos | Alta |
| Cloudflare (DNS, Tunnels, protección web, R2) | Exposición de servicios sin abrir puertos del VPS; archivos y audios en R2 | Audios, archivos, copias lógicas | Estados Unidos o Unión Europea; tránsito por su red | Alta |
| Supabase Pro (Postgres) | Base de datos principal | Cuentas, conversaciones, transcripciones, tokens cifrados, índices de búsqueda | Estados Unidos o Unión Europea | Alta |
| n8n Cloud | Flujos de automatización | Datos que pasan por los flujos y registros de ejecución | Unión Europea | Media |
| GitHub y GitHub Actions | Código, despliegue | Código y secretos de despliegue | Estados Unidos | Alta |
| Lovable | Construcción de interfaces | Código de interfaces; no debe contener datos reales | Estados Unidos | Media |
| OpenAI, Anthropic, Groq, OpenRouter | Modelos de lenguaje | Mensajes y fragmentos enviados en cada consulta | Estados Unidos | Alta |
| ElevenLabs | Voz: síntesis, transcripción, agentes y modelos de voz | Audio, transcripciones, modelos de voz (biométricos) | Estados Unidos | Alta |
| Twilio | Telefonía, SMS, grabaciones | Registros de llamadas y grabaciones | Estados Unidos | Alta |
| Resend | Correo transaccional | Destinatarios y contenido de avisos | Estados Unidos | Baja |
| Meta (usuario del sistema y tokens de WABA) | Operar WhatsApp, Instagram y Messenger del Cliente | Tokens de acceso | Cuenta del Cliente | Alta |
| Google (OAuth) | Calendar, Gmail (solo envío), Drive (archivos elegidos) | Tokens de acceso y actualización | Cuenta del Cliente | Alta |
| Dapta (temporal, durante la migración) | Agentes de algunos clientes | Conversaciones y llamadas de esos clientes | Por confirmar | Alta |
| HubSpot | CRM propio | Prospectos y clientes | Estados Unidos | Media |
| Bold | Pagos | Datos de pago del Cliente (no los guardamos) | Colombia | Media |
| Portátil del representante legal | Administración | Acceso a todos los paneles | Colombia | Alta |

## 4. Controles

### 4.1 Identidad y acceso

1. **MFA en todas las cuentas de administración**: Cloudflare, OVHcloud, Supabase, GitHub, Meta Business, Google Cloud, Twilio, ElevenLabs, OpenAI, Anthropic, Groq, OpenRouter, n8n, HubSpot, Resend, Bold y el correo de ialabs.app. Preferir llave física o aplicación de códigos; no usar SMS donde exista otra opción.
2. Cuentas personales, nunca compartidas. Un gestor de contraseñas para todas las credenciales.
3. Mínimo privilegio: cada contratista solo tiene acceso a lo que necesita y por el tiempo del encargo. Revisión de accesos cada 3 meses.
4. Retiro de accesos dentro de 1 día hábil cuando alguien termina su relación.
5. El VPS no expone puertos al público: se publica solo por Cloudflare Tunnels. Acceso SSH solo con llave, sin contraseña ni usuario root remoto. El panel de Dokploy y n8n quedan detrás de Cloudflare Access.

### 4.2 Secretos y llaves

1. Ningún secreto en el código ni en los repositorios. Los secretos viven en las variables de entorno de Dokploy y en los secretos de GitHub Actions.
2. GitHub con detección de secretos y bloqueo de envíos que los contengan.
3. **Tokens de Meta.** Un usuario del sistema con los permisos mínimos (whatsapp_business_management, whatsapp_business_messaging y los de Instagram o Messenger solo si el Cliente los conecta). Los tokens se guardan cifrados en la base (cifrado a nivel de aplicación, AES-256-GCM), con la llave fuera de la base de datos. Se revocan y borran dentro de 1 día hábil tras la desconexión.
4. **Tokens de Google.** Solo los permisos aprobados (openid, userinfo.email, userinfo.profile, calendar.events, gmail.send, drive.file). Tokens de actualización cifrados igual que los de Meta. Se revocan ante Google al desconectar.
5. Rotación de llaves y secretos cada 12 meses, y de inmediato ante un incidente o la salida de una persona con acceso.
6. La llave de cifrado de tokens no se guarda en Supabase ni en el repositorio. Hoy vive en el VPS como variable de entorno; no hay un servicio de gestión de llaves (KMS) — ver brecha B1.

### 4.3 Aislamiento entre Clientes

1. Cada tabla con datos de Clientes tiene la columna tenant_id y políticas de seguridad a nivel de fila (RLS) en Postgres.
2. La llave de servicio de Supabase solo se usa en el servidor, nunca en interfaces. Las interfaces hechas con Lovable usan la llave pública con RLS obligatoria.
3. Las búsquedas en índices vectoriales filtran siempre por tenant_id. Los objetos en R2 se guardan con el prefijo del Cliente.
4. Cada Cliente tiene credenciales propias en n8n; ningún flujo mezcla datos de dos Clientes.
5. **Pruebas automáticas de fuga** en GitHub Actions en cada despliegue: un usuario del Cliente A intenta leer datos del Cliente B por la API, por la base, por la búsqueda y por un Agente. Si una prueba falla, no se despliega — ver brecha B3.

### 4.4 Cifrado

1. En tránsito: TLS 1.2 o superior en todos los servicios, terminado en Cloudflare y en los proveedores.
2. En reposo: Supabase y R2 cifran por defecto con AES-256. Los tokens de Meta y Google tienen además cifrado de aplicación.
3. El disco del VPS no tiene cifrado propio confirmado — ver brecha B9. No guardar en el disco del VPS datos de Clientes fuera de los temporales de proceso.

### 4.5 Copias de respaldo y continuidad

1. Supabase hace copias diarias (plan Pro). Además, una copia lógica diaria cifrada se guarda en R2 con rotación de 35 días, la misma que prometen 05, 07 y 08.
2. La configuración del VPS (Dokploy, Traefik, variables sin valores) se guarda en un repositorio para reconstruir el servidor.
3. Objetivos: RPO 24 horas y RTO 8 horas (05, A.6). Prueba de restauración cada 3 meses, con acta.
4. Con un solo VPS, una falla del servidor detiene la Plataforma. El plan de continuidad es restaurar en otro VPS del mismo proveedor o en uno de los proveedores en reserva de la 09 (Contabo en Alemania; AWS o Google Cloud en Estados Unidos o la Unión Europea).

### 4.6 Registros y monitoreo

1. Registros técnicos: 12 meses. Registros de seguridad (accesos, cambios de permisos, inicios de sesión de administración, errores de autorización): hasta 24 meses.
2. Los registros no guardan el contenido de las conversaciones, salvo lo necesario para depurar un error y por el plazo de las conversaciones.
3. Monitor externo de disponibilidad con historial; las mediciones del SLA (05, A.2) salen de ahí.
4. Las alertas técnicas a Telegram no llevan datos personales ni contenido de conversaciones (09).

### 4.7 Proveedores

1. Solo se usan proveedores de la lista 09, con contrato de tratamiento de datos (DPA) y datos alojados en Colombia, Estados Unidos o la Unión Europea.
2. En cada proveedor de IA se activa la exclusión de entrenamiento y la retención mínima o cero disponible (OpenAI, Anthropic con inferencia en Estados Unidos, Groq, OpenRouter con lista cerrada de proveedores y sin respaldo automático, ElevenLabs).
3. Revisión anual de cada proveedor y antes de agregar uno nuevo. Aviso de 30 días a los Clientes (02, cláusula 4).
4. Dapta, mientras siga alojando agentes de clientes, es un proveedor que trata datos y debe quedar declarado — ver brecha B2.

### 4.8 Desarrollo seguro

1. Rama principal protegida; todo cambio pasa por una revisión con lista de chequeo (secretos, RLS, filtros por tenant_id, permisos de herramientas de los Agentes).
2. Escaneo de dependencias (Dependabot o equivalente) y actualizaciones de seguridad dentro de 15 días; las críticas, dentro de 3 días.
3. Nunca usar datos reales de Clientes en desarrollo o pruebas. El laboratorio local es solo de desarrollo.
4. Revisar el código generado con Lovable antes de publicarlo: sin llaves de servicio en el navegador y con RLS activa.

### 4.9 Seguridad de los Agentes de IA

1. Las instrucciones del sistema no contienen secretos ni datos de otros Clientes.
2. Cada herramienta de un Agente tiene el mínimo permiso: por ejemplo, crear citas solo en el calendario de su Cliente.
3. Los documentos de la base de conocimiento y los mensajes de los Contactos se tratan como contenido no confiable: no pueden cambiar las reglas del Agente.
4. Pruebas antes de activar y en cada cambio (10, sección 8): inyección de instrucciones, intento de leer datos de otro Contacto o de otro Cliente, revelación de instrucciones y promesas no autorizadas.
5. Los Agentes no piden números completos de tarjetas, cuentas financieras ni contraseñas.

### 4.10 Personas y equipos

1. Portátiles con cifrado de disco, bloqueo de pantalla y actualizaciones automáticas.
2. Capacitación corta una vez al año (phishing, manejo de datos, este protocolo), con registro de asistencia.
3. Ningún dato de Clientes en memorias USB, correos personales ni herramientas no aprobadas.

## 5. Protocolo de respuesta a incidentes (una página)

**Incidente:** cualquier acceso, uso, pérdida, alteración o divulgación no autorizada de datos personales, o la sospecha razonable de que ocurrió. Ejemplos: token filtrado, fuga entre Clientes, Agente que revela datos de otro Contacto, cuenta de administración comprometida, pérdida de un portátil.

| Paso | Qué hacer | Plazo |
|---|---|---|
| 1. Detectar y registrar | Abrir el registro del incidente en la bitácora: hora de detección, quién lo detectó, qué se vio | Inmediato (hora 0) |
| 2. Contener | Revocar o rotar tokens y llaves; pausar Agentes o flujos afectados; cerrar accesos; bloquear la cuenta comprometida. Preservar evidencia (registros, capturas) antes de borrar nada | Primeras horas |
| 3. Evaluar | Qué datos, de qué Clientes, cuántos titulares y registros, si hay datos sensibles o de menores, consecuencias probables | Dentro de 24 horas |
| 4. Avisar a los Clientes afectados (somos Encargado) | Naturaleza del incidente, categorías y número aproximado de titulares y registros, consecuencias probables, medidas adoptadas y contacto (02, cláusula 6) | **Dentro de 48 horas desde la confirmación** |
| 5. Reportar a la SIC (somos Responsable: cuentas, usuarios B2C, prospectos) | Reporte en el Registro Nacional de Bases de Datos (art. 17, literal n, de la Ley 1581 de 2012; Circular Única de la SIC, Título V [VERIFICAR numeral]). Si somos Encargado, avisamos al Cliente en 48 horas y también informamos a la SIC (art. 18, literal k), en coordinación con él | **Dentro de 15 días hábiles desde la detección** |
| 6. Avisar a Meta o a Google | Si el incidente afecta Datos de Plataforma de Meta o Datos de Usuario de Google, avisar según sus términos (Términos de la Plataforma de Meta y Política de Datos de Usuario de los Servicios de API de Google) [VERIFICAR plazos vigentes] | Sin demora |
| 7. Avisar a los titulares | Cuando exista un riesgo para ellos, en lenguaje claro y con qué pueden hacer | Tan pronto como sea posible |
| 8. Unión Europea | Si hay Contactos en la UE, apoyar al Cliente para su aviso a la autoridad en 72 horas (art. 33 del Reglamento (UE) 2016/679) | Dentro de 72 horas |
| 9. Cerrar | Informe de causa, impacto, medidas y lecciones; cambios a controles; actualizar esta Política si aplica | Dentro de 10 días hábiles del cierre |

**Contactos de emergencia:** Mateo Piza Ruiz, +57 300 332 9814 · soporte@ialabs.app · privacidad@ialabs.app. Soporte de Supabase, Cloudflare, OVHcloud, Twilio y ElevenLabs desde sus paneles.

**Bitácora:** fecha y hora, descripción, sistemas, datos y Clientes afectados, acciones con hora, avisos enviados (a quién, cuándo, por qué canal) y cierre. Se conserva 24 meses como registro de seguridad.

## 6. Brechas ordenadas por riesgo

| # | Brecha | Dónde se promete | Riesgo | Acción | Prioridad |
|---|---|---|---|---|---|
| B1 | No hay servicio de gestión de llaves (KMS) con rotación; la llave de cifrado vive como variable de entorno | 02, Anexo B («Gestión de llaves en un servicio de KMS con rotación») | Incumplimiento contractual; robo de la llave junto con el VPS | Adoptar un gestor de secretos con rotación o cambiar el texto de 02 a «gestión segura de llaves, separadas de los datos, con rotación» | Alta |
| B2 | Dapta aloja agentes de clientes y no está declarado | 09 y 02, Anexo C (lista de Subencargados) | Subencargado no declarado; ubicación de datos sin confirmar | Declararlo con su ubicación o terminar la migración antes de firmar con nuevos clientes | Alta |
| B3 | Pruebas automáticas de aislamiento entre Clientes sin confirmar | 02, Anexo B («pruebas periódicas de aislamiento») | La fuga entre Clientes es el peor escenario del servicio | Crear las pruebas de 4.3.5 en GitHub Actions y auditar las políticas RLS de todas las tablas | Alta |
| B4 | Respuesta de severidad 1 en 1 hora, 24x7, con una sola persona | 05, A.5 | Incumplimiento contractual casi seguro en un fin de semana o festivo | Cambiar en 05 a 2 horas, de 7:00 a. m. a 10:00 p. m., todos los días, o contratar guardia | Alta |
| B5 | Exclusión de entrenamiento de ElevenLabs sin confirmar por escrito | 10, sección 7; 08, sección 12 | Promesa pública falsa de no entrenamiento; voz es dato sensible cuando se clona | Obtener la exclusión por escrito o plan con retención cero antes de publicar 10 | Alta |
| B6 | MFA en todas las cuentas sin verificar | 08, sección 15; 02, Anexo B | Toma de cuentas de Meta, Google o Supabase | Revisar cuenta por cuenta (sección 4.1.1) y dejar acta | Alta |
| B7 | Registros de auditoría «inmutables» no implementados | 02, Anexo B | Incumplimiento contractual; sin evidencia confiable tras un incidente | Enviar registros de seguridad a un bucket de R2 con bloqueo de objetos, o cambiar el texto a «protegidos contra modificación» | Media |
| B8 | Sin prueba de penetración anual | 02, Anexo B | Incumplimiento contractual | Presupuestar una prueba externa anual o cambiar el texto a «evaluación de seguridad anual» | Media |
| B9 | Disco del VPS sin cifrado confirmado | 08, sección 15 («cifrado en reposo») | Exposición si se compromete el proveedor o la imagen del servidor | Mantener los datos solo en Supabase y R2; cifrar volúmenes con datos temporales | Media |
| B10 | Registro de versiones por Agente (modelo, instrucciones y base de conocimiento) y de eventos por conversación | 10, sección 9.1 | Promesa pública sin respaldo técnico | Construirlo o ajustar 10 antes de publicarla | Media |
| B11 | Redacción automática de datos sensibles antes de enviarlos al modelo | 02, Anexo B («cuando se configure») | Envío de datos de tarjeta o documentos a proveedores de IA | Mantener «cuando se configure» y no ofrecerla hasta que exista | Media |
| B12 | Copia lógica propia con rotación de 35 días sin confirmar | 05, A.6; 07; 08 | Pérdida de datos más allá del RPO | Programar la copia diaria a R2 y probar una restauración | Media |
| B13 | Un solo VPS (punto único de falla) | 05, A.2 (99,0 %) y A.6 (RTO 8 h) | Una caída larga consume el margen del SLA | Documentar la restauración en otro servidor y probarla | Media |
| B14 | Capacitación anual sin registro | 02, Anexo B | Incumplimiento menor | Sesión anual de una hora con acta | Baja |

**Nota (22 oct. 2026):** después de la auditoría (22), el Anexo B del DPA (02) ya no promete KMS, pruebas periódicas de aislamiento, registros inmutables, prueba de penetración ni redacción automática de datos. B1, B3, B7, B8 y B11 siguen como mejoras de seguridad, pero ya no son incumplimientos contractuales. B4 se resolvió cambiando la severidad 1 del SLA (05) a 2 horas, de 7:00 a. m. a 10:00 p. m.

## 7. Evaluación CASA Tier 2 (solo si se usa un permiso restringido de Google)

Con los permisos actuales (calendar.events, gmail.send y drive.file con el selector de Google) no hay permisos restringidos y Google no exige CASA. Si algún día se pide leer Gmail o todo Drive, Google exigirá una evaluación CASA Tier 2 antes de aprobar y cada 12 meses. Tier 2 la hace la propia empresa con herramientas de escaneo y la valida un laboratorio autorizado [VERIFICAR modalidad vigente]. Revisa, con base en OWASP ASVS:

| Dominio | Qué revisa | Estado hoy |
|---|---|---|
| Autenticación | MFA, contraseñas, recuperación de cuenta | Ver B6 |
| Control de acceso | Autorización en cada solicitud; aislamiento entre clientes | Ver B3 |
| Manejo de sesiones | Expiración, cookies seguras | Por revisar |
| Validación de entradas | Inyección SQL, XSS, SSRF | Por revisar |
| Criptografía | TLS, cifrado de tokens en reposo, gestión de llaves | Ver B1 |
| Protección de datos | Datos sensibles en reposo y en registros | Ver B9 y 4.6.2 |
| Errores y registros | Registros de seguridad sin datos sensibles | Parcial |
| Configuración | Cabeceras de seguridad, dependencias vulnerables, secretos | Ver 4.2 y 4.8 |
| API y servicios web | Autenticación de API, límites de uso | Por revisar |
| Lógica de negocio y archivos | Abusos de flujo, carga de archivos | Por revisar |

## 8. Revisión

Esta Política se revisa una vez al año, después de cada incidente y cuando cambie la infraestructura o un proveedor. La aprueba Mateo Piza Ruiz.

## Anexo interno — no publicar

### Pendientes antes de usar

- [ ] Cerrar las brechas de prioridad alta (B1 a B6) o ajustar el texto de 02, 05, 08 y 10 antes de firmar con el próximo cliente o publicar.
- [ ] Verificar el numeral exacto de la Circular Única de la SIC para el reporte de incidentes en el RNBD y los plazos de aviso a Meta y Google.
- [ ] Confirmar la entidad y el centro de datos de OVHcloud, la región y la entidad de Supabase, y la ubicación de los datos en Dapta.
- [ ] Crear la bitácora de incidentes (hoja con las columnas de la sección 5) y la lista de chequeo de revisión de código (4.8.1).
- [ ] Hacer y documentar la primera prueba de restauración (4.5.3).
- [ ] Revisión del abogado.