Decizie CNSC BO2026_3416

Pagina 1 din 80 În conformitate cu prevederile art. 14 alin. (2) și ale art. 27 alin. (1) din Legea nr. 101/2016 privind remediile și căile de atac în materie de atribuire a contractelor de achiziție publică, a contractelor sectoriale și a contractelor de concesiune de lucrări și concesiune de servicii, precum și pentru organizarea și funcționarea Consiliului Național de Soluționare a Contestațiilor, cu modificările și completările ulterioare, Consiliul adoptă următoarea DECIZIE Nr. 3416/C6/3388 Data: 22.10.2026 Prin contestația nr. 1369/17.08.2026, înregistrată la CNSC cu nr. 62324/18.08.2026, formulată de către ......... SRL, cu sediul în ........., ........., ........., și sediul ales pentru transmiterea corespondenței în ........., ...., înregistrată la Registrul Comerțului sub nr. ........., având CUI ........., reprezentată prin administrator ..... SRL, prin reprezentant legal ...., împotriva documentației de atribuire, întocmită de către ........., cu sediul în ........., ........., ........., în calitate de autoritate contractantă, în cadrul licitației deschise, organizată în vederea atribuirii contractului de Servicii de dezvoltare a Sistemului Informatic Integrat în cadrul proiectului „Sistem Informatic pentru Gestionarea Fondului Forestier Administrat de Romsilva” Cod SMIS 348488, anunț de participare nr. CN1095145/06.08.2026, s-a solicitat: • în principal, obligarea autorității contractante la remedierea aspectelor din documentația de atribuire ca fiind restrictive, disproporționate și nelegale, astfel încât să permită derularea procedurii de achiziție publică în condiții de deplină legalitate și concurență reală; • în subsidiar, în eventualitatea în care nu s-ar mai putea dispune măsuri de remediere, anularea procedurii, în conformitate cu prevederile art. 212 alin. (1) lit. d) și alin. (2) din Legea nr. 98/2016; • cu titlu preliminar, dispunerea măsurii suspendării procedurii de atribuire, în conformitate cu prevederile art. 22 din Legea nr. 101/2016, până la soluționarea contestației. Cererea de suspendare a procedurii de atribuire a fost respinsă, ca nefondată, de Consiliu prin Încheierea nr. 3207/C6/3388 din data de 24.08.2026. CONSILIUL NAȚIONAL DE SOLUȚIONARE A CONTESTAȚIILOR, asupra cauzei de față, constată următoarele:

Pagina 2 din 80 Consiliul a fost legal sesizat și este competent, potrivit dispozițiilor art. 12 alin. (1) din Legea nr. 101/2016, să soluționeze contestația de față, prin care ......... SRL solicită cele menționate în partea introductivă a deciziei. Precizează că, în urma analizei documentației de atribuire, a constatat existența mai multor aspecte pe care le consideră restrictive, disproporționate și nelegale, structurate pe patru categorii: neconcordanțe și deficiențe de claritate ale documentației de atribuire (secțiunea A), specificații tehnice redactate cu încălcarea principiilor nediscriminării și proporționalității (secțiunea B), o grilă de punctaj tehnic lipsită de transparență și de granularitate obiectivă (secțiunea C), și cerințe disproporționate privind personalul-cheie (secțiunea D). Motivarea integrală a contestației se regăsește în fișierul [CN1095145/00028] Contestatie_CN1095145_Romsilva.pdf, postat de autoritatea contractantă în SEAP la 19.08.2026, în cadrul documentelor asociate anunțului de participare nr. CN1095145/06.08.2026. Reproducerea în cuprinsul deciziei a ansamblului motivării nu se justifică, din moment ce întreaga contestație poate fi vizualizată liber și gratuit în SEAP de către orice persoană interesată. Sintetizarea de mai sus a contestației nu prejudiciază nici părțile și nici terții, din moment ce oricine are la dispoziție spre vizualizare și descărcare, prin intermediul SEAP, întreaga contestație. Dimpotrivă, reproducerea unui volum foarte mare de argumente, ar încărca excesiv și, astfel, ar îngreuna parcurgerea prezentei decizii. Desigur, motivarea completă va fi avută în vedere de membrii completului la adoptarea soluției. ........., prin adresa nr. 15315/24.08.2026, înregistrată la Consiliu sub nr. 64141/25.08.2026, a formulat punct de vedere raportat la contestația depusă de ......... SRL, prin care solicită respingerea pe fond, în totalitate, a contestației ca neîntemeiată și menținerea documentației de atribuire în forma publicată, cu clarificările care vor fi aduse prin Răspunsul consolidat la solicitările de clarificări, ce urmează a fi postat până la data de 27.08.2026, conform fișei de date Cap.VI.3., pentru următoarele motive: În susținerea acestor solicitări, prezintă următoarele argumente de fapt și de drept: I. ARGUMENTE TEHNICE ȘI JURIDICE PE FONDUL CONTESTAȚIEI: A. Neclaritatea și incoerența internă a documentației de atribuire A.1. Nelegalitatea documentației de atribuire prin raportare la contradicția dintre structura tranșelor de plată prevăzută în fișa de date, Formularul F1A financiar și modelul de contract, respectiv structura documentelor de recepție impuse la art. 26.3 din modelul de contract: 1. Cu privire la pretinsa nelegalitate a documentației de atribuire prin raportare la structura tranșelor de plată prevăzută în fișa de date, Formularul F1A financiar și modelul de contract, respectiv structura documentelor de recepție impuse la art. 26.3 din modelul de contract (A.1), contestatoarea susține că ar exista o necorelare structurală între: - structura celor patru tranșe de plată (fișa de date pct. III.1.7 și art. 4.1 din modelul de contract); - Formularul F1A - propunerea financiară detaliată (care nu conține poziții distincte pentru „Document de analiză de business" și „Document de proiectare");

Pagina 3 din 80 - cele două livrabile distincte individualizate în caietul de sarcini (1.1 analiză de business detaliată și 1.2 document de proiectare); - cele șapte procese-verbale de recepție prevăzute la art. 26.3 din modelul de contract, și, pe această bază, solicită ........., invocând art. 3 lit. z) și art. 154 alin. (1) din Legea nr. 98/2016, precum și art. 20 din HG nr. 395/2016. Solicită respingerea acestui capăt de cerere ca neîntemeiat, pentru următoarele motive de fapt și de drept: Formularul F1A are o structură fixă, iar adăugarea de poziții ori rânduri suplimentare nu este permisă, pentru a menține comparabilitatea unitară a ofertelor financiare. Toate activitățile și componentele software solicitate prin caietul de sarcini care nu figurează pe rânduri dedicate se vor include și cota în cadrul pozițiilor existente ale formularului, astfel: Documentul de analiză de business și proiectare: Costul aferent elaborării acestei documentații se include la poziția «Servicii de dezvoltare». Acest livrabil reprezintă prima etapă a procesului de dezvoltare/implementare și constituie baza pentru plata Tranșei 1 (20% din valoarea serviciilor de dezvoltare și implementare). Nu există nicio ambiguitate cu privire la modul de cotare a celor două livrabile (analiză de business + proiectare). Ele se ofertează cumulat în cadrul poziției „Servicii de dezvoltare" din Formularul F1A, iar valoarea Tranșei 1 reprezintă 20% din valoarea totală a acestei poziții (plus eventualele componente de dezvoltare aferente). Deși caietul de sarcini detaliază două sub-activități (1.1 analiză de business detaliată și 1.2 document de proiectare), acestea formează un singur livrabil complex, care constituie baza Tranșei 1. În opinia sa, această abordare este consistentă cu practica standard în proiectele de dezvoltare software de complexitate ridicată: analiza de business și proiectarea tehnică sunt etape succesive și interdependente ale aceleiași faze de inițiere a proiectului. Separarea lor valorică artificială în Formularul F1A ar fi generat riscuri de necorelare și de dificultăți în evaluarea comparabilității ofertelor. Faptul că art. 26.3 din modelul de contract prevede procese-verbale distincte pentru recepția raportului de analiză și pentru recepția documentației de proiectare nu transformă aceste documente în jaloane de plată independente. Ele reprezintă etape de control al calității în cadrul aceleiași Tranșe 1. Plata Tranșei 1 devine exigibilă numai după ce ambele documente au fost acceptate fără observații (sau după remedierea observațiilor, conform regulilor de recepție din Cap. 13), conform formulării exprese din caietul de sarcini: „acceptat fără observații de autoritatea contractantă". Raportul dintre cele patru tranșe de plată și cele șapte procese-verbale de recepție de la art. 26.3 din contract: cele patru tranșe de plată (analiză/proiectare - licențe - dezvoltare software - instruire) definesc jaloanele financiare ale contractului, iar cele șapte procese-verbale de la art. 26.3 definesc documentele de recepție cantitativă și calitativă necesare pentru a atesta îndeplinirea prestațiilor aferente fiecărei tranșe. Nu există contradicție, ci o relație de tip „condiție de plată - document justificativ":

Pagina 4 din 80 - Tranșa 1 - recepția raportului de analiză + recepția documentației de proiectare (lit. b și c din Art. 26.3); - Tranșa 2 - proces-verbal de recepție cantitativă și calitativă pentru livrarea și instalarea componentelor software (lit. a); - Tranșa 3 - proces-verbal de recepție pentru serviciile de dezvoltare software + proces- verbal de recepție a raportului de testare (lit. d și e); - Tranșa 4 - proces-verbal de recepție a raportului de instruire (lit. f). Procesul-verbal de recepție a raportului de punere în producție (lit. g) și procesul-verbal de recepție finală (prevăzut la pct. 13.4 din caietul de sarcini) reprezintă condiții de acceptanță finală a sistemului, nu jaloane de plată distincte. Ele condiționează, în mod logic, plata ultimei tranșe și eliberarea eventualelor garanții, fără a crea o a cincea tranșă. Această structură este coerentă, transparentă și conformă cu principiile de gestionare a contractelor de dezvoltare software complex. Absența încălcării art. 154 alin. (1) din Legea nr. 98/2016 și a art. 20 din HG nr. 395/2016, documentația de atribuire asigură operatorilor economici o informare completă, corectă și precisă cu privire la: - modul de formare a prețului; - jaloanele de plată (cele patru tranșe); - documentele care atestă recepția și condiționează exigibilitatea plăților (Art. 26.3 + Cap. 13 din caietul de sarcini). Nu există nicio neclaritate sau ambiguitate care să afecteze elaborarea propunerii financiare sau comparabilitatea ofertelor. Orice operator economic diligent poate stabili, pe baza clarificărilor publicate, modul exact de cotare și de facturare. De altfel, în opinia sa, argumentul privind riscul de litigii în executare este speculativ. Afirmația contestatoarei potrivit căreia lipsa unei defalcări valorice distincte ar genera litigii pe durata executării contractului este pur ipotetică. Regulile de recepție (Cap. 13), mecanismul de acceptanță „fără observații" și termenele de remediere sunt stabilite clar. Tranșa 1 devine facturabilă numai după semnarea procesului-verbal de recepție cu calificativul „acceptat fără observații". Ca și concluzie cu privire la capătul de cerere A.1: Necorelarea invocată nu există. Documentația stabilește în mod clar: - că cele două livrabile (analiză + proiectare) se ofertează cumulat în poziția „Servicii de dezvoltare" din Formularul F1A; - că Tranșa 1 reprezintă 20% din valoarea serviciilor de dezvoltare și implementare și se plătește la acceptarea fără observații a ambelor documente; - că cele șapte procese-verbale de la Art. 26.3 sunt documente de recepție care susțin cele patru tranșe de plată, fără a crea jaloane financiare suplimentare. Argumente pentru respingere: - Ofertanții trebuie să completeze fiecare element din Formularul nr. 1A (Propunerea financiară detaliată), fără a adăuga poziții suplimentare, menținându-se structura prezentată în documentația de atribuire. - Următoarele: a) Documentul de analiză de business și proiectare (în care se vor prezenta rezultatele activității de analiză de business detaliată, precum și un document

Pagina 5 din 80 de proiectare sistem informatic), este parte din prima etapă a procesului de dezvoltare/implementare), b) Serviciile de tip SOC, solicitate 24/7 pe toată perioada de garanție, c) Serviciile de garanție și suport tehnic pe 3 ani și d) Soluția de management al vulnerabilităților, furnizată ca serviciu pe toată durata contractului, sunt incluse în capitolul bugetar „SERVICII DE DEZVOLTARE Șl IMPLEMENTARE" și nu se vor bugeta separat. - Aplicația software de instruire (e-learning) este inclusă în capitolul bugetar „SERVICII DE INSTRUIRE/FORMARE PROFESIONALĂ SPECIFICĂ" și nu se vor bugeta separat. - Conform modelului de contract, prețul contractului (pe baza a patru componente) este similar cu structură de patru tranșe de plată (confirmată la pct. III.1.7 din fișa de date). - formularul de propunere financiară nu conține livrabilele „DOCUMENT DE ANALIZĂ DE BUSINESS - Prestatorul va prezenta rezultatele activității de analiză de business detaliată", respectiv „DOCUMENT DE ANALIZĂ DE BUSINESS Șl PROIECTARE - Prestatorul va prezenta un document de proiectare sistem informatic", întrucât acestea sunt parte din prima etapă a procesului de dezvoltare/implementare. - Chiar dacă sunt livrabile distincte, acestea nu se vor bugeta separat. - Recepția separată a raportului/documentului de analiză și a documentației tehnice aferente activității de modelare/proiectare nu înseamnă automat și alte tranșe de plată distincte. - Tranșa 1 de plată se va efectua după recepția integrală a etapei: Servicii de dezvoltare. - Operatorii economici nu au, în structura actuală a Formularului F1A, un mecanism prin care să aloce valoric livrabilele. - Art. 4.1.1 din modelul de contract stabilește Tranșa 1 ca procent fix (20% din valoarea serviciilor de dezvoltare și implementare), iar nu ca sumă calculată pe bază de prețuri unitare separate. Mecanismul de procentaj este autosuficient: ofertantul include costul activităților de analiză și proiectare în cadrul prețului global al „serviciilor de dezvoltare" (poziția 2.1 din F1A), fără a fi necesară o linie de preț distinctă, exact așa cum, în orice contract de servicii complexe, etapele pregătitoare (analiză, proiectare) sunt uzual incluse în prețul global al fazei de dezvoltare, nu facturate separat; - Cele șapte documente menționate la art. 26.3 din contract sunt instrumente de control calitativ și de recepție intermediară (dovezi ale prestării corespunzătoare), nu tranșe de plată suplimentare. Nu există nicio normă legală care să impună o corespondență biunivocă între fiecare document de recepție și fiecare tranșă de plată; este uzual și legal ca mai multe verificări/recepții parțiale să preceadă și să documenteze o singură plată aferentă unei tranșe; - Caietul de sarcini respectă art. 3 lit. z) și art. 154 alin. (1) din Legea nr. 98/2016, care impun o informare „completă, corectă și explicită" cu privire la cerințele achiziției (standard pe deplin atins prin structura actuală), care indică fără echivoc cele patru tranșe, procentele/momentele de plată și obiectul fiecărei tranșe. Legea nu impune, suplimentar, cel mai ridicat nivel posibil de

Pagina 6 din 80 granularitate a defalcării financiare pe fiecare sublivrabil în parte, nu este o cerință legală obligatorie; - F1A nu impune ofertarea de produse separate, ci detalierea costurilor pe componente funcționale. Prin urmare, consideră că acest capăt de cerere este neîntemeiat și trebuie respins. B. Specificațiile tehnice sunt redactate pornind de la produse comerciale determinate, cu încălcarea art. 155 și art. 156 din Legea nr. 98/2016 și impun, în mod restrictiv, ofertarea exclusiv a componentelor de tip COTS B.1. Componenta de gestionare a bazelor de date, arhitectura de tip cluster activ-activ fără achiziția de componente adiționale: Contestatoarea critică cerința din Cap. 5.4.4 al caietului de sarcini, potrivit căreia: „trebuie să permită instalarea bazei de date pe mai multe noduri (arhitectura de tip cluster), in regim activ-activ, pentru a asigura toleranta la căderi de noduri, fără a necesita achiziția de componente adiționale", și susține că cerința ar fi restrictivă, întrucât ar limita ofertele la doar două produse COTS (Oracle Database cu Real Application Clusters și IBM Db2 pureScale), că nici măcar aceste produse nu ar fi compatibile cu Azure Stack Hub (mediul de implementare din Cloudul Privat Guvernamental) și că, prin coroborare cu cerința de software comercial (COTS), s-ar încălca art. 155 alin. (6) și art. 156 alin. (2)-(3) din Legea nr. 98/2016. Solicită respingerea acestui capăt de cerere ca neîntemeiat, pentru următoarele motive de fapt și de drept: a) Cerința este formulată în termeni de performanță și funcționalitate, nu prin trimitere la un produs determinat Cerința nu indică niciun producător, nicio marcă și niciun produs concret. Ea definește un rezultat funcțional clar și obiectiv: posibilitatea instalării bazei de date pe mai multe noduri, în regim activ-activ, cu toleranță la căderi de noduri, fără achiziția de componente software adiționale. Această formulare se încadrează perfect în dispozițiile art. 156 alin. (1) lit. a) din Legea nr. 98/2016, care permit autorității contractante să definească specificațiile tehnice prin raportare la cerințe de performanță sau cerințe funcționale. Clauza generală „sau echivalent" din caietul de sarcini rămâne pe deplin aplicabilă. Orice soluție software care asigură nativ (fără componente suplimentare de la terți) capacitatea de cluster activ-activ îndeplinește cerința, indiferent de producător. b) Interpretarea extrem de restrictivă adoptată de contestatoare: Contestatoarea reduce în mod artificial cerința la doar două produse (Oracle RAC și IBM Db2 pureScale), pe baza unei interpretări tehnice foarte înguste a noțiunii de „activ-activ" (multi-master cu scrieri concurente pe toate nodurile asupra aceleiași baze de date). Este relevant faptul că însăși contestatoarea menționează Microsoft SQL Server în analiza sa, dar îl exclude pe motiv că arhitectura Always On Availability Groups ar fi „fundamental activ- pasivă" pentru operațiunile de scriere.

Pagina 7 din 80 Această excludere confirmă că pe piață există cel puțin o a treia soluție comercială majoră (SQL Server), pe care contestatoarea o înlătură doar prin adoptarea unei interpretări excesiv de restrictive a cerinței. Caietul de sarcini nu definește „activ-activ" în sensul tehnic extrem de multi-master cu scrieri simultane pe toate nodurile. Cerința vizează un rezultat funcțional - capacitatea de a rula pe mai multe noduri cu toleranță la căderi de noduri, fără componente adiționale - și nu un anumit mecanism intern de implementare. Piața modernă de sisteme de gestiune a bazelor de date comerciale (COTS) oferă multiple soluții care pot asigura regimuri de înaltă disponibilitate de tip activ-activ sau echivalente funcțional (inclusiv configurații multi-master, shared-nothing sau shared-disk cu failover automat și distribuție a sarcinii), în funcție de arhitectura aleasă de ofertant. Contestatoarea ignoră funcționalitățile native introduse de ani de zile în aceste motoare de baze de date, precum și modul de licențiere comercială al distribuțiilor Enterprise. MySQL oferă clustering multi-master NATIV: începând cu versiunea MySQL 5.7 și continuând în versiunile 8.x, Oracle a introdus MySQL InnoDB Cluster, care se bazează pe funcționalitatea MySQL Group Replication. Această tehnologie suportă nativ Multi-Primary Mode (unde toate nodurile din cluster sunt active și pot procesa scrieri concurente/active-active). Nu necesită „produse sau extensii de la terți", ci este o funcționalitate integrată (in the box) în distribuția standard MySQL. Referință oficială: Documentația oficială MySQL - MySQL Group Replication - Multi-Primary Mode. PostgreSQL (în varianta COTS/Enterprise) oferă clustering multi-master ca un singur produs: Dacă un ofertant propune EDB Postgres Distributed (anterior cunoscut ca BDR - Bi-Directional Replication), acesta nu achiziționează „componente adiționale de la terți". EDB Postgres Distributed este un singur produs comercial COTS furnizat de compania EnterpriseDB, care include atât motorul de bază de date, cât și clusteringul activ-activ nativ. Nu se încalcă nicio cerință din caietul de Sarcini, deoarece ofertantul ofertează produsul EDB direct, care conține funcționalitatea cerută out-of-the-box. Falsa premisă că Microsoft SQL Server este doar Activ-Pasiv: Afirmația contestatoarei: „Microsoft SQL Server oferă, prin arhitectura sa de tip Always On, mecanisme fundamental active-pasive... secundarele putând servi doar citiri, iar nu scrieri concurente". Deși caracteristica Always On Availability Groups este predominant utilizată pentru arhitecturi Active-Pasive (sau Active-Read), Microsoft SQL Server suportă de ani de zile scenarii active- active pentru scrieri concurente prin intermediul funcționalității Peer-to-Peer Transactional Replication. Aceasta permite ca datele să fie replicate și modificate concurent pe multiple noduri, asigurând arhitectura activ-activă necesară. c) Justificarea obiectivă a cerinței: Sistemul informatic face obiectul unui proiect de interes național, finanțat din fonduri europene, destinat gestionării fondului forestier administrat de .......... Datele prelucrate au un nivel ridicat de sensibilitate (informații privind proprietatea, masa lemnoasă, arii protejate, interacțiuni cu publicul și alte instituții).

Pagina 8 din 80 Asigurarea unei disponibilități ridicate și a toleranței la căderi de noduri la nivelul motorului de bază de date reprezintă o necesitate tehnică obiectivă, legată direct de continuitatea serviciilor publice și de protejarea integrității datelor. Cerința nu este arbitrară, ci proporțională cu riscurile operaționale și de securitate ale sistemului. d) Compatibilitatea cu Cloudul Privat Guvernamental (Azure Stack Hub): Contestatoarea afirmă că nici Oracle RAC, nici IBM Db2 pureScale nu ar fi compatibile cu Azure Stack Hub. În opinia sa, această afirmație nu atrage nelegalitatea cerinței, din următoarele motive: Cerința din Cap. 5.4.4 privește capacitatea software-ului de bază de date, nu o configurație hardware sau de rețea specifică pe care achizitoarea ar impune-o. Infrastructura de mașini virtuale/containere și soluția de disaster recovery sunt furnizate de Cloudul Privat Guvernamental. Ofertantul are obligația de a propune o soluție software care să poată rula în acest mediu, respectând constrângerile tehnice ale CPG, așa cum sunt ele publicate de administratorii infrastructurii. Avizul pozitiv emis de Comitetul Tehnico-Economic pentru Societatea Informațională (nr. 412CTE/18.06.2026) atestă că specificațiile tehnice, inclusiv cele referitoare la componenta de gestiune a datelor și la mediul de implementare, au fost analizate și avizate din perspectiva interoperabilității, securității și neutralității tehnologice. e) Cerința privind software-ul comercial (COTS): Cerința ca software-ul standard să fie oferit în versiune comercială (COTS) este justificată explicit în caietul de sarcini prin: - sensibilitatea datelor; - nivelul de securitate solicitat; - necesitatea asigurării de către producători a suportului tehnic pentru toate componentele funcționale, de securitate și de suport ale platformei. Această cerință este proporțională și se încadrează în dreptul autorității contractante de a stabili specificații care să garanteze un nivel adecvat de suport, mentenanță și responsabilitate pe durata de viață a sistemului (art. 155 alin. (1) și (2) din Legea nr. 98/2016). Nu există nicio obligație legală ca autoritatea contractantă să accepte soluții open-source atunci când, din rațiuni obiective de securitate și suport, a optat pentru produse comerciale. Absența încălcării art. 155 alin. (6) și art. 156 alin. (2)-(3) din Legea nr. 98/2016, cerința nu precizează un anumit producător, o anumită origine sau un anumit procedeu care ar avea ca efect favorizarea sau eliminarea anumitor operatori economici. Ea definește un nivel de performanță (cluster activ-activ nativ) justificat de obiectul contractului. Clauza „sau echivalent" este operabilă, iar contestatoarea nu a demonstrat că pe piață nu ar exista soluții alternative care să poată îndeplini cerința funcțională în mediul CPG. Ca și concluzie, arată că această cerință privind arhitectura de tip cluster activ-activ, fără componente adiționale, este: - formulată în termeni de performanță și funcționalitate; - justificată de criticitatea sistemului și de necesitatea asigurării continuității operaționale; - compatibilă cu principiul neutralității tehnologice;

Pagina 9 din 80 - deja validată prin Avizul pozitiv CTE nr. 412CTE/18.06.2026, confirmând astfel că specificațiile tehnice au fost analizate și avizate din perspectiva securității, interoperabilității și neutralității tehnologice. Interpretarea restrictivă propusă de contestatoare (reducerea pieței la doar două produse și incompatibilitatea absolută cu Azure Stack Hub) nu este susținută de realitatea tehnică a pieței și nu demonstrează caracterul nelegal al cerinței. Deci, capătul de cerere este neîntemeiat și trebuie respins. B.2. Cerința de portabilitate pe AWS, Azure și Google Cloud, la nivelul aceleiași componente de bază de date, este disproporționată în raport cu infrastructura fixă de implementare declarată în restul documentației Contestatoarea critică cerința din Cap. 5.4.4 al caietului de sarcini: „Componenta trebuie să ofere suport pentru instalarea in mod hibrid sau in cloud, pe oricare dintre platformele AWS, Azure, Google Cloud". Aceasta susține că cerința ar fi disproporționată și lipsită de legătură cu obiectul contractului, întrucât restul documentației stabilește că sistemul va fi implementat exclusiv în Cloudul Privat Guvernamental (CPG), pe tehnologia Azure Stack Hub. Pe această bază, solicită eliminarea cerinței de portabilitate pe AWS și Google Cloud, invocând principiul proporționalității (art. 2 alin. (2) lit. e) din Legea nr. 98/2016) și art. 156 alin. (3). Solicită respingerea acestui capăt de cerere ca neîntemeiat, pentru următoarele motive: a) Distincția esențială între mediul de implementare actual și capacitatea intrinsecă a produsului: Susține că sistemul care face obiectul prezentului contract va fi implementat în Cloudul Privat Guvernamental, pe infrastructura Azure Stack Hub. Această opțiune este stabilită de cadrul strategic național de digitalizare și de Contractul de finanțare. Cerința din Cap. 5.4.4 nu obligă însă ca sistemul să fie instalat efectiv pe AWS sau Google Cloud în cadrul acestui contract. Ea cere ca produsul software de gestiune a bazelor de date să dețină o caracteristică intrinsecă, capacitatea de a putea fi instalat și rulat pe oricare dintre cele trei platforme cloud majore (AWS, Azure, Google Cloud), inclusiv în regim hibrid. Cu alte cuvinte, cerința vizează portabilitatea și maturitatea tehnologică a produsului, nu locația efectivă de instalare din cadrul prezentului proiect. b) Justificarea obiectivă a cerinței - sustenabilitate și evitarea vendor lock-in pe termen lung: Are interesul legitim de a achiziționa o soluție de bază de date care: - să nu fie legată tehnologic exclusiv de un singur cloud public; - să permită, pe termen mediu și lung, eventuale migrări, scenarii hibride sau evoluții ale arhitecturii naționale de cloud; - să demonstreze un nivel ridicat de maturitate și de adoptare pe piețele cloud majore, ceea ce constituie un indicator al stabilității și al suportului pe termen lung oferit de producător. Această abordare este pe deplin conformă cu principiul utilizării eficiente a fondurilor publice și cu nevoia de a evita dependența tehnologică pe termen lung

Pagina 10 din 80 (vendor lock-in), chiar dacă, în prezent, implementarea se face pe Azure Stack Hub. c) Cerința nu este disproporționată Principiul proporționalității (art. 2 alin. (2) lit. e) din Legea nr. 98/2016) nu-i interzice să solicite caracteristici de portabilitate și de maturitate tehnologică superioare mediului de implementare imediat, ci doar impunerea de cerințe care nu au nicio legătură cu obiectul contractului sau care restrâng concurența într-un mod nejustificat, în speță: - cerința are legătură directă cu obiectul contractului (achiziția unei componente de gestiune a datelor robuste, sustenabile și portabile); - ea nu exclude automat produsele care rulează pe Azure Stack Hub; dimpotrivă, majoritatea soluțiilor comerciale mature de pe piață (inclusiv cele care rulează pe Azure) dețin certificări sau suport oficial pentru cel puțin două dintre cele trei platforme majore; - nu creează o barieră artificială, ci filtrează produsele cu un grad redus de portabilitate și de adoptare pe piețele cloud. d) Absenta contradicției cu restul documentației: Arată că nu există contradicție între: - obligația de a implementa sistemul în CPG (Azure Stack Hub) - care privește locația de instalare din cadrul acestui contract; - cerința ca produsul să suporte instalarea pe AWS, Azure și Google Cloud - care privește capacitatea intrinsecă a software-ului. Cele două prevederi se referă la planuri diferite (implementare actuală vs. caracteristici de produs) și pot coexista fără dificultate. În concluzie, menționează că cerința de portabilitate pe AWS, Azure și Google Cloud: - nu obligă la instalarea efectivă a sistemului pe aceste platforme în cadrul prezentului contract; - vizează capacitatea și maturitatea tehnologică a produsului de bază de date; - este justificată de nevoia de sustenabilitate, de evitarea dependenței tehnologice pe termen lung și de asigurarea unui nivel ridicat de suport din partea producătorului; - nu este disproporționată și nu încalcă principiile legii achizițiilor publice. Deci, capătul de cerere este neîntemeiat și trebuie respins. B.3. Componenta Server GIS este redactată pornind de la o soluție predeterminată, Esri ArcGIS Enterprise: Contestatoarea susține că specificațiile din Cap. 5.4.2.2.3 (Software Server GIS) și din capitolele conexe ar fi fost redactate pornind de la platforma Esri ArcGIS Enterprise, cu încălcarea art. 155 alin. (6) și art. 156 alin. (2)-(3) din Legea nr. 98/2016, iar în argumentare, invocă folosirea termenului „geodatabase", a conceptului de versiune „parent", menționarea aplicației „ArcGIS Field Maps sau echivalent" și includerea tehnologiilor Microsoft Silverlight și Adobe Flex. Solicită respingerea acestui capăt de cerere ca neîntemeiat, pentru următoarele motive: Acceptă soluții tehnice echivalente care asigură aceleași funcții, performanțe și capabilități tehnice, indiferent de denumirea comercială a formatelor, componentelor sau platformelor ofertate.

Pagina 11 din 80 Ofertantul va trebui să demonstreze în propunerea tehnică modul în care soluția echivalentă propusă atinge obiectivele funcționale și de performanță solicitate de achizitoare. Cerințele se citesc în cheie funcțională, iar soluțiile echivalente sunt acceptate. Contestatoarea afirmă că modelul de versionare cu „versiune parent" și reconcilierea conflictelor ar fi specific exclusiv arhitecturii Esri. Această afirmație este inexactă, deoarece capacitatea de a gestiona editarea multi-user a datelor geospațiale, cu crearea de versiuni derivate, reconcilierea modificărilor și rezolvarea conflictelor înainte de integrarea acestora în versiunea de bază (parent), reprezintă o funcționalitate enterprise standard, implementată de mai multe platforme GIS profesionale. Un exemplu concret este platforma Hexagon GeoMedia, suita Hexagon oferind mecanisme native de versionare a datelor geospațiale, de lucru concurent multi-user și de reconciliere a conflictelor între versiuni, permițând editorilor să își integreze modificările înapoi în versiunea de referință. Documentația oficială Hexagon privind gestionarea conflictelor în mediile multi-user și reconcilierea modificărilor este disponibilă, între altele, în resursele tehnice ale producătorului (de exemplu, documentația HxGN privind rezolvarea conflictelor în mediile de configurare și merge: https://docs.hexagonppm.eom/ r/en-US/HxGN-SDx-Help/1050366). Cerința nu este specifică unui singur producător, ci descrie o capacitate funcțională necesară, pe care o pot îndeplini mai multe soluții GIS enterprise. Chiar textul cerinței conține mențiunea expresă „sau echivalent". Un exemplu de soluție echivalentă este Hexagon GeoMedia WebMap Mobile, aplicație mobilă dedicată accesării, actualizării și editării datelor geospațiale din teren, cu suport pentru dispozitive iOS și Android, lucru online/offline și sincronizare cu platforma enterprise. Aplicația este publicată oficial de Hexagon (Intergraph Corporation, a Hexagon Company) și este disponibilă la adresa https://play.google.com/store/apps/details?id=com. intergraph.mobilemapworksadv&hl=en_US. Aceasta demonstrează că pe piață există soluții comerciale alternative care îndeplinesc același rezultat funcțional (colectare și actualizare de date forestiere direct de pe teren). Absența încălcării dispozițiilor legale: Specificațiile nu au ca efect favorizarea sau eliminarea nejustificată a operatorilor economici. Ele definesc capacități necesare unui sistem GIS enterprise complex. Avizul pozitiv CTE nr. 412CTE/18.06.2026 confirmă, de asemenea, că specificațiile tehnice au fost analizate din perspectiva securității, interoperabilității și neutralității tehnologice. Din punct de vedere tehnologic: - Termenul „Geodatabase" (Geo-Database): în ingineria geospațială modernă și în literatura de specialitate, termenul este o abreviere comună utilizată generic pentru a desemna un container sau o bază de date relațională cu capabilități spațiale (bază de date geografică). - Standardele deschise de piață (OGC): Formatul standardizat internațional OGC GeoPackage (.gpkg), precum și formatul SpatiaLite (stocare locală bazată pe SQLite), utilizate nativ de suita Open-Source QGIS și de biblioteca universală

