Civilinė byla Nr. e2-201-425/2026. 

    Teisminio proceso Nr. 2-55-3-00271-2026-5.
      Procesinio sprendimo kategorija 3.1.18.2.6

 (S)

PANEVĖŽIO APYGARDOS TEISMAS

LIETUVOS RESPUBLIKOS VARDU

SPRENDIMAS

2026 m. gegužės 11 d. 

Panevėžys

Panevėžio apygardos teismo Civilinių bylų skyriaus teisėja Laimantas Misiūnas,

veikdamas Vilniaus apygardos teismo vardu, 

         viešame teismo posėdyje rašytinio proceso tvarka išnagrinėjo civilinę bylą pagal ieškovės UAB „Blue Bridge MSP“ (toliau – ir Ieškovas) ieškinį atsakovui VĮ Registrų centras (toliau – ir Atsakovas, Perkančioji organizacija), trečiasis asmuo atsakovės pusėje UAB „Novian Technologies“ (toliau – ir trečiasis asmuo) dėl Atsakovo priimto Sprendimo viešajame tarptautiniame pirkime „ESPBI IS modernizavimo (dekomponavimo) projekto programinės įrangos ir programinės įrangos konfigūravimo paslaugų pirkimas (Pirkimo Nr. (duomenys neskelbtini)) panaikinimo.

 Teismas

n u s t a t ė:

1. Panevėžio apygardos teisme 2026-03-09 priimtas Ieškovo UAB „Blue Bridge MSP“ ieškinys, kuriuo prašoma teismą:

1.

1.2.taikyti laikinąsias apsaugos priemones: sustabdyti viešojo tarptautinio pirkimo „ESPBI IS modernizavimo (dekomponavimo) projekto programinė įranga ir programinės įrangos konfigūravimo paslaugos“ (pirkimo Nr. (duomenys neskelbtini)) procedūras (teismas 2026-03-09 nutartimi prašymą tenkinto, sustabdė viešąjį tarptautinį pirkimą);

1.3. įpareigoji Atsakovą Valstybės įmonę Registrų centrą nesudaryti viešojo pirkimo sutarties su UAB „Novian Pro“;

1.4. Ieškovo naudai iš Atsakovo priteisti visas bylinėjimosi išlaidas, kurias pagrindžiantys dokumentai bus pateikti vėliau.

2.  Ieškovas ieškinį argumentuoja sekančiais pagrindiniais motyvais:

2.1. Atsakovas nepagrįstai plečiamai aiškina Techninės specifikacijos (toliau – TS) 17.7 punkte numatytus reikalavimus, kadangi minėtame punkte nėra pateikta jokių reikalavimų aplikacijų jautrios informacijos saugojimo priemonei. Ieškovas teigia, kad Pirkimo TS nenustatė papildomų reikalavimų jautrios informacijos saugojimo priemonėms, nes TS 17. p. yra aptarti papildomi konteinerizacijos platformos valdymo komponentai, skirti Pirkime siekiamo įsigyti sprendimo funkcionalumui užtikrinti, kurie turi būti sudiegti Perkančiosios organizacijos virtualizacijos platformoje. Konkrečiai 17.7. p. nustato, kad virtualizacijos platformoje turi būti sudiegtas papildomas komponentas: Aplikacijų jautrios informacijos saugojimo priemonės (angl. secret store/vault);

2.2. Reikalavimas dėl jautrios informacijos saugojimo atskiroje, nuo platformos izoliuotoje, saugykloje nebuvo numatytas nei TS reikalavimuose, nei Platformos komponentų architektūros schemoje, pateiktoje TS 1 paveikslėlyje. Pirkimo sąlygose nėra nustatyti jokie papildomi reikalavimai nei tokioms informacijos saugojimo priemonėms (techniniai, teisiniai, funkciniai ir pan.), nei tokių priemonių veikimo principams ar algoritmams, nei jokie kiti reikalavimai TS apskritai nėra nustatyti. Perkančioji organizacija Pirkimo dokumentuose nelaikė esant reikalinga nustatyti detalesnių reikalavimų tokiai priemonei, jos veikimo principams ar kitoms savybėms;

2.3. Ieškovas pirkimui pasiūlė integruotą jautrių duomenų saugojimo sprendimą, kuris atitinka visas geriausias praktikas (TS 12 ir 13 p.) ir tai patvirtina Ieškovo pasiūlyto sprendimo - Red Hat Ansible Automation Platform (toliau – ir Programinė įranga) oficiali dokumentacija. Atsakovas Sprendime atmesti Ieškovo pasiūlymą abstrakčiai nurodo, kad Ieškovo siūloma Programinė įranga neatitinka geriausių saugos praktikų, tačiau nepateikia jokių nuorodų į TS 12 punktą. Ieškovas teigia, kad tiek Ieškovas, tiek ir Pirkimo laimėtoju pripažintas Trečiasis asmuo visiems TS 17 p. aptartiems papildomiems komponentams pasiūlė identiškus sprendimus, išskyrus 17.7. p. aptartoms saugojimo priemonėms;

2.4. Ieškovas teigia, kad atsakovas nepagrįstai sutapatino TS 17 p. sąvoką „papildomas komponentas“ su sąvoka „atskiras komponentas“. Ieškovo pasiūlytas sprendimas (Programinė įranga) iš esmės yra identiškas Trečiojo asmens pasiūlymui (6 iš 7 siūlomų sprendinių sutampa), kuris buvo pripažintas Pirkimo laimėtoju, todėl tai parodo, kad Atsakovas Ieškovo pasiūlymus vertino pažeisdamas nediskriminavimo principą (Ieškinio 43-53 p.);

2.5. Techninės specifikacijos 17.7 p. pateiktos sąvokos „secret store“ (jautrios informacijos saugojimas savyje) ir „secret vault“ (jautrios informacijos saugojimas išorinėje saugykloje) turi būti aiškinamos kaip alternatyva, kas turi būti suprantama, kad Ieškovo pasiūlyta Programinė įranga, kuri turi vidinę duomenų saugyklą savyje (angl. secret store), atitinka ir geriausias saugumo praktikas, tuo pačiu ir TS 12-13 punktus. Be to, Atsakovas, vertindamas Ieškovo pasiūlymą, padarė esminį pažeidimą, nes vertino ne tai, ar Ieškovo pasiūlytas komponentas atlieka jautrių duomenų saugojimo funkciją (t. y. ar atitinka TS 17.7 p.), o tai, kaip jis ją atlieka, t. y. vertino reikalavimus, kurie nebuvo apibrėžti TS 17.7 p.;

2.6. Atsakovas TS 17.7 p. nustatė tik vieną kertinį reikalavimą –  Aplikacijų jautrios informacijos saugojimo priemonės (angl. secret store/vault), t.y.: vidinėje saugykloje (angl. secret store) arba išorinėje saugykloje (angl. secret vault). TS 22.8 p. yra skirtas apibrėžti tik konteinerizavimo platformai taikomus reikalavimus. Tarp šių TS 17.7 p. ir 22.8 p. reikalavimų nėra tarpusavio sąsajų, kadangi šie reikalavimai yra nurodyti skirtinguose TS skyriuose, todėl  Ieškovo pasiūlymas, kaip neatitinkantis TS 22.8 p., buvo atmestas visiškai nepagrįstai. Atsakovas nepagrįstai sieja TS 17.7. p. su TS 22.8. p. reikalavimais, kurie taikomi išimtinai konteinerizacijos platformai, o ne konteinerizacijos platformos valdymo ar automatizavimo įrankiams. TS 17.7. p., priešingai nei Sprendime nurodo Atsakovas, nustato vieną kertinį reikalavimą - informacijos saugojimą vidinėje secret store arba išorinėje secret vault saugykloje. Tuo tarpu TS 22.8. yra skirtas apibrėžti tik konteinerizavimo platformai taikomus reikalavimus. Ieškovo manymu, tai akivaizdžiai patvirtina, kad tarp TS 17.7. p. ir TS 22.8. p. reikalavimų nėra tarpusavio sąsajų;

2.7. Ieškovas teigia, kad jo pasiūlyta Programinė įranga apima visus TS aptartus funkcionalumus, įskaitant ir jautrių duomenų saugojimo vidinėje saugykloje - secret store. Konkrečiai Tiekėjo pasiūlyto sprendimo dalis - Ansible Vault ir Red Hat Ansible Automation Platform Automation Controller programinė įranga, užtikrinanti konteinerizacijos platformos valdymo funkcionalumą, atskirai nėra licencijuojama. Ši programinė įranga yra pagrindinė siūlomos Programinės įrangos licencijos dalis. Atsižvelgiant į tai, Atsakovo nurodomas trūkumas bet kuriuo atveju yra laikytinas visiškai nepagrįstu ir negali būti vertinamas kaip teisėtas pagrindas atmesti Ieškovo pasiūlymą. Ieškovas daro išvadą, kad jo pasiūlymas visiškai atitinka TS 17.7. bei 22.8. punktų reikalavimus.

3. Atsakovas procesiniuose dokumentuose prašė teismą civilinę bylą pagal pareikštą Ieškovo ieškinį nutraukti, o teismui šio prašymo netenkinus, Ieškovo ieškinį atmesti kaip nepagrįstą ir Atsakovo naudai priteisti visas patirtas bylinėjimosi išlaidas (žyminis mokestis už sumokėtą atskirąjį skundą dėl Panevėžio apygardos teismo 2026-03-09 nutarties dėl laikinųjų apsaugos priemonių taikymo);

3.1. Atsakovas atsiliepime nurodė, kad visiškai nesutinka su Ieškovo ginčo situacijos vertinimu bei Ieškinyje dėstoma Ieškovo pozicija, kadangi ji grindžiama ne sisteminiu Pirkimo dokumentų vertinimu, o fragmentiška atskirų nuostatų ir techninių reikalavimų analize, subjektyviu Pirkimo sąlygose nurodytų sąvokų bei schemų aiškinimu, tokiu būdu bandant paneigti aiškiai Pirkimo sąlygose nurodytą Perkančiosios organizacijos valią dėl Pirkimo objekto;

3.2. Techninės specifikacijos 17 punkte nurodyta, kad sprendimo funkcionalumui užtikrinti, Perkančiosios organizacijos virtualizacijos platformoje turi būti sudiegti papildomi konteinerizacijos platformos valdymo komponentai: Git tipo pirminio kodo valdymo sistema (17.1. papunktis); Automatizuoto infrastruktūros diegimo ir valdymo sistema (17.2. papunktis); Konteinerio atvaizdų (angl. container image) registras (17.3. papunktis); Aplikacijų tiekimo grandinės patikros įrankiai (17.4. papunktis); Aplikacijų nuolatinio integravimo, pateikimo ir diegimo (CI/CD) įrankiai (17.5. papunktis); Privilegijuotų paskyrų prieigos valdymo sistemos (17.6. papunktis); Aplikacijų jautrios informacijos saugojimo priemonės (angl. secret store / vault) (17.7. papunktis). Vertinant Techninės specifikacijos 17.7. papunkčio nuostatas jų įgyvendinimo aspektu, šiuo atveju vertintinos visos Pirkimo sąlygos kaip visuma;

3.3. Specialiųjų sąlygų 2.2. papunkčiu, pirkimo objektas yra sprendimas, kuris diegiamas kompleksinėje aplinkoje, integruojant daug skirtingų komponentų, kurie turi būti visiškai suderinami tarpusavyje, kad būtų pasiekti projekto tikslai - pilnai automatizuotai diegiama, vystoma, prižiūrima ir saugi E.sveikatos paslauga, kurios platforma buvo perkama kaip vientisas sprendimas, o ne kaip skirtingų komponentų rinkiniai, tokiu būdu užtikrinant, kad vienas tiekėjas yra atsakingas už visos sistemos veikimą, stabilumą ir palaikymą, todėl schema ir atspindi Pirkimo objektą kaip perkamą vientisą sprendimą; 

