Platformă digitală completă pentru primăriile din România

00Rezumat executiv și recomandare

Recomandare. Construim un sistem de operare al primăriei, livrat ca produs instalabil, nu o colecție de module. Primăria este, în esență, o organizație care primește cereri, produce acte și publică ce este public. Tot ce face trece prin trei instrumente vechi de două secole: registrul (numărul de înregistrare), semnătura (cine răspunde) și afișierul (ce se face public). Platforma propusă digitalizează exact aceste trei instrumente și le pune sub un motor de fluxuri configurabil de primărie, fără cod.

Produsul are patru fețe pe aceeași bază de date: Portal (cetățeni, firme, profesioniști), Birou (funcționari, primar, secretar general), Studio (configurarea organizației și a fluxurilor) și Public (transparență, Monitorul Oficial Local, date deschise). AI-ul rulează local și face trei lucruri: înțelege documente, propune drafturi și răspunde cu citări. Decizia rămâne la om, cu semnătură.

Deciziile de arhitectură propuse

Ce nu construim în prima versiune

• Calcul fiscal (impozite și taxe locale). Codul fiscal are sute de reguli de calcul, iar piața are furnizori stabili (Indeco Soft, Sobis). Integrăm rolul fiscal și plățile, construim modulul propriu în versiunea 3.
• Contabilitate, salarizare, Forexebug. Raportările către Ministerul Finanțelor au formate proprii și furnizori dedicați. Modelăm fluxurile (referat, viză CFP, ordonanțare) și exportăm către contabilitate.
• Stare civilă și evidența persoanelor. Sunt sisteme MAI (SIIEASC, SNIEP). Oferim programări, informare și preluarea cererilor, nu registrul.
• Achiziții în SEAP. SEAP e obligatoriu și extern. Modelăm fluxul intern (referat, PAAP, oferte, contract) și legăm anunțul SEAP.

Piața în cifre

Regista (Zitec) raporta peste 600 de primării cu registratură electronică în 2020 și venituri de 1,5 milioane de euro în 2022. Indeco Soft furnizează software de taxe pentru peste 200 de instituții. Nimeni nu vinde azi o platformă care să acopere organizația, fluxurile și transparența ca un singur sistem on-prem. Asta e poziționarea.

01Context și diagnostic: primăria de azi

Modelul de referință de mai jos este cel pe care platforma îl ia ca „adevăr implicit”. Orice primărie îl poate modifica în Studio, dar instalarea pornește deja configurată pentru mărimea ei.

1.1 Trei mărimi, trei realități

Cifrele de personal și volum sunt estimări proprii din practică, nu statistici oficiale, și servesc doar la dimensionarea instalării (secțiunea 09).

1.2 Cine decide și cine răspunde

1.3 Organigrama tipică (compartimente și ce produc)

1.4 Cele cinci tipuri de documente

Tot ce iese dintr-o primărie se încadrează într-unul din cinci tipuri. Platforma le tratează cu un singur model de document (secțiunea 06), dar cu reguli diferite de semnare, numerotare și publicare.

1.5 Cadrul legal tradus în funcții de platformă

1.6 Calendarul recurent al primăriei

Platforma vine cu acest calendar preîncărcat, pentru că termenele ratate sunt cel mai frecvent motiv de sancțiune.

02Utilizatori și stakeholderi

Tabelul de mai jos este inventarul complet. „Rol în platformă” spune cum intră fiecare în sistem: cont de angajat (Birou), cont de cetățean sau firmă (Portal), fără cont (Public) sau prin integrare.

2.1 În interiorul primăriei

2.2 Aleșii

2.3 Cetățenii, pe segmente

2.4 Mediul de afaceri și profesioniștii

2.5 Instituții și autorități

2.6 Societatea civilă și publicul

03Viziune, principii și modelul de operare țintă

3.1 Ce este produsul

Un sistem de operare al primăriei. Nu un portal lipit de o registratură, ci un singur sistem în care organizația (structuri, posturi, roluri), lucrul (procese, sarcini, termene), documentele (registre, versiuni, semnături, arhivă), teritoriul (hartă, imobile, adrese) și comunicarea (cetățeni, consiliu, instituții, public) sunt aceeași bază de date, cu reguli diferite de acces. Primăria îl instalează o dată, îl configurează singură și îl ține la zi prin pachete de actualizare legislativă.

3.2 Zece principii de proiectare

3.3 Modelul de operare țintă

Platforma schimbă felul în care lucrează primăria, nu doar instrumentul. Tabelul descrie starea țintă pe fiecare zonă de operare, în comparație cu practica de azi.

3.4 Suprafețele produsului

3.5 Granițele scopului

„Complet” înseamnă că primăria nu mai are nevoie de un alt sistem pentru lucrul propriu. Nu înseamnă că rescriem sistemele naționale sau softurile de specialitate consolidate. Regula de delimitare: dacă statul ține registrul, ne integrăm; dacă primăria ține registrul, îl construim.

3.6 Harta funcțională: ce tipuri de sistem înlocuiește

Primăriile cumpără azi, separat, un sistem de registratură, un document management, un portal, un site, un GIS, un modul de ședințe și câteva tabele Excel. Platforma le acoperă ca funcții ale aceluiași nucleu. Tabelul arată categoriile clasice de software și ce devin aici.

Ce rămâne în afara platformei, prin integrare: calculul impozitelor, contabilitatea și salarizarea, stare civilă și evidența persoanelor, SEAP, sistemele naționale de identitate și plată. Ce rămâne fizic și e doar organizat de platformă: ghișeul, scanerul, imprimanta, poșta, afișierul de la sediu, arhiva pe hârtie deja existentă.

04Harta capabilităților și catalogul serviciilor

Harta capabilităților spune ce trebuie să poată face sistemul, independent de ecrane și de tehnologie. Catalogul serviciilor spune ce primește concret fiecare beneficiar. Prima e stabilă ani de zile; al doilea se schimbă cu legea și se livrează ca date.

4.1 Harta capabilităților

