Două platforme aproape identice, un singur stat

PDURo e gata. Beta lansat în martie 2026. Rulează în Cloud Guvernamental, infrastructură deja plătită de statul român cu peste 2,8 miliarde de lei. Episodul anterior a arătat că la nivelul caietelor de sarcini, PDURo și PNI sunt aproximativ 78% identice literal pe componenta de interoperabilitate.

PNI era anulat pe 15 mai 2026. Caietul cerea hardware separat, hyper-convergent, instalat tot la STS, dar în paralel cu cel deja folosit pentru PDURo. Și cerea, paragraf cu paragraf, cam aceleași componente.

Articolul nu propune o nouă arhitectură pentru PNI. Am scris deja despre asta (în episodul 8). Articolul de față pune o singură întrebare: ce ar fi rezultat efectiv din această decizie, în cifre și în utilitate, pe an, pe spinarea aceluiași stat?

Cifrele cheie

Element	Valoare
Buget atribuit PDURo (2023)	96,92 mil. lei fără TVA
Buget prevăzut PNI (anulat 2026)	164,4 mil. lei cu TVA
Identitate literală a caietelor	aproximativ 78% pe componenta de interoperabilitate
Investiție națională în Cloud Guvernamental	peste 2,8 miliarde de lei (PNRR Componenta C7 Investiția 1)
Datacentere Cloud Guvernamental	4 (București, Brașov, Sibiu, Timiș)
Sisteme IT publice planificate să migreze în Cloud	30+ până la finalul 2025
KPI declarat în HG noiembrie 2025	1 instituție beneficiară, 2 consumatoare, 15 registre conectate, ~163.000 accesări/an

Două platforme, aceleași componente

Atât caietul PDURo (livrat), cât și caietul PNI (anulat) descriu un set comun de componente arhitecturale obligatorii: un portal, un Single Sign-On cu federation SAML, un API Gateway, un motor de orchestrare procese, un Identity Manager, un Document Library, monitorizare operațională. Aceleași produse comerciale enterprise menționate ca acceptate în ambele documente. Aceleași standarde tehnice cerute. Aceleași denumiri. Practic, același paragraf.

Diferențele țin de scope: PDURo are în plus migrarea vechiului PCUe și Once-Only Technical System pentru cross-border SDG. PNI ar fi avut în plus Registrul Național al Registrelor și Catalogul Național Semantic, ambele cerute explicit de Legea 242/2022.

Și încă o diferență, care nu e tehnică: infrastructura.

PDURo a fost cumpărat ca software pe Cloud Guvernamental. Caietul declară explicit că infrastructura hardware nu intră în scopul contractului; vine din alt proiect, finanțat tot din PNRR. PNI cerea hardware propriu hyper-convergent, cel puțin 8 noduri identice cu procesoare Intel Xeon generația a cincea, 1.024 GB DDR5 ECC fiecare, instalat la centrul de date STS din Cristian, Brașov.

Adică, în paralel cu Cloud Guvernamental care e construit explicit ca platformă comună pentru sisteme IT publice, PNI ar fi avut propriul mini-cluster, separat, în același centru de date.

Cost anual pe spinarea statului

Costul unei astfel de platforme nu se termină când se semnează acceptanța. Începe atunci. Toate componentele enterprise majore ascunse în caiet au costuri recurente fixe:

• Licențiere și mentenanță produse enterprise comerciale (motor SOA, API Gateway, Identity Management, Single Sign-On, portal, baze de date). Tipic 20-22% din valoarea licențierii pe an, conform contractelor standard ale vendorilor.
• Echipa operațională pentru un astfel de sistem: minimum 10-15 specialiști permanenți, cu profile rare pe piața românească (administratori de motor SOA enterprise, specialiști federation SAML, administratori Identity Manager, ingineri Java enterprise).
• Infrastructură: pentru hardware propriu, energie + cooling + refresh la 5 ani + redundanță geografică + business continuity. Pentru variantă cloud, doar consum.

Estimare profesională, cu cifre la prețuri de listă vendor, înainte de discount enterprise: 7-13 milioane de lei pe an pentru o platformă de tipul PDURo, 8-15 milioane pe an pentru o platformă de tipul PNI cu hardware propriu.

În scenariul în care ambele platforme ar fi mers paralel:

