Termeni și condiții: specificație de produs, nu text copiat

Cardul unui client expiră marți dimineața. Stripe reîncearcă plata, eșuează, trece abonamentul în past_due și trimite invoice.payment_failed. Aplicația continuă să servească exact aceleași funcții ca luni, fiindcă nimeni nu a scris codul care le oprește. Termenii și condițiile, în schimb, spun că accesul se suspendă automat la neplată.

Trei descrieri ale aceluiași eveniment: una în Stripe, una în cod, una în document. Numai primele două produc efecte. A treia e o promisiune pe care produsul nu o ține — și, spre deosebire de o politică de confidențialitate incompletă, se verifică din exterior fără niciun instrument.

Termenii și condițiile sunt singurul document legal care descrie comportamentul aplicației: ce se întâmplă la neplată, la suspendare, la ștergerea contului, la modificarea prețului, la downtime. În majoritatea site-urilor descriu un produs pe care echipa nu l-a construit niciodată — textul a fost copiat dintr-un șablon înainte ca produsul să existe și nu a mai fost citit după.

Termenii și condițiile descriu un produs, nu o pagină

Nu există un model impus prin lege pentru un T&C. Există o listă de lucruri fără de care documentul nu ține: cine e furnizorul și care e serviciul, cum se încheie contractul — care clic obligă și ce confirmare primește clientul —, prețul cu moneda și regimul de TVA, durata și reînnoirea, condițiile de încetare, limitele de răspundere, legea aplicabilă și instanța, plus data ultimei actualizări și un mecanism declarat de modificare.

Fiecare punct din listă e o afirmație despre o stare a sistemului. „Contractul se încheie la confirmarea comenzii” înseamnă un moment în care un rând devine confirmed și pleacă un e-mail. „Abonamentul se reînnoiește automat” înseamnă un job și un webhook. „Contul poate fi șters oricând” înseamnă un endpoint, o coadă și o politică de backup.

Informarea precontractuală nu e același lucru cu T&C-ul

Confuzia asta e sistematică, iar consecințele ei cad pe două suprafețe diferite din aplicație.

Informarea precontractuală e un set de informații pe care consumatorul trebuie să le primească înainte de a plasa comanda, chiar pe ecranul unde o plasează: caracteristicile serviciului, identitatea profesionistului, prețul total cu taxe, modalitățile de plată, durata și încetarea, dreptul de retragere, existența garanției legale de conformitate. OUG nr. 34/2014 cere în plus ca butonul care angajează plata să fie etichetat neechivoc — „comandă ce implică o obligație de plată” sau o formulare la fel de clară. Fără eticheta asta, consumatorul nu e ținut de comandă.

T&C-ul e altceva: conținutul contractului, disponibil permanent, la care informarea face trimitere. Un link în subsolul paginii de checkout nu îndeplinește obligația de informare — aceasta trebuie prezentată, nu doar accesibilă.

Pentru un produs strict B2B, tot blocul ăsta dispare. Rămân regulile de comerț electronic și dreptul comun al contractelor, cu o condiție: excluderea trebuie scrisă explicit și susținută de fluxul real de comandă — cele trei elemente care o fac să țină apar în ce trebuie să conțină un site legal în România, punctul 6.

Testul care găsește clauzele goale

Metoda de audit e mecanică. Extragi din document fiecare propoziție care promite un comportament automat sau o consecință și cauți, pentru fiecare, locul din sistem care o execută: o funcție, un job, un webhook handler, o setare din dashboard-ul unui furnizor sau, în cel mai bun caz onest, o procedură umană cu un responsabil.

Rezultatul se așază în trei coșuri. Clauze cu execuție identificabilă — bune. Clauze fără execuție, dar care descriu o autorizare exercitată manual — acceptabile, dacă responsabilul e real. Clauze fără execuție care promit ceva clientului — acolo e problema: o lipsă de funcționalitate devine o afirmație inexactă.

Neplata: ce spune clauza, ce face state machine-ul