Pagina 12 din 80 GDAL/OGR, oferă exact capabilitatea de stocare locală a datelor vectoriale și raster în fișiere unice de mare capacitate (până la terabytes), fără dependență de Esri. - Justificarea limitei de 1 TB: Volumul de 1 TB nu reprezintă o preluare de la vreun producător, ci este o cerință de dimensionare operațională a ROMSILVA. Având în vedere dimensiunile uriașe ale ortofotoplanurilor de înaltă rezoluție, hărților amenajistice și cadastrului forestier la nivel de ocol silvic, capacitatea locală de lucru de până la 1 TB este absolut necesară pentru performanța specialiștilor silvici în mod deconectat. - Referințe oficiale verificabile: a) Standardul internațional OGC GeoPackage (format deschis compatibil): OGC GeoPackage Standard b) Suportul universal GDAL pentru fișiere geospațiale locale de mari dimensiuni: GDAL Vector Formats. În concluzie, criticile contestatoarei sunt infirmate atât de clarificările publicate, cât și de realitatea pieței soluțiilor GIS enterprise. Deci, capătul de cerere este neîntemeiat și trebuie respins. B.4. Componentele de management al identității și de control acces sunt redactate pornind de la o soluție predeterminată de tip Web Access Management: Contestatoarea susține că specificațiile din Cap. 5.4.8 al caietului de sarcini ar fi fost redactate pornind de la o soluție predeterminată de tip Web Access Management (precum Oracle Access Manager, CA/Broadcom SiteMinder sau IBM Security Access Manager), cu un nivel de detaliere al mecanismelor interne care ar încălca art. 155 alin. (6) și art. 156 alin. (2)-(3) din Legea nr. 98/2016. Solicită respingerea acestui capăt de cerere ca neîntemeiat, pentru următoarele motive: Caietul de sarcini stabilește cerințe minime și obligatorii ale Componentei pentru administrarea identității utilizatorilor (IAM), nu descrie un produs comercial specific. Toate caracteristicile enumerate (extensibilitatea prin API- uri/limbaje de nivel înalt, orchestrarea fluxurilor, controlul accesului la nivel granular/atribut - ACI, servicii de directoare virtuale și separarea regulilor de business) reprezintă capabilități standard de arhitectură software specifice platformelor moderne de IAM. Soluția software ofertată trebuie să îndeplinească nativ toate aceste capabilități tehnice direct în cadrul produsului propus. Ofertantul va descrie în propunerea tehnică modul în care platforma sa acoperă fiecare cerință de funcționalitate și arhitectură solicitată. Orice referință tehnologică sau de standard din documentație are caracter minimal și obligatoriu, iar ofertantul are sarcina de a dovedi că produsul propus satisface integral parametrii solicitați. Documentația nu descrie un produs comercial specific, iar caracteristicile invocate reprezintă capabilități standard ale platformelor moderne de IAM. Lipsa oricărei dovezi privind pretinsul caracter restrictiv: Contestatoarea afirmă că ansamblul cerințelor ar corespunde arhitecturii unui număr restrâns de soluții comerciale, însă nu prezintă nicio dovadă concretă în acest sens. Nu este depusă nicio analiză comparativă, niciun extras din documentațiile tehnice ale produselor menționate și nicio demonstrație că

Pagina 13 din 80 celelalte soluții existente pe piața IAM nu ar putea îndeplini cumulativ cerințele funcționale și de performanță stabilite. Din punct de vedere tehnologic: - Controlul granular al accesului: Definirea politicilor de acces bazate pe roluri și atribute (RBAC/ABAC) la nivel de resursă web sau prefix URL reprezintă funcționalitatea fundamentală a oricărui Reverse Proxy, API Gateway sau Identity Provider modern, fiind recomandată de standardele internaționale de securitate (NIST SP 800-207 Zero Trust Architecture). - Caching distribuit Activ-Activ: Soluțiile moderne de IAM mențin sesiunile utilizatorilor într- un layer distribuit de memorie partajată (de tip Infinispan, Redis Enterprise sau Hazelcast). Acest lucru permite comutarea automată (failover) fără deconectarea utilizatorilor activi în cazul căderii unui nod de aplicație. - Chiar contestatarea recunoaște că textul caietului de sarcini conține o alternativă explicită și deschisă: „Trebuie sa fie bazata pe standardul BPEL pentru orchestrarea proceselor SAU să dispună de un motor de fluxuri de lucru (workflow) capabil de modelare vizuală a proceselor (low-code/no- code) și orchestrare prin standarde web moderne (ex: REST API, JSON, Webhooks)". Justificarea tehnică și legală a cerințelor de autentificare federată SAML 2.0 și certificate digitale X.509 prin prisma Regulamentului elDAS: Referitor la afirmația contestatoarei potrivit căreia: „Combinația cumulată a acestor cerințe, autentificare Windows Native Authentication alături de SAML federat și X.509 [...] corespunde arhitecturii unui număr restrâns de soluții consacrate precum Oracle sau IBM." prezintă următoarele (demontare și justificare legală): - Obligația legală de integrare elDAS și ROeID: Conform cerințelor asumate prin proiect (finanțat prin PoCIDIF) și a cadrului legal european instituit de Regulamentul (UE) nr. 910/2014 (elDAS), sistemul informatic trebuie să asigure accesul transfrontalier securizat pentru cetățenii și persoanele juridice din Uniunea Europeană. - SAML 2.0 și X.509 - Standardele obligatorii elDAS: Cadrul de interoperabilitate elDAS (elDAS Technical Specifications) impune în mod expres utilizarea profilului SAML 2.0 pentru schimbul securizat de aserțiuni de identitate și a certificatelor digitale X.509 pentru semnarea și criptarea mesajelor între furnizorii de identitate (Identity Providers) și nodul național elDAS/aplicațiile publice (Service Providers). - Arhitectura hibridă justificată: a) SAML 2.0 și X.509: Asigură autentificarea securizată și recunoașterea identităților electronice ale cetățenilor prin conectarea la platforma națională ROeID și nodul european elDAS. b) Windows Native Authentication (Kerberos / NTLM): Asigură conectarea transparentă și securizată (Single Sign-On) a personalului intern al ROMSILVA, integrat în domeniul Microsoft Active Directory existent. - Referințe oficiale verificabile: a) Specificațiile tehnice oficiale ale Comisiei Europene pentru nodul elDAS (SAML 2.0 & X.509): European Commission - elDAS Technical Specifications b) Ghidul de integrare ROeID (Autoritatea pentru Digitalizarea României): Platforma ROeID.

Pagina 14 din 80 Afirmația rămâne, așadar, o simplă susținere nesusținută de probe, insuficientă pentru a demonstra caracterul restrictiv al specificațiilor. Caracterul funcțional al cerințelor reprezintă faptul că, cerințele din Cap. 5.4.8 definesc capacități necesare unui sistem modern de management al identității și al accesului: suport pentru multiple mecanisme de autentificare, definire granulară a politicilor de acces, management centralizat al sesiunilor și disponibilitate ridicată a mecanismului de caching. Acestea sunt formulate ca cerințe de performanță și funcționale, conform art. 156 alin. (1) lit. a) din Legea nr. 98/2016. Clauza „sau echivalent" este aplicabilă. Ca și justificarea obiectivă, autoritatea contractantă arată că, cerințele sunt proporționale cu nevoile de securitate ale unui sistem care gestionează date sensibile privind fondul forestier național și oferă servicii publice, în conformitate cu reglementările DNSC/CPG. Cu privire la absența încălcării dispozițiilor legale, specificațiile nu precizează un anumit producător și nu au ca efect favorizarea sau eliminarea nejustificată a operatorilor economici. Avizul pozitiv CTE nr. 412CTE/18.06.2026 confirmă că specificațiile tehnice au fost analizate din perspectiva securității, interoperablității și neutralității tehnologice. În concluzie, criticile contestatoarei sunt infirmate de absența oricărei probe care să demonstreze că ansamblul cerințelor ar putea fi îndeplinit doar de un număr restrâns de soluții comerciale. Deci, capătul de cerere este neîntemeiat și trebuie respins. B.5. Componenta de backup impune un protocol proprietar Veritas: Contestatoarea critică cerința din Cap. 5.4.15 al caietului de sarcini: „Soluția trebuie să suporte integrarea cu celelalte echipamente de stocare propuse [...] precum și cu cele existente în infrastructura beneficiarului, în mod nativ sau prin protocolul OST (OpenStorage)", susținând că menționarea protocolului OST (tehnologie proprietară Veritas) ar indica drept soluție de referință familia de produse Veritas, cu încălcarea art. 155 și art. 156 din Legea nr. 98/2016. Se solicită respingerea acestui capăt de cerere ca neîntemeiat, pentru următoarele motive: a) Cerința este formulată alternativ („în mod nativ sau prin protocolul OST") Textul cerinței nu impune obligatoriu protocolul OST. El prevede expres două modalități alternative de integrare cu echipamentele de stocare în mod nativ, sau prin protocolul OST. Menționarea OST reprezintă doar un exemplu de protocol de integrare, nu o cerință exclusivă. Clauza generală „sau echivalent" din caietul de sarcini este pe deplin aplicabilă. b) Realitatea pieței soluțiilor de backup enterprise: În piața soluțiilor de backup de nivel enterprise, integrarea optimizată cu sistemele de stocare se realizează, în practică, prin protocoale proprietare sau specializate ale fiecărui producător. Exemple: - Veeam utilizează Veeam Data Mover și integrări native/optimizate cu diverse platforme de stocare;

Pagina 15 din 80 - Commvault utilizează tehnologii proprii (inclusiv Hyperscale) și integrări certificate; - Alți producători folosesc protocoale native sau tehnologii precum HPE Catalyst, Dell DD Boost etc. Faptul că Veritas promovează protocolul OST nu transformă cerința din Caietul de sarcini într-una restrictivă. Dimpotrivă, formularea „în mod nativ sau prin protocolul OST" acoperă exact această realitate a pieței: se acceptă atât integrarea nativă (specifică fiecărui producător), cât și integrarea prin OST. c) Lipsa oricărei dovezi privind pretinsul caracter restrictiv Contestatoarea afirmă că menționarea OST ar restrânge piața la produsele Veritas, însă nu prezintă nicio dovadă concretă că alte soluții majore (Veeam, Commvault, Rubrik sau altele) nu ar putea îndeplini cerința prin integrare nativă sau prin protocoale echivalente. Afirmația rămâne o simplă susținere nesusținută de probe. d) Cerințele privind Bare Metal Restore și NDMP: NDMP (Network Data Management Protocol): Este un protocol deschis (open standard), administrat de SNIA, utilizat la nivel de industrie pentru backup-ul echipamentelor de stocare de tip NAS. Nu aparține Veritas și nu favorizează niciun producător de software. BMR (Bare Metal Restore): Reprezintă o capacitate funcțională generică (restaurare direct pe hardware fără sistem de operare prealabil), oferită nativ de aproape toate soluțiile de backup enterprise (Veeam, Commvault, Cohesity, Rubrik, Veritas). Acestea sunt capacități funcționale standard în soluțiile enterprise de backup, justificate de nevoile de recuperare rapidă și de integrare cu sistemele de stocare de tip NAS. Ele definesc rezultate funcționale, nu un produs determinat. e) Pretinsa necorelare cu agenții de backup pentru baze de date Menționarea expresă a agenților de backup pentru Microsoft SQL Server și PostgreSQL este fundamentată în mod obiectiv pe faptul că acestea reprezintă sistemele de gestiune a bazelor de date utilizate în prezent în infrastructura operațională a autorității contractante. Suplimentar, obligația includerii agenților pentru orice alte baze de date ofertate rezidă direct din cerința generală prevăzută la Secțiunea 5.2 (Arhitectura sistemului), respectiv «Componenta de Backup care să permită salvarea informațiilor din aplicații și baze de date». Astfel, specificațiile tehnice se citesc în mod unitar: garantează protecția mediului existent și impun acoperirea integrală a oricărei soluții noi ofertate, fără a crea vreun avantaj nejustificat sau a restrânge concurența. f) Absența încălcării dispozițiilor legale: Cerința de integrare este formulată alternativ și funcțional. Ea nu precizează un anumit producător și nu are ca efect favorizarea sau eliminarea nejustificată a operatorilor economici. Avizul pozitiv CTE nr. 412CTE/ 18.06.2026 confirmă că specificațiile tehnice au fost analizate și avizate din perspectiva securității, interoperabilității și neutralității tehnologice. În concluzie, susține că această cerință de integrare cu echipamentele de stocare este formulată alternativ („în mod nativ sau prin protocolul OST") și reflectă realitatea pieței soluțiilor de backup enterprise, în care fiecare producător major utilizează propriile protocoale optimizate. Menționarea OST ca opțiune nu transformă cerința într-una restrictivă.

Pagina 16 din 80 Cerințele privind Bare Metal Restore și suportul NDMP definesc capacități funcționale standard, justificate de nevoile de recuperare și de integrare cu sistemele de stocare. Menționarea agenților de backup pentru Microsoft SQL Server și PostgreSQL este fundamentată obiectiv pe sistemele de gestiune a bazelor de date existente în infrastructura autorității contractante, iar obligația de a acoperi orice altă bază de date ofertată rezultă din cerința generală de la Secțiunea 5.2. Specificațiile se citesc unitar și nu creează avantaje nejustificate sau restrângeri ale concurenței. Contestatoarea nu a demonstrat că ansamblul acestor cerințe ar putea fi îndeplinit doar de un număr restrâns de soluții comerciale. Astfel, capătul de cerere este neîntemeiat și trebuie respins. B.6. Componenta integrată de gestiune și analiză a datelor este redactată pornind de la o soluție predeterminată de tip platformă de data science, compatibilă cu profilul Dataiku DSS, astfel: - Cerință: „Componenta oferă un mediu dedicat de dezvoltare pentru limbajul de dezvoltare care sa permită dezvoltarea tehnicilor statistice, precum modelarea liniara si neliniara, execuția testelor statistice clasice, analize pe serii de timp si/sau clasificări" (caiet de sarcini, cap. 5.4.4. Componentă integrată de gestiune și analiză a datelor) - Cerință: „Posibilitatea de a integra (ex: prin API, scripturi externe etc.) inclusiv modele de tip generativ (e.g. Llama, Mistral) pentru a susține arii emergente de analiza si fluxuri de business" (caiet de sarcini, cap. 5.4.4. Componentă integrată de gestiune și analiză a datelor). Combinația exactă de cerințe de la acest capitol, mediu dedicat de notebook-uri cu nuclee Python și R, funcționalități AutoML pentru clasificare, regresie, clustere și serii de timp, interfață vizuală de tip low-code/no-code pentru fluxuri de date, guvernanță și trasabilitate a modelelor, precum și posibilitatea de a conecta modele generative externe precum Llama și Mistral, corespunde punct cu punct profilului tehnic documentat public al platformei Dataiku DSS, una dintre puținele platforme comerciale de pe piață care oferă simultan mediu dedicat R, flux vizual low-code, notebook-uri Python/R/SQL, AutoML pentru exact aceste categorii, clasificare, regresie, clustering, serii de timp, și un mecanism denumit LLM Mesh prin care se conectează explicit la modele precum Llama și Mistral. Surse: Dataiku, Unifying analytics, machine learning, and agents in one platform, https://www.dataiku.com/blog/unified-ai-platform; ToolChase, Dataiku Review 2026, https://toolchase.com/tool/dataiku/; Dataiku Community, August Release Notes, suport Llama3/Mistral prin LLM Mesh, https://community.dataiku.com/discussion/44110/august- release-notes-llm- fine-tuning-govern-status-monitoring-data-quality-enhancements. Petenta solicită fie eliminarea, fie reformularea cerințelor de la cap. 5.4.4 privind mediile de dezvoltare și componenta de inteligență artificială la nivel de funcționalitate necesară, fără raportare la o combinație de caracteristici care corespunde unui singur produs comercial existent pe piață, temei legal art. 155 alin. (6) și art. 156 alin. (2)-(3) din Legea nr. 98/2016. Susținerile contestatoarei conform cărora specificațiile tehnice de la Cap. 5.4.4 ar fi fost redactate pornind exclusiv de la profilul platformei comerciale

Pagina 17 din 80 Dataiku DSS sunt complet nefondate și denotă o înțelegere trunchiată a domeniului Data Science & Machine Learning (DSML). Funcționalitățile solicitate (mediu de dezvoltare pentru limbajul R și Python, capabilități AutoML pentru clasificare/regresie/serii de timp, fluxuri vizuale de date de tip low-code/no-code, guvernanță a modelelor și integrare prin API cu modele generative open-source de tip Llama/Mistral) reprezintă standardul universal de capabilități al oricărei platforme moderne de Data Science de nivel Enterprise, definit de rapoartele internaționale de referință (ex. Gartner Magic Quadrant for Data Science and Machine Learning Platforms). a) Justificarea operațională a cerințelor pentru specificul activității .........: Cerințele tehnice din caietul de sarcini nu au fost preluate din fișa vreunui produs, ci răspund direct necesităților specifice ale managementului forestier național: - Limbajul R și modelarea statistică: în domeniul silviculturii și cercetării forestiere (inclusiv colaborarea cu INCDS „Marin Drăcea"), limbajul R este standardul științific consacrat la nivel internațional pentru biomatematică forestieră, calculul tabelelor de producție, ecuațiilor alometrice de volum și dendrometrie. Un sistem care ar exclude limbajul R ar face imposibilă reutilizarea modelelor matematice forestiere validate academic. - AutoML (Clasificare, Regresie, Serii de timp): ROMSILVA gestionează peste 3 milioane de hectare de fond forestier. Previziunea evoluției arboretelor, estimarea volumelor de masă lemnoasă recoltabilă pe cicluri multianuale și detecția anomaliilor de vegetație impun algoritmi automați de serii de timp și regresie care să poată fi rulați și de personal tehnic silvic, nu exclusiv de programatori specializați. - Integrarea cu modele generative (ex: Llama, Mistral): Introducerea asistenților virtuali și procesarea cererilor/petițiilor cetățenilor privind fondul forestier necesită capacitatea platformei de a consuma, prin API-uri deschise, modele lingvistice mari (LLM) care pot rula on-premises sau în cloud securizat, asigurând confidențialitatea datelor conform GDPR. b) Demontarea pretinsului caracter „exclusiv" al funcționalităților invocate: Contestatoarea susține că asocierea dintre mediul R, fluxurile low-code și integrarea cu Llama/Mistral ar fi unică pentru Dataiku DSS, afirmație pe care o consideră falsă: Cerințele stabilite la Cap. 5.4.4 din caietul de sarcini: - Sunt esențiale pentru obiectivele specifice ale ROMSILVA, asigurând prelucrarea avansată a datelor forestiere prin limbajul statistic R, automatizarea fluxurilor prin AutoML și procesarea limbajului natural prin LLM-uri. - Nu descriu exclusiv produsul Dataiku DSS, ci reflectă stadiul actual al tehnologiei în domeniul analizei de date, existând multiple alternative solide de piață (Posit, H20.ai, Domino Data Lab, KNIME). - Sunt compatibile cu arhitectura Azure Stack Hub a proiectului. În consecință, cerințele respectă principiul proporționalității și nediscriminării prevăzute de art. 155 alin. (6) din Legea nr. 98/2016, iar criticile formulate la punctul B.6 din contestație sunt neîntemeiate și trebuie respins. Capătul de cerere este neîntemeiat și trebuie respins.

Pagina 18 din 80 B.7. Cerința privind antrenarea și inferența modelelor de inteligență artificială nu poate fi îndeplinită în infrastructura Cloudului Privat Guvernamental, bazată exclusiv pe Azure Stack Hub în variantă privată, fără capabilități GPU Contestatoarea critică cerința din Cap. 5.4.4 al caietului de sarcini privind capabilitățile de modelare, antrenare și inferență a modelelor Al, susținând că aceasta nu ar putea fi îndeplinită în infrastructura Cloudului Privat Guvernamental (bazată pe Azure Stack Hub), care nu dispune de resurse de calcul accelerat de tip GPU, motiv pentru care solicită fie confirmarea existenței resurselor GPU, fie eliminarea/reformularea cerinței. Solicită respingerea acestui capăt de cerere ca neîntemeiat, pentru următoarele motive: a. Infrastructura de procesare accelerată de tip GPU nu este pusă la dispoziție în Cloudul Privat Guvernamental (CPG) și nu face obiectul achiziției de echipamente hardware în cadrul prezentului contract: Antrenarea, calibrarea sau ajustarea fină (fine-tuning) a modelelor de învățare automată/Al trebuie realizată de către Contractant anterior livrării, utilizând propria infrastructură de dezvoltare, astfel încât în mediul de producție să fie livrate modele deja antrenate (pre-trained). Cerința din Caietul de Sarcini vizează o capabilitate funcțională de integrare software. Soluția ofertată trebuie să pună la dispoziție mecanismele tehnice (interfețe API REST, microservicii, conectori, scripturi) necesare interfațării cu modele avansate/generative (ex. Llama, Mistral etc.). Pentru funcționarea în CPG, inferența modelelor se va realiza prin optimizarea acestora pentru arhitectura de procesare standard bazată pe vCPU/RAM furnizată în CPG sau prin conectarea securizată la servicii/APl-uri externe furnizate de modelele respective, fără a necesita resurse GPU fizice dedicate în CPG. b. Distincția clară între antrenare și inferență: - Antrenarea/fine-tuning-ul modelelor se realizează de către contractant în afara mediului CPG, pe propria infrastructură, urmând ca în producție să fie livrate modele deja antrenate (pre-trained). - Inferența (utilizarea modelelor în producție) se realizează în CPG fie prin optimizarea modelelor pentru resursele standard de tip vCPU/RAM, fie prin conectare securizată la servicii/API-uri externe, fără a necesita GPU-uri dedicate în CPG. Cerința din caietul de sarcini vizează, așadar, o capabilitate funcțională de integrare software, nu obligația de a rula antrenamente GPU-intensive în infrastructura CPG. c. Absența oricărei imposibilități de executare sau a unor costuri neprevăzute: Se elimină orice incertitudine privind modul de îndeplinire a cerinței. Ofertanții știu exact: - că nu trebuie să prevadă costuri de infrastructură GPU în CPG; - că antrenarea se face pe infrastructura proprie; - că inferența se face pe resursele standard CPG sau prin API-uri externe. Nu există nicio încălcare a principiului transparenței și previzibilității documentației de atribuire (art. 2 alin. (2) lit. d) din Legea nr. 98/2016). Ca și concluzie, cerința privind capabilitățile de modelare, antrenare și inferență a modelelor Al este pe deplin fezabilă în cadrul contractului.

Pagina 19 din 80 Capătul de cerere este neîntemeiat și trebuie respins. B.8. Componenta de optimizare automată a resurselor este redactată pornind de la o soluție predeterminată, compatibilă cu profilul IBM Turbonomic, și este parțial incoerentă cu infrastructura fixă de implementare Contestatoarea susține că specificațiile din Cap. 5.4.14 al caietului de sarcini ar fi fost redactate pornind de la platforma IBM Turbonomic, pe motiv că lista de infrastructuri de virtualizare suportate (Azure, Kubernetes, OpenShift), coroborată cu funcționalitățile de tip what-if, rollback, alocare la nivel de containere/pod-uri și optimizare de cost, ar corespunde profilului tehnic al acestui produs. În plus, invocă o pretinsă incoerență, întrucât lista nu menționează platforme de virtualizare tradițională (VMware, Hyper-V), deși infrastructura de destinație este Azure Stack Hub. Solicită respingerea acestui capăt de cerere ca neîntemeiat, pentru următoarele motive: a) Cerința definește capacități funcționale, nu un produs determinat: Capitolul 5.4.14 stabilește un set de capacități necesare unei componente moderne de optimizare automată a resurselor: suport pentru mediile cloud și de containerizare utilizate, simulări what-if, acțiuni reversibile, alocare precisă la nivel de containere/pod-uri și recomandări de optimizare a costurilor. Acestea sunt formulate ca cerințe de performanță și funcționale, conform art. 156 alin. (1) lit. a) din Legea nr. 98/2016. b) Lista „Azure, Kubernetes, OpenShift" este coerentă cu mediul de implementare Infrastructura de găzduire a sistemului este Cloudul Privat Guvernamental, unitatea de Cloud Dedicat bazată pe tehnologia Azure Stack Hub. În acest context, menționarea Azure ca platformă suportată este pe deplin naturală și necesară. Totodată, arhitectura solicitată a sistemului informatic (componente containerizate, microservicii, orchestrare) face ca suportul pentru Kubernetes și pentru distribuții enterprise precum Red Hat OpenShift să fie relevant și justificat. Aceste tehnologii reprezintă standardul de facto pentru orchestrarea containerelor în medii cloud hibride și private, inclusiv pe Azure Stack Hub. Lista nu are caracter exhaustiv sau exclusiv. Ea reflectă mediile de virtualizare și de orchestrare pe care componenta de optimizare trebuie să le poată gestiona în cadrul arhitecturii propuse, fără a interzice suportul pentru alte platforme. c) Existența pe piață a unor soluții alternative Pe piață există multiple soluții COTS de Application Resource Management/Continuous Optimization care oferă capacități similare. Un exemplu concret este platforma Cast Al, care asigură optimizare automată a resurselor în medii Kubernetes (inclusiv pe Azure Kubernetes Service și OpenShift), rightsizing, acțiuni automate de scalare și optimizare de cost, cu mecanisme de control al acțiunilor. Documentația oficială a producătorului confirmă aceste capabilități: https://cast.ai/, exemplu care demonstrează că cerințele din Cap. 5.4.14 nu sunt specifice unui singur produs. d) Lipsa oricărei dovezi privind pretinsul caracter restrictiv:

Pagina 20 din 80 Contestatoarea afirmă că ansamblul cerințelor ar corespunde profilului unui singur produs, însă nu prezintă nicio dovadă concretă că alte soluții existente pe piață nu ar putea îndeplini aceleași capacități funcționale. În concluzie, autoritatea contractantă precizează că, cerințele din Cap. 5.4.14 definesc capacități funcționale necesare unei componente de optimizare automată a resurselor. Lista de platforme suportate (Azure, Kubernetes, OpenShift) este coerentă cu mediul de implementare (Azure Stack Hub) și cu arhitectura containerizată a sistemului. Aceste capacități pot fi îndeplinite de mai multe soluții COTS existente pe piață, inclusiv Cast Al. Contestatoarea nu a demonstrat caracterul restrictiv al specificațiilor. Deci, capătul de cerere este neîntemeiat și trebuie respins. B.9. Componenta SIEM este redactată pornind de la o soluție predeterminată, compatibilă cu profilul IBM QRadar: Contestatoarea susține că specificațiile din Cap. 5.4.12 al caietului de sarcini ar fi fost redactate pornind de la platforma IBM QRadar, pe motiv că combinația de cerințe (livrare ca appliance software cu funcții interne securizate de producător, monitorizare a traficului prin metadate de tip flow, informații GeolP, mecanism de tip Identity Feed pentru Active Directory și posibilitatea de extindere fără înlocuirea hardware-ului existent) ar corespunde arhitecturii și terminologiei acestui produs. Solicită respingerea acestui capăt de cerere ca neîntemeiat, pentru următoarele motive: a) Cerințele definesc capacități funcționale, nu un produs determinat: Capitolul 5.4.12 stabilește un set de capacități necesare unei componente SIEM enterprise: - livrare sub formă de appliance software (sau echivalent securizat de producător); -monitorizare a traficului de rețea prin captură continuă și metadate de tip flow; - îmbogățire a evenimentelor cu informații GeolP; - corelare a evenimentelor cu surse de identitate (Active Directory / liste de utilizatori); - posibilitatea de scalare/extindere a soluției fără înlocuirea integrală a infrastructurii existente. Acestea sunt formulate ca cerințe de performanță și funcționale, conform art. 156 alin. (1) lit. a) din Legea nr. 98/2016. b) Terminologia utilizată descrie funcționalități, nu este un produs exclusiv: Faptul că unele formulări apar și în documentația IBM QRadar nu transformă cerințele într-o dedicație ilegală. Noțiunile folosite („flow", „Identity Feed", „appliance", „GeolP") descriu funcționalități generice ale soluțiilor SIEM mature. - Formatul de tip „Appliance Software": Reprezintă un standard în securitate ce presupune livrarea soluției sub formă de imagine virtuală securizată și optimizată (hardened OS - Linux/Windows), reducând riscul de vulnerabilități la nivelul sistemului de operare gazdă. Acest model de livrare este utilizat de Splunk, Wazuh, Elastic, LogRhythm, Fortinet FortiSIEM, nu doar de IBM. - Monitorizarea traficului prin „metadate de tip flow":

Pagina 21 din 80 Metadatele de tip flow (NetFIow, sFIow, IPFIX) sunt standarde deschise internaționale (ex. IETF RFC 7011 pentru IPFIX, standard Cisco pentru NetFIow). Captarea și analiza fluxurilor de rețea este o cerință fundamentală de monitorizare NDR (Network Detection and Response) integrată în majoritatea SIEM-urilor moderne. - Informațiile GeolP: Localizarea geografică a adreselor IP suspecte (GeolP enrichment) este o capabilitate universală oferită de baze de date deschise sau comerciale (cum ar fi MaxMind GeoLite/GeolP2 sau IP2Location), integrată nativ în toate platformele de analiză a logurilor. - „Identity Feed" pentru Active Directory: Sintagma descrie funcționalitatea de preluare și corelare automată a evenimentelor de securitate cu conturile de utilizator din Microsoft Active Directory (User Context/UEBA - User and Entity Behavior Analytics). Această funcționalitate este un standard de securitate pentru a identifica rapid utilizatorul uman din spatele unei adrese IP sau a unui atac cibernetic. Sursele nerelevante invocate de contestatoare: citează articole informale de pe platforma de blogging Medium.com și un ghid generic de la CyberSkilIsHub. Faptul că un articol explicativ despre securitate folosește termeni generici precum flow, geoip sau identity pentru a descrie un produs nu înseamnă că acești termeni sunt marcă înregistrată sau proprietatea acelui producător. c) Lipsa oricărei dovezi privind pretinsul caracter restrictiv: Contestatoarea afirmă că ansamblul cerințelor ar corespunde profilului IBM QRadar, însă nu prezintă nicio dovadă concretă că alte soluții SIEM enterprise nu ar putea îndeplini aceleași capacități. Afirmația rămâne o simplă susținere nesusținută de probe. Avizul pozitiv CTE nr. 412CTE/18.06.2026 confirmă, de asemenea, că specificațiile tehnice au fost analizate din perspectiva securității, interoperabilității și neutralității tehnologice. d) Justificarea obiectivă a cerințelor Cerințele sunt proporționale cu nevoile de securitate ale unui sistem care gestionează date sensibile si oferă servicii publice, în conformitate cu Legea nr. 362/2018 și reglementările DNSC/CPG. În concluzie, cerințele din Cap. 5.4.12 definesc capacități funcționale standard ale unei soluții SIEM enterprise. Prin aplicarea clauzei „sau echivalent", aceste capacități pot fi îndeplinite de alte soluții, chiar dacă acestea operează cu terminologie proprie. Contestatoarea nu a demonstrat caracterul restrictiv al specificațiilor. Astfel, capătul de cerere este neîntemeiat și trebuie respins. B.10. Componenta de analiză și raportare avansată a datelor corespunde profilului tehnic și modelului de licențiere al platformei IBM Cognos Analytics: Contestatoarea susține că specificațiile din Cap. 5.4.6 al caietului de sarcini ar fi fost redactate pornind de la platforma IBM Cognos Analytics, pe motiv că structura de licențiere pe trei niveluri de utilizatori (administrare; creare/personalizare/partajare inclusiv analize predictive; vizualizare/ partajare/comentarii) și folosirea termenului „prompt" ar corespunde exact rolurilor și terminologiei acestui produs (Administrator, Explorer, Viewer/ Consumer).

Pagina 22 din 80 Solicită respingerea acestui capăt de cerere ca neîntemeiat, pentru următoarele motive: a) Cerințele definesc roluri funcționale de acces, nu un model de licențiere proprietar Structura pe trei niveluri prevăzută la Cap. 5.4.6 descrie nevoi reale de acces ale achizitoarei: - un număr restrâns de administratori cu control deplin asupra platformei; - un grup de utilizatori avansați care creează, personalizează și partajează rapoarte, tablouri de bord și analize (inclusiv predictive); - un număr mai mare de utilizatori finali care doar vizualizează, partajează și comentează conținutul predefinit. Această diferențiere pe roluri (administrator/creator/consumator) este o practică standard în domeniul Business Intelligence și Analytics, nu o particularitate exclusivă a IBM Cognos Analytics. Clauza generală „sau echivalent" din caietul de sarcini este pe deplin aplicabilă. b) Terminologia „prompt" descrie o funcționalitate generică: Termenul „prompt" (pagină de parametri/variabile prin care utilizatorul selectează valori la rularea unui raport) este folosit generativ în industria Bl pentru a descrie parametrizarea interactivă a rapoartelor. El nu indică un produs determinat. c) Existența pe piață a unor soluții alternative cu structuri de acces similare: Pe piață există multiple platforme COTS de analiză și raportare avansată care oferă modele de acces diferențiat pe roluri, echivalente funcțional cu cele solicitate. Un exemplu relevant este Microsoft Power Bl (în varianta Premium / Fabric), care permite definirea de roluri distincte: - administratori ai spațiului de lucru/tenant; - utilizatori cu drepturi de creare, editare și partajare a rapoartelor și tablourilor de bord (inclusiv capabilități de analiză avansată); - utilizatori cu drepturi limitate la vizualizare, consum și interacțiune cu conținutul publicat. Structuri similare de acces diferențiat se regăsesc și la alte platforme mature (Tableau, Qlik Sense etc.). Prin aplicarea clauzei „sau echivalent", aceste soluții îndeplinesc cerințele de la Cap. 5.4.6, chiar dacă denumirile comerciale ale rolurilor de licențiere diferă. d) Lipsa oricărei dovezi privind pretinsul caracter restrictiv: Contestatoarea afirmă că structura de licențiere ar corespunde exact modelului IBM Cognos Analytics, însă nu prezintă nicio dovadă concretă că alte platforme Bl nu ar putea asigura aceleași niveluri funcționale de acces. Afirmația rămâne o simplă susținere nesusținută de probe. e) Justificarea obiectivă a structurii de acces Numărul și tipurile de utilizatori (5 administratori, 15 creatori, 100 consumatori) reflectă nevoile reale de organizare a accesului la analizele și rapoartele sistemului informatic al ROMSILVA RA. Această dimensionare este proporțională și necesară pentru utilizarea eficientă a componentei. În concluzie, autoritatea contractantă susține că, cerințele din Cap. 5.4.6 definesc roluri funcționale de acces necesare unei platforme de analiză și raportare avansată, nu un model de licențiere proprietar. Acestea pot fi îndeplinite de mai multe soluții COTS existente pe piață (inclusiv Microsoft

Pagina 23 din 80 Power Bl), prin aplicarea clauzei „sau echivalent". Contestatoarea nu a demonstrat caracterul restrictiv al specificațiilor. Capătul de cerere este neîntemeiat și trebuie respins. B.11. Structura formularului F1A confirmă abordarea documentației pe produs, nu pe funcționalitate: Contestatoarea susține că structura Formularului F1A (15 componente licențiate distinct, fiecare cu cantitate 1) și cerințele din Formularul F2B (identificarea producătorului, produsului, ediției și modului de licențiere) ar confirma că documentația a fost gândită pe baza a 15 produse comerciale distincte, deja identificate, și ar împiedica ofertarea de soluții combinate, open- source sau dezvoltate la comandă pentru unele dintre componente. Autoritatea contractantă solicită respingerea acestui capăt de cerere ca neîntemeiat, pentru următoarele motive: a. Structura Formularului F1A servește comparabilității financiare, nu predeterminării produselor Cele 15 poziții din Formularul F1A corespund componentelor software solicitate pe baza cărora va fi construit sistemul, așa cum sunt definite în caietul de sarcini. Această structură asigură: - evaluarea unitară și comparabilă a ofertelor; - trasabilitatea costurilor pe fiecare componentă software; - claritatea propunerii financiare. Ea nu interzice ca un ofertant să propună o platformă integrată care acoperă mai multe componente sau o combinație de produse de la producători diferiți. Costurile se înscriu în pozițiile existente ale formularului. Ofertanții trebuie să completeze fiecare element din Formularul nr. 1A (Propunerea financiară detaliată), fără a adăuga poziții suplimentare, menținându-se structura prezentată în documentația de atribuire b. Documentația nu interzice soluțiile combinate: Nici caietul de sarcini, nici Formularele F1A/F2B nu impun ca fiecare componentă software să fie acoperită de un produs distinct de la un producător diferit. Ofertantul poate propune: - o soluție integrată care îndeplinește cerințele mai multor componente; - combinații de produse COTS de la unul sau mai mulți producători, atâta timp cât fiecare cerință este acoperită și poate fi demonstrată. Solicitarea de a indica producătorul, produsul și modul de licențiere în Formularul F2B are rol de transparență și de verificare a conformității, nu de restrângere a posibilităților de ofertare. c. Cerința privind software-ul comercial (COTS): Cerința ca software-ul standard să fie oferit în versiune comercială (COTS) este justificată expres în caietul de sarcini prin sensibilitatea datelor; nivelul de securitate solicitat; necesitatea asigurării de către producători a suportului tehnic pentru toate componentele funcționale, de securitate și de suport. Această cerință se aplică componentelor software ale platformei și nu interzice, în principiu, elemente de dezvoltare specifică (custom) acolo unde caietul de sarcini le prevede (servicii de dezvoltare, configurare, integrare, personalizare). Soluțiile open-source pure nu sunt acceptate pentru componentele software solicitate tocmai din rațiuni de suport pe termen lung, responsabilitate

