Una empresa de programari com a servei —un CRM, un ERP, una plataforma d'email màrqueting, una eina de gestió de projectes, un programari de RH, un product analytics— processa cada dia dades personals que no són seves, sinó de les empreses que la fan servir. Aquesta posició particular, ser peça crítica en l'operativa de centenars o milers d'empreses-client, converteix la SaaS en un dels actors amb major exposició al RGPD de l'ecosistema digital. I, alhora, en un on millor es pot convertir el compliment normatiu en avantatge comercial.
Aquesta guia explica com regula una empresa SaaS el seu rol sota el RGPD (Reglament UE 2016/679) i la LOPDGDD (Llei Orgànica 3/2018): quan és encarregada del tractament, quin document ha d'oferir als seus clients empresarials (DPA), com gestiona els subencarregats, on és la frontera entre encarregat i responsable independent i què tenir cura en entrenar models o integrar intel·ligència artificial.
El repartiment de rols típic en SaaS
Quan un client empresarial contracta una SaaS, conviuen com a mínim dos plans de tractament de dades personals amb rols diferents:
- Dades que el client puja a la plataforma (clients finals al CRM, empleats al programari de RH, subscriptors a la plataforma d'email): el client és responsable d'aquests tractaments; la SaaS és encarregada que executa el que aquell li indica. Aquí s'aplica el règim de l'art. 28 RGPD.
- Dades del propi client com a usuari de la SaaS (compte de l'administrador, dades de facturació, registre d'accés, contacte comercial): la SaaS és responsable d'aquests tractaments. Aquí s'aplica el règim de l'art. 6 RGPD, amb base habitualment en l'execució del contracte.
En empresses SaaS ben estructurades, aquesta dualitat apareix reflectida amb claredat en dos documents diferents: la política de privacitat del lloc web públic (que cobreix la captació comercial, l'ús del producte i la facturació, on la SaaS és responsable) i el DPA (Data Processing Agreement) que el client empresarial signa o accepta en contractar (que cobreix el règim de l'art. 28 RGPD per a les dades que el client pujarà).
El DPA: el document que tota SaaS professional ofereix als seus clients
L'art. 28.3 RGPD obliga el responsable i l'encarregat a regular la seva relació mitjançant un contracte o un altre acte jurídic vinculant amb un contingut mínim concret. En el món SaaS, aquest instrument s'anomena universalment Data Processing Agreement (DPA) o Acord de Tractament de Dades i sol oferir-se com a annex d'adhesió als termes del servei.
Una SaaS professional posa el DPA a disposició del client sense que aquest l'hagi de demanar, idealment accessible des del panell d'administració, descarregable com a PDF signat o acceptable mitjançant una casella de consentiment que deixa constància. El DPA ha de cobrir:
| Clàusula | Què ha de dir en un SaaS |
|---|---|
| Objecte i durada | Prestació del servei descrit en els termes de contractació durant la vigència de la subscripció del client. |
| Naturalesa i finalitat | Emmagatzemar, processar, analitzar i mostrar les dades que el client puja segons les funcionalitats del producte, sense fer-les servir per a finalitats pròpies diferents en el seu rol d'encarregat. |
| Tipus de dades i interessats | Identificatives, contacte, dades comercials, si escau categories especials si el producte ho permet. Interessats: clients finals, empleats, proveïdors del client. |
| Personal de la SaaS | Confidencialitat per contracte, control d'altes i baixes, principi del mínim privilegi en accessos a dades de client. |
| Mesures de seguretat | Xifratge en trànsit i en repòs, control d'accessos amb doble factor, segregació lògica entre tenants, registre d'activitat, còpies de seguretat, gestió de vulnerabilitats, certificacions (ISO 27001, SOC 2) si s'apliquen. |
| Subencarregats | Llista accessible i actualitzada (hosting, CDN, monitoratge, suport extern si n'hi ha), autorització general en el DPA i mecanisme de notificació de canvis. |
| Transferències internacionals | Identificació de països fora de l'EEE, base de la transferència (decisió d'adequació, Data Privacy Framework per als EUA, clàusules contractuals tipus) i anàlisi d'impacte quan escaigui. |
| Assistència per a drets | Eines al producte perquè el client atengui drets de l'interessat (exportació, supressió, rectificació) i procediment de suport quan es requereix intervenció tècnica. |
| Notificació de bretxes | Termini concret per notificar al client qualsevol bretxa que afecti les seves dades (típicament 24-48 hores), informació mínima i procediment de col·laboració. |
| Devolució i supressió | En finalitzar la subscripció, el client pot exportar les dades en format estructurat (CSV, JSON, API). Termini de retenció posterior, normalment 30-90 dies, i supressió segura confirmada. |
Subencarregats: la cadena que tota SaaS ha de documentar
Gairebé cap SaaS opera sola: al darrere sol haver-hi un proveïdor cloud (AWS, Google Cloud, Azure), una CDN (Cloudflare, Fastly), un servei de monitoratge (Sentry, Datadog), una passarel·la de pagament (Stripe), una eina de suport (Intercom, Zendesk), un proveïdor de correu transaccional (SendGrid, Postmark) i, cada cop més, models d'IA externs.
Cadascun d'aquests proveïdors processa dades dels clients de la SaaS i és, per tant, subencarregat en el sentit de l'art. 28.2 RGPD. La SaaS ha de:
- Mantenir una llista pública i actualitzada de tots els subencarregats que utilitza, accessible des del lloc web (típicament en una pàgina titulada "Subprocessors" o "Subencarregats").
- Signar amb cada subencarregat un contracte de l'art. 28 RGPD amb garanties equivalents a les del DPA principal.
- Notificar als clients amb antelació raonable (entre 14 i 30 dies sol ser estàndard) qualsevol canvi significatiu: incorporació d'un nou subencarregat, substitució d'un d'existent, ampliació de l'abast del tractament.
- Permetre al client oposar-se al canvi en aquest termini. Si l'oposició és justificada i bloqueja la continuïtat del servei, el client ha de tenir dret a rescindir la seva subscripció.
Encarregat vs. responsable independent: la frontera que més costa de dibuixar
L'error més subtil del SaaS en protecció de dades és assumir que tota l'operativa sobre les dades del client es regeix pel règim d'encarregat. En realitat, hi ha tres zones on la SaaS freqüentment actua com a responsable independent i on el règim aplicable canvia completament:
- Analítica agregada del producte: si la SaaS creua dades d'ús de tots els seus clients per millorar el producte, generar benchmarks sectorials o entrenar models de recomanació, aquesta finalitat és pròpia de la SaaS, no del client. La SaaS es converteix en responsable i necessita base jurídica autònoma (típicament interès legítim de l'art. 6.1.f RGPD, amb ponderació documentada), informar els interessats finals per via contractual amb els seus clients-empresa o anonimitzar les dades abans del creuament.
- Entrenament de models d'IA: utilitzar les dades dels clients per entrenar models generals que serviran a tots els clients futurs és clarament una finalitat pròpia de la SaaS. Sense consentiment explícit del client o sense anonimització irreversible, aquest tractament no està cobert pel rol d'encarregat.
- Màrqueting comercial als usuaris del producte: si la SaaS envia newsletters, ofertes d'upsell o comunicacions de producte a usuaris individuals que pertanyen a empresses-client, està actuant com a responsable sobre les dades d'aquests usuaris concrets, no com a encarregada sobre les dades de les seves empresses.
La forma professional de gestionar aquesta zona és:
- Mapejar amb claredat quins tractaments són d'encarregat i quins de responsable independent.
- Regular cadascun amb la seva pròpia base jurídica i documentació.
- Esmentar explícitament al DPA quins tractaments queden fora del rol d'encarregat i quins requereixen consentiment addicional o anonimització prèvia.
- Oferir al client mecanismes per autoritzar o bloquejar els tractaments opcionals (opt-in / opt-out clarament diferenciat).
"En SaaS, el compliment de l'art. 28 RGPD no és paperassa: és producte. Un DPA accessible, una llista de subencarregats pública i una segregació clara de tenants són tres senyals que els clients empresarials miren abans de signar. Complir bé accelera vendes; complir malament les bloqueja."
Mario P. Talamillo · Soci director, Certix®
Multi-tenant i segregació: la mesura de seguretat estructural
Una SaaS atén múltiples clients (tenants) en una mateixa infraestructura. La forma en què l'arquitectura segrega les dades entre tenants és una mesura de seguretat estructural de l'art. 32 RGPD i, en conseqüència, un punt que el DPA ha de descriure amb honestedat tècnica:
- Multi-tenant lògic amb segregació a nivell d'aplicació (cada registre porta un identificador de tenant i el filtratge està aplicat en totes les consultes). És el model més estès. Requereix extrema cura en els tests perquè cap bug no permeti leakage entre tenants.
- Multi-tenant físic amb base de dades separada per client. Major cost operatiu però millor segregació. Habitual en SaaS de gamma alta o sectors molt regulats.
- Single-tenant aïllat amb instància dedicada per client. L'extrem oposat, reservat a clients molt grans o regulats.
El client empresarial madur pregunta per aquest punt abans de signar. Una SaaS professional ho documenta al DPA i a la seva documentació de seguretat pública.
Bretxes: la SaaS és el canal natural de notificació
Quan es produeix una bretxa de seguretat a la SaaS, el règim de l'art. 33 RGPD obliga el client (responsable) a notificar-ho a l'AEPD (Agència Espanyola de Protecció de Dades) en menys de 72 hores. Perquè això sigui tècnicament possible, la SaaS (encarregada) ha d'avisar el client amb la màxima rapidesa. El DPA ho ha de regular:
- Termini de notificació al client: típicament 24-48 hores des que la SaaS en pren coneixement.
- Informació mínima de la primera comunicació: naturalesa de l'incident, sistemes i categories de dades afectats, abast estimat, mesures immediates adoptades.
- Col·laboració tècnica: la SaaS facilita al client el que necessita per preparar la notificació a l'AEPD i, si escau, la comunicació als afectats.
- Comunicació posterior: anàlisi de causa arrel, pla de millora, lliçons apreses.
Checklist mínim d'una SaaS responsable
- DPA estàndard publicat, accessible i signable, alineat amb el contingut de l'art. 28.3 RGPD.
- Llista pública de subencarregats amb identificació, funció, país i URL del DPA propi de cadascun.
- Mecanisme de notificació de canvis de subencarregats a clients amb termini raonable d'oposició.
- Mapatge clar entre tractaments d'encarregat i de responsable independent, amb bases jurídiques diferents.
- Política d'ús d'IA i entrenament: quines dades es fan servir per millorar el model i sota quina autorització del client.
- Documentació pública de seguretat: xifratge, segregació de tenants, certificacions, recovery point objective.
- Procediment de notificació de bretxes a clients amb termini exprés.
- Funcionalitats al producte per a exportació, supressió i rectificació que facilitin al client atendre drets de l'interessat.
- Pàgina pública de privacitat per a usuaris del producte (web públic, prova gratuïta) que separi clarament del DPA empresarial.
Preguntes freqüents
Una empresa SaaS és responsable o encarregada del tractament sobre les dades que processen els seus clients?
La regla general és encarregada (art. 28 RGPD) sobre les dades que el client puja a la plataforma. Però la SaaS també actua com a responsable independent en altres capes: compte de l'administrador, facturació, anàlisi d'ús agregat, millora del propi servei. La dualitat s'ha de regular clarament en els termes de servei i, sobretot, en el DPA de l'art. 28 RGPD que la SaaS signa amb cada client.
Què ha d'oferir una SaaS als seus clients per complir l'art. 28 RGPD?
Un Data Processing Agreement (DPA) que contingui el contingut mínim de l'art. 28.3 RGPD: objecte, durada, naturalesa i finalitat, tipus de dades, obligacions, confidencialitat, mesures de seguretat, subencarregats, assistència per a drets, notificació de bretxes i devolució de dades. Sol oferir-se com a annex d'adhesió als termes del servei o signat expressament.
Quan deixa una SaaS de ser encarregada i es converteix en responsable independent?
Quan decideix per si mateixa finalitats noves que el client no li ha indicat: creuament de dades entre clients per a analítica pròpia, entrenament de models d'IA generals, reutilització per millorar el producte comercial més enllà de la prestació contractada o màrqueting a usuaris individuals. En aquests casos cal base jurídica autònoma, informar els interessats i complir tots els altres deures del responsable.
Una SaaS ha d'oferir als seus clients garanties sobre els subencarregats que utilitza?
Sí (art. 28.2 RGPD). La SaaS ha de mantenir una llista accessible i actualitzada de subencarregats (AWS, Google Cloud, Cloudflare, Stripe, etc.), signar amb cadascun un contracte de l'art. 28 RGPD amb garanties equivalents, notificar al client els canvis significatius amb antelació raonable i permetre-li oposar-se al canvi. Les grans plataformes cloud ofereixen els seus propis DPA estàndard que s'han de revisar.
Aquest contingut és merament orientatiu i divulgatiu; no constitueix en cap cas assessorament jurídic especialitzat. L'aplicació de la normativa a cada cas concret requereix una anàlisi individualitzada. La normativa autonòmica sectorial pot ampliar o modificar terminis i requisits.
El teu SaaS té un DPA sòlid que aguanti el due diligence de clients empresarials?
A Certix t'assignem un expert en compliment del sector tecnològic. Sense intermediaris comercials, sense plantilles genèriques.
Parlar amb un expert