15-28 milioane de lei pe an, pe perioada de garanție și după garanție, pentru cele două platforme luate împreună.

Pentru context, garanția software cerută în caietul PDURo era de 60 de luni de la acceptanța finală. Caietul PNI prevedea sustenabilitate minim 5 ani post-implementare, plus minim 3 ani suport plin după. Adică, în zona unui deceniu, statul plătea pentru două platforme aproape identice de tipul ăsta cumulat probabil între 150 și 280 de milioane de lei doar în operare, peste investiția inițială cumulată.

Cu cifrele astea, ce primește cetățeanul?

Indicatorii oficiali RCO14 și RCR11 din nota de fundamentare a HG noiembrie 2025 declară pentru PNI ținta de o singură instituție beneficiară, două instituții care utilizează platforma pentru accesarea datelor, cincisprezece registre conectate și aproximativ 163.000 accesări/an (RCR11 măsoară interacțiuni cu servicii digitale, nu cetățeni unici). Pentru un buget total de 164,4 milioane de lei și un cost recurent estimat de 8-15 milioane pe an.

PDURo, la zece săptămâni după lansarea Beta, declară 21 de proceduri online disponibile cross-border, dintre câteva mii descrise în portofoliul Single Digital Gateway. Cifrele exacte de utilizare publică (cetățeni unici, tranzacții pe lună) nu sunt raportate public la momentul redactării.

Întrebarea care rămâne deschisă: două platforme care, împreună, costă 15-28 milioane de lei pe an de operare, deservesc câți cetățeni efectiv, în câte interacțiuni efective cu administrația, cu câte sarcini birocratice efectiv reduse?

Cadrul legal european: reutilizarea, nu construirea

Regulamentul (UE) 2024/903 privind interoperabilitatea sectorului public european (Interoperable Europe Act), aplicabil integral din 12 iulie 2024, încurajează reutilizarea soluțiilor existente. Articolul 3, aplicabil din 12 ianuarie 2025, impune EVALUARE OBLIGATORIE înainte de orice cerință tehnică nouă, cu identificarea soluțiilor Interoperable Europe deja existente și justificare publică dacă acestea nu sunt reutilizate. Raportul de evaluare se publică pe Interoperable Europe Portal.

Regulamentul nu prevede sancțiuni directe pentru nerespectare. Mecanismele indirecte sunt mai blânde și mai lente: condiționalitate fonduri UE, reclamații private ale operatorilor economici către Comisia Europeană, monitorizare prin Interoperable Europe Board. Asta nu înseamnă că obligația nu există. Înseamnă doar că rolul de a o respecta intră în responsabilitatea autorității contractante înainte de a publica caietul. Nu după.

În cazul PNI, caietul a fost publicat pe 6 februarie 2026, ulterior datei de aplicabilitate a articolului 3. PDURo era atribuit din 2023, în implementare publică din martie 2026. Un raport de evaluare a interoperabilității care identifica PDURo ca soluție existentă, evalua reutilizarea și justifica decizia de a construi un sistem nou ar fi fost obligatoriu. Documentul nu apare pe Interoperable Europe Portal la data redactării.

Cadrul legal național: dubla finanțare

Pe partea românească, OUG 66/2011 privind prevenirea, constatarea și sancționarea neregulilor apărute în obținerea și utilizarea fondurilor europene reglementează situațiile de dublă finanțare. Definiția neregulii e largă: include atât duplicarea cheltuielilor pe aceeași investiție din fonduri diferite, cât și abateri de la principiul bunei gestiuni financiare. Sancțiunile sunt corecții financiare prin grila MFE, recuperarea sumelor și raportare la Comisia Europeană.

Dubla finanțare se aplică strict când e vorba de aceeași investiție cu același scop. PNI și PDURo au scopuri formal diferite: PDURo e portalul cetățeanului către serviciile publice digitale (Single Digital Gateway național), PNI e platforma de interoperabilitate între instituții (transport date G2G). Componentele tehnice cerute însă sunt majoritar comune. Întrebarea procedurală e legitimă, fără a fi automatizat un caz de aplicare a OUG 66.

Cele două cadre legale, european și național, conduc spre aceeași concluzie practică: orice autoritate contractantă care lansează o procedură pentru un sistem cu componente esențial identice cu un sistem deja contractat și implementat are obligația documentată să publice argumentarea înainte de a publica caietul. Nu este suficient să existe scopuri declarate diferite. Componenta tehnică contează.