Pagina 24 din 80 a producătorului și securitate, aspecte deja validate prin Avizul pozitiv CTE nr. 412CTE/18.06.2026. d. Lipsa demonstrației privind pretinsa imposibilitate de ofertare: Contestatoarea susține că structura documentației ar împiedica ofertarea de soluții combinate sau alternative, susținere care nu este însă însoțită de nicio demonstrație concretă. Contestatoarea nu arată în ce mod un operator economic diligent ar fi în imposibilitate de a propune o arhitectură conformă, bazată pe produse COTS (fie integrate, fie combinate), care să îndeplinească toate cerințele. În absența unei astfel de demonstrații, afirmația rămâne o simplă interpretare, nesusținută de probe. Ca și argumente, arată că: - structura financiară pe componente reflectă arhitectura modulară reală a sistemului, descrisă chiar prin obiectivele proiectului (cele 15 componente funcționale distincte), fiind necesară tocmai pentru a asigura comparabilitatea ofertelor financiare, cerință expresă a art. 3 lit. z) din Legea nr. 98/2016; - F1A nu impune ofertarea de produse separate, ci detalierea costurilor pe componente funcționale. În concluzie, structura Formularului F1A asigură comparabilitatea ofertelor financiare pe componente software și nu predetermină produse comerciale concrete. Documentația permite soluții integrate sau combinate, cu respectarea cerinței de software comercial (COTS), justificată de nevoile de securitate și de suport. Contestatoarea nu a demonstrat că această structură ar restrânge nejustificat concurența sau ar împiedica ofertarea de soluții viabile. Deci, capătul de cerere este neîntemeiat și trebuie respins. B.12. Cerințele prin care se exclude categoric orice soluție bazată pe software open source în favoarea exclusivă a produselor comerciale de tip COTS restrâng nejustificat concurența și contravin direcțiilor de politică ale Uniunii Europene în materie de software open source: Contestatoarea critică cerința din Cap. 5.3 al caietului de sarcini conform căreia, ținând cont de sensibilitatea datelor, de nivelul de securitate solicitat și de necesitatea asigurării suportului tehnic de către producători, furnizorul este obligat să ofere versiunea comercială (COTS) pentru tot software-ul standard. Aceasta susține că excluderea categorică a soluțiilor open source ar restrânge nejustificat concurența, ar încălca principiul proporționalității și ar contraveni politicii Uniunii Europene în materie de software open source. Solicită respingerea acestui capăt de cerere ca neîntemeiat, pentru următoarele motive: a. Cerința este justificată obiectiv de specificul sistemului și de considerente legate de ciclul de viată: Cerința privind software-ul comercial (COTS) este motivată expres prin: - sensibilitatea datelor prelucrate; - nivelul de securitate impus de legislația națională și de reglementările DNSC/CPG; - necesitatea asigurării suportului tehnic pe întreaga durată de implementare și de garanție, cu responsabilitate contractuală clară. Conform art. 155 alin. (2) din Legea nr. 98/2016, specificațiile tehnice pot viza inclusiv un proces specific pentru un alt stadiu al ciclului de viață al

Pagina 25 din 80 produselor sau serviciilor (utilizare, întreținere, suport), cu condiția ca aceste caracteristici să aibă legătură cu obiectul contractului și să fie proporționale. Cerința de software comercial, care garantează suport tehnic pe termen lung și responsabilitatea pe durata de viață a sistemului, se încadrează exact în această dispoziție legală. b. Legea nr. 98/2016 nu impune acceptarea obligatorie a soluțiilor open source Art. 155 și art. 156 din Legea nr. 98/2016 permit autorității contractante să stabilească specificații pe bază de performanță, funcționalitate și considerente de ciclu de viață. Nicio dispoziție nu obligă la acceptarea soluțiilor open source atunci când, din rațiuni obiective de securitate, suport și asumare a răspunderii, s-a optat pentru software comercial. c. Politica europeană încurajează open source, dar nu anulează dreptul de a formula cerințe de ciclu de viată Regulamentul (UE) 2024/903 și strategiile Comisiei promovează software- ul open source, însă nu interzic autorităților contractante să solicite software comercial atunci când justifică obiectiv nevoia de suport contractual garantat și de responsabilitate clară pe durata ciclului de viață al sistemului. Prioritizarea open source este o orientare de politică, nu o normă care înlătură dispozițiile art. 155 alin. (2) din Legea nr. 98/2016. d. Proporționalitatea cerinței: Obiectivul legitim - asigurarea unui suport tehnic adecvat și a unui nivel de securitate corespunzător pe întreaga durată de viață a sistemului - este atins prin cerința de software comercial. Această măsură este proporțională cu valoarea și obiectivele contractului (sistem critic, date sensibile, găzduire în CPG). e. Avizul pozitiv CTE: Avizul pozitiv nr. 412CTE/18.06.2026 confirmă că specificațiile tehnice, inclusiv cele privind arhitectura și modelul de licențiere, au fost analizate din perspectiva securității, interoperabilității și neutralității tehnologice. f. Lipsa demonstrației privind restrângerea nejustificată a concurenței Contestatoarea afirmă că cerința ar exclude o întreagă categorie de operatori, însă nu demonstrează că pe piață nu ar exista un număr suficient de operatori economici capabili să ofere soluții COTS conforme. Cerința nu creează un monopol și nu favorizează un producător anume. Ca și concluzie, arată că cerința de a oferi software comercial (COTS) pentru componentele standard este justificată de sensibilitatea datelor, de nivelul de securitate și de necesitatea unui suport tehnic garantat pe durata ciclului de viață al sistemului. Ea se întemeiază pe art. 155 alin. (2) din Legea nr. 98/2016, este proporțională și nu este interzisă de cadrul european de politică privind open source. Contestatoarea nu a demonstrat caracterul disproporționat sau discriminatoriu al acestei cerințe. Capătul de cerere este neîntemeiat și trebuie respins. C. Grila de punctaj a factorilor calitativi Pt2, Pt3 și Pt4 nu permite o diferențiere reală și proporțională a ofertelor, iar în cazul Pt3 și Pt4 nu delimitează cerințele minime obligatorii de avantajele calitative suplimentare punctate, contrar art. 32 alin. (2) din HG nr. 395/2016: Contestatoarea susține că grila de evaluare a factorilor Pt2 (Abordarea și metodologia), Pt3 (Planul de lucru) și Pt4 (Graficul de prestare) - fiecare cu

Pagina 26 din 80 pondere de 15% și praguri discrete de 0,10 și 15 puncte - nu permite o diferențiere reală și proporțională a ofertelor, nu delimitează clar cerințele minime obligatorii de avantajele calitative suplimentare (în special la Pt3 și Pt4) și încalcă art. 32 alin. (2) din HG nr. 395/2016. Față de aceste susțineri, solicită respingerea acestui capăt de cerere ca neîntemeiat, pentru următoarele motive: a. Grila de punctaj respectă recomandările din Catalogul ANAP al factorilor de evaluare pentru servicii intelectuale: Catalogul Factorilor de evaluare ce pot fi incluși în criteriul „cel mai bun raport calitate-preț" pentru serviciile intelectuale (disponibil la https:// achizitiipublice.gov.rO/matrix/cell/71/1) recomandă expres, pentru factori de tipul: - demonstrarea unei abordări și metodologii corespunzătoare; - gradul de adecvare al planului de lucru; - alte elemente calitative similare, utilizarea unei structuri pe trei niveluri de calificative (ex. „Acceptabil/ Satisfăcător", „Bine/Adecvat", „Foarte bine/Excepțional"), fiecare asociat cu un punctaj distinct. Grila adoptată de autoritatea contractantă pentru Pt2, Pt3 și Pt4 (0/10/15 puncte) respectă întocmai această abordare recomandată de ANAP. Ea permite diferențierea ofertelor pe baza calității propunerii tehnice și este pe deplin compatibilă cu art. 32 alin. (2) din HG nr. 395/2016. b. Delimitarea dintre conformitate și avantajul calitativ punctat: Cerințele minime obligatorii privind Planul de lucru (pct. 9.2) și Graficul de prestare (pct. 9.3) din Caietul de sarcini definesc conținutul minim pe care trebuie să îl îndeplinească orice ofertă pentru a fi considerată conformă. Grila de punctaj aferentă Pt3 și Pt4 evaluează modul în care acest conținut minim este elaborat și prezentat: gradul de detaliere, coerența, optimizarea structurii, calitatea reprezentării, capacitatea de replanificare etc. O ofertă care nu îndeplinește cerințele minime obligatorii este neconformă. O ofertă conformă poate primi 0, 10 sau 15 puncte, în funcție de calitatea demonstrată. Nu există confuzie între planul conformității și planul punctajului calitativ. c. Caracterul apreciativ al unor formulări este inerent și acceptat de ANAP: Utilizarea unor termeni precum „completă", „coerentă", „excelență", „optimă", „bună"/„foarte bună" este specifică evaluării factorilor calitativi de tip metodologie, plan de lucru și grafic. Catalogul ANAP utilizează exact același tip de formulări apreciative („Acceptabil", „Bine", „Foarte bine/ Excepțional") pentru a diferenția nivelurile de calitate. Comisia de evaluare aplică aceste criterii în mod unitar, iar media aritmetică a punctajelor individuale asigură un echilibru suplimentar. d. Comparația cu factorul Pt1 nu demonstrează nelegalitatea: Faptul că factorul Pt1 utilizează o scală graduală obiectivă nu obligă Autoritatea Contractantă să aplice același mecanism și factorilor de tip metodologie/plan/grafic. Natura diferită a acestor factori justifică abordări de evaluare diferite, ambele conforme cu legea și cu recomandările ANAP. e. Ponderea cumulată a factorilor este legitimă: Cei trei factori însumează 45 de puncte din 100. Această pondere reflectă importanța acordată calității abordării metodologice, planificării și graficului de

Pagina 27 din 80 prestare într-un proiect complex de servicii intelectuale de dezvoltare a unui sistem informatic și nu contravine legii. Ca argumente: - factorii tehnici de evaluare vizează aspecte calitative și sunt în strictă legătură cu obiectul contractului de achiziție publică ce urmează a fi atribuit prin prezenta procedură, vizând extinderea unor cerințe minime stabilite în caietul de sarcini, în conformitate cu prevederile art. 188 alin. (1) din Lege; - comisia de evaluare va analiza conținutul propunerii tehnice și va evalua calitatea Abordării și metodologiei propuse pentru implementarea contractului, calitatea Planului de lucru, respectiv calitatea Graficului de prestare conform unor grile de punctaj detaliate clar în caietul de sarcini; - cerințele minime și obligatorii pentru fiecare dintre cei 3 factori de evaluare (Abordarea și metodologia, Planul de lucru, Graficul de prestare) sunt detaliate clar în caietul de sarcini, iar pentru îndeplinirea acestor cerințe minime și obligatorii, ofertele sunt considerate conforme, dar vor primi 0 puncte; - grila de punctaj pentru factorii Pt2, Pt3 și Pt4 conține deja repere obiective și verificabile numeroase (structura WBS, matricea RACI, tipurile de relații logice, numărul de scenarii de optimizare, etc.), care permit o aplicare uniformă a criteriilor de către membrii comisiei de evaluare, iar pragul minim de 0 puncte nu se suprapune cu motivele de respingere a ofertei ca neconformă; - analiza integrală a grilelor Pt2, Pt3 și Pt4 arată că fiecare factor de evaluare este descris prin de subcriterii concrete, obiective și verificabile (existența și completitudinea matricei RACI, tipurile de relații logice utilizate în Grafic, documentarea decalajelor, numărul de scenarii de optimizare a drumului critic prezentate (explicit cuantificat: „minimum 2 scenarii documentate" la pragul de 15 puncte), existența unor criterii SMART pentru jaloane). Nu se poate aprecia astfel că diferențierea s-ar realiza „exclusiv prin calificative subiective"; - practica CNSC și a instanțelor de judecată acceptă constant grile de evaluare structurate în trepte (nu neapărat cu valori numerice continue), atâta vreme cât fiecare nivel este descris în mod suficient de clar (condiție pe deplin îndeplinită în cazul de față), unde fiecare dintre cele trei praguri beneficiază de câte un set detaliat de criterii; - pragul de 0 puncte nu se suprapune cu motivul de respingere a ofertei ca neconformă: o ofertă la acest nivel îndeplinește, potrivit propriei descrieri din grilă, structura minimă obligatorie (WBS cu faze, etape, sub-activități, livrabile, durate), diferența față de pragurile superioare constând în profunzimea și calitatea acestor elemente, nu în absența lor. Neconformitatea, în schimb, presupune neîndeplinirea propriu-zisă a cerințelor minime obligatorii - o situație calitativ diferită; - aplicarea grilei este suplimentar garantată de mecanismul de evaluare independentă a fiecărui membru al comisiei, urmată de media aritmetică a punctajelor acordate, mecanism menit tocmai să atenueze orice element de subiectivitate izolată în interpretarea criteriilor; - prevederile art. 32 alin. (2) din HG nr. 395/2016 impun ca factorii de evaluare și algoritmul de calcul să fie precizați clar și detaliat în documentația de atribuire, să reflecte metodologia de punctare a avantajelor din propunerile depuse, să aducă un avantaj real ofertelor, să nu fie formali și să poată fi urmăriți/verificați în procesul de evaluare. Toate aceste cerințe sunt îndeplinite:

Pagina 28 din 80 fiecare dintre cele trei grile indică expres algoritmul de calcul (evaluare independentă a fiecărui membru al comisiei, urmată de media aritmetică pe criteriu), iar fiecare palier este însoțit de un paragraf descriptiv detaliat, redactat detaliat, care explică punctual ce trebuie să demonstreze oferta pentru a atinge acel nivel; - delimitarea cerinței minime obligatorii de avantajul calitativ suplimentar punctat există expres, inclusiv la Pt3 și la Pt4, rezultând chiar din textul grilelor: fiecare dintre cele trei grile, nu doar Pt2, etichetează explicit palierul de 0 puncte drept „(cerință minimă)", în formulare identică. Afirmația potrivit căreia această delimitare ar lipsi punctual la Pt3 și Pt4 este contrazisă de text: tratamentul este unitar și simetric pentru toți cei trei factori calitativi; - un ofertant care îndeplinește strict elementele descrise la palierul de 0 puncte (de exemplu, la Pt3: WBS prezentat, faze și etape definite, sub-activități, livrabile, durate justificate, matrice de alocare a responsabilităților și structură organizatorică, chiar la un nivel de detaliere de bază) nu este descalificat și nu obține o ofertă neconformă, rămâne eligibil, primind pur și simplu 0 puncte suplimentare pe acel factor. Punctajul de 10, respectiv de 15 puncte, recompensează exclusiv avantaje calitative demonstrabile peste acest nivel minim (profunzime, corelare cu metodologia propusă, matrice RACI bine întocmită, scenarii de optimizare, criterii SMART pentru jaloane), exact structura de „cerință minimă versus avantaj calitativ suplimentar" pe care contestatoarea o consideră absentă; - diferențierea reală și proporțională a ofertelor nu se limitează, în fapt, la trei valori discrete: potrivit algoritmului de calcul prevăzut chiar în grilă, punctajul final acordat fiecărei oferte este media aritmetică a punctajelor atribuite independent de fiecare membru al comisiei de evaluare. într-o comisie formată din mai mulți evaluatori care apreciază independent aceeași ofertă, media aritmetică produce, matematic, un spectru de valori intermediare (de exemplu 8, 9, 11, 12, 13 puncte etc.), nu doar 0,10 sau 15. Critica potrivit căreia grila ar permite doar trei rezultate posibile ignoră tocmai mecanismul de calcul pe care contestatoarea îl citează ca fiind aplicabil grilei; - prevederile art. 32 alin. (2) din HG nr. 395/2016, invocate chiar de contestatoare, sunt respectate punct cu punct (claritate, detaliere, algoritm verificabil); - prin mecanismul mediei aritmetice a punctajelor acordate independent de fiecare evaluator din comisie (mecanism prevăzut chiar în grilă), rezultatul final nu se limitează la trei valori discrete (0/10/15), ci produce matematic un spectru de valori intermediare — ceea ce infirmă direct premisa contestației. În concluzie, grila de punctaj pentru factorii Pt2, Pt3 și Pt4 este formulată în mod clar, respectă structura pe trei niveluri de calitate recomandată de Catalogul ANAP al factorilor de evaluare pentru servicii intelectuale și permite diferențierea reală a ofertelor. Delimitarea dintre cerințele minime obligatorii și avantajele calitative punctate este asigurată. Contestatoarea nu a demonstrat încălcarea art. 32 alin. (2) din HG nr. 395/2016. Deci, capătul de cerere este neîntemeiat și trebuie respins. D. Cerințele privind personalul-cheie sunt, în parte, disproporționate și insuficient corelate cu complexitatea reală a rolurilor solicitate:

Pagina 29 din 80 D.1. Cerința de competențe pentru Expertul cheie nr. 4 - Expert îmbunătățire procese de business, privind implementarea asistenților virtuali este disproporționată în raport cu rolul acestui expert Contestatoarea critică cerința din Cap. 11.1.4 al caietului de sarcini conform căreia Expertul cheie nr. 4 (Expert îmbunătățire procese de business) trebuie să dețină competențe, printre altele: „în domeniul analizei de business pentru implementarea asistenților virtuali (Conversational Al)". Aceasta susține că responsabilitățile acestui expert (identificarea legislației și a procedurilor, maparea proceselor, elaborarea proiectelor de implementare a noului model de livrare a serviciilor publice) nu fac referire expresă la chatbot/asistent virtual și că impunerea acestei competente de nisă ar fi disproporționată, cu încălcarea art. 2 alin. (2) lit. e) din Legea nr. 98/2016. Solicită respingerea acestui capăt de cerere ca neîntemeiat, pentru următoarele motive: a. Competența este legată de rolul expertului în transformarea proceselor de business: Expertul cheie nr. 4 are ca responsabilitate principală îmbunătățirea proceselor de business și elaborarea noului model de livrare a serviciilor publice digitale. În cadrul acestui model, interacțiunea cu cetățenii și cu beneficiarii serviciilor publice va include, printre altele, canale digitale moderne de tip asistent virtual/Conversational Al. Analiza de business necesară pentru integrarea acestor canale în fluxurile de lucru (definirea cazurilor de utilizare, maparea interacțiunilor, identificarea punctelor de contact cu procesele de business, stabilirea regulilor de escaladare etc.) face parte integrantă din activitatea de îmbunătățire a proceselor. Competența solicitată nu vizează dezvoltarea tehnică a chatbot-ului, ci analiza de business specifică integrării acestuia în procesele organizaționale - aspect care ține direct de rolul Expertului cheie nr. 4. b. Cerința este proporțională cu obiectul contractului: Sistemul informatic urmărește digitalizarea serviciilor publice oferite de ROMSILVA RA. Asistenții virtuali reprezintă un canal modern de interacțiune cu publicul, integrat în arhitectura generală a soluției. Solicitarea ca expertul responsabil cu redesign-ul proceselor de business să dețină competențe de analiză pentru implementarea acestui canal este adecvată și necesară pentru asigurarea coerenței între procesele de business și canalele digitale de livrare a serviciilor. Cerința nu depășește ceea ce este necesar pentru atingerea obiectivului contractului. c. Competența nu este una de dezvoltare tehnică, ci de analiză de business Formularea din caietul de sarcini se referă la „analiza de business pentru implementarea asistenților virtuali (Conversational Al)", nu la competențe de programare, antrenare de modele de limbaj sau dezvoltare software. Această distincție confirmă că cerința este plasată corect la nivelul expertului de procese de business, nu la nivelul echipei tehnice de dezvoltare. d. Lipsa demonstrației privind caracterul disproporționat: Contestatoarea afirmă că funcționalitatea de tip chatbot ar fi „minoră" și că competența ar fi de nișă, însă nu demonstrează că integrarea canalelor

Pagina 30 din 80 Conversațional Al în procesele de business ar fi ¡relevantă pentru rolul Expertului cheie nr. 4 sau că ar restrânge nejustificat concurența. Afirmația rămâne o apreciere subiectivă, nesusținută de o analiză concretă a impactului asupra pieței. Ca argumente, prezintă următoarele: - competența de analiză de business pentru implementarea asistenților virtuali este o extensie a rolului de analiză și îmbunătățire a proceselor de business, în condițiile în care proiectul vizează explicit digitalizarea interacțiunii cu beneficiarii (portal, formulare online, servicii digitale), domeniu în care componentele conversaționale au un rol direct în modelul de livrare a serviciilor publice; - beneficiază de o marjă de apreciere rezonabilă în a grupa competențe tehnice conexe în cadrul profilului unui singur expert-cheie, mai ales atunci când componenta respectivă face parte din ansamblul livrabilelor de analiză de business pe care acest expert le coordonează; - cerința nu impune, pentru competența de Conversațional Al, o certificare sau diplomă distinctă, ci se solicită doar „deținerea de competențe", care poate fi dovedită flexibil, inclusiv prin experiență de proiect, portofoliu profesional sau participare anterioară la implementări similare, iar nu printr-o calificare formală suplimentară, ceea ce reduce sensibil pretinsa disproporționalitate invocată de contestatoare. - obiectivele proiectului, astfel cum sunt descrise chiar în caietul de sarcini, includ expres digitalizarea interacțiunii cu beneficiarii prin portal, formulare online și servicii digitale. Componentele de tip Conversațional Al/chatbot reprezintă, în prezent, un instrument frecvent utilizat tocmai pentru îmbunătățirea proceselor de interacțiune cu beneficiarii, astfel încât cerința nu este arbitrară, ci se corelează direct cu unul dintre obiectivele declarate ale proiectului pe care Expertul cheie nr. 4 îl va îndeplini; - cerința contestată vizează o singură competență specifică, adăugată unui profil de expert care cuprinde, de altfel, un ansamblu mai larg de competențe relevante pentru rolul de bază — managementul proceselor de business, managementul cerințelor și managementul schimbării. O cerință de nișă, grefată pe un profil altfel corect corelat cu rolul, nu poate fi calificată, prin ea însăși, drept disproporționată, în absența unei demonstrații concrete a unui impact real asupra concurenței sau a accesului la procedură; - consideră chiar util ca profilul responsabil de analiza proceselor de business să acopere și componenta conversațională, tocmai pentru a asigura coerența dintre analiza proceselor operaționale existente și noile canale digitale de interacțiune (inclusiv chatbot) care le vor înlocui sau completa parțial, o decizie de organizare internă a echipei de experți aflată în marja de apreciere tehnică legitimă a autorității contractante. În concluzie, cerința de competențe privind analiza de business pentru implementarea asistenților virtuali este legată direct de rolul Expertului cheie nr. 4 în redesign-ul proceselor de business și în definirea noului model de livrare a serviciilor publice digitale. Ea este proporțională cu obiectul contractului și nu încalcă art. 2 alin. (2) lit. e) din Legea nr. 98/2016. Astfel, capătul de cerere este neîntemeiat și trebuie respins.

Pagina 31 din 80 D.2. Rolurile Expertului cheie nr. 8 și Expertului cheie nr. 9 se suprapun aproape integral, fără nicio diferențiere substanțială a responsabilităților: Contestatoarea susține că responsabilitățile, structura cerinței de experiență specifică și formularea competențelor profesionale ale Expertului cheie nr. 8 (Expert implementare Componenta de interoperabilitate) și ale Expertului cheie nr. 9 (Expert implementare Componenta de integrare și pregătire a datelor) sunt identice, singura diferență constând în denumirea componentei. Pe această bază, apreciază că cele două roluri se suprapun funcțional și solicită fie comasarea lor, fie o justificare obiectivă a separării. Solicită respingerea acestui capăt de cerere ca neîntemeiat, pentru următoarele motive: a. Cele două componente sunt distincte din punct de vedere funcțional și arhitectural: Deși ambele componente operează în zona datelor și a schimbului de informații, ele au obiective și arii de responsabilitate diferite: - Componenta de interoperabilitate (Expert cheie nr. 8) vizează asigurarea schimbului de date și de servicii între sistemul care face obiectul contractului si alte sisteme informatice externe (instituții publice, registre naționale, platforme guvernamentale etc.), pe baza unor standarde și protocoale de interoperabilitate. - Componenta de integrare și pregătire a datelor (Expert cheie nr. 9) vizează extragerea, transformarea, curățarea, consolidarea și încărcarea datelor din sursele interne existente ale ROMSILVA (aplicații insulare, fișiere, baze de date descentralizate) în noul sistem, inclusiv activitățile de migrare. Aceste două arii - interoperabilitate externă versus integrare/migrare internă a datelor - sunt complementare, dar distincte. Separarea rolurilor reflectă această diferență de obiect. b. Formularea similară a responsabilităților este generată de natura comună a activităților de implementare Activitățile de tip „transpunere a cerințelor din analiză și proiectare", „instalare și configurare", „testare" sunt comune tuturor experților de implementare pe componentă (inclusiv Experții nr. 5, 6 și 7). Faptul că textul responsabilităților urmează un șablon similar nu înseamnă că rolurile sunt identice. Diferențierea este dată de obiectul componentei pe care fiecare expert o implementează. Aceeași logică se aplică și celorlalți experți de implementare pe componentă, pe care contestatoarea nu îi contestă. c. Separarea rolurilor este proporțională cu complexitatea sistemului: Sistemul informatic include atât o componentă dedicată interoperabilității cu sisteme externe, cât și o componentă dedicată integrării și migrării volumului mare de date interne (sute de mii de unități amenajistice, date din multiple aplicații insulare etc.). Alocarea câte unui expert-cheie dedicat fiecărei componente asigură responsabilitate clară pe fiecare arie; expertiză specifică pe durata implementării; capacitatea de a gestiona simultan cele două fluxuri de lucru complexe. Cerința nu mărește nejustificat numărul de personal-cheie, ci reflectă arhitectura reală a soluției. d. Lipsa demonstrației privind imposibilitatea de a mobiliza doi experți:

Pagina 32 din 80 Contestatoarea afirmă că separarea ar mări nejustificat efortul de mobilizare, însă nu demonstrează că pe piață nu ar exista operatori economici capabili să propună doi specialiști cu profilurile solicitate sau că această cerință ar restrânge semnificativ concurența. Ca argumente, menționează următoarele: - cele două componente tehnice — interoperabilitate și integrare/pregătire a datelor, corespund unor arii funcționale distincte ale sistemului (schimb de date cu sisteme externe, respectiv migrarea și pregătirea datelor interne), care justifică menținerea a doi experți-cheie separați; - experții cheie au un rol determinant în realizarea activităților contractului și întocmirea livrabilelor și fost solicitați cu respectarea art. 3 din Instrucțiunea președintelui ANAP nr. 1/2017, deoarece activitatea acestora va fi reflectată direct în rezultatul contractului; - interoperabilitatea (schimbul de date și servicii cu sisteme externe, prin API/servicii web) și integrarea/pregătirea datelor (migrare, transformare, curățare a datelor interne - ETL) sunt discipline tehnice distincte în arhitecturile IT complexe, chiar dacă, în practica pieței, pot fi uneori acoperite de personal cu profil similar; - similitudinea de formulare a celor două fișe de expert reflectă un șablon de redactare comun, dar nu anulează rațiunea tehnică a separării celor două roluri, corespunzătoare celor două componente funcționale distincte ale sistemului (interoperabilitate, respectiv integrare și pregătire a datelor), amândouă necesare complexității proiectului; - complexitatea și amploarea proiectului (valoare estimată de 54.926.500 lei fără TVA, durată de 24 de luni, sistem alcătuit din multiple componente funcționale majore — Portal, GIS, gestiune a fluxurilor de lucru, interoperabilitate, integrare și pregătire a datelor, backup, securitate cibernetică, testare) justifică organizarea echipei de implementare pe roluri specializate, corespunzătoare fiecărei componente tehnice principale a sistemului, exact așa cum acestea sunt descrise distinct în capitolele tehnice ale Caietului de sarcini; o structură de proiect segmentată pe componente reprezintă o practică uzuală și rezonabilă pentru proiecte IT de această amploare, iar nu o multiplicare artificială de personal-cheie; - prin comparație, celelalte roluri de coordonator de implementare pe componentă - Experții cheie nr. 5, 6 și 7 (Portal, gestiune a fluxurilor de lucru, GIS), urmează același șablon de redactare, dar privesc domenii tehnice suficient de distincte, motiv pentru care nu extinde contestația și la aceștia. Această recunoaștere confirmă că simpla similitudine de formulare a fișelor de expert nu este un indiciu de nelegalitate, ci ține de un mod de redactare unitar al documentației pentru roluri de aceeași natură funcțională (coordonare de componentă), aspect neutru din perspectiva legalității. În concluzie, rolurile Expertului cheie nr. 8 și Expertului cheie nr. 9 privesc două componente funcționale distincte (interoperabilitate externă versus integrare și migrare internă a datelor). Formularea similară a responsabilităților de implementare este generată de natura comună a activităților de tip instalare/configurare/testare și nu atrage identitatea rolurilor. Separarea este justificată de complexitatea sistemului și este proporțională. Deci, consideră capătul de cerere neîntemeiat și necesar a fi respins.

Pagina 33 din 80 D.3. Cerința de competențe pentru Experții cheie nr. 2 și nr. 3 privind managementul serviciilor IT nu are legătură cu responsabilitățile de arhitect de sistem, respectiv de analist de business, ale acestor experți: Contestatoarea critică cerința din Cap. 11.1.2 și 11.1.3 ale caietului de sarcini conform căreia Expertul cheie nr. 2 (Arhitect de sistem) și Expertul cheie nr. 3 (Analist de business) trebuie să dețină competențe în domeniul managementului serviciilor IT, dovedite prin diplomă/certificare recunoscută. Aceasta susține că responsabilitățile celor doi experți privesc exclusiv proiectarea arhitecturii, respectiv analiza de business și elaborarea specificațiilor funcționale, fără nicio activitate specifică managementului serviciilor IT (ITIL), și că impunerea acestei competențe ar fi disproporționată. Solicită respingerea acestui capăt de cerere ca neîntemeiat, pentru următoarele motive: a. Competența de management al serviciilor IT este relevantă pentru calitatea arhitecturii și a analizei de business: Deși responsabilitățile principale ale Experților cheie nr. 2 și nr. 3 se concentrează pe etapa de proiectare și analiză, rezultatele activității lor (arhitectura sistemului și specificațiile funcționale) determină în mod direct modul în care sistemul va putea fi operat, monitorizat, întreținut și livrat ca serviciu pe durata de viață. O arhitectură și o analiză de business care nu țin seama de principii de management al serviciilor IT (disponibilitate, continuitate, gestionarea schimbărilor, niveluri de serviciu, suport) riscă să genereze un sistem dificil de operat și de menținut. Solicitarea ca acești experți să dețină competențe de management al serviciilor IT asigură că, încă din faza de concepție, soluția este proiectată și specificată cu luarea în considerare a cerințelor de operare ulterioară. b. Cerința este proporțională cu obiectul contractului: Sistemul informatic este unul critic, cu perioadă de garanție de 36 de luni și cu obligații de suport. Capacitatea de a proiecta o arhitectură și de a elabora specificații funcționale care să permită o operare eficientă pe durata ciclului de viață reprezintă un avantaj real. Cerința nu transformă Experții nr. 2 și nr. 3 în manageri de servicii IT operaționali, ci le solicită o competență complementară care îmbunătățește calitatea livrabilelor din etapa de analiză și proiectare. c. Competența nu este excesivă și nu creează o barieră nejustificată: Cerința se referă la deținerea de competențe dovedite printr-o diplomă sau certificare recunoscută în domeniul managementului serviciilor IT. Pe piață există numeroase certificări accesibile (inclusiv din familia ITIL, dar nu exclusiv) pe care specialiștii în arhitectură și analiză de business le pot obține. Contestatoarea nu demonstrează că această cerință ar reduce semnificativ numărul de specialiști disponibili sau ar restrânge concurența în mod nejustificat. d. Corelarea cu celelalte cerințe de competențe: Faptul că Expertul cheie nr. 1 (Manager de proiect) are o cerință de competențe direct legată de managementul de proiect confirmă abordarea de a solicita competențe relevante pentru fiecare rol.

Pagina 34 din 80 În cazul Experților nr. 2 și nr. 3, competența de management al serviciilor IT a fost apreciată ca relevantă pentru calitatea pe termen lung a soluției proiectate și analizate, nu ca o cerință mecanică, aplicată indiferent de rol. Ca argumente susține că: - cunoștințele de management al serviciilor IT sunt transversale și direct utile oricărui expert implicat într-un proiect care presupune, în final, punerea în producție și operarea continuă a sistemului; caietul de sarcini prevede chiar obligații extinse de garanție, suport tehnic și mentenanță, aspecte a căror bună proiectare depinde inclusiv de înțelegerea ciclului de viată al serviciilor IT de către arhitectul de sistem si analistul de business; - impunerea unei competențe transversale suplimentare, care asigură coerența dintre etapa de proiectare/analiză și etapa ulterioară de operare a sistemului, se înscrie în marja de apreciere legitimă a autorității contractante privind calificarea profesională a experților- cheie, fără a depăși ceea ce este necesar și adecvat obiectivului urmărit; - cerința este direct relevantă pentru obiectul propriu-zis al sistemului, caietul de sarcini prevede, ca o componentă distinctă a sistemului, „Componenta de service desk", care trebuie să fie „conformă cu practicile ITIL". Managementul serviciilor IT nu este, așadar, o disciplină abstractă, atașată artificial celor doi experți, ci descrie chiar unul dintre subsistemele funcționale pe care Expertul arhitect de sistem trebuie să îl integreze în arhitectura tehnică de ansamblu, respectiv pe care Expertul analist de business trebuie să îl reflecte corect în specificațiile funcționale și în fluxurile de proces documentate; - întrucât componenta de service desk trebuie proiectată și integrată coerent cu restul arhitecturii sistemului, este necesar ca înșiși experții responsabili de arhitectura tehnică și de analiza cerințelor de business să înțeleagă principiile de bază ale managementului serviciilor IT, pentru a putea proiecta și documenta corect modul în care celelalte componente ale sistemului interacționează cu procesele ITIL de incident, probleme și schimbare, astfel încât cerința reflectă o nevoie funcțională reală a proiectului, iar nu o suprapunere nejustificată de discipline; - faptul că aceeași competență este menționată identic ambilor experți nu reprezintă un indiciu de redactare mecanică: atât arhitectul de sistem, cât și analistul de business intervin, din perspective complementare (tehnică, respectiv funcțională), asupra aceleiași componente de service desk și asupra proceselor ITIL pe care aceasta trebuie să le acopere, astfel încât este normal ca ambii experți să dețină un nivel minim comun de înțelegere a managementului serviciilor IT, chiar dacă rolul lor principal rămâne diferit. În concluzie, cerința de competențe privind managementul serviciilor IT pentru Experții cheie nr. 2 și nr. 3 este legată de necesitatea ca arhitectura și analiza de business să țină seama de cerințele de operare și de suport pe durata ciclului de viață al sistemului. Ea este proporțională cu obiectul contractului si nu încalcă principiul proporționalității prevăzut de art. 2 alin. (2) lit. e) din Legea nr. 98/2016. Capătul de cerere este neîntemeiat și trebuie respins. D.4. Observație de context privind modul de redactare a cerințelor pentru expert- coordonator pe componentă:

Pagina 35 din 80 Contestatoarea observă că profilele Experților cheie nr. 5, 6, 7, 8 și 9 urmează un șablon identic de responsabilități și de competențe profesionale, singurul element variabil fiind denumirea componentei tehnice. Aceasta prezintă observația ca element de context care ar întări teza generală a contestației, potrivit căreia documentația ar fi fost redactată mecanic, prin duplicarea unor șabloane și prin asamblarea unor fragmente provenite din fișe de produs, iar nu printr-o analiză funcțională proprie. Solicită respingerea acestei observații ca neîntemeiată, pentru următoarele motive: a. Utilizarea unui șablon comun pentru experții de implementare pe componentă este legitimă și eficientă: Experții cheie nr. 5-9 au, toți, rol de coordonare a implementării câte unei componente software distincte. Activitățile de bază ale unui astfel de rol - transpunerea cerințelor din analiza și proiectarea în funcționalități, participarea la instalare și configurare, testarea, colaborarea cu ceilalți experți, asigurarea conformității cu documentația de proiectare - sunt structural similare, indiferent de componenta tehnică vizată. Utilizarea unui șablon comun de responsabilități, adaptat prin denumirea componentei, este o practică de redactare coerentă și eficientă, care asigură uniformitatea cerințelor și facilitarea evaluării. Ea nu demonstrează absența unei analize funcționale. b. Diferențierea reală este dată de obiectul fiecărei componente: Deși structura responsabilităților este similară, obiectul pe care fiecare expert îl coordonează este distinct: - Expert nr. 5 - Componenta Portal; - Expert nr. 6 - Componenta de gestiune a fluxurilor de lucru; - Expert nr. 7 - Componenta GIS; - Expert nr. 8 - Componenta de interoperabilitate; - Expert nr. 9 - Componenta de integrare și pregătire a datelor. Aceste componente au cerințe tehnice, volume de lucru și riscuri diferite, ceea ce justifică alocarea câte unui expert-cheie dedicat. Contestatoarea însăși recunoaște că, pentru Experții nr. 5, 6 și 7, domeniile sunt suficient de distincte încât să justifice roluri separate. c. Observația nu constituie un motiv de nelegalitate autonom: Contestatoarea nu solicită eliminarea sau comasarea Experților nr. 5, 6 și 7 și nu identifică o încălcare concretă a vreunei dispoziții legale rezultând din utilizarea șablonului comun. Observația rămâne un argument de context, fără efect juridic propriu asupra legalității documentației de atribuire. Ca argumente, susține că: - profilele Experților cheie nr. 5, 6, 7, 8 și 9 cuprind responsabilități generale, însă cu aplicabilitate în componente tehnice diferite; - competențe profesionale solicitate a fi demonstrate sunt în domeniul implementării de soluții pe platforma ofertată, pentru că exact acest aspect se dorește a fi îndeplinit de fiecare expert în parte, având la bază chiar o analiză funcțională proprie, pornind de la nevoile reale ale autorității contractante;

Pagina 36 din 80 - șablonul comun de redactare a celor cinci profiluri de experți-coordonator reflectă o structură funcțională comparabilă a rolurilor respective (coordonare a implementării pe o componentă tehnică dedicată), nu o lipsă de analiză proprie; - similitudinea de formă nu echivalează cu identitate de conținut: fiecare fișă de expert este particularizată prin denumirea componentei tehnice coordonate și prin raportarea responsabilităților generice la specificul tehnic și funcțional propriu al respectivei componente, astfel cum este descris pe larg în capitolele tehnice dedicate ale caietului de sarcini; - afirmația potrivit căreia documentația ar fi fost asamblată „din fișe de produs ale unor producători determinați" rămâne o simplă supoziție a contestatoarei, exprimată chiar de aceasta cu rezerva „cel mai probabil", neînsoțită de nicio dovadă concretă (de exemplu, o comparație textuală punctuală cu documentația tehnică a unui anumit producător), în condițiile în care întreaga documentație este acoperită de clauza „sau echivalent". În concluzie, arată că, utilizarea unui șablon comun de responsabilități pentru experții-coordonatori pe componentă este o alegere de redactare legitimă, care reflectă natura similară a activităților de implementare și nu demonstrează absența unei analize funcționale sau caracterul mecanic al documentației. Observația contestatoarei nu atrage nelegalitatea specificațiilor. Capătul de cerere/observația este neîntemeiat(ă) și trebuie respins(ă). E. Necorelarea prevederilor documentației de atribuire privind durata de prestare a serviciilor, calendarul activităților, recepția finală și formalitățile de plată face imposibilă determinarea duratei efective de prestare și elaborarea Graficului de prestare pe baze clare și unitare: Contestatoarea susține că prevederile documentației de atribuire privind durata de 24 de luni, calendarul orientativ (cu instruire în lunile 23-24), termenele de verificare și remediere (5 + 3 zile lucrătoare), recepția finală și mențiunea că ultima lună contractuală este dedicată formalităților de plată ar fi necorelate, făcând imposibilă determinarea duratei efective disponibile pentru prestarea serviciilor si elaborarea unitară a Graficului de prestare (factorul Pt4). Solicită respingerea acestui capăt de cerere ca neîntemeiat, deoarece caietul de sarcini prevede că toate activitățile tehnice, livrările, testările și perioada de 4 săptămâni de funcționare fără incidente majore trebuie finalizate cel târziu la sfârșitul lunii 23 din graficul de implementare, luna 24 fiind rezervată exclusiv formalităților administrative de recepție finală, facturare și procesare a plății. Ofertanții au, așadar, o regulă clară pe baza căreia își pot construi Graficul de prestare: activitățile de prestare (inclusiv instruirea) trebuie planificate astfel încât să se încheie până la finalul lunii 23, lăsând luna 24 pentru formalitățile de recepție și plată. Calendarul orientativ din caietul de sarcini are caracter orientativ. Ofertanții pot propune justificat durate diferite pentru faze, cu încadrarea în termenul maxim de 24 de luni. Caietul de sarcini stabilește limita efectivă pentru activitățile tehnice (sfârșitul lunii 23). Orice ofertant diligent își va planifica instruirea și celelalte activități astfel încât să respecte această limită. Regula conform căreia livrabilele trebuie depuse cu anticipație (pentru a permite verificarea de 5 zile lucrătoare și eventuala remediere de 3 zile

Pagina 37 din 80 lucrătoare) rămâne aplicabilă. Ofertanții o vor integra în Graficul de prestare, în interiorul termenului maxim de finalizare a activităților tehnice (sfârșitul lunii 23). Operatorii economici dispun de o informare completă, corectă și precisă privind durata efectiv disponibilă pentru prestarea serviciilor. Graficul de prestare poate fi elaborat pe baze unitare, iar drumul critic poate fi calculat fără a recurge la interpretări divergente. Ca argumente, prezintă următoarele: - Durata estimată de implementare a contractului va fi de cel mult 24 de luni de la data semnării acestuia de către ambele părți. - Modelul de contract definește clar „Durata de prestare a serviciilor" ca fiind intervalul cuprins între data stabilită pentru începerea prestării și data încheierii procesului-verbal privind recepția finală. Durata de implementare a contractului (cel mult 24 de luni) cuprinde această durată inițială, de prestare a serviciilor, plus durata necesară pentru recepția finală și plățile finale. - Tocmai pentru cuprinderea tuturor activităților necesare (implementare, recepție și plată), ofertantul trebuie să propună: a) un Plan de lucru, prin care să demonstreze organizarea ierarhică, o structură detaliată de defalcare a serviciilor/activităților, cu o defalcare optimă care facilitează atât monitorizarea detaliată cât și raportarea executivă și b) un Grafic de prestare, prin care să demonstreze o reprezentare GANTT foarte bună a activităților și subactivităților conform Planului de lucru/structurii detaliate de defalcare a serviciilor/activităților. - caietul de sarcini este clar, prevederile sale sunt coroborate: termenele de verificare (5 zile) și remediere (3 zile) sunt expres incluse „în interiorul termenului limită de prestare a fiecărei faze", nefiind adăugate ulterior; textul este explicit: „Contractantul are obligația de a depune livrabilele ... astfel încât să includă perioada de verificare ... precum și cea necesară remedierii”. Un ofertant diligent își poate construi Graficul de prestare astfel încât activitățile efective să se încheie suficient de devreme (de exemplu, în cursul lunii 22-23) pentru a lăsa timpul necesar verificării, remedierii și recepției finale până cel târziu în luna 24; - caietul de sarcini oferă expres ofertanților libertatea de a-și adapta planificarea: „Ofertanții pot opta justificat pentru durate diferite pentru fazele proiectului, cu condiția încadrării în termenul contractual maxim", exact mecanismul prin care fiecare ofertant își poate rezolva coerent propria planificare în raport cu propria metodologie și resurse, ceea ce constituie o dovadă de flexibilitate a documentației, nu de neclaritate; - calendarul de implementare este declarat expres „orientativ", iar nu obligatoriu în privința datelor exacte; caracterul orientativ permite tocmai adaptări rezonabile de către fiecare ofertant, fără a compromite comparabilitatea ofertelor la factorul de evaluare Pt4, care evaluează tocmai calitatea și realismul planificării propuse de fiecare ofertant în parte; - nicio prevedere din documentație nu impune ca activitatea de instruire să se desfășoare integral și exclusiv în luna 24; calendarul orientativ indică un interval maxim posibil, nu o obligație de a epuiza toată luna respectivă cu activități de prestare efectivă; - definirea distinctă în art. 1 din modelul de contract, a conceptelor de „Durată de valabilitate a contractului”, „Durata de prestare a serviciilor" și, separat, în

Pagina 38 din 80 art. 5.2 a „Duratei de executare a contractulu”i nu constituie o incoerentă redacțională, ci reflectă o tehnică juridică uzuală în contractele publice complexe, prin care termeni distincți acoperă faze și efecte juridice diferite: intrarea în vigoare și epuizarea efectelor contractuale, pe de o parte, perioada efectivă de prestare până la recepția finală, pe de altă parte, respectiv termenul contractual maxim; - chiar dacă definiția contractuală a „Duratei de prestare a serviciilor" leagă finalul acesteia de încheierea procesului-verbal de recepție finală, această opțiune redacțională este legitimă și frecvent întâlnită în contractele de servicii complexe, tocmai pentru a proteja interesul autorității contractante: activitatea de prestare nu se consideră finalizată prin simpla executare faptică a ultimei activități, ci abia după validarea sa formală, mecanism care responsabilizează Prestatorul să livreze din timp, astfel încât să rămână spațiu suficient pentru verificare, remediere și recepție înainte de expirarea celor 24 de luni contractuale; - mențiunea privind faptul că „ultima lună contractuală ... este dedicată formalităților legate de plată" nu impune încetarea integrală a oricărei activități tehnice în luna 24, ci subliniază că în planificarea proprie, aceștia trebuie să lase suficient timp, către finalul perioadei contractuale, pentru parcurgerea etapelor administrative de facturare și plată aferente ultimei tranșe contractuale (Tranșa 4 instruire); - în caietul de sarcini se precizează că „ofertanții pot opta justificat pentru durate diferite pentru fazele proiectului, cu condiția încadrării în termenul contractual maxim". Ofertanții trebuie să interpreteze calendarul orientativ prin raportare la această clauză de flexibilitate, alocând activitatea de instruire mai devreme (de exemplu, în lunile 21-22), tocmai pentru a lăsa marja necesară verificării, remedierii și recepției finale până la expirarea celor 24 de luni; - conform prevederilor pct. 9.3 din caietul de sarcini, în termen de maximum 5 zile lucrătoare de la semnarea contractului, Graficul de prestare va fi actualizat în consultare cu autoritatea contractantă, iar versiunea actualizată va deveni anexă la contract și va constitui referința oficială pentru monitorizarea execuției și aplicarea eventualelor penalități de întârziere. Această fază de consultare și ajustare, ulterioară atribuirii dar anterioară aplicării oricărei penalități, este exact mecanismul contractual prin care orice detaliu privind alocarea exactă a activităților în lunile finale ale contractului se clarifică și se validează bilateral, înainte de a produce vreun efect practic asupra executării; - faptul că exact acest aspect al planificării (realismul, fezabilitatea și alocarea coerentă a resurselor și activităților pe durata celor 24 de luni) este evaluat și punctat distinct la factorul Pt4 (Graficul de prestare, 15% din punctajul total) demonstrează că documentația tratează planificarea temporală drept un element de diferențiere calitativă a ofertelor, lăsat, în mod deliberat, la latitudinea profesională a fiecărui ofertant, iar nu ca pe o normă rigidă, unică și predeterminată, abordare compatibilă cu marja de apreciere tehnică a autorității contractante și cu natura factorilor calitativi de evaluare. În concluzie, autoritatea contractantă precizează că, toate activitățile tehnice trebuie finalizate până la sfârșitul lunii 23; luna 24 este rezervată formalităților administrative de recepție finală, facturare și plată.

Pagina 39 din 80 Față de toate argumentele tehnice și juridice expuse, formulează următoarele concluzii: 1. Toate capetele de cerere pe fond sunt neîntemeiate și trebuie respinse, pentru următoarele considerente esențiale: - o parte importantă a criticilor (structura tranșelor de plată și Formularul F1A, cerințele privind antrenarea/inferența modelelor Al, durata efectivă de prestare și calendarul activităților) fac obiectul Răspunsului consolidat la solicitările de clarificări care va fi publicat în conformitate cu prevederile din Fișa de date cap. VI.3 Informații suplimentare, până în data de 27.08.2026, inclusiv. - cerințele tehnice contestate (cluster activ-activ, portabilitate multi-cloud, specificații GIS, SIEM, optimizare resurse, backup, analiză și raportare, management identitate/acces etc.) sunt formulate, în esență, ca cerințe de performanță și funcționale, în deplină conformitate cu art. 156 alin. (1) lit. a) din Legea nr. 98/2016. Clauza generală „sau echivalent" este operabilă, iar contestatoarea nu a demonstrat că aceste cerințe ar favoriza un producător determinat sau ar restrânge nejustificat concurența. - cerința privind software-ul comercial (COTS) este justificată obiectiv de sensibilitatea datelor, de nivelul de securitate solicitat și de necesitatea unui suport tehnic garantat pe durata ciclului de viață al sistemului, în temeiul art. 155 alin. (2) din Legea nr. 98/2016. - grila de punctaj pentru factorii calitativi Pt2, Pt3 și Pt4 respectă structura pe trei niveluri de calitate recomandată de Catalogul ANAP al factorilor de evaluare pentru servicii intelectuale si permite diferențierea reală a ofertelor, conform art. 32 alin. (2) din HG nr. 395/2016. - cerințele privind experții-cheie (competențe Conversațional Al, management servicii IT, separarea rolurilor de interoperabilitate și integrare date) sunt proporționale cu complexitatea sistemului și cu responsabilitățile reale ale fiecărui rol. - avizul pozitiv nr. 412CTE/18.06.2026 emis de Comitetul Tehnico-Economic pentru Societatea Informațională confirmă că specificațiile tehnice ale Caietului de sarcini au fost analizate din perspectiva interoperabilității, securității, fezabilității și neutralității tehnologice. 2. Documentația de atribuire, asigură operatorilor economici o informare completă, corectă și precisă, conform art. 3 lit. z) și art. 154 alin. (1) din Legea nr. 98/2016. Nu există neclarități, contradicții sau restrângeri nejustificate ale concurenței care să atragă nelegalitatea acesteia. În concluzie, proiectul fiind finanțat prin Programul Operațional Creștere Inteligentă, Digitalizare și Instrumente Financiare 2021-2027, ......... are obligația de a respecta cerințele contractului de finanțare, inclusiv aplicarea standardelor europene în domeniul digitalizării, securității cibernetice și trasabilității. Aceste condiții justifică cerințele tehnice riguroase, fără a încălca principiul proporționalității (art. 2 alin. (2) lit. e) din Legea nr. 98/2016). Documentația de atribuire a fost elaborată în conformitate cu art. 154 alin. (1) și art. 155-159 din Legea nr. 98/2016 și publicată. Toate cerințele tehnice, de calificare și clarificare respectă dispozițiile legale actualizate și principiile de transparență, tratament egal si proporționalitate consacrate la art. 2 alin. (2) din Legea nr. 98/2016. Astfel, toate criticile formulate de ......... SRL, sunt

