De ce orice modificare automată a site-ului trebuie aprobată

Orice sistem care poate modifica un site trebuie să primească o autorizație înainte de scriere. Faptul că o schimbare a fost generată rapid, a trecut câteva teste sau poate fi anulată nu îi conferă automat dreptul de publicare.

Aprobarea nu înseamnă neapărat că un om apasă un buton pentru fiecare virgulă. Modificările cu risc mic pot fi acoperite de o politică preaprobată, strict limitată. Dar nu există scriere legitimă fără o formă de autoritate: cineva a definit ce poate fi schimbat, în ce condiții, pe ce ținte, cu ce verificări și când permisiunea expiră.

Separarea dintre propune, aprobă și execută protejează conținutul, reputația, accesibilitatea, securitatea și continuitatea măsurării. Ea nu încetinește automatizarea; îi dă limite verificabile.

Autonomia de a genera nu este autoritatea de a publica

Un model poate scrie o introducere, recomanda un redirect sau modifica date structurate. Un agent poate chiar apela instrumente. Niciuna dintre aceste capacități nu stabilește dacă organizația acceptă afirmația, riscul juridic, efectul comercial sau impactul tehnic.

Autoritatea aparține unei persoane ori unei politici aprobate de organizație. Sistemul poate oferi dovezi și poate estima riscul, dar nu ar trebui să își extindă singur permisiunile pe baza propriei concluzii.

NIST AI RMF cere roluri și responsabilități clare și procese documentate pentru supravegherea configurațiilor om–AI. Este un principiu de guvernanță, nu o prescripție că toate organizațiile trebuie să folosească aceeași interfață.

Ce risc introduce o schimbare aparent banală

O modificare de conținut poate părea locală, dar poate avea efecte în mai multe straturi:

• factual — publică o dată, o funcție sau o certificare greșită;
• juridic și comercial — schimbă o promisiune, un preț, un termen contractual sau o comparație;
• SEO — modifică intenția paginii, canonicalul, indexabilitatea ori internal linkingul;
• accesibilitate — elimină titluri, alt text, etichete sau contrast necesar;
• tehnic — rupe markupul, schema, template-ul sau cache-ul;
• operațional — repetă schimbarea pe sute de URL-uri ori declanșează alte automatizări;
• de securitate — transformă un output influențat extern într-o acțiune privilegiată.

OWASP descrie prompt injection inclusiv prin conținut extern, iar categoria Excessive Agency arată riscul acțiunilor produse din outputuri neașteptate sau manipulate. Un gate de aprobare nu rezolvă singur securitatea, dar întrerupe traseul direct dintre input neverificat și publicare.

Aprobarea trebuie proporționată după risc

Nu tratăm corectarea unui spațiu și schimbarea unui preț cu același proces. O matrice simplă folosește impactul și raza de propagare:

Nivel	Exemple	Autorizație minimă
scăzut	formatare sigură, typo fără schimbare de sens, un singur URL	politică preaprobată, teste automate, jurnal și limită strictă
mediu	titlu, introducere, legături interne, date structurate	aprobare editorială explicită pe diff
ridicat	afirmații comerciale, prețuri, canonical, redirect, multe pagini	doi ochi potriviți riscului și fereastră controlată de execuție
critic	legal, securitate, plăți, autentificare, template global	change process formal, owner de sistem și plan testat de revenire

Clasificarea depinde de context. Un typo într-o clauză contractuală poate fi critic, iar o actualizare repetitivă de markup poate avea blast radius mare chiar dacă fiecare diferență este mică.

Politică preaprobată nu înseamnă permisiune nelimitată

Pentru lucrările previzibile putem autoriza o clasă de schimbări înainte de apariția fiecărui caz. Politica trebuie să specifice:

• câmpurile și tipurile de conținut permise;
• URL-urile sau mediile eligibile;
• regulile exacte și testele obligatorii;
• numărul maxim de pagini și ritmul execuției;
• condițiile care cer escaladare;
• data expirării și ownerul politicii.

Dacă sistemul întâlnește o afirmație comercială, un fragment necunoscut sau o țintă în afara listei, se oprește. Nu „interpretează creativ” autorizația. Preaprobarea reduce clicurile, nu elimină responsabilitatea.