Aici divergența e cea mai ușor de demonstrat, pentru că stările au nume publice și sunt documentate de procesatorul de plăți.

Documentația Stripe descrie opt stări pentru un abonament: trialing, active, incomplete, incomplete_expired, past_due, canceled, unpaid și paused. Diferența dintre ele nu e cosmetică. Un abonament past_due continuă să genereze facturi și poate reveni la active dacă factura cea mai recentă e plătită. Unul unpaid rămâne în vigoare și generează facturi, dar nu mai încearcă plata — documentația recomandă explicit revocarea accesului aici. Unul canceled e terminal. Iar incomplete_expired apare când prima factură rămâne neplătită 23 de ore de la crearea abonamentului: stare finală, ireversibilă.

Ce se întâmplă după ultima reîncercare e o setare, nu o clauză

Punctul pe care îl ratează aproape toate documentele: destinația finală a unui abonament past_due, după epuizarea reîncercărilor, se configurează în setările de facturare din dashboard. Opțiunile sunt trei — trecerea în canceled, trecerea în unpaid sau menținerea în past_due.

Adică propoziția din T&C care spune ce se întâmplă la neplată descrie o valoare de configurare pe care persoana care a scris textul, de regulă, nu a deschis-o niciodată. Dacă setarea e „rămâne past_due”, iar clauza spune „contractul încetează de drept”, documentul descrie o încetare care nu are loc: abonamentul continuă să genereze facturi și clientul rămâne în sistem.

Perioada de grație trebuie să existe în cod, nu doar în frază

„Accesul se suspendă la neplată” e imprecis în toate direcțiile. La ce neplată — prima încercare eșuată sau ultima? După câte zile? Ce înseamnă suspendare: blocarea autentificării, trecerea contului în mod read-only, oprirea job-urilor de fundal?

Formularea utilizabilă spune trei lucruri: evenimentul care pornește numărătoarea, durata, și efectul exact. „La prima încercare de plată eșuată începe o perioadă de grație de 14 zile, în care serviciul funcționează normal. După expirarea ei, contul trece în regim de citire: datele rămân accesibile și exportabile, iar crearea de conținut nou și integrările automate se opresc.” Fiecare element are corespondent: un handler pe invoice.payment_failed care marchează începutul, un câmp cu data-limită, un guard în middleware care aplică regimul de citire.

Documentația însăși nu e perfect consecventă

Merită știut înainte de a copia stări în text. În aceeași pagină despre webhook-uri, Stripe descrie efectul lui invoice.payment_failed în două feluri: într-un tabel, statusul PaymentIntent-ului devine requires_action, în altul requires_payment_method; iar despre abonament se spune într-un loc că statusul rămâne incomplete doar pentru prima factură, iar în altul, fără nuanța asta, că trece în incomplete.

Starea reală se citește din obiectul primit, nu din memorie și nici din documentație. De aici și o regulă de redactare: numele stărilor interne ale procesatorului nu au ce căuta în T&C. Descrie efectul pentru client în cuvinte pe care le poate verifica — ce vede, ce nu mai poate face, după cât timp. Pentru partea de implementare, cu webhook-uri, idempotență și reconciliere, există un material dedicat despre billing cu Stripe.

Modificarea unilaterală: preț, funcții, termeni

Clauza-tip sună așa: „ne rezervăm dreptul de a modifica oricând prezenții termeni și prețurile, fără notificare prealabilă”. În relația cu un consumator, pică — și merită spus pe ce temei anume, nu ca opinie.

Anexa la Legea nr. 193/2000 enumeră, cu titlu de exemplu, clauzele considerate abuzive. Litera a) vizează exact prevederile care dau profesionistului dreptul de a modifica unilateral clauzele contractului fără un motiv întemeiat precizat în contract. Litera e) vizează modificarea unilaterală, fără acordul consumatorului, a caracteristicilor produselor sau serviciilor care urmează să fie furnizate. Sancțiunea civilă e la articolul 6: clauza abuzivă nu produce efecte asupra consumatorului, iar contractul continuă dacă mai poate funcționa fără ea.