Pagina 40 din 80 neîntemeiate, prin prisma interpretărilor eronate ale cadrului normativ, motiv pentru care, vă solicită: - respingerea contestației ca nefondată și neîntemeiată, - menținerea documentației de atribuire în forma publicată, respectiv menținerea procedurii de atribuire în derulare. ......... SRL, prin adresa nr. 1379/26.08.2026, înregistrată la Consiliu cu nr. 65016/27.08.2026, a transmis răspuns la punctul de vedere formulat de ......... nr. 15315/24.08.2026. Precizează că, privite în ansamblu, apărările formulate de autoritatea contractantă prin punctul de vedere nu înlătură neregulile semnalate prin contestație, ci le confirmă, de cele mai multe ori chiar prin propriile argumente și prin textul documentației pe care punctul de vedere îl invocă în sprijinul lor. Pentru aceste motive, coroborate cu lipsa unei argumentări obiective și temeinice din partea autorității contractante, solicită admiterea contestației. Consiliul, prin adresa nr. 67119/3388/C6/03.09.2026, a solicitat contestatoarei, ......... SRL, să transmită un punct de vedere la măsurile de remediere luate de autoritatea contractantă. ......... SRL a transmis punct de vedere nr. 1390/08.09.2026 la documentul Răspuns consolidat la solicitările de clarificări cu privire la documentația de atribuire nr. 15556/J.V./27.08.2026, înregistrat la Consiliu sub nr. 68299/09.09.2026, precizând că acest document nu constituie, în ansamblul său, un răspuns sistematic la motivele de contestație, ci o centralizare a răspunsurilor formulate întrebărilor punctuale adresate de operatorii economici în cadrul mai multor solicitări de clarificări. Rezultă, așadar, că unele dintre aspectele contestate de societatea sa au făcut obiectul unor întrebări formulate de alți operatori economici, caz în care răspunsul autorității contractante poate fi analizat direct prin raportare la critica sa, în timp ce altele nu au fost vizate de nicio întrebare, caz în care Răspunsul consolidat nu aduce nicio modificare situației semnalate prin contestație. Astfel, structurează punct de vedere pe capetele de cerere din contestație, astfel cum au fost dezvoltate prin răspunsul la punctul de vedere al autorității contractante, indicând pentru fiecare dacă și în ce măsură Răspunsul consolidat remediază neregula semnalată. Concluzionând, consideră că Răspunsul consolidat confirmă temeinicia contestației, astfel constată faptul că autoritatea contractantă nu a procedat la o reexaminare de fond a documentației de atribuire prin prisma criticilor formulate de societatea sa, ci s-a limitat în a răspunde punctual întrebărilor adresate de alți operatori economici, remediind doar acele aspecte care au făcut, întâmplător, obiectul unei asemenea întrebări. Acolo unde autoritatea contractantă a fost pusă direct în fața alegerii de a remedia o cerință contestată, aceasta a ales în majoritatea cazurilor să o mențină, iar în cel puțin două rânduri chiar să o înăsprească. O asemenea conduită, coroborată cu numărul mare de capete de cerere rămase complet neatinse, arată că restricțiile semnalate prin contestație nu sunt rezultatul unor omisiuni de redactare, susceptibile de corectare printr-un simplu răspuns la clarificări, ci al unei opțiuni asumate și menținute de autoritatea contractantă, care nu poate fi înlăturată decât prin decizia Consiliului.

Pagina 41 din 80 Pentru toate aceste motive, solicită să se rețină că Răspunsul consolidat la solicitările de clarificări remediază integral capătul de cerere B.7., parțial capetele de cerere A.1., B5, și B.6. și nu aduce nicio modificare capetelor de cerere B.1, B.2., B.3., B.4., B.8., B.9., B.10., B.11., B.12., C., D.1., D.2., D.3., D.4. și E., pe care le menține în integralitate, astfel cum au fost formulate prin contestație și dezvoltate prin răspunsul la punctul de vedere al autorității contractante. ........., prin adresa nr. 16706/J.V./15.09.2026, înregistrată la Consiliu cu nr. 71554/21.09.2026, a transmis concluzii scrise la punctul de vedere al contestatoarei nr. 1390/08.09.2026, depus după publicarea Răspunsului consolidat la solicitarea de clarificare nr. 15556/J.V./27.08.2026 ......... SRL a depus recipisa de consemnare a cauțiunii, în original, nr. 212621062/1 din data de 21.08.2026, eliberată de CEC BANK Sucursala Victoria, în sumă de 220.000,00 lei, înregistrată la CNSC sub nr. 63584/21.08.2026, solicitând respingerea pe fond, în totalitate, a contestației ca neîntemeiată și menținerea documentației de atribuire în forma publicată, astfel cum a fost clarificată prin Răspunsul consolidat. Din analiza susținerilor părților și a documentelor existente la dosarul cauzei, Consiliul reține cele ce urmează: ........., în calitate de autoritate contractantă, a inițiat licitația deschisă, în vederea atribuirii contractului de Servicii de dezvoltare a Sistemului Informatic Integrat în cadrul proiectului „Sistem Informatic pentru Gestionarea Fondului Forestier Administrat de Romsilva” Cod SMIS 348488, publicând în SEAP anunțul de participare nr. CN1095145/06.08.2026, cu o valoare estimată de 54.926.500,00 lei, fără TVA, iar criteriul de atribuire este „cel mai bun raport calitate-preț”. Împotriva documentației de atribuire, ......... SRL a înaintat Consiliului contestația în analiză, solicitând cele menționate în partea introductivă a deciziei. Din analiza contestației, Consiliul constată că autoarea acesteia critică modul în care autoritatea contractantă a înțeles să-și formuleze anumite cerințe ale documentației de atribuire, considerând că unele aspecte sunt neclare, contradictorii sau restrictive, motiv pentru care solicită remedierea lor. În ceea ce privește conținutul documentației de atribuire pusă la dispoziție operatorilor economici de către autoritatea contractantă, inclusiv clarificările aduse acesteia, dată fiind natura litigiului, actele atacate și solicitările adresate Consiliului cu privire la ele, acesta reține necesitatea examinării contestației primite prin raportare la următoarele dispoziții ale legislației privind achizițiile publice: - din HG nr. 395/2016: - art. 20 alin. (2) și (10) ”(2) Documentaţia de atribuire conţine orice cerinţă, criteriu, regulă şi alte informaţii necesare pentru a asigura ofertantului/candidatului o informare completă, corectă şi explicită cu privire la modul de aplicare a procedurii de atribuire. (10) Caietul de sarcini conţine, în mod obligatoriu, specificaţii tehnice care reprezintă cerinţe, prescripţii, caracteristici de natură tehnică ce permit fiecărui produs, serviciu sau lucrare să fie descris, în mod obiectiv, astfel încât să corespundă necesităţii autorităţii contractante.” - din Legea nr. 98/2016: - art. 154 alin. (1):

Pagina 42 din 80 ”Autoritatea contractantă are obligaţia de a elabora documentaţia de atribuire care conţine toate informaţiile necesare pentru a asigura operatorilor economici o informare completă, corectă și precisă cu privire la cerinţele achiziţiei, obiectul contractului şi modul de desfăşurare a procedurii de atribuire.” - art. 155 alin. (1) și (6): ”(1) Specificaţiile tehnice sunt stabilite prin documentaţia de atribuire şi definesc caracteristicile solicitate privind lucrarea, serviciul sau produsele care fac obiectul achiziţiei. (6) Specificaţiile tehnice trebuie să permită tuturor operatorilor economici accesul egal la procedura de atribuire şi nu trebuie să aibă ca efect introducerea unor obstacole nejustificate faţă de asigurarea unei concurenţe efective între operatorii economici. - art. 156 alin. (1) lit. a) și b), alin. (2) – (4): „Art. 156. - (1) Fără a aduce atingere normelor tehnice obligatorii de la nivel naţional, în măsura în care sunt compatibile cu actele normative adoptate la nivelul Uniunii Europene, specificaţiile tehnice se stabilesc în una dintre următoarele modalităţi: a) prin raportare la cerinţe de performanţă sau cerinţe funcţionale, inclusiv caracteristici de mediu, cu condiţia ca parametrii să fie suficient de precişi pentru a permite ofertanţilor să determine obiectul contractului şi autorităţile contractante să atribuie contractul; b) prin trimitere la specificaţii tehnice şi, ca ordine de prioritate, la standarde naţionale care transpun standarde europene, evaluări tehnice europene, specificaţii tehnice comune, standarde internaţionale, alte sisteme de referinţă tehnice instituite de către organismele de standardizare europene sau, în lipsa oricărora dintre acestea, la standarde naţionale, la agremente tehnice naţionale sau specificaţii tehnice naţionale referitoare la proiectarea, calcularea şi execuţia lucrărilor şi la utilizarea produselor; fiecare trimitere este însoţită de menţiunea "sau echivalent"; (2) Cu excepţia cazului în care acest lucru este justificat de obiectul contractului, specificaţiile tehnice nu precizează un anumit producător, o anumită origine sau un anumit procedeu care caracterizează produsele sau serviciile furnizate de un anumit operator economic şi nici nu se referă la mărci, brevete, tipuri, la o origine sau la o producţie specifică, care ar avea ca efect favorizarea sau eliminarea anumitor operatori economici sau produse. (3) Prin excepţie de la prevederile alin. (2), stabilirea specificaţiilor tehnice prin precizarea elementelor prevăzute la alin. (2) este permisă în situaţii excepţionale, în cazul în care nu este posibilă o descriere suficient de precisă şi de inteligibilă a obiectului contractului în conformitate cu dispoziţiile alin. (1); în aceste situaţii, precizarea elementelor prevăzute la alin. (2) este însoţită de cuvintele "sau echivalent". (4) În cazul în care autoritatea contractantă stabileşte specificaţiile tehnice potrivit dispoziţiilor alin. (1) lit. b), aceasta nu respinge o ofertă pe motiv că lucrările, produsele sau serviciile oferite nu sunt conforme cu specificaţiile tehnice la care se face trimitere, dacă ofertantul demonstrează în oferta sa, prin orice mijloace adecvate, că soluţiile propuse îndeplinesc într- un mod echivalent cerinţele definite prin specificaţiile tehnice. - art. 160 alin. (1) și (2): ”(1) Orice operator economic interesat are dreptul de a solicita clarificări sau informaţii suplimentare în legătură cu documentaţia de atribuire, cu respectarea termenului limită stabilit de autoritatea contractantă în anunţul de participare/ simplificat/de concurs. (2) Autoritatea contractantă stabileşte prin anunţul de participare/simplificat/de concurs unul sau două termene-limită în care va răspunde în mod clar şi complet tuturor solicitărilor de clarificare/informaţiilor suplimentare, conform prevederilor normelor metodologice la prezenta lege.” Așadar, regula o reprezintă situația în care nevoia sau oportunitatea achiziționării la un anumit nivel de performanță, precum și caracteristicile tehnice impuse, sunt stabilite de fiecare autoritate contractantă în parte, în funcție de necesitățile obiective și prioritățile comunicate de compartimentele din cadrul autorității contractante [art. 2 alin. (3) lit. b) și art. 12 alin. (3) lit. a) din HG nr. 395/2016]. Singura limitare a acestui drept al autorității contractante este determinată de introducerea unor obstacole nejustificate față de asigurarea

Pagina 43 din 80 unei concurențe efective între operatorii economici, în sfera unei astfel de posibilități aflându-se și situația impunerii de către autoritate a unor specificații și condiții care nu au legătură cu nevoia sa de achiziție. În consecință, pentru a cenzura prevederile documentației de atribuire stabilite de autoritatea contractantă, așa cum solicită petenta în prezenta cauză, este necesară stabilirea existenței în aceste prevederi a unor condiții restrictive, nejustificate și nelegale ce pot împiedica o concurență efectivă între operatorii economici. Prin urmare, contestatoarea, în susținerea demersului său la Consiliu, are obligația de a proba caracterul restrictiv al cerințelor criticate, prin prezentarea unor mijloace de probă pertinente și concludente, fiind pe deplin aplicabile în acest caz prevederile art. 249 din Codul de procedură civilă, potrivit cărora „cel care face o susținere în cursul procesului trebuie să o dovedească, în afară de cazurile anume prevăzute de lege”. Raționamentul se circumscrie faptului că nu se regăsesc în legislația achizițiilor publice prevederi care să permită operatorilor economici să ceară modificarea documentației de atribuire și, cu atât mai mult, să oblige autoritatea contractantă să modifice documentația de atribuire ori modificările aduse acesteia după cum solicită fiecare operator economic care apreciază că este necorespunzător întocmită. Astfel fiind, autoritatea contractantă nu are vreo obligație legală de a modifica documentația de atribuire după voința operatorului economic care a formulat contestație, iar Consiliul nu o poate obliga la o astfel de conduită, decât în măsura în care se face dovada încălcării reale și obiective a dispozițiilor legale ce împiedică restrângerea nejustificată a concurenței. Acestei obligații a contestatorului, de a face proba afirmațiilor sale, îi corespunde obligația autorității contractante de a proba și justifica că includerea anumitor cerințe este realizată cu respectarea prevederilor legale, astfel încât să asigure realizarea necesității sale, orice abatere de la acest scop putând fi cenzurată. În consecință, în evaluarea temeiniciei cererilor adresate Consiliului, acesta va avea în vedere faptul că ele trebuie justificate și probate obiectiv, cu dovada fermă a caracterului restrictiv, simpla pretindere a necesității modificării lor și simpla afirmație că restricționează concurența nefiind suficiente pentru a conchide asupra nelegalității actului atacat. În egală măsură, în stabilirea legalității actului atacat al autorității contractante va fi avută în vedere și proba pe care achizitoarea o realizează cu privire la legătura obiectivă de cauzalitate și dependența dintre prevederile documentației de atribuire astfel cum au fost acestea clarificate/modificate și nevoia sa de achiziție. Astfel, un prim aspect criticat, cel de la pct. A (A.1), Consiliul constată că privește presupusa existență a unei contradicții între structura tranșelor de plată prevăzută în fișa de date, Formularul F1A și modelul de contract, autoarea contestației solicitând ......... de atribuire prin corelarea expresă a acestora, inclusiv cu cerințele caietului de sarcini. În acest sens, Consiliul constată că în discuție sunt următoarele prevederi ale documentației de atribuire:

Pagina 44 din 80 - cap . III.1.7) Principalele condiții de finanțare și modalități de plată și/sau trimitere la dispozițiile relevante care le reglementează din Instructiuni pentru ofertanti/candidati (Fisa de date): „Plățile în cadrul contractului se vor realiza pt livrarea produselor si pt serviciile efectiv prestate,la prețurile unitare prevăzute în prop financiară detaliată a ofertantului declarat câștigător.Plata se va efectua în tranșe corespunzătoare jaloanelor definite în „Graficul de prestare” al proiectului,realizat pe baza calendarului de implementare,astfel: -Tranșa 1–la finalizarea doc de analiză de business și proiectare, acceptat fără observații de autoritatea contractantă (20% din val serviciilor de dezvoltare și implementare) -Tranșa 2- pt livrarea, instalarea și configurarea licențelor (inclusiv pentru asigurarea securității cibernetice a rețelei și sistemelor informatice dezvoltate); -Tranșa 3 – pt dezvoltarea aplicațiilor software; -Tranșa 4 – pt serviciile de instruire.” - Formular F1A: Nr. crt. Servicii / Produse solicitate UM Cantita te 1 LICENŢE NECESARE IMPLEMENTĂRII PROIECTULUI (software de bază și pentru asigurarea securității cibernetice a rețelei și sistemului informatic dezvoltat)