Ce trebuie să vadă aprobatorul

O cerere de aprobare nu poate fi doar „îmbunătățește pagina pentru AI”. Persoana care decide are nevoie de un pachet minim:

• ținta exactă: URL, tip de conținut și identificator intern;
• versiunea curentă și diferența înainte/după;
• motivul schimbării și dovezile care îl susțin;
• câmpurile afectate și raza de propagare;
• nivelul de risc, dependențele și efectele secundare cunoscute;
• rezultatele testelor editoriale, tehnice, SEO și de accesibilitate;
• fereastra de execuție și condițiile de anulare;
• metoda de revenire și verificarea după publicare.

Acesta nu este încă întregul execution bundle; este minimul necesar unei decizii informate. Analiza inițială poate porni de la checklistul pentru auditarea unui articol pentru GEO și AEO.

Aprobarea aparține unei versiuni exacte

Cea mai periculoasă eroare subtilă este aprobarea unei idei, urmată de executarea altui fișier. Cererea trebuie legată de conținutul exact analizat. Dacă textul, ținta, sursele ori contextul se schimbă, aprobarea devine invalidă.

Regula rezolvă problema „time of check versus time of use”: pagina poate fi editată de altcineva între aprobare și execuție. În acel caz, sistemul nu suprascrie noua versiune și nu încearcă să combine automat diferențele. Regenerează propunerea pe baza stării actuale și cere reaprobare.

W3C PROV oferă un model general pentru atribuirea entităților, activităților și agenților și pune accent pe proveniență, versiuni și reproductibilitate. Nu este obligatorie implementarea completă a ontologiei; principiul util este să putem demonstra cine a aprobat ce versiune și ce proces a transformat-o.

Stările deciziei trebuie să fie explicite

Un flux sănătos nu are doar „da” și „nu”. El diferențiază:

• propus — schimbarea există, dar nu are autoritate;
• validat tehnic — testele au trecut, fără a echivala cu aprobarea;
• necesită modificări — aprobatorul cere corecții și o versiune nouă;
• respins — nu se execută, iar motivul rămâne în jurnal;
• aprobat — numai versiunea și condițiile declarate pot fi executate;
• expirat — fereastra s-a închis ori precondițiile nu mai sunt adevărate;
• executat — operația a rulat, dar nu este încă verificată;
• verificat — starea live corespunde schimbării aprobate și testele post-publicare au trecut.

Starea „executat” nu este sinonimă cu succes. Un API poate răspunde 200, iar pagina să fie ascunsă de cache, să aibă schema invalidă sau să fi declanșat o problemă de randare.

Separarea rolurilor reduce conflictul de interes

Pentru schimbările importante, entitatea care generează propunerea nu ar trebui să fie și singurul aprobator. Separăm pe cât posibil:

• autorul sau sistemul care propune;
• validatorul care rulează testele;
• ownerul editorial, tehnic ori juridic care aprobă;
• executorul cu permisiuni minime;
• verificatorul rezultatului live.

O echipă mică poate combina roluri, dar trebuie să păstreze decizia explicită. Pentru risc ridicat, principiul „patru ochi” este mai valoros decât o semnătură automată produsă de aceeași componentă care a generat schimbarea.

NIST AI RMF Playbook recomandă documentarea autorităților delegate, a rolurilor, a testării, a planurilor de deployment, monitorizare și change management. Aplicăm aceste idei proporțional, fără a transforma un site mic într-o birocrație federală.

Exemplu: o aprobare corectă devine invalidă înainte de execuție

Un sistem propune pentru o singură pagină schimbarea titlului, rescrierea introducerii și corectarea unei afirmații factuale. Atașează sursa primară, diff-ul, testele de linkuri și schema și baseline-ul paginii. Schimbarea este clasificată mediu deoarece alterează o afirmație publică.

Editorul aprobă exact versiunea 7 pentru URL-ul declarat, cu execuție în următoarele 24 de ore. Nu aprobă alte pagini și nu acordă permisiune permanentă pentru „schimbări similare”.