Unde ar fi putut ajunge banii

Magistrala nu prescrie aici o nouă arhitectură pentru PNI. Episodul 8 a făcut deja asta. Ce facem acum e o observație simplă: o platformă de interoperabilitate nu produce interoperabilitate prin ea însăși. Produce interoperabilitate doar dacă sistemele instituționale care există deja sunt modificate să comunice unele cu altele.

În clipa în care un cetățean cere un certificat fiscal de la ANAF pentru o procedură la MJ, interoperabilitatea reală e ca sistemul ANAF să expună un serviciu standard pe care MJ să-l poată consuma direct. Nu ca un orchestrator central să întrebe ANAF, să primească un răspuns proprietar, să-l transforme, să-l ducă la MJ printr-un alt format proprietar.

Asta înseamnă investiție în furnizorii sistemelor existente, nu în construcția unei platforme noi pe deasupra. Furnizorul SIPCEP de la ANAF, furnizorul ECRIS de la MJ, furnizorii aplicațiilor CNAS, furnizorii aplicațiilor ANCPI, furnizorii aplicațiilor MAI: fiecare are nevoie de ChangeRequests punctuale, scope-uri finite, cu cerințe aliniate la standardele europene (Core Vocabularies UE, eIDAS, eDelivery AS4) ca să expună servicii predefinite. Majoritatea instituțiilor au mai multe sisteme, nu un singur sistem, ceea ce înseamnă că investiția se distribuie pe portofoliu, nu pe un singur furnizor.

Pe direcția platformă centralizată, banii se duc spre licențiere recurentă vendor enterprise, hardware nou, echipă specializată pe stack rar, refresh de infrastructură la cinci ani. Cetățeanul primește acces indirect, prin orchestrare la mijloc, fără ca sistemele instituționale să se schimbe substanțial.

Pe direcția investiție în sisteme existente, banii se duc spre ChangeRequests finite la furnizorii actuali. Costul e majoritar punctual, nu recurent. Sistemele instituționale devin interoperabile la sursă. Extinderea la noi servicii nu cere platformă centralizată nouă, cere doar alt ChangeRequest la sistemul vizat. Cetățeanul primește acces direct, prin canalele care există deja: portalul PDURo pentru cross-border SDG, portalurile instituționale pentru servicii sectoriale, ghișeele online ale ANAF, CNAS, ONRC, ANCPI.

În cifre, o direcție produce cost recurent de 8-15 milioane de lei pe an, indefinit. Cealaltă produce investiție inițială distribuită pe furnizorii actuali, cu cost recurent mult redus, pentru că nu adaugă o nouă platformă enterprise în peisaj.

Care dintre cele două direcții servește mai bine principiul declarat al Regulamentului (UE) 2024/903 (reutilizare) și principiul declarat al strategiei Cloud Guvernamental (mutarea aplicațiilor instituționale în cloud comun)?

Cum am ajuns la concluziile astea

Magistrala a făcut o investigație pe baza informațiilor publice. Am cercetat documentele de licitație disponibile pe e-licitatie.ro, am răsfoit anunțurile oficiale ADR, am consultat sursele publice care documentează atribuirea contractului PDURo, am navigat pe portalul public roepas.ro și am consultat resurse standard de transparență care listează site-urile publice ale unei autorități contractante. Toate metodele sunt non-intruzive: niciun test de penetrare, nicio autentificare, nicio interacțiune care depășește comportamentul unui vizitator obișnuit al unui portal public.

Pe baza acestor surse publice, am identificat cu un grad de siguranță de aproximativ 90% componentele majore ale stack-ului ROePAS:

• Portalul public e construit pe Liferay DXP (ediție comercială licențiată, confirmat prin referința EULA din răspunsul HTML)
• Gateway-ul API e Broadcom Layer7 API Gateway (confirmat prin semnătura proprie a produsului afișată în răspunsurile platformei)
• Single Sign-On e CA/Symantec SiteMinder (confirmat prin pagina default afișată public și prin pattern-urile de URL ale produsului)
• Motorul de orchestrare e Oracle SOA Suite enterprise complet (confirmat prin endpoint-urile canonice publice ale platformei și prin pattern-urile de routing standard al produsului)
• Chatbot-ul livrat de Wisevoice AI rulează pe Rasa Open Source (confirmat prin pattern-ul de API expus public)
• Repository-ul de build artifacts e Sonatype Nexus Community 3.83.1-03 (versiune declarată direct de produs în răspunsul public)
• Infrastructura e găzduită pe Cloud Guvernamental STS, prin CDN Azure Front Door în față