1.1. Componenta BPM (de gestiune a fluxurilor de lucru) licență 1 1.2. Componenta GIS (Geographic Information System) licență 1 1.3. Componenta de Portal licență 1 1.4. Componentă integrată de gestiune și analiză a datelor licență 1 1.5. Componenta de interoperabilitate licență 1 1.6. Componenta de monitorizare automată a performanței aplicațiilor licență 1 1.7. Componenta ETL (de integrare si pregătire a datelor) licență 1 1.8. Componenta de analiză și raportare avansată a datelor licență 1 1.9. Componenta inteligentă de optimizare automată a resurselor licență 1 1.10. Componenta de backup licență 1 1.11. Componenta de Service desk licență 1 1.12. Componenta de administrare a identității utilizatorilor licență 1 1.13. Componenta SIEM (Managementul Incidentelor de Securitate) licență 1 1.14. Componenta de mascare a datelor licență 1 1.15. Componenta de securizare a accesului privilegiat licență 1 2 SERVICII DE DEZVOLTARE ȘI IMPLEMENTARE

1 2.1. Servicii de dezvoltare pachet/set 1 2.2. Serviciile de instalare și configurare software de bază pachet/set 1 3 SERVICII DE INSTRUIRE / FORMARE PROFESIONALĂ SPECIFICĂ

3.1. Training utilizatori (pregătirea personalului care va utiliza echipamentele achiziționate prin proiect şi aplicaţia / serviciul software achiziționat şi/sau dezvoltat prin proiect) serv./pachet 1 3.2. Training administratori sistem (pregătirea personalului care va asigura administrarea şi mentenanţa echipamentelor achiziţionate prin proiect şi aplicaţiei / serviciului software achiziţionat şi/sau dezvoltat prin proiect, dacă acesta este angajat al beneficiarului) serv./pachet 1 - model de contract: - art. 4.1: „4.1. Preţul convenit pentru executarea contractului, plătibil Prestatorului de către Achizitor, este de lei fără TVA, respectiv lei cu TVA, conform propunerii financiare, Anexa nr.3 la contract, fiind compus din: 4.1.1. servicii de analiză de business şi proiectare, acceptate fără observaţii de autoritatea contractantă (20% din valoarea serviciilor de dezvoltare şi implementare), în valoare de ... lei fără TVA, respectiv ... lei cu TVA; 4.1.2. livrare, instalare şi configurare a licenţelor (inclusiv pentru asigurarea securităţii cibernetice a reţelei şi sistemelor informatice dezvoltate), în valoare de ... lei fără TVA, respectiv ... lei cu TVA; 4.1.3. servicii de dezvoltare a aplicaţiilor software, în valoare de ... lei fără TVA, respectiv ... lei cu TVA; 4.1.4. servicii de instruire, în valoare de ... lei fără TVA, respectiv ... lei cu TVA.” - caiet de sarcini: „13.3. LIVRABILE PENTRU PRODUSELE FURNIZATE ȘI SERVICIILE PRESTATE

Pagina 45 din 80 Principalele activități și livrabile ce trebuie avute în vedere de Contractant în cadrul acestui contract, dar fără a se limita la acestea, sunt: Nr. livrabi l LIVRABILE (Servicii și Produse solicitate) UM CANT. 1 DOCUMENT DE ANALIZĂ DE BUSINESS ȘI PROIECTARE 1.1 Prestatorul va prezenta rezultatele activității de analiză de business detaliată serv./pachet 1 1.2 Prestatorul va prezenta un document de proiectare sistem informatic serv./pachet 1 Aceste obligații ale ofertanților au constituit subiect al solicitărilor de clarificări, iar prin răspunsul consolidat nr. 15556/J.V./27.08.206, publicat în SEAP la aceeași dată, autoritatea contractantă a comunicat următoarele: „Întrebarea nr. 2: Pozițiile din Formularul F1A pentru analiză, SOC, garanție, e-learning și scanare vulnerabilități Referință: Formular F1A financiar.xlsx; Caiet de sarcini, cap. 5.5.1, cap. 5.5.4, cap. 6.1 și cap. 13.3 Text vizat: Formularul F1A conține 19 poziții: 15 licențe de componentă, „Servicii de dezvoltare”, „Serviciile de instalare și configurare software de bază”, „Training utilizatori” și „Training administratori sistem”. Solicitare: Formularul de propunere financiară detaliată nu conține poziții distincte pentru: (a) documentul de analiză de business și proiectare, care constituie baza Tranșei 1 de plată; (b) serviciile de tip SOC, solicitate 24/7 pe toată perioada de garanție; (c) serviciile de garanție și suport tehnic pe 3 ani; (d) aplicația software de instruire (e-learning) solicitată la cap. 5.5.4; (e) soluția de management al vulnerabilităților, furnizată ca serviciu pe toată durata contractului conform cap. 5.5.1. Vă rugăm să precizați pe ce poziții din Formularul F1A se cotează fiecare dintre aceste elemente sau, în caz contrar, să confirmați că ofertanții pot adăuga poziții suplimentare în formular, cu menținerea structurii existente. Răspuns la întrebarea nr. 2: Ofertanții trebuie să completeze fiecare element din Formularul nr. 1A (Propunerea financiară detaliată), fără a adăuga poziții suplimentare, menținându-se structura prezentată în documentația de atribuire. - Documentul de analiză de business și proiectare (în care se vor prezenta rezultatele activității de analiză de business detaliată, precum și un document de proiectare sistem informatic) (este parte din prima etapă a procesului de dezvoltare/implementare), - Serviciile de tip SOC, solicitate 24/7 pe toată perioada de garanție, - Serviciile de garanție și suport tehnic pe 3 ani și - Soluția de management al vulnerabilităților, furnizată ca serviciu pe toată durata contractului sunt incluse în capitolul bugetar ”SERVICII DE DEZVOLTARE ȘI IMPLEMENTARE” și nu se vor bugeta separat. Aplicația software de instruire (e-learning) este inclusă în capitolul bugetar ”SERVICII DE INSTRUIRE / FORMARE PROFESIONALĂ SPECIFICĂ” și nu se vor bugeta separat. ……………………………………………………………………………………………………………………………………………………… Întrebarea nr. 27 Tranșele de plată nu sunt corelate complet cu livrabilele, recepțiile și Formularul F1A Referință: Caietul de sarcini, cap. 14, paginile 191–192. „Tranșa 1 – la finalizarea documentului de analiză de business și proiectare, acceptat fără observații [...] (20% din valoarea serviciilor de dezvoltare și implementare).” Referință: Caietul de sarcini, cap. 14, paginile 191–192. „Tranșa 2 – pentru livrarea, instalarea și configurarea licențelor [...]; Tranșa 3 – pentru dezvoltarea aplicațiilor software; Tranșa 4 – pentru serviciile de instruire.” Referință: Proiectul de contract, art. 26, pagina 17. „Facturile vor fi emise după semnarea [...] proceselor verbale de recepție [...] pentru fiecare fază/etapă corespunzătoare jaloanelor definite în «Planul de lucru / Graficul de prestare».”

Pagina 46 din 80 Numai Tranșa 1 are un procent explicit. Nu sunt precizate procentele/plafonul celorlalte tranșe, recepția aferentă fiecărei poziții F1A și tratamentul licențelor livrate sau activate etapizat. Vă rugăm să publicați matricea completă jalon–livrabil–proces-verbal–poziție F1A–tranșă– procent/plafon–moment de facturare. Vă rugăm să confirmați că procentele, plafoanele și condițiile de plată care vor fi înscrise în contract sunt cele comunicate înainte de depunerea ofertelor și nu vor fi stabilite ulterior la semnare. Răspuns la întrebarea nr. 27: Costul aferent elaborării Documentului de analiză de business și proiectare se include la poziția „Servicii de dezvoltare” din Formularul F1A. Acest livrabil reprezintă prima etapă a procesului de dezvoltare/implementare și constituie baza pentru plata Tranșei 1, valoarea acesteia fiind de 20% din valoarea totală a poziției „Servicii de dezvoltare și implementare”. Singura limitare procentuală expresă este cea aferentă Tranșei 1, repartizarea valorică a celorlalte plăți rezultând direct din valorile prevăzute pe pozițiile din Formularul F1A. Cele 4 tranșe de plată definesc jaloanele financiare ale contractului, iar procesele-verbale prevăzute la art. 26.3 din proiectul de contract reprezintă documentele justificative de control al calității necesare pentru atestarea prestațiilor: • Tranșa 1 (Analiză și Proiectare): Se achită pe baza Procesului-verbal de recepție a raportului de analiză + Procesului-verbal de recepție a documentației de proiectare (lit. b și c din Art. 26.3). Prevederea proceselor-verbale distincte nu creează jaloane de plată separate, ci etape de control al calității, plata devenind exigibilă numai după acceptarea fără observații a ambelor documente. • Tranșa 2 (Licențe / Componente Software): Se achită pe baza Procesului-verbal de recepție cantitativă și calitativă pentru livrarea, instalarea și configurarea componentelor software (lit. a din Art. 26.3), pentru pozițiile aferente din F1A. • Tranșa 3 (Dezvoltare Software): Se achită pe baza Procesului-verbal de recepție pentru serviciile de dezvoltare software + Procesului-verbal de recepție a raportului de testare (lit. d și e din Art. 26.3). • Tranșa 4 (Instruire și Finalizare): Se achită pe baza Procesului-verbal de recepție a raportului de instruire (lit. f din Art. 26.3). Procesul-verbal de recepție a raportului de punere în producție (lit. g din Art. 26.3) și Procesul- verbal de recepție finală (pct. 13.4 din Caietul de sarcini) constituie condiții de acceptanță finală a sistemului informatic și condiționează plata ultimei tranșe și eliberarea garanției de bună execuție, fără a constitui o tranșă de plată distinctă.” Acest răspuns a fost considerat de către autoarea contestației că remediază doar parțial criticile sale, cu referire doar la pct. 2, motiv pentru care a declarat că: „Menținem solicitarea de remediere cu privire la corelarea expresă a procesului-verbal de recepție a punerii în producție cu structura celor patru tranșe de plată, aspect care rămâne neclarificat, cât și corelarea expresă a Caietului de sarcini, a Formularului F1A, a Fișei de date și a modelului de contract, în sensul arătat prin contestație.” Ulterior, la data de 17.09.2026, autoritatea contractantă a publicat în SEAP răspunsul consolidat nr. 16803/J.V./17.09.2026 prin care a comunicat următoarele: „Întrebarea nr. 3: Structurarea şi decontarea liniilor de analiză şi proiectare din tranşa 1 în Formularul F1A Vă rugăm să confirmaţi dacă în Formularul Financiar F1A, ofertanţii vor introduce o singură linie financiară unificată pentru „Servicii de analiză de business şi proiectare tehnică" (corespunzătoare celor 20% din valoarea serviciilor de dezvoltare - Tranşa 1), urmând ca decontarea acestei linii să fie efectuată pe baza semnării ambelor procese-verbale de recepţie (Raportul de Analiză şi Documentaţia de Proiectare), sau sa publicaţi formularul Financiar F1A corelat cu defalcarea valorica a transelor de plata. Răspuns la întrebarea nr. 3 Ofertanţii trebuie să completeze fiecare element din Formularul nr. 1A (Propunerea financiară detaliată), fără a adăuga poziţii suplimentare, menţinându-se structura prezentată în

Pagina 47 din 80 documentaţia de atribuire. A se vedea şi răspunsul la întrebarea nr. 2 aferentă Clarificării nr. 1 din Răspunsul Consolidat.” Analizând toate aceste informații, Consiliul constată că autoritatea contractantă a prezentat prin răspunsul consolidat nr. 15556/J.V./27.08.206, pct. 27, modul de corelare a procesului-verbal de recepție a punerii în producție cu structura celor patru tranșe de plată, astfel că au rămas fără obiect criticile sale din această perspectivă. Cât privește necesitatea corelării exprese a caietului de sarcini, a Formularului F1A, a fișei de date și a modelului de contract, în sensul arătat prin contestație, solicitată de contestatoare, Consiliul lipsa de temei a solicitării contestatoarei, în condițiile în care autoritatea contractantă a arătat care structura tranșelor de plată, și a adus clarificări referitoare la poziția în care trebuie cuprinse fiecare dintre costurile în discuție în cadrul Formularului F1A, respectiv faptul că acest formular are o structură fixă, nefiind permisă adăugarea de poziții noi. Prin urmare, Consiliul va respinge ca rămase fără obiect și aceste critici, reținând relevanța explicațiilor aduse de autoritatea contractantă prin aceste răspunsuri consolidate. În ceea ce privește următorul set de critici, respectiv cel de la pct. B, Consiliul reține că se referă la specificațiile tehnice, autoarea contestației susținând că sunt redactate pornind de la produse comerciale determinate, cu încălcarea art. 155 și art. 156 din Legea nr. 98/2016 și impun, în mod restrictiv, ofertarea exclusiv a componentelor de tip COTS. Astfel, o primă critică, cea de la pct. B1, se referă la componenta de gestionare a bazelor de date, arhitectura de tip cluster activ – activ, fără achiziția de componente adiționale. În acest sens, Consiliul constată că sunt criticate cerințele caietului de sarcini, cap. 5.3.3 Componentă integrată de gestiune și analiză a datelor, prin care autoritatea contractantă a solicitat, printre altele, următoarele: „Componenta de gestionare a bazelor de date trebuie să îndeplinească următoarele cerințe minime obligatorii: ……………………………………………………………………………………………………………………………………………………. • trebuie să permită instalarea bazei de date pe mai multe noduri (arhitectura de tip cluster), in regim activ-activ, pentru a asigura toleranta la căderi de noduri, fără a necesita achiziția de componente adiționale.” Această solicitare a constituit subiect al solicitărilor de clarificări, iar prin răspunsul consolidat nr. 15556/J.V./27.08.206, publicat în SEAP la aceeași dată, autoritatea contractantă a comunicat următoarele: - Clarificarea nr. 1: „Întrebarea nr. 78 — G. Gestiunea fluxurilor de lucru, datele, integrarea și raportarea, Echivalența pentru cerințele componentei de gestiune și analiză a datelor Referință: Caiet de sarcini, cap. 5.4.4 „Componentă integrată de gestiune și analiză a datelor” Text vizat: „instalarea bazei de date pe mai multe noduri (arhitectura de tip cluster), in regim activ-activ […] fără a necesita achiziția de componente adiționale”; „asigurând că sunt utilizate întotdeauna indexurile optime”; „nativ integrata cu modele proprii pre-antrenate”; „acces federalizat la surse de date disparate sau chiar deconectate”. Solicitare: Vă rugăm să confirmați că sunt acceptate soluții echivalente care asigură funcționarea în cluster cu disponibilitate ridicată prin licențe și componente incluse în oferta prezentată, optimizarea automată a planurilor de execuție, integrarea cu modele de inteligență artificială disponibile comercial sau open-source, respectiv interogarea federată a surselor de date, indiferent de denumirea comercială a acestor capabilități și de producătorul modelelor pre-antrenate.

Pagina 48 din 80 Răspuns la întrebarea nr. 78: Nu se confirmă. Solicitarea dumneavoastră vizează modificarea cerințelor tehnice minime și obligatorii din Caietul de Sarcini. Cerința privind funcționarea în regim Activ-Activ pe mai multe noduri este o cerință obligatorie de performanță și disponibilitate. O arhitectură de tip Activ-Pasiv nu este echivalentă și nu satisface cerința, întrucât nu asigură balansarea dinamică a încărcării și procesarea simultană pe toate nodurile din cluster. Componenta solicitată trebuie să fie livrată ca o soluție unitară, integrată nativ. Introducerea de software-uri terțe disparate, licențiate separat sau adăugate ca straturi intermediare pentru a suplini lipsa unor funcționalități native ale platformei de bază, contravine cerinței de arhitectură unitară și nu este acceptată. Soluția ofertată trebuie să includă nativ capabilitățile de analiză avansată (modele pre- antrenate) și acces federat la date, așa cum sunt ele specificate în Caietul de Sarcini. ……………………………………………………………………………………………………………………………………………………… Întrebarea nr. 83 — Arhitectura cluster activ-activ fara componente aditionale Referință: Caiet de sarcini, cap. 5.4.4 „Componenta integrata de gestiune si analiza a datelor”, Text vizat: „trebuie să permită instalarea bazei de date pe mai multe noduri (arhitectura de tip cluster), in regim activ-activ, pentru a asigura toleranta la căderi de noduri, fără a necesita achiziția de componente adiționale;” Solicitare: Va rugam sa confirmati ca se accepta solutii echivalente care asigura toleranta la caderea unui nod si continuitatea serviciului bazei de date, cu incadrarea in valorile RTO si RPO solicitate, chiar daca mecanismul nu este de tip activ-activ. Răspuns la întrebarea nr. 83: Nu se confirmă. Cerința privind instalarea bazei de date într-o arhitectură de tip cluster Activ- Activ pe mai multe noduri este o cerință tehnică și de performanță minimă și obligatorie.” - Clarificarea nr. 13: „Întrebarea nr. 18: Referitor la capitolul 5.3 Arhitectura tehnica, unde se precizează ca: "Din punct de vedere tehnic, arhitectura sistemului va include un mediu de producție și unul de testare-dezvoltare ce vor fi găzduite în Cloud-ul Privat Guvernamental - componenta de Cloud Dedicat bazat pe tehnologia Azure Hub Stack.”, coroborat cu următoarele cerințe de la capitolul 5.4.4 “trebuie să permită instalarea bazei de date pe mai multe noduri (arhitectura de tip cluster), in regim activ-activ, pentru a asigura toleranta la căderi de noduri, fără a necesita achiziția de componente adiționale; ... trebuie să permită salvarea/restaurarea precum si arhivarea/dezarhivarea datelor prin intermediul unor instrumente de back-up în regim de lucru online;” rezulta o incompatibilitate tehnologica care reduce practic la zero soluțiile COTS eligibile din piața, va rugam sa confirmați faptul ca, complementar infrastructurii Azure hub stack, componente din cadrul soluție propuse pot fi găzduite si in cadrul infrastructurii de Oracle Cloud@Customer existenta in cadrul Cloud-ul Privat Guvernamental. Răspuns la întrebarea nr. 18: Întregul sistem informatic va fi instalat și operat pe infrastructura Azure Stack Hub din Cloudul Privat Guvernamental (CPG). Cerința din Cap. 5.4.4 privind instalarea bazei de date în cluster activ-activ și toleranța la căderi de noduri privește capacitatea tehnică nativă a software-ului de bază de date ofertat, și nu o configurație specifică pe care Autoritatea Contractantă ar impune-o să fie implementată la nivel de infrastructură CPG. Ofertantul are obligația de a include un produs SGBD care deține această capabilitate de clusterizare/HA, însă arhitectura concretă de deployment în CPG va fi adaptată și configurată de ofertant în acord cu mecanismele IaaS puse la dispoziție de mediul Azure Stack Hub.” - Clarificarea nr. 15: „Întrebarea nr. 31: Sistemul de gestiune a bazelor de date: cluster activ-activ „fără componente adiționale” Prevederea vizată: Caietul de sarcini, cap. 5.4, Componenta integrată de gestiune și analiză a datelor: instalarea bazei de date „pe mai multe noduri (arhitectura de tip cluster), în regim activ-activ […] fără a necesita achiziția de componente adiționale”

Pagina 49 din 80 Solicitare: Foarte puține produse de pe piață oferă nativ cluster shared-everything activ-activ, iar formularea elimină arhitecturile activ-pasiv cu failover automat și replicile de citire, la fel de sigure funcțional pentru profilul de încărcare al beneficiarului. Vă rugăm să confirmați că sunt acceptate și arhitecturi de înaltă disponibilitate de tip activ-pasiv cu failover automat, respectiv activ-activ pe citire cu replicare sincronă, atât timp cât se asigură obiectivele de RTO/RPO și toleranța la căderea unui nod. Răspuns la întrebarea nr. 31: Nu se confirmă. Cerința privind instalarea bazei de date într-o arhitectură de tip cluster Activ- Activ pe mai multe noduri reprezintă o capabilitate tehnică nativă, minimă și obligatorie a produsului ofertat.” În legătură cu afirmațiile celor două părți, ca prim aspect, Consiliul constată că, prin susținerile sale, autoarea contestației nu demonstrează că prin introducerea acestei cerințe autoritatea contractantă ar fi urmărit achiziționarea unui anumit produs. În fapt, prin cele precizate, petenta susține că nicio soluție cunoscută care ar putea îndeplini cerința privind arhitectura bazei de date să fie de tip cluster în regim activ-activ nu este compatibilă cu componenta Microsoft Azure Stack Hub din Cloud-ul guvernamental. De altfel, Consiliul constată că, în realitate, autoarea contestație susținând că cerința în cauză este una restrictivă dorește modificarea ei în sensul că arhitectura să fie una de tip cluster, în regim activ-pasiv în loc de regim activ- activ. Prin urmare, din întregul raționament prezentat de contestatoare lipsește tocmai demonstrarea modului în care îi este afectată participarea la prezenta procedură de atribuire și demonstrarea faptului că pentru a atinge dezideratele impuse prin documentația de atribuire o soluție care prevede un regim activ- pasiv ar fi suficientă. În aprecierea sa, Consiliul a avut în vedere diferența dintre cele două configurații (activ-activ: două sau mai multe noduri deservesc simultan mai multe cereri, iar activ-pasiv: un nod principal gestionează toate cererile, iar unul sau mai multe noduri rămânând pasive), avantajele și dezavantajele acestora (distribuția și utilizarea volumului de muncă, performanța și scalabilitate, disponibilitate etc). Pe de altă parte, Consiliul reține că autoritatea contractantă a prezentat nevoia sa obiectivă ca fiind aceea ca sistemul ofertat să permită instalarea unei bazei de date pe mai multe noduri (arhitectura de tip ”cluster”), în regim activ- activ, cu toleranța la căderi de noduri, fără a necesita achiziția de componente adiționale, compatibilă cu componenta Microsoft Azure Stack Hub din Cloud-ul guvernamental, iar unul din argumentele prezentate este obținerea avizului pozitiv de la Comitetul Tehnico-Economic pentru Societatea Informațională nr. 412CTE/18.06.2026, organism a cărei activitate este reglementată de dispozițiile HG nr. 941/2013, care la art. 3 stabilește: „Art. 3. - Comitetul Tehnico-Economic are următoarele atribuţii principale: a) contribuie la elaborarea direcţiilor strategice în domeniul tehnologiei informaţiei şi comunicaţiilor, securităţii cibernetice şi societăţii informaţionale, în corelare cu cele ale strategiilor naţionale, ale Uniunii Europene, ale Alianţei Nord-Atlantice şi cele care decurg din relaţia României cu alţi parteneri internaţionali; b) avizează în vederea asigurării interoperabilităţii sistemelor informatice şi a eliminării finanţărilor multiple şi suprapunerilor funcţionale: (i) strategiile din domeniul tehnologiei informaţiei şi comunicaţiilor şi e-guvernării; (ii) documentaţiile tehnice aferente proiectelor de finanţare, inclusiv PCDIF, care au o componentă specifică domeniului tehnologiei informaţiei şi comunicaţiilor, ale instituţiilor publice, din punctul de vedere al securităţii cibernetice, interoperabilităţii, funcţionalităţilor,

Pagina 50 din 80 arhitecturilor sistemelor informatice, tehnologiilor utilizate în realizarea sistemelor informatice, drepturilor de autor, accesului la date deschise şi reutilizării informaţiilor din sectorul public; c) avizează proiectele tehnice, studiile de fezabilitate, respectiv caietele de sarcini din documentaţiile de achiziţii ale componentelor sau sistemelor IT&C aferente proiectelor pentru care se solicită garanţii guvernamentale, excluzând secţiuni referitoare la factori de evaluare, grafic de plăţi, termene de livrare; d) avizează conformitatea proiectelor de finanţare care au o componentă specifică domeniului tehnologiei informaţiei şi comunicaţiilor cu obiectivele strategiilor naţionale din domeniul tehnologiei informaţiei, comunicaţiilor şi societăţii informaţionale şi cu strategia naţională de securitate cibernetică, pronunţându-se inclusiv asupra oportunităţii acestor proiecte, iniţiate de instituţiile publice, astfel cum sunt definite de Legea nr. 500/2002 privind finanţele publice, cu modificările şi completările ulterioare, de companiile/societăţile naţionale sau societăţile reglementate de Legea societăţilor nr. 31/1990, republicată, cu modificările şi completările ulterioare, la care statul este acţionar unic ori majoritar, precum şi de institutele naţionale de cercetare-dezvoltare reglementate prin Ordonanţa Guvernului nr. 57/2002 privind cercetarea ştiinţifică şi dezvoltarea tehnologică, aprobată cu modificări şi completări prin Legea nr. 324/2003, cu modificările şi completările ulterioare; e) contribuie la evaluarea implementării strategiilor naţionale din domeniul tehnologiei informaţiei la nivelul administraţiei publice. f) în aplicarea prevederilor art. 4 alin. (5) din Ordonanţa de urgenţă a Guvernului nr. 89/2022 privind înfiinţarea, administrarea şi dezvoltarea infrastructurilor şi serviciilor informatice de tip cloud utilizate de autorităţile şi instituţiile publice, aprobată cu modificări şi completări prin Legea nr. 180/2023, efectuează o analiză la nivelul comisiei tehnice, în baza căreia emite avizul conform motivat sau, după caz, refuză motivat avizarea”. În același timp, Consiliul are în vedere că răspunsurile la solicitările de clarificări au fost formulate prin raportare la ceea ce s-a solicitat, și sunt consecvente cu conținutul documentației de atribuire, autoritatea contractantă refuzând solicitările privind modificarea cerinței privind arhitectura de tip cluster în regim activ-activ. Astfel, Consiliul constată că autoritatea contractantă a impus cerința ca soluția ofertată să poată asigura o arhitectură de tip cluster, în regim activ-activ, fără a impune cum anume se va realiza acest lucru, un anumit procedeu sau produs, condiționând această cerință doar în două privințe, să nu necesite achiziția de componente adiționale și să fie compatibilă cu componenta Microsoft Azure Stack Hub din Cloud-ul guvernamental. Prin urmare, Consiliul are în vedere cele stabilite în preambul, respectiv obligația petentei de a proba caracterul restrictiv al cerințelor criticate, prin prezentarea unor mijloace de probă pertinente și concludente, în raport de prevederile art. 249 din Codul de procedură civilă, respectiv lipsa unor prevederi care să permită operatorilor economici să ceară modificarea documentației de atribuire și, cu atât mai mult, să oblige autoritatea contractantă să modifice documentația de atribuire după cum solicită fiecare operator economic care apreciază că este necorespunzător întocmită, astfel de măsuri putând fi dispuse de către Consiliu doar în măsura în care se face dovada încălcării reale și obiective a dispozițiilor legale pentru a împiedica restrângerea nejustificată a concurenței, ceea ce în speță nu este cazul. În aceste condiții, în lipsa unor alte informații și susțineri care să demonstreze caracterul restrictiv al cerinței criticate, Consiliul va respinge ca nefondate aceste critici formulate de contestatoare. În ceea ce privește următoarea critică, respectiv cea de la pct. B.2, Consiliul reține privește cerința de portabilitate, autoarea contestației susținând

Pagina 51 din 80 că solicitarea portabilității pe platformele AWS, Azure și Google Cloud, la nivelul aceleiași componente de bază de date, este disproporționată în raport cu infrastructura fixă de implementare declarată în restul documentației. În acest sens, Consiliul are în vedere că afirmațiile contestatoarei privesc una dintre cerințele funcționale stabilite de autoritatea contractantă în caietului de sarcini de la cap. 5.4.4. Componentă integrată de gestiune și analiză a datelor, potrivit căreia: „- Componenta trebuie să ofere suport pentru instalarea in mod hibrid sau in cloud, pe oricare dintre platformele AWS, Azure, Google Cloud.” În legătură cu această cerință, autoarea contestației susține că este contrazisă de restul documentației de atribuire, care stabilește în mod expres că sistemul va fi implementat într-un mediu determinat, respectiv pe infrastructura Cloud-ului guvernamental bazat pe Azure Stack Hub, fapt ce face, în opinia sa, inutilă solicitarea dovedirii suportului de instalare pe oricare din platformele indicate, motiv pentru care solicită eliminarea cerinței. În replică, autoritatea contractant arată că această cerință vizează portabilitatea și maturitatea tehnologică a produsul, nu locația de instalare, și aduce argumente cu privire la justificarea cerinței și nevoia acoperită de aceasta, apreciind că nu este o cerință disproporționată, respectiv că nu este în contradicție cu restul documentației de atribuire. În legătură cu această cerință, raportat la susținerile celor două părți, Consiliul constată că se solicită eliminarea ei de către petentă în condițiile în care lipsește o minimă justificare care să demonstreze nelegala introducere a acesteia în documentația de atribuire și motivele pentru care impunerea ei este de natură a împiedica autoarea contestației în participarea la procedura de față. Or, așa cum s-a stabilit în preambul, ca și în precedent, era de datoria sa în a proba caracterul restrictiv al cerinței criticate, neexistând în cadrul legislației achizițiilor publice prevederi care să le permită operatorilor economici să ceară modificarea documentației de atribuire după cum solicită fiecare operator economic care apreciază că este necorespunzător întocmită, Consiliul putând dispune măsuri doar dacă se face dovada încălcării reale și obiective a dispozițiilor legale și restrângerea artificială a concurenței, ceea ce în cauză nu s-a demonstrat. Prin urmare, Consiliul va respinge ca nefondată și această critică. În ceea ce privește următoarea critică, Consiliul reține că privește componenta server GIS, autoarea contestației susținând că este redactată pornind de la o soluție predeterminată, respectiv Esri ArcGIS Enterprise. În acest sens autoarea contestației invocă faptul anumite cerințe sunt fie formulate prin preluarea denumirii comerciale a unor aplicații, termeni sau concepte, fie se referă la tehnologii perimate, pe care le prezintă, solicitând: „(…) constatarea faptului că specificațiile tehnice ale componentei Server GIS sunt redactate pornind de la platforma Esri ArcGIS Enterprise, contrar art. 155 alin. (6) și art. 156 alin. (2)- (3) din Legea nr. 98/2016, și solicităm fie eliminarea, fie reformularea acestora la nivel de funcționalitate necesară, fără raportare la concepte, denumiri de produse sau limite tehnice specifice unui singur producător.” În contra celor susținute de contestatoare, autoritatea contractantă prezintă argumente pentru a le combate, precizând că acceptă soluții echivalente care asigură aceleași funcții, performanțe și capabilități tehnice, indiferent de denumirea comercială a formatelor, componentelor sau platformelor ofertate, pe piață existând soluții comerciale alternative care

Pagina 52 din 80 determină același rezultat, iar cerințele în cauză sunt însoțite de mențiune expresă ”sau echivalent”. Având în vedere cele reclamate de petentă, Consiliul constată că în discuție sunt următoarele prevederi ale caietului de sarcini: - cap. 5.4.2.1. Cerințe funcționale Componenta GIS: „Colectarea și Gestionarea Datelor pe Teren: se vor efectua cu o aplicatie mobila (ArcGIS Field Maps sau echivalent)” - cap. 5.4.2.2.1.Software Desktop GIS5 (nu cap. 5.4.2.2.3. Software Server GIS cum invocă autoarea contestației): „• mod stocare date in format geodatabase local pe calculatorul de lucru ce suporta pana la 1 TB.” - 5.4.2.2.3. Software Server GIS: „• trebuie să permită rezolvarea conflictelor de versiuni atat la nivelul versiunii ”parent” a bazei de date cat şi in cadrul sesiunii de editare. ……………………………………………………………………………………………………………………………………………………… • produsul GIS destinat dezvoltării de portale web GIS trebuie să ofere urmatoarele facilităţi: o Trebuie să permită dezvoltarea de aplicatii RIA (Rich Internet Applications), fără a avea cunostinţe avansate de programare, utilizând API-uri pentru .NET, JavaScript, Java, Microsoft Silverlight. HTML 5 şi Adobe Flex în care să se poată utiliza animatii, înregistrari video.” În legătură cu aceste cerințe, Consiliul constată că au fost solicitate clarificări, iar prin răspunsul consolidat nr. 15556/JV/27.08.2026, autoritatea contractantă a remediat parte din aceste cerințe, în sensul că răspunsurile date au fost în concordanță cu cele solicitate de contestatoare, și acceptate de aceasta ca atare după cum rezultă din punctul său de vedere nr. 1390/ 08.09.2026, astfel că aceste critic vor fi respinse ca rămase fără obiect, mai puțin în ceea ce privește cerința de la cap. 5.4.2.2.3. Software Server GIS din caietul de sarcini privind „(…) rezolvarea conflictelor de versiuni atat la nivelul versiunii ”parent” a bazei de date (…)”, referitor la care își menține criticile. În legătură cu această cerință, Consiliul consideră relevante cele precizate de autoritatea contractantă prin clarificarea nr. 15, pct. 18, pag. 223, din răspunsul consolidat nr. 15556/JV/27.08.2026, invocate de către achizitoare, cunoscute de către petentă, dar necombătute de aceasta: „Întrebarea nr. 18: Mecanismul proprietar de versionare a bazei de date geospațiale Prevederea vizată: Caietul de sarcini, cap. 5.4, Software Desktop GIS și Server GIS: administrarea și editarea datelor „pe versiuni distincte ale aceluiași set de date”, „fiecare utilizator trebuie sa dispună de propria versiune de date”, comprimarea bazelor de date cu versiuni multiple în stare conectată, reconciliere pe „versiunea parent” Solicitare: Cerințele descriu implementarea internă (mecanismul de versioning cu reconcile/post și compress) a unui singur produs comercial, iar nu rezultatul funcțional urmărit. Solicităm confirmarea că aceste cerințe se consideră îndeplinite de ORICE mecanism tehnic care asigură rezultatul funcțional urmărit, editare concurentă multi-utilizator, izolarea modificărilor până la validare, detectarea și rezolvarea conflictelor, istoricul modificărilor și replicarea/sincronizarea între baze de date, indiferent dacă acesta este implementat prin „versiuni” în accepțiunea unui producător anume, prin branch-uri, prin MVCC nativ al sistemului de gestiune a bazelor de date sau prin tranzacții lungi. Răspuns la întrebarea nr. 18: Se confirmă. Cerințele se consideră îndeplinite de orice mecanism tehnic care asigură rezultatul funcțional urmărit: editare concurentă multi-utilizator, izolarea modificărilor până la validare, detectarea și rezolvarea conflictelor, istoricul modificărilor și replicarea/sincronizarea între baze de date. Sarcina probei privind asigurarea integrală a rezultatului funcțional revine ofertantului.”