Etichetele arată versiunea în care capabilitatea devine disponibilă: V1 nucleul vandabil, V2 extinderea la 12 luni, V3 la 24 de luni. „Integrare” marchează capabilități livrate prin conectarea la alt sistem.

4.2 Catalogul serviciilor

Fiecare rând este o intrare în catalogul livrat cu produsul, pe care primăria o poate activa, dezactiva sau adapta. Coloana „Livrare” arată versiunea și dacă serviciul se bazează pe o integrare. PF = persoană fizică, PJ = persoană juridică.

Relația cu publicul, petiții, informare

Secretariat, consiliu local, acte

Urbanism, construcții, adrese

Venituri locale

Asistență socială

Agricol, fond funciar

Patrimoniu, contracte, spații

Achiziții, buget, execuție

Oameni și organizație

Gospodărire, mediu, utilități, ordine publică

Educație, cultură, sport, sănătate

Stare civilă și evidența persoanelor (sisteme MAI)

Transparență, participare, date deschise

Capabilități de platformă (invizibile beneficiarului, obligatorii)

05Modelul serviciilor și experiențe de referință

Modelul serviciilor definește cum ajunge un serviciu la beneficiar: pe ce canal, cu ce nivel de identificare, cu ce structură standard și cu ce comunicare. Experiențele de referință sunt scenarii complete, pas cu pas, pe care le folosim ca specificație de produs și ca scenarii de test.

5.1 Canalele

5.2 Niveluri de identitate

Nu toate serviciile cer aceeași certitudine despre cine depune. Nivelurile sunt definite o dată și atașate fiecărui serviciu în catalog.

5.3 Fișa standard a unui serviciu

Fiecare serviciu din catalog este descris prin aceleași câmpuri. Fișa este și documentația publică a serviciului (pagina lui din Portal), și configurația care îl pune în funcțiune.

5.4 Experiențe de referință

Zece scenarii care acoperă toate tipurile de utilizatori. Fiecare arată ce vede beneficiarul, ce face primăria și ce face sistemul singur. Ele devin criteriile de acceptanță ale versiunii 1.

A. Sesizare din stradă, fără cont

B. Certificat de urbanism pentru o casă

C. Din diaspora: certificat fiscal și plata impozitului

D. Venit minim de incluziune, la ghișeu asistat

E. Petiție și cerere de informații publice

F. Adeverință din registrul agricol, pe loc

G. Registratura, la 8:30 dimineața

H. De la proiect de hotărâre la Monitorul Oficial Local

I. Coada de semnare a primarului

J. Factura furnizorului, de la e-Factura la plată

5.5 Comunicare și notificări

• Fiecare schimbare de stare notifică beneficiarul pe canalele alese (e-mail, SMS, push) și lasă mesajul în dosar. Mesajele au șabloane în limbaj simplu, bilingve, fără jargon.
• Comunicarea oficială (acte, răspunsuri) se livrează în cont, cu dovadă de primire (data deschiderii). La cerere, și pe hârtie, cu borderou.
• Termenele avertizează funcționarul la 50% și la 80% din termen, escaladează la șef la 100%, la primar la depășire.
• Afișarea la sediu rămâne pentru comunicările prevăzute de lege; sistemul generează lista și procesul-verbal de afișare.

06Modelul informațional

Modelul informațional spune ce știe sistemul și cum se leagă lucrurile. Este stabil: domeniile (urbanism, social, agricol) nu adaugă entități noi, ci tipuri și câmpuri pe aceleași entități.

6.1 Entitățile

6.2 Cum se leagă

6.3 Ciclul de viață al dosarului

6.4 Registre și numerotare

• Registrul general de intrări-ieșiri este unic pe instituție și pe an; numărul este continuu, alocat de baza de date într-o tranzacție, imposibil de sărit, de refolosit sau de aloca retroactiv.
• Registrele speciale (HCL, dispoziții, CU, AC, petiții, 544, contracte, certificate fiscale, adeverințe, procese-verbale, sesizări) au secvențe proprii și pot fi cerute de lege sau create de primărie în Studio.
• O înregistrare leagă un document de un registru. Un document poate avea o înregistrare de intrare și una de ieșire; un act are înregistrarea în registrul lui și, dacă se expediază, una în registrul general.
• Anularea unei înregistrări este o înregistrare nouă cu motiv, semnată de secretarul general, vizibilă în registru.
• Registrele cerute de Monitorul Oficial Local (proiecte, HCL, dispoziții, refuzuri de contrasemnare, propuneri) se publică automat ca liste.

6.5 Documente: versiuni, formate, semnături

6.6 Clasificare și date personale

Nivelul se stabilește din fișa serviciului la crearea dosarului și se moștenește de documente. Un document poate avea nivel mai strict decât dosarul (o anchetă socială într-un dosar de locuință), niciodată mai permisiv. Anonimizarea folosește reguli (CNP, adrese, nume în contexte cunoscute) și modelul local de recunoaștere a entităților; rezultatul este o versiune separată a documentului, verificată de secretarul general sau de responsabilul 544 înainte de publicare.

6.7 Relațiile cu reguli

Legăturile dintre entități nu sunt simple referințe: fiecare poartă o regulă care decide comportamentul sistemului. Acestea sunt relațiile pe care Studio le lasă configurabile.

6.8 Exemplu de instanțiere: certificatul de urbanism

6.9 Document management, în detaliu

Funcțiile clasice ale unui sistem de management al documentelor sunt toate prezente, dar organizate în jurul dosarului și al registrului, nu al folderelor. Tabelul enumeră cerințele și cum le acoperim.

07Arhitectura proceselor

Procesele administrative au o formă aparte: puține ramuri, multe așteptări, termene legale în zile lucrătoare, semnături în ordine și obligații de publicare. Nu sunt procese de fabrică și nu sunt orchestrări de microservicii. Arhitectura de mai jos este făcută pentru această formă, iar alegerea motorului este argumentată în secțiunea 16.

7.1 Ce trebuie să poată exprima un proces

7.2 Definiția unui proces