Ce salvează clauza: motivul și notificarea

Aceeași literă a) conține și portița, iar ea descrie un mecanism, nu o formulare. Modificarea unilaterală a unui contract cu durată nedeterminată rămâne posibilă dacă profesionistul are obligația de a-l informa pe consumator printr-o notificare prealabilă transmisă într-un termen rezonabil, astfel încât acesta să poată rezilia contractul.

Trei elemente, toate cu corespondent tehnic: un motiv scris în contract, o notificare care pleacă înainte, o cale de ieșire care funcționează. Notificarea nu e un banner în aplicație — trebuie să ajungă la client, ceea ce în practică înseamnă e-mail plus înregistrarea faptului că a fost trimis. Calea de ieșire înseamnă că anularea trebuie să fie disponibilă în intervalul dintre notificare și intrarea în vigoare, fără să treacă printr-un formular de contact. Iar formularul acela are, la rândul lui, obligațiile proprii — de la temei până la ștergere, în materialul despre formularul de contact ca suprafață de conformitate.

Pentru servicii digitale, regula e și mai strictă

OUG nr. 141/2021, care transpune directiva privind conținutul digital și serviciile digitale, se aplică inclusiv atunci când clientul nu plătește un preț, ci furnizează date cu caracter personal. Articolul 18 permite modificarea serviciului dincolo de ce e necesar pentru menținerea conformității, dar numai cu patru condiții cumulative: contractul permite modificarea și prevede o justificare valabilă; modificarea nu aduce costuri suplimentare pentru consumator; consumatorul e informat clar; iar dacă modificarea are impact negativ, informarea se face din timp, pe suport durabil, cu caracteristicile și data modificării și cu menționarea dreptului de a înceta contractul.

Când impactul negativ nu e minor, consumatorul poate înceta contractul fără costuri în 30 de zile de la primirea informării sau de la data modificării, oricare intervine mai târziu. Nerespectarea articolului 18 alineatele (1) și (3) e contravenție, cu amendă de la 10.000 la 50.000 lei. Iar articolul 24 închide discuția despre clauzele care ar încerca să deroge: nu produc efecte în defavoarea consumatorului.

Versionarea termenilor e o cerință tehnică

Dacă modificarea produce efecte doar după notificare, sistemul trebuie să știe ce versiune a acceptat fiecare client și când. Concret: un tabel cu versiunile documentului, o coloană pe contul de client cu versiunea acceptată și data, un ecran care afișează diferențele la prima autentificare după publicare, și o dată de intrare în vigoare separată de data publicării.

Fără asta, întrebarea „ce a acceptat clientul în martie” nu are răspuns, iar clauza de modificare devine neverificabilă în ambele sensuri. Prețul are, în plus, propria constrângere de afișare: regimul de TVA lângă valoare, cu regula pe două ramuri pentru consumatori și pentru firme. Cum arată asta în facturare, împreună cu e-Factura, stă în conformitatea fiscală a unui SaaS din România.

Limitarea răspunderii și SLA-ul

Un plafon de răspundere e o clauză normală într-un contract între profesioniști. Nu e nelimitat, însă: Codul civil prevede la articolul 1355 că răspunderea pentru prejudiciul material cauzat cu intenție sau din culpă gravă nu poate fi exclusă ori limitată prin convenție. Un plafon rezonabil rezistă; o clauză care exonerează furnizorul indiferent de conduită, nu.

În relația cu un consumator, lista de la Legea 193/2000 adaugă două limite dure: litera k) — excluderea sau limitarea răspunderii legale în caz de vătămare sau deces — și litera l) — excluderea dreptului consumatorului de a acționa în justiție, cerându-i în schimb rezolvarea disputelor în special prin arbitraj.

Ce nu poți limita la un serviciu digital

