Caietul care vorbește o singură limbă

Un caiet de 167 de pagini descrie funcționalitatea unei platforme prin care instituțiile publice își trimit date unele altora. Pe hârtie, cerința e generală: schimb securizat de informații. În text însă, cerința ajunge să conțină nume tehnice care, în 2026, sunt denumiri comerciale ale unui singur producător de baze de date proprietare. Un caiet neutru ar fi cerut funcționalitatea. Acesta cere produsul. Diferența nu e doar tehnică. E juridică. Episodul 01 a arătat contextul și cifrele. Acest episod intră în text, linie cu linie.

Ce spune legea

România nu e liberă să scrie caiete de sarcini cum vrea când banii sunt publici.

Articolul 35 din Legea 98/2016 privind achizițiile publice obligă la neutralitate tehnologică. Specificațiile tehnice nu pot face referire la „o anumită origine, sursă, producție, un procedeu special, o marcă de fabrică sau de comerț, un brevet de invenție, o licență de fabricație”. Există o excepție, dar ea vine cu o condiție strictă: dacă referința devine inevitabilă — pentru că funcționalitatea nu poate fi descrisă altfel — ea trebuie însoțită de mențiunea „sau echivalent”. Lipsa acelor două cuvinte transformă referința într-o restricționare de facto a concurenței.

Regulamentul (UE) 2021/1060 adaugă stratul european. Achizițiile finanțate din Fondul European de Dezvoltare Regională trebuie să respecte principiul valorii pentru bani și concurența pe piața internă. Comisia are instrumentul corecției financiare: reducerea sau anularea plăților când identifică nereguli grave, inclusiv cerințe favorizate fără justificare.

Cadrul european de interoperabilitate (European Interoperability Framework, revizuit în 2017 de Comisie) recomandă explicit standardele deschise. Motivul e simplu: interoperabilitatea înseamnă, prin definiție, că sisteme construite de furnizori diferiți trebuie să vorbească aceeași limbă. Legarea acelei limbi de un singur vendor contrazice chiar scopul declarat al platformei.

Concluzia scurtă: un caiet care cere produse, nu funcționalități, și care omite sistematic formula „sau echivalent funcțional”, pare să contravină acestor norme. Analiza care urmează arată cum.

Surse: Legea 98/2016 art. 35 · Regulamentul (UE) 2021/1060 · European Interoperability Framework (COM 2017/134).

Cinci nume de produs camuflate în cerințe tehnice

Caietul PNI conține, printre cele câteva sute de cerințe tehnice, cinci formulări care se disting de restul prin acest test simplu: există un singur produs pe piață care le îndeplinește direct, în 2026, fără intermediere.

1. BPEL — o cerință care nu are loc într-un ESB

Caietul cere, la componenta de interoperabilitate, suport pentru BPEL (Business Process Execution Language). Formularea pare tehnică neutră. Nu e.

Un ESB — Enterprise Service Bus, componenta centrală a oricărei platforme naționale de interoperabilitate — nu orchestrează procese de afaceri. Rutează mesaje între instituții. Paradigma consacrată pentru asta se numește EIP — Enterprise Integration Patterns (Hohpe & Woolf, 2003): un set de șabloane arhitecturale pentru routing, transformare, filtrare, agregare de mesaje. Toate ESB-urile moderne — WSO2 Micro Integrator, Apache Camel, Red Hat Fuse, MuleSoft — implementează EIP, nu BPEL, și nici nu au nevoie.

BPEL și BPMN 2.0 sunt limbaje de orchestrare de procese de afaceri — utile la sisteme tranzacționale complexe care derulează workflow-uri interne cu stare persistentă. Nu sunt instrumentele corecte pentru un bus de mesaje inter-instituțional. În douăzeci de ani de practică pe platforme de acest tip, autorul acestui dosar nu a avut niciodată nevoie de BPEL sau BPMN pentru orchestrarea traficului între instituții.

Cerința BPEL în caietul PNI nu e, deci, o alegere între două standarde echivalente. E un semnal că cineva a confundat un ESB cu un motor de workflow pentru procese de afaceri. Problema e dublă: pe de o parte, produce o cerință fără utilitate funcțională; pe de altă parte, restricționează ofertanții la singurul furnizor care livrează BPEL nativ într-o suită de produse întreținută activ — producătorul care apare recurent în restul caietului.

2. Directorul de identități legat de producătorul bazei de date

Caietul cere, la componenta de identitate, conector către un produs nominal: directorul LDAP al aceluiași producător care apare pe partea de baze de date. E singurul director LDAP menționat cu nume.