3.4. Atsakovas teigia, kad Tiekėjas Ieškovas yra profesionalus ir nuolatinis viešųjų pirkimų dalyvis, todėl iš Techninės specifikacijos reikalavimų, įskaitant pateiktą architektūrinę schemą, jam turėjo būti aiškiai ir nedviprasmiškai suprantama, jog papildomas valdymo komponentas „Aplikacijų jautrios informacijos saugojimo priemonė (angl. secret store / vault)" privalo būti įgyvendinamas kaip atskiras diegiamas komponentas, o ne kaip integruota ar vidinė kitos sistemos funkcija. Tokia išvada kyla tiek iš pačios sąvokos turinio, tiek iš rinkos standartų, kurie „secret store / vault" apibrėžia kaip atskirą jautrios informacijos saugyklą;

3.5. Išanalizavus Tiekėjo Ieškovo pateiktą pasiūlymą ir jame nurodytus komponentus nustatyta, kad Ieškovo minima programinė įranga valdo jautrią informaciją, operuoja ja, tačiau nesaugo jautrios informacijos - neturi saugyklos (angl.Vault) funkcionalumo, o saugojimui naudoja išorines saugyklas (taip pat turi šifravimo funkcionalumą, kuri padeda apsaugoti jautrią informaciją). Nepaisant to, kad pasiūlytos programinės įrangos pavadinimas Ansible Vault, kuris turi žodį "Vault" pavadinime, tačiau tai nereiškia, kad ji savyje turi specializuotas saugyklas jautriai informacijai saugoti;

3.6. Atsakovas nepagrįstai traktuoja nesant Techninės specifikacijos 17.7. papunkčio nuostatų ryšio su Techninės specifikacijos 22.8. papunkčio nuostatomis. Atsakovas paaiškino, kad vertinant sistemiškai Techninės specifikacijos 17.7. papunktį ir 22.8. papunktį akivaizdu, kad šios nuostatos reglamentuoja viena kitos papildančius sprendimo įgyvendinimo etapus. Techninės specifikacijos 17.7. papunktis nustato, kas turi būti įdiegta ir kokius kriterijus turi atitikti sprendimas, o Techninės specifikacijos 22.8. papunktis detalizuoja, kaip ši infrastruktūra turi būti diegiama ir valdoma - užtikrinant automatizavimą, atsekamumą ir valdymo kontrolę per visą gyvavimo ciklą. Techninės specifikacijos 22.8. papunktis yra būtinas technologinis ir funkcinis mechanizmas, leidžiantis realiai įgyvendinti Techninės specifikacijos 17.7 papunktyje nustatytus reikalavimus. Konteinerizavimo platformoje bus saugomos aplikacijos, kurios saugos savo jautrią informaciją Techninės specifikacijos 17.7. papunktyje nurodomose priemonėse. Atsakovas teigia, kad Tiekėjas Ieškovas savo pasiūlyme neužtikrino Techninės specifikacijos 17.7. papunkčio reikalaujamo papildomo valdymo komponento, todėl atitinkamai nėra galimybės valdyti aplikacijų konfigūracijos - jautrios informacijos saugojimo kontekste. Atsakovas teigia, kad nepagrįsti Tiekėjo Ieškovo argumentai, kad Pirkimo dokumentai nenustato jokių tarpusavio sąsajų tarp Techninės specifikacijos 17.7. papunktyje nurodyto jautrios informacijos saugojimo komponento ir Techninės specifikacijos 22.8. papunktyje numatyto automatizuoto konfigūracijos valdymo funkcionalumo, kadangi tokia išvada grindžiami pernelyg siauru bei pavieniu Techninės specifikacijos nuostatų aiškinimu.

3.7. Pagal nuosekliai suformuotą kasacinio teismo praktiką ieškinio reikalavimas dėl ieškovės pretenzijos atmetimo nėra savarankiškas reikalavimas ir dėl to nepatenka į bylos nagrinėjimo dalyką (žr., pvz., Lietuvos Aukščiausiojo Teismo 2014-10-03 nutartį civilinėje byloje Nr. 3K-3-411/2014, 2017-05-04 nutartį civilinėje byloje Nr. e3K-3-219-690/2017, 2018-10-04 nutartį civilinėje byloje Nr. e3K-3-343-690/2018, ir kt.). Nagrinėjamoje civilinėje byloje Ieškovė nereiškia iš esmės jokio reikalavimo panaikinti Perkančiosios organizacijos sprendimą, kuriuo būtų tiesiogiai pažeidžiamos Ieškovės teisės, o ginčija tik Perkančiosios organizacijos 2026-02-24 atsakymą į Tiekėjos 2026-02-13 pretenziją, kuris pats savaime nesukelia teisinių pasekmių Tiekėjos teisėms ir pareigoms, spręstina, jog pagal šiuo metu suformuluotą Ieškinio reikalavimą (dalyką) civilinė byla iš viso negali būti nagrinėjama Teisme ir civilinė byla turėtų būti nutraukta (Civilinio proceso kodekso 293 straipsnis).

4. Trečiasis asmuo UAB „Noviiom Technologies“ procesiniuose dokumentuose prašė atmesti Ieškovo ieškinį visa apimtimi, priteisti iš Ieškovo visas trečiojo asmens patirtas bylinėjimosi išlaidas, kurios bus patikslintos iki Bylos išnagrinėjimo iš esmės pabaigos.

4.1. Trečiasis asmuo procesiniuose dokumentuose teigia, kad nepagrįstas Ieškinio argumentas, kad Atsakovas nepagrįstai plečiamai aiškina Techninės specifikacijos 17.7 p. reikalavimus, teigdamas, kad minėtame punkte nėra pateikta jokių reikalavimų aplikacijų jautrios informacijos saugojimo priemonei, kad Atsakovas leido tiekėjams pasirinkti, kokioje saugykloje turės būti saugojama jautri informacija, kad reikalavimas siūlyti tokią programinę įrangą, kuri saugotų jautrią informaciją tik izoliuotoje duomenų saugykloje (angl. secret vault) nebuvo nustatytas TS 17.7 p, tuo pačiu Ieškovas be pagrindo daro išvadą, kad jo pasiūlyta ginčo pirkimui Programinė įranga atitinka TS 17.7 p. reikalavimus;

4.2. Trečiasis asmuo teigia, kad Atsakovas ginčo Pirkimu siekia įsigyti „ESPBI IS modernizavimo (dekomponavimo) projekto programinę įrangą ir programinės įrangos konfigūravimo paslaugas”, t. y. šio Pirkimo objektas - įdiegta platforma, kurioje bus modernizuojama E. Sveikata informacinė sistema, šią sistemą dekomponuojant į atskiras aplikacijas (programas) , kurių jautri informacija ir turės būti saugoma, valdoma ir pasiekiama iš jautrių duomenų saugyklos;

4.3. Pirkimo objektas yra itin kompleksiška, jautrių asmens duomenų saugojimo, apsikeitimo ir valdymo sistema, todėl, kaip numatyta TS 2 skyriaus 18.3 p., siūloma tiekėjų, įskaitant ir Ieškovo, Programinė įranga turi užtikrinti platformos saugumą ir vientisumą, taikant patikimas prieigos kontrolės priemones, šifravimą ir audito mechanizmus, siekiant apsaugoti jautrius duomenis ir išlaikyti visuomenės pasitikėjimą. TS keliami reikalavimai, visi be išimties yra keliami būtent šiai E. Sveikatai modernizuoti. Ir šie reikalavimai turi būti aiškinami ir taikomi sistemiškai, o ne atsietai vienas nuo kito, kaip kad Ieškinyje siekia parodyti Ieškovas;

4.4. Atsakovas TS 1.3 dalyje, be kita ko, kėlė tokius reikalavimus Pirkimo objektui, t. y. apibrėžė reikalingus sprendimus, kad aplikacijų veikimo tęstinumui ir saugumui užtikrinti planuojami tokie sprendimai: turėtų būti automatizuotai tikrinama pirminio kodo kokybė, aplikacijų pirminis kodas ir susiję objektai turėtų būti tikrinami dėl galimų pažeidžiamumų ir t.t. Atsakovas TS 17.7 p. numatė reikalavimą, pagal kurį turės būti įdiegta programinė įranga, skirta ir galinti užtikrinti jautrios informacijos valdymą ir saugojimą iš skirtingų programinių įrangų, t. y. visų platformoje, kurioje bus modernizuota E. Sveikatos sistema, veikiančių aplikacijų slaptų duomenų valdymo infrastruktūra (priemonės, komponentai). Tai, kad TS 17.7 p. apima jautrios informacijos (angl. secret /sensitive) saugojimą ir valdymą, patvirtina ir Atsakovo argumentai, nurodyti sprendime dėl Ieškovo pasiūlymo atmetimo (Ieškinio Priedas Nr.3);

4.5. Trečiasis asmuo paaiškino, kad jautri informacija (angl. secret /sensitive) šio ginčo kontekste reiškia programinių įrangų slaptų duomenų (pvz., slaptažodžių, API raktų, prieigos žetonų, sertifikatų ar kitų autentifikavimo kredencialų) saugojimą, saugų apsikeitimą ir valdymą. Būtent šiuo reikalavimu Atsakovas siekė, kad tiekėjų siūloma programinė įranga užtikrintų jautrios informacijos, tokios kaip slaptažodžiai, API raktai ir kt., saugojimą ir apsikeitimą su kitomis aplikacijomis (kitomis programinėmis įrangomis). Tačiau Ieškovo pasiūlyta Programinė įranga nėra skirta aplikacijų slaptažodžių saugojimui ir dalijimuisi tarp aplikacijų, t. y. Ieškovo Programinė įranga nėra skirta ir negali užtikrinti skirtingų aplikacijų slaptažodžių saugojimo ir apsikeitimo su kitomis aplikacijomis (programinėmis įrangomis). Tai patvirtina pačios Programinės įrangos gamintojas (Ištrauka iš Ieškovo pasiūlytos Programinės įrangos gamintojo viešai skelbiamos dokumentacijos anglų kalba, su vertimu į lietuvių kalbą);

4.6. Kaip matyti iš Ieškovo pasiūlytos Programinės įrangos gamintojo viešai skelbiamos informacijos ir paties gamintojo atsakymų į konkrečius klausimus, pats Programinės įrangos gamintojas nurodo skyriuose apie slaptažodžių valdymą (2.3.4 p. ir 13 skyrius), kad jo Programinė įranga tokios funkcijos neturi ir tam, kad būtų užtikrintas slaptažodžių saugojimas bei valdymas, t. y. keitimasis su kitomis aplikacijomis, turi būti naudojama kita išorinė sistema, t. y. kita programinė įranga, kuri tokį funkcionalumą turi;

4.7. Nors Ieškovo pasiūlyta Programinė įranga ir turi vidinį šifravimo mechanizmą savo konfigūraciniams duomenims (angl. credentials), kaip teigia pats Ieškovas Ieškinio 59 p., tačiau Ieškovo Programinė įranga yra skirta tik savo reikmėms, t. y. prisijungimo duomenys yra prienami tik pačios Programinės įrangos (Ansible) automatizacijos užduočių vykdymui, tačiau nepateikia prisijungimo duomenų (paslapčių, angl. secrets) kitoms aplikacijoms jų vykdymo metu (angl. runtime). Ieškovo pasiūlyta Programinė įranga yra automatizacijos įrankio vidinė konfigūracija, o ne paslauga, skirta kitoms aplikacijoms gauti, t. y. ji nėra skirta ir pritaikyta aplikacijų jautrios informacijos saugojimui ir neužtikrina slaptažodžių dalijimosi su kitomis aplikacijomis, programinėmis įrangomis, tokiomis kaip numatyta TS 1.2.3 p.;

