Cum se construiește PNI corect

Anularea licitației deschide o fereastră, dar nu garantează că platforma va fi reluată bine. Calea corectă cere două sisteme de fundație, livrate incremental, pe parcursul a mai multor ani. Le-am construit în Republica Moldova în 2014. Aici e arhitectura, componentă cu componentă, cu cifrele realiste pentru România.

Două sisteme, două straturi

PNI nu se construiește ca o aplicație monolitică livrată la cheie după 36 de luni. Se construiește ca două sisteme de fundație, peste care, ulterior, se așază restul.

Stratul 1: sistemul central de audit al accesărilor. Fiecare interogare a unui funcționar public asupra datelor unui cetățean trebuie să lase urmă verificabilă: cine a întrebat, ce date, când, pentru ce proces de business, cu ce temei legal. Acesta e mecanismul prin care opacitatea birocratică devine transparență civică. În Republica Moldova, sistemul ăsta se numește MLog și l-am livrat în 2014. Funcționează și astăzi.

Stratul 2: registrul central de servicii. Funcționarul public dintr-o instituție trebuie să poată interoga date despre un cetățean din alte instituții, fără să cunoască sistemele-sursă. Registrul e harta: ce servicii expun ce instituții, cum se cheamă, ce parametri primesc, ce întorc. Funcționarul completează un formular pe ecran, registrul construiește cererea corect și o livrează la instituția care deține datele. În Republica Moldova, sistemul ăsta se numește MAccess; l-am proiectat în 2014, dar n-a fost finalizat acolo. Designul tehnic există însă, complet.

Aceste două straturi vin întâi. PNI propriu-zis (automatizarea schimbului de date între sisteme, fără intervenție umană) vine la urmă, după ce stratele 1 și 2 sunt în producție și au validat ipotezele.

Stratul 1: sistemul central de audit (MLog, Republica Moldova 2014)

Ce rezolvă

Orice acces la datele unui cetățean, de la verificarea cazierului fiscal până la consultarea istoricului medical, generează un eveniment de log centralizat. Cetățeanul are dreptul, prin GDPR și prin Constituție, să vadă cine i-a accesat datele, când, și pentru ce. Sistemul de audit oferă infrastructura tehnică pentru acest drept.

Arhitectura

Stack-ul folosit în Moldova în 2014, validat în 12 ani de producție:

• Nginx la intrare: reverse proxy cu mTLS. Identitatea instituției care trimite log-uri se extrage din certificatul digital, nu din payload. Instituția nu se poate impersona.
• Receptor sincron (pool Java): primește mesajul, validează formatul, generează ID unic, publică în coadă, răspunde imediat instituției cu ACK. Debit mare, latență mică.
• Apache ActiveMQ cluster master/slave: coadă persistentă. Dacă instanțele de procesare cad, mesajele nu se pierd; se acumulează în coadă până se restabilește serviciul.
• Procesor asincron (pool Java): consumă din coadă, validează semnătura digitală a evenimentului (dacă există), scrie în index.
• Elasticsearch cluster: registrul de jurnalizare. Index per instituție per zi calendaristică, izolare strictă (o instituție nu vede log-urile alteia), retenție administrabilă.
• Serviciu de extragere (Java + ESB): interogări cu filtre și paginare pentru rapoarte.

Hardware minim pentru High Availability: 7 noduri Linux modeste (2-4 vCPU, 8 GB RAM, 20 GB disc per nod). Total memorie pentru tot sistemul: sub 50 GB, nu „256 GB per nod” cum cere caietul anulat.

Stack-ul din 2014 nu e obligatoriu, e ilustrativ. Cerințele arhitecturale rămân (separare sincron/asincron, buffer persistent între ele, audit complet, izolare per instituție, autentificare la edge). În 2026, implementarea în România poate folosi tehnologii moderne care respectă aceleași cerințe: Apache Kafka în loc de ActiveMQ (standard matur pentru fluxuri de evenimente, ecosistem bogat), OpenSearch (fork Amazon) sau MeiliSearch în loc de Elasticsearch (care din 2021 are licență restrictivă), Java 21 (LTS) în loc de Java 8, PostgreSQL în loc de MSSQL proprietar, ROeID/eIDAS în loc de MPass moldovenesc. Republica Moldova însăși și-a modernizat probabil MLog pe Kafka între timp. Important nu e tehnologia exactă, ci respectarea principiilor arhitecturale și a cerințelor declarate public de ministru: soluții deschise, sustenabile, cu costuri de scalare previzibile.