LDAP este standard IETF din 1997 (versiunea 3 — RFC 4511). Orice implementare conformă — OpenLDAP, 389 Directory Server, FreeIPA, Samba AD, Apache DS — vorbește aceeași limbă. Diferența dintre directorul menționat nominal în caiet și oricare alternativă e de formă, nu de conținut: toate expun aceleași operații, aceleași atribute, același protocol.

O formulare neutră ar fi cerut „conector către orice server LDAP v3 compliant (RFC 4511)”. Numirea unui produs specific, fără „sau echivalent”, înseamnă că ofertantul care vine cu un stack deja funcțional pe un alt director LDAP trebuie să demonstreze, în evaluare, că al lui „e la fel” — deși funcțional e la fel prin chiar standardul pe care amândouă îl implementează.

3. Securitate pe etichete — un nume comercial, nu o capabilitate

Caietul cere „restricționare acces pe rânduri cu etichete și politici de securitate” — folosind o formulare care reproduce, aproape literal, numele comercial al unui modul opțional al bazei de date proprietare: Label Security.

Capabilitatea există în cinci baze de date open source și comerciale, sub alt nume. PostgreSQL Row Level Security (RLS) face același lucru din versiunea 9.5 (ianuarie 2016): politici declarative care filtrează rândurile vizibile per utilizator sau per rol. SQL Server o numește tot Row Level Security. MySQL Enterprise are Virtual Private Database. Standardul SQL:2011 conține baza conceptuală în partea de acces condiționat.

Nimic din funcționalitate nu necesită modulul comercial numit în caiet. Cerința scrisă neutru ar fi sunat: „mecanism de control al accesului la nivel de rând, pe bază de atribute sau etichete, cu politici declarative — de exemplu Row Level Security sau echivalent funcțional”. Scrisă cum e, cerința marchează o componentă care se vinde separat, cu licență separată, de către un singur producător.

4. Interogări istorice — o funcție cerută acolo unde nu e nevoie

Caietul cere „interogare directă a datelor la un moment anterior în timp” — formulare care reproduce denumirea comercială a unei funcționalități specifice bazei de date proprietare, numită Flashback Query.

Problema începe mai devreme decât echivalența tehnică. O platformă de interoperabilitate transportă date, nu le stochează. Datele sunt, prin design, la instituția sursă: ANAF are datele fiscale, Casa de Pensii are pensiile, Primăria are registrele ei. Platforma centrală mediază conversația. Ce reține ea sunt log-uri de audit — cine a întrebat ce, când, cu ce rezultat — și configurații de rutare. Nu e sursa de adevăr pentru nicio informație business.

Prin urmare, cerința „interogare istorică a datelor” într-un PNI nu are un caz de utilizare funcțional. Nu ai ce interoga istoric dacă nu stochezi. Singurul sens în care ai nevoie de vedere temporală într-o platformă de acest tip e la log-urile de audit — iar acolo un index clasic pe timestamp, fără sintaxă SQL specială, e suficient.

Dacă totuși lăsăm întrebarea tehnică deoparte și acceptăm, prin absurd, că ar exista o nevoie — funcționalitatea e standard SQL din 2011. Clauza FOR SYSTEM_TIME AS OF face parte din SQL:2011, implementată nativ în PostgreSQL, SQL Server, DB2, MariaDB. O bază de date modernă întreabă „cum arătau datele la 15 martie 2024, ora 10:00” — și răspunde.

Cerința, așa cum e scrisă, combină două probleme într-una: se referă la o capabilitate pe care platforma centrală nu ar trebui să o aibă și o descrie cu numele comercial al unei singure implementări de pe piață.

5. WSRP — un standard mort care cere explicații

Caietul cere, la componenta portal, suport pentru WSRP (Web Services for Remote Portlets). Standardul a fost publicat de OASIS, ultima revizie în 2008. Industria l-a abandonat în anii de după — chiar producătorul dominant al directorului LDAP menționat la punctul 2 a eliminat suportul WSRP din versiunile recente ale propriului portal.

În 2026, nevoia funcțională a dispărut odată cu arhitectura care o justifica: portalurile de tip enterprise portlets au fost înlocuite de aplicații single-page (React, Vue, Angular) care consumă API-uri REST. Nu există un „echivalent modern” al WSRP — nu pentru că standardul ar fi încă viu, ci pentru că nevoia pe care o rezolva s-a evaporat.

Cerința lui într-un caiet din 2026 ridică o singură întrebare: de ce e acolo? Dacă răspunsul e „pentru că face parte din suita de produse a unui anumit producător”, atunci cerința nu descrie o nevoie publică. Descrie un catalog.