Peste toate astea vine regimul de conformitate din OUG 141/2021, care nu se negociază. Când contractul prevede furnizare continuă pe o perioadă, comerciantul răspunde pentru orice neconformitate apărută în acel interval, iar sarcina probei privind conformitatea îi revine tot lui. Aducerea în conformitate se face într-un termen rezonabil care nu poate depăși 15 zile calendaristice de la sesizare. Consumatorul are dreptul la reducerea proporțională a prețului pentru perioada în care serviciul nu a fost conform.

O clauză de tipul „serviciul e furnizat ca atare, fără nicio garanție” nu produce efectul dorit în fața unui consumator. Poate produce însă un efect nedorit în fața ANPC, ca informare incorectă despre drepturi.

SLA-ul e obligație doar dacă are un remediu

Diferența dintre un SLA contractual și un slogan e remediul. „Disponibilitate 99,9%” fără nimic în continuare e o afirmație de marketing. „Disponibilitate 99,9% lunară, măsurată la nivelul endpoint-ului public, verificată din trei locații externe; sub prag, credit de 10% din abonamentul lunar, aplicat automat la următoarea factură” e o obligație, pentru că fiecare element e verificabil și are un executant.

Capcana e că afirmațiile publice nu rămân fără efect doar pentru că nu-s în contract. La serviciile digitale, cerințele obiective de conformitate includ ceea ce consumatorul se poate aștepta în mod rezonabil, ținând seama de orice declarație publică făcută de comerciant sau în numele lui, mai ales în anunțuri publicitare. Un procent de uptime scris mare pe pagina de prețuri intră în această categorie, chiar dacă T&C-ul nu îl menționează. Excepțiile sunt înguste: comerciantul trebuie să demonstreze că nu cunoștea declarația, că a rectificat-o în același mod înainte de încheierea contractului sau că ea nu ar fi putut influența decizia de achiziție.

Cine măsoară downtime-ul

Dacă în document scrie un procent, cineva trebuie să îl poată calcula: sursa de măsurare — monitorizare externă, nu log-urile proprii —, fereastra de calcul, ce se scade din ea (mentenanța anunțată, incidentele la terți, dacă sunt excluse explicit) și cum se cere creditul, dacă nu se aplică automat.

Un SLA fără sursă de măsurare declarată rămâne o clauză pe care furnizorul o interpretează singur. Nu ține nici în B2B, unde clientul poate veni cu propriile date de monitorizare.

Ștergerea contului și ce rămâne după

Clauza tipică spune că utilizatorul poate șterge contul oricând și că datele se șterg. Traducerea în sistem e mai lungă, iar diferența dintre cele două e locul unde se produc plângerile.

Regulamentul (UE) 2016/679 dă dreptul la ștergere la articolul 17, dar cu excepțiile din alineatul (3) — între care îndeplinirea unei obligații legale. Facturile și evidențele contabile intră acolo: nu se șterg la cererea clientului, iar termenul de păstrare nu ți-l alegi tu.

Ce înseamnă „șterge” în trei straturi

Un flux corect are trei momente distincte, iar clauza ar trebui să le numească pe toate: dezactivarea imediată a accesului, ștergerea efectivă din baza de date activă după o fereastră de recuperare declarată, și expirarea copiilor de siguranță după rotația lor. Dacă backup-urile se păstrează 30 de zile, datele nu dispar complet în ziua cererii, iar textul care sugerează contrariul e inexact.

La final rămân datele pe care legea le cere păstrate, în sisteme separate, cu acces restrâns — factura, nu profilul. Inventarul complet al prelucrărilor, cu duratele și destinatarii fiecăreia, e construit după metoda din articolul despre politica de confidențialitate ca document tehnic; T&C-ul trimite la politică, nu o rescrie.

Exportul conținutului nu e o favoare

Partea ignorată aproape universal: la încetarea contractului, OUG 141/2021 cere comerciantului să se abțină de la utilizarea conținutului care nu reprezintă date cu caracter personal, furnizat sau creat de consumator prin utilizarea serviciului, și să i-l pună la dispoziție la cerere. Consumatorul îl poate recupera fără costuri, într-un termen rezonabil care nu poate depăși 15 zile calendaristice de la cerere, într-un format utilizat în mod curent și care poate fi citit automat.