Definițiile sunt date, nu cod: un document structurat, versionat, citit de motor. Exemplul de mai jos este certificatul de urbanism, simplificat. În Studio, aceeași definiție se vede și se editează vizual.

proces: certificat-urbanism
versiune: 3
serviciu: urbanism.certificat-urbanism
registru_cerere: registratura-generala
registru_act: registrul-cu
termen:
  durata: 15
  unitate: zile-lucratoare
  de_la: inregistrare
  temei: "Legea 50/1991 art. 6 alin. 2"
  suspendat_in: [completari]
taxa:
  formula: taxa_cu(suprafata_teren)
  moment: la-depunere
  temei: "Codul fiscal art. 474; HCL taxe locale"
pasi:
  - id: inregistrare
    tip: inregistrare
  - id: verificare
    tip: verificare-completitudine
    rol: referent-urbanism
    termen_intern: 2 zile-lucratoare
    daca_incomplet: completari
  - id: completari
    tip: solicitare-completari
    termen_raspuns: 10 zile-lucratoare
    la_expirare: clasare
    apoi: verificare
  - id: redactare
    tip: sarcina
    rol: referent-urbanism
    sablon: cu-standard
    asistent: draft-cu-din-pug
  - id: aviz
    tip: aviz
    rol: arhitect-sef
    alternativa_daca_rol_lipseste: subproces(aviz-structura-cj)
    la_negativ: redactare
  - id: semnare
    tip: semnatura
    roluri: [secretar-general, primar]
    delegare: permisa
  - id: emitere
    tip: inregistrare
    registru: registrul-cu
  - id: comunicare
    tip: comunicare
    canale: [cont, email, ghiseu-la-cerere]
  - id: publicare
    tip: publicare
    sectiune: urbanism/lista-cu
    forma: lista
    anonimizare: standard
  - id: inchidere
    tip: inchidere
    nomenclator: U-01

7.3 Cum rulează

• Termene. Se calculează în zile lucrătoare după calendarul instituției (sărbători legale plus zile libere locale). Sistemul arată mereu „zile rămase” și motivul oricărei suspendări. Termenul legal și termenul intern sunt separate; primul nu poate fi modificat de primărie, al doilea da.
• Rolurile se rezolvă la momentul pasului, nu la pornirea dosarului. Dacă arhitectul-șef pleacă, pasul ajunge la înlocuitorul desemnat sau la alternativa din definiție.
• Delegarea este un mandat cu perioadă și cu tipuri de acte; se aplică automat la pasul de semnătură și se consemnează pe act („semnat prin delegare, dispoziția nr.”).
• Escaladarea notifică șeful structurii la 100% din termenul intern și primarul la depășirea termenului legal; nu mută sarcina, o face vizibilă.
• Versiuni. O definiție modificată primește versiune nouă. Dosarele în curs continuă pe versiunea lor; Studio oferă migrarea controlată a dosarelor deschise, pas cu pas, cu raport.
• Integrările sunt pași cu reîncercare și cu mod degradat explicit: dacă RAN nu răspunde, pasul se marchează „de reluat” și dosarul merge mai departe unde legea permite.
• Totul este eveniment. Fiecare tranziție scrie în jurnalul dosarului; de aici ies istoricul vizibil beneficiarului, rapoartele de performanță și analiza de proces.
• Compensare. Un act emis din greșeală nu se șterge: se revocă printr-un act nou, cu propriul proces.

7.4 Biblioteca de procese standard

Produsul se livrează cu procesele de mai jos gata definite, cu termene, semnatari și publicări conform legii. Primăria le activează și le adaptează. Lista este și harta a ceea ce Codul administrativ și legile speciale cer explicit unei primării.

7.5 Studio: cum configurează primăria

• Editor vizual pentru pași, cu panou de proprietăți; validare în timp real (un pas de semnătură fără rol, un termen fără temei).
• Roluri, nu nume: editorul oferă numai roluri din organigramă; dacă un rol lipsește, cere alternativa.
• Simulare: rulează procesul pe un dosar de test cu date fictive, arată calendarul rezultat și cine ar fi notificat.
• Publicare controlată: schiță, testare, publicare; doar secretarul general sau un rol desemnat poate publica; fiecare publicare are jurnal și poate fi revenită.
• Impact: înainte de publicare, Studio arată câte dosare deschise sunt pe versiunea veche și ce pași diferă.
• Pachete legislative: furnizorul trimite actualizări de definiții (termen nou, formular nou); primăria vede diferențele și acceptă, cu posibilitatea de a păstra adaptările proprii.
• Formulare: același editor definește formularele din Portal, cu validări, precompletare și întrebări condiționate.

7.6 Procedurile SCIM se generează din procese

OSGG 600/2018 obligă fiecare primărie să aibă proceduri documentate pentru activitățile ei. Azi sunt documente Word scrise o dată și uitate. Aici, procedura operațională este o vedere a definiției de proces: scop, domeniu, documente de referință (temeiul), responsabilități (rolurile), descrierea pașilor, formularele, înregistrările (registrele) și indicatorii. Când procesul se schimbă, procedura se regenerează cu număr de ediție. Registrul riscurilor primește automat riscurile standard ale pașilor (termen depășit, semnatar indisponibil, integrare căzută), iar autoevaluarea anuală pornește de la date reale de execuție.

7.7 Exemplu vizual

7.8 Motorul

Recomandarea este un motor propriu, declarativ, care rulează în același proces cu aplicația și păstrează definițiile, instanțele și temporizatoarele în PostgreSQL. Motivele, alternativele (Temporal, Flowable) și punctajul sunt în secțiunea 16.2. Pe scurt: procesele administrative au nevoie de termene în zile și de semnături în ordine, nu de orchestrare de milisecunde; iar 2.800 de comune nu pot opera un runtime Java sau un cluster Temporal separat.

08Organizare și autorizare

Fiecare primărie își desenează organizația în Studio, pornind de la organigrama aprobată prin HCL și de la statul de funcții. Drepturile de acces nu se dau niciodată direct persoanelor: derivă din post, rol și mandat, iar excepțiile sunt delegări înregistrate.