Schema unui mesaj de log

Standard, simplu, suficient pentru orice tip de eveniment de acces la date:

{
  "event_type": "ANAF.CazierFiscal.Consultat",
  "event_time": "2026-05-18T14:32:11Z",
  "source": "primarie-cluj-napoca-app1",
  "service": "consultare-cazier-fiscal",
  "user": "ion.popescu@primariacluj.ro",
  "subject": "CNP-functionar-hash",
  "object": "CNP-cetatean-investigat",
  "action": "READ",
  "process": "verificare-eligibilitate-ajutor-social",
  "tranzaction": "uuid-corelație-proces-business",
  "status": "SUCCESS"
}

16 câmpuri în total. Standardizate prin Hotărâre de Guvern, devin lingua franca pentru toate sistemele publice. Orice instituție care expune un serviciu prin PNI generează evenimente în acest format. Orice instituție care interoghează, la fel.

Dimensiunea civică: instrument constituțional

Aici e diferența între un sistem tehnic de audit și un instrument constituțional de control civic. Cetățeanul intră în portalul personal (echivalentul ghiseul.ro pentru identitate), se autentifică cu ROeID, și vede:

• Lista cronologică a instituțiilor care i-au accesat datele în ultimele 12 luni
• Pentru fiecare acces: cine (instituția + funcționarul, prin rol nu prin nume, pentru protecția funcționarului), ce date (categorie: financiar / medical / educație / etc.), când (timestamp), pentru ce proces (calcul pensie, verificare eligibilitate, control fiscal, etc.)
• Drept de plângere automată: dacă un acces pare nelegitim, cetățeanul îl raportează la ANSPDCP (Autoritatea de Protecție a Datelor) cu un click. Investigația pleacă de la log, nu de la suspiciune.

În Republica Moldova, mecanismul ăsta funcționează prin Cabinetul personal al MPass (echivalentul ROeID românesc). În România ar trebui livrat ca extensie naturală a ROeID: un buton nou în interfața deja existentă, peste registrul central de audit.

Stratul 2: registrul central de servicii (MAccess, Republica Moldova 2014, design)

Ce rezolvă

În România avem peste 3.000 de instituții publice, fiecare cu sisteme legacy diferite, dezvoltate de furnizori diferiți (Siveco, TeamNet, Maguay și alții), pe tehnologii diferite (Oracle, MSSQL, fișiere, dosare cu șină). Un funcționar de la Primăria Cluj nu poate interoga ANAF-ul direct fără să cunoască sistemul ANAF, fără credențiale specifice, fără protocoale specifice.

Registrul rezolvă asta în trei pași: (1) fiecare instituție expune un set fix de servicii standardizate prin conectori instalați local; (2) conectorii înregistrează serviciile la un registru central; (3) registrul oferă funcționarilor publici o interfață uniformă: formular pe ecran, completezi, primești răspunsul, fără să știi pe ce tehnologie rulează instituția-sursă.

Arhitectura

• Conector instituțional: instalat la fiecare instituție, lângă sistemele legacy. Folosește o componentă open source matură ca WSO2 Data Services Server sau echivalent, cu adaptoare JDBC / JMS / REST către sursele de date. Expune servicii standardizate, autentificate cu certificate digitale, criptate.
• Registru central: bază de date cu cataloagele de servicii ale tuturor instituțiilor: nume serviciu, parametri, response, instituția care îl furnizează, drepturi de acces.
• Front-end pentru funcționari: aplicație web (stack modern Node.js sau echivalent). Funcționarul caută serviciul, vede formularul auto-generat din specificația OpenAPI, completează, primește răspunsul structurat.
• Auth & Authz: autentificare prin ROeID (SSO instituțional). Autorizare pe baza rolului funcționarului și a contextului procesului de business.
• Jurnalizare obligatorie: orice request prin registru trece prin sistemul de audit (Stratul 1). Fără excepții.

Onboarding-ul unei instituții

În practică, pașii pentru a aduce o instituție nouă pe platformă:

