NDA IT projektui: 8 privalomi elementai ir dažniausios klaidos (2026)

Standartinė verslo NDA buvo sukurta bendroms verslo deryboms apsaugoti: klientų sąrašams, kainų politikai, verslo planams. IT projekte konfidenciali informacija yra iš esmės kitokia prigimties. Source code yra funkcinis produktas, ne tik dokumentas — jį nukopijuoti ir perpanaudoti techniškai nesunku. Technologijų stack atskleidžia architekturinius sprendimus, kuriuos konkurentas gali atkurti; API raktai suteikia tiesioginę prieigą prie mokamų trečiųjų šalių paslaugų. Klientų duomenų bazė, kurią pasiekia developer'is, dažnai yra vertingiausia verslo informacija. Be to, IT projektuose abi šalys paprastai ateina su savo pre-existing IP: rangovas turi bibliotekas ir framework'us, užsakovas turi verslo algoritmus. Bendra NDA šių kategorijų neatskiria — ginčo atveju tai sukuria teisinę spragą. IT NDA turi tiksliai apibrėžti kiekvieną informacijos kategoriją atskirai, nustatyti skirtingus terminus ir skirtingas grąžinimo procedūras kiekvienai iš jų.

Pirmasis ir svarbiausias IT NDA elementas — tikslus konfidencialios informacijos apibrėžimas pagal kategorijas. Pagal CK 1.116 str. komercinė paslaptis turi turėti komercinę vertę ir būti saugoma nuo atskleidimo. IT kontekste rekomenduojama apibrėžti atskirai: (a) source code — tiek galutinis produktas, tiek tarpiniai sprendimai ir kodo peržiūros; (b) technologijų stack ir sistemos architektūra; (c) API raktai, slaptažodžiai, infrastruktūros prieigos duomenys; (d) klientų ir vartotojų duomenys, kuriuos IT komanda pasiekia darbo eigoje; (e) verslo procesai ir know-how, kurie automatizuojami projekto metu. Svarbu nurodyti, ar informacija turi būti pažymėta „Konfidencialu", ar visi perduoti techniniai dokumentai automatiškai konfidencialūs. Per platus apibrėžimas — „visa informacija, kuria keičiamasi" — teisme yra ginčytinas. Kiekvieną kategoriją įrašykite su konkrečiais pavyzdžiais ir aiškiomis išimtimis (viešai prieinama informacija, informacija, kurią gavėjas jau turėjo iki sutarties).

Viena dažniausių IT NDA spragų — neatskirtas pre-existing IP, t. y. technologijos, kurias kiekviena šalis turėjo iki projekto pradžios. Developer'is dažnai naudoja savo bibliotekas, boilerplate šablonus, testavimo įrankius — tai yra jo intelektinė nuosavybė, ne kliento. Pagal ATGTĮ 9 str. kūrinio turtinės teisės priklauso kūrėjui, nebent sutartyje aiškiai numatyta kitaip. IT NDA turi aiškiai nurodyti: (1) kokios developer'io technologijos laikomos jo pre-existing IP ir lieka jo nuosavybe po projekto; (2) kokias teises klientas gauna naudoti šias technologijas projekte ir po jo — naudojimo licencija ar visiškas nuosavybės perdavimas; (3) ar klientas gali modifikuoti rangovo bibliotekas savarankiškai po projekto pabaigos. Be šio atskyrimo projekto pabaigoje dažnai kyla ginčas: ar source code visiškai perduotas klientui, ar jame yra rangovo proprietary komponentų, kuriuos klientas neturi teisės naudoti toliau be papildomo licencijavimo.

IT industrijoje standartinis 2–3 metų konfidencialumo terminas dažnai yra per trumpas. Programinės įrangos produktai gali išlikti rinkoje 5–10 metų; algoritmai ir architektūriniai sprendimai — dar ilgiau. Lietuvos komercinės paslapties įstatymas nenustato maksimalaus termino, todėl IT NDA terminas turi būti grindžiamas informacijos pobūdžiu: source code ir architektūriniai sprendimai — rekomenduojama 7–10 metų; API raktai ir infrastruktūros prieigos — iki jų pakeitimo (ne ilgiau kaip 90 dienų po projekto pabaigos); klientų asmens duomenys — pagal BDAR nustatytą saugojimo laikotarpį. Svarbu nurodyti, ar terminas skaičiuojamas nuo sutarties pasirašymo, nuo informacijos perdavimo, ar nuo projekto pabaigos — kiekvienam informacijos tipui gali būti skirtinga pradžios data. Neapibrėžtas arba „neribotas" terminas gali teisme būti sumažintas kaip neproporcingas laisvos konkurencijos ribojimas.

