Guía de manejo de datos.

1. Cómo fluye una llamada por nuestro sistema

Cuando alguien llama a una empresa que usa nuestro recepcionista IA, este es el recorrido que siguen el audio y los datos. Nada se persiste en nuestro servidor más allá del estado de llamada en vivo; el almacenamiento permanente ocurre en el paso de Airtable.

• Twilio recibe la llamada, la enruta vía puntos de presencia canadienses y transmite el audio por una conexión WebSocket cifrada a nuestro servidor.
• Agente de voz se ejecuta en nuestro VPS canadiense. Transcribe el habla del llamante, envía la transcripción a la IA para procesamiento y reproduce la respuesta de la IA vía Twilio.
• Claude AI (Anthropic) procesa la conversación en tiempo real. La API de Anthropic aplica una política de cero retención — las entradas no se almacenan ni se usan para entrenar el modelo.
• Airtable almacena el registro de la llamada, el resumen de la transcripción y los detalles de la cita después de que termina la llamada — el primer punto donde algo se persiste.

2. Cifrado y seguridad

En tránsito

• Todo el tráfico HTTP usa TLS 1.2+ (TLS 1.3 preferido). Aplicado a nivel de nginx con HSTS y un conjunto de cifrado moderno.
• Los flujos de audio de Twilio usan conexiones WebSocket cifradas.
• Las llamadas API a Anthropic, Airtable y Stripe usan HTTPS cifrado con TLS.

En reposo

• Airtable cifra todos los datos almacenados con AES-256.
• Nuestro archivo de secretos (/opt/secrets/secrets.enc.yaml) está cifrado con SOPS + age. El texto plano nunca toca el disco — el archivo se descifra en memoria al iniciar el servicio.
• Los permisos de archivos están bloqueados (chmod 600). Los secretos nunca se escriben en registros, nunca se pasan por línea de comandos, nunca se comprometen al código.
• Redis (caché en memoria) almacena el estado temporal de llamada con expiración automática — nada persiste en disco.
• La base de datos PostgreSQL que aloja los datos de workflow usa credenciales por base de datos, rotadas vía el mismo almacén SOPS.

Hosting canadiense

• La infraestructura principal del servidor está alojada en Canadá (proveedor VPS: Hostinger, región canadiense).
• Twilio está configurado para enrutar llamadas vía puntos de presencia canadienses cuando está disponible.

3. Cronograma de retención de datos

La retención se aplica mediante scripts automatizados semanales. No son aspiracionales — se ejecutan en producción y pueden auditarse con --dry-run.

4. Ciclo de vida automatizado de datos

Trabajos concretos que aplican el cronograma de retención anterior:

• Purga semanal de transcripciones (data_retention.py, domingo 03:30 UTC) — transcripciones de más de 90 días eliminadas permanentemente. Los resúmenes generados por IA (sin identificadores directos) se conservan.
• Anonimización semanal de llamantes — los registros de llamadas de más de 12 meses tienen su número de teléfono reemplazado por ANONYMIZED. Las estadísticas agregadas permanecen.
• Limpieza semanal de grabaciones — los Twilio recording SIDs de más de 90 días se eliminan vía la API de Twilio Recordings, luego se borra la referencia de nuestro lado.
• Purga semanal de ejecuciones — los datos de ejecución n8n de más de 90 días se eliminan.
• Pruebas de regresión nocturnas — un cron separado ejecuta pruebas de extremo a extremo que verifican que los trabajos de retención y el pipeline de eliminación siguen funcionando; las alertas van al operador en cualquier fallo.

Todos los trabajos de retención soportan el modo --dry-run — puede ver exactamente qué filas se verían afectadas sin ejecutar.

5. Derecho al olvido — mecánica de eliminación

Cuándo se activa la eliminación

La eliminación completa de datos (según el cronograma anterior — 90 días para transcripciones/grabaciones, 12 meses para metadatos) se activa automáticamente cuando el servicio de un cliente comercial se deshabilita por cualquiera de:

• El cliente cancela su suscripción a través del portal de facturación de Stripe
• Se emite un reembolso completo — el servicio se deshabilita segundos después del evento de reembolso de Stripe; el reloj de retención comienza en la marca de tiempo de deshabilitación
• Se presenta un contracargo (disputa bancaria) — mismo comportamiento que un reembolso completo
• Una prueba expira sin conversión a un plan pagado
• Se cancela la cuenta de un socio agencia, huérfanizando sus cuentas de clientes (período de gracia de 30 días antes de deshabilitar)

Los reembolsos parciales (créditos de buena fe) no deshabilitan el servicio ni activan el cronograma de eliminación.

Qué se elimina (offboarding de cliente comercial)

• Todos los registros de llamadas de voz asociados con la empresa
• Todas las grabaciones de Twilio (archivos de audio)
• Todas las citas, registros de personal, horarios comerciales, feriados y listas de servicios
• Todos los datos en caché en Redis
• El registro del cliente en sí

Rastro de auditoría

Cada acción de eliminación se registra: marca de tiempo, conteos de registros, identidad del operador. El registro de auditoría se mantiene separado de los datos eliminados, por lo que los eventos de eliminación permanecen verificables.

Solicitudes individuales de llamantes

Si un llamante individual (no un cliente comercial) solicita la eliminación de sus datos, envíe una solicitud a través de nuestro formulario de solicitud de privacidad (en inglés). Verificamos la solicitud por correo electrónico, luego localizamos y eliminamos todos los registros asociados con su número de teléfono dentro de 30 días.

6. Subprocesadores

Servicios de terceros que procesan datos como parte de la entrega del servicio. Datos que ven y su propia postura de cumplimiento:

Auto-alojado (no es un subprocesador): Redis se ejecuta en nuestro propio VPS canadiense como caché en memoria para el estado temporal de llamada. Los datos expiran automáticamente; nada persiste en disco.

7. Aislamiento por inquilino

• A cada empresa se le asigna un ID de inquilino único.
• Cada consulta a Airtable, clave de Redis y ejecución de workflow está delimitada por ID de inquilino. El acceso entre inquilinos no es una ruta de código que exista.
• Los tokens API están limitados a los permisos mínimos requeridos. Las credenciales nunca se comparten entre inquilinos.
• El acceso al portal se autentica por inquilino con tokens JWT que llevan el claim de inquilino.
• Las claves de caché de Redis tienen espacio de nombres por ID de inquilino con expiración automática.

8. Controles de acceso

• Tokens API — limitados a los permisos mínimos requeridos; rotados vía el almacén SOPS.
• Permisos de archivos — secretos almacenados con chmod 600 (acceso solo del propietario).
• Sin credenciales compartidas — cada servicio usa su propia autenticación.
• Autenticación de portal — contraseñas con hash bcrypt, JWT con expiración corta.
• Aislamiento de entorno — secretos cargados desde archivos de entorno con permisos restringidos al iniciar el servicio, nunca comprometidos al código.

9. Copias de seguridad

Las copias de seguridad automatizadas protegen contra la pérdida de datos. Almacenadas localmente en nuestra infraestructura canadiense — sin transferencia transfronteriza.