Surse: OASIS BPEL 2.0 (2007) · ISO/IEC 19510:2013 (BPMN 2.0) · IETF RFC 4511 (LDAP v3) · PostgreSQL documentation (RLS, versiunea 9.5) · SQL:2011 (ISO/IEC 9075-2:2011) · OASIS WSRP 2.0 (2008).

Ce lipsește: două cuvinte

Formularea juridică salvatoare, în orice caiet de achiziții publice care atinge tehnologii brevetate, are două cuvinte: „sau echivalent”. Uneori e extinsă la „sau echivalent funcțional” — pentru claritate.

Articolul 35 alin. (6) din Legea 98/2016 o impune expres atunci când o cerință tehnică nu poate fi formulată fără referință la o marcă, brevet sau producător. Ea transferă evaluarea de la numele produsului la capabilitatea cerută. Un ofertant poate veni cu orice soluție care îndeplinește funcția, dovedește echivalența, trece filtrul.

În caietul PNI, clauza lipsește sistematic la cele cinci cerințe de mai sus. Absența ei nu e accidentală — e un tipar. În alte locuri din caiet, formulări neutre apar: „sistem de operare Linux sau echivalent”, „bază de date relațională”. Deci autorul știe să folosească formula. Alegerea de a nu o folosi la cerințele-cheie e o decizie, nu o scăpare.

Remediul există, și e cunoscut în procedurile de achiziții: amendament la caietul de sarcini înainte de evaluare, cu introducerea clauzei „sau echivalent funcțional” la fiecare cerință problematică. Dacă evaluarea e deja în curs, instrumentul devine contestația la Consiliul Național de Soluționare a Contestațiilor (CNSC). Precedentele în care CNSC a admis contestații pe Articolul 35 sunt numeroase și publice.

Ce e deja acolo și se pierde

Aici intră experiența directă a autorului acestui dosar.

Mai multe ministere și agenții centrale din România rulează, în producție, stack-uri de integrare construite pe aceeași familie open source pe care Moldova a folosit-o pentru MConnect în 2014 — WSO2. Am oferit, profesional, suport tehnic pentru Trencadis, integrator român, fost partener regional WSO2, pe implementări în administrația publică românească. Lista exactă a instituțiilor nu e subiectul acestui episod. Existența stack-ului e.

Faptul e important pentru că schimbă calculul bugetar. Cerințele vendor-specific din caietul PNI nu elimină doar concurența pe piață — elimină migrarea naturală de la ce există deja în producție. Un PNI construit pe tehnologia unui singur producător cere, de la fiecare instituție deja conectată, refacerea conectorilor — nu doar extinderea lor. Echipele IT care operează azi WSO2 în acele instituții ar trebui re-antrenate pe stack-ul nou. Licențele deja cumpărate pentru infrastructura existentă își pierd valoarea.

Cost dublu: licențe noi pentru produse proprietare plus rescrierea integrărilor existente. Timp dublu: integrările existente se refac, nu se reutilizează. Risc triplu: orice întrerupere în instituțiile deja conectate e generată nu de platforma nouă, ci de migrarea forțată de la cea veche.

Un caiet scris neutru ar fi lăsat această opțiune deschisă. Un PNI construit pe standarde deschise — LDAP v3, BPMN 2.0, RLS SQL standard, SQL:2011 temporal — ar fi putut absorbi stack-ul existent, nu să-l înlocuiască. Caietul actual nu permite asta.

Întrebarea care urmează

Cinci cerințe. Zero clauze „sau echivalent”. Un singur furnizor care livrează nativ toate cele cinci, într-o suită unică de produse. Un stack open source deja în producție în administrația publică românească, pe care noile cerințe îl fac incompatibil prin construcție.

Cifra din Episodul 01 — 33 de milioane de euro — nu vine din costul real al funcționalității. Vine din costul unei funcționalități livrate doar de un anumit producător, într-un caiet scris astfel încât concurența să nu poată intra.

Și dacă restricționarea vendorilor era doar primul strat? Hardware-ul cerut — 256 GB de RAM pe fiecare nod al componentei centrale, pentru o platformă care rutează mesaje, nu calculează matrici științifice — ridică un al doilea val de întrebări. Aritmetica supradimensionării, și bugetul care crește exponențial din ea, urmează în Episodul 03.

Surse: Legea 98/2016 art. 35 · Regulamentul (UE) 2021/1060 · OASIS (BPEL, WSRP) · ISO/IEC 19510:2013 · IETF RFC 4511 · ISO/IEC 9075-2:2011 (SQL:2011) · PostgreSQL documentation.