Contracte SaaS și aplicații clasice: ce trebuie să știi

Atunci când discutăm despre contracte SaaS și aplicații clasice, punctul de plecare trebuie să fie modul în care produsul este furnizat. Un model de licență sau un set standard de termeni și condiții nu poate fi folosit automat pentru ambele situații, căci documentele potrivite pentru o platformă SaaS nu sunt identice cu cele necesare pentru o aplicație instalată pe dispozitivul clientului.

Diferența vine din modul în care produsul este furnizat. Un SaaS funcționează ca un serviciu continuu: furnizorul găzduiește platforma, aplică actualizările și păstrează serviciul disponibil. În cazul unei aplicații clasice, accentul cade, de regulă, pe licență, livrare, instalare și mentenanță.

Scopul acestui ghid este de a explica, pe scurt și practic, cum trebuie gândite contractile pentru platforme tip SaaS și, respectiv, cele pentru aplicațiile clasice, ce documente sunt necesare și unde apar cele mai importante diferențe juridice.

I. Pornește de la felul în care funcționează produsul

Într-un model SaaS – Software as a Service – utilizatorul nu primește programul pentru a-l administra independent. El primește acces la o platformă găzduită de furnizor, de obicei prin browser sau aplicație mobilă. Furnizorul controlează infrastructura, versiunea produsului și actualizările, iar accesul încetează, de regulă, odată cu abonamentul.

În cazul aplicației clasice, programul este instalat pe calculatorul utilizatorului sau în infrastructura clientului. Clientul primește un drept de utilizare asupra unei copii a programului și are, de obicei, mai mult control asupra mediului tehnic, datelor și momentului în care instalează actualizările.

Multe produse combină însă cele două modele. O aplicație instalată local poate folosi autentificare online, sincronizare în cloud sau copii de siguranță administrate de furnizor; tocmai de aceea, documentația nu trebuie construită după denumirea produsului, ci după modul în care acesta funcționează în realitate.

II. Nu folosi același contract pentru ambele modele

În cazul SaaS, obligațiile furnizorului continuă pe toată durata contractului. Acesta trebuie să asigure accesul, să mențină infrastructura, să remedieze incidentele, să gestioneze actualizările și să protejeze datele găzduite în platformă.

Pentru o aplicație instalată local, momentul livrării este mult mai important. Contractul trebuie să arate ce se livrează, pe ce sisteme trebuie să funcționeze, cum se face instalarea, când se consideră acceptată aplicația și ce suport primește clientul ulterior.

Un contract generic riscă să rateze exact aceste diferențe. Un simplu contract de licență nu este suficient pentru un SaaS dacă nu spune nimic despre disponibilitate, securitate sau exportul datelor. În același timp, termenii unei platforme online nu rezolvă automat criteriile de acceptanță și cerințele tehnice ale unei aplicații instalate local. De aceea, diferențele dintre contracte SaaS și aplicații clasice trebuie reflectate în documentația juridică, nu doar în descrierea tehnică sau comercială a produsului.

III. Alege documentele potrivite

Pentru un SaaS standard, achiziționat direct de pe website, punctul de plecare este de regulă un set de termeni și condiții. Acesta stabilește cine poate folosi serviciul, ce funcții sunt incluse, cum se plătește abonamentul, când poate fi suspendat contul și cum încetează relația contractuală.

Pentru clienții mai mari, documentația este de obicei modulară. Condițiile comerciale pot fi incluse într-un formular de comandă, regulile generale într-un contract-cadru, iar disponibilitatea și timpii de intervenție într-un acord privind nivelul serviciilor, cunoscut ca SLA. Dacă furnizorul prelucrează date personale în numele clientului, va fi necesar și un acord de prelucrare a datelor, cunoscut ca DPA, uneori completat de o anexă privind securitatea.

Pentru o aplicație clasică, documentul central este contractul de licență. Dacă furnizorul se ocupă și de instalare ori personalizare, trebuie adăugate specificațiile tehnice, etapele de implementare și criteriile de acceptanță. Mentenanța și suportul ar trebui reglementate separat, mai ales dacă se plătesc printr-un abonament distinct.

IV. Spune clar ce primește clientul

Contractul trebuie să descrie produsul suficient de clar. Pentru SaaS, este important să fie stabilite planul ales, numărul de utilizatori, funcțiile incluse, limitele de utilizare și eventualele servicii suplimentare. Pentru aplicația clasică, licența trebuie să arate pe câte dispozitive poate fi instalat programul, cine îl poate folosi, pentru ce activități și pe ce durată.