1. Inventar: echipa tehnică PNI merge la instituție (ex: ANAF) și identifică ce date îi cer alte instituții (cazier fiscal, dovadă venituri, datorii bugetare etc.).
2. Design conector: pentru fiecare serviciu, se proiectează interfața standardizată: ce parametri primește, ce întoarce, ce drepturi sunt necesare.
3. Implementare conector: WSO2 DSS sau echivalent, configurat cu adaptoare către sistemele legacy (JDBC către Oracle, JMS către cozile interne, REST către API-urile noi). Implementarea nu cere modificări în legacy, doar acces de citire.
4. Înregistrare în registru: serviciile noi sunt înregistrate cu specificația OpenAPI. Devin vizibile pentru funcționarii autorizați.
5. Testare cu utilizatori reali: un grup pilot de funcționari începe să folosească serviciile. Erori, performanță, ergonomie — corecții iterative.

Timpul realist per instituție: 3-9 luni, în funcție de complexitatea legacy-ului și de cooperarea furnizorului original. Pentru instituțiile mari (ANAF, Casa de Pensii, MAI), poate mai mult; pentru cele mici (primării rurale), mult mai puțin.

Cum se face în România, incremental

Primele rezultate rapide: instituțiile cu WSO2 deja achiziționat

Înainte de a cumpăra orice altceva, statul trebuie să facă inventarul a ceea ce există deja. Mai multe instituții centrale au licențe WSO2 ESB achiziționate, în diferite stadii de utilizare: Ministerul Justiției, ANRE (Autoritatea Națională de Reglementare în Energie), Registrul Comerțului, Ministerul Educației (sistemul SIIR). Toate au fost cumpărate prin contracte separate, în momente diferite, la prețuri diferite, cu termeni diferiți.

Două acțiuni paralele, ambele cu impact direct:

1. Inventar guvernamental complet: ce instituții au WSO2, perioada de valabilitate a licențelor și a suportului, dacă softul e efectiv folosit sau doar pe raft, ce competențe tehnice există în echipele interne.
2. Renegociere unitară a licențelor la nivel guvernamental, nu instituție-cu-instituție. Volume mai mari = preț mai bun. Termeni unitari = predictibilitate. Aliniere a valabilităților = planificare strategică reală. Asta e ce ar trebui să facă MEDAT sau Cancelaria Primului-Ministru, nu fiecare instituție în parte.

Beneficiu politic imediat: zero buget suplimentar. Beneficiu tehnic real: 4 instituții pot deveni primele rezultate rapide pentru PNI în 6-12 luni — primii conectori funcționali, primele servicii înregistrate în registru.

După primele rezultate: extindere progresivă

Cu 4 instituții funcționale, tiparul devine cunoscut: ce durează, ce costă, ce drepturi sunt necesare, ce probleme apar. De aici, extinderea se face în valuri.

Ritm realist pentru primii ani: 50-100 de instituții pe an. Pentru cele 3.000 de instituții publice românești, asta înseamnă un calendar de 30-60 de ani la viteza inițială. Ritmul crește însă pe măsură ce echipele se rodează, conectorii se standardizează și instituțiile noi le copiază pe cele deja integrate. Realist: 10-15 ani pentru acoperire substanțială.

Pentru context comparativ:

• Republica Moldova, în primii 8-9 ani de MConnect (2014-2023): aproximativ 100 de instituții conectate.
• Ucraina, pe Trembita, în mai mulți ani: aproximativ 500 de instituții.
• Caietul anulat al PNI: 3.000 de instituții în 24 de luni. Nesusținut de nicio experiență internațională comparabilă.

De ce e politic, nu tehnic

Componentele tehnice există. Stack-ul e validat. Cifrele sunt cunoscute. Modelul funcționează în țări vecine. Atunci de ce e greu?

Pentru că opoziția vine din patru direcții care se susțin reciproc:

1. Instituțiile nu vor să facă efortul de integrare. Asta înseamnă inventarul propriilor date, expunerea lor, drepturi de acces clare, audit transparent. Mulți funcționari preferă status-quo-ul birocratic.
2. Furnizorii originali ai sistemelor legacy (Siveco, UTI Grup, Trencadis, Maguay, Indeco Soft, Romsys, S&T Romania, Net Brinel și alți contractori cu prezență publică recunoscută în registrele SEAP/SICAP) au interes contractual să nu se schimbe arhitectura. Modificările cerute pentru conectori presupun fie bani mulți (consultanță, personalizare), fie consimțământ, fie acces la cod: toate trei sunt obstacole.
3. Costul percepției: fără înțelegerea valorii incrementale, statul cere bugete uriașe „pentru tot odată” și apoi nu primește banii, sau îi primește cu condiționări politice. Modelul incremental, cu cifre realiste, e politic neatractiv: nu produce tăieturi de panglică.
4. Politica transparenței, și aici e cauza cea mai adâncă. Un sistem de audit funcțional arată exact ce s-a întâmplat: cine a interogat datele cui, când, pentru ce. Asta poate produce probleme pentru decidenții care preferă opacitatea.