8.1 Modelul organizației

Primăria Comunei Exemplu (instituție, CUI, sigiliu electronic)
├─ Primar (post de demnitate, mandat 2024-2028)
│  ├─ Viceprimar (mandat; delegări prin dispoziție)
│  ├─ Cabinetul primarului
│  └─ Administrator public (post contractual, opțional)
├─ Secretar general al UAT (funcție publică de conducere)
│  ├─ Compartiment juridic, consiliu local, registratură, arhivă
│  └─ Compartiment stare civilă (lucrează în SIIEASC)
├─ Compartiment urbanism și amenajarea teritoriului
├─ Compartiment registru agricol și fond funciar
├─ Compartiment asistență socială (SPAS)
├─ Compartiment buget, contabilitate, taxe, achiziții
│  └─ Persoana desemnată CFP (rol, nu post)
├─ Compartiment resurse umane
├─ Serviciul voluntar pentru situații de urgență
├─ Poliția locală
└─ Compartiment gospodărire, mediu, drumuri
Consiliul local (autoritate deliberativă, 13 mandate)
├─ Comisia 1: buget, finanțe, patrimoniu
├─ Comisia 2: urbanism, agricultură, mediu
└─ Comisia 3: social, educație, cultură, juridic
Unități subordonate (conturi de instituție în aceeași instanță)
├─ Școala Gimnazială Exemplu
└─ Serviciul public de alimentare cu apă

8.2 Roluri standard

8.3 Modelul de autorizare

Autorizarea este pe atribute (ABAC): o politică spune cine poate face ce, pe ce obiect, în ce condiții. Politicile standard vin cu produsul; primăria le poate restrânge, nu le poate lărgi peste limitele legale (de exemplu nu poate da acces public la dosare restricționate).

8.4 Delegare, înlocuire, absență, separare

• Delegarea se face prin dispoziție generată din Studio sau Birou: cine, cui, ce tipuri de acte, până când, limită de sumă. Actele semnate prin delegare o menționează.
• Înlocuirea la absență: fiecare post are un înlocuitor desemnat; la concediu înregistrat, sarcinile noi merg la înlocuitor, cele vechi rămân vizibile ambilor.
• Posturile vacante primesc sarcini doar prin înlocuitor sau prin alternativa din proces (de exemplu aviz CJ în loc de arhitect-șef).
• Separarea atribuțiilor este impusă de politici, nu de bunăvoință: CFP față de ordonator, inițiator față de avizator, operator de ghișeu față de aprobator al aceleiași cereri.
• Plecarea unei persoane închide contul, nu șterge nimic; sarcinile deschise se redistribuie printr-un raport de predare generat.

8.5 Conturi externe

Cetățenii, firmele, profesioniștii, furnizorii, consilierii, auditorii și partenerii au conturi în aceeași instanță, cu nivelurile de identitate din 5.2 și cu drepturi derivate din relația lor cu dosarele. Consilierii sunt un caz hibrid: externi ca acces la dosare, interni ca rol în procesele de ședință. Unitățile subordonate au propriile structuri și văd numai dosarele lor, dar folosesc registrele și procesele primăriei unde legea o cere.

8.6 Jurnal și audit

• Fiecare acțiune (vizualizare de document restricționat, editare, repartizare, semnătură, publicare, export, modificare de configurație, autentificare) lasă o intrare cu actor, moment, obiect, motiv, canal.
• Jurnalul este scris o singură dată, înlănțuit criptografic; o copie zilnică semnată pleacă în backup.
• Rapoarte standard: cine a accesat un dosar, ce a semnat o persoană într-o perioadă, ce s-a publicat, ce configurații s-au schimbat, ce accesări cu motiv au fost făcute pe date restricționate.
• Auditorii externi primesc conturi de citire pe perioadă, cu acces jurnalizat, fără export în masă.

09Arhitectura tehnică

Constrângerea care decide totul: sistemul trebuie să ruleze singur, ani de zile, într-o comună fără IT, pe un singur server, și să scaleze pe același cod la un municipiu cu o mie de utilizatori. De aici vin alegerile: o singură unitate de instalare, o singură bază de date, un singur limbaj, actualizări semnate, întreținere la distanță.

9.1 Principii tehnice

• Monolit modular. Un singur proces aplicativ cu module izolate prin interfețe interne. Microserviciile se justifică la echipe mari și trafic enorm; aici ar multiplica punctele de eșec în 3.000 de instalări.
• PostgreSQL pentru tot. Date, documente (metadate), căutare full-text, vectori, geometrie, cozi de joburi, temporizatoare. Un singur backup, o singură restaurare, un singur lucru de înțeles.
• TypeScript end-to-end. Același limbaj în Portal, Birou, Studio, server și scripturi de operare. Echipa rămâne mică și interschimbabilă.
• Instanță izolată per primărie. Datele unei primării nu împart baza de date cu ale alteia, nici când găzduim noi mai multe instanțe pe aceeași infrastructură.
• Operabil de la distanță, fără acces de intrare. Instanța deschide un canal de ieșire către consola de flotă; nimeni nu deschide porturi în primărie.
• Totul versionat și semnat. Imagini de container semnate, definiții de proces versionate, pachete legislative semnate, jurnal înlănțuit.
• Degradare elegantă. Fără internet, Biroul funcționează complet în rețeaua locală; integrările se reiau singure.

9.2 Vedere de ansamblu

9.3 Componente și tehnologii

9.4 Date și stocare

• Scheme pe module (organizație, dosare, documente, registre, acte, gis, plăți, social, urbanism, agricol, achiziții, publicare, jurnal), cu legături prin chei străine; migrații versionate și reversibile.
• Jurnalul de evenimente este sursa pentru istoricul dosarului, notificări, indicatori și integrări (model outbox: evenimentele se scriu în aceeași tranzacție cu datele, apoi se consumă).
• Fișierele se stochează după hash, cu metadatele în Postgres; versiunile sunt fișiere separate; criptare la repaus cu chei per instanță; ștergerea este logică până la expirarea termenului de păstrare.
• Căutarea indexează conținutul OCR și câmpurile; rezultatele trec prin politicile de autorizare înainte de afișare.
• Geometria se păstrează în PostGIS în EPSG:3844 (Stereo 70) și se servește în WGS84; importurile din ANCPI și PUG se reproiectează la intrare.
• Dimensiuni de referință: o comună de 5.000 de locuitori produce sub 10 GB pe an, inclusiv scanări; un municipiu de 100.000, sub 400 GB pe an.

