```html

SaaS y startups tech: cómo cumplir la Ley 21.719 desde el día uno

Si acabas de fundar una startup tech o SaaS, probablemente estés enfocado en product-market fit, usuarios y tracción. Pero hay un detalle crítico que no puedes ignorar: tu empresa casi seguro es un encargado del tratamiento de datos personales según la Ley 21.719. Esto significa que tus clientes B2B son responsables legales de los datos que fluyen por tu plataforma, y tú tienes obligaciones concretas sobre cómo los tratas, almacenas y proteges. Hacerlo bien desde el inicio te ahorra conflictos, auditorías y problemas con tus clientes grandes. Acá te mostramos cómo.

¿Responsable o encargado? La diferencia que define tus obligaciones

La Ley 21.719 define dos roles clave: el responsable (quien decide para qué se usan los datos) y el encargado (quien procesa datos según instrucciones del responsable). En un modelo SaaS típico, tu cliente es el responsable — por ejemplo, una empresa de retail que usa tu plataforma para gestionar clientes — y tú eres el encargado. Esto no es menor: significa que no puedes usar esos datos para fines propios sin autorización explícita.

¿Ejemplo real? Si tu SaaS de email marketing almacena las listas de contactos de tus clientes, esos datos les pertenecen legalmente a ellos. Tú solo puedes procesarlos para enviar correos, generar reportes y nada más. Si quisieras usar esos datos para entrenar un modelo de IA o venderlos, violarías la ley y perderías clientes al instante.

El DPA: tu documento más importante para clientes B2B

Un Data Processing Agreement (DPA) es un contrato que formaliza la relación entre responsable (tu cliente) y encargado (tú). La Ley 21.719, en su artículo 25, lo exige cuando hay tratamiento de datos por cuenta de terceros. Sin DPA, no tienes legitimidad legal para procesar datos de tus clientes.

¿Qué debe incluir tu DPA?

Descripción clara de qué datos procesas (contactos, transacciones, comportamiento, etc.)
Para qué fines específicos (envío de emails, análisis, reportes)
Dónde se almacenan los datos (servidores, regiones, país)
Cómo proteges la seguridad (encriptación, firewalls, acceso limitado)
Derechos del cliente para auditar, acceder, eliminar datos
Qué pasa si hay un incidente de seguridad
Duración y qué ocurre con los datos al terminar el contrato

Esto no es para abogados únicamente. Tus clientes grandes (especialmente si son B2B2C) lo van a pedir antes de firmar. Tenerlo listo desde día uno es competitivo: muestra que eres profesional y que tomas en serio la privacidad.

Términos de servicio y privacidad: hazlos compatibles

Muchas startups tienen términos de servicio genéricos que choquean con sus políticas de privacidad. Eso confunde a los clientes y genera riesgos legales. Tu ToS y tu política de privacidad deben contar la misma historia.

Concretamente: si tu ToS dice que los datos son propiedad tuya, pero tu política de privacidad dice que el cliente es dueño, tienes un problema. Asegúrate de ser claro desde el inicio: los datos de usuarios finales pertenecen al cliente (responsable), no a ti. Los datos de tu cliente como empresa (empresa, contacto, plan contratado) sí pueden ser tuyos para operación y seguridad.

Subcontratación y encargados en cadena: AWS, GCP, Stripe y cía.

Aquí viene lo complejo: si usas AWS para almacenar datos, GCP para analytics o Stripe para pagos, ellos también son encargados (aunque de segundo nivel). La Ley 21.719 exige que documentes explícitamente esto y que tus clientes lo aprueben.

¿Cómo? Incluye en tu DPA una lista de "subencargados autorizados" con sus países de operación. Algo como:

Amazon Web Services (AWS): Almacenamiento en us-east-1 (Virginia, EE.UU.)
Google Cloud Platform (GCP): Analytics en europe-west1 (Bélgica)
Stripe: Procesamiento de pagos, servidores en múltiples regiones

Permite que tus clientes objetivamente antes de usar estos servicios. Es lo que hace Slack, Notion y cualquier SaaS serio.

Logs de acceso y auditoría: infraestructura básica

La Ley 21.719 requiere que puedas demostrar quién accedió a qué datos, cuándo y por qué. Esto significa: logs. Implementa desde día uno.

Mínimo obligatorio:

Registra cada acceso a datos personales (quién, cuándo, qué datos, acción realizada)
Almacena logs por al menos 1 año (mejor 2 años)
Permite que tus clientes y auditores accedan a estos logs
Detecta accesos inusuales (login desde IP sospechosa, descarga masiva, etc.)

No necesitas un sistema ultra-complejo. Herramientas como Datadog, New Relic o incluso CloudTrail de AWS registran esto automáticamente. Tu equipo de desarrollo debe revisarlos regularmente.

Privacy by design: construye seguridad desde el código

Privacy by design no es un documento, es una filosofía: la privacidad debe estar en el ADN de tu producto desde el primer commit. Significa:

Encriptación: Todo dato en tránsito (HTTPS) y en reposo (AES-256 o superior)
Acceso mínimo: Cada empleado accede solo a los datos que necesita. Tu soporte no ve el email del usuario final; tu DevOps no ve datos sensibles
Retención limitada: Elimina automáticamente datos antiguos según políticas (ej: después de 12 meses de inactividad)
Seudoanonimización: Si usas datos para analytics o tests, hazlo anónimo
Desactivación de usuarios: Cuando un cliente cancela, todos sus datos se eliminan en 30 días (configurable)

Esto no es overhead: es buena arquitectura. Y tu