Mărturia directă a celei care a făcut-o în Republica Moldova, Nicoleta Colomeeț (șefa Agenției de Guvernare Electronică), citată de jurnalistul independent Vitalie Cojocari într-o vizită recentă la Chișinău:

„Au dus lupte seculare ca să convingă diferite instituții să-și dea datele pentru a le integra în Cloud. […] Transparența arată scheme uriașe de corupție. Se poate afla din câteva click-uri cine ascunde o vilă somptuoasă pe numele unei mătușe. […] Persoana și-a schimbat viza de reședință, gata, Fiscul află a doua zi.”

Iar concluzia lui Cojocari, după 12 ani de țară vecină digitalizată:

„De vină e proasta noastră organizare. Mulți politicieni se opun digitalizării, nu le place transparența și inventează tot felul de motive că nu se poate.”

Articolul integral al lui Cojocari: postare publică, Chișinău, mai 2026.

Standardizare prin lege: modelul moldovenesc

Pe lângă arhitectura tehnică, există un nivel de standardizare administrativă care lipsește complet în România. Din octombrie 2025, Republica Moldova are un Model Unitar de Design pentru toate serviciile digitale publice, instituit prin Hotărârea Guvernului nr. 677/2025, publicat în open source pe GitHub și obligatoriu pentru autoritățile centrale care dezvoltă platforme electronice.

Site-ul sistemului: mud.egov.md. Conține componente reutilizabile, principii, șabloane, exact ca GOV.UK Design System din Marea Britanie sau U.S. Web Design System din Statele Unite. România nu are nimic comparabil: fiecare aplicație guvernamentală arată diferit, se comportă diferit, cere altă curbă de învățare.

Pentru PNI, standardizarea înseamnă două lucruri:

• Schema mesajelor de audit și specificațiile OpenAPI pentru servicii: instituite prin Hotărâre de Guvern, devin obligatorii pentru orice integrare nouă.
• Sistem unitar de design pentru toate front-end-urile: cetățeanul interacționează cu zeci de aplicații publice, recunoaște instant familia vizuală, reduce curba de învățare, scade barierele.

Branding-ul public (un nume scurt și memorabil, în spiritul ghiseul.ro) e responsabilitatea statului, nu a unui observator civic. Magistrala documentează arhitectura tehnică; numele potrivit pentru sistemul de audit și pentru registrul de servicii e treaba ADR și a comunicării guvernamentale.

Concluzia: PNI e ultimul, nu primul

PNI v2 (automatizarea completă a schimbului de date între instituții, fără intervenție umană) va fi probabil ultima componentă realizată, nu prima. Depinde critic de succesul celor două straturi de fundație (audit + registru) și de maturizarea practicii operaționale.

Realist: câțiva ani de muncă tehnică și de lobby politic-administrativ înainte de a fi posibil să se construiască PNI propriu-zis. Asta nu e o veste rea. E recunoașterea faptului că infrastructura digitală a unui stat se construiește pe etape, nu prin proiecte unice de 33 de milioane de euro livrate „la cheie”.

Ce trebuie făcut acum, în 2026:

1. Inventar guvernamental al licențelor WSO2 existente și renegociere unitară.
2. Hotărâre de Guvern pentru schema standard a mesajelor de audit și pentru specificațiile OpenAPI ale serviciilor publice.
3. Selectarea a 3-4 instituții pilot (din cele cu WSO2 deja achiziționat) pentru primii conectori și primul registru funcțional.
4. Construirea sistemului central de audit în paralel, stack open source, cu dimensionare reală (sub 50 GB RAM total, nu 256 GB per nod).
5. Hotărâre de Guvern pentru indicatorii tehnico-economici ai PNI v2, dimensionați pe baza experienței primelor 6-12 luni.

Magistrala va continua să documenteze fiecare etapă publică. Arhitectura propusă aici e disponibilă sub licență deschisă; oricine poate prelua, adapta sau duce mai departe.