9.5 API și extensibilitate

• Tot ce fac interfețele fac prin același API REST documentat OpenAPI; conturile de integrare primesc chei cu drepturi limitate.
• Webhook-uri semnate pentru evenimente (dosar înregistrat, act emis, plată confirmată), pentru softurile de specialitate și pentru consiliile județene.
• Pachete de domeniu (urbanism, social, agricol) sunt module care înregistrează tipuri de dosar, câmpuri, procese, șabloane și straturi GIS; un terț poate construi un pachet nou pe aceleași interfețe.
• Export complet al instanței (date, fișiere, jurnal) într-un format documentat, oricând, fără aprobarea furnizorului: condiția de portabilitate pe care o cerem în contract.

9.6 Niveluri de instalare

Prețurile de hardware sunt orientative: RTX 5090 apărea în 2026 la aproximativ 2.500 – 4.000 €, iar RTX PRO 6000 Blackwell la 9.000 – 12.000 €, cu variații mari între listări. Hardware-ul se cumpără de primărie direct sau prin noi, la cost.

9.7 Operare fără IT local

9.8 Performanță și capacitate

9.9 Dezvoltare și calitate

• Monorepo; fiecare experiență de referință din secțiunea 5.4 are un test end-to-end care rulează la fiecare versiune.
• Două trenuri de lansare: lunar (funcții) și la nevoie (legislativ, securitate). O versiune cu suport extins pe an, pentru primăriile care nu vor schimbări dese.
• Date de test sintetice realiste (persoane, imobile, acte) pentru demonstrații și instruire; niciodată date reale în afara instanței primăriei.
• Audit de securitate extern anual și la fiecare versiune majoră; listă de componente (SBOM) publicată.

10Integrări și interoperabilitate

Regula: fiecare sistem extern are un adaptor izolat, cu contract clar, cu jurnal și cu un mod de lucru fără el. Nicio funcție de bază a platformei nu depinde de disponibilitatea unui sistem național, pentru că multe nu au API, iar cele care au se schimbă.

10.1 Inventarul integrărilor

10.2 Modelul adaptorului

• Fiecare adaptor implementează aceeași interfață: configurare (în Studio), verificare de conexiune, operații cu reîncercare și idempotență, jurnal detaliat, stare vizibilă pe pagina de sănătate.
• Secretele (certificate, chei) stau criptate în instanță și nu părăsesc primăria.
• Un adaptor căzut nu blochează procesul: pasul de integrare se marchează „de reluat” și se reia automat; dacă legea cere confirmarea externă înainte de a merge mai departe, pasul rămâne în așteptare cu termen vizibil.
• Adaptoarele pentru softurile de taxe și contabilitate se construiesc cu furnizorii respectivi, pe bază de contract de interoperabilitate; acolo unde refuză, exportul programat este calea.

10.3 Federare între instanțe (V3)

Consiliile județene, asociațiile de dezvoltare intercomunitară și primăriile schimbă zilnic documente semnate. În V3, două instanțe se pot „cunoaște” reciproc și pot transmite acte direct, cu înregistrare automată în registrele ambelor părți și cu dovadă de primire. Același mecanism servește comunicarea cu prefectura, dacă prefectura rulează o instanță.

11Teritoriu și GIS

Harta nu este un modul, ci un index al primăriei: aproape orice dosar are un loc. Urbanismul, sesizările, patrimoniul, cimitirele, intervențiile și registrul agricol se înțeleg mai repede pe hartă decât în liste.

11.1 Straturi și surse

11.2 Funcții pe domenii

• Urbanism: solicitantul alege parcela; sistemul aduce zona și reglementările; referentul vede vecinătățile, autorizațiile anterioare, litigiile; lista publică de CU și AC are hartă.
• Sesizări: poziție din fotografie sau din hartă; detectarea duplicatelor; rutare pe zonă; hartă publică cu stări.
• Patrimoniu: fiecare bun are geometrie și contracte; licitațiile arată terenul; expirările se văd pe hartă.
• Agricol: parcelele din registrul agricol se leagă de cadastru unde există; adeverințele pot include schița.
• Social: harta beneficiarilor este restricționată; servește planificării anchetelor în teren.
• Situații de urgență: zone de risc, puncte de adunare, resurse; avertizări pe zonă.

11.3 Instrumente

PostGIS stochează, martin servește tile-uri vectoriale, MapLibre le afișează în toate suprafețele, iar QGIS (desktop, gratuit) este instrumentul personalului de urbanism pentru editare avansată, conectat direct la PostGIS cu drepturi de editare pe straturile lui. Implementarea include digitizarea PUG-ului dacă primăria nu îl are în format vectorial, pentru că fără zone de reglementare pe hartă, draftul automat al certificatului de urbanism nu există.

12Inteligență artificială locală

AI-ul din platformă are un singur rol: să reducă munca de citit, căutat și redactat a funcționarilor și să răspundă cetățenilor cu surse. Nu emite acte, nu evaluează eligibilități, nu decide. Această limită este și cea legală: Anexa III a AI Act listează ca risc ridicat sistemele folosite de autorități pentru a evalua eligibilitatea la beneficii și servicii publice esențiale.

12.1 Cazuri de utilizare

12.2 Modelele

Alegerile de mai jos sunt cele din octombrie 2026 și se reevaluează la fiecare versiune. Criteriile: licență care permite uz comercial și instalare locală, calitate dovedită în română, dimensiune potrivită hardware-ului de nivel.

12.3 Cum răspunde cu surse

