Contractele IT au între 10 și 40 de pagini. Nimeni nu le citește integral — nici tu, nici furnizorul. Rezultatul: disputele mari apar exact pe clauzele pe care le-a sărit toată lumea. Iată cele 9 clauze care produc 80% din conflictele reale, cu formularea de verificat și cu semnalul de alarmă.
1. Definiția livrabilului
De 3 ori din 4, conflictul pe „am livrat sau nu” vine din definiții vagi. „Modulul de raportare” nu e un livrabil, e o direcție. Livrabilul e: „Modulul de raportare care include rapoartele X, Y, Z, cu filtrele A și B, exportabile în Excel și PDF, accesibil de rolurile de manager și contabil.”
Verifică: fiecare livrabil are un criteriu de acceptanță testabil — ce anume trebuie să se întâmple ca să spunem „da, e gata”. Fără asta, acceptarea e subiectivă.
2. Change requests — cine decide ce e change
Aproape sigur va apărea: „dar asta nu era în scope”. Problema e că scope-ul inițial n-a fost suficient de detaliat și fiecare parte va interpreta în favoarea lui.
Verifică: există un proces documentat pentru change requests — cine le documentează, cine le estimează, cât timp durează aprobarea, ce se întâmplă dacă nu există acord. Absența acestui proces e red flag.
3. Proprietatea intelectuală
Cine deține codul la sfârșit? Pare evident (tu, clientul), dar contractele standard ale multor firme de software spun altceva în litere mici.
Verifică: clauza spune explicit „Clientul deține integral toate drepturile de proprietate intelectuală asupra codului, designului, și documentației produse în cadrul proiectului.” Dacă e formulată ca „licență perpetuă”, nu e suficient — nu poți modifica și redistribui liber.
Excepție legitimă: biblioteci interne preexistente ale furnizorului, pe care le licențiază cu drept de utilizare perpetuu. Trebuie listate explicit.
4. Access la cod pe parcursul proiectului
Dacă furnizorul îți dă codul doar „la final”, pierzi capacitatea de audit pe parcurs, nu poți verifica progresul real, și ești în poziție slabă dacă relația se rupe.
Verifică: ai acces la repository (GitHub, GitLab, Bitbucket) de la începutul proiectului, cu rol de observator sau administrator. Commit-urile se fac direct acolo, nu „se livrează zipul la final”.
5. SLA pe mentenanță
„Răspundem rapid la probleme” nu e SLA. Un SLA real are numere.
Verifică formulări ca: „Incident P1 (sistem inaccesibil): răspuns inițial în 2h lucrătoare, remediere temporară în 8h, remediere permanentă în 72h.” Fără ore explicite, nu e SLA.
Atenție la: ce contează „ore lucrătoare” — 8-17 luni-vineri e diferit de 24/7. Penalizările pentru nerespectare trebuie specificate.
6. Rezilierea contractului
Cum ieși din contract dacă relația nu merge? E prima întrebare pe care trebuie să o pui, pentru că e momentul în care ai cel mai puțin leverage.
Verifică: ambele părți pot rezilia cu preaviz rezonabil (30-90 zile), plata se face pro-rata pentru munca livrată până la acel moment, se predă tot materialul (cod, documentație, credentiale) într-un termen specificat.
Red flag: clauze care cer penalizări mari pentru rezilierea timpurie din partea ta, sau care cer plata integrală a contractului inițial.
7. Confidențialitate și date
Verifică: NDA separat sau clauză dedicată, cu durată care supraviețuiește rezilierii (minim 3 ani). Acoperă date de business, date personale, cod, documentație.
Pentru GDPR: dacă furnizorul procesează date personale ale tale, ai nevoie de DPA (Data Processing Agreement) separat, nu doar NDA.
8. Garanție post-livrare
După go-live, câte zile ai garanție pe bug fix gratuit?
Standard rezonabil: 30-90 zile de bug fixing gratuit (problemele existente la momentul livrării), apoi intră în regim de mentenanță paid.
Distincție importantă: bug (eroare de implementare vs. specificație) vs. feature request (funcționalitate nouă dorită). Contractul trebuie să definească cum se face distincția.
9. Limitarea răspunderii
Dacă un bug din codul lor provoacă o pierdere de 200.000 EUR pentru tine, care e responsabilitatea furnizorului?
Formularea tipică: răspunderea furnizorului e limitată la valoarea contractului (sau un multiplu). E standard în industrie, acceptabil.
Red flag: exclusii totale de responsabilitate („furnizorul nu răspunde pentru niciun tip de daune”). Nelegal în majoritatea jurisdicțiilor, dar unii îl strecoară.
Rezumat: cele 3 lucruri non-negociabile
Clauza | Poziția ta fermă |
IP | Cod, design, documentație — 100% ale tale, fără ambiguitate |
Access repository | Din prima zi, rol de owner |
Reziliere | Posibilă cu preaviz de 30-90 zile, fără penalități disproporționate |
Ce facem la Skyvertex
Contractul nostru standard include din oficiu toate cele 9 puncte de mai sus, formulate în favoarea clientului (IP complet al tău, access de owner la repo din prima zi, reziliere cu 30 de zile, SLA cu numere). Nu negociem aceste puncte în defavoarea clientului — sunt parte din cum facem business. Ce negociem sunt: prețul, durata, volumul de ore pe mentenanță.
Ai un contract de furnizor IT în evaluare și vrei o review pe clauzele critice? Hai să vorbim fără obligație. → skyvertex.ro/contact
Întrebări frecvente (FAQ)
Trebuie să am avocat pentru un contract IT de 50.000 EUR?
Pentru primul contract cu un furnizor — da, chiar și o ora de consultanță juridică te protejează. Pentru contracte ulterioare cu același furnizor pe termen de referință — nu neapărat.
Pot modifica contractul lor standard?
Da. Orice furnizor serios acceptă modificări rezonabile. Dacă refuză, e un semnal.
E ok să plătesc în avans?
Avans rezonabil (15-30%) e normal. 50% sau mai mult — atenție, ești în poziție slabă dacă relația nu merge.
Cine plătește pentru bug-uri descoperite la 6 luni post-go-live?
Dacă e clar bug de implementare (nu feature nou), în perioada de garanție — furnizorul. După garanție — intră în mentenanță sau e plătit la oră.