IT NDA be konkrečios sankcijų sumos yra silpna. Net jei pažeidimas akivaizdus, be netesybų sąlygos teisme teks įrodinėti realią žalą — o IT IP žalos vertinimas reikalauja eksperto, procesas gali trukti metus. Pagal CK 6.245 str. žalos atlyginimas apima tiesioginius nuostolius ir negautas pajamas, tačiau jų įvertinimas IT srityje yra kompleksiškas. Rekomenduojama įtraukti: (1) fiksuotą baudą už kiekvieną pažeidimo atvejį — 10 000–50 000 EUR SMB segmentui, priklausomai nuo projekto vertės; (2) teismo draudimo (injunction) galimybę — sustabdyti pažeidimą dar iki galutinio teismo sprendimo; (3) papildomo žalos atlyginimo galimybę, kai reali žala viršija netesybas. Teismai pagal CK 6.258 str. 3 d. gali mažinti neproporcingas netesybas, todėl suma turi būti pagrįsta projekto verte ir informacijos jautrumo laipsniu — ne arbitraliai didelė skaičius.

Tiekėjas dažnai dirba ne vienas: gali turėti juniorų komandą, pasitelkti testuotojus arba naudoti offshore developer'ius per platformas. Jei NDA nutyli apie subrangovus, susidaro rimta teisinė skylė — tiekėjas pasirašo NDA, o jo subrangovas, neturintis jokio konfidencialumo įsipareigojimo, pasiekia jūsų source code ir klientų duomenis. IT NDA privalo numatyti: (1) draudimą subnuomoti darbą be išankstinio raštiško kliento sutikimo arba aiškų patvirtintų subrangovų sąrašą sutarties priedu; (2) pareigą tiekėjui su kiekvienu subrangovu sudaryti konfidencialumo sutartį tokiomis pat arba griežtesnėmis sąlygomis; (3) tiekėjo atsakomybę už subrangovo pažeidimus — tiekėjas atsako solidariai kaip už savo pažeidimą. Pagal CK 6.709 str. šalys gali laisvai susitarti dėl atsakomybės pasiskirstymo, tačiau be aiškios nuostatos šią atsakomybę teisme bus sunku įrodyti.

Projekto pabaigoje IT rangovas turi turėti aiškius nurodymus dėl konfidencialios informacijos grąžinimo ar sunaikinimo. Standartinė formuluotė „sunaikina visus dokumentus po projekto" yra nepakankamai tiksli. Rekomenduojama nurodyti konkrečias procedūras: (1) source code repository — GitHub arba GitLab projekto perdavimas klientui per 7 dienas po projekto pabaigos, rangovas pašalinamas iš prieigos raštu; (2) API raktai ir slaptažodžiai — pakeičiami per 7 dienas, rangovas raštu patvirtina senus raktus ištrynęs iš visų darbo sistemų; (3) klientų duomenų kopijos — sunaikinamos per 30 dienų, rangovas pateikia rašytinį sunaikinimo aktą pagal CK 6.38 str.; (4) backup kopijos ir lokali kūrimo aplinka — aiškiai nustatyta, kas atsakingas ir per kiek laiko jas ištrinti. Be šios procedūros konfidenciali informacija gali likti rangovo darbo kompiuteriuose ir cloud backup'uose metų metus po projekto pabaigos.

