De ce infrastructura controlată de AI are nevoie de dovezi, nu doar de permisiuni

Pe vremuri, modificările de infrastructură erau simple. Un inginer senior se conecta la server, rula o comandă și spera că documentația era actualizată. Astăzi, delegăm sarcini complexe unor agenți AI – migrări, ajustări de capacitate, patch-uri de securitate – și avem nevoie de un mod mai bun de a verifica dacă aceste operațiuni sunt sigure.

Modelul tradițional de securitate nu mai ține pasul.

De ce RBAC nu mai e suficient în era AI

Majoritatea sistemelor de protecție din producție funcționează cam așa:

RBAC spune: „Acest utilizator poate scrie în producție.”
GitOps spune: „Aceasta este starea dorită.”

Dar niciunul nu răspunde la întrebarea esențială: „De ce este sigură această modificare exact acum?”

Când un om rulează o comandă, aduce cu el context, experiență și judecată. Când un agent AI cere o modificare în producție – mai ales una complexă, cum ar fi o migrare de bază de date – lipsește complet stratul de explicație. Verificăm doar permisiunile, nu raționamentul.

Problema devine critică la operațiunile cu stare. O migrare de schemă, un transfer de date sau o modificare de configurație nu înseamnă doar „aplici niște YAML”. Este o secvență de pași ireversibili, cu dependențe, cerințe de rollback și constrângeri de timp. Sistemul de control al accesului nu vede nimic din toate acestea.

Cum arată un control bazat pe dovezi

O abordare mai bună presupune atașarea unei dovezi criptografice la fiecare modificare propusă, înainte de execuție. Practic, semnezi schimbarea.

Fluxul arată astfel:

1. Agentul propune modificarea – cu toate detaliile și raționamentul
2. Sistemul generează dovada – validare criptografică a siguranței
3. Motorul de politici evaluează – respectă regulile de autorizare?
4. Verificarea semnăturii – totul este intact sau a fost alterat?
5. Execuția – doar dacă toate filtrele sunt trecute
6. Înregistrarea – jurnal complet, cu pași și motive

Dovada include validări multiple: dry-run pe infrastructura reală, detectarea drift-ului, scanări de securitate, SBOM, digest-uri de imagini, proveniența build-urilor, impactul estimat asupra SLO-urilor și verificarea lanțului de evenimente. Toate acestea sunt semnate, timestampate și stocate alături de artifactele de release.

Exemplu real: migrarea din Oracle în PostgreSQL

Să luăm o situație concretă. Migrarea unui sistem Oracle/APEX în PostgreSQL pe Kubernetes, cu date live, nu cu demo-uri.

Pașii includ: verificarea clusterului, aprobări de fereastră de schimbare, înghețarea sursei, exportul datelor, crearea punctelor de restore, extinderea schemei, setup-ul tabelelor shadow, verificarea rând cu rând, redirecționarea traficului și validarea finală. Este un proces cu pași ireversibili și zero toleranță la erori.

Când un agent AI cere execuția acestei secvențe, poarta de validare captează 23 de verificări, 20 de evenimente intermediare, 20 de artifacte de dovadă și un scor final de 100%. Semnătura ed25519 permite verificarea ulterioară cu torque proof verify --require-signature. Nimic nu a fost falsificat.

Poarta prinde ce scapă oamenilor

Chiar și cu dovada în loc, sistemul cere autorizare explicită. O grafă de validare validă nu înseamnă automat „poți continua”.

În teste, aceeași cerere a fost respinsă de două ori: o dată pentru că nu exista o intrare explicită în lista de permisiuni, a doua oară pentru că semnătura criptografică nu mai era validă (cineva modificase o piesă din dovadă). Asta înseamnă apărare în profunzime: ai nevoie și de dovadă, și de politică.

De ce contează pentru infrastructura ta

Instrumentele clasice de GitOps și RBAC (Argo CD, Crossplane) au fost create înainte ca operațiunile autonome să devină obișnuite. Ele pot spune cine are voie să scrie și care este starea dorită, dar nu pot explica de ce o anumită modificare este sigură acum.

Pe măsură ce treci la deployment-uri asistate de AI, scalare autonomă, migrări multi-cloud sau workload-uri cu cerințe stricte de conformitate, ai nevoie de un sistem care să explice criptografic fiecare schimbare din producție.

Pași practici

Dacă rulezi Kubernetes și lucrezi cu migrări complexe sau operațiuni conduse de agenți, începe cu:

1. Generarea de dovezi – poate sistemul tău crea dovezi criptografice pentru fiecare modificare?
2. Politici ca cod – liste explicite de operațiuni permise pentru agenți
3. Jurnale de audit – înregistrări semnate, cu raționament inclus
4. Scoruri de validare – încredere cuantificată că o modificare poate fi rulată

Lumea infrastructurii se îndreaptă spre operațiuni autonome. Controlul schimbărilor trebuie să evolueze și el – de la „ai permisiune?” la „iată dovada că e sigur și de ce”. Doar așa poți dormi liniștit când agentul AI rulează migrări în producție la 3 noaptea.