• Corpusul unei instanțe: catalogul de servicii, HCL și dispoziții, regulamente, PUG, procedurile, actele emise (pentru funcționari), legislația relevantă (pachet livrat și actualizat).
• Fiecare răspuns arată fragmentele folosite; funcționarul le deschide cu un click. Asistentul public nu are acces la nimic intern sau restricționat, prin construcție (index separat).
• Jurnal al tuturor interacțiunilor AI, cu versiunea modelului; set de evaluare în română întreținut de noi (întrebări reale anonimizate, răspunsuri de referință) rulat la fiecare schimbare de model.
• Instruirea personalului în folosirea AI (art. 4 AI Act, „alfabetizare AI”) face parte din implementare.

12.4 Hardware și cost

12.5 Română și maghiară

Modelele alese acoperă ambele limbi. Setul nostru de evaluare are secțiuni în română și maghiară; catalogul, șabloanele și interfața sunt traduse de oameni, nu de model; AI-ul propune traduceri doar pentru conținut nou (anunțuri, răspunsuri), cu verificare.

13Transparență și date deschise

Transparența nu este o pagină de site, ci o consecință automată a felului în care sunt clasificate actele. Tot ce legea cere public se publică singur, la momentul potrivit, în forma potrivită, iar primăria nu mai întreține un site de mână.

13.1 Ce este obligatoriu public

13.2 Cum ajunge un act public

• Anonimizarea înlocuiește CNP, adrese de domiciliu, date de contact, date de sănătate; păstrează numele unde legea cere (beneficiari de contracte, semnatari de acte).
• Retragerea unei publicări (eroare, anulare în instanță) lasă în loc o mențiune cu motiv, nu un gol.
• Monitorul Oficial Local se poate exporta integral către platforma consiliului județean pentru UAT-urile care publică acolo.

13.3 Site-ul primăriei

Suprafața Public este un site complet, generat static din datele instanței, cu stema și culorile primăriei: pagini de prezentare, program și contact, anunțuri, evenimente, servicii (din catalog, cu legătura către Portal), Monitorul Oficial Local, informații din oficiu, ședințe, buget, achiziții, hartă, sesizări, declarația de accesibilitate. Bilingv acolo unde legea o cere, cu structură identică în ambele limbi. Primăria care are deja un site îl poate păstra și poate integra doar secțiunile generate.

13.4 Date deschise

Seturile se publică și pe data.gov.ro prin API, cu metadate DCAT, fără intervenție manuală. Indicatorii de performanță sunt publici din principiu: un primar care livrează în termen are interesul să se vadă.

13.5 Participare (V2)

Consultări publice cu răspuns la fiecare propunere, bugetare participativă cu vot verificat prin cont N2, sondaje pe teme locale, petiții colective. Toate folosesc aceleași conturi și aceleași registre; rezultatele se publică automat.

14Experiență și design

Două publicuri cu nevoi opuse folosesc același sistem: cetățeanul care intră o dată pe an și vrea să termine repede, și funcționarul care stă opt ore pe zi în el și vrea densitate, tastatură și viteză. Designul le tratează separat, pe aceeași fundație.

14.1 Principii

14.2 Personas

14.3 Concepte de interfață și variante

Portalul cetățeanului

Schiță de structură, nu design final.

Biroul funcționarului

Schiță de structură, nu design final.

Studio

Schiță de structură, nu design final.

14.4 Design system

14.5 Accesibilitate

• Conformitate WCAG 2.1 AA pe Portal și Public, cerută de OUG 112/2018; declarația de accesibilitate generată din rezultatele testelor.
• Testare cu cititoare de ecran (NVDA, VoiceOver), navigare numai din tastatură, mărire 200%, mod cu contrast ridicat, fără conținut care clipește.
• Formularele anunță erorile la nivel de câmp și în rezumat; fiecare câmp are etichetă și ajutor; sesiunile nu expiră în mijlocul unui formular fără avertizare.
• Limbaj simplu verificat cu persoane reale din grupurile vulnerabile în faza de pilot.

14.6 Mobil și teren

Portalul este o aplicație web progresivă instalabilă, cu notificări push; aplicația de Teren este tot PWA, cu stocare locală criptată, formulare care funcționează fără semnal, cameră, geolocalizare și semnătură pe ecran; sincronizarea se face la reconectare, cu rezolvarea conflictelor în favoarea serverului și cu jurnal. Aplicații native vin doar dacă magazinele de aplicații devin o cerință a primăriilor.

15Securitate, conformitate, guvernanța datelor

O primărie este o țintă ușoară: date personale ale întregii comunități, personal fără pregătire de securitate, servere sub birou. Platforma trebuie să fie sigură implicit, nu prin configurare, și să demonstreze conformitatea prin rapoarte generate, nu prin dosare scrise de mână.

15.1 Modelul de amenințare

15.2 Măsuri pe straturi

15.3 GDPR prin construcție

15.4 NIS2 și DNSC

OUG 155/2024, aprobată prin Legea 124/2025, transpune NIS2; ordinele DNSC 1 și 2 din 2025 stabilesc înregistrarea și evaluarea riscului. Încadrarea explicită a primăriilor nu reiese clar din sursele publice; proiectăm ca și cum s-ar aplica, pentru că măsurile sunt oricum bune practici: responsabil de securitate desemnat, analiză de risc documentată (generată din modelul de amenințare adaptat), politici de acces, backup și continuitate, jurnalizare, notificarea incidentelor în 24 de ore (avertizare timpurie) și 72 de ore (notificare), raport final în 30 de zile, instruirea conducerii. Platforma livrează șabloanele și registrul de incidente; obligația rămâne a primăriei.

15.5 Semnătură și arhivare electronică

