Unha empresa de software como servizo —un CRM, un ERP, unha plataforma de email marketing, unha ferramenta de xestión de proxectos, un software de RRHH, un product analytics— procesa cada día datos persoais que non son seus, senón das empresas que a usan. Esa posición particular, ser peza crítica na operativa de centos ou miles de empresas-cliente, converte á SaaS nun dos actores con maior exposición ao RGPD do ecosistema dixital. E, ao mesmo tempo, nun onde mellor se pode converter o cumprimento normativo en vantaxe comercial.
Esta guía explica como regula unha empresa SaaS o seu rol baixo o RGPD (Regulamento UE 2016/679) e a LOPDGDD (Lei Orgánica española 3/2018): cando é encargada do tratamento, que documento debe ofrecer aos seus clientes empresariais (DPA), como xestiona os subencargados, onde está a fronteira entre encargado e responsable independente e que coidar ao adestrar modelos ou ao integrar intelixencia artificial.
O reparto de roles típico en SaaS
Cando un cliente empresarial contrata unha SaaS, conviven polo menos dous planos de tratamento de datos persoais con roles diferentes:
- Datos que o cliente sobe á plataforma (clientes finais no CRM, empregados no software de RRHH, subscritores na plataforma de email): o cliente é responsable deses tratamentos; a SaaS é encargada que executa o que aquel lle indica. Aquí aplícase o réxime do art. 28 RGPD.
- Datos do propio cliente como usuario da SaaS (conta do administrador, datos de facturación, log de acceso, contacto comercial): a SaaS é responsable deses tratamentos. Aquí aplícase o réxime do art. 6 RGPD, con base habitualmente na execución do contrato.
En empresas SaaS ben estruturadas, esta dualidade aparece reflectida con claridade en dous documentos distintos: a política de privacidade do sitio web público (que cobre a captación comercial, o uso do produto e a facturación, onde a SaaS é responsable) e o DPA (Data Processing Agreement) que o cliente empresarial asina ou acepta ao contratar (que cobre o réxime do art. 28 RGPD para os datos que o cliente subirá).
O DPA: o documento que toda SaaS profesional ofrece aos seus clientes
O art. 28.3 RGPD obriga ao responsable e ao encargado a regular a súa relación mediante un contrato ou outro acto xurídico vinculante cun contido mínimo concreto. No mundo SaaS, ese instrumento chámase universalmente Data Processing Agreement (DPA) ou Acordo de Tratamento de Datos e adoita ofrecerse como anexo de adhesión aos termos do servizo.
Unha SaaS profesional pon o DPA á disposición do cliente sen que este teña que pedilo, idealmente accesible desde o panel de administración, descargable como PDF asinado ou aceptable mediante un check de consentimento que deixa constancia. O DPA debe cubrir:
| Cláusula | Que debe dicir nun SaaS |
|---|---|
| Obxecto e duración | Prestación do servizo descrito nos termos de contratación durante a vixencia da subscrición do cliente. |
| Natureza e finalidade | Almacenar, procesar, analizar e mostrar os datos que o cliente sobe segundo as funcionalidades do produto, sen usalos para finalidades propias distintas no seu rol de encargado. |
| Tipos de datos e interesados | Identificativos, contacto, datos comerciais e, no seu caso, categorías especiais se o produto o permite. Interesados: clientes finais, empregados, provedores do cliente. |
| Persoal da SaaS | Confidencialidade por contrato, control de altas e baixas, principio do mínimo privilexio en accesos a datos de cliente. |
| Medidas de seguridade | Cifrado en tránsito e en repouso, control de accesos con dobre factor, segregación lóxica entre tenants, rexistro de actividade, copias de seguridade, xestión de vulnerabilidades, certificacións (ISO 27001, SOC 2) se aplican. |
| Subencargados | Lista accesible e actualizada (hosting, CDN, monitorización, soporte externo se o hai), autorización xeral no DPA e mecanismo de notificación de cambios. |
| Transferencias internacionais | Identificación de países fóra do EEE, base da transferencia (decisión de adecuación, Data Privacy Framework para EE.UU., cláusulas contractuais tipo) e análise de impacto cando proceda. |
| Asistencia para dereitos | Ferramentas no produto para que o cliente atenda dereitos do interesado (exportación, supresión, rectificación) e procedemento de soporte cando se require intervención técnica. |
| Notificación de violacións | Prazo concreto para notificar ao cliente calquera violación que afecte aos seus datos (tipicamente 24-48 horas), información mínima e procedemento de colaboración. |
| Devolución e supresión | Ao finalizar a subscrición, o cliente pode exportar os datos en formato estruturado (CSV, JSON, API). Prazo de retención posterior, normalmente 30-90 días, e supresión segura confirmada. |
Subencargados: a cadea que toda SaaS debe documentar
Case ningunha SaaS opera soa: detrás adoita haber un provedor cloud (AWS, Google Cloud, Azure), unha CDN (Cloudflare, Fastly), un servizo de monitorización (Sentry, Datadog), unha pasarela de pagamento (Stripe), unha ferramenta de soporte (Intercom, Zendesk), un provedor de correo transaccional (SendGrid, Postmark) e, cada vez máis, modelos de IA externos.
Cada un destes provedores procesa datos dos clientes da SaaS e é, polo tanto, subencargado no sentido do art. 28.2 RGPD. A SaaS debe:
- Manter unha lista pública e actualizada de todos os subencargados que utiliza, accesible desde o sitio web (tipicamente nunha páxina titulada "Subprocessors" ou "Subencargados").
- Asinar con cada subencargado un contrato do art. 28 RGPD con garantías equivalentes ás do DPA principal.
- Notificar aos clientes con antelación razoable (entre 14 e 30 días adoita ser estándar) calquera cambio significativo: incorporación dun novo subencargado, substitución dun existente, ampliación do alcance do tratamento.
- Permitir ao cliente opoñerse ao cambio nese prazo. Se a oposición é xustificada e bloquea a continuidade do servizo, o cliente debe ter dereito a rescindir a súa subscrición.
Encargado vs. responsable independente: a fronteira que máis custa debuxar
O erro máis sutil do SaaS en protección de datos é asumir que toda a operativa sobre os datos do cliente se rexe polo réxime de encargado. En realidade, hai tres zonas onde a SaaS frecuentemente actúa como responsable independente e onde o réxime aplicable cambia por completo:
- Analítica agregada do produto: se a SaaS cruza datos de uso de todos os seus clientes para mellorar o produto, xerar benchmarks sectoriais ou adestrar modelos de recomendación, esa finalidade é propia da SaaS, non do cliente. A SaaS convértese en responsable e necesita base xurídica autónoma (tipicamente interese lexítimo do art. 6.1.f RGPD, con ponderación documentada), informar aos interesados finais por vía contractual cos seus clientes-empresa ou anonimizar os datos antes do cruce.
- Adestramento de modelos de IA: usar os datos dos clientes para adestrar modelos xerais que servirán a todos os clientes futuros é claramente unha finalidade propia da SaaS. Sen consentimento explícito do cliente ou sen anonimización irreversible, ese tratamento non está cuberto polo rol de encargado.
- Marketing comercial aos usuarios do produto: se a SaaS envía newsletters, ofertas de upsell ou comunicacións de produto a usuarios individuais que pertencen a empresas-cliente, está a actuar como responsable sobre os datos deses usuarios concretos, non como encargada sobre os datos das súas empresas.
A forma profesional de xestionar esta zona é:
- Mapear con claridade que tratamentos son de encargado e cales de responsable independente.
- Regular cada un coa súa propia base xurídica e documentación.
- Mencionar explicitamente no DPA que tratamentos quedan fóra do rol de encargado e cales requiren consentimento adicional ou anonimización previa.
- Ofrecer ao cliente mecanismos para autorizar ou bloquear os tratamentos opcionais (opt-in / opt-out claramente diferenciado).
"En SaaS, o cumprimento do art. 28 RGPD non é papelorio: é produto. Un DPA accesible, unha lista de subencargados pública e unha segregación clara de tenants son tres sinais que os clientes empresariais miran antes de asinar. Cumprir ben acelera vendas; cumprir mal bloquéaas."
Mario P. Talamillo · Socio director, Certix®
Multi-tenant e segregación: a medida de seguridade estrutural
Unha SaaS atende a múltiples clientes (tenants) nunha mesma infraestrutura. A forma en que a arquitectura segrega os datos entre tenants é unha medida de seguridade estrutural do art. 32 RGPD e, en consecuencia, un punto que o DPA debe describir con honestidade técnica:
- Multi-tenant lóxico con segregación a nivel de aplicación (cada rexistro leva un identificador de tenant e o filtrado está aplicado en todas as consultas). É o modelo máis estendido. Require extremo coidado nos tests para que ningún bug permita leakage entre tenants.
- Multi-tenant físico con base de datos separada por cliente. Maior custo operativo pero mellor segregación. Habitual en SaaS de gama alta ou sectores moi regulados.
- Single-tenant illado con instancia dedicada por cliente. O extremo oposto, reservado a clientes moi grandes ou regulados.
O cliente empresarial maduro pregunta por este punto antes de asinar. Unha SaaS profesional documéntao no DPA e na súa documentación de seguridade pública.
Violacións: a SaaS é a canle natural de notificación
Cando ocorre unha violación de seguridade na SaaS, o réxime do art. 33 RGPD obriga ao cliente (responsable) a notificar á AEPD (Axencia Española de Protección de Datos) en menos de 72 horas. Para que isto sexa tecnicamente posible, a SaaS (encargada) debe avisar ao cliente coa maior rapidez. O DPA debe regulalo:
- Prazo de notificación ao cliente: tipicamente 24-48 horas desde que a SaaS toma coñecemento.
- Información mínima da primeira comunicación: natureza do incidente, sistemas e categorías de datos afectados, alcance estimado, medidas inmediatas adoptadas.
- Colaboración técnica: a SaaS facilita ao cliente o que necesita para preparar a notificación á AEPD e, no seu caso, a comunicación aos afectados.
- Comunicación posterior: análise de causa raíz, plan de mellora, leccións aprendidas.
Checklist mínimo dunha SaaS responsable
- DPA estándar publicado, accesible e asinable, aliñado co contido do art. 28.3 RGPD.
- Lista pública de subencargados con identificación, función, país e URL do DPA propio de cada un.
- Mecanismo de notificación de cambios de subencargados a clientes con prazo razoable de oposición.
- Mapeo claro entre tratamentos de encargado e de responsable independente, con bases xurídicas distintas.
- Política de uso de IA e adestramento: que datos se usan para mellorar o modelo e baixo que autorización do cliente.
- Documentación pública de seguridade: cifrado, segregación de tenants, certificacións, recovery point objective.
- Procedemento de notificación de violacións a clientes con prazo expreso.
- Funcionalidades no produto para exportación, supresión e rectificación que faciliten ao cliente atender dereitos do interesado.
- Páxina pública de privacidade para usuarios do produto (web público, proba gratuíta) que separe claramente do DPA empresarial.
Preguntas frecuentes
Unha empresa SaaS é responsable ou encargada do tratamento sobre os datos que procesan os seus clientes?
A regra xeral é encargada (art. 28 RGPD) sobre os datos que o cliente sobe á plataforma. Pero a SaaS tamén actúa como responsable independente noutras capas: conta do administrador, facturación, análise de uso agregado, mellora do propio servizo. A dualidade debe regularse claramente nos termos de servizo e, sobre todo, no DPA do art. 28 RGPD que a SaaS asina con cada cliente.
Que debe ofrecer unha SaaS aos seus clientes para cumprir o art. 28 RGPD?
Un Data Processing Agreement (DPA) que conteña o contido mínimo do art. 28.3 RGPD: obxecto, duración, natureza e finalidade, tipos de datos, obrigas, confidencialidade, medidas de seguridade, subencargados, asistencia para dereitos, notificación de violacións e devolución de datos. Adoita ofrecerse como anexo de adhesión aos termos do servizo ou asinado expresamente.
Cando deixa unha SaaS de ser encargada e convértese en responsable independente?
Cando decide por si mesma finalidades novas que o cliente non lle indicou: cruzamento de datos entre clientes para analítica propia, adestramento de modelos de IA xerais, reutilización para mellorar o produto comercial máis aló da prestación contratada ou marketing a usuarios individuais. Neses casos cómpre base xurídica autónoma, informar aos interesados e cumprir todos os demais deberes do responsable.
Ten unha SaaS que ofrecer aos seus clientes garantías sobre os subencargados que utiliza?
Si (art. 28.2 RGPD). A SaaS debe manter unha lista accesible e actualizada de subencargados (AWS, Google Cloud, Cloudflare, Stripe, etc.), asinar con cada un un contrato do art. 28 RGPD con garantías equivalentes, notificar ao cliente os cambios significativos con antelación razoable e permitirlle opoñerse ao cambio. As grandes plataformas cloud ofrecen os seus propios DPA estándar que deben revisarse.
Este contido é meramente orientativo e divulgativo; non constitúe en ningún caso asesoramento xurídico especializado. A aplicación da normativa a cada caso concreto require análise individualizada. A normativa autonómica sectorial pode ampliar ou modificar prazos e requisitos.
O teu SaaS ten un DPA sólido que aguante o due diligence de clientes empresariais?
En Certix asignámosche un experto en cumprimento do sector tecnolóxico. Sen intermediarios comerciais, sen modelos xenéricos.
Falar cun experto