Prețul trebuie corelat cu modelul comercial. În cazul abonamentelor, termenii trebuie să explice frecvența facturării, reînnoirea automată, consecințele neplății și condițiile în care prețul poate fi modificat. Clientul ar trebui să știe din timp ce opțiuni are dacă nu acceptă noul preț.

Într-un SaaS, furnizorul poate aplica actualizările tuturor utilizatorilor în același timp. Tocmai de aceea, contractul trebuie să distingă între actualizările de securitate, îmbunătățirile obișnuite și schimbările care elimină o funcție importantă. O clauză care permite modificarea serviciului oricând și în orice mod este prea largă și poate crea probleme, mai ales în relația cu consumatorii.

La încetarea contractului, regulile trebuie să fie la fel de clare ca la început. Pentru SaaS, trebuie stabilit cum își recuperează clientul datele, în ce format, cât timp rămân disponibile și când sunt șterse. Pentru o aplicație clasică, trebuie precizat dacă licența încetează sau dacă utilizatorul poate continua să folosească versiunea cumpărată fără mentenanță și actualizări.

V. Tratează protecția datelor ca parte din produs

O politică de confidențialitate și un DPA nu au același rol. Politica explică persoanelor vizate cum sunt folosite datele lor. DPA-ul stabilește regulile dintre client și furnizor atunci când furnizorul prelucrează date în numele clientului.

Într-un SaaS B2B, clientul este adesea operator pentru datele încărcate în platformă, iar furnizorul acționează ca persoană împuternicită. În acest caz, art. 28 GDPR impune ca DPA-ul să acopere, printre altele, instrucțiunile clientului, confidențialitatea, securitatea, subcontractanții și ștergerea sau returnarea datelor la finalul contractului.

Furnizorul poate avea și rol de operator pentru anumite prelucrări proprii, cum sunt administrarea conturilor, facturarea sau prevenirea fraudei. Din acest motiv, rolurile trebuie stabilite pentru fiecare scop în parte, nu doar declarate generic în contract.

La o aplicație instalată local, furnizorul poate să nu aibă acces la date după livrare, însă situația se schimbă dacă oferă suport la distanță, colectează informații tehnice, administrează copii de siguranță sau poate accesa baza de date a clientului. În aceste cazuri pot fi necesare aceleași reguli de protecție și securitate ca într-un SaaS.

Confidențialitatea comercială trebuie tratată separat. Codul, documentația tehnică, planurile de dezvoltare, prețurile și datele de business pot fi confidențiale chiar dacă nu sunt date personale.

VI. Clarifică cine deține produsul și dezvoltările

Faptul că un client plătește pentru software nu înseamnă automat că dobândește drepturile de autor asupra lui. În mod obișnuit, clientul primește doar dreptul de a utiliza produsul în limitele stabilite prin contract.

Potrivit Legii nr. 8/1996, programele pentru calculator sunt protejate prin drept de autor, iar transferul dreptului de utilizare nu înseamnă și transferul dreptului de autor asupra programului.

Contractul trebuie să separe clar platforma, codul și componentele deja deținute de furnizor de datele și conținutul clientului. Dezvoltările realizate special pentru client trebuie tratate distinct: fie drepturile sunt transferate clientului, fie acesta primește o licență suficientă pentru scopul proiectului.

Dacă furnizorul dorește să păstreze module sau instrumente pe care le folosește și pentru alți clienți, acestea trebuie identificate expres. La fel, trebuie avute în vedere componentele terților, programele cu sursă deschisă și integrările externe, pentru că furnizorul nu poate acorda mai multe drepturi decât deține.

VII. Stabilește obligații realiste pentru ambele părți

În cazul unei platforme SaaS, o formulare generală potrivit căreia furnizorul va depune toate eforturile pentru a asigura funcționarea serviciului poate fi insuficientă. SLA-ul ar trebui să stabilească nivelul de disponibilitate, situațiile exceptate, intervalele de mentenanță, timpii de răspuns și remediile aplicabile dacă serviciul nu funcționează conform celor asumate.

Pentru aplicația instalată local, contractul trebuie să prevadă o procedură de testare și acceptanță. Astfel se poate face diferența dintre un defect real, o incompatibilitate a sistemului clientului și o funcție care nu a fost inclusă în proiect.

De asemenea, și utilizatorul are la rândul său obligații pe care trebuie să le respecte. El trebuie să își protejeze datele de acces, să folosească produsul legal și să respecte limitele licenței sau ale abonamentului. În cazul aplicațiilor locale, clientul poate avea și obligația de a asigura un mediu tehnic compatibil și de a instala actualizările necesare.