Înainte de execuție, un coleg publică versiunea 8, adăugând un paragraf necesar. Precondiția „pagina live este versiunea 7” nu mai este adevărată. Sistemul oprește operația, recalculează diff-ul față de versiunea 8 și trimite o cerere nouă. Nu suprascrie munca și nu aplică aprobarea veche unei combinații pe care editorul nu a văzut-o.

Acest control este mai important decât viteza. Baseline-ul necesar înaintea intervenției este explicat separat în ghidul pentru construirea unui baseline de conținut.

Revisions și rollback sunt necesare, dar nu înlocuiesc aprobarea

WordPress păstrează revizii pentru drafturi și actualizări publicate și permite compararea și restaurarea lor. Este o plasă de siguranță valoroasă.

Dar revenirea are limite:

• o afirmație greșită poate fi indexată sau distribuită înainte de restaurare;
• un preț ori o promisiune publică poate produce efecte care nu se „undo”;
• o modificare poate declanșa cache, feeduri, emailuri sau webhookuri;
• restaurarea conținutului nu repară automat efectele din sisteme externe;
• fără verificare, putem reveni la o versiune care avea deja alte probleme.

Rollback-ul reduce timpul de recuperare. Aprobarea reduce probabilitatea să avem nevoie de el. Sunt controale complementare.

Controlul editorial protejează și SEO-ul, nu doar securitatea

Publicarea automată la scară poate transforma o optimizare aparentă într-o problemă de calitate. Politicile Google privind spamul definesc scaled content abuse prin pagini produse în principal pentru manipularea rezultatelor și cu valoare redusă, indiferent de metoda de creare. Ghidul Google despre conținutul generativ cere respectarea Search Essentials și valoare pentru utilizator.

Aprobatorul nu verifică doar gramatica. El întreabă dacă pagina are un scop distinct, dacă afirmațiile sunt susținute, dacă schimbarea păstrează intenția canonică și dacă nu creează canibalizare. Pentru accesibilitate, testele trebuie raportate la standardul stabil curent; W3C recomandă utilizarea WCAG 2.2.

După aprobare urmează verificarea, nu uitarea

Execuția trebuie să confirme că a modificat numai ținta aprobată. Verificarea minimă include:

• răspunsul URL-ului și conținutul live;
• canonical, robots, schema și legături;
• randarea vizuală și accesibilitatea;
• absența schimbărilor în pagini neautorizate;
• corespondenta dintre diff-ul aprobat și rezultatul publicat;
• monitorizarea erorilor și a indicatorilor stabiliți în baseline.

Pentru efectul asupra vizibilității, nu atribuim imediat orice variație intervenției. Articolul despre măsurarea impactului unei intervenții GEO separă execuția reușită de dovada impactului.

Checklist pentru un gate de aprobare credibil

• scrierea este imposibilă fără autorizație explicită sau politică preaprobată;
• permisiunile executorului sunt limitate la țintele necesare;
• aprobatorul vede diff-ul, dovezile, riscul și testele;
• aprobarea este legată de versiune, țintă și termen de expirare;
• schimbarea precondițiilor invalidează autorizația;
• cazurile neclare și depășirile de scop sunt oprite, nu ghicite;
• decizia și motivul sunt păstrate într-un audit trail;
• rollback-ul este posibil și testat proporțional cu riscul;
• starea live este verificată după execuție;
• impactul este măsurat față de un baseline, nu presupus.

Automatizarea bună nu elimină decizia umană; o face mai informată și mai precisă. Sistemul pregătește dovezile, calculează diferența, rulează testele și execută exact ce a fost autorizat. Omul sau politica organizației stabilește limitele în care acea putere poate fi folosită.

Surse

• NIST — AI Risk Management Framework Core
• NIST — AI RMF Playbook: Govern
• OWASP — LLM01:2025 Prompt Injection
• OWASP — LLM06:2025 Excessive Agency
• Google Search Central — Spam policies
• Google Search Central — Guidance on generative AI content
• WordPress.org — Revisions
• W3C WAI — WCAG 2 Overview
• W3C — PROV Overview

Sursele au fost reverificate la 2 august 2026. NIST precizează că AI RMF 1.0 este în curs de actualizare; articolul folosește cadrul voluntar ca reper de guvernanță, nu ca obligație universală. Textul descrie un control editorial și tehnic și nu afirmă existența unei funcții AYSA deja lansate.