Excepțiile există — conținut fără utilitate în afara serviciului, conținut care privește doar activitatea consumatorului acolo, conținut agregat care nu poate fi dezagregat rezonabil, conținut generat în comun cu alți utilizatori. Regula rămâne însă că furnizorul poate opri accesul și dezactiva contul fără ca obligația de export să dispară.

Corespondentul tehnic e un endpoint care produce un fișier structurat, nu un e-mail către suport. Nerespectarea articolului 15 alineatele (4)-(6) e contravenție, cu amendă de la 5.000 la 30.000 lei.

Retragere, lege aplicabilă, instanță

Dreptul de retragere în 14 zile privește consumatorii și e detaliat, cu excluderea B2B și cele trei condiții cumulative, la punctul 6 din checklist-ul legal. Pentru un T&C de produs digital contează o singură literă din OUG 34/2014: articolul 16 litera m) exceptează furnizarea de conținut digital nelivrat pe suport material, dacă prestarea a început cu acordul prealabil expres al consumatorului și după ce acesta a confirmat că își pierde dreptul la retragere.

Tehnic: două acțiuni separate în interfață, nu un checkbox cu text lung, plus stocarea consimțământului cu versiunea textului și marcajul de timp. Fără dovadă, excepția nu se aplică și dreptul rămâne.

Ce s-a schimbat în 2026 și când

Statutul legislativ merită descris pe articole, nu în bloc, pentru că OUG nr. 18/2026 — publicată în Monitorul Oficial nr. 236 din 26 martie 2026 — folosește două mecanisme diferite. Articolul III stabilește intrarea în vigoare la 27 martie 2026 pentru articolul I și pentru o parte din punctele articolului II. Articolul IV alineatul (1) stabilește aplicarea de la 19 iunie 2026 pentru alte puncte, iar alineatul (2) amână aplicarea prevederilor deja intrate în vigoare până la 27 septembrie 2026. Intrare în vigoare și aplicare nu sunt același lucru pe același text — de aici confuzia din materialele care vorbesc despre „trei valuri”.

Obligația relevantă pentru un T&C se aplică deja: din 19 iunie 2026, contractele la distanță încheiate printr-o interfață online trebuie să pună la dispoziție o funcție de retragere, etichetată „retrageți-vă din contract aici” sau printr-o formulare la fel de clară, ușor de citit, vizibilă și disponibilă permanent pe toată durata perioadei de retragere. Declarația online colectează numele, datele de identificare a contractului și mijlocul electronic pentru confirmare; se transmite printr-o funcție de confirmare etichetată „confirmați retragerea”; iar profesionistul trimite fără întârzieri nejustificate o confirmare de primire pe suport durabil, cu conținutul retragerii, data și ora. Sancțiunea e amendă între 5.000 și 15.000 lei.

Articolul 16 litera m) nu a fost modificat de această ordonanță. Ce s-a adăugat sunt articolele 16^1-16^5, pentru serviciile financiare la distanță, iar OG nr. 85/2004 a fost abrogată de la 19 iunie 2026. Din 27 septembrie 2026 se aplică pachetul de informare privind durabilitatea, reparabilitatea și afirmațiile de mediu.

Legea aplicabilă când clientul e din alt stat membru

Clauza „legea română, instanțele de la sediul furnizorului” funcționează între profesioniști. Cu un consumator din alt stat membru, funcționează parțial și în ambele sensuri.

Alegerea legii rămâne valabilă, dar Regulamentul (CE) nr. 593/2008 prevede la articolul 6 alineatul (2) că ea nu poate priva consumatorul de protecția acordată de dispozițiile imperative din legea statului în care își are reședința obișnuită. Practic, dacă legislația lui e mai protectivă pe un punct, acel punct se aplică peste clauza ta.