Tarptautinio IT projekto atveju — kai rangovas yra iš kitos ES šalies ar trečiosios šalies — jurisdikcija ir taikoma teisė yra kritiniai klausimai. Lietuva aktyviai naudoja IT outsourcing'ą iš Ukrainos, Lenkijos, Indijos ir kitų šalių, todėl IT NDA privalo aiškiai nurodyti: (1) taikytiną teisę — Lietuvos Respublikos teisė pagal CK 1.37 str.; (2) ginčų sprendimo vieta — Lietuvos teismai arba tarptautinė arbitražo institucija (Vilniaus komercinis arbitražas arba ICC); (3) ginčų nagrinėjimo kalba. Arbitražas dažnai greitesnis nei teismo procesas ir išsaugo ginčo konfidencialumą — tai ypač svarbu IT sektoriuje, kur viešas bylinėjimasis dažniausiai kenkia abiem pusėms. Pasirinkus arbitražą, svarbu nurodyti konkretų reglamentą ir arbitrų skaičių, ne tik bendrą frazę „ginčai sprendžiami arbitražu".

Kai IT komanda pasiekia klientų asmens duomenis — vartotojų duomenų bazę, el. pašto adresus, mokėjimų informaciją — NDA vienos nepakanka. Pagal BDAR 28 str. privaloma sudaryti atskirą duomenų tvarkymo sutartį (DPA), kurioje nurodoma: duomenų tvarkymo tikslas ir apimtis, techninės saugumo priemonės (šifravimas, prieigos kontrolė), subtvarkymo taisyklės (ar developer'is gali naudoti offshore serverius), duomenų grąžinimo arba sunaikinimo tvarka po projekto. DPA ir NDA gali būti viename dokumente — NDA kaip pagrindinė sutartis, DPA kaip priedas. Praktinė rekomendacija: net jei duomenų tvarkymas minimalus, pridėkite DPA priedą — tai paprasčiau, nei vėliau aiškintis VDAI, kodėl jo nebuvo. VDAI baudos už DPA nebuvimą gali siekti iki 20 000 000 EUR. Plačiau apie IT paslaugų sutarčių DPA sąlygas galite paskaityti IT paslaugų sutarties straipsnyje.

(1) Per platus konfidencialumo apibrėžimas — formuluotė „visa informacija, kuria keičiamasi" teisme retai gynama, nes apima ir viešai žinomą informaciją bei developer'io standartines žinias. (2) Pre-existing IP neatskyrimas — projekto pabaigoje kyla ginčas: ar developer'is gali toliau naudoti savo bibliotekas, kurias įdiegė jūsų projekte pas kitą klientą. (3) Per trumpas terminas — 2 metai IT produktui, kuris rinkoje gyvena 7–10 metų, yra akivaizdžiai nepagrįstas. (4) Subrangovai nepaminėti — tiekėjas naudoja offshore developer'į, kuris nesurištas NDA; informacija nuteka be teisinės atsakomybės. (5) Grąžinimo tvarka be konkretaus termino — „sunaikinti po projekto" be aiškaus laiko ir patvirtinimo procedūros sukuria ilgalaikę apsaugos spragą. (6) Nėra sankcijų sumos — NDA be netesybų yra tik moralinis įsipareigojimas; IT IP žalos įrodinėjimas teisme be iš anksto nustatytos baudos trunka ilgai ir kainuoja neproporcingai brangiai. Kiekviena iš šių klaidų buvo realių ginčų pagrindas.

K: Kada pasirašyti NDA — prieš pirmuosius pokalbius ar tik prieš techninį briefą? A: Prieš bet kokius techninius pokalbius, kur kalbama apie sistemos architektūrą ar technologijų stack. Paprasti kontaktai be techninės informacijos NDA nereikalauja, tačiau kai pereinate prie produkto detalių — NDA turi būti pasirašyta pirmiau, ne po. K: Ar pakanka anglakalbės NDA su Lietuvos rangovu? A: Teisiškai galioja, tačiau ginčo atveju Lietuvos teismas gali reikalauti oficialaus vertimo. Jei abiejų šalių anglų kalbos supratimas abejotinas, lietuviška sutartis sumažina interpretacijos riziką. K: Kiek kainuoja IT NDA su source code priedu? A: Standartinė IT NDA su technologijų priedu kainuoja 300–800 EUR pas specializuotą IT teisę išmanantį advokatą. Šablonas be individualizavimo gali kainuoti 100–200 EUR, tačiau kelia pre-existing IP ir subrangovų rizikas. Alternatyva — pradėti nuo patikrinto šablono ir palyginti jį su DI analizatoriumi prieš pasirašant.