4.8. Trečiasis asmuo pabrėžia, kad Ieškovo pasiūlyta Programinė įranga neatitinka ne tik Pirkimo sąlygų, bet ir Lietuvos Respublikos Vyriausybės 2018 m. rugpjūčio 13 d. nutarimo Nr. 818 „Dėl Lietuvos Respublikos kibernetinio saugumo įstatymo įgyvendinimo“ reikalavimų, kurie taikomi Atsakovui, kaip esminiam kibernetinio saugumo subjektui. LRV nutarimo priede „Kibernetinio saugumo reikalavimų aprašas“ 7 lentelės 76 p. yra numatyta, kad draudžiama saugoti aplikacijų sąsajas, raktus ir kitas paslaptis (angl. secrets) programiniame kode arba atskiruose failuose, kaip kad Ieškovas siūlo savo sprendime, kuriuos atskleidus gali būti pasinaudota prieiga prie įrenginių, resursų, paskyrų ar valdiklių: Papildomi atpažinties, tapatumo patvirtinimo ir naudojimosi kontrolės reikalavimai (kibernetinio saugumo subjekto svetainėms, pasiekiamoms.

4.9. Iš Ieškinyje pateiktų Ieškovo ir Trečiojo asmens pasiūlymų palyginimo nustatyta, kad  Trečiasis asmuo Pirkime pasiūlė tą pačią Programinę įrangą, siekdamas pagrįsti atitikimą TS 17.1-17.6 p. reikalavimams. Su tuo sutinka ir Ieškovas Ieškinio 51 p., išskirdamas, kad Trečiojo asmens ir Ieškovo pasiūlyta programinė įranga skiriasi tik dėl TS 17.7 p. Ieškovas pasiūlė Red Hat Ansible Automation Platform (t. y. programinę įrangą, kurios pats gamintojas patvirtina, kad ji neturi    aplikacijų jautrios informacijos saugojimo ir dalijimosi funkcionalumo), o Trečiasis asmuo pasiūlė kito gamintojo Infiscal Pro programinę įrangą, kuri tokį funkcionalumą turi;

4.10. Ieškovas pateikia subjektyvų, niekuo nepagrįstą TS 17.7 p. reikalavimo interpretavimą ir aiškinimą, kad Atsakovas nei Pirkimo sąlygose, nei jų prieduose niekur nenurodė ir neapibrėžė, kad angliškas terminas „secret store“ reiškia būtent vidinę saugyklą, o angliškas terminas „secret vault“ reiškia išorinę saugyklą. Ši interpretacija bei TS 17.7 p. plečiamasis aiškinimas yra paties Ieškovo deklaratyvi nuomonė, kuri nepagrįsta ir neįrodyta jokiais konkrečiais įrodymais;

5. Ieškovas teismui pateiktame dublike nurodė, kad Atsakovas Ieškovo pasiūlymui iškėlė reikalavimus, kurie jokia forma nebuvo aptarti TS. Trečiasis asmuo savo atsiliepime taip pat pateikia reikalavimus, kurie jokiu būdu nekyla iš TS turinio. Lietuvos apeliacinis teismas savo praktikoje yra konstatavęs, kad techninė specifikacija, kaip esminė viešojo pirkimo dokumentacijos dalis, detaliai reglamentuojama VPĮ 37 straipsnyje, kuris įpareigoja perkančiąją organizaciją aiškiai ir tiksliai nustatyti pirkimo objektui keliamus reikalavimus. Šie reikalavimai būtini siekiant užtikrinti, kad įsigyjamos prekės, paslaugos ar darbai atitiktų perkančiosios organizacijos poreikius, būtų tinkamos kokybės ir atitiktų viešojo intereso principus.  Atsakovas ir Trečiasis asmuo savo atsiliepimuose ir toliau remiasi TS neįtvirtintais reikalavimais, kuriuos išpildo Trečiojo asmens Pirkime pateiktas pasiūlymas, tačiau kurie jokia forma nėra įtvirtinti nei TS, nei kituose Pirkimo dokumentuose. Ieškovas daro išvadą, kad Atsakovas ir toliau siekia pakeisti Pirkimo sąlygas jau pasibaigus pasiūlymų pateikimo terminui, kas pagal kasacinio teismo praktiką yra negalima. Trečiasis asmuo nepagrįstai teigia, kad Ieškovo siūlomas sprendimas pirkime neva nėra skirtas ir negali užtikrinti aplikacijų slaptažodžių saugojimo ir nėra skirtas ir negali užtikrinti aplikacijų slaptažodžių apsikeitimo su kitomis aplikacijomis (programinėmis įrangomis);

5.2. Ieškovas teigia, kad jo siūlomas sprendimas atlieka slaptažodžiu saugojimo funkciją ir tai patvirtina Ieškovo siūlomos programinės įrangos gamintojo oficiali dokumentacija, kurioje nurodoma, kad slapti prisijungimo duomenys, tokie kaip SSH slaptažodžiai, SSH privatūs raktai ir debesų paslaugų API prieigos raktai, duomenų bazėje saugomi užšifruoti. Pats Atsakovas 2026-02-24 priimtame savo sprendime bei 2026-02-05 per CVP IS sistemą Ieškovui pateiktame pranešime „Dėl pasiūlymo atmetimo“ aiškiai ir nedviprasmiškai patvirtino, kad Ieškovo siūlomas sprendimas saugo jautrią informaciją: „Komisija išanalizavusi UAB „Blue Bridge MSP“ įvardintus komponentus nustatė, kad pasiūlyme nurodoma programinė įranga valdo jautrią informaciją, operuoja ja, tačiau nesaugo jautrios informacijos - neturi saugyklos (angl. Vault) funkcionalumo, o saugojimui naudoja išorines saugyklas (taip pat turi šifravimo funkcionalumą, kuris padeda apsaugoti jautrią informaciją).“

5.3.  Ieškovas teigia, kad Aplinkybė, ar jis tokią funkciją atlieka saugodamas jautrią informaciją ne izoliuotoje ar izoliuotoje saugykloje, neturi jokios teisinės reikšmės, nes Atsakovas pasirinko Pirkimo dokumentuose tokio reikalavimo (pvz., saugoti duomenis tik izoliuotoje saugykloje - secret vault) nekelti nei formuluodamas pozityviąsias (t. y. formuluodamas reikalavimus, kuriuos turi atitikti pirkimo objektas), nei negatyviąsias (t. y. formuluodamas draudimus pirkimo objekto savybėms) sąlygas.

5.4. Ieškovas motyvuoja, kad Pirkimo dokumentai nenumato reikalavimo aplikacijų slaptažodžių apsikeitimo su kitomis aplikacijomis funkcionalumui. Trečiasis asmuo be pagrindo teigia, teigia, kad Ieškovo pasiūlytas sprendimas nėra skirtas ir negali užtikrinti aplikacijų slaptažodžių apsikeitimo su kitomis aplikacijomis (programinėmis įrangomis), kadangi Pirkimo dokumentuose, konkrečiai TS, niekur nėra įtvirtinto reikalavimo, kad tiekėjo siūlomas sprendimas privalo užtikrinti tokį Trečiojo asmens atsiliepime nurodomą funkcionalumą, kadangi toks funkcionalumas nėra nustatytas TS 17.7 punkte, nes TS 17. p. yra aptarti papildomi konteinerizacijos platformos valdymo komponentai, skirti Pirkime siekiamo įsigyti sprendimo funkcionalumui užtikrinti, kurie turi būti sudiegti Perkančiosios organizacijos virtualizacijos platformoje, t.y. 17.7. p. nustato, kad virtualizacijos platformoje turi būti sudiegtas papildomas komponentas: aplikacijų jautrios informacijos saugojimo priemonės (angl. secret store/vault). Sąlygose nėra pateikti jokie reikalavimai TS 17.7. p. aptartam komponentui - aplikacijų jautrios informacijos saugojimo priemonėms. Konkrečiai nėra nustatyti jokie papildomi reikalavimai nei tokioms informacijos saugojimo priemonėms (techniniai, teisiniai, funkciniai ir pan.), nei tokių priemonių veikimo principams ar algoritmams, nei jokie kiti reikalavimai.

5.5. Trečiojo asmens atsiliepime pateiktas teiginys, kad, remiantis TS 17.7 p. reikalavimais, siūlomas sprendimas privalėjo užtikrinti aplikacijų slaptažodžių apsikeitimo su kitomis aplikacijomis (programinėmis įrangomis) yra nepagrįstas. Ieškovas, teikdamas savo pasiūlymą Pirkime, turėjo pagrįstą ir teisėtą lūkestį, kad aplikacijų jautrios informacijos saugojimo priemonė turi atitikti tik šiuos reikalavimus - ji turi būti įdiegta ir ji turi užtikrinti jautrios informacijos saugojimo funkciją. Jokių kitų specialiųjų reikalavimų (reikalavimai veikimo principams, algoritmams ar kitoms savybėms) Perkančioji organizacija Pirkimo dokumentuose nenustatė, todėl jokių kitų specialiųjų reikalavimų Ieškovo siūlyta priemonė ir neprivalėjo atitikti. Kadangi ši priemonė TS aprašoma kaip konteinerizacijos platformos valdymo dalis (TS 17 p.), jai taikomi ir bendrieji reikalavimai, nustatyti konteinerių platformos valdymo sistemai (TS 4 p.).

5.6. Ieškovas daro išvadą, kad TS nenumato nei reikalavimo, kad jautri informacija būtų saugoma tik atskiroje, nuo platformos izoliuotoje saugykloje, nei reikalavimo, kad ji būtų saugoma ne izoliuotoje saugykloje. Priešingai, tarp secret store (ne izoliuotos jautrių duomenų saugyklos) ir secret vault yra padėtas pasviro brūkšnio skyrybos ženklas, reiškiantis jau aptartą alternatyvą. Ieškovo vertinimu, dėl šios alternatyvos tiekėjai buvo laisvi Pirkime siūlyti arba vienos, arba antros rūšies saugyklą. Remiantis TS 17.7 p. reikalavimais, siūlomas sprendimas privalėjo užtikrinti aplikacijų apsaugą. Ieškovo vertinimu, minėtas skyrybos ženklas (secret store/vault) reiškia išreiškiamą alternatyvą - jautrios informacijos saugojimą ne izoliuotoje (secret store) arba izoliuotoje saugykloje (secret vault). Dėl to net ir teoriškai laikant, jog Tiekėjo pasiūlymas neatitinka secret vault reikalavimo, jis vis tiek bus laikomas atitinkančiu pirkimo dokumentus, jeigu jis atitinka secret store reikalavimą.

5.7. Ieškovo siūloma Programinė įranga, savyje talpinanti ne izoliuotą duomenų saugyklą - secret store, atitinka visas geriausias saugumo praktikas, aptartas TS 12 p. bei 13 p, todėl Atsakovas Sprendime nepagrįstai nurodo, kad Ieškovo siūlyta Programinė įranga neturi saugyklos funkcionalumo arba, kaip atsiliepime nurodyta, kad šis funkcionalumas neatitinka rinkos standartų.   Jeigu formuluodamas TS sąlygas Atsakovas ir padarė tam tikrų klaidų apibrėždamas TS 17.7. įtvirtintą komponentą, šių klaidų pasekmės jokiu būdu negali būti perkeliamos Ieškovui. Lietuvos Aukščiausiasis Teismas savo praktikoje yra konstatavęs, kad sisteminio pirkimo sąlygų aiškinimo metodas iš esmės reiškia, kad, pirkimo (konkurso) sąlygose aiškiai neįtvirtinus vienos ar kitos jų nuostatos (sąvokos) turinio (ir būtent dėl to tarp šalių kilus ginčui), jis galėtų būti teismo nustatytas aiškinantis kitas pirkimo (konkurso) sąlygas;

5.8. Ieškovas daro išvadą, kad Atsakovas TS 17.7. p. aptartam papildomam konteinerizacijos platformos komponentui nenustatė reikalavimo, kad informacija būtų saugoma tik izoliuotoje duomenų saugykloje. Ieškovo vertinimu, remiantis TS 17.7. p. analize, Atsakovas suteikė galimybę tiekėjams pasirinkti ar siūlyti ne izoliuotą saugyklą - secret store, ar izoliuotą saugyklą - secret vault.

5.9. Atsakovas, vertindamas Ieškovo pasiūlymą. patvirtino, kad Tiekėjo pasiūlytas komponentas atitinka TS 17.7. p. reikalavimus. Aplinkybė, ar jis tokią funkciją atlieka saugodamas jautrią informaciją ne izoliuotojoje ar izoliuotoje saugykloje, neturi visiškai jokios teisinės reikšmės, nes Atsakovas pasirinko Pirkimo dokumentuose tokio reikalavimo (pvz., saugoti duomenis tik izoliuotoje saugykloje - secret vault) nekelti nei formuluodamas pozityviąsias (t. y. formuluodamas reikalavimus, kuriuos turi atitikti pirkimo objektas), nei negatyviąsias (t. y. formuluodamas draudimus pirkimo objekto savybėms) sąlygas.

5.10. Ieškovo vertinimu, Atsakovas nepagrįstai sieja TS 17.7. p. su TS 22.8. p., nes TS 22.8 punkto reikalavimas taikomas išimtinai konteinerizacijos platformai, o ne konteinerizacijos platformos valdymo ar automatizavimo įrankiams. TS 17.7. p., priešingai nei Sprendime nurodo Atsakovas, nustato vieną kertinį reikalavimą - informacijos saugojimą ne izoliuotoje secret store arba izoliuotoje secret vault saugykloje, o TS 22.8. yra skirtas apibrėžti tik konteinerizavimo platformai taikomus reikalavimus.

5.11. TS 22.8 p. netgi fiziškai yra patalpintas kitame 2.1. TS skyriuje, o tuo tarpu TS 17.7. p. yra TS dalyje 1.3., skirtoje apibrėžti reikalingus sprendimus. Be to, Pirkimo dokumentai nenustato jokių sąsajų tarp TS 17.7 p. nurodyto komponento (jautrios informacijos saugojimo) ir TS 22.8 p. nustatyto funkcionalumo (automatizuoto konfigūracijos valdymo). Dėl šių priežasčių Atsakovo bandymas susieti šias dvi sąlygas ir grįsti pasiūlymo neatitikimą TS 22.8 p. sąlygai neaiškiu, neapibrėžtu ir menamu neatitikimu TS 17.7 p. neturi jokio teisinio pagrindo bei yra neteisėtas.

6. Atsakovas teismui pateiktame triplike teigia, kad nagrinėjamo Pirkimo atveju Techninės specifikacijos sąlygos buvo suformuluotos nuosekliai, išsamiai ir aiškiai apibrėžiant Perkančiosios organizacijos valią dėl Pirkimo objekto, dėl ko pakankamai gerai informuoti ir normaliai rūpestingi tiekėjai galėjo jas suprasti vienareikšmiškai, t. y. taip, kaip jos buvo nustatytos Pirkimo dokumentuose. Nurodo, kad Techninėje specifikacijoje buvo aiškiai pavaizduota schema „Pav. 1. PLANUOJAMA PLATFORMOS ARCHITEKTŪRA" (toliau - Schema), kuri atspindėjo Pirkimo objektą. Ieškovas neteigia, kad schema buvo neaiški, nesuprantama, ar kėlė abejonių dėl jos įgyvendinimo būdų, todėl Atsakovas daro išvadą, jog Ieškovui, dalyvaujant Pirkime ir teikiant savo pasiūlymą, schemos įgyvendinimas buvo suprantamas ir nekėlė jokių abejonių dėl jos įgyvendinimo. Kaip matyti iš pačios Schemos turinio bei Pirkimo Specialiųjų sąlygų 2.2. papunkčio nuostatų, kurie reglamentuoja Pirkimo objekto turinį, Schema atspindėjo Pirkimo objektą kaip perkamą vientisą sprendimą, kuriame aiškiai atvaizduotas ir vieno iš Pirkimo objekto reikalavimų, t. y. Techninės specifikacijos 17.7. papunktis) įgyvendinimo būtas, t .y. jog, įgyvendinant Techninės specifikacijos 17.7. papunkčio reikalavimus, jautri informacija turės būti saugoma tik atskiroje nuo Platformos izoliuotoje saugykloje.

6.2. Perkančiosios organizacijos valia dėl papildomo komponento „Aplikacijų jautrios informacijos saugojimo priemonės (angl. secret store / vault)" įgyvendinimo, t. y. jog jis privalo būti įgyvendinamas kaip atskirai diegiamas komponentas, o ne kaip integruota ar vidinė kitos sistemos funkcija, buvo aiškiai išreikšta ne tik schemos forma, bet ir Techninės specifikacijos 17.7. papunktyje. Atsakovas teigia, kad pakankamai gerai informuotiems ir normaliai rūpestingiems tiekėjams, dalyvavusiems Pirkime, vien tai, jog Techninės specifikacijos 17. 7 p. papunktyje nurodyta „Aplikacijų jautrios informacijos saugojimo priemonės (angl. secret store / vault)" leido aiškiai suprasti, jog šis komponentas turės būti atskirai diegiamas, o ne kaip integruota ar vidinė kitos sistemos funkcija.

Atsižvelgiant į rinkos praktiką ir tarptautiniuose kibernetinio saugumo standartuose vartojamas sąvokas, sąlyga „Aplikacijų jautrios informacijos saugojimo priemonės (angl. secret store / vault)" objektyviai suprantama kaip reikalavimas diegti savarankiškai veikiančią jautrios informacijos saugyklą, o vadovaujantis rinkos praktika „secret store / vault" apibrėžiama kaip atskira jautrios informacijos saugykla.

6.3. Nors Ieškovas akcentuoja, jog Perkančioji organizacija Techninės specifikacijos 17.7. papunktyje numatytam komponentui pasirinko neformuoti jokių specifinių reikalavimų, tačiau toks Ieškovo teiginys neleidžia vertinti, jog Pirkimo sąlygos buvo neišsamios, neaiškios, nepakankamos ar kėlė kokių nors dviprasmybių ar abejonių dėl įgyvendinimo būdo, ar tai, jog ginčo atveju buvo būtina Pirkimo sąlygose įtvirtinti papildomas sąlygas dėl Techninės specifikacijos 17.7. papunkčio įgyvendinimo, siekiant įgyvendinti Perkančiosios organizacijos valią dėl to, jog papildomas valdymo komponentas „Aplikacijų jautrios informacijos saugojimo priemonės (angl. secret store / vault)" būtų įgyvendinamas kaip atskirai diegiamas komponentas. Atsakovės vertinimu, tokia Ieškovės pozicija, kad nebuvo įtvirtinta jokių specifinių reikalavimų dėl Techninės specifikacijos 17.7. papunkčio įgyvendinimo, yra sąlygota vien Ieškovės tikslo pateisinti netinkamai pateiktą Pirkime savo pasiūlymą.

6.4. Ieškovo pozicija dėl Techninės specifikacijos 17.7. papunkčio įgyvendinimo bei teiginys, kad Ieškovo pasiūlymas atitiko ginčo Techninės specifikacijos sąlygas, yra gynybinė pozicija dėl netinkamai pateikto pasiūlymo Pirkime ir tai pagrindžia faktinės aplinkybės, susijusios su Ieškovo dalyvavimu ankstesniame viešajame tarptautiniame pirkime „ESPBI IS modernizavimo (dekomponavimo) projekto programinė įranga ir programinės įrangos konfigūravimo paslaugos" Nr. (duomenys neskelbtini), kuriame dalyvavo tiek Ieškovas, tiek ir Trečiasis asmuo (Šis pirkimas buvo nutrauktas). Atsižvelgiant į aplinkybes, dėl kurių ankstesnis pirkimas buvo nutrauktas, ginčo Pirkime Techninė specifikacija buvo patikslinta tokiais aspektais, t. y.

Pirma, Schemoje papildomai nurodant schemos elementą Pav. 1.;

ffĮ Secret

                     Vault

Patikslinant ginčo Techninės specifikacijos sąlygą dėl 17.7. papunkčio įgyvendinimo, jį papildant, bei tokiu būdu išsamiau nurodant kokiu būdu turi būti įgyvendintas Techninės specifikacijos 17.7. papunktis, todėl Ieškovas, kaip pakankamai gerai informuotas ir normaliai rūpestingas tiekėjas, suvokė ir negalėjo nesuvokti aplinkybės, kad Perkančioji organizacija, nutraukdama ankstesnį pirkimą ir paskelbdama naują pirkimą, t.y. ginčo Pirkimą, kuriame Techninė specifikacija buvo papildyta atitinkamais aspektais, susijusiais su jautrios informacijos saugojimu, išreiškia aiškią Perkančiosios organizacijos valią nupirkti Pirkimo objektą, kuriame, be kita ko, papildomas komponentas „Aplikacijų jautrios informacijos saugojimo priemonės (angl. secret store / vault)" turi būti įgyvendinamas kaip atskirai diegiamas komponentas, o ne kaip integruota ar vidinė kitos sistemos funkcija.

6.5. Ieškovo pozicija dėl to, jog, dalyvaudama Pirkime, jis turėjo teisę pasirinkti, kaip įgyvendinti Techninės specifikacijos 17.7. papunktį, kadangi Perkančioji organizacija pasirinko Pirkimo dokumentuose nurodyti tik tikslą - jautrios informacijos saugojimą papildomu konteinerizacijos platformos valdymo komponentu, o ne kaip turi būti saugomi jautrūs duomenys, turėtų būti vertinama tik kaip pasirinkta gynybinė pozicija, nes esant pateiktam Pirkime pasiūlymui, kuris neatitiko Techninės specifikacijos reikalavimų, nėra pagrindo pripažinti, kad Techninės specifikacijos sąlygos dėl 17.7. papunkčio įgyvendinimo yra neišsamios ar neaiškios. Atsakovas motyvuoja, kad vertinant Techninės specifikacijos 17.7. papunkčio nuostatas sisteminiu ir loginio aiškinimo požiūriu, akivaizdu, kad Perkančioji organizacija nesiekė ir negalėjo siekti sudaryti sąlygų tiekėjams laisvai pasirinkti skirtingus šio papunkčio reikalavimo įgyvendinimo būdus. Priešingu atveju būtų nelogiška ir prieštarautų viešųjų pirkimų principams, jog perkančioji organizacija, aiškiai apibrėždama konkrečius jautrios informacijos saugumo reikalavimus, kartu paliktų tiekėjams diskreciją pasirenkant iš esmės skirtingus technologinius sprendimus, neapibrėždama jų funkcinio turinio. Atsakovės vertinimu, pakankamai gerai informuotiems ir normaliai rūpestingiems tiekėjams, susipažinusiems su Pirkimo dokumentais ir rinkoje nusistovėjusia atitinkamų sąvokų reikšme, neturėjo kilti jokių pagrįstų abejonių dėl to, kaip turi būti įgyvendintas Techninės specifikacijos 17.7. papunkčio reikalavimas, ar tuo labiau, vertinti šiuos reikalavimus įgyvendinimo prasme kaip suteikiančius diskrecijos teisę pasirinkti skirtingus technologiniu aspektu įgyvendinimo variantus. Atsakovė teigia, kad techninių reikalavimų - jautrios informacijos saugojimo priemonių paskirties ir įgyvendinimo - vertinimas yra vienas esminių, sprendžiant, ar Ieškovės pasiūlytas sprendimas atitinka Techninės specifikacijos nuostatas.

6.6. Ieškovas kaip profesionalus ir nuolatinis viešųjų pirkimų dalyvis, dalyvaudamas Pirkime, nekėlė Perkančiajai organizacijai jokio klausimo dėl Techninės specifikacijos 17.7. papunkčio įgyvendinimo. Atsakovo vertinimu, tai patvirtina, kad Ieškovui Pirkimo sąlygos buvo aiškios ir suprantamos, objektyvių neaiškumų dėl Pirkimo objekto įgyvendinimo Ieškovui nebuvo kilę. Atsakovas akcentuoja, kad nors tikslių, aiškių ir nedviprasmiškų viešojo pirkimo dokumentų parengimo pareiga tenka perkančiajai organizacijai, tiekėjai taip pat turi veikti apdairiai - išsamiai ir atidžiai susipažinti su visais viešojo pirkimo dokumentais bei juose iškeltais reikalavimais.

6.7. Ieškovas nepagrįstai tvirtina, kad jo pateiktas pirkimui pasiūlymas, naudojant Ansible Vault (kuris yra integruota Tiekėjo pasiūlyme nurodytos Red Hat Ansible Automation Platform Premium licencijos dalis) ir Red Hat Ansible Automation Platform Automation Controller (kuri taip pat yra integruota Tiekėjo pasiūlyme nurodytos Red Hat Ansible Automation Platform Premium licencijos dalis), užtikrina jautrios informacijos saugojimą, kaip numatyta Techninės specifikacijos 17.7. papunktyje, ir neva tai patvirtino Atsakovas. Atsakovo pirkimo Komisija aiškiai ir ne kartą patvirtino visiškai priešingą poziciją, t. y. jog: „Komisija išanalizavusi UAB „Blue Bridge MSP" įvardintus komponentus nustatė, kad pasiūlyme nurodoma programinė įranga valdo jautrią informaciją, operuoja ja, tačiau nesaugo jautrios informacijos - neturi saugyklos (angl.Vault) funkcionalumo, o saugojimui naudoja išorines saugyklas (taip pat turi šifravimo funkcionalumą, kuri padeda apsaugoti jautrią informaciją). Pažymi, kad Ansible Vault neturi savyje specializuotos saugyklos jautriai informacijai saugoti. Kadangi Ieškovo siūlomame sprendime nėra jautrios informacijos saugyklos, tai neįmanoma ir automatizuotai valdyti jautrios informacijos saugojimo (TS 22.8. p. reikalavimas dėl automatizuoto konfigūracijos valdymo)." Vadovaujantis oficialia Red Hat dokumentacija, Ansible Vault neturi savo atskiros arba centralizuoto išorinio saugojimo sistemos (šia aplinkybę patvirtina ir pats Tiekėjas Pretenzijos 22 pastraipoje); vietoj to, ji leidžia vartotojams šifruoti konfidencialius duomenis tiesiogiai Ansible YAML failuose (inventoriaus sąrašuose, kintamuosiuose arba žaidimų knygose), todėl neatitinka TS 1 p. pateiktame platformos komponentų architektūros schemoje (Paveikslas 1) reikalavimo turėti informacijos saugojimui atskirą nuo platformos izoliuotą saugyklą; 

6.8. Kadangi programa Ansible Vault neužtikrina jautrios informacijos saugojimo (neturi „store / vault" funkcijos) (pažymėtina, jog gamintojas atsakymuose taip pat nepatvirtino, kad Ansible Vault užtikrina jautrios informacijos saugojimą), o naudoja išorines saugojimo priemones, kas visiškai neatitinka Techninės specifikacijos sąlygų, todėl šis klausimas sąmoningai Ieškovo nebuvo pateiktas gamintojui, ir buvo teikiami klausimai tendencingai Ieškovei naudinga linkme;

6.9. Atsakovas teigia, kad jog papildomą valdymo komponentą „Aplikacijų jautrios informacijos saugojimo priemonės (angl. secret store / vault)" įgyvendinus kaip integruotą ar vidinę kitos sistemos funkciją, toks sprendimas neatitiktų ir visų geriausių saugos praktikų (Techninės specifikacijos 12 punktas). Nagrinėjamo pirkimo atveju kalbama apie jautrios informacijos (API raktų, slaptažodžių, šifravimo raktų, sertifikatų ir autentiškumo tokenų) saugojimą. Techninės specifikacijos 12 punkte įtvirtinta, kad „Platforma turi būti suprojektuota atsižvelgiant į saugumą, įtraukiant geriausias saugos praktikas ir t.t. ... Platforma turi turėti galimybę būti integruota su esamais saugos įrankiais ir paslaugomis, tokiomis kaip tapatybės ir prieigos valdymo (IAM) sistemos, kad būtų užtikrinta vieninga saugumo pozicija. Taip pat platforma turi gebėti teikti beveik realaus laiko saugumo stebėjimo ir įspėjimo galimybes, užtikrinančias, kad saugumo incidentai būtų greitai aptikti ir į juos būtų reaguojama". Žodžiai „paslapčių valdymas" (angl. secrets management) yra tiesioginis techninis terminas, apibūdinantis būtent „secret store / vault" funkcionalumą, kuris numatytas Techninės specifikacijos 17.7 punkte kaip papildomą valdymo komponentą „Aplikacijų jautrios informacijos saugojimo priemonės (angl. secret store / vault)" įgyvendinus kaip integruotą ar vidinę kitos sistemos funkciją, ir neužtikrinus būtent „secret store / vault" funkcionalumo, toks sprendimas akivaizdžiai neatitiktų ir visų geriausių saugos praktikų, nurodytų Techninės specifikacijos 12 punkte.

6.10. Atsakovės vertinimu, kaip nepagrįstas turėtų būti atmestas ieškinio motyvas, kad Atsakovas nepagrįstai sutapatina Techninės specifikacijos 17.7. papunkčio nuostatas su Techninės specifikacijos 22.8. papunkčio nuostatomis. Techninės specifikacijos 17.7. papunktis nustato kas turi būti įdiegta ir kokius kriterijus turi atitikti sprendimas, o Techninės specifikacijos 22.8. papunktis apibrėžia jo diegimo ir valdymo būdą - užtikrinant automatizavimą, atsekamumą ir valdymo kontrolę per visą gyvavimo ciklą. Taigi, Techninės specifikacijos 22.8. papunktis yra funkciškai būtinas mechanizmas, leidžiantis praktikoje įgyvendinti Techninės specifikacijos 17.7. papunkčio reikalavimus. Atsižvelgiant į tai, Ieškovo teiginiai apie šių Techninės specifikacijos nuostatų tarpusavio nesusiejimą yra nepagrįsti ir grindžiami vien izoliuotu jų aiškinimu.

6.11. Byloje reiškiamas reikalavimas dėl 2026-02-13 Pretenzijos atmetimo bei suformuotos teismų praktikos (t. y. jog ieškinio reikalavimas dėl pretenzijos atmetimo nėra savarankiškas reikalavimas ir dėl to nepatenka į bylos nagrinėjimo dalyką), todėl Atsakovė vertina esant pagrindui pagal suformuluotą ieškinio reikalavimą (dalyką) bylą nutraukti (Civilinio proceso kodekso 293 straipsnis).

7. Trečiasis asmuo teismui patiktame Triplike prašė atmesti Ieškovo ieškinį visa apimtimi, priteisti iš Ieškovo visas Trečiojo asmens patirtas bylinėjimosi išlaidas. Triplike teigiama, kad nagrinėjamos bylos esmė - ne ginčas dėl Pirkimo sąlygų, o siekis patikrinti ir įsitikinti, ar Ieškovo pateikta pirkimui Programinė įranga atitiko Pirkimo sąlygų TS 17.7 p. ir 22.8 p. reikalavimus. Trečiasis asmuo teigia, kad Ieškovas Ieškiniu ginčija Pirkimo sąlygas, konkrečiai, TS 17.7 p. ir 22.8 p., tačiau tai daro pavėluotai, po to, kai Ieškovo pasiūlymas buvo atmestas kaip neatitinkantis minėtų TS reikalavimų. Pagal formuojamą kasacinio teismo praktiką tiekėjams taikomas ribojimas ginčyti pirkimo sąlygas, o teismui - jas vertinti, jei pirkimo sąlygų teisėtumas kvestionuojamas bet kurioje vėlesnėje viešojo pirkimo stadijoje. Tokiuose ginčuose teismai gali vertinti, ar perkančioji organizacija tinkamai dalyviams pritaikė pirkimo sąlygas, bet ne tai, ar jos (pirkimo sąlygos) yra teisėtos (Lietuvos Aukščiausiojo Teismo 2012 m. rugsėjo 27 d. nutartis civilinėje byloje Nr. 3K-3-408/2012.

7.1. Atsakovas triplike pripažino, kad Ieškovo pasiūlymas atitiko TS 12 p. reikalavimus, tačiau Atsakovas Ieškovo pasiūlymą atmetė ne dėl šio punkto sąlygų, o todėl, kad Ieškovo pasiūlymas neatitiko TS 17.7 p. ir 22.8 p. reikalavimų. Trečiasis asmuo teigia, kad TS 17.7 p. pateiktos sąvokos secret vault ir secret store yra sinonimai, o ne alternatyvos, nes ginčo konkurso specialiųjų pirkimo sąlygų 1.9 p. draudė pirkimo dalyviams pateikti alternatyvius pasiūlymus (Tripliko 1 priedas, 1.9 p.), t.y. ginčo Pirkime neleidžiama pateikti alternatyvių pasiūlymų. Atsakovo tikslas ginčo pirkimu buvo įsigyti programinę įrangą, t. y. papildomą kompiuterizavimo platformos komponentą, kuris užtikrintų jautrios informacijos saugojimą ir saugų atidavimą kitoms aplikacijoms, tačiau Ieškovo pasiūlyta Programinė įranga būtent šio funkcionalumo ir tokių galimybių neturėjo, nes yra ne tam skirta. Ieškovo pasiūlytos Programinės įrangos atitikimo TS 17.7 p. nepatvirtina ir neįrodo nei Ieškovo Ieškinio, nei Dubliko argumentai, nei Programinės įrangos gamintojo atsakymai. Priešingai, Programinės įrangos gamintojas patvirtina, kad įranga neturi aplikacijų jautrios informacijos (angl. secrets) saugojimo ir perdavimo kitoms aplikacijoms funkcionalumo, kaip to reikalauja TS 17.7 p., o programinės įrangos gamintojo atstovų atsakymų aiškinimas patvirtina ir įrodo, kad Ieškovo pasiūlyta Programinė įranga neturi ir neužtikrina aplikacijų jautrios informacijos saugojimo ir apsikeitimo su kitomis aplikacijomis funkcionalumo.

7.2. Trečiasis asmuo teigia, kad Ieškovas akcentuoja selektyviai parinkęs gamintojo atsakymus, nors visuma atsakymų patvirtina bei įrodo, kad Ieškovo pasiūlyta pirkimui programinė įranga neturi funkcionalumo ir saugoti, ir dalintis aplikacijų jautria informacija su kitomis aplikacijomis (su kitomis programinėmis įrangomis). Programinės įrangos gamintojo atsakymai bei pastebėjimai (Ištraukos iš Dubliko 1 priedo: Išorės programos negali pateikti užklausos ar „ištraukti“ neskelbtinų slaptų duomenų reikšmių iš AAP RĘST API“). Panašiai, „Ansible playbook" nepasiima kredencialų vykdymo metu. Vietoj to, AAP naudoja saugų „Push“ modelį. Iš programinės įrangos gamintojo atstovų atsakymų matyti, kad kitos išorinės aplikacijos (programos) negalės pasiimti jautrios informacijos iš Programinės įrangos, todėl Ieškovo pasiūlyta Programinė įranga neatitinka TS 17.7 p. Be to, kaip patvirtina pats Programinės įrangos gamintojas, jautri informacija galėtų būti prieinama tik tam tikrą laiko tarpą (momentą), t. y. tik konkrečiu automatizavimo užduoties laikotarpiu, ką akcentuoja ir pats Ieškovas Dubliko 52 p., 54 p., 56 p.

7.3. Ieškovas Dubliko 9-oje išnašoje pripažįsta, kad automatizavimo valdikliu nors ir saugojami įvairūs slapti duomenys, tačiau jie yra naudojami tik automatizavimui arba atsiranda kaip jo rezultatas, tačiau tai jokia apimtimi neįrodo, kad kitos aplikacijos galės savarankiškai kreiptis į Programinę įrangą (AAP) kaip į saugyklą, o tai yra esminis secret store/vault požymis, tačiau tokio funkcionalumo Ieškovo pasiūlyta pirkimui įranga neturi. Trečiasis asmuo paaiškina, kad būtent LRV nutarimo draudimo tikslas yra užtikrinti, kad secrets nebūtų laikomos nesaugiose vietose ir šis tikslas pasiekiamas tik turint dedikuotą, izoliuotą saugyklą (angl. secret store/vault), prie kurios aplikacijos kreipiasi kontroliuojamu būdu, ko ir reikalauja TS 17.7 p.. tačiau Ieškovo pasiūlyta Programinė įranga (AAP) automatiškai negarantuoja, jog slapti duomenys nepateks į žurnalus ar išvestį - tai reikalauja papildomo rankinio kūrėjų veiksmo, tą akcentuoja ir gamintojo atstovas, nurodydamas, kad visada reikės taikyti tam tikrą papildomą apsaugą (angl. „nojog.true“). Nurodytos aplinkybės patvirtina, kad Ieškovo Programinė įranga neatitinka TS 17.7 p., kas papildomai reiškia, kad neužtikrins ir kibernetinio saugumo reikalavimų, apibrėžtų LRV nutarime.

7.4. Ieškovas Dubliko 56 p. pripažįsta, kad jo pasiūlyta Programinė įranga aptarnauja ne daugelio aplikacijų (programinių įrangų) jautrią informaciją, o tik vienos konkrečios programinės įrangos vidinę jautrią informaciją, t. y. pačios Ansible jautrią informaciją, t.y. Ieškovas patvirtina Trečiojo asmens argumentus bei Atsiliepime į ieškinį (2.13-2.14 p.) įrodinėjamą poziciją. Trečiasis asmuo teigia kad sistemiškai aiškinant viešai skelbiamą Programinės įrangos gamintojo informaciją ir gamintojo atsakymus į Trečiojo asmens konkrečius ir tiksliai bei korektiškai suformuluotus klausimus (Atsiliepimo į ieškinį 2.11 p. ir 1 priedas), taip pat gamintojo atsakymus, Ieškovo pasiūlyta Programinė įranga neužtikrina aplikacijų jautrios informacijos valdymo (saugojimo ir apsikeitimo su kitomis aplikacijomis), kas yra esminis TS 17.7 p. tikslas ir paskirtis;

7.5. Ieškovo pasiūlyta Programinė įranga neatitiko Techninės specifikacijos 22.8 p. reikalavimo, o Ieškovas Dublike neįrodė ir net neįrodinėjo, kad jo pasiūlyta Programinė įranga atitinka TS 22.8 p. Ieškovas tiek Ieškinio 71-79 p., tiek Dubliko 100-108 p. teigia, kad Atsakovas nepagrįstai sieja TS 17.7 p. su TS 22.8 p., nes Ieškovo vertinimu, TS 22.8 p. taikomas išimtinai konteinerizacijos platformai, o ne konteinerizacijos platformos valdymo ar automatizavimo įrankiams, t. y. TS 22.8 p. yra skirtas apibrėžti tik konteinerizacijos platformai taikomus reikalavimus, kadangi šis punktas yra patalpintas visai kitame TS skyriuje. Trečiasis asmuo teigia, kad Ieškovas nei Ieškinyje, nei Dublike nepateikė nė vieno argumento bei įrodymo, kad jo pasiūlyta Programinė įranga atitinka TS 22.8 p. reikalavimus, procesiniuose dokumentuose įrodinėdamas, kad TS 22.8 p. apskritai neturėjo būti taikomas jo pasiūlytai Programinei įrangai;

7.6. Trečiasis asmuo daro išvadą, kad Ieškovo pasiūlyta Programinė įranga (Red Hat Ansible Automation Platform) neatitinka TS reikalavimų ir tai patvirtina tiek Programinės įrangos gamintojo pateikti konkretūs atsakymai į Trečiojo asmens tikslius klausimus Programinės įrangos gamintoja patvirtina, kad „išorės programos negali pateikti užklausos ar „ištraukti neskelbtinų slaptų duomenų reikšmių iš APP“ (Programinės įrangos) (Dubliko 53 p.), o būtent tokio funkcionalumo reikalavo Atsakovas TS 17.7 p., su kuo sutinka ir pats Ieškovas (Dubliko 49-50p.);

7.7. Trečiasis asmuo teigia, kad Ieškovas ne tik netinkamai suformulavo Ieškinio reikalavimus, bet Ieškinys apskritai neatitinka Ieškiniui keliamų reikalavimų (CPK 113 str. 3 d.,135 str.), kadangi Ieškovas pažeidė CPK numatytas pareigas (CPK 113 str.), taip pat pateikė į bylą procesinius dokumentus Byloje, kurie neatitinka ir CPK 135 str. reikalavimų, be to, yra netinkamai suformuluotas Ieškinio dalykas (CPK 135 str. 1 d. 4 p.), todėl yra faktinis ir teisinis pagrindas teismui bylą nutraukti CPK 293 str. 1 p. pagrindu.

Faktinės bylos aplinkybės:

8. Atsakovo Viešojo pirkimo komisija (toliau - Komisija) atlieka viešąjį tarptautinį pirkimą „ESPBI IS modernizavimo (dekomponavimo) projekto programinė įranga ir programinės įrangos konfigūravimo paslaugos" (toliau - Pirkimas) atviro konkurso būdu, apie kurį Centrinės viešųjų pirkimų informacinės sistemos priemonėmis buvo paskelbta 2025-11-04 (Pirkimo Nr. (duomenys neskelbtini)). Pirkimas yra vykdomas įgyvendinant Europos Sąjungos lėšomis bendrai finansuojamą projektą Nr. 09-021-P-0001 „ESPBI IS sudarančių posistemių dekomponavimas". Pirkimu Atsakovas siekė įsigyti „ESPBI IS modernizavimo (dekomponavimo) projekto programinę įrangą ir programinės įrangos konfigūravimo paslaugas”, t. y. šio Pirkimo objektas - įdiegta platforma, kurioje bus modernizuojama E. Sveikata informacinė sistema, šią sistemą dekomponuojant į atskiras aplikacijas (programas), kurių jautri informacija turės būti saugoma, valdoma ir pasiekiama iš jautrių duomenų saugyklos.

8.1. Ieškovas pateikė pasiūlymą Atsakovo paskelbtam pirkimui. Atsakovo Komisija 2026-02-05 raštu „Dėl pasiūlymo atmetimo" informavo Ieškovą, kad, vadovaujantis Lietuvos Respublikos viešųjų pirkimų įstatymo 45 straipsnio 1 dalies 1 punktu ir Bendrųjų sąlygų 18.1.6. papunkčio nuostatomis, Komisija nusprendė atmesti Ieškovės pasiūlymą kaip nepriimtiną, nes pasiūlymas neatitinka Techninės specifikacijos 17.7. papunktyje ir 22.8. papunktyje nurodytų reikalavimų, kadangi siūlomame Ieškovės sprendime nėra jautrios informacijos saugyklos (Techninės specifikacijos 17.7. papunktis), atitinkamai, neįmanoma ir automatizuotai valdyti jautrios informacijos saugojimo (Techninės specifikacijos 22.8. papunktis). Komisija paaiškino, kad išanalizavusi Ieškovės įvardintus komponentus nustatė, kad pasiūlyme nurodoma programinė įranga valdo jautrią informaciją, operuoja ja, tačiau nesaugo jautrios informacijos - neturi saugyklos (angl. vault) funkcionalumo, o saugojimui naudoja išorines saugyklas (taip pat turi šifravimo funkcionalumą, kuri padeda apsaugoti jautrią informaciją). Komisija pažymėjo, kad Ansible Vault neturi savyje specializuotos saugyklos jautriai informacijai saugoti.

8.2. Ieškovas pateikė 2026-02-13 Pretenziją „Dėl neteisėto Tiekėjo pasiūlymo atmetimo Pirkime", kuriuo Ieškovė prašė panaikinti 2026-02-05 raštą visa apimtimi ir iš naujo vertinti Tiekėjo pasiūlymą Pirkime, pripažįstant jį atitinkančiu Pirkimo reikalavimus, ir nustatyti naują pasiūlymų eilę; vadovaujantis VPĮ 103 straipsnio 2 dalimi, nesudaryti viešojo pirkimo - pardavimo sutarties su trečiaisiais asmenimis Pirkime tol, kol nebus išnagrinėta Tiekėjos pretenzija, o tuo atveju, jeigu ši pretenzija nebūtų tenkinama, nurodyti išsamius pretenzijos atmetimo pagrindus ir argumentus, kad Tiekėja galėtų savo pažeistas teises ginti pareiškiant ieškinį VPĮ nustatyta tvarka. Ieškovas teigia, kad Atsakovo 2026-02­-05 rašte išdėstytas sprendimas dėl Ieškovo pasiūlymo atmetimo yra neproporcingas, jame plečiamai aiškinamos Techninės specifikacijos sąlygos, tokiu būdu neteisėtai sukuriant papildomus reikalavimus, kurie Pirkimo objektui Pirkimo dokumentuose, konkrečiai Techninėje specifikacijoje, apskritai nėra nustatyti (toliau - Pretenzija, Ieškinio Priedas Nr. 5);

8.3. Komisija, 2026-02-23 posėdyje išnagrinėjusi Ieškovo Pretenziją, nutarė ją atmesti kaip nepagrįstą ir 2026-02-24 rašte „Dėl gautos pretenzijos" išdėstė savo atsakymus į Ieškovo 2026-02-13 Pretenzijoje nurodytus argumentus, jog Ieškovo 2026-02-13 Pretenzijos 1 ir 2 reikalavimą atmetami kaip nepagrįsti, o dėl 3 reikalavimo paaiškino, kad sutartis su Trečiuoju asmeniu nėra sudaryta, kol neišnagrinėta Ieškovė 2026-02-13 pretenzija. 

8.4. Ieškovė 2026-03-06 pateikė Teismui Ieškinį.

 9. Teismo išvados nagrinėjamais ieškinio reikalavimais

9.1. Lietuvos Respublikos viešųjų pirkimų įstatymo (toliau – VPĮ) 37 straipsnio 1 dalyje įtvirtina, kad perkamų prekių, paslaugų ar darbų ypatybės apibūdinamos pirkimo dokumentuose pateikiamoje techninėje specifikacijoje. Technines specifikacijas reglamentuojančiose teisės normose perkančiajai organizacijai pripažįstama didelė jos poreikių išmanymu pagrįsta diskrecija formuluojant technines pirkimo specifikacijas. Ši diskrecija pateisinama tuo, kad būtent perkančiosios organizacijos geriausiai žino prekes, kurių joms reikia, ir gali geriausiai nustatyti reikalavimus, kurie turi būti tenkinami tam, kad būtų gauti pageidaujami rezultatai (Europos Sąjungos Teisingumo Teismo 2018 m. spalio 25 d. sprendimo byloje Roche Lietuva, C-413/17, 29-30 punktai). Taigi, už techninių specifikacijų parengimą, tiekėjų pasiūlymų atitikties norimam rezultatui vertinimą yra atsakinga perkančioji organizacija, kadangi, minėta, būtent ji nustato savo poreikius, norimas ir reikalingas įsigyti prekes, paslaugas ir darbus.

9.2. Teismų praktikoje laikomasi nuostatų, kad tikslių, aiškių ir nedviprasmiškų viešojo pirkimo dokumentų parengimo pareiga tenka perkančiajai organizacijai, tačiau ir tiekėjai taip pat turi veikti apdairiai - išsamiai ir atidžiai susipažinti su visais viešojo pirkimo dokumentais bei juose iškeltais reikalavimais. VPĮ 36 straipsnio 5 dalyje įtvirtinta tiekėjų, susipažinusių su viešojo pirkimo dokumentais, teisė, nesuėjus pasiūlymų pateikimo terminui, kreiptis į perkančiąją organizaciją prašant pateikti papildomą su pirkimo dokumentais susijusią informaciją. Ši tiekėjų teisė suponuoja perkančiosios organizacijos pareigą tokią informaciją pateikti, paaiškinti pirkimo sąlygas, jas patikslinti. Taigi tiekėjams taip pat suteikta iniciatyvos teisė (perkančioji organizacija tokią turi pagal VPĮ 36 straipsnio 6 dalį) siekti pašalinti galimus neaiškumus dėl pirkimo sąlygų turinio (Lietuvos Aukščiausiojo Teismo 2024-01-04 nutarties civilinėje byloje Nr. e3K-3-65-381/2024 55 punktas

9.3. Nagrinėjamo ginčo esmė, kad Atsakovo Pirkimo komisija pripažino Ieškovo pasiūlymą Pirkime  nepriimtinu, nes pasiūlymas neatitiko Techninės specifikacijos 17.7. papunktyje ir 22.8. papunktyje nurodytų reikalavimų, kadangi Ieškovo pasiūlytame sprendime nėra jautrios informacijos saugyklos (Techninės specifikacijos 17.7. papunktis), todėl neįmanoma automatizuotai valdyti jautrios informacijos saugojimo (Techninės specifikacijos 22.8. papunktis).

Teismas vertina, kad Ieškovas UAB „Blue Bridge MSP“ yra profesionalus kompiuterinės programos įrangos paslaugų tiekėjas, kad pagal jo paties pateiktą informaciją internetiniuose puslapiuose nustatyta, kad jis savo veiklą vykdo daugiau kaip 10 metų, todėl teismas Ieškovą vertina kaip profesionalų savo srities verslo subjektą, kuriam keliami padidinti atidumo bei rūpestingumo kriterijai, aukščiausių savo veiklos standartų žinojimas ir laikimąsį.  Tuo pačiu teismas daro išvada, kad iki Pasiūlymo pirkimui pateikimo, Ieškovui nagrinėjamo ginčo Pirkimo sąlygos buvo aiškios ir suprantamos, nes Ieškovas nekėlė klausimų perkančiajai organizacijai dėl Techninės specifikacijos 17.7. papunkčio ir 22.8 papunkčio esmės bei įgyvendinimo išaiškinimo, o į pateiktą klausimą buvo gautas Atsakovo atsakymas. VPĮ 36 straipsnio 5 dalyje įtvirtinta tiekėjų, susipažinusių su viešojo pirkimo dokumentais, teisė, nesuėjus pasiūlymų pateikimo terminui, kreiptis į perkančiąją organizaciją prašant pateikti papildomą su pirkimo dokumentais susijusią informaciją. Ši tiekėjų teisė suponuoja perkančiosios organizacijos pareigą tokią informaciją pateikti, paaiškinti pirkimo sąlygas, jas patikslinti. Taigi tiekėjams taip pat suteikta iniciatyvos teisė siekti pašalinti galimus neaiškumus dėl pirkimo sąlygų turinio;

9.4. Atsakovo organizuojamo Pirkimo Techninė specifikacija susideda iš tokių dalių:

 1 dalies „Planuojama platformos architektūra",

2 dalies „Programinė įranga, įrankiai ir paslaugos" bei šių dalių atskirų punktų.

Pirkimo TS 2 skyriaus 18.3 punktas numatė reikalavimą, kad perkama Programa „užtikrintų Platformos saugumą ir vientisumą, taikant patikimas prieigos kontrolės priemones, šifravimą ir audito mechanizmus, siekiant apsaugoti jautrius duomenis ir išlaikyti visuomenės pasitikėjimą“, t.y. aptarti TS reikalavimai yra nustatyti visai E. Sveikatai modernizuoti, todėl teismo vertinimu, pirkimo sąlygose nustatyti reikalavimai turi būti aiškinami ir taikomi sistemiškai, susiejant juos į vieną funkcinę visumą, kad Atsakovo siekiama įsigyti programa turi būti suvokiama kaip vientisas sprendimas, turintis funkcines galimybes užtikrinti visos sistemos veikimą, stabilumą ir palaikymą, pateiktas dėl visiško aiškumo Planuojamos platformos architektūros Schemoje nurodytas konkretus schemos elementas Pav. 1.; ffĮ Secret/Vault, kas leidžia teismui daryti išvadą, kad iš pačios schemos turinio bei Pirkimo Specialiųjų sąlygų 2.2. papunkčio nuostatų, kurie reglamentuoja Pirkimo objekto turinį, schema atspindėjo Pirkimo objektą kaip perkamą vientisą sprendimą, kuriame atvaizduotas vieno iš Pirkimo objekto reikalavimų (t. y. Techninės specifikacijos 17.7. papunktis) įgyvendinimo būdas, t .y. jog, įgyvendinant Techninės specifikacijos 17.7. papunkčio reikalavimus, jautri informacija turės būti saugoma tik atskiroje nuo Platformos izoliuotoje secret/vault saugykloje kaip nurodyta Planuojamos platformos architektūros Schemos Pav. 1. Ši aplinkybė Ieškovui kaip savo srities profesionalui turėjo būti suprantama, kad tai yra atskirai diegiamas komponentas būtent secret/vault, o ne integruota ar vidinė kitos sistemos funkcija;

9.5. Pirkimo TS 1.3 punktas numatė reikalavimus, kad perkama Programa užtikrintų tokius reikalingus sprendimus, t.y. „Aplikacijų veikimo tęstinumui ir saugumui užtikrinti planuojami tokie sprendimai: turėtų būti automatizuotai tikrinama pirminio kodo kokybė, aplikacijų kūrimas iš pirminio kodo (angl. build) turėtų būti automatizuotas ir saugus“, o TS 17.7 p. numatė reikalavimą, pagal kurį turės būti įdiegta programinė įranga, skirta užtikrinti jautrios informacijos valdymą ir saugojimą iš skirtingų programinių įrangų, t. y. visų platformoje, kurioje bus modernizuota E. Sveikatos sistema, veikiančių aplikacijų slaptų duomenų valdymo infrastruktūrą (priemonės, komponentai);

9.6. Specialiųjų sąlygų Platformos diegimo reikalavimai 52 punkte numatyta, kad „Tiekėjas turi sukonfigūruoti integracijas su CI / CD įrankiais, konteinerių registru, vartotojo sąsaja, rodančia visus sprendime įdiegtus konteinerių klasterius, ir jų pažeidžiamumų ataskaitas. Sukonfigūruoti bendro duomenų sluoksnio (angl. Persistent storage) formavimo programinę įrangą. Sukonfigūruoti integracijas su įsigyta ir esama infrastruktūra: DNS, NTP, SSO, Srauto paskirstymo įranga)“ ir t.t., kas leidžia daryti išvadą, kad perkama Programa turi turėti galimybę integruoti daug skirtingų komponentų, kurie turi būti suderinami tarpusavyje, kad būtų pasiekti projekto tikslai - pilnai automatizuotai diegiama, vystoma, prižiūrima ir saugi E.sveikatos paslauga;

9.7. Techninės specifikacijos 17 punktas numatė, kad virtualizacijos platformoje Aplikacijų veikimo tęstinumui ir saugumui užtikrinti planuojami tokie sprendimai: 17.1. Git tipo pirminio kodo valdymo sistema; 17.2. Automatizuoto infrastruktūros diegimo ir valdymo sistema; 17.3. Konteinerio atvaizdų (angl. container image) registras; 17.4. Aplikacijų tiekimo grandinės patikros įrankiai; 17.5. Aplikacijų nuolatinio integravimo, pateikimo ir diegimo (CI/CD) įrankiai, 17.6. Privilegijuotų paskyrų prieigos valdymo sistemos bei ginčo 17.7.  „Aplikacijų jautrios informacijos saugojimo priemonės (angl. secret store/vault)“; Techninės specifikacijos 2.1. papunktyje numatyti Reikalavimai konteinerizavimo platformai, kurios 22 punkte numatyta, kad platforma turi turėti šias arba lygiavertes savybes ir funkcionalumus, tarp jų 22.8 papunktyje: „Automatizuoto konfigūracijos valdymo“;

9.8. Pirkimo sąlygų 12 punktas numatė, kad “Platforma turi būti suprojektuota atsižvelgiant į saugumą, įtraukiant geriausias saugos praktikas, pvz., mažiausių reikiamų privilegijų prieigą, saugius ryšio protokolus ir saugų duomenų saugojimą. Įtaisytosios (angl. Built-in) Arsaugos funkcijos, pvz., tinklo politikos, paslapčių valdymas ir rolėmis pagrįstas prieigos valdymas (RBAC), reikalingos siekiant užtikrinti, kad aplikacijos ir paslaugos būtų saugios pagal nutylėjimą. Platforma turi turėti galimybę būti integruota su esamais saugos įrankiais ir paslaugomis, tokiomis kaip tapatybės ir prieigos valdymo (IAM) sistemos, kad būtų užtikrinta vieninga saugumo pozicija. Taip pat platforma turi gebėti teikti beveik realaus laiko saugumo stebėjimo ir įspėjimo galimybes, užtikrinančias, kad saugumo incidentai būtų greitai aptikti ir į juos būtų reaguojama, o 13 punktas, kad „Platforma turi palaikyti nulinio pasitikėjimo saugos modelį, kai visas gaunamas ir išeinantis srautas yra autentikuojamas, autorizuojamas ir šifruojamas, neatsižvelgiant į siuntėją ar adresatą. Detalus prieigos valdymas yra būtinas siekiant užtikrinti, kad kiekvienas komponentas, aplikacija ar paslauga turėtų mažiausiai prieigos teisių, reikalingų veikimui užtikrinti. Todėl visi perduodami ar saugomi duomenys turi būti užšifruoti ir apsaugoti nuo neautorizuotos prieigos“;

9.9. Kaip jau buvo nurodyta, Ieškovas ginčo pirkimui pasiūlė jautrių duomenų saugojimo pasiūlymą - sprendimą  Red Hat Ansible Automation Platform parengtą Programinė įrangą, teigdamas, kad ji atitinka visas geriausias praktikas (TS 12 ir 13 p.). Atsakovo Komisija, išanalizavusi Ieškovo pasiūlyme pateiktus komponentus padarė pagrįstą išvadą, kad nurodoma programinė įranga valdo jautrią informaciją, operuoja ja, tačiau nesaugo jautrios informacijos - neturi saugyklos (angl.Vault) funkcionalumo, o saugojimui naudoja išorines saugyklas (taip pat turi šifravimo funkcionalumą, kuri padeda apsaugoti jautrią informaciją). Komisija nurodė, kad Ansible Vault neturi savyje specializuotos saugyklos jautriai informacijai saugoti, todėl neįmanoma ir automatizuotai valdyti jautrios informacijos saugojimo (TS 22.8. p. reikalavimas dėl automatizuoto konfigūracijos valdymo)." 

9.10.  Sutiktina su Atsakovu bei Trečiuoju asmeniu, kad TS 17.7 p. p. nustatytas papildomas valdymo komponentas „Aplikacijų jautrios informacijos saugojimo priemonė (angl. secret store / vault)" turėtų būti įdiegiamas sistemoje kaip atskiras komponentas, o ne kaip integruota ar vidinė kitos sistemos funkcija, nes „secret store / vault" savo prasme turi būti suprantama kaip atskira jautrios informacijos saugykla, kurios savo pasiūlyme pirkimui Ieškovas nebuvo įdiegęs, dėl ko nėra galimybės realizuoti konteinerizavimo platformos  22.8 papunktyje numatyto sistemos funkcionalumo „Automatizuoto konfigūracijos valdymas“. Kaip jau buvo pasisakyta, Techninės specifikacijos 17.7. papunktyje numatyta, kokie komponentai ir pagal kokius kriterijus turi būti įdiegti, o  Techninės specifikacijos 22.8. papunktyje nurodyta, kaip ši infrastruktūra turi būti diegiama ir valdoma, kad būtų užtikrintas automatizavimas, atsekamumas ir valdymo kontrolė visai sistemai funkcionuojant. Techninės specifikacijos 22.8. papunktis yra svarbus technologinis ir funkcinis mechanizmas, leidžiantis realiai įgyvendinti Techninės specifikacijos 17.7 papunktyje  nustatyto funkcionalumą – saugojimą aplikacijų jautrią informaciją, todėl teismas daro išvadą, kad Atsakovo Pirkimo komisija pagrįstai Ieškovo pasiūlymą pripažino neatitinkančiu pirkimo TS reikalavimų;

9.11. Įvertinus Sprendimo 9.9. punkte padarytą išvadą kad Ieškovo ginčo pirkimui pasiūlyta programinė įranga nors ir valdo jautrią informaciją, operuoja ja, tačiau nesaugo jautrios informacijos - neturi saugyklos (angl.Vault) funkcionalumo darytina sekanti išvada, kad Ieškovo pasiūlytą Programinė įranga neatitinka ir Lietuvos Respublikos Vyriausybės 2018 m. rugpjūčio 13 d. nutarimo Nr. 818 „Dėl Lietuvos Respublikos kibernetinio saugumo įstatymo įgyvendinimo“ reikalavimų, kurie taikomi Atsakovui, kaip svarbiam kibernetinio saugumo subjektui. LRV nutarimo priede „Kibernetinio saugumo reikalavimų aprašas“ 7 lentelės 76 punkte yra numatyta, kad draudžiama saugoti aplikacijų sąsajas, raktus ir kitas paslaptis programiniame kode arba atskiruose failuose, kuriuos atskleidus gali būti pasinaudota prieiga prie įrenginių, resursų, paskyrų ar valdiklių;

9.12. Ieškovas dublike nepagrįstai teigė, kad aplinkybė, ar ginčo pirkimui Ieškovo pasiūlytą Programa jautrios informacijos saugojimo funkciją atlieka saugodama jautrią informaciją ne izoliuotoje ar izoliuotoje saugykloje neturi teisinės reikšmės, nes Atsakovas pasirinko Pirkimo dokumentuose tokio reikalavimo (pvz., saugoti duomenis tik izoliuotoje saugykloje - secret vault) nekelti nei formuluodamas pozityviąsias (t. y. formuluodamas reikalavimus, kuriuos turi atitikti pirkimo objektas), nei negatyviąsias (t. y. formuluodamas draudimus pirkimo objekto savybėms) sąlygas.  Toks Ieškovo motyvas negali būti pripažintas pagrįstu, nes bylos medžiaga nustatyta ir nurodyta, kad šioje byloje nagrinėjamas Atsakovo 2025-11-04 paskelbtas pirkimas (Pirkimo Nr. (duomenys neskelbtini)) prieš tai jau buvo nutrauktas, sukonkretinant šio Pirkimo Techninės specifikacijos sąlygas, Schemoje papildomai nurodant schemos elementą Pav. 1.; ffĮ Secret / Vault: bei Techninės specifikacijos sąlygą dėl 17.7. papunkčio įgyvendinimo dėl jautrios informacijos saugojimo reikalavimų, kas teismui leidžia daryti išvadą, kad  Perkančiosios organizacijos Atsakovo siekis buvo įsigyti programą kurioje komponentas „Aplikacijų jautrios informacijos saugojimo priemonės (angl. secret store / vault)" turi būti įgyvendinamas kaip atskirai diegiamas komponentas būtent secret/vault, o ne kaip integruota ar vidinė kitos sistemos funkcija ir ši aplinkybė Ieškovui, kaip savo srities profesionalui, turėjo būti ir suprantama;

9.13. Sutiktina su Atsakovu ir Trečiuoju asmeniu, kad Ieškovas, kaip savo srities profesionalas, turintis ilgametę veiklos patirtį ir būdamas gerai informuotas ir normaliai rūpestingas tiekėjas, suvokė ir negalėjo nesuvokti, kad Atsakovo Perkančioji organizacija, nutraukdama ankstesnį pirkimą ir paskelbdama naują pirkimą, t.y. ginčo Pirkimą( Pirkimo Nr. (duomenys neskelbtini)), TS 17.7 punktu ir siekė įsigyti aplikacijų jautrios informacijos saugojimo priemones (angl. secret store / vault)", kurios turėtų būti įdiegiamos sistemoje kaip atskiras komponentas, o ne kaip integruota ar vidinė kitos sistemos funkcija. Būtent toks sprendinys ir atitinka TS 1.3 punktas numatytus reikalavimus, užtikrinti įsigyjamos Programos reikalingus sprendimus, t.y. „Aplikacijų veikimo tęstinumui ir saugumui užtikrinti planuojami tokie sprendimai: turėtų būti automatizuotai tikrinama pirminio kodo kokybė, aplikacijų kūrimas iš pirminio kodo (angl. build) turėtų būti automatizuotas ir saugus“, todėl TS 17.7 p. numatytas reikalavimas, pagal kurį turės būti įdiegta programinė įranga, skirta užtikrinti jautrios informacijos valdymą ir saugojimą iš skirtingų programinių įrangų, t. y. visų platformoje, kurioje bus modernizuota E. Sveikatos sistema, veikiančių aplikacijų slaptų duomenų valdymo infrastruktūra (priemonės, komponentai), kaip, kad numatyta TS 22.8. p. reikalavime dėl automatizuoto konfigūracijos valdymo;

9.14. Pripažintinas nepagrįstu ieškinio motyvas, kad TS 17.7 p. pateiktos sąvokos „secret store“ (jautrios informacijos saugojimas savyje) ir „secret vault“ (jautrios informacijos saugojimas išorinėje saugykloje) turi būti aiškinamos kaip alternatyva viena kitai, todėl Ieškovo pasiūlyta Programinė įranga, turinti vidinę duomenų saugyklą savyje (angl. secret store), atitinka ir geriausias saugumo praktikas, tuo pačiu ir TS 12-13 punktus kadangi toks Ieškovo vertinimas yra nelogiškas ir prieštaringas, sudarantis sąlygas tiekėjams laisvai pasirinkti skirtingus šio papunkčio reikalavimo įgyvendinimo būdus, t.y. skirtingus technologinius sprendimus, neapibrėžiant jų funkcinio turinio, o be to, ginčo pirkimo Specialiųjų pirkimo sąlygų 1.9 punkte nurodyta, kad „Pirkime neleidžiama pateikti alternatyvių pasiūlymų“, tuo labiau, kad ginčo pirkimo sąlygose (Schemos 1 paveikslas bei Techninės specifikacijos 17.7. papunkčio formuluotė) ir nebuvo numatyta galimybė saugoti jautrią Atsakovo informaciją išorinėje saugykloje;

9.15. Informacija (angl. secret /sensitive) nagrinėjamo pirkimo kontekste, teismo vertinumu, reiškia programinių įrangų slaptų duomenų (pvz., slaptažodžių, API raktų, prieigos žetonų, sertifikatų ar kitų autentifikavimo kredencialų) saugojimą, saugų apsikeitimą ir valdymą. Būtent šiuo reikalavimu Atsakovas siekė, kad tiekėjų siūloma programinė įranga užtikrintų jautrios informacijos, tokios kaip slaptažodžiai, API raktai ir kt., saugojimą ir apsikeitimą su kitomis aplikacijomis (kitomis programinėmis įrangomis), todėl įgyvendinant Techninės specifikacijos 17.7. papunkčio reikalavimus, jautri informacija turės būti saugoma atskirai diegiamame komponente, o ne kaip integruota ar vidinė kitos sistemos funkcija, ir tokia sąlyga buvo suprantamai išreikšta Schemos Paveiksle 1.; ffĮ Secre

                                                                                Vault:

9.16. Teismas, įvertinęs TS 17.7 p. formuluotę daro išvadą, kad Ieškovas nepagrįstai teigia, kad reikalavimas dėl jautrios informacijos saugojimo atskiroje, nuo platformos izoliuotoje, saugykloje nebuvo numatytas nei TS reikalavimuose, nei Platformos komponentų architektūros schemoje, pateiktoje TS 1 paveikslėlyje, todėl darytina išvada, kad Ieškovo pateiktas pasiūlymas Atsakovo organizuojame Pirkime neatitiko TS 17.7 papunkčio bei TS 22.8. papunkčio reikalavimų, todėl Atsakovo Pirkimo komisijos 2026-02-24 raštu „Dėl gautos pretenzijos“ pagrįstai atmetė Ieškovo Pretenziją, todėl Ieškovo ieškinys kaip nepagrįstas atmestinas. 

Dėl bylinėjimosi išlaidų ir laikinųjų apsaugos priemonių

10. Šaliai, kurios naudai priimtas sprendimas, jos turėtas bylinėjimosi išlaidas teismas priteisia iš antrosios šalies, nors ši ir būtų atleista nuo bylinėjimosi išlaidų mokėjimo į valstybės biudžetą. (CPK 93 straipsnio 1 dalis). Bylinėjimosi išlaidų paskirstymo taisyklės yra sureguliuotos taip, kad būtų užtikrinta šalies, laimėjusios bylą, teisė į bylinėjimosi išlaidų atlyginimą. Pagrindas, pagal kurį yra nustatoma laimėjusioji šalis ir atitinkamai paskirstomos bylinėjimosi išlaidos, pirmosios instancijos teisme yra ieškiniu pareikštų materialiųjų reikalavimų išsprendimo rezultatas. Ieškinio nepatenkinus, vadovaujantis bylinėjimosi išlaidų paskirstymo principu „pralaimėjęs moka“, trečiojo asmens patirtos bylinėjimosi išlaidos priteistinos iš Ieškovės. Atsakovas nepateikė teismui patirtų bylinėjimosį išlaidų.

11. Iki bylos išnagrinėjimo iš esmės pabaigos trečiasis asmuo UAB „Noviiom Technologies“ pateikė teismui prašymą priteisti iš ieškovės 14 616,61 Eur advokato teisinės pagalbos išlaidų, pateikė teismui įrodymus, patvirtinančius patirtų bylinėjimosi išlaidų dydį bei faktą, pateikė bylinėjimosi išlaidų apskaičiavimą pagal pridedamas PVM sąskaitas faktūras ir Atliktų darbų išklotines (Prašymo 1-2 priedai).

12. Teismas, atsižvelgdamas į šios civilinės bylos sudėtingumą, Trečiajam asmeniui suteiktų teisinių paslaugų, procesinių dokumentų apimtis ir jų kokybę, daro išvadą, kad pateiktų išlaidų, susijusių su advokato pagalba, dydis neviršija Lietuvos Respublikos teisingumo ministro 2004-04-02 įsakymu Nr. 1R-85 patvirtintose rekomendacijose rekomenduojamų dydžių, yra pagrįstas ir nemažintinas. Atsižvelgiant į tai, kad Trečiasis asmuo buvo Atsakovo pusėje ir palaikė bendrą ieškinio nepripažinimo poziciją, įrodinėjo Ieškovo pateikto pasiūlymo neatitikimą nustatytiems reikalavimams, atmestus Ieškinį, turi teisę į patirtų bylinėjimosi išlaidų atlyginimą.

13. Vadovaujantis CPK 150 straipsniu, teismo 2026-03-09  nutartimi taikytos laikinosios apsaugos priemones paliktinos galioti iki šio sprendimo įsiteisėjimo.

        Teismas, vadovaudamasis Lietuvos Respublikos civilinio proceso kodekso 93 straipsniu, 150 straipsniu, 269-271, 423 1-8  straipsniais,

n u s p r e n d ė :

1.Atmesti ieškovo UAB „Blue Bridge MSP“ ieškinį Atsakovui VĮ Registrų centras, Trečiasis asmuo Atsakovo pusėje UAB „Novian Technologies“ dėl Atsakovo priimto Sprendimo viešajame tarptautiniame pirkime „ESPBI IS modernizavimo (dekomponavimo) projekto programinės įrangos ir programinės įrangos konfigūravimo paslaugų pirkimas (Pirkimo Nr. (duomenys neskelbtini)) panaikinimo.

2. Priteisti iš Ieškovo UAB „Blue Bridge MSP“ (JAK 301489547) Trečiajam asmeniui UAB „Noviiom Technologies“ (JAK 301318539) 14 616,61 Eur patirtų advokato teisinės pagalbos išlaidų apmokėjimui.

3. Panevėžio apygardos teismo 2026 m. kovo 9 d. nutartimi taikytas laikinąsias apsaugos priemones palikti galioti iki šio sprendimo įsiteisėjimo.

        Sprendimas per 14 dienų apeliaciniu skundu gali būti skundžiamas Lietuvos apeliaciniam teismui, apeliacinį skundą paduodant Panevėžio apygardos teisme.

Teisėjas                                                                Laimantas Misiūnas