Competența e mai categorică. Regulamentul (UE) nr. 1215/2012 permite consumatorului să acționeze în justiție la propriul domiciliu, iar profesionistul îl poate acționa numai acolo. Convențiile atributive de competență sunt admise doar dacă sunt încheiate după nașterea litigiului sau dacă îi permit consumatorului să sesizeze și alte instanțe decât cele prevăzute în secțiunea de protecție. O clauză de competență exclusivă la sediul furnizorului, semnată în avans de un consumator, nu produce efectul urmărit.

Anexa nr. 5 la Legea nr. 232/2022 cere tot aici o descriere a modului în care serviciul respectă cerințele de accesibilitate — o secțiune scurtă sau un document echivalent, cu trimitere din termeni. Ce înseamnă conformitatea în interfață e altă discuție, pe cod și criterii WCAG.

Ce promite /termeni de pe basetech.ro și unde stă execuția

Testul de mai sus se aplică și textului de față. Pagina /termeni de pe basetech.ro a fost citită pe 15 august 2026 exact cu metoda descrisă: fiecare clauză care promite un comportament automat, pusă în dreptul mecanismului care ar trebui să o execute.

Contextul schimbă natura constatărilor. Site-ul nu vinde abonamente și nu are conturi: contractul se încheie prin acceptarea unei propuneri comerciale, nu prin apăsarea unui buton. Fără state machine de abonament, webhook de plată sau flux de ștergere, divergențele descrise mai sus nu au unde să apară. Rămân clauzele care descriu procese.

Regimul de TVA lipsește de lângă preț. Secțiunea 2 enumeră intervale de preț în euro pe linie de serviciu, fără să precizeze dacă sunt cu sau fără TVA. Legea nr. 365/2002 cere la articolul 5 ca tarifele să fie indicate cu precizarea scutirii, includerii sau neincluderii taxei. E singura constatare din listă care are un temei direct și o reparație de un rând.

Penalitățile și suspendarea sunt clauze fără mecanism. Secțiunea 3 prevede penalități de 0,1% pe zi de întârziere și dreptul de suspendare a prestării după 30 de zile. Sunt autorizări, nu promisiuni către client, deci nu produc o afirmație inexactă — dar niciun sistem nu le calculează și nu le declanșează. Diferența dintre o clauză de rezervă și una moartă e existența unui responsabil, nu a unui paragraf.

Documentul nu spune cum se modifică. Nu există clauză de modificare a termenilor și nici istoric de versiuni — singurul semnal e „Ultima actualizare: 27 mai 2026” din antet, în timp ce politica de confidențialitate a fost actualizată pe 15 august 2026. Pentru un contract care se formează prin propuneri comerciale, riscul e mic; pentru un produs cu conturi, ar fi blocant.

Două documente într-unul. Secțiunea 11 declară serviciile destinate exclusiv persoanelor juridice și exclude aplicarea OUG 34/2014, iar secțiunea 9 informează totuși clientul care are calitatea de consumator despre mecanismul SAL. Nu e o contradicție juridică — e o plasă de siguranță — dar documentul descrie, în două locuri, două produse cu regimuri diferite. Ambiguitatea dispare dacă informarea SAL e legată explicit de ipoteza în care, prin excepție, se încheie un raport cu un consumator.

Declarația de accesibilitate stă în altă parte. Anexa nr. 5 la Legea 232/2022 acceptă condițiile generale sau un document echivalent; pagina dedicată din subsol îndeplinește cerința. Lipsește doar trimiterea din termeni către ea.

Partea care trece verificarea

Identificarea furnizorului e completă, cu denumire, sediu, CUI, EUID, administrator, cont bancar și e-mail. Informarea SAL indică platforma ANPC corectă și spune explicit că platforma europeană SOL nu mai funcționează din 20 iulie 2025 — inclusiv scoaterea ei din clauze, ceea ce rezolvă tiparul descris în articolul despre bannerul ANPC din footer. Momentul transferului drepturilor de autor e legat de un eveniment verificabil, confirmarea bancară a încasării. Cazurile de încetare sunt enumerate limitativ, iar forța majoră are termen de notificare.