Componentele rămase (un Identity Manager separat, un subsistem de gestiune a accesului auxiliar, eventual o platformă de logging/analiză tip Elasticsearch sau OpenSearch în spate) nu sunt identificabile cu certitudine din public. Pentru fiecare avem o ipoteză suficient de solidă, dar fără confirmare directă.

Aici intervine o observație care merită menționată: pentru o platformă națională de această amploare, cu vizibilitate la nivel european prin Single Digital Gateway, Oracle nu publică PDURo în portofoliul lor de referințe enterprise. Nici în pagina Oracle Customer Success Stories. Nici în studiile de caz Oracle SOA Suite. Nici în comunicatele româneşti ale Oracle România. Broadcom, similar, nu listează PDURo în paginile Layer7 Success sau SiteMinder Customer References.

Pentru comparație, WSO2 își laudă explicit implementarea platformei naționale de interoperabilitate din Republica Moldova (MConnect) ca studiu de caz public, prezent pe site-ul oficial și menționat în prezentări la conferințe. WSO2 listează la fel și alte implementări guvernamentale, în Sri Lanka, Nigeria, Wales. Vendorii open source și enterprise non-Oracle prezintă astfel de proiecte ca puncte forte de portofoliu. Vendorii din stack-ul ROePAS, deși proiectul are vizibilitate publică prin Beta lansat, nu fac același lucru.

Asta poate avea mai multe explicații, dar discreția vendorilor merită o întrebare publică: dacă PDURo e un proiect de referință, de ce nu apare în portofoliul celor care l-au livrat?

Cine câștigă oricum

Stack-ul identificat ridică o întrebare de aritmetică simplă: cine ia cea mai mare felie din bugetul cumulat al celor două proiecte.

La prețuri de listă, doar pentru cele patru componente Oracle (SOA Suite cu cluster 16 cores, Database Enterprise Edition, Identity Manager, Access Manager) plus cele două Broadcom (Layer7 API Gateway, SiteMinder), licențierea inițială estimată e de aproximativ 12-13 milioane de lei per proiect. Mentenanța vendor de 22% pe an, pe 5 ani de sustenabilitate cerută în caiete, urcă cifra la 25-27 milioane de lei per proiect. Plus serviciile de implementare pentru care e nevoie de specialiști certificați vendor (Oracle Premier Partner, Broadcom certified consultants), încă 15-25% din buget.

Cu discount enterprise maxim agresiv (în jur de 30% e plafonul practic Oracle în contracte guvernamentale, pentru că discount-uri mai mari cer aprobare specială și nu sunt rutină), licențiere plus mentenanță plus servicii vendor pe 5 ani ajunge la aproximativ 20-25 milioane de lei per proiect, doar către Oracle și Broadcom. Pentru două proiecte cu același stack, cumulat: 40-50 milioane de lei către aceiași doi vendori, indiferent de cine e integratorul român.

Ipoteza care merită formulată: caietul PNI, fiind aproape identic cu caietul PDURo, oferea consorțiului Oracle deja câștigător două șanse. Fie confirmarea unui al doilea contract și recuperarea pierderilor din întârzierea de aproximativ 11 luni a livrării PDURo (Beta lansat martie 2026 față de termenul contractual de 18 luni din iulie 2023). Fie, dacă licitația PNI era câștigată de un alt consorțiu, schimbarea integratorului ar fi adus, eventual, expertiză externă utilă în finalizarea PDURo prin colaborare între furnizori. În oricare dintre cele două scenarii, licențele rămâneau aceleași. Stack-ul cerut limita drastic câmpul ofertanților eligibili și asigura că Oracle și Broadcom apăreau în fiecare ofertă, indiferent de lider.