Pagina 53 din 80 Prin urmare, autoritatea contractantă a arătat precizat ceea ce urmărește prin cerința în cauză (rezultatul funcțional urmărit), cu referire expresă inclusiv la aspectul criticat, astfel că, raportat la cele solicitate de petentă, citate anterior, și această cerere a sa a rămas fără obiect. În aceste condiții, criticile contestatoarei de la acest punct vor fi respinse ca rămase fără obiect. În ceea ce privește următorul aspect criticat, cel de la pct. B.4, Consiliul constată că privesc cerințele caietului de sarcini de la cap. 5.4.8 Componenta pentru administrarea identității utilizatorilor, prin care autoritatea contractantă a stabilit următoarele: „(…) Componenta de management al cererilor de acces trebuie sa indeplineasca urmatoarele cerinte: ● Trebuie sa fie bazata pe standardul BPEL pentru orchestrarea proceselor sau să dispună de un motor de fluxuri de lucru (workflow) capabil de modelare vizuală a proceselor (low-code/no-code) și orchestrare prin standarde web moderne (ex: REST API, JSON, Webhooks); ……………………………………………………………………………………………………………………………………………………… Componenta de control acces va identifica utilizatorul la inceputul sesiunii de lucru prin redirectarea catre un ecran de autentificare. Ca si mecansime de autentificare, solutia va suporta minim urmatoarele: ● utilizator si parola ● X.509 Digital certificates ● Windows Native Authentication ● Federated tokens – SAML (Security Assertion Markup Language) ● Autentificare de tip multi-factor prin introducerea unui mecanism secundar de autentificare. ……………………………………………………………………………………………………………………………………………………… Componenta trebuie sa includa o consola web pentru crearea politicilor de acces, aceasta trebuind sa permita definirea granulara de politici de access la nivel de resursa web sau adresa URL. Politicile de acces vor fi definite in mod grafic, fara a necesita cunostinte de programare sau rularea de scripturi de server. ……………………………………………………………………………………………………………………………………………………… De asemenea, mecanismul de caching trebuie sa asigure disponibilitate ridicata printr-o arhitectura de tip cluster activ-activ.” Referitor la aceste cerințe, Consiliul reține că aceasta afirmă următoarele: „Combinația cumulată a acestor cerințe, (…), corespunde arhitecturii funcționale a unui număr restrâns de soluții comerciale consacrate de tip Web Access Management, precum Oracle Access Manager, CA/Broadcom SiteMinder sau IBM Security Access Manager, nivelul de detaliere al mecanismelor interne, mai degrabă decât al rezultatului funcțional urmărit, este el însuși contrar art. 155 alin. (6) din Legea nr. 98/2016”, solicitând fie eliminarea lor, fie reformularea lor „la nivelul funcționalității necesare, cu eliminarea trimiterilor la mecanisme interne de implementare specifice unei categorii restrânse de produse, precum și confirmarea de către autoritatea contractantă a acceptării oricărei soluții tehnic echivalente pentru mecanismul de caching de sesiune.” În replică autoritatea contractantă arată că aceste cerințe sun parte ale componentei obligatorii privind administrarea identității utilizatorilor, fără a descrie un produs comercial specific, reprezentând capabilități standard de arhitectură software specifice platformelor de acest gen și prezintă argumente pentru a demonstra caracterul nefundat al cererilor contestatoarei pe acest aspect. Din analiza susținerilor celor două părți, Consiliul constată, pe de o parte, că autoarea contestației solicită modificarea documentației de atribuire

Pagina 54 din 80 fie prin eliminarea cerințelor amintite, fie prin reformularea lor, fără a dovedi în vreun fel caracterul restrictiv al acestora, inclusiv petenta arătând că există cel puțin două soluții comerciale care le pot îndeplini. Pe de altă parte, Consiliul are în vedere că, la fel ca și în cazul celorlalte cerințe criticate, definirea lor a fost realizată de fiecare dată prin utilizarea sintagmei ”sau echivalent”, în acord cu dispozițiile legale citate anterior, astfel cum rezultă și din răspunsul consolidat nr. 15556/JV/27.08.2026, fiind de datoria ofertanților, în mod evident, să demonstreze echivalența soluțiilor oferrtate. Prin urmare, pentru aceste motive, Consiliul va respinge ca nefondate criticile contestatoarei formulat în această privință. În ceea ce privește criticile contestatoarei de la pct. B.5, Consiliul constată că privește componenta de backup, autoarea contestației susținând că privește un protocol proprietar Veritas, motiv pentru care solicită eliminarea cerinței privind protocolul OST, precum și clarificarea și corelarea cerințelor privind sistemul de gestiune a bazelor de date cu cele privind agenții de backup solicitați. În legătură cu cele solicitate de autoarea contestației, autoritatea contractantă arată că cerința este formulată alternativ, respectiv în mod nativ sau prin protocolul OST, menționarea protocolului OST fiind doar un exemplu de integrare, nu o cerință exclusivă, asupra căreia este aplicabilă clauza prevăzută în caietul de sarcini ”sau echivalent”. De asemenea, precizează că menționarea agenților de backup pentru Microsoft SQL Server și PostgreSQL este fundamentată obiectiv pe sistemele de gestiune a bazelor de date existente în infrastructura sa. În legătură cu aspectul criticat, Consiliul reține că privește cerințele caietului de sarcini, cap. 5.4.15. Componenta de backup, prin care autoritatea contractantă a stabilit următoarele: „Cerinte functionale: • Soluția trebuie să suporte integrarea cu celelalte echipamente de stocare propuse în cadrul acestui proiect, precum și cu cele existente în infrastructura beneficiarului, în mod nativ sau prin protocolul OST (OpenStorage). ………………………………………………………………………………………………………………………………. • Soluția trebuie să ofere posibilitatea de a efectua Bare Metal Restore (functionalitati de restaurare complet automatizate care includ sistemul de operare, configuratia, aplicatiile si datele) pentru Windows și Linux (RHEL, SUSE) fără a necesita integrarea cu soluții terte, instrumente native ale sistemului de operare sau instrumente pentru crearea de imagini. ………………………………………………………………………………………………………………………………. • Soluția trebuie să suporte utilizarea protocolului Network Data Management Protocol (NDMP) pentru a iniția și controla salvarea/restaurarea sistemelor Network Attached Storage (NAS) pentru cel puțin echipamentele propuse în cadrul prezentului proiect, precum și pentru cele existente în infrastructura beneficiarului. ………………………………………………………………………………………………………………………………. • Soluția trebuie să suporte salvari NDMP local și 3-way, functionalitatea Direct Access Recovery (DAR).” Urmare a publicării în SEAP de către autoritatea contractantă a răspunsului consolidat nr. 15556/JV/27.08.2026, autoarea contestației precizează că nu mai insistă asupra protocolului OST, însă își menține critica privind necorelarea dintre agenții de backup enumerați (Microsoft SQL Server, PostgreSQL) și cerința criticată la B.1, susținând că acest aspect nu a făcut obiectul niciunei solicitări de clarificări.

Pagina 55 din 80 În ceea ce privește aspectul rămas în discuție, se constată că autoritatea contractantă a explicat motivele pentru care a menționat agenții de backup Microsoft SQL Server și PostgreSQL (raportat la actualele sisteme de gestiune deținute), astfel că, raportat la simpla afirmație a contestatoarei privind lipsa de coerența a documentației de atribuire, fără a combate explicațiile furnizate de achizitoare pe acest subiect, limitându-se doar la a declara că își menține critica, nu este considerată de Consiliu suficientă pentru a impune autorității contractante realizarea de modificări în această privință. În aprecierea sa, Consiliul a avut în vedere pe lângă lipsa prezentării unor motive temeinice, concrete care să ateste luare de măsuri precum cele solicitate, inclusiv cele precizate de autoritatea contractantă prin răspunsul consolidat nr. 15556/JV/27.08.2026: - Clarificarea nr. 9, pct. 50, pag. 133: „Întrebarea nr. 50 Cap. 5.4.3 - Bază de date native suportate: SQL Server, Oracle, DB2 Se solicită integrare nativă „cu baze de date precum: Microsoft SQL Server, Oracle sau DB2”, fără menționarea explicită a bazelor de date open-source (PostgreSQL, MySQL) utilizate curent de ROMSILVA (Platforma INTRANET folosește MySQL). Vă rugăm să confirmați dacă suportul pentru PostgreSQL/MySQL este acceptat ca echivalent, având în vedere că platformele existente ale ROMSILVA menționate în capitolul 3.6 utilizează MySQL. Răspuns la întrebarea nr. 50: Sunt acceptate și alte soluții SGBD pentru Componenta de gestiune a fluxurilor de lucru, cu condiția obligatorie ca acestea să fie versiuni Enterprise ce beneficiază de suport tehnic comercial, actualizări de securitate și mentenanță asigurate direct de un vendor sau partener autorizat pe bază de abonament ori contract, fiind astfel asimilate software-ului comercial (COTS). Utilizarea versiunilor comunitare libere (Community Edition), neînsoțite de garanții și suport oficial, este exclusă. Prin urmare, Componenta de gestiune a fluxurilor de lucru poate utiliza sau se poate integra nativ cu un SGBD open-source, atâta timp cât acesta este furnizat ca variantă Enterprise acoperită de suport comercial pe întreaga durată a contractului și respectă toate cerințele de performanță, scalabilitate și securitate solicitate prin Caietul de Sarcini.” - Clarificarea nr. 12, pct. 70, pag. 181: „Întrebarea nr. 70: Referitor la Caietul de Sarcini, cap. 5.4.10 – Componenta de mascare a datelor, vă rugăm să confirmați că enumerarea tehnologiilor și formatelor Oracle DB Server, MySQL, Microsoft SQL Server, PostgreSQL, Sybase, XML, SQL, CSV, JSON și HTML reprezintă cerințe privind capabilitățile de suport ale produsului ofertat și nu reprezintă implicit un inventar al tuturor sistemelor/surselor de date care trebuie conectate și licențiate în cadrul proiectului. Totodată, vă rugăm să confirmați că perimetrul operațional al componentei de mascare va include bazele de date și sursele de date utilizate sau integrate în cadrul sistemului implementat prin prezentul proiect. Răspuns la întrebarea nr. 70: Se confirmă. Enumerarea tehnologiilor și formatelor (Oracle DB Server, MySQL, Microsoft SQL Server, PostgreSQL, Sybase, XML, SQL, CSV, JSON, HTML) reprezintă cerințe privind capabilitățile de suport ale produsului ofertat și nu reprezintă un inventar al tuturor sistemelor/surselor de date care trebuie conectate și licențiate în cadrul proiectului. Perimetrul operațional al componentei de mascare include bazele de date și sursele de date utilizate în cadrul sistemului implementat prin prezentul proiect”. Prin urmare, Consiliul ia act de renunțare la criticile privind protocolul OST și respinge ca nefondate critica privind necorelarea dintre agenții de backup. În ceea ce privește criticile contestatoarei de la pct. B6, Consiliul constată că privește componenta integrată de gestiune și analiză a datelor, referitor la care se susține că este redactată pornind de la o soluție

Pagina 56 din 80 predeterminată de tip platformă de data science, compatibilă cu profilul Dataiku DSS. Astfel, Consiliul constată că în discuție sunt următoarele prevederi ale caietului de sarcini, cap. 5.4.4 Componentă integrată de gestiune și analiză a datelor: „(…) Medii integrate de dezvoltare - Componenta oferă un mediu dedicat de dezvoltare pentru limbajul de dezvoltare R care sa permită dezvoltarea tehnicilor statistice, precum modelarea liniara si neliniara, execuția testelor statistice clasice, analize pe serii de timp si/sau clasificări” (…) Componenta integrată de gestiune și analiză a datelor va include capabilități de modelare, antrenare si inferența a modelelor AI ce va asigura cel puțin următoarele funcționalități avansate de analiza si înțelegere a datelor: ………………………………………………………………………………………………………………………………. - Posibilitatea de a integra (ex: prin API, scripturi externe etc.) inclusiv modele de tip generativ (e.g. Llama, Mistral) pentru a susține arii emergente de analiza si fluxuri de business.” Ulterior, ca urmare a publicării în SEAP de către autoritatea contractantă a răspunsului consolidat nr. 15556/JV/27.08.2026, prin adresa nr. 1390/ 08.09.2026, contestatoarea precizează că își menține capătul de cerere cu privire la: „restul combinației cumulate (AutoML pentru toate categoriile solicitate, MLOps, catalog de date, de-duplicare, conectare la modele generative Llama/Mistral), care rămâne confirmată ca obligatorie fără excepție, precum și cu privire la cerința ca, în cazul unei arhitecturi compuse din mai multe produse, acestea să aparțină aceluiași producător, aspect care menține, în opinia subscrisei, orientarea cerinței către profilul unei platforme unice de tip Dataiku DSS”. Or, în legătură cu aceste afirmații ale contestatoarei, Consiliul constată că lipsește, pe de o parte, demonstrarea faptului că cerințele rămase în discuție pot fi asigurate în totalitatea doar de către platforma Dataiku DSS, iar pe de altă parte, demonstrarea modului în care îi este afectată participarea la procedura de atribuire, în condițiile în care sarcina probei îi revenea acesteia în calitate de reclamant. Prin urmare, Consiliul constatând lipsa de temei a susținerile contestatoarei pe acest aspect, va respinge ca nefondată solicitarea contestatoarei de eliminare/reformulare a cerințelor de la cap. 5.44. criticate. În ceea ce privește următoarea critică, respectiv cea de la pct. B.7, Consiliul reține că urmare a remedierilor luate de autoritatea contractantă prin intermediul răspunsului consolidat nr. 15556/JV/27.08.2026, Clarificarea nr. 1, pct. 87, pag. 38, autoarea contestației nu o mai susține, astfel că va lua act de renunțarea la aceasta. În ceea ce privește critica de la pct. B.8, Consiliul reține că se referă la componenta de optimizare automată a resurselor, autoarea contestației susținând că pornește de la o soluție predeterminată, compatibilă cu profilul IBM Turbonomic, și este parțial incoerentă cu infrastructura fixă de implementare. Astfel, Consiliul constată că este criticată cerința caietului de sarcini, cap. 5.4.14 Componentă inteligentă de optimizare automată a resurselor, prin care autoritatea contractantă a stabilit următoarele: „● Infrastructură de virtualizare suportată : Azure, Kubernetes, OpenShift;” În legătură cu această cerință, contestatoare afirmă că indicarea exact doar a 3 platforme, corespunde profilului tehnic documentat al platformei IBM Turbonomic, respectiv că lipsa menționării platformelor tradiționale de

Pagina 57 din 80 virtualizare (VMwarw sau Hyper-V), impun, în opinia sa, fie eliminarea, fie reformularea cerinței de la cap. 5.4.14 la nivel de funcționalitate necesară, cu eliminarea trimiterii la o listă închisă de platforme corespunzătoare unui produs anume. În replică, autoritatea contractantă arată că solicitarea criticată a fost formulată cu luarea în considerare a faptului că mediul de implementare este infrastructura de găzduire a sistemului Cloud-ului Privat Guvernamental, exemplifică soluțiile alternative existente pe piață și argumente pentru care consideră că cererile contestatoarei în privința cerinței criticate ar trebui respinse. În legătură cu cele invocate de către petentă, Consiliul ar în vedere relevanța celor arătate de autoritatea contractantă prin răspunsul consolidat nr. 15556/JV/27.08.2026, Clarificarea nr. 5, pct. 8, pag. 74-75, și anume: „Întrebarea nr. 8 Referință: Caietul de sarcini, cap. 5.4.14 – Componentă inteligentă de optimizare automată a resurselor, pagina 125. „Simulări avansate de tip 'what-if' pentru planificarea capacității, permițând analiza scenariilor și optimizarea proactivă a resurselor în funcție de diferite ipoteze de creștere.” Referință: Caietul de sarcini, cap. 5.4.14 – Componentă inteligentă de optimizare automată a resurselor, pagina 125. „Migrare inteligentă și automatizată a încărcărilor între furnizorii de Cloud [...] optimizând costurile și performanța prin redistribuirea dinamică a sarcinilor [...].” Referință: Caietul de sarcini, cap. 5.4.14 – Componentă inteligentă de optimizare automată a resurselor, pagina 125. „Executare automată și inteligentă a acțiunilor de optimizare [...] fără intervenție manuală.” Referință: Caietul de sarcini, cap. 5.4.14 – Componentă inteligentă de optimizare automată a resurselor, pagina 126. „Sistem inteligent de recomandări pentru optimizarea costurilor cloud [...] sugerând cea mai eficientă combinație de instanțe rezervate și plan de reducere costuri pentru maximizarea economiilor.” Cerințele de mai sus indică în mod clar produsul IBM Turbonomic. Combinația dintre simulările de capacitate de tip «what-if», planificarea migrării sarcinilor între platforme cloud, executarea automată a acțiunilor de optimizare și recomandarea instanțelor rezervate și a planurilor de economisire este documentată de IBM pentru acest produs. Documentație oficială IBM: https://www.ibm.com/docs/en/tarm/8.19.6?topic=reference- plans-looking-future;

https://www.ibm.com/docs/en/tarm/8.17.x?topic=types-migrate- cloud-plan; https://www.ibm.com/docs/en/tarm/8.20.2?topic=actions-action-acceptance- modes; https://www.ibm.com/docs/en/tarm/8.18.x?topic=types-discount-coverage-chart Vă rugăm să confirmați acceptarea, ca echivalentă, a oricărei soluții care asigură: simularea necesarului de capacitate; planificarea migrării sarcinilor între platforme cloud; recomandări de optimizare a costurilor și performanței; recomandarea resurselor rezervate și a planurilor de economisire; executarea automată sau supusă aprobării a acțiunilor de optimizare. Vă rugăm să confirmați că modul supus aprobării este echivalent cu executarea fără intervenție manuală, atunci când acțiunea aprobată este executată automat. Răspuns la întrebarea nr. 8: Cerințele tehnice din Caietul de Sarcini reprezintă capabilități funcționale și de performanță minimale obligatorii și nu se referă la o anumită soluție. Specificațiile privind simulările de tip „what-if”, planificarea capacității, recomandările de optimizare a costurilor și performanței, gestionarea resurselor rezervate și executarea acțiunilor de optimizare reprezintă standarde din industria software pentru platformele enterprise de optimizare a resurselor, nefiind proprietare unei singure suite comerciale. Este admisă ofertarea unei stive/suite formate din mai multe produse software COTS aparținând aceluiași producător, cu condiția ca acestea să acopere integral cerințele caietului de sarcini și să poată fi instalate/desfășurate pe infrastructura virtuală alocată în Cloudul Privat Guvernamental (CPG).

Pagina 58 din 80 Produsele din cadrul suitei ofertate trebuie să comunice nativ prin conectori standard, API-uri și protocoale optimizate furnizate direct de producător, fără a necesita dezvoltări de cod personalizat (custom code) pentru integrarea funcționalităților. În privința executării acțiunilor de optimizare, produsul software ofertat trebuie să dețină nativ capacitatea tehnică de a executa automat ajustările de resurse. Cu toate acestea, în implementarea efectivă din Cloudul Privat Guvernamental (CPG), acordarea acestor drepturi de execuție va fi guvernată de politicile de securitate și de administrare ale operatorului CPG, soluția urmând să funcționeze într-un regim hibrid (execuție automată controlată și/sau regim de recomandare/aprobare). Sarcina probei privind integrarea funcțională revine ofertantului. Acesta va demonstra în Propunerea Tehnică, pe baza documentației tehnice oficiale a producătorului, modul în care suita de produse propusă satisface fiecare cerință din Caietul de Sarcini.” Astfel, se constată că autoritatea contractantă a arătat faptul că cerința descrie capabilități funcționale și de performanță, nefiind proprietare ale unei singure suite comerciale, putând fi ofertate stive/suite formate din mai multe produse COTS aparținând același producător care asigură îndeplinirea tuturor cerințelor. De asemenea, Consiliul are în vedere că potrivit acestui răspuns rezultă că lista privind infrastructura suportată (Azure, Kubernetes, OpenShift) se referă la lista mediului de destinație, respectiv Cloud-ul Privat Guvernamental, Justificând astfel și presupusa omisiune a platformelor tradiționale de virtualizare invocate de către petentă. Prin urmare, în condițiile în care autoarea contestației nu a prezentat argumente și dovezi din care să rezulte modul în care îi este afectată participarea la procedura de atribuire, respectiv că cerința poate fi îndeplinită doar de un singur produs, respectiv IBM Turbonomic, Consiliul va respinge ca nefondate criticile contestatoarei formulate în legătură cu acest aspect. În ceea ce privește critica de la pct. B.9, Consiliul constată că privește componenta SIEM, referitor la care contestatoarea susține că pornește de la o soluție predeterminată, compatibilă cu profilul IBM QRadar. Astfel, Consiliul constată că autoarea contestației critică prevederile caietului de sarcini de la cap. 5.4.12. Componenta SIEM (”Componenta pentru Managementul Incidentelor de Securitate”), și în acest caz, ca și în precedent, susținând că formulările utilizate de achizitoare corespund arhitecturii și terminologiei folosite public de IBM, dar alt produs, respectiv QRadar SIEM. Ca și în precedent, Consiliul constată că autoarea contestației nu demonstrează că termenii utilizați de achizitoare sunt proprietari IBM și produsului invocat și nici imposibilitatea participării la prezenta procedură reprezentată de imposibilitatea depunerii ofertei. Prin urmare, pentru identitate de raționament, criticile contestatoarei vor fi respinse ca nefondate, constatând lipsa argumentelor/dovezilor care să demonstreze caracterul restrictiv al cerinței, modul în care este afectată concurența și că singurul produs care poate asigura îndeplinirea ei este produsul nominalizat de către aceasta, respectiv lipsa argumentelor privind posibilitatea depunerii unei oferte prin utilizarea sintagmei ”sau echivalent” în analizarea cerințelor. În stabilirea acestui rezultat, Consiliul a avut în vedere inclusiv clarificările aduse prin răspunsul consolidat nr. 15556/JV/27.08.2026, evocate de achizitoare prin adresa nr. 16706/JV/15.09.2026, aspecte cunoscute către contestatoare, dar neinfirmate de aceasta.

Pagina 59 din 80 În baza aceluiași raționament de mai sus vor fi respinse ca nefondate de către Consiliu și criticile formulate de contestatoare la pct. B.10, privind cerințele caietului de sarcini, cap. 5.4.6. Componenta de analiză si raportare avansata a datelor, referitoare la numărul de utilizatori și modul de licențiere al acestora. În ceea ce privește critica de la pct. B.11, Consiliul are în vedere că se referă la structura Formularului 1A - PROPUNERE FINANCIARĂ DETALIATĂ și Formularul F2B matrice de conformitate tehnică.. Consiliul constată că, în fapt, autoarea contestației nu critică conținutul acestui formular, ci doar formulează speculații cu privire la modul în care a fost întocmită documentația de atribuire, susținând că structura acestuia confirmă că: „documentația de atribuire a fost gândită pornind de la 15 produse comerciale distincte, deja identificate implicit prin nivelul de detaliu tehnic al cerințelor din caietul de sarcini analizate la pct. B.1-B.10, și nu de la o arhitectură funcțională neutră tehnologic care ar permite ofertarea unor soluții combinate, open-source sau dezvoltate la comandă pentru unele dintre componente”. Referitor la solicitarea contestatoarei de obligare a autorității contractante la confirmarea expresă a faptului că nu vor fi respinse ofertele care oferă o soluție integrată pe mai multe dintre cele cincisprezece componente nu va fi respinsă ca neconformă pentru simplul motiv al structurii Formularului F1A și F2B, Consiliul are în vedere cele precizate de autoritatea contractantă prin răspunsul consolidat nr. 15556/JV/27.08.2026, Clarificarea nr. 5, pct. 15, pag. 79, și anume: „Întrebarea nr. 15 Referință: Formularul F1A, foaia «F1A», pozițiile 1.1–1.15. F1A: pentru fiecare componentă software, coloanele indică „UM – licență” și „Cantitate – 1”. Referință: Caietul de sarcini, cap. 13.3, paginile 189–190. Caietul de sarcini: „Se va specifica în clar numele licenței de la producător, ediția, producătorul, cantitatea și unitățile de licențiere specifice producătorului precum «User» sau «Processor Core» [...].” Referință: Caietul de sarcini, cap. 17, pagina 202. „Soluția trebuie să se bazeze pe licențe perpetue/subscripții de tip COTS [...] sau sub formă de subscripție valabilă [...] pentru perioada de implementare a contractului și pentru întreaga perioadă de garanție.” Valoarea „1” poate însemna un pachet funcțional complet sau o singură unitate de licențiere. În același timp, documentația admite atât drepturi perpetue, cât și subscripții, fără o matrice minimă pe medii, utilizatori, core-uri, capacitate și durată. Vă rugăm să confirmați că „1 licență” din F1A reprezintă pachetul complet necesar componentei, iar ofertantul va detalia toate produsele/SKU-urile, cantitățile și metricele incluse. Vă rugăm să publicați matricea minimă de licențiere pe medii, durată și metrică și să precizați pentru fiecare componentă dacă se solicită licență perpetuă sau subscripție, inclusiv pentru întreaga perioadă de garanție. Răspuns la întrebarea nr. 15: Se confirmă faptul că valoarea „1” (UM: licență) din Formularul F1A reprezintă pachetul complet de licențiere necesar pentru asigurarea tuturor funcționalităților, capacităților și volumetriilor solicitate prin Caietul de Sarcini pentru componenta respectivă, acoperind mediile de producție, dezvoltare/testare și Disaster Recovery, după caz. În Propunerea Tehnică (Formularul F2B și anexele tehnice), ofertanții au obligația de a detalia structura exactă a pachetului comercial propus, specificând denumirea produselor, producătorul, codurile de identificare (SKU), metrica specifică de licențiere (ex. Per Core, Per User, Per Instance, Per Managed Node etc.) și cantitățile aferente fiecărei componente. În privința tipului de licențiere și a duratei de valabilitate: • Sunt acceptate atât licențe de tip perpetue, cât și subscripții (COTS / abonamente).

Pagina 60 din 80 • În cazul licențelor pe bază de subscripție, prețul ofertei financiare trebuie să acopere valabilitatea acestora pentru întreaga perioadă de implementare a contractului, la care se adaugă întreaga perioadă de garanție prevăzută în documentația de atribuire, fără a genera costuri ulterioare pentru Autoritatea Contractantă. • Indiferent de modelul de licențiere ales, dreptul de utilizare și suportul tehnic aferent trebuie să fie asigurate neîntrerupt pe toată durata contractului și a garanției. Dimensionarea minimă a licențelor pe medii, utilizatori sau capacități derivă din cerințele specifice stabilite la nivelul fiecărei componente din Caietul de Sarcini, corelate și cu cerințele minimale din tabelul din secțiunea 5.3.1 din caietul de sarcini”, Precum și cele precizate prin Clarificare 15, pct. 1, pag. 214-215, din același răspuns consolidat, respectiv: „Întrebarea nr. 1: Principiul echivalenței pentru toate componentele COTS Prevederea vizată: Caietul de sarcini, cap. 5.4, Componentele software, integral; art. 155-156 din Legea nr. 98/2016 Solicitare: Numeroase cerințe din capitolul 5.4 al Caietului de sarcini sunt formulate prin trimitere la mecanisme interne, denumiri de funcționalități și metrici proprii unor produse comerciale determinate, fără mențiunea „sau echivalent”. Vă rugăm să confirmați, cu titlu de regulă generală aplicabilă întregului capitol 5.4, că: (i) toate specificațiile tehnice se citesc însoțite de mențiunea „sau echivalent”, în conformitate cu art. 156 alin. (8) din Legea nr. 98/2016; (ii) îndeplinirea unei cerințe se apreciază prin raportare la REZULTATUL funcțional obținut, iar nu la mecanismul tehnic intern prin care acesta este obținut; (iii) sunt acceptate soluții compuse din produse ale mai multor producători, integrate de ofertant, precum și soluții bazate pe tehnologii open-source în ediție enterprise, cu suport comercial contractat de ofertant, atât timp cât parametrii funcționali și de performanță solicitați sunt îndepliniți sau depășiți. Răspuns la întrebarea nr. 1: Caietul de sarcini prevede deja mențiunea „sau echivalent” acolo unde sunt menționate produse de o anumită origine, sursă, producție, un procedeu special, o marcă de fabrică sau de comerț, un brevet de invenție sau o licență de fabricație. Cerințele componentelor software de la cap. 5.4 pot fi îndeplinite, pentru fiecare componentă în parte, printr-o arhitectură integrată compusă din mai multe produse COTS aparținând aceluiași producător, cu condiția ca acestea să comunice nativ prin conectori standard, API-uri și protocoale optimizate furnizate direct de producător, fără a necesita dezvoltări de cod personalizat (custom code) și să acopere integral toate cerințele din caietul de sarcini. Sunt acceptate, de asemenea, componente COTS de la mai mulți producători în cadrul aceleiași componente, cu condiția ca soluția să fie certificată de producătorul principal în ceea ce privește suportul și integrarea. Această abordare este justificată de necesitatea asigurării unei integrări native, stabile și suportate oficial pe întreaga durată a contractului, eliminând riscurile de incompatibilitate, de dependență de dezvoltări personalizate și de fragmentare a responsabilității de suport tehnic. Sarcina probei privind îndeplinirea condițiilor revine ofertantului, care va demonstra în Propunerea Tehnică, pe baza documentației oficiale a producătorului, modul în care soluția propusă satisface cerințele.”, Aspecte cunoscute contestatoarei, fără infirmarea relevanței lor. Prin urmare, Consiliul va respinge ca nefondate criticile contestatoarei privind acest aspect. În ceea ce privește ultima dintre criticile formulat în cadrul acestui set de critici, respectiv cea de la pct. B12, Consiliul constată că privește impunerea de către autoritatea contractantă a utilizării de către ofertanții în cadrul soluției ofertate doar a produselor comerciale de tip COTS, contestatoarea susținând că este restrânsă nejustificat concurența și contravine direcțiilor de politică ale Uniunii Europene în materie de software open source. În acest sens, autoarea contestației invocă politica Uniunii Europene în materie de software open source în sectorul public (Regulamentul (UE)

Pagina 61 din 80 2024/903 al Parlamentului European și al Consiliului din 13 martie 2024 de stabilire a unor măsuri pentru un nivel ridicat de interoperabilitate a sectorului public în întreaga Uniune (Interoperable Europe Act)), strategia Comisiei Europene privind software-ul open source și pachetul de suveranitate tehnologică etc, aducând argumente referitor la caracterul incorect/nerelevant al justificărilor prezentate de achizitoare pentru impunerea doar a produselor comerciale de tip COTS, motiv pentru care solicită: „(…) constatarea caracterului nelegal și disproporționat al cerinței privind excluderea software-ului open source de la cap. 5.3. Arhitectura tehnică a sistemului, din Caietul de sarcini, precum și a tuturor celorlalte cerințe din caietul de sarcini care impun ofertarea exclusivă de soluții de tip COTS, cu excluderea soluțiilor de tip open source, și obligarea autorității contractante la eliminarea acestei cerințe, precum și a tuturor celorlalte cerințe din cadrul caietului de sarcini care fac referire la ofertarea exclusivă și restrictivă de componente COTS, sau la reformularea cerințelor astfel încât să permită ofertarea unor soluții open source susținute contractual, echivalente din punct de vedere funcțional, al costului total și al securității cibernetice, potrivit criteriilor obiective la care face referire Regulamentul (UE) 2024/903, temei legal art. 2 alin. (2) lit. e) și f), art. 155 alin. (6) și art. 156 alin. (2)-(3) din Legea nr. 98/2016.” În replică, autoritatea contractantă arată că impunerea ofertării doar de soluții realizate în baza unor produse COTS are la bază rațiuni privind sensibilitatea datelor prelucrate, nivelul de securitate impus de legislația națională și de reglementările DNSC/CPG, asigurarea suportului tehnic pe întreaga perioadă de implementare și de garanție, invocă avizul pozitiv Comitetul Tehnico-Economic pentru Societatea Informațională nr. 412CTE/18.06.2026. În soluționare, Consiliul reține relevanța celor precizate de autoarea contestației prin adresa nr. 1390/08.09.2026, în legătură cu acest aspect, și anume: „Acest capăt de cerere a fost remediat parțial, nu integral. La întrebarea explicită privind excluderea soluțiilor open source, autoritatea contractantă a răspuns: „Soluțiile de tip open- source în versiuni Enterprise, care beneficiază de suport tehnic comercial, actualizări de securitate și mentenanță asigurate direct de un vendor pe bază de abonament sau contract, sunt acceptate și sunt considerate conforme cu cerința de furnizare a software-ului comercial (COTS). Scopul acestei cerințe este excluderea utilizării versiunilor comunitare libere (Community Edition) ce nu beneficiază de garanții, servicii de suport sau actualizări oficiale.” – întrebarea nr. 20 din Clarificarea nr. 9, pag. 122-123. Această poziție este reluată identic în cel puțin alte două răspunsuri ulterioare din același document: întrebarea nr. 50 din Clarificarea nr. 9, pag. 133, întrebarea nr. 22.1 din Clarificarea nr. 14, pag. 204-205. Această clarificare înlătură premisa de fapt a celei mai mari părți a criticii formulate la B.12: excluderea nu mai vizează, potrivit clarificării oficiale, orice soluție open source, ci exclusiv versiunile comunitare fără suport comercial, o distincție rezonabilă și frecvent întâlnită în achizițiile publice. Menținem însă, cu titlu subsidiar, observația că motivarea inițială a cerinței, aceea că open source-ul ar prezenta, în sine, un risc de securitate, rămâne, în continuare, în contradicție cu poziția oficială a Regulamentului (UE) 2024/903 invocată în contestație care nu face distincție între open source-ul cu suport de tip community și cel cu suport de tip enterprise.” Referitor la observația petentei din finalul acestui punct de vedere, Consiliul are în vedere cele precizate de autoritatea contractantă prin adresa nr. 16706/JV/15.09.2026, necombătute de contestatoare, deși i-au fost aduse la cunoștință referitor la faptul că Regulamentului (UE) 2024/903 nu-i interzice solicitarea de suport comercial și actualizări oficiale pentru componenta pe care o pune în producție.