Răspunderea trebuie adaptată riscurilor reale. Furnizorul va urmări, de regulă, un plafon raportat la sumele plătite de client. În același timp, pot fi necesare reguli distincte pentru încălcarea confidențialității, incidente de securitate, probleme de proprietate intelectuală sau indisponibilitate gravă. Contractul nu ar trebui să transfere asupra utilizatorului riscurile pe care doar furnizorul le poate controla.

VIII. Dacă vinzi consumatorilor, regulile sunt mai stricte

În relațiile dintre profesioniști există mai mult spațiu pentru negocierea contractului și împărțirea riscurilor, însă în relația cu un consumator, o parte importantă a protecției este obligatorie și nu poate fi înlăturată prin T&C.

OUG nr. 141/2021 se aplică atât serviciilor digitale de tip SaaS, cât și aplicațiilor instalabile. Produsul trebuie să respecte cerințele de funcționalitate, compatibilitate și securitate, iar comerciantul trebuie să furnizeze actualizările necesare. Dacă produsul nu este conform, consumatorul poate cere remedierea, reducerea prețului sau încetarea contractului, în condițiile legii.

Termenii standard trebuie să fie clari și să nu creeze un dezechilibru semnificativ în detrimentul consumatorului. Probleme pot apărea, de exemplu, atunci când furnizorul își rezervă dreptul de a modifica unilateral orice funcție, stabilește o perioadă nerezonabil de scurtă pentru refuzul reînnoirii sau face încetarea contractului inutil de dificilă.

Pentru contractele încheiate online, OUG nr. 34/2014 prevede, ca regulă, un drept de retragere de 14 zile. Din 19 iunie 2026, interfața online trebuie să ofere și o funcție vizibilă prin care consumatorul să își poată exercita retragerea în această perioadă. Așadar, conformitatea nu ține doar de textul T&C, ci și de modul în care este construit produsul.

IX. Gândește și ieșirea clientului din platformă

Pentru un SaaS, contractul nu este complet dacă explică doar cum intră clientul în platformă. Trebuie să arate și cum poate pleca: ce date poate exporta, în ce format, cât timp le mai poate accesa și ce asistență primește pentru migrare.

Regulamentul (UE) 2023/2854 – Data Act se aplică din 12 septembrie 2025 și urmărește eliminarea obstacolelor care împiedică schimbarea furnizorului de servicii de prelucrare a datelor, categorie în care intră și serviciile SaaS. De la 12 ianuarie 2027, taxele pentru operațiunile necesare schimbării furnizorului și transferului datelor vor fi eliminate integral.

Aceste reguli trebuie reflectate atât în contract, cât și în produs. O promisiune de export al datelor nu ajută dacă platforma nu oferă, în practică, o metodă clară și utilizabilă de descărcare sau transfer.

X. Ce ar trebui verificat înainte de lansare?

Înainte să redactezi contractele, merită să clarifici câteva aspecte de bază:

• cum este livrat produsul și ce componente sunt găzduite de furnizor;
• ce date sunt colectate, unde sunt stocate și cine are acces la ele;
• dacă produsul este destinat profesioniștilor, consumatorilor sau ambelor categorii;
• ce funcții, niveluri de disponibilitate și servicii sunt promise clienților;
• cine deține codul, datele și dezvoltările personalizate;
• ce se întâmplă în caz de incident, neplată, încetare sau migrare.

Documentele trebuie apoi corelate între ele și cu produsul real. Pagina de prețuri, materialele de prezentare și interfața nu ar trebui să promită mai mult decât poate susține contractul, iar contractul nu ar trebui să descrie funcții pe care produsul nu le oferă.

XI. Concluzie

Diferența dintre SaaS și aplicația clasică nu este doar tehnică. Ea schimbă obiectul contractului, documentele necesare și riscurile pe care trebuie să le gestioneze fiecare parte.

Pentru SaaS, accentul cade pe furnizarea continuă a serviciului, disponibilitate, securitate, date și migrare. Pentru aplicația instalată local, sunt esențiale licența, specificațiile tehnice, acceptanța, compatibilitatea și mentenanța. Un produs hibrid are nevoie de ambele tipuri de reguli.

Dacă produsul este încă într-o etapă de început, poate fi util și ghidul nostru juridic pentru startup-uri, care explică principalele aspecte juridice ce trebuie clarificate înainte ca businessul să înceapă să crească.

Dacă dezvoltați sau comercializați o platformă SaaS ori o aplicație software, echipa ZIC Legal vă poate ajuta cu structurarea contractului, redactarea termenilor și condițiilor, SLA, DPA și documentația necesară lansării sau negocierii cu clienții.