Aici e o întrebare la care nu prea găsim un răspuns convingător. Dacă ai fi un integrator român (Maguay, Vodafone, Phoenix IT sau oricare altul de pe lista ofertanților PNI), de ce ai milita pentru un caiet care impune un stack enterprise greu, dacă știi că pentru aceeași bucată de buget licența ajunge oricum la Oracle și Broadcom? Marja integratorului român e ce rămâne după ce vendorii americani își iau partea. La un caiet cu cerințe mai deschise (componente open source acceptate explicit, sau alternative comerciale mai diverse), câștigătorul ar fi putut alege un stack mai ieftin pe licențe, lăsând mai mult în partea de servicii, adică în partea integratorului. Cu stack-ul ales, partea integratorului român e fragmentată între câțiva parteneri în consorțiu, iar partea vendorilor americani e concentrată și sigură.

E o întrebare la care, ne facem că nu înțelegem, nu reușim să găsim un răspuns rezonabil.

Întrebări care merită răspuns public

1. Existența raportului art. 3 IEA: există documentat, înainte de publicarea caietului PNI pe 6 februarie 2026, un raport de evaluare a interoperabilității care identifica PDURo ca soluție existentă și justifica decizia de a construi un sistem nou? Dacă da, unde e publicat pe Interoperable Europe Portal?

2. Decizia hardware propriu vs Cloud Guvernamental: care a fost argumentația tehnică sau economică pentru cerința de hardware separat hyper-convergent în caietul PNI, dat fiind că statul investise deja peste 2,8 miliarde de lei în Cloud Guvernamental?

3. Costul anual cumulat declarat: care e costul anual de operare estimat pentru PDURo în ofertă tehnico-financiară (post-garanție)? Care era costul anual estimat pentru PNI dacă procedura nu era anulată? Suma cumulată pe perioada minimă de sustenabilitate (5-7 ani) e publicabilă?

4. Utilitatea reală: pentru PDURo în Beta, câți cetățeni unici au accesat platforma în primele zece săptămâni? Câte proceduri au fost finalizate efectiv? Pentru PNI, ținta KPI declarată în HG (2 instituții consumatoare) e suficientă pentru un buget de 164,4 milioane? Magistrala intenționează o solicitare formală conform Legii 544/2001 către ADR pentru cifrele de utilizare reală ale ROePAS și pentru raportările PNRR aferente. Răspunsul, când va veni, va fi publicat.

5. Bani bugetați pentru adaptarea sistemelor existente: există în portofoliul PNRR sau în bugetul ADR sume alocate explicit pentru ca furnizorii actuali ai sistemelor publice să expună servicii interoperabile? Concret, există o linie bugetară pentru ChangeRequest la sistemul SIPCEP al ANAF, prin care să se publice un serviciu standard de tip „verificare cazier fiscal pe baza de CNP, conform vocabularului Core Person UE”, consumabil direct de alte instituții? Sau pentru ECRIS la MJ, prin care „cazier judiciar redus” devine apel direct API? Acestea sunt exemple concrete de investiție unde rezultatul e verificabil într-un an, nu peste cinci.

6. Migrare sisteme în Cloud Guvernamental: PNI a fost luat în considerare ca extensie a Cloud Guvernamental deja construit, în loc de proiect cu hardware separat? Dacă da, decizia de separare e documentată public?

Ce poate face un cititor

Documentele oficiale sunt publice. Anunțul PDURo pe e-licitatie.ro conține link la documentația completă. Nota de fundamentare HG PNI e accesibilă pe arhiva consultării publice. Portalul ROePAS în versiune Beta poate fi accesat la roepas.ro. Detaliile despre Cloud Guvernamental sunt pe pagina oficială ADR.

Atât pentru astăzi.

---

Surse consultate:

• Caiet de sarcini PDURo, anunț e-licitatie.ro nr. 100454961, document nr. 367/IICG-PNRR/13.07.2023
• Caiet de sarcini PNI, document nr. 13PNI/06.02.2026, procedură SMIS 333977 anulată pe 15 mai 2026
• Nota de fundamentare HG PNI, rev. 21 noiembrie 2025
• Cloud Guvernamental România, comunicat oficial ADR, Investiția 1 PNRR Componenta 7, valoare 1,866 miliarde de lei plus componente complementare cumulând peste 560 milioane de euro
• Regulamentul (UE) 2024/903 (Interoperable Europe Act), articolul 3, aplicabil din 12 ianuarie 2025
• OUG 66/2011 privind prevenirea, constatarea și sancționarea neregulilor în utilizarea fondurilor europene
• Legea 242/2022 privind schimbul de date și crearea Platformei Naționale de Interoperabilitate