Pagina 62 din 80 Prin urmare, pentru aceste motive, Consiliul va respinge critica formulată de contestatoare ca nefondată, clarificările aduse de autoritatea contractantă pe acest aspect fiind considerate edificatoare. În ceea ce privește criticile următoare, respectiv cele de la pct. C, Consiliul constată că privesc factorii de evaluare Pt2, Pt3 și Pt4, contestatoarea susținând că nu permit o diferențiere reală și proporțională a ofertelor, iar factorii Pt3 și Pt4 nu delimitează cerințele minime obligatorii de avantajele calitative suplimentare punctate, solicitând următoarele: „fie eliminarea factorilor Pt2, Pt3 și Pt4 în forma actuală, fie reformularea grilei de punctaj și a algoritmilor aferenți, prin delimitarea expresă, în cazul Pt3 și Pt4, a cerințelor minime obligatorii de elementele calitative suplimentare care aduc un avantaj real autorității contractante și justifică acordarea punctajului, precum și prin stabilirea, pentru Pt2, Pt3 și Pt4, a unor repere clare, obiective și verificabile pentru diferențierea nivelurilor de punctaj, inclusiv, după caz, prin introducerea unor praguri intermediare ori subcriterii care să permită reflectarea proporțională a avantajelor oferite, în acord cu prevederile art. 32 alin. (2) din HG nr. 395/2016.” În replică, autoritatea contractantă susține că a stabilit factorii de evaluare și algoritmii de acordare a punctajelor aferenți prin raportare la Catalogul ANAP privind factorii de evaluare ce pot fi incluși în criteriul „cel mai bun raport calitate preț” și prezintă argumente care, în opinia sa sunt de natură a demonstra legalitatea stabilirii acestor factorii și a modului de acordare a punctajului. Astfel, Consiliul are în vedere în soluționare criteriile stabilite de autoritatea contractantă în acordarea punctajului pentru acești factori de evaluare, și anume: - factorul de evaluare Pt2 – Abordarea și metodologia, cu o pondere de 15%, descris astfel: „Comisia de evaluare va analiza conținutul Propunerii tehnice și va evalua calitatea Abordării și metodologiei propuse pentru implementarea contractului conform grilei de punctaj detaliate in caietul de sarcini. Fiecare membru al comisiei de evaluare va acorda independent punctaj. Apoi se va realiza media aritmetică/criteriu pentru punctajele acordate de toți membrii comisiei”. având următorul algoritm de calcul: „1) Ofertantul prezintă o înțelegere de bază a contextului și obiectivelor contractului și propune o abordare generală pentru realizarea serviciilor (detaliere algoritm si analiza in caietul de sarcini). – se acorda 0 puncte 2) Ofertantul prezintă o înțelegere bună, solidă a contextului și obiectivelor contractului și propune o abordare adaptată pentru realizarea serviciilor (detaliere algoritm si analiza in caietul de sarcini). - se acorda 10 puncte. 3) Ofertantul demonstrează o înțelegere completă și profundă a dimensiunilor contractului și propune o abordare foarte adaptată prin raportare la cerințele specifice din caietul de sarcini (detaliere algoritm si analiza in caietul de sarcini). - se acorda 15 puncte.” - factorul de evaluare Pt3 – Planul de lucru, cu o pondere de 15%, descris astfel: „Comisia de evaluare va analiza conținutul Propunerii tehnice și va evalua calitatea Planului de lucru conform grilei de punctaj detaliate in caietul de sarcini. Fiecare membru al comisiei de evaluare va acorda independent punctaj. Apoi se va realiza media aritmetică/criteriu pentru punctajele acordate de toți membrii comisiei”. având următorul algoritm de calcul: „Comisia de evaluare va analiza conținutul Propunerii tehnice și va evalua calitatea Planului de lucru conform grilei de punctaj detaliate in caietul de sarcini. Fiecare membru al comisiei de evaluare va acorda independent punctaj. Apoi se va realiza media aritmetică/criteriu pentru punctajele acordate de toți membrii comisiei.

Pagina 63 din 80 1) Structura WBS (structura detaliată de defalcare a serviciilor / activităților: WBS - Work Breakdown Structure) este prezentată, însă mai multe elemente din aria de cuprindere sunt omise sau tratate necorespunzător. Pot fi identificate mai multe contradicții și neclarități.Planul de lucru prezintă faze și etape, defalcate în activități principale și sub- activități, dar nivelul de detaliere este insuficient.... (detaliere algoritm si analiza in caietul de sarcini). - se acorda 0 puncte 2) Structura WBS este completă și acoperă întreaga arie de cuprindere a contractului. Elementele sunt prezentate coerent și fără contradicții semnificative. Planul de lucru demonstrează o aliniere clară cu cerințele caietului de sarcini precum și cu abordarea și metodologia propuse. ... (detaliere algoritm si analiza in caietul de sarcini). - se acorda 10 puncte 3) Structura WBS demonstrează excelență în organizarea ierarhică, cu o defalcare optimă care facilitează atât monitorizarea detaliată cât și raportarea executivă. Toate elementele sunt foarte bine integrate și corelate, fără neclarități majore sau contradicții. Planul de lucru demonstrează alinierea foarte bună cu cerințele caietului de sarcini și cu abordarea și metodologia propuse. ... (detaliere algoritm si analiza in caietul de sarcini). - se acorda 15 puncte.” - factorul de evaluare Pt4 – Grafic de prestare, cu o pondere de 15%, descris astfel: „Comisia de evaluare va analiza conținutul Propunerii tehnice și va evalua calitatea Abordării și metodologiei propuse pentru implementarea contractului conform grilei de punctaj detaliate in caietul de sarcini. Fiecare membru al comisiei de evaluare va acorda independent punctaj. Apoi se va realiza media aritmetică/criteriu pentru punctajele acordate de toți membrii comisiei”. având următorul algoritm de calcul: „Comisia de evaluare va analiza conținutul Propunerii tehnice și va evalua calitatea Graficului de prestare conform grilei de punctaj detaliate in caietul de sarcini. Fiecare membru al comisiei de evaluare va acorda independent punctaj. Apoi se va realiza media aritmetică/criteriu pentru punctajele acordate de toți membrii comisiei. 1) Graficul de prestare este realizat cu un software de management de proiect și prezintă planificarea temporală a activităților și sub-activităților într-o reprezentare GANTT corelată în linii mari cu WBS-ul, dar nivelul de detaliere este minimal. Graficul demonstrează capacitate elementară de replanificare și nivelare a resurselor.. (detaliere algoritm si analiza in caietul de sarcini).(cerința minimă) - se acorda 0 puncte 2) Graficul demonstrează utilizarea competentă a unui software profesional de management de proiect, cu o reprezentare GANTT buna a activităților și sub-activităților conform structurii WBS. Nivelul de detaliere este adecvat pentru monitorizarea eficientă a progresului. Graficul demonstrează capacitate bună de replanificare cu recalcularea drumului critic și permite nivelarea manuală sau semi-automată a resurselor. (detaliere algoritm si analiza in caietul de sarcini)- se acorda 10 puncte 3) Graficul demonstrează excelență în planificare folosind capabilitățile avansate ale unui software profesional de management de proiect cu o reprezentare GANTT foarte bună a activităților și sub-activităților conform structurii WBS. Sunt utilizate consistent codurile WBS, iar nivelul de detaliere prezentat permite monitorizarea eficientă a progresului, evitând însă micro-managementul. Graficul demonstrează capacitate foarte bună de replanificare dinamică cu recalcularea drumului critic și permite nivelarea manuală sau semi-automată a resurselor. (detaliere algoritm si analiza in caietul de sarcini)- se acorda 15 puncte.” În legătură cu primul dintre factorii de evaluare contestați, respectiv Pt2 – Abordarea și metodologia, Consiliul are în vedere că autoritatea contractantă a prevăzut în caietul de sarcini următoarea detaliere: - pentru un punctaj de ”0” puncte:

Pagina 64 din 80 „Ofertantul prezintă o înțelegere de bază a contextului și obiectivelor contractului și propune o abordare generală pentru realizarea serviciilor. Metodologia propusă are la bază metodologii, metode sau instrumente recunoscute în domeniu, dar reprezintă mai degrabă o descriere generică a modului de lucru. Multe pasaje ar putea fi aplicate oricărui proiect și nu sunt adaptate prin raportare la cerințele specifice ale proiectului de față. Aspectele-cheie specifice contractului sunt identificate și tratate la nivel formal, dar corelația dintre metodologia propusă și modul de adresare a aspectelor-cheie este demonstrată parțial convingător. Analiza riscurilor suplimentare există, dar este generică sau expeditivă, iar ipotezele de lucru sunt explicitate sumar. Managementul calității este menționat, însă majoritatea aspectelor sunt teoretice, fără măsuri concrete adaptate specificului proiectului. Analiza cadrului legal se limitează la prevederile menționate în caietul de sarcini. (cerința minimă)” - pentru un punctaj de 10 puncte: „Ofertantul prezintă o înțelegere bună, solidă a contextului și obiectivelor contractului și propune o abordare adaptată pentru realizarea serviciilor. Metodologia propusă are la bază metodologii, metode sau instrumente recunoscute în domeniu. Pentru majoritatea componentelor metodologice propuse sunt prezentate referințe la standarde, bune practici sau metodologii consacrate, cu explicarea modului de aplicare în contextul specific al proiectului și beneficiile pe care le aduc. Cerințele specifice din caietul de sarcini sunt identificate și abordate prin soluții concrete. Aspectele-cheie pentru succesul contractului sunt identificate corect și există o corelație bună între metodologia propusă și modul de adresare a aspectelor-cheie, deși unele aspecte sunt tratate la nivel general. Ipotezele de lucru sunt explicitate și justificate. Analiza riscurilor suplimentare acoperă principalele categorii de risc (tehnic, organizațional, resurse) cu strategii de răspuns specifice, bine corelate cu cerințele caietului de sarcini. Managementul calității este prezentat prin măsuri concrete adaptate specificului proiectului. Analiza cadrului legal include câteva prevederi relevante suplimentare față de cele indicate în caietul de sarcini.” - pentru un punctaj de 15 puncte: „Ofertantul demonstrează o înțelegere completă și profundă a dimensiunilor contractului și propune o abordare foarte adaptată prin raportare la cerințele specifice din caietul de sarcini. Metodologia propusă are la bază metodologii, metode sau instrumente testate și recunoscute în domeniu. Pentru toate componentele metodologice sunt prezentate referințe la standarde internaționale, certificări profesionale sau metodologii consacrate, cu adaptări specifice și inovative la contextul contractului. Pentru fiecare instrument și proces propus este justificată alegerea și explicat în detaliu modul de aplicare, precum și beneficiile pentru autoritatea contractantă. Cerințele specifice din caietul de sarcini sunt identificate și abordate prin soluții concrete, fiind propuse elemente inovative sau optimizări demonstrabile față de abordările standard. Aspectele-cheie pentru succesul contractului sunt identificate exhaustiv și există o corelație foarte bună între metodologia propusă și modul de adresare a aspectelor-cheie. Ipotezele sunt validate prin date concrete sau analize comparative prin raportare la proiecte anterioare implementate cu succes. Analiza riscurilor suplimentare este foarte bine abordată, incluzând evaluarea probabilitate/impact, strategii diferențiate de răspuns și planuri de contingență detaliate, foarte bine corelate cu cerințele caietului de sarcini. Managementul calității este detaliat cu măsuri concrete, puncte de control și metrici specifice adaptate proiectului. Sunt prezentate mecanisme concrete de îmbunătățire continuă, adaptate la specificul contractului. Sunt propuși indicatori de performanță suplimentari față de cei din caietul de sarcini, cu valori țintă și metode de măsurare. Analiza cadrului legal este foarte bine realizată, identificând prevederi relevante suplimentare substanțiale și demonstrând modalitatea de asigurare a conformității.”

Pagina 65 din 80 Față de problematica dedusă judecății, Consiliul reține relevanța următoarelor dispoziții ale Legii nr. 98/2016: - art. 187 „(3) Pentru determinarea ofertei celei mai avantajoase din punct de vedere economic în conformitate cu dispozițiile alin. (2), autoritatea contractantă are dreptul de a aplica unul dintre următoarele criterii de atribuire: a) cel mai bun raport calitate-preț (...)” (4) În sensul alin. (3) lit. a) şi b), cel mai bun raport calitate-preţ/calitate-cost se determină pe baza unor factori de evaluare care includ aspecte calitative, de mediu şi/sau sociale în legătură cu obiectul contractului de achiziţie publică/acordului-cadru (5) Factorii de evaluare prevăzuţi la alin. (4) pot viza, printre altele: a) calitatea, inclusiv avantajele tehnice, caracteristicile estetice şi funcţionale, accesibilitatea, conceptul de proiectare pentru toţi utilizatorii, caracteristicile sociale, de mediu şi inovatoare şi comercializarea şi condiţiile acesteia; b) organizarea, calificarea şi experienţa personalului desemnat pentru executarea contractului, în cazul în care calitatea personalului desemnat poate să aibă un impact semnificativ asupra nivelului calitativ de executare a contractului; c) serviciile postvânzare, asistenţa tehnică şi condiţiile de livrare, cum ar fi data livrării, procesul de livrare şi termenul de livrare sau de finalizare. d) ofertantul are la nivel de unitate contract colectiv de muncă încheiat cu o organizaţie sindicală sau îi este aplicabil un contract colectiv de muncă la nivel de sector de negociere colectivă. ”. - art. 188: „(1) Factorii de evaluare prevăzuţi la art. 187 alin. (4) au legătură directă cu obiectul contractului de achiziţie publică/acordului-cadru atunci când se referă în orice mod la produsele, serviciile sau lucrările care urmează a fi furnizate/prestate/executate în temeiul contractului de achiziţie publică/acordului-cadru şi în orice stadiu al ciclului lor de viaţă, chiar dacă aceşti factori nu fac parte din substanţa materială a produselor, serviciilor sau lucrărilor respective. (2) În sensul dispoziţiilor alin. (1), autoritatea contractantă poate avea în vedere factori de evaluare în legătură cu: a) procesul specific de producţie, furnizare sau comercializare a lucrărilor, produselor sau serviciilor; b) un proces specific pentru un alt stadiu al ciclului de viaţă a lucrărilor, produselor sau serviciilor. (3) În sensul dispoziţiilor alin. (1), pentru categoriile de contracte de achiziţie publică/acorduri-cadru prevăzute la art. 187 alin. (8) lit. c), autoritatea contractantă va avea în vedere cel puţin factori de evaluare în legătură cu: a) contribuţia procesului de fabricaţie la protecţia mediului; b) lanţul de aprovizionare - canale scurte de aprovizionare; c) cea mai scurtă distanţă de la locul de producţie la locul de consum”. Relevante soluționării cauzei sunt și dispozițiile art. 9 din HG nr. 395/2016, care stipulează următoarele: (1) Etapa de planificare/pregătire a unui proces de achiziţie publică se iniţiază prin identificarea necesităţilor şi elaborarea referatelor de necesitate şi se încheie cu aprobarea de către conducătorul autorităţii contractante/unităţii de achiziţii centralizate a documentaţiei de atribuire, inclusiv a documentelor-suport, precum şi a strategiei de contractare pentru procedura respectivă. (2) Strategia de contractare este un document al fiecărei proceduri de achiziţie publică cu o valoare estimată egală sau mai mare decât pragurile valorice stabilite la art. 7 alin. (5) din Lege, iniţiată de autoritatea contractantă. (3) Prin intermediul strategiei de contractare se documentează deciziile din etapa de planificare/pregătire a achiziţiei în legătură cu: (...) f) justificările privind alegerea procedurii de atribuire în situaţiile prevăzute la art. 69 alin. (2) - (5) din Lege şi, după caz, decizia de a reduce termenele în condiţiile legii, decizia de a nu utiliza împărţirea pe loturi, criteriile de calificare privind capacitatea şi, după caz, criteriile de selecţie, criteriul de atribuire şi factorii de evaluare utilizaţi; (...)”, precum și cele ale art. 32 alin. (2) și (8) din HG nr. 395/2016, prin care legiuitorul stabilește că: „(2) Factorii de evaluare a ofertelor, precum şi algoritmul de punctare prevăzut la alin. (1) se precizează în mod clar şi detaliat în cadrul documentaţiei de atribuire şi vor reflecta metodologia de punctare a avantajelor care vor rezulta din propunerile tehnice şi financiare prezentate de ofertanţi şi trebuie să aducă un avantaj real, să nu fie formali şi să poată fi urmăriţi în cadrul procesului de evaluare a ofertelor şi aplicare a criteriului de atribuire. (8) Atunci când stabileşte factorii de evaluare a ofertelor, autoritatea contractantă nu are dreptul de a utiliza factori care:

Pagina 66 din 80 a) nu au o legătură directă cu natura şi obiectul contractului de achiziţie publică ce urmează să fie atribuit; b) nu reflectă un avantaj pe care autoritatea contractantă îl poate obţine prin utilizarea factorului de evaluare respectiv.” În legătură cu factorul de evaluare criticat, din analiza Strategiei de contractare nr. 13742/20.05.2026, Consiliul constată că autoritatea contractantă a prezentat următoarele explicații: „Autoritatea contractantă a avut, vedere prevederile art. 32 alin (9) din HG nr. 395/2016. Pe baza experiențelor anterioare, autoritatea contractanta a identificat riscul unei abordări formale din partea ofertanților, materializată prin redactarea ofertei cu tehnica de tip copy- paste, ceea ce conduce la o înțelegere insuficientă a cerințelor specifice şi, implicit, la o ofertare care nu ia în considerare toate exigențele autorităţii contractante. Pentru a stimula depunerea unor oferte adecvate, care să răspundă în mod convingător şi angajant cerințelor autoritatea contractantă a stabilit un punctaj suplimentar pentru propunerile tehnice ce demonstrează niveluri superioare de înțelegere a cerințelor caietului de sarcini. Ponderea de 15% reflectă importanța pe care autoritatea contractantă o acordă calității metodologiei și abordării, aspecte care influențează direct calitatea livrabilelor intelectuale ale contractului.” Analizând toate aceste informații, Consiliul constată că, în fapt, în discuție este un factor privind aspecte considerate de autoritatea contractantă a fi calitative, respectiv dovedirea înțelegerii și prezentare unei oferte adecvate. Astfel, autoritatea contractantă leagă relevanța rezultatului obținut în baza contractului supus achiziție prin derularea procedurii de atribuire de față, de modul în care ofertanți prezintă în cadrul ofertei abordarea și metodologia avută în vedere, fără a exista o justificare necesară impusă de legiuitor prin normele legale citate anterior, lipsind avantajele de ordin tehnic care ar fi obținute ca urmare a aplicării factorului de evaluare respectiv. În aprecierea sa, Consiliul are în vedere că nu există nicio justificare efectivă a modului în care se va stabili nivelul de adecvare pentru acordare punctajului pentru acest factor de evaluare, punctarea fiecăreia dintre oferte fiind, în mod evident, fiind una arbitrară. Din coroborarea informațiilor existente în documentația de atribuire și clarificările aduse acesteia se constată că, în fapt, toate aceste indicații date de autoritatea contractantă cu privire la algoritmul de calcul pentru acest factor de evaluare reprezintă mai degrabă instrucțiuni cu privire la ce ar trebui să conțină propunerea tehnică, decât avantajele rezultate prin utilizarea lor, respectiv descrierea modului de acordare a punctajului pentru un factor de evaluare stabilit conform prevederilor legale incidente anterior citate. În acest sens, prezintă relevanță dispozițiile art. 20 alin. (10) din HG nr. 395/2016: ”Caietul de sarcini conţine, în mod obligatoriu, specificaţii tehnice care reprezintă cerinţe, prescripţii, caracteristici de natură tehnică ce permit fiecărui produs, serviciu sau lucrare să fie descris, în mod obiectiv, astfel încât să corespundă necesităţii autorităţii contractante.” A avea o abordare și o metodologie adaptate la specificul contractului, situație care determină primirea punctajului maxim de 15 de puncte, pondere mai mult decât semnificativă din totalul punctajului, presupune că respectiva propunere tehnică corespunde necesității autorității contractante, și reprezintă o condiție de conformitate a ofertei și nu un avantaj obținut de autoritatea contractantă, pentru a putea fi folosit ca factor de evaluare a ofertelor. Dacă cerințele de calitate minime considerate necesare au fost stabilite prin caietul de sarcini, Consiliul consideră că nu pot fi făcute aprecieri dacă acestea nu au fost îndeplinite sau au fost îndeplinite parțial ori în mare măsură, respectiv dacă metodologia propusă are la bază metodologii, metode sau

Pagina 67 din 80 instrumente testate și recunoscute în domeniu, determinând aprecieri evident subiective a măsurii în care sunt recunoscute ori a caracterului lor inovativ. Se introduce astfel un factor de evaluare privind documente care conțin metodologiile, metodele și sau instrumentele necesare realizării contractului care, în fapt, ar trebui să se regăsească în propunerea tehnică pentru a dovedi îndeplinirea cerințelor caietului de sarcini. În acest sens sunt și cele stabilite de achizitoare în caietul de sarcini, în care, printre altele, este indicat la cap. 9 ABORDAREA, METODOLOGIA, PLANUL DE LUCRU ȘI GRAFICUL DE PRESTARE, subcap. 9.1 ABORDARE ȘI METODOLOGIE, că: „Această secțiune constituie fundamentul conceptual al propunerii tehnice și trebuie să prezinte strategia ofertantului pentru prestarea calitativă a serviciilor solicitate. Autoritatea contractantă permite ofertanților să propună o abordare proprie de răspuns la cerințele caietului de sarcini, fără să se înregistreze abateri de la cerințele minime sau condiționări de orice fel. Ofertantul va demonstra înțelegerea profundă a cerințelor prin prezentarea viziunii sale asupra modului de realizare a contractului, identificând și analizând contextul specific în care se va desfășura contractul, particularitățile sarcinilor stabilite în caietul de sarcini, factorii critici de succes și potențialele riscuri specifice care pot afecta implementarea. Metodologia propusă va detalia modul de organizare a resurselor propuse de Ofertant pentru obținerea rezultatelor la nivelul cantitativ și calitativ așteptat pentru atingerea obiectivelor contractului. Ofertantul va identifica și analiza aspectele-cheie care condiționează succesul contractului, prezentând corelația dintre metodologia propusă și modul de adresare a acestor aspecte critice. Ofertantul va prezenta în mod explicit metodologiile, metodele și instrumentele propuse a fi utilizate. Pentru fiecare instrument și proces propus, se va justifica alegerea acestuia și se va explica modul concret în care va fi aplicat în contextul specific al contractului, precum și beneficiile pe care le aduce. Se vor prezenta ipotezele de lucru pe care se bazează abordarea propusă, precum și analiza riscurilor suplimentare asociate execuției contractului, identificate de Ofertant, cu evidențierea strategiilor de răspuns propuse. Ofertantul va demonstra prin măsuri concrete, adaptate specificului proiectului ce face obiectul prezentului caiet de sarcini, modul în care va avea în vedere managementul calității în cadrul contractului. Analiza cadrului legal și normativ aplicabil va include identificarea prevederilor relevante pentru domeniul contractului, inclusiv unele suplimentare față de cele detaliate de autoritatea contractantă, explicând modul în care se asigură conformitatea deplină cu aceste cerințe. Ofertantul trebuie să prezinte în cadrul propunerii tehnice descrierea metodologiei proprii de management de proiect pe care o va utiliza în cadrul contractului din care va reieși cel puțin modul de organizare a resurselor pentru obținerea rezultatelor așteptate. Pentru a demonstra o foarte bună înțelegere a caietului de sarcini, abordarea și metodologia trebuie să fie adaptate cerințelor specifice ale contractului, fiind descurajate abordările de tip copy-paste.” Îndeplinirea acestor cerințe determină conformitatea ofertei, fiind obligatorie îndeplinirea condiției ca abordarea și metodologia să fie detaliate și adaptate la specificul contractului, iar lipsa prezentării acestora în cadrul unei oferte nu îi poate permite autorității contractante să acorde punctaj unei astfel de oferte, în discuție fiind o condiție de conformitate. Este evident că neîndeplinirea lor sau îndeplinirea parțială a acestora, ar trebui să constituie, mai degrabă, subiect al unor solicitări de clarificări sau să determine neconformitatea ofertei și nu primirea unui punctaj, chiar și minim. De asemenea, raportarea la faptul că abordarea propusă și metodologia prezentată nu se bazează/se bazează într-o măsură mai mare sau mai mică pe

Pagina 68 din 80 metodologii, metode și/sau instrumente recunoscute, este evident că nu poate determina o apreciere obiectivă a unei propuneri tehnice, fiind la latitudinea membrilor comisiei de evaluare de a stabili gradul de recunoaștere al acestora, fără a se putea stabili modul în care s-ar aprecia că aceste metodologii/metode și sau/instrumente etc, în ce măsură sunt recunoscute sau nu. În fapt, este prevăzut un raționament care se referă la condiții de conformitate a ofertei, neputând fi acceptate oferte care nu sunt adaptate specificului contractului. Nici neprezentarea detaliată a metodologiilor nu ar putea avea ca rezultat declararea conformă a unei oferte, constituind mai degrabă motiv de neconformitate a acesteia, situație în care nu este permisă acordarea unui punctaj. Nu în ultimul rând, neasigurarea nivelului calitativ solicitat prin caietul de sarcini, prin metodologia propusă, este din nou o condiție neîndeplinită de conformitate a ofertei, nicio ofertă neputând fi declarată conformă, și cu atât mai puțin să primească punctaj, în situația existenței unor astfel de deficiențe. Toate aceste condiții sunt cerințe minimale care ar trebui să se regăsească în caietul de sarcini, condiții de conformitate a unei oferte și în niciun caz criterii de acordare a punctajului/departajare a ofertelor. Este evident faptul că o ofertă care îndeplinește aceste condiții impuse prin caietul de sarcini în totalitatea lor determină conformitatea acesteia, neputând fi acceptată îndeplinirea cerințelor caietului de sarcini pe mai multe nivele pentru a putea primi 0, 10 sau 15 puncte. În discuție sunt condiții de conformitate ale ofertei, nu cele aferente unui factor de evaluare, iar o ofertă nu poate fi ”mai conformă” decât alta pentru a primi un punctaj mai mare, în funcție de aprecierea subiectivă a membrilor comisiei de evaluare. Este evident că a se constata că o ofertă este conformă nu este un avantaj pentru achizitoare pentru a-i acorda un anumit punctaj, iar a acorda punctaje diferite pe principiul că o ofertă are un nivel de înțelegere ”mai adecvat” decât alta, contravine prevederilor legale incidente, mai sus citate. Relevant pentru lipsa de legalitate a utilizării unui astfel de factor de evaluare este modul în care este descris raționamentul pentru acordarea punctajului maxim, de 15 de puncte: ”Ofertantul demonstrează o înțelegere completă și profundă a dimensiunilor contractului și propune o abordare foarte adaptată prin raportare la cerințele specifice din caietul de sarcini. Metodologia propusă are la bază metodologii, metode sau instrumente testate și recunoscute în domeniu. Pentru toate componentele metodologice sunt prezentate referințe la standarde internaționale, certificări profesionale sau metodologii consacrate, cu adaptări specifice și inovative la contextul contractului. Pentru fiecare instrument și proces propus este justificată alegerea și explicat în detaliu modul de aplicare, precum și beneficiile pentru autoritatea contractantă. Cerințele specifice din caietul de sarcini sunt identificate și abordate prin soluții concrete, fiind propuse elemente inovative sau optimizări demonstrabile față de abordările standard. ……………………………………………………………………………………………………………………………………………………… Analiza riscurilor suplimentare este foarte bine abordată, incluzând evaluarea probabilitate/impact, strategii diferențiate de răspuns și planuri de contingență detaliate, foarte bine corelate cu cerințele caietului de sarcini. Managementul calității este detaliat cu măsuri concrete, puncte de control și metrici specifice adaptate proiectului. Sunt prezentate mecanisme concrete de îmbunătățire continuă, adaptate la specificul contractului. Sunt propuși indicatori de performanță suplimentari față de cei din caietul de sarcini, cu valori țintă și metode de măsurare.

Pagina 69 din 80 Analiza cadrului legal este foarte bine realizată, identificând prevederi relevante suplimentare substanțiale și demonstrând modalitatea de asigurare a conformității.” Pe lângă ambiguitatea situației determinate de introducerea sintagmei ”o înțelegere completă și profundă a dimensiunilor contractului și propune o abordare foarte adaptată” în privința detalierii solicitate (de a avea la bază în mare măsură metodologii, metode și/sau instrumente testate recunoscute în domeniu), lipsa de obiectivitate a aprecierilor este accentuată și de stabilirea necesității ca aceste metodologii, metode instrumente să fie recunoscute, Consiliul apreciind că notorietatea acestora nu poate determina departajarea ofertelor, fiind contrară prevederilor legale amintite. Acordarea punctajului în funcție de modul în care s-ar aprecia că aceste metodologii, metode și/sau instrumente sunt mai mult sau mai puțin recunoscute ori metodologia prezentată a fost mai bine sau mai puțin detaliată, ar fi lipsită de obiectivitate, în mod evident. Nivelul de detaliere dorit trebuie indicat în caietul de sarcini și analizat prin raportare la obiectul contractului și nu ca element de departajare a ofertelor. Pe de altă parte, modul în care este prezentat algoritmul de calcul atestă faptul că în stabilirea punctajului acordat, nu există niciun element de control, altul decât aprecierea discreționară a membrilor comisiei de evaluare. Mai mult decât atât, devine evident că, procedând astfel, prin stabilirea acestui factor de evaluare, caracterul obiectiv al evaluării este afectat pentru o situație care nu poate fi verificată, ofertanții neputând anticipa la momentul realizării ofertei punctajul pe care l-ar obține oferta lor pentru acest factor de evaluare, deși se raportează strict la propria ofertă, nefiind condiționat de elementele existente în cadrul unei alte oferte. Toate aceste elemente impuse pentru algoritmul de acordare a punctajului ar fi trebuit să se materializeze în cerințe ale caietului de sarcini, iar mențiunile legate de acordarea punctajului maxim ar trebui să fie cerințe minime ale caietului de sarcini și nu mijloc de departajare a ofertelor în baza unei aprecieri subiective. Îndeplinirea unor cerințe minimale ale caietului de sarcini nu poate primi calificative precum cele definite de autoritatea contractantă, ci doar stabilită conformitatea/neconformitatea ofertei din acest punct de vedere. Modul de punctare nu este stabilit în mod clar și neechivoc, pentru a permite ofertanților să obțină punctaje cât mai ridicate, tocmai pentru că ofertanții nu vor putea face nicio apreciere legată de faptul că viziunea lor de a întocmi oferta corespunde cu cea a autorității contractante din punct de vedere al caracterului adecvării și al detalierii metodologiei propuse. Faptul că se dorește să se convingă că viitorul executant știe să execute și să gestioneze un astfel de contract, nu este asigurat de utilizarea unor factori de evaluare subiectivi precum cel în analiză, cu o pondere foarte mare, a cărui modalitate de aplicare nu poate fi verificată, interpretarea ofertanților putând diferi de cea a achizitoarei sau chiar a Consiliului la un eventual control de legalitate al modului de acordare al punctajului, tocmai datorită faptului că în discuție sunt mai degrabă cerințe minimale ale caietului de sarcini din acest punct de vedere, iar îndeplinirea lor nu poate fi făcută prin aprecieri de genul celor analizate, ci prin stabilirea caracterului conform/neconform al ofertei din acest punct de vedere. Legiuitorul a pus la dispoziția sa suficiente instrumente a se asigura că viitorul executant știe să execute și să gestioneze un astfel de

Pagina 70 din 80 contract, fără a fi necesară utilizarea unui astfel de factor de evaluare pentru atingerea obiectivelor propuse. Prin urmare, deși nu este stabilită metodologia clară cu privire la modul în care o ofertă primește punctaj, devine evident că avantajul obținut de autoritatea contractantă prin utilizarea acestui factor de evaluare este nul. Dacă achizitoarea dorește a impune anumite cerințe care din prisma sa sunt absolut necesare pentru a fi asigurate condițiile de calitate dorite, acestea pot fi impuse prin caietul de sarcini, fără a se utiliza un factor de evaluare care nu îi va aduce niciun avantaj în sensul definit conform prevederilor legale amintite. De asemenea, legalitatea unui asemenea factor de evaluare nu este dată de faptul că acesta se regăsește în CATALOGUL Factori de evaluare, emis de ANAP. Într-adevăr, ANAP a emis un catalog cu factorii care pot fi utilizați, însă acel catalog este cu titlu general, parte a unei documentații standard, orientative, dar alegerea factorilor de evaluare nu este universal valabilă, indiferent de complexitatea și natura contractului. Utilizarea unui astfel de factor de evaluare într-un astfel de contract, cu o pondere de 15% din punctajul total nu poate fi justificată în condițiile în care este afectată evaluarea ofertelor într-un mod care contravine prevederilor legale amintite. De altfel, ANAP a precizat expres chiar în acest catalog faptul că: ”(...) orice factor de evaluare inclus în Documentația de atribuire trebuie sa aibă „în oglindă” o clauză contractuală care să asigure materializarea avantajului obținut de Operatorul Economic Ofertant în evaluare pe perioada derulării Contractului, precum și un mecanism de corectare a eventualelor devieri de la materializarea avantajelor acordate pe perioada evaluării”. Or, este evident că informațiile pentru care acordă punctajul autoritatea contractantă nu își au oglindă într-o clauză contractuală, nematerializându-se în vreun avantaj în favoarea achizitoarei, ci reprezintă doar o modalitate neanticipabilă/discreționară de acordare a punctajului. Utilizarea unui astfel de factor de evaluare indiferent de tipul procedurii de atribuire și gradul de complexitate a contractului nu oferă vreun avantaj autorității contractante, dar contribuie la crearea de condiții de eludare a rezultatului procedurii, prin ponderea mare acordată acestui factor și imposibilitatea verificării obiective a modului de punctare a lui. Pentru aceste motive, Consiliul consideră necesară eliminarea acestui factor de evaluare și completarea caietului de sarcini prin cuprinderea ca cerințe minime obligatorii a elementelor considerate necesare a se regăsi în cadrul propunerilor tehnice pentru atingerea obiectivelor dorite de achizitoare. În ceea ce privește factorii de evaluare Pt3 Planul de lucru și Pt4 Grafic de prestare, Consiliul are în vedere că autoritatea contractantă a prevăzut în caietul de sarcini următoarea detaliere: - Pt3 Planul de lucru: - pentru ”0” puncte: „Structura WBS (structura detaliată de defalcare a serviciilor / activităților: WBS - Work Breakdown Structure) este prezentată, însă mai multe elemente din aria de cuprindere sunt omise sau tratate necorespunzător. Pot fi identificate mai multe contradicții și neclarități. Planul de lucru prezintă faze și etape, defalcate în activități principale și sub-activități, dar nivelul de detaliere este insuficient. Nu se demonstrează sistematic și convingător alinierea cu cerințele caietului de sarcini sau cu abordarea și metodologia propuse.