Constatările din auditul anterior

Cele trei corecturi semnalate în articolul precedent pe pagina de confidențialitate au fost aplicate între timp: linia de măsurare a campaniilor publicitare apare acum în datele colectate și în lista de destinatari, cu Google LLC numit ca operator independent pentru conversii; afirmația despre stocarea exclusiv în Uniunea Europeană a fost înlocuită cu o formulare pe două straturi — infrastructura proprie în Uniune, transferurile către Google pe bază de decizie de adecvare și clauze contractuale standard; iar secțiunea 9 se numește acum „Contact GDPR și exercitarea drepturilor”.

Întrebări frecvente

Pot folosi un generator de termeni și condiții?

Pentru schelet, da. Pentru conținut, nu — din același motiv pentru care nu poți genera documentația unui sistem fără să-l fi văzut. Generatorul nu știe ce se întâmplă la a treia încercare de plată eșuată, câte zile ține fereastra de recuperare a contului sau ce disponibilitate poți susține.

T&C-ul trebuie acceptat explicit sau ajunge un link în subsol?

Depinde ce vrei să obții cu el. Pentru simpla utilizare a unui site informativ, un link permanent e suficient. Pentru clauze care produc efecte împotriva clientului — limitare de răspundere, plafoane, competență — ai nevoie de o acceptare pe care o poți proba: o acțiune separată la crearea contului sau la comandă, stocată cu versiunea documentului și marcajul de timp.

Cum tratez o clauză despre care nu știu dacă e abuzivă?

Verifică întâi dacă se regăsește în lista din anexa la Legea 193/2000 — acolo temeiul e direct. Dacă nu, rămâne evaluarea generală: clauza nu a fost negociată direct și creează un dezechilibru semnificativ în detrimentul consumatorului, contrar bunei-credințe. În al doilea caz formulează concluzia ca risc argumentat, nu ca interdicție.

Ce fac dacă produsul se comportă altfel decât spune documentul?

Repari partea mai ieftină, dar în ordinea corectă. Dacă clauza promite ceva ce produsul nu face, ai două opțiuni: implementezi comportamentul sau modifici textul — iar dacă alegi modificarea, se aplică regimul de notificare de mai sus. Dacă produsul face ceva ce documentul nu autorizează, ordinea se inversează: oprești comportamentul până când baza contractuală există.

Am nevoie de documente separate pentru B2B și B2C?

Nu neapărat, dar ai nevoie de secțiuni separate, marcate clar, iar fluxul trebuie să determine care se aplică. Varianta cu un singur text și o frază de excludere B2B funcționează doar dacă procesul de contractare chiar filtrează — câmp obligatoriu de firmă și CUI, validat, nu opțional.

Cât de des trebuie revizuit un T&C?

La fiecare schimbare de comportament al produsului, nu la interval fix. Un release care atinge facturarea, suspendarea sau ștergerea contului e evenimentul care declanșează revizuirea — iar dacă un pull request modifică modulele de billing, abonamente sau conturi, review-ul poate cere confirmarea că textul rămâne adevărat.

Notă: materialul descrie metoda de construire a documentului și temeiurile aplicabile, nu ține loc de consultanță juridică. Contractele complexe, sectoarele reglementate și vânzările transfrontaliere cer analiză dedicată.

Un T&C bun se citește ca un test de acceptanță scris în limbaj natural: fiecare propoziție, o afirmație verificabilă despre sistem. Cine îl parcurge cu produsul deschis alături ar trebui să găsească, de fiecare dată, comportamentul descris — iar unde nu îl găsește, are deja lista de reparat.

Restul obligațiilor care cad pe un site comercial sunt strânse în conformitate legală web. Pentru cum se construiesc produsele care generează clauzele astea, de la arhitectură la facturare, materialele stau pe hub-ul SaaS.