• Semnătura calificată (QES) are efectul semnăturii olografe (eIDAS art. 25; Legea 455/2001); o folosim pentru toți semnatarii de acte. Semnătura avansată este suficientă pentru vize interne. Sigiliul electronic calificat al instituției certifică originea și integritatea actelor emise automat.
• Marca temporală calificată fixează momentul; validarea pe termen lung (PAdES-LT) include lanțul de certificate, pentru ca actul să rămână verificabil după expirarea certificatelor.
• Legea 135/2007 privind arhivarea documentelor în formă electronică cere, pentru arhiva electronică cu valoare legală, un administrator de arhivă acreditat. Strategia: platforma produce pachete de arhivare standardizate (documente, metadate, semnături, hash-uri) și le predă unui administrator acreditat pentru documentele cu termen permanent; pentru restul, păstrarea în instanță cu jurnal și backup este suficientă operațional. Nomenclatorul arhivistic al primăriei, aprobat de Arhivele Naționale, este importat ca date.

15.6 AI Act

15.7 Continuitate

15.8 Guvernanța datelor

• Proprietar: primăria, pe toate datele și documentele; furnizorul nu are drepturi de folosire, nici pentru antrenare de modele.
• Portabilitate: export complet, documentat, în orice moment, fără cost și fără aprobarea furnizorului.
• Date de referință: persoane, firme, imobile, adrese sunt entități unice cu istoric; dublurile se detectează la înregistrare și se unesc cu urmă.
• Calitate: rapoarte de completitudine (dosare fără imobil, acte fără temei, adrese nevalidate) pentru secretarul general.
• Reședința datelor: în primărie sau, la găzduire, în România; backup-ul extern în UE, criptat cu chei deținute de primărie.

16Opțiuni de arhitectură și evaluare

Cinci decizii structurale, fiecare cu trei opțiuni reale, punctate de la 1 (slab) la 5 (foarte bun) pe criterii ponderate. Scorul total este suma ponderată. Opțiunea recomandată este prima în fiecare tabel.

16.1 Modelul de livrare

A câștigă pe control și vandabilitate, pierde pe cost de operare; consola de flotă și actualizările în valuri reduc exact acel dezavantaj. C rămâne o variantă de deployment a lui A, nu o arhitectură diferită.

16.2 Motorul de procese

Camunda 7 Community a ajuns la sfârșitul suportului în 2025, iar Camunda 8 este sursă disponibilă, nu open source; Flowable rămâne Apache 2.0, dar este Java. Temporal este excelent pentru orchestrare tehnică, nu pentru procese administrative editate de non-tehnici. Motorul propriu costă mai mult la început (aproximativ trei luni de echipă) și este cel mai ieftin pe zece ani.

16.3 Modelul de date

16.4 Stack-ul tehnic

Python rămâne pentru două componente de nișă, ca servicii auxiliare: semnarea și validarea PDF (pyHanko) și pipeline-urile AI unde ecosistemul este Python.

16.5 Inteligența artificială

Hibridul este permis ca opțiune a primăriei: un furnizor cloud din UE poate fi configurat ca adaptor pentru funcții neesențiale, dar implicit totul rulează local.

17Model de livrare și comercial

17.1 Ce cumpără primăria

17.2 Prețuri orientative

Prețurile sunt propuneri de pornire, fără TVA, calibrate pe pragurile de achiziție și pe capacitatea de plată a fiecărui nivel. Ele se validează în pilot.

Justificarea prețului de comună: la 45.000 lei licența, o comună plătește echivalentul a cinci luni de salariu al unui referent pentru un sistem care îi economisește ore pe zi la registratură, urbanism și secretariat și care o pune în legalitate la transparență. Prețul se afișează public pe site: primăriile compară oferte, iar transparența prețului scurtează vânzarea.

17.3 Piața adresabilă (estimare proprie)

Ținta realistă pe cinci ani: 400 de comune, 40 de orașe, 10 municipii, adică aproximativ 34 de milioane de lei din licențe și 5 milioane de lei pe an din mentenanță la final de perioadă.

17.4 Cum cumpără primăria

• Achiziție directă: produsul listat în catalogul electronic SEAP; primăria face referatul de necesitate (îi dăm modelul), compară cu alte oferte, cumpără din catalog. Durata: 2 – 4 săptămâni.
• Procedură simplificată pentru municipii: documentație de atribuire standard pe care o putem pune la dispoziție ca model neutru; 6 – 10 săptămâni.
• Finanțare: bugetul local (capitolul de investiții), programe naționale și europene pentru digitalizare locală când există apeluri (PNRR Fondul Local a finanțat sisteme de management local), programe ale consiliilor județene pentru comune.
• Fereastra politică: alegerile locale din 2028 fac din 2027 anul în care primarii vor rezultate vizibile; vânzarea se concentrează în 2027.

17.5 Implementarea, în opt săptămâni

1. Pornire. Decizia de implementare, desemnarea responsabilului de platformă și a secretarului general ca proprietar de procese, comanda hardware-ului, colectarea organigramei, statului de funcții, nomenclatorului arhivistic, HCL de taxe, PUG.
2. Instalare și organizație. Serverul instalat, structuri, posturi, conturi, roluri; delegările în vigoare; conturile consilierilor.
3. Catalog și procese. Activarea serviciilor din bibliotecă, adaptarea responsabililor și semnatarilor, taxele din HCL, calendarul; simulări cu secretarul general.
4. Registre, șabloane, migrare. Continuarea numerotării din registrele existente, importul registrelor din Regista sau Excel, șabloanele proprii ale primăriei, importul site-ului vechi și al MOL.
5. Hartă și integrări. Limite, străzi, adrese, digitizarea PUG (începe aici, continuă după lansare), conectarea softului de taxe, Ghișeul.ro, furnizorul de semnătură, e-Factura.
6. Instruire și pilot intern. Două zile de instruire pe roluri; registratura și un compartiment lucrează o săptămână în paralel cu hârtia.
7. Lansare internă și site. Biroul devine sistemul oficial; registrele pe hârtie se închid cu proces-verbal; Public înlocuiește site-ul vechi; MOL migrat.
8. Lansare publică. Portalul deschis, ROeID activ, campania de informare a cetățenilor (afiș, anunț, ghișeu asistat); 30 de zile de asistență intensivă.

17.6 Migrarea din sistemele existente

17.7 Suport și mentenanță

17.8 Parteneri