Pagina 71 din 80 Sub-activitățile prezentate permit controlul execuției la un nivel de bază, respectând limita de maximum o lună, dar descrierea lor detaliată prezintă mai multe omisiuni sau necorelări. Pentru fiecare activitate / sub-activitate sunt specificate rezultatele / livrabilele asociate, însă nivelul de detaliere este minimal. Duratele activităților / sub-activităților sunt prezentate, dar justificarea lor prin detalierea efortului exprimat în zile-om și a resurselor alocate este incompletă sau neclară. Există o matrice de alocare a responsabilităților, dar aceasta este incompletă sau necorelată suficient cu cerințele din caietul de sarcini. Structura organizatorică propusă pentru managementul și implementarea contractului și procesele de coordonare sunt prezentate, dar insuficient de adaptate la specificul și provocările specifice ale proiectului. Alocarea resurselor umane pentru implementarea contractului este prezentată, dar se limitează la experții-cheie/non-cheie cu cerințe minime stabilite în caietul de sarcini. Există multe neclarități cu privire la corelația între competențele experților propuși, activitățile necesar a fi realizate și efortul estimat pentru realizarea acestora. Pentru asocieri/subcontractanți este explicat modul de integrare și coordonare, dar există și aspecte neclare sau ambiguități. (cerință minimă)” - pentru 10 puncte: „Structura WBS este completă și acoperă întreaga arie de cuprindere a contractului. Elementele sunt prezentate coerent și fără contradicții semnificative. Planul de lucru demonstrează o aliniere clară cu cerințele caietului de sarcini precum și cu abordarea și metodologia propuse. Aspectele de management al calității și al riscurilor sunt transpuse în activități și sub-activități concrete. Sub-activitățile sunt detaliate adecvat, respectând limita de maximum o lună, și permit monitorizarea eficientă a progresului. Descrierea lor este clară și corelată cu obiectivele contractului. Pentru toate activitățile și sub-activitățile sunt specificate rezultatele/livrabilele concrete asociate și criteriile de acceptare, cu un nivel de detaliere satisfăcător care permite înțelegerea clară a așteptărilor. Duratele estimate sunt justificate prin prezentarea efortului în zile-om și a resurselor alocate, demonstrând o corelare logică între complexitatea activităților și resursele necesare. Matricea de alocare a responsabilităților (RACI) este bine întocmită, clarificând bine rolurile fiecărui membru al echipei. Ține cont de activitățile principale și este bine corelată cu cerințele din caietul de sarcini. Structura organizatorică propusă este bine adaptată specificului proiectului, cu procese clare de coordonare, comunicare și raportare. Procesul de luare a deciziilor diferențiază între deciziile operaționale și cele strategice. Procedurile de escaladare sunt prezentate pentru situațiile principale. Alocarea resurselor umane demonstrează o corelare satisfăcătoare între competențele experților propuși, complexitatea activităților și efortul estimat. Pe lângă experții-cheie sunt prezentați și experți non-cheie sau personal suport relevant. Pentru asocieri/subcontractanți, modul în care expertiza fiecărui membru contribuie la implementarea contractului este prezentat clar, cu mecanisme definite de coordonare și control.” - pentru 15 puncte: „Structura WBS demonstrează excelență în organizarea ierarhică, cu o defalcare optimă care facilitează atât monitorizarea detaliată cât și raportarea executivă. Toate elementele sunt foarte bine integrate și corelate, fără neclarități majore sau contradicții. Planul de lucru demonstrează alinierea foarte bună cu cerințele caietului de sarcini și cu abordarea și metodologia propuse. Aspectele de management al calității și al riscurilor sunt integrate complet cu puncte de control și metrici specifice. Sub-activitățile prezintă granularitate optimă pentru monitorizare eficientă fără complexitate excesivă, respectând foarte bine cerințele. Fiecare sub-activitate este descrisă foarte bine cu inputuri, procese, outputuri și criterii de succes.

Pagina 72 din 80 Pentru toate activitățile și sub-activitățile sunt specificate în detaliu rezultatele/livrabilele concrete, criteriile clare și măsurabile de acceptare, precum și standardele de calitate aplicabile. Sunt prezentate template-uri sau exemple de livrabile acolo unde este relevant. Duratele estimate sunt justificate clar și sistematic prin raportare la efortul estimat, ținând cont de complexitatea activităților, resursele alocate, precum și alte constrângeri existente. Matricea de alocare a responsabilităților (RACI) este foarte bine întocmită, clarificând foarte bine rolurile fiecărui membru al echipei. Ține cont de activitățile principale și este foarte bine corelată cu cerințele din caietul de sarcini. Structura organizatorică detaliată demonstrează adaptare foarte bună la specificul și complexitatea proiectului, cu toate procesele de coordonare, comunicare și raportare definite complet. Procesul de luare a deciziilor este clarificat complet cu diagrame de flux. Procedurile de escaladare acoperă mai multe scenarii posibile cu timpii de răspuns definiți. Alocarea resurselor demonstrează optimizare foarte bună cu analize de încărcare, identificarea perioadelor de vârf și strategii de nivelare. Se prezintă echipa completă inclusiv personal de back-up și planuri de continuitate pentru experții critici. Pentru asocieri/subcontractanți este demonstrată foarte bine valoarea adăugată, sinergia și complementaritatea competențelor, cu proceduri detaliate de integrare, mecanisme clare de coordonare, control al calității și transfer de cunoștințe.”. - Pt4 Grafic de prestare: - pentru ”0” puncte: „Graficul de prestare este realizat cu un software de management de proiect și prezintă planificarea temporală a activităților și sub-activităților într-o reprezentare GANTT corelată în linii mari cu WBS-ul, dar nivelul de detaliere este minimal. Graficul demonstrează capacitate elementară de replanificare și nivelare a resurselor. Pentru elementele prezentate sunt specificate data de început, durata și data de finalizare, însă alocarea resurselor umane pe activități este prezentată la nivel general, demonstrând parțial că planificarea propusă este realistă și fezabilă. Dependențele între activități sunt stabilite predominant folosind relații de tip finish-to-start, cu utilizare limitată a altor tipuri de relații logice. Jaloanele intermediare și finale sunt definite pentru etapele majore, demonstrând încadrarea generală în termenul specificat în caietul de sarcini, dar se limitează la detalierea furnizată de achizitor. Drumul critic este identificat, dar scenariile de optimizare sunt neclare sau slab argumentate. (cerința minimă)” - pentru 10 puncte: „Graficul demonstrează utilizarea competentă a unui software profesional de management de proiect, cu o reprezentare GANTT buna a activităților și sub-activităților conform structurii WBS. Nivelul de detaliere este adecvat pentru monitorizarea eficientă a progresului. Graficul demonstrează capacitate bună de replanificare cu recalcularea drumului critic și permite nivelarea manuală sau semi-automată a resurselor. Pentru toate elementele sunt specificate corect data de început planificată, durata în zile lucrătoare, data de finalizare planificată și resursele alocate. Alocarea resurselor umane pe activități este detaliată pentru experții-cheie, demonstrând bine că planificarea propusă este realistă și fezabilă. Dependențele dintre activități sunt modelate folosind diverse tipuri de relații logice (FS, SS, FF) acolo unde este cazul, demonstrând înțelegerea logicii de execuție. Jaloanele intermediare și finale sunt definite pentru toate fazele și etapele majore, demonstrând planificarea echilibrată pe parcursul celor 24 de luni. Pe lângă jaloanele solicitate în caietul de sarcini sunt propuse jaloane suplimentare relevante pentru monitorizare. Drumul critic este calculat automat și analizat cu explicarea unor scenarii minimale de optimizare.” - pentru 15 puncte: „Graficul demonstrează excelență în planificare folosind capabilitățile avansate ale unui software profesional de management de proiect cu o reprezentare GANTT foarte bună a activităților și sub-activităților conform structurii WBS. Sunt utilizate consistent codurile WBS, iar nivelul de detaliere prezentat permite monitorizarea eficientă a progresului, evitând însă

Pagina 73 din 80 micro-managementul. Graficul demonstrează capacitate foarte bună de replanificare dinamică cu recalcularea drumului critic și permite nivelarea manuală sau semi-automată a resurselor. Dependențele dintre activități sunt modelate folosind diverse tipuri de relații logice (FS, SS, FF) acolo unde este cazul, demonstrând înțelegerea logicii de execuție. Decalajele (lead/lag) sunt documentate cu explicarea necesității tehnice. Nu există constrângeri temporale fixe nejustificate, toate activitățile fiind conduse de logica dependențelor. Alocarea detaliată a tuturor resurselor umane necesare (experți-cheie, non-cheie, suport) inclusiv cele pentru care nu există cerințe minime formulate la nivelul caietului de sarcini, dar care sunt necesare pentru o bună implementre. Jaloanele sunt definite la multiple niveluri cu criterii SMART de verificare. Sunt propuse jaloane de control al calității, jaloane de decizie și jaloane de comunicare cu stakeholderii, demonstrând înțelegerea aprofundată a managementului proiectului. Drumul critic este analizat cu identificarea tuturor secvențelor critice și aproape critice. Sunt prezentate minimum 2 scenarii documentate de optimizare, demonstrând flexibilitatea planificării.” Din analiza acestor descrieri, rezultă cu prisosință valabilitatea celor reținute anterior în legătură cu factorul Pt2, fiind și mai vizibilă punctarea unor condiții de conformitate ale ofertei, motiv pentru care, fără a relua cele stabilite anterior, Consiliul constată necesitatea eliminării și a acestor factori de evaluare și completarea caietului de sarcini prin cuprinderea ca cerințe minime obligatorii ale acestuia a elementelor considerate necesare a se regăsi în cadrul propunerilor tehnice pentru atingerea obiectivelor dorite de achizitoare. În aprecierea sa, Consiliul a avut în vedere inclusiv clarificările aduse de autoritatea contractantă asupra factorilor de evaluare, considerând că aceste nu sunt de natură a modifica natura discreționară a acestor factori în acordarea unui punctaj cumulat de până la 45% din punctajul total al ofertei fără ca autoritatea contractantă să obține vreun avantaj măsurabil în urma utilizării lor. Prin urmare, Consiliul va admite solicitarea contestatoarei privind eliminarea celor trei factori de evaluare Pt2 – Abordarea și metodologia, Pt3 – Planul de lucru și Pt4 – Grafic de prestare. În ceea ce privește următorul set de critici, respectiv cel de la pct. D, Consiliul reține că se referă la cerințele privind personalul-cheie, autoarea contestației sunt, în parte, disproporționate și insuficient corelate cu complexitatea reală a rolurilor solicitate. Astfel, o primă critică, Consiliul constată că privește cerința referitoare la competențele solicitate pentru Expertul cheie nr. 4 - Expert îmbunătățire procese de business, legat de implementarea asistenților virtuali, autoarea contestației susținând că este disproporționată în raport cu rolul acestui expert. În soluționare, Consiliul constată că pentru acest expert, autoritatea contractantă a prevăzut în caietul de sarcini, cap. 11.1.4. Expert cheie nr. 4: Expert îmbunătățire procese de business, următoarele obligații: Responsabilități: - identificarea legislației și a procedurilor operaționale care reglementează serviciile publice în scopul proiectului ; - maparea grafică a proceselor existente și viitoare ; - elaborarea proiectelor de implementare a noului model de livrare a serviciilor publice ; - colaborarea cu ceilalți membri ai echipei de implementare cu scopul de a asigura implementarea corectă a noului model de livrare al serviciilor publice ; - participarea la elaborarea livrabilelor aferente serviciilor de analiză și proiectare. ……………………………………………………………………………………………………………………………………………………… Competențe profesionale Deținerea de competențe: - în domeniul managementului proceselor de business și

Pagina 74 din 80 - în domeniul managementului cerințelor și managementul schimbării și - în domeniul analizei de business pentru implementarea asistenților virtuali (Conversational AI), dovedite prin prezentarea unei diplome / certificări recunoscute la nivel național sau internațional în domeniul solicitat, în raport cu competențele specifice ce trebuie demonstrate. Sunt acceptate și documente echivalente celor solicitate, emise de organisme stabilite în alte state membre ale Uniunii Europene sau cu care România are încheiate acorduri pentru recunoașterea și echivalarea certificărilor / autorizațiilor în cauză. Referitor la aceste cerințe autoarea contestației critică impunerea deținerii unei competențe foarte specifice, respectiv deținerea de competențe în domeniul analizei de business pentru implementarea asistenților virtuali (Conversational AI), considerând că este disproporționată în raport cu obiectul și complexitatea reală a rolului său, în condițiile în care este unul dintre experții avuți în vedere la acordarea punctajului pentru factorul de evaluare Pt1 Experiență experți-cheie. Invocând principul proporționalității, contestatoarea susține că achizitoarea nu a explicat de ce competența privind implementarea asistenților virtuali, aplicabilă unei componente minore a sistemului, chatbot, a fost atașată tocmai profilului acestui expert și nu, spre exemplu, echipei tehnice responsabile direct de dezvoltarea componentei respective, motiv pentru care solicită: „fie eliminarea cerinței de competență privind Conversational AI de la Expertul cheie nr. 4 - Expert îmbunătățire procese de business, fie transferarea acesteia către un rol distinct, proporțional cu ponderea reală a componentei de chatbot în ansamblul contractului.” În replică, autoritatea contractantă prezintă argumente care, în opinia sa, arată motivele pentru care a asociat acestui expert cerința criticată, susținând că cerința caietului de sarcini se referă la analiza de business pentru implementarea asistenților virtuali (Conversațional AI) și nu la competențe de programare, antrenare de modele de limbaj sau dezvoltare software. Analizând susținerile celor două părți, inclusiv argumentele contestatoarei formulate prin răspunsul la punctul de vedere la apărările autorități contractante, transmis cu adresa nr. 1379/26.08.2026, respectiv prin punctul de vedere privind răspunsul consolidat nr. 15556/JV/27.08.2026 din această perspectivă, precum și concluziile scrise ulterioare acestuia din urmă formulate de achizitoare, Consiliul constată că autoritatea contractantă nu a fost în măsură să demonstreze motivele pentru care a impus pentru acest expert cheie necesitatea deținerii de competențe în domeniul analizei de business pentru implementarea asistenților virtuali (Conversational AI), în condițiile în care în cadrul echipei a impus includerea Expertului cheie nr. 3: Expert analist de business, expert care va realiza efectiv analiza de business, inclusiv din perspectiva ”asistentului virtual”. Prin urmare, consideră Consiliul, deținerea de competențe privind în domeniul analizei de business pentru implementarea asistenților virtuali (Conversational AI) sunt mai degrabă necesare expertului nr. 3, raportat la condițiile impuse pentru demonstrarea lor, respectiv competențe: „dovedite prin prezentarea unei diplome / certificări recunoscute la nivel național sau internațional în domeniul solicitat, în raport cu competențele specifice ce trebuie demonstrate. Sunt acceptate și documente echivalente celor solicitate, emise de organisme stabilite în alte

Pagina 75 din 80 state membre ale Uniunii Europene sau cu care România are încheiate acorduri pentru recunoașterea și echivalarea certificărilor / autorizațiilor în cauză”, decât pentru expertul nr. 4, pentru care ar trebui să fie suficientă participarea în astfel de contracte care au presupus implementarea asistenților virtuali (Conversațional AI) în calitatea de expert îmbunătățire procese de business, nefiind astfel afectată aplicarea factorului de evaluare Pt1 – Experiență experți- cheie. Această apreciere a Consiliului este în acord cu cele susținute de contestatoare (neinfirmate de achizitoare), care nu afirmă că nu ar fi necesare astfel de competențe, ci doar că atribuire lor expertului cheie desemnat pentru îmbunătățire procese de business este una disproporționată. Prin urmare, Consiliul va admite criticile contestatoarei în această privință și va obliga autoritatea contractantă la eliminarea cerinței privind deținerea de către Expertul cheie nr. 4 - Expert îmbunătățire procese de business de competențe în domeniul analizei de business pentru implementarea asistenților virtuali (Conversational AI). În ceea ce privește următoarea critică, respectiv cea de la pct. D.2, Consiliul constată că privește rolurile experților cheie nr. 8 și nr. 9, autoarea contestației susținând că se suprapun aproape integral, fără nicio diferențiere substanțială a responsabilităților. În acest sens, Consiliul are în vedere că în discuție sunt prevederile caietului de sarcini care stabilesc atribuțiile experților cheie, potrivit cărora: - cap. 11.1.8. Expert cheie nr. 8: Expert implementare Componenta de interoperabilitate: „Responsabilități: - transpunerea în funcționalități a cerințelor documentate în etapele de analiză și proiectare; - participarea la activitățile de instalare și dezvoltare/configurare a Componentei de interoperabilitate; - testarea funcționării soluției instalate și configurate, la nivelul sistemului, cu setul de date de test agreat cu Beneficiarul astfel încât să fie acoperite cerințele specifice de sistem; - asigurarea expertizei în domeniul tehnic cu privire la Componenta de interoperabilitate, precum și participarea la activitățile de testare; - colaborarea cu ceilalți membrii ai echipei cu scopul de a asigura implementarea corectă a cerințelor Beneficiarului; - documentarea configurărilor efectuate și transfer de cunoștințe către echipa de administrare IT din partea Beneficiarului; - stabilirea și elaborarea curriculei pentru instruirea utilizatorilor privind exploatarea soluției implementate; - participarea la elaborarea documentației de utilizare și administrare pentru soluția implementată.” - cap. 11.1.9. Expert cheie nr. 9: Expert implementare Componenta de integrare si pregătire a datelor: „Responsabilități: - transpunerea în funcționalități a cerințelor documentate în etapele de analiză și proiectare; - participarea la activitățile de instalare și dezvoltare/configurare a Componentei de integrare si pregătire a datelor, inclusiv pentru migrarea datelor; - testarea funcționării soluției instalate și configurate, la nivelul sistemului, cu setul de date de test agreat cu Beneficiarul astfel încât să fie acoperite cerințele specifice de sistem; - asigurarea expertizei în domeniul tehnic cu privire la Componenta de integrare si pregătire a datelor, precum și participarea la activitățile de testare; - colaborarea cu ceilalți membrii ai echipei cu scopul de a asigura implementarea corectă a cerințelor Beneficiarului;

Pagina 76 din 80 - documentarea configurărilor efectuate și transfer de cunoștințe către echipa de administrare IT din partea Beneficiarului; - stabilirea și elaborarea curriculei pentru instruirea utilizatorilor privind exploatarea soluției implementate; - participarea la elaborarea documentației de utilizare și administrare pentru soluția implementată.” Raportat la aceste cerințe, contestatoarea solicită următoarele: „fie comasarea Expertului cheie nr. 8 și a Expertului cheie nr. 9 într-un singur rol, fie prezentarea de către autoritatea contractantă a unei justificări obiective privind necesitatea separării acestor două roluri.” Astfel se constată că ceea ce reclamă autoarea contestației este impunerea de către autoritatea contractantă a doi experți cu responsabilități similare, susținând că, așa cum sunt definite rolurile acestora prin intermediul documentației de atribuire, nu există niciun temei pentru a impune în cadrul echipei de experți două persoane, apreciind ca suficientă includerea doar a uneia singure. Consiliul constată că din apărările autorității contractante nu rezultă motivele pentru care responsabilitățile celor doi experți nu ar putea fi asigurate de o singură persoană desemnată în acest scop, respectiv motivele pentru care aceste atribuții se exclud unele pe celelalte pentru a nu putea fi realizate de același expert. Presupusa nevoie de separare a responsabilităților ar trebui să reflectată de volumul activităților, nevoia rezultată din competențele necesare sau alte asemenea atribute și nu din aprecierea empirică privind faptul că necesitatea rezultă din faptul că activitatea acestora privește componente funcționale diferite ale soluției. Niciunul dintre argumentele prezentate de autoritatea contractantă prin intermediul punctului de vedere nu este de natură a dovedi că impunerea a doi experți cheie pentru îndeplinirea responsabilităților în discuție este rezultatul unei analize obiective în acest sens care determină o astfel de dimensionare a echipei propuse pentru realizarea contractului. Prin urmare, în lipsa unor explicații care să determine nevoia dimensionării echipei experți cheie din acest punct de vedere, prin raportare la principiul proporționalității, statuat de art. 2 din Legea nr. 98/2016, pentru a stabili ceea ce este necesar și adecvat pentru realizarea contractului, Consiliul va admite criticile contestatoarei și va obliga autoritatea contractantă la comasarea atribuțiilor celor doi experți pentru unul singur. În ceea ce privește critica de la pct. D.3, Consiliul reține că se referă la competențele experților nr. 2 și nr. 3, autoarea contestației susținând că nu au legătură cu responsabilitățile de arhitect de sistem, respectiv de analist de business, ale acestor experți. Astfel, Consiliul constată că autoarea contestației critică responsabilitățile prevăzute de autoritatea contractantă în caietul de sarcini la cap. 11.1.2. Expert cheie nr. 2: Expert arhitect de sistem și cap. 11.1.3. Expert cheie nr. 3: Expert analist de business, susținând că acestea nu privesc activități specifice managementului serviciilor IT, motiv pentru care solicită următoarele: „eliminarea cerinței de competențe privind managementul serviciilor IT de la Experții cheie nr. 2 și nr. 3, cu menținerea exclusivă a cerințelor de competențe aflate în directă legătură cu responsabilitățile fiecăruia dintre cele două roluri.” Ca și în cazurile anterior analizate, Consiliul constată că nu există nicio justificare din partea autorității contractante care să demonstreze motivele

Pagina 77 din 80 pentru care în activitatea desfășurată în realizarea contractului supus achiziției prin procedura de atribuire, arhitectul de sistem sau analistul de business au nevoie de asemenea competențe, fără de care ar fi pusă în pericol realizarea contractului. De altfel, chiar din apărările autorității contractante rezultă rolul diferit al celor doi experți față de un expert în managementul serviciilor IT. Or, în situația în care achizitoarea consideră necesară acoperirea unei astfel de nevoi privind managementul serviciilor IT, atunci nimic nu o împiedică în a solicita ca ofertanții să includă în echipa lor un expert care să dețină astfel de competențe, fără a include în mod discreționar aceste competențe printre competențele unor experți cu atribuții diferite. În condițiile în care contestatoarea a invocat și demonstrat că atribuțiile celor doi experți sunt diferite de cele ale unui expert în managementul serviciilor IT, fără ca autoritatea contractantă să le infirme prin apărările formulate, Consiliul va admite criticile contestatoarei formulate în acest sens și va obliga autoritatea contractantă la eliminarea cerinței privind dovedirea deținerii de competențe în domeniul managementului serviciilor IT. În ceea ce privește ultima critică din cadrul acestui set de critici, respectiv cea de la pct. D.4, Consiliul constată că reprezintă: „Observație de context privind modul de redactare a cerințelor pentru expert- coordonator pe componentă”, fără a fi însoțită de argumente și dovezi din care să rezulte nelegalitatea definirii cerințelor aferente experților, altele decât cele deja analizate, precum și fără a fi însoțită și de o solicitare concretă privind modul de remediere a celor semnalate. În aceste condiții, Consiliul va respinge ca nefondate criticile contestatoarei de la acest punct. Referitor la ultima dintre criticile formulate de contestatoare, respectiv cea de la pct. E, Consiliul constată că privește prevederilor documentației de atribuire privind durata de prestare a serviciilor, calendarul activităților, recepția finală și formalitățile de plată, autoarea contestației susținând că necorelarea acestora face imposibilă determinarea duratei efective de prestare și elaborarea Graficului de prestare pe baze clare și unitare, motiv pentru care solicită următoarele: „Se impune, în consecință, obligarea autorității contractante să stabilească fără echivoc momentul până la care trebuie finalizate serviciile de instruire și toate celelalte activități contractuale, dacă verificarea, remedierea și recepția finală trebuie realizate în interiorul termenului de 24 de luni și care este, în concret, semnificația rezervării ultimei luni contractuale pentru formalitățile de plată, cu modificarea corespunzătoare a calendarului de implementare și a celorlalte prevederi ale documentației care se dovedesc necorelate”. În soluționarea contestației, pe acest aspect, Consiliul consideră relevante cele comunicate de autoritatea contractantă prin adresa nr. 16706/JV/ 15.09.2026, ca urmare a punctului de vedere formulat de contestatoare nr. 1390/08.09.2026 privind clarificările aduse de achizitoare pe acest aspect prin răspunsul consolidat nr. 15556/JV/27.08.2026, și anume: „Contestatoarea recunoaşte că răspunsul la întrebarea nr. 137 înlătură ambiguitatea de intenţie, însă menţine capătul E pe seama calendarului orientativ publicat în caietul de sarcini şi pe seama regulii de reluare a perioadei de stabilitate, lămurită la întrebarea nr. 129. Nici una dintre cele două observaţii nu restabileşte o necorelare care ar face imposibilă determinarea duratei efective de prestare.

Pagina 78 din 80 Regula de planificare este una singură şi se citeşte unitar. Termenul maxim de executare este de 24 de luni de la semnarea contractului. Activitătile tehnice — livrări, implementare, testare, instruire şi cele patru săptămâni de funcţionare fără incidente majore — se încheie cel târziu la sfârşitul lunii 23. Luna 24 nu este o fază suplimentară de dezvoltare. Este fereastra rezervată formalităţilor de recepţie finală, facturare şi plată, anunţată încă din cap. 9.3 şi 10.2 ale Caietului de sarcini şi reconfirmată prin răspunsurile la întrebările nr. 22 din Clarificarea nr. 5 şi nr. 137. Cele două răspunsuri nu se contrazic: primul ancorează durata contractuală de 24 de luni de la semnare şi corelează formularea „nu mai târziu de "din art. 5.2 al modelului de contract cu eligibilitatea fondurilor, fără a scurta acest termen; al doilea precizează distribuţia internă a celor 24 de luni între activitatea tehnică şi formalităţile finale. Definiţiile din contract — durata de valabilitate, durata de prestare până la procesul- verbal de recepţie finală şi durata de executare de 24 de luni — acoperă faze juridice diferite, tehnică obişnuită în contractele publice complexe. Prestarea nu se consideră încheiată prin ultima operaţiune tehnică, ci prin validarea formală. De aceea prestatorul trebuie să îşi aşeze livrările cu anticipaţie, astfel încât recepţia finală şi plata să poată fi încheiate în luna 24. Calendarul publicat în caietul de sarcini este etichetat orientativ. Cap. 9.3 permite expres durate diferite pe faze, cu încadrare în termenul maxim. O diagramă care prelungeşte linia de instruire şi asupra lunii 24 rămâne o ilustrare, nu o dispoziţie de a desfăşura activitate tehnică în luna rezervată plăţii. O interpretare care ar trata diagrama orientativă ca regulă autonomă, fără a o corobora cu răspunsurile la întrebările nr. 22 şi nr. 137, nu evidenţiază o necorelare a documentaţiei, ci o interpretare incompletă a acesteia. Comparabilitatea graficelor se judecă pe respectarea aceluiaşi plafon — 24 de luni în total, activitate tehnică până cel târziu la sfârşitul lunii 23 — nu pe copierea rândurilor din figură (…). Autoritatea nu era ţinută să republice diagrama după ce regula opozabilă a fost precizată de două ori. Răspunsurile la solicitările de clarificare fac parte din documentaţia de atribuire şi prevalează asupra unei scheme prezentate ca orientativă. Termenele de verificare de cinci zile şi de remediere de trei zile, prevăzute în Cap. 13 al Caietului de sarcini, se înscriu în termenul fazei respective, nu în afara celor 24 de luni. Ofertantul îşi plasează livrabilele cu anticipaţie faţă de sfârşitul fiecărei faze. Reluarea perioadei de patru săptămâni după un incident de severitate Urgent sau Critic, definită la cap. 6.1 şi reafirmată la întrebarea nr. 129, nu agravează un viciu de informare. Este o condiţie de calitate, anunţată la cap. 5.5.2 şi 5.5.3: recepţia finală presupune patru săptămâni de funcţionare fără incidente majore. Un sistem critic, cu perioadă de garanţie de 36 de luni care curge de la recepţia finală, nu se recepţionează după o lună întreruptă de astfel de incidente. Reluarea de la prima zi este consecinţa firească a cerinţei. Riscul se gestionează prin calitatea livrării şi prin rezerva de timp pe care ofertantul o înscrie în grafic — element evaluat, de altfel, la factorul Pt4. Transformarea acestui risc într-o prelungire automată a celor 24 de luni ar anula condiţia de calitate şi ar transfera asupra Autorităţii consecinţele unei execuţii defectuoase. Calculul contestatoarei, potrivit căruia perioada de stabilitate ar trebui începută în luna 22, este un exerciţiu de planificare al operatorului, nu o contradicţie internă a documentaţiei. Documentaţia fixează momentul până la care perioada trebuie încheiată: sfârşitul lunii 23. Data de la care fiecare ofertant o începe ţine de drumul său critic.” În ceea ce privește răspunsul consolidat nr. 15556/JV/27.08.2026, pct. 137, Consiliul constată că autoritatea contractantă a precizat următoarele: „Întrebarea nr. 137 — Durata efectivă de execuție în cadrul celor 24 de luni Referință: Caiet de sarcini, cap. 9.3 și cap. 10.2 Text vizat: „Se va ține cont și de faptul că ultima lună contractuală este dedicată formalităților legate de plată.” Solicitare: Înțelegem că activitățile tehnice, inclusiv perioada de 4 săptămâni de funcționare fără incidente majore prevăzută la cap. 5.5.3, trebuie finalizate până la sfârșitul lunii 23, ultima lună contractuală fiind rezervată formalităților de plată. Vă rugăm să confirmați această înțelegere sau să precizați interpretarea corectă. Răspuns la întrebarea nr. 137: Se confirmă că toate activitățile tehnice, livrările, testările și perioada de 4 săptămâni de funcționare fără incidente majore trebuie finalizate cel târziu la sfârșitul lunii 23 din graficul de

Pagina 79 din 80 implementare, luna 24 fiind rezervată exclusiv formalităților administrative de recepție finală, facturare și procesare a plății”. Aceste explicații sunt considerate relevante de către Consiliu cu privire la cele reclamate de către petentă, autoritatea contractantă arătând, lipsit de echivoc, că în discuție nu este nicio necorelare, inclusiv clarificările aduse prin răspunsul consolidat nr. 15556/JV/27.08.2026 contribuind la acest rezultat. În condițiile în care aceste explicații i-au fost aduse la cunoștință contestatoarei, lipsa sa de reacție în a le combate poate fi considerată, fără a greși, drept o acceptare a lor, motiv pentru care Consiliul va respinge ca nefondate criticile formulate la acest punct. Luând în considerare aspectele de fapt și de drept mai sus prezentate, în temeiul art. 26 alin. (2) și (5) din Legea nr. 101/2016 privind remediile și căile de atac în materie de atribuire a contractelor de achiziție publică, a contractelor sectoriale şi a contractelor de concesiune de lucrări și concesiune de servicii, precum și pentru organizarea și funcționarea Consiliului Național de Soluționare a Contestațiilor, cu modificările și completările ulterioare, pentru argumentele evocate în motivare, Consiliul va admite, în parte, contestația formulată de către societatea ......... SRL, în contradictoriu cu autoritatea contractantă ........., în sensul că va admite criticile contestatoarei de la pct. C, D.1, D.2 și D.3 din contestație și va obliga autoritatea contractantă ca, în termen de 15 zile de la primirea deciziei Consiliului, cu respectarea prevederilor legale, să remedieze documentația de atribuire în sensul celor stabilite de Consiliu prin motivarea sa, să aducă modificările efectuate la cunoștința operatorilor economici interesați de participarea la procedură prin publicarea acestora în SEAP și, în temeiul art. 155 alin. (2) din HG nr. 395/2016 să stabilească un nou termen de depunere a ofertelor, astfel încât, între data publicării remedierilor și data depunerii ofertelor, să fie asigurată o perioada de timp suficientă pentru elaborarea și prezentarea unor oferte care să respecte toate cerințele documentației de atribuire, astfel cum este modificată ca urmare a prezentei decizii. În baza art. 26 alin. (6) din Legea nr. 101/2016, Consiliul va respinge ca nefondate celelalte criticii, precum și capătul de cerere de anulare a procedurii de atribuire, având în vedere că este posibilă luarea de măsuri de remediere de către autoritatea contractată, cu respectarea principiului art. 2 alin. (2) din Legea nr. 98/2016, procedura fiind suspendată. Pentru aceste motive, în baza legii și a mijloacelor de probă aflate la dosar, CONSILIUL DECIDE: Admite, în parte, contestația depusă de către societatea ......... SRL, în contradictoriu cu autoritatea contractantă ........., în sensul că admite criticile contestatoarei de la pct. C, D.1, D.2 și D.3 din contestație. Obliga autoritatea contractantă ca, în termen de 15 zile de la primirea deciziei Consiliului, cu respectarea prevederilor legale, să remedieze documentația de atribuire în sensul celor stabilite de Consiliu prin motivarea sa, să aducă modificările efectuate la cunoștința operatorilor economici interesați de participarea la procedură prin publicarea acestora în SEAP și, în temeiul art.

Pagina 80 din 80 155 alin. (2) din HG nr. 395/2016 să stabilească un nou termen de depunere a ofertelor, astfel încât, între data publicării remedierilor și data depunerii ofertelor, să fie asigurată o perioada de timp suficientă pentru elaborarea și prezentarea unor oferte care să respecte toate cerințele documentației de atribuire, astfel cum este modificată ca urmare a prezentei decizii. Respinge ca nefondate celelalte critici, inclusiv capătul de cerere de anulare a procedurii de atribuire. Prezenta decizie este obligatorie pentru părți, în conformitate cu dispozițiile art. 28 alin. (1) din Legea nr. 101/2016. Împotriva ei se poate formula plângere, în termen de 10 zile de la comunicare pentru părțile cauzei, respectiv de la data luării la cunoștință de către alte persoane vătămate, în temeiul art. 29 din Legea nr. 101/2016. PREȘEDINTE, MEMBRU, MEMBRU, ... ... ... Redactată practicaua deciziei ... Redactată în 4 exemplare, conține 80 pagini.