AI Act pentru un SaaS WordPress cu agenți AI

Ghid pentru un SaaS WordPress cu agenți AI: roluri upstream/downstream, transparență, permisiuni, aprobări, versiuni, teste și dovezi de release.

Publicat 2 august 20264 minute

AI ACT · SAAS ȘI AGENȚI

Un produs care conectează un model general la WordPress nu este doar „un prompt cu interfață”. În momentul în care citește date, decide pași și poate modifica website-ul, produsul are propriul scop, propriile limite și un lanț de responsabilitate care trebuie documentat.

Separă modelul upstream de sistemul tău

Furnizorul modelului GPAI documentează modelul și își îndeplinește obligațiile proprii. SaaS-ul downstream combină modelul cu prompturi, surse, memorie, permisiuni, instrumente și interfață pentru un scop concret. Folosirea API-ului nu te face automat furnizorul modelului GPAI, dar poți avea rol de provider pentru sistemul pus pe piață sub propriul nume. ^[EU-REG] ^[EU-GPAI-G] ^{[EU-GPAI-OBL]}

Fișa de produs trebuie să numească modelul și versiunea, scopul prevăzut, utilizatorii, datele, funcțiile, limitele, cazurile excluse și dependențele. Nu copia limitele modelului upstream ca și cum ar descrie întregul SaaS: orchestrarea și accesul la WordPress pot crea erori pe care model card-ul nu le acoperă. ^[EU-GPAI-G] ^[OAI-ACT]

Definește autonomia pe niveluri

Nivelul 0 doar explică; nivelul 1 recomandă; nivelul 2 pregătește un draft; nivelul 3 execută după confirmare; nivelul 4 execută în limite preautorizate. Fiecare instrument WordPress — citire, editare, publicare, pluginuri, utilizatori, redirecturi — primește cel mai mic nivel și cea mai mică permisiune necesară. ^[EU-LIT] ^[EU-REG]

Publicarea, ștergerea, schimbarea permisiunilor și modificările dificil de reversat cer rezumat al efectului și confirmare explicită. Sistemul trebuie să distingă întrebarea de comandă și să evite transformarea unei formulări ambigue într-o acțiune. Draftul este control tehnic, nu simplă preferință editorială. ^[EU-LIT] ^[EU-REG]

Transparența începe în interfață

Dacă agentul interacționează direct cu o persoană, articolul 50 cere informarea clară de la începutul primei interacțiuni, cu o excepție interpretată restrictiv când natura AI este evidentă. Denumirea „copilot” sau avatarul nu sunt suficiente. Interfața spune că este AI, scopul și limita acțiunilor. ^[EU-A50] ^[EU-A50-G]

Pentru administratorul site-ului, transparența înseamnă și un jurnal inteligibil: ce a cerut utilizatorul, ce surse au fost citite, ce model și versiune au rulat, ce instrument a fost apelat, ce schimbare a fost propusă, cine a aprobat și ce s-a executat. Nu păstra mai multe date decât justifică scopul jurnalului. ^[EU-LIT] ^[EU-REG] ^[EDPB-28]

Release-ul trebuie să aibă o mapă de dovezi

Pentru fiecare release păstrează scopul și clasificarea revizuite, modelele și furnizorii, changelogul, testele, limitele cunoscute, setul de permisiuni, textele de transparență, rezultatele de securitate, aprobarea și planul de rollback. O modificare de prompt poate fi materială chiar dacă nu schimbă versiunea pluginului. ^[EU-REG] ^[EU-GPAI-G] ^[EU-LIT]

Setul de test include site gol și site mare, permisiuni insuficiente, plugin incompatibil, eroare API, limbă diferită, sursă contradictorie, instrucțiuni malițioase în pagină, comandă ambiguă, anulare și rollback. Testează efectul în WordPress, nu doar textul pe care îl produce modelul. ^[EU-LIT] ^[EU-REG]

Schimbarea modelului este schimbare de produs

Un model nou poate modifica refuzurile, costul, lungimea contextului, limbile, utilizarea instrumentelor și profilul de eroare. Nu promova automat aliasul furnizorului în producție. Rulează evaluările, compară rezultatele și păstrează posibilitatea de pinning sau rollback. Reanalizează rolul dacă modificarea modelului ori a sistemului este substanțială. ^[EU-GPAI-G] ^[OAI-ACT]

Păstrează un mod degradat: analiză fără execuție, draft fără publicare sau funcții clasice când modelul nu este disponibil. Un produs sigur nu transformă indisponibilitatea furnizorului într-o invitație de a ocoli aprobările. Statusul și limitele trebuie să fie vizibile administratorului. ^[EU-LIT] ^[EU-REG]

Modelul prudent pentru AYSA.AI

Ca model recomandat, AYSA.AI ar inventaria fiecare agent după scop și instrumente, ar păstra versiuni de model și prompt, ar limita permisiunile, ar explica interacțiunea AI, ar produce implicit drafturi, ar cere confirmare pentru acțiuni și ar lega fiecare release de teste și rollback. Acestea sunt criterii de produs, nu afirmații despre implementarea actuală. ^[EU-REG] ^[EU-A50] ^[EU-LIT]

Înaintea unei clasificări finale trebuie cunoscute funcțiile reale, scopul prevăzut, clienții, datele și consecințele. Un instrument SEO sau de productivitate nu este automat high-risk; nici eticheta „low risk” nu este certificat oficial. Folosește textul legal și instrumentele Service Desk, iar cazurile sensibile merg la evaluare specializată. ^[EU-RISK] ^[EU-DESK] ^[EU-REG]