• Consilii județene și ADI: găzduirea instanțelor comunelor, nodul AI partajat, cofinanțare; în schimb, standardizare la nivel de județ și export MOL.
• Integratori locali: implementare și suport de proximitate în județe, pe bază de certificare; noi ținem produsul, ei relația.
• Furnizorii de taxe și contabilitate: acorduri de interoperabilitate; ei păstrează clientul pe partea lor, noi pe a noastră.
• Furnizorii de semnătură calificată: prețuri negociate pentru primării pe volum.
• ADR: acordul de colaborare pentru ROeID; publicarea procedurilor în ROePAS.

17.9 Echipa și planul

17.10 Costul de dezvoltare până la V1

Pragul de rentabilitate: aproximativ 35 de comune și 5 orașe vândute, sau un singur județ convins să echipeze comunele lui.

18Riscuri și indicatori de succes

18.1 Registrul riscurilor

18.2 Indicatori

19Nume și identitate

Criterii: pronunțabil de un secretar de comună și de un ministru, fără diacritice obligatorii în scris, cu sens legat de administrația locală, domeniu .ro liber, fără conflict evident de marcă, utilizabil și ca nume de produs intern („deschide în Edilia”). Am verificat 96 de nume în registrul ROTLD pe 20 octombrie 2026; mai jos sunt cele libere cu potențial. cityzen.ro este luat, la fel civitas.ro, civio.ro, edil.ro, urbis.ro, primariamea.ro, ghiseul.ro și toate variantele descriptive cu „primăria”.

20Pași următori

Decizii de luat de owner

1. Confirmarea modelului de livrare: instanță per UAT, licență perpetuă, mentenanță opțională (secțiunile 16.1, 17.1).
2. Confirmarea scopului V1 (secțiunea 4.1, etichetele V1) și a celor trei primării pilot.
3. Motorul de procese propriu, cu cost inițial mai mare (16.2).
4. Numele: Edilia sau alternativa (19).
5. Bugetul și echipa pentru 8 luni (17.10).

Ce urmează imediat după decizii

1. Specificația de produs pentru V1, derivată din acest studiu: fișele celor aproximativ 40 de servicii din V1, definițiile de proces, modelul de date detaliat, API-ul.
2. Prototip clicabil al Portalului, Biroului și Studio-ului pe design system, testat cu două primării (un secretar general, un registrator, trei cetățeni).
3. Prototip tehnic de două săptămâni: motorul de procese pe PostgreSQL cu procesul „petiție” complet, inclusiv termene, semnătură calificată la distanță cu un furnizor și publicare.
4. Planul de implementare pe luni, cu echipa, și contractul-cadru pentru pilot.
5. Înregistrarea numelui și a domeniilor; acordul de colaborare cu ADR pentru ROeID; discuții cu doi furnizori de taxe pentru interoperabilitate.

AGlosar

BSurse

Cercetare făcută pe 20 octombrie 2026. Legislația se citează după legislatie.just.ro; sursele de presă confirmă stările sistemelor naționale.

• Codul administrativ, OUG 57/2019, inclusiv Anexa 1 (Monitorul Oficial Local); Legea 544/2001; Legea 52/2003; OG 27/2002; Legea 50/1991 (art. 6 modificat prin Legea 193/2019); Legea 350/2001; OG 28/2008; Legea 98/2016 art. 7; Legea 273/2006; OMFP 1792/2002; Legea 455/2001; OUG 38/2020; Legea 135/2007; Legea 16/1996; Legea 179/2022; OUG 112/2018; OUG 155/2024 și Legea 124/2025; OSGG 600/2018.
• Praguri achiziții directe (270.120 lei; 900.400 lei): economica.net, 2022, „Pragurile pentru achizițiile directe au fost dublate”.
• Ghișeul.ro: răspunsul ADR din 2021 privind conectorii și comisionul (hotnews.ro, document ADR); profit.ro, 2025, privind UAT-urile neînrolate; g4media.ro privind obligația de înrolare din reforma administrației.
• ROeID: g4media.ro (Primăria Sectorului 6, prima înrolată); cursdeguvernare.ro, 2024, privind acordurile cu ADR; euronews.ro, ghid ROeID.
• RO Wallet: alfasign.ro, „EUDIW, stadiul implementării în 2026”; newsweek.ro și alba24.ro privind calendarul (31 octombrie 2026 sandbox, 14 ianuarie 2027 lansare).
• PNI: financialintelligence.ro și digi24.ro, mai 2026, privind anularea procedurii de achiziție; revistabiz.ro.
• ROePAS: economedia.ro, lansarea versiunii beta.
• SIIEASC: profit.ro și hotnews.ro, 2024 – 2025, privind extinderea la 2.909 UAT și certificatele digitale.
• e-Factura B2G: fiscalitatea.ro, alfasign.ro (ghid 2026), materiale ANAF.
• NIS2 în România: cms.law, wolftheiss.com, agerpres.ro privind ordinele DNSC 1 și 2 din 2025.
• AI Act și Omnibus: cooley.com, gibsondunn.com, cloudsecurityalliance.org, technology.org (octombrie 2026) privind Regulamentul 2026/1744 și termenul de 2 decembrie 2027.
• Modele: anunțurile Gemma 4 (aprilie 2026, Apache 2.0), listările Qwen3.6-27B (aprilie 2026, Apache 2.0), ghiduri comparative 2026 (Hugging Face, vellum.ai, benchlm.ai); OpenLLM-Ro (GitHub și Hugging Face); GlotOCR Bench (arXiv 2604.12978); „Open Source State-Of-the-Art Solution for Romanian Speech Recognition” (arXiv 2511.03361).
• Hardware: getdeploying.com și tech-insider.org, 2026, privind prețurile RTX 5090 și RTX PRO 6000.
• Piață: economedia.ro și financialintelligence.ro privind Regista (Zitec); indecosoft.ro; revistabiz.ro privind gradul de digitalizare al primăriilor.
• Domenii: interogări WHOIS la whois.rotld.ro, whois.verisign-grs.com și whois.eu, 20 octombrie 2026.