Securitatea AI: 7 măsuri esențiale după avertismentul lui Nadella

Când discutăm despre securitatea AI, un asistent care scrie o primă variantă de text reprezintă un caz. Un agent care poate citi datele clienților, modifica fișiere și transmite informații mai departe reprezintă un caz diferit. În momentul în care îi oferim modelului instrumente, calitatea răspunsului devine doar o parte a problemei. Trebuie să știm și ce are voie să facă sistemul, cum sunt controlate acțiunile și cine îl poate opri.

Pe 10 octombrie 2026, directorul general al Microsoft, Satya Nadella, a publicat eseul „Models as Insider Risks in the Super Intelligence Era”. Ideea sa principală este că mecanismele de securitate trebuie să existe în afara modelului. Este o direcție utilă pentru dezbaterea despre securitatea AI.

În același timp, mesajul vine la câteva zile după o serie de anunțuri Microsoft care privesc tocmai controlul, administrarea agenților și AI-ul local. Avem, așadar, motive să citim textul cu interes tehnic, dar și cu scepticism comercial. Pentru o companie norvegiană, cel mai important este ce înseamnă aceste principii în practică: cum folosim tehnologia fără să îi acordăm mai multă autoritate decât cere sarcina?

Acest ghid separă declarațiile documentate, evaluarea noastră și propunerile concrete pentru fluxuri de lucru mai sigure. Exemplele practice sunt situații ipotetice, nu descrieri ale unor incidente petrecute la clienții Kodemagisk.

Securitatea AI

Prin securitatea AI înțelegem aici menținerea unui asistent sau agent în limitele unui mandat clar. Sistemul trebuie să poată ajuta la îndeplinirea sarcinii, dar accesul la date, instrumente și acțiuni trebuie să fie limitat și verificabil. Un răspuns bun este valoros. Totuși, un răspuns bun oferit de un sistem cu drepturi inutil de largi poate reprezenta o soluție slabă.

Acest lucru contează mai ales când o companie trece de la a cere sfaturi unui chatbot la conectarea AI-ului direct la propriile sisteme. Un asistent de redactare poate propune un răspuns pentru client. Un agent cu acces la e-mail îl poate trimite. Un asistent poate explica o modificare de cod. Un agent cu acces la mediul de producție o poate aplica. Diferența constă în consecințele unei erori.

Securitatea trebuie, așadar, evaluată împreună cu utilitatea. Întrebați ce necesită efectiv sarcina și ce se poate întâmpla dacă o neînțelegere se transformă într-o acțiune. O propunere de titlu pentru blog are nevoie de un alt flux de lucru decât modificarea informațiilor de plată. Ambele pot folosi modele lingvistice, dar nu există prea multe motive să le acordăm aceleași drepturi.

Recomandăm să începeți cu o schemă simplă: ce informații poate citi sistemul, ce propuneri poate face și ce acțiuni poate executa. Schema trebuie să fie inteligibilă atât pentru cel care comandă soluția, cât și pentru cel care o construiește. Dacă descrierea spune doar că agentul „are acces la instrumentele companiei”, mandatul este prea vag pentru o evaluare adecvată.

De ce un model lingvistic necesită alte mecanisme de control

Este tentant să spunem că software-ul obișnuit este inteligibil, iar AI-ul este o cutie neagră. Diferența este însă mai nuanțată. Și software-ul tradițional poate fi complex, poate avea multe dependențe și poate fi dificil de depanat. Totuși, un dezvoltator poate adesea examina regulile concrete, schimbările de stare și execuția care au dus la un rezultat.

Un răspuns generat nu oferă, prin el însuși, o vizibilitate comparabilă asupra motivului pentru care modelul a ales exact acea formulare sau acțiune. O explicație bine formulată de agent nu trebuie, prin urmare, folosită ca singura dovadă că sarcina a fost rezolvată corect. Verificați rezultatul în raport cu sursele, așteptările și starea efectivă a sistemelor folosite.

Gândiți-vă la un agent care spune că a modificat doar descrierea unui produs. Ceea ce contează este ce câmpuri a înregistrat efectiv sistemul de conținut ca fiind modificate. O explicație îl poate ajuta pe redactor să înțeleagă propunerea. Istoricul modificărilor oferă o bază diferită și mai concretă pentru verificare. Când ambele sunt disponibile, este mai ușor să depistați o abatere înainte să o vadă clientul.

Ideea este practică: construiți mecanismele de control în jurul unor acțiuni observabile și al unor drepturi clare. Compania nu trebuie să înțeleagă toate detaliile unui model lingvistic pentru a cere ca publicarea, modificarea accesului și alte operațiuni importante să respecte reguli proprii.

Ce solicită, de fapt, Nadella

Nadella propune să tratăm modelul ca pe un posibil risc intern: acesta are acces și capacități, dar nu trebuie să fie propria instanță de control. Eseul descrie diversitatea modelelor, urme lizibile și protejate împotriva manipulării, verificare continuă, controale și audituri independente, izolare și transparență privind incidentele. El menționează și responsabilitatea umană, precum și posibilitatea ca o persoană autorizată să oprească sistemul în timpul execuției. Citiți eseul original pe X.

Acesta este un argument în favoarea mecanismelor de control din jurul modelului. A planifica pornind de la posibilitatea ca un model să fie compromis este o ipoteză de securitate, nu dovada unui atac real.

Spre final, el scrie:

It will be the one that enables us to trust the model the least.

Un sistem robust ar trebui, așadar, să se bazeze cât mai puțin pe încrederea în model. Sursa: Nadella.

Instrumentele Microsoft: ce este disponibil acum?

Microsoft a publicat mai multe anunțuri relevante pe 7 octombrie 2026. Acestea acoperă componente diferite ale activității agenților și au stadii diferite de disponibilitate. Tabelul prezintă descrierile producătorului așa cum existau la analiza din 12 octombrie. Nu reprezintă un test independent al produselor.

Stadiile provin din anunțul tehnic Microsoft despre MXC, anunțul despre Windows și anunțul despre Surface.

MXC stabilește limite, dar configurația este decisivă

Microsoft descrie MXC ca pe un strat care aplică politicile de acces în afara controlului agentului. Soluția poate limita, printre altele, accesul la fișiere și la rețea. Documentația distinge între mai multe forme de izolare și moduri de operare. Un detaliu important este că „Permissive” înregistrează accesul pe care politica l-ar fi respins, dar permite continuarea operațiunii. „Learning” blochează și înregistrează. „Enforcement” aplică limitele fără acest raport de activitate. Sursa: Windows Developer Blog.

Evaluarea noastră: o companie ar trebui să primească o demonstrație a configurației efective. Un nume de produs sau un raport activat nu arată, prin ele însele, dacă accesul nedorit este oprit. Cereți furnizorului să încerce o operațiune pe care agentul nu ar trebui să o poată efectua și să arate rezultatul în sistemul țintă. Completați limitarea accesului cu propria jurnalizare a acțiunilor importante. Astfel obțineți un răspuns concret despre ce protejează configurația și ce necesită în continuare alte măsuri.

HydraFusion rutează sarcinile; asta nu dovedește securitatea

Microsoft și GitHub descriu HydraFusion ca pe un orchestrator care poate alege unul sau mai multe modele în funcție de performanță, cost și latență. Extensia pentru Windows ar urma să poată folosi și modele locale; o versiune experimentală preliminară era anunțată pentru mai târziu în octombrie. Surse: explicația tehnică și anunțul despre Windows.

Evaluarea noastră: acest tip de rutare poate fi util, dar trebuie evaluat separat de verificarea unei decizii importante. Faptul că un sistem poate folosi mai multe modele nu arată cine verifică rezultatul, pe ce date se bazează verificarea sau dacă execuția poate fi blocată. Când un furnizor folosește termeni precum „mai multe modele” într-un argument de securitate, cereți o explicație a fluxului concret de lucru și a situațiilor de eroare pe care acesta trebuie să le gestioneze.

Surface Laptop Ultra: capacitatea locală este doar o parte din ansamblu

Microsoft indică un preț de pornire recomandat de 2.599 de dolari americani și până la 128 GB de memorie unificată, în funcție de configurație. Precomenzile au început pe 7 octombrie, cu disponibilitate din 16 octombrie. Memoria maximă nu reprezintă, așadar, ceea ce include prețul de pornire. Sursa: Microsoft Devices Blog.

Evaluarea noastră: rularea locală a modelelor poate fi interesantă când o companie vrea să controleze unde are loc procesarea. Dar și un agent local are nevoie de un mandat clar. Dacă fluxul de lucru trimite date prin alte instrumente sau are acces la dosare de care nu are nevoie, simpla localizare a modelului nu rezolvă problema. Evaluați fluxul de date de la început până la sfârșit înainte să cumpărați hardware pentru a obține control. Este o chestiune de arhitectură în aceeași măsură în care este o chestiune de capacitate.

Când mesajul despre securitate susține și o afacere

Este rezonabil să observăm o legătură comercială între noile instrumente Microsoft și mesajul lui Nadella despre securitate. Controlul, identitatea agenților, orchestrarea modelelor și capacitatea locală sunt atât nevoi tehnice, cât și domenii în care compania dorește să vândă soluții. Aceasta este interpretarea noastră editorială asupra momentului și conținutului declarațiilor documentate.

Eseul nu numește produsele. Nu avem, prin urmare, o bază pentru a-l prezenta drept o încercare demonstrată de a ascunde un catalog comercial. O critică mai solidă este și mai utilă: principiile bune de securitate trebuie să poată fi evaluate independent de furnizorul care le prezintă. O companie ar trebui să poată solicita aceleași mecanisme de control de la Microsoft, de la alte platforme sau pentru o soluție proprie.

Acest lucru necesită întrebări la care se poate răspunde printr-o demonstrație. Puteți opri o execuție fără să așteptați ca agentul să respecte o instrucțiune? Cine poate modifica drepturile? Ce acțiuni sunt înregistrate? Ce se întâmplă dacă modelul întâlnește un text care îl îndeamnă să depășească sarcina? Ce componente ale configurației continuă să funcționeze dacă schimbați modelul?

Merită să verificați și cine controlează afirmațiile furnizorului. Un reprezentant de vânzări poate prezenta un exemplu bun, iar un dezvoltator poate explica un proiect bine gândit. Ambele sunt utile. Totuși, înainte ca sistemul să primească drepturi mai largi, compania ar trebui să ceară teste care pun soluția la încercare și să solicite unei persoane fără responsabilitate pentru vânzare să evalueze constatările.

Interesul comercial nu face ca un sfat de securitate să fie greșit. Face însă necesară separarea sfatului de decizia de cumpărare. Începeți cu riscul pe care doriți să îl reduceți. Formulați o cerință măsurabilă. Comparați apoi modul în care soluțiile posibile îndeplinesc cerința. Astfel, achiziția este ghidată de nevoie, iar o lansare spectaculoasă de produs nu ajunge să definească de la început întreaga problemă.

Amodei aduce în discuție o altă parte a aceleiași dezbateri

Linkul către „We Must Pace the Frontier” al lui Dario Amodei, datat septembrie 2026, duce la un alt eseu decât cel al lui Nadella. Amodei propune evaluatori externi cu acces continuu, coordonare între țările democratice și companii și un demers mai amplu de coordonare globală. El argumentează că ritmul dezvoltării trebuie să lase timp activității de securitate să țină pasul.

Evaluarea noastră este că aceste perspective se pot completa reciproc. O întrebare privește mecanismele de control din jurul unui agent folosit astăzi. O alta privește modul în care sunt dezvoltate și examinate cele mai mari modele. Companiile norvegiene au o influență limitată asupra celei de-a doua, dar pot impune cerințe concrete soluțiilor pe care le folosesc.

Nu există, așadar, prea multe motive să așteptați un consens asupra direcției întregii industrii AI înainte să stabiliți cine poate publica din sistemul de conținut, ce date ale clienților poate citi un asistent sau cum se oprește o automatizare. Aceste alegeri țin de puterea de decizie a companiei. Măsurile care urmează reprezintă propunerea noastră pentru începutul acestui demers.

Acces minim: începeți cu sarcina

OWASP descrie „Excessive Agency” drept riscul asociat cu prea multe funcționalități, drepturi prea largi și prea multă autonomie. Proiectul recomandă, printre altele, aprobarea umană a acțiunilor importante și aplicarea drepturilor de acces în sistemele folosite de agent. Recomandările de mai jos concretizează aceste nevoi de control prin propriile noastre fluxuri de lucru ipotetice.

Oferiți unui agent AI numai accesul de care are nevoie pentru o anumită sarcină. Astfel limitați ce poate merge prost când agentul înțelege greșit o instrucțiune, folosește informații greșite sau este influențat de conținutul pe care îl citește. O descriere bună a comportamentului dorit este utilă, dar regulile de acces trebuie aplicate de sistemul din jurul modelului.

Începeți cu o întrebare simplă: ce trebuie să facă efectiv agentul? Rezumarea unei comenzi necesită un alt acces decât schimbarea adresei de livrare. Redactarea unei propuneri pentru un articol de blog necesită un alt acces decât publicarea lui. Dacă toate sarcinile primesc același acces larg, compania pierde posibilitatea de a controla separat consecințele fiecăreia.

Imaginați-vă un magazin online care testează un agent pentru relațiile cu clienții. Acesta este un exemplu ipotetic. Agentul trebuie să găsească starea unei comenzi și să propună un răspuns pentru client. Poate avea nevoie de numărul comenzii, starea livrării și informațiile relevante despre produs. Nu are nevoie de întregul registru de clienți, de informații de plată sau de posibilitatea de a iniția rambursări. Un instrument limitat, care extrage o anumită comandă, oferă o graniță mai clară decât accesul general la baza de date.

Stabiliți și la ce clienți, documente și spații de lucru poate avea acces agentul. Accesul la cazul unui client nu trebuie să ofere automat acces la toate celelalte cazuri. Sistemul trebuie să verifice drepturile utilizatorului de fiecare dată când agentul solicită informații. Modelul nu trebuie să decidă cui îi aparține o cerere sau ce drepturi conferă aceasta.

Această parte a securității AI presupune adesea precizarea mai atentă a mecanismelor existente de administrare a accesului. Notați acțiunile permise, necesarul estimat de date și acțiunile care cer intervenția unei persoane. Astfel, atât dezvoltatorii, cât și responsabilii companiei au o bază concretă pentru a evalua dacă accesul este adecvat.

Separați citirea, propunerea și acțiunea

Împărțiți fluxul de lucru în etape cu drepturi diferite. Agentul poate mai întâi citi anumite informații, apoi elabora o propunere și, în final, solicita unui sistem separat să execute o acțiune aprobată. Nu permiteți ca o etapă de citire reușită să deschidă automat calea către publicare, plată sau modificarea datelor clienților.

Nici accesul de citire nu este lipsit de risc. Informațiile pot fi transmise mai departe dacă agentul poate, în același timp, folosi servicii externe, trimite mesaje sau deschide adrese web arbitrare. Analizați, așadar, împreună accesul la informații și posibilitatea de a le transmite în exterior. Un agent care trebuie să facă rezumate interne rareori are nevoie de libertatea de a trimite conținut unor destinatari externi.

Pentru un dezvoltator, aceasta poate însemna construirea unor instrumente mici, cu parametri clari. Un instrument pentru propunerea unei rambursări poate returna suma și justificarea fără să transfere bani. Un alt instrument poate efectua rambursarea după trecerea verificărilor necesare. Verificați limitele de sumă, destinatarul și legătura cu comanda în codul obișnuit, inclusiv atunci când modelul oferă o propunere convingătoare.

Faceți tranzițiile vizibile pentru utilizator. O propunere salvată ca ciornă trebuie să apară ca o ciornă. Un buton care aprobă trimiterea trebuie să arate ce se trimite și cui. Dacă utilizatorul crede că agentul doar scrie text, dar în practică acesta modifică și sistemul, fluxul de lucru devine greu de controlat.

Alegeți gradul de automatizare în funcție de consecințe. O clasificare limitată poate fi adesea executată automat când erorile sunt ușor de detectat și corectat. O acțiune care afectează bani, acces sau drepturile clientului are nevoie de controale mai puternice. Scopul este o legătură clară între sarcină, permisiune și consecință.

Izolarea care limitează daunele

Rulați agentul într-un mediu delimitat, cu conexiuni controlate către restul companiei. Astfel este mai ușor să limitați consecințele erorilor și să opriți o sarcină fără să perturbați totul. Izolarea trebuie să acopere spațiul de lucru, instrumentele, accesul la rețea și informațiile pe care le poate folosi agentul.

Un mediu separat ajută prea puțin dacă agentul primește, în același timp, chei cu acces extins la sistemele de producție. Analizați, așadar, întregul lanț. Ce fișiere sunt disponibile? Ce servicii poate contacta agentul? Ce acțiuni pot executa instrumentele? Cât timp durează accesul? Limitele trebuie să funcționeze în practică, inclusiv când modelul cere altceva.

Imaginați-vă un agent de programare care trebuie să corecteze o eroare pe un site. În acest exemplu ipotetic, el poate lucra într-o copie separată a proiectului, poate citi fișierele relevante și poate executa verificările convenite. Nu primește chei de producție sau acces pentru a pune modificările în funcțiune. Rezultatul este o modificare pe care dezvoltatorul o poate inspecta și testa înainte să afecteze clienții.

Un sistem de publicare poate folosi același principiu. Un agent de conținut poate scrie într-o anumită ciornă și poate încărca o imagine, în timp ce publicarea necesită o permisiune separată. Restricția trebuie să existe în instrument sau în platforma de publicare. O instrucțiune de a ține minte să nu publice nu reprezintă o limită tehnică de acces.

Limitați și timpul și resursele pe care le poate folosi agentul. Stabiliți limite pentru durata sarcinii, numărul apelurilor către instrumente și cost, acolo unde este relevant. O sarcină care se învârte în cerc trebuie să se poată opri controlat. Compania are nevoie de un rezultat inteligibil și atunci când agentul nu reușește: ce s-a făcut, ce mai rămâne și ce modificări există deja.

O oprire de urgență care funcționează cu adevărat

Construiți o modalitate de oprire a agentului care funcționează fără cooperarea modelului. Un buton de întrerupere în interfață este util, dar trebuie conectat la mecanismele care controlează execuția, accesul și acțiunile. Altfel, utilizatorul poate crede că lucrul s-a oprit, în timp ce o sarcină în fundal continuă.

Stabiliți ce înseamnă oprirea în fluxul de lucru respectiv. Trebuie blocate apelurile noi către instrumente? Trebuie reținute mesajele care așteaptă să fie trimise? Trebuie retras accesul temporar? Trebuie încheiată o operațiune în desfășurare? Sisteme diferite necesită mecanisme diferite, dar consecința trebuie să fie clară pentru persoana care apasă butonul.

O oprire de urgență nu poate anula toate acțiunile anterioare. Un e-mail deja trimis nu poate, de regulă, fi tratat ca și cum nu ar fi fost trimis. De aceea, trebuie să separați oprirea activității viitoare de remedierea a ceea ce s-a întâmplat. Arătați ce acțiuni au fost executate și care sunt încă în așteptare.

Desemnați pe cineva responsabil pentru folosirea funcției de oprire și pentru gestionarea situației ulterior. Într-o companie mică, poate fi aceeași persoană care răspunde de relațiile cu clienții sau de site. Persoana are nevoie de instrucțiuni scurte și accesibile despre cum se oprește execuția, unde se găsește jurnalul de evenimente și cum se identifică sarcinile afectate.

Testați funcția de oprire înainte ca agentul să lucreze independent. Porniți o sarcină de test inofensivă, întrerupeți-o în timpul execuției și verificați că acțiunile noi sunt efectiv blocate. Testați și o sarcină cu acțiuni aflate în coada de așteptare. Oprirea de urgență face parte din operare și trebuie să funcționeze când restul fluxului de lucru este greu de urmărit.

Jurnale care rezistă întrebărilor critice

Înregistrați acțiunile importante în afara controlului modelului. Un asemenea jurnal permite investigarea a ceea ce a făcut efectiv sistemul, a instrumentelor folosite și a aprobărilor primite. Rezumatul agentului poate ajuta la lizibilitate, dar nu trebuie să fie singura documentare a succesiunii evenimentelor.

Începeți cu întrebările pe care le-ați putea primi după o eroare: ce sarcină era activă? Cine a pornit-o? Ce informații au fost extrase? Ce instrument a modificat comanda? Cine a aprobat trimiterea? Ce a răspuns serviciul care a primit cererea? Înregistrați evenimente structurate care permit răspunsul la aceste întrebări.

Asociați evenimentele unei sarcini și folosiți marcaje temporale clare. Este adesea util să înregistrați ce versiuni ale modelelor și instrumentelor au fost folosite, precum și rezultatul controalelor de acces. Dacă o acțiune a fost respinsă, acest lucru trebuie să apară. O serie exclusivă de evenimente reușite spune prea puțin despre eventualele încercări ale agentului de a face și ceva nepermis.

Imaginați-vă că un agent pentru relații cu clienții propune schimbarea adresei de livrare într-un magazin online ipotetic. Un jurnal util arată cererea, modificarea propusă, verificarea accesului clientului, eventuala aprobare și rezultatul din sistemul de comenzi. O afirmație a agentului că adresa a fost actualizată nu documentează faptul că sistemul de comenzi a acceptat efectiv schimbarea.

Jurnalele trebuie, de asemenea, protejate împotriva modificării și ștergerii neautorizate. Agentul care execută sarcina nu ar trebui să poată edita documentarea propriilor acțiuni. Alegeți o configurație de stocare care permite urmărirea modificărilor relevante. Rețineți totodată că un jurnal descrie evenimente observabile; nu oferă neapărat o explicație sigură a evaluărilor interne ale modelului.

Protejați și informațiile din jurnal

Înregistrați ceea ce este necesar pentru control și depanare și evitați colectarea informațiilor sensibile fără un motiv clar. Altfel, un jurnal poate deveni o colecție suplimentară de date ale clienților, documente interne și secrete. Înregistrarea fără discernământ a tuturor informațiilor poate face o problemă mai greu de gestionat.

Separați documentarea unei acțiuni de copierea integrală a conținutului. Pentru unele evenimente, este suficient să înregistrați referința comenzii, tipul acțiunii și rezultatul. Alte investigații pot necesita mai multe detalii. Evaluați nevoia în avans și aplicați controlul accesului și pentru persoanele care pot citi jurnalele.

Fiți deosebit de atenți la parametrii instrumentelor și la mesajele de eroare. Acestea pot conține chei de acces sau alte informații care nu ar trebui să apară niciodată într-un jurnal obișnuit de operare. Mascarea trebuie să aibă loc înainte de stocarea datelor. Nu vă așteptați ca modelul să recunoască și să elimine consecvent toate secretele din propria descriere.

Definiți cine poate citi ce informații și pentru cât timp aveți efectiv nevoie de ele. Echipa de relații cu clienții poate avea nevoie de o imagine de ansamblu asupra acțiunilor într-un singur caz, în timp ce dezvoltatorii au nevoie de coduri tehnice de eroare. Aceasta nu înseamnă că toată lumea trebuie să aibă acces la întreaga conversație sau la toate documentele folosite de agent.

Verificați jurnalele cu date de test realiste înainte de folosirea soluției. Puteți urmări o sarcină de la început până la sfârșit? Este eroarea inteligibilă? Există informații care nu ar fi trebuit stocate? O bună securitate a AI-ului necesită atât trasabilitate, cât și limitarea informațiilor. Jurnalele trebuie să ajute compania să investigheze un incident fără să creeze acces inutil la și mai multe date.

Mai multe modele pot ajuta, dar pot avea și aceleași puncte oarbe

Puteți folosi un model suplimentar pentru verificare, dar evaluați rezultatul în raport cu cerințe concrete și surse externe. Două modele care sunt de acord pot greși în continuare. Valoarea depinde de modul în care este concepută verificarea și de erorile pe care le detectează efectiv.

Un model suplimentar poate, de exemplu, examina dacă un răspuns nu are referințe la surse, dacă o propunere încalcă o limită de sumă declarată sau dacă un text conține afirmații care necesită documentare. Este mai util decât a-i cere modelului să evalueze în general dacă totul arată bine. Cu cât întrebarea de verificare este mai clară, cu atât este mai ușor să testați controlul folosind erori cunoscute.

Modelele pot totuși împărtăși aceleași ipoteze, lacune de cunoaștere sau vulnerabilități la același conținut. Dacă ambele primesc un document cu o instrucțiune ascunsă, ambele pot fi influențate. Dacă ambele evaluează date greșite despre comandă, acordul dintre ele nu rezolvă problema. Mai multe modele nu oferă, așadar, o garanție automată a independenței.

Într-un sistem de conținut ipotetic, un model poate scrie un articol, iar altul poate marca afirmațiile factuale nedocumentate. Acest lucru îl poate ajuta pe redactor să găsească pasajele care necesită verificare. Redactorul trebuie în continuare să deschidă sursele relevante și să examineze ce spun efectiv. Un model de verificare care inventează el însuși o sursă poate face textul mai convingător fără să îl facă mai corect.

Folosiți controale obișnuite ale sistemului atunci când cerința poate fi exprimată precis. Limitele de sumă, destinatarii permiși, câmpurile obligatorii și regulile de acces pot fi adesea verificate direct. Modelele pot fi atunci folosite pentru sarcini care necesită evaluare lingvistică, iar limitele clare pot fi aplicate în mod previzibil. Combinația trebuie aleasă în funcție de riscul și costul fluxului concret de lucru.

Aprobarea umană trebuie să fie concretă

Oferiți persoanei care aprobă suficiente informații pentru a înțelege acțiunea și consecința ei. Aprobarea unui plan neclar este un punct slab de control. Același lucru este valabil pentru un buton care spune „continuă”, când este greu de înțeles ce va face agentul mai departe.

Arătați acțiunea concretă: destinatarul, conținutul, suma, documentul sau modificarea. În cazul modificărilor de cod, dezvoltatorul trebuie să poată inspecta diferențele și să vadă rezultatele testelor relevante. În cazul publicării, redactorul trebuie să vadă textul, imaginea, sursele și pagina care urmează să fie actualizată. Nu transferați întreaga povară a evaluării într-un istoric lung de conversație.

Aprobarea trebuie legată de propunerea pe care persoana a văzut-o efectiv. Dacă agentul schimbă ulterior destinatarul sau conținutul, sistemul trebuie să ceară o nouă evaluare atunci când modificarea este semnificativă. Altfel, o permisiune pentru o acțiune poate ajunge să fie folosită pentru alta.

Evitați, în același timp, solicitarea unei confirmări pentru fiecare operațiune neînsemnată. Prea multe întreruperi pot transforma aprobarea într-un obicei fără evaluare reală. Amplasați punctele de control acolo unde o eroare ar avea consecințe vizibile și folosiți limite clare pentru acțiunile mai mici care pot fi executate automat.

Stabiliți și ce se întâmplă dacă nimeni nu răspunde. Expirarea unui termen nu este același lucru cu aprobarea. Un agent care așteaptă permisiunea de a trimite un mesaj unui client nu trebuie să interpreteze tăcerea drept consimțământ. Arătați că sarcina este în așteptare și oferiți responsabilului o modalitate simplă de a respinge sau modifica propunerea. Controlul uman funcționează cel mai bine când persoana are vizibilitate, timp și posibilitatea de a interveni.

Testați sistemul pe tot parcursul utilizării sale

Testați fluxul efectiv de lucru al agentului înainte de utilizare și după modificări. Modelul, instrucțiunile, instrumentele și sursele de date acționează împreună, astfel încât un model lingvistic bun, singur, spune prea puțin despre siguranța întregului sistem. Un test trebuie să verifice atât rezultatul, cât și calea urmată de sistem pentru a ajunge la el.

Construiți un set mic de sarcini reprezentative din activitatea companiei. Includeți cazuri obișnuite, mesaje neclare, informații lipsă și situații în care agentul trebuie să se oprească. Descrieți în avans ce acțiuni sunt permise, ce înseamnă un rezultat bun și ce evenimente trebuie să existe în jurnal. Astfel, evaluarea devine mai concretă decât simpla impresie că răspunsul pare rezonabil.

Verificați în special dacă agentul respectă limitele de acces. Poate extrage comanda altui client? Poate publica o ciornă fără permisiunea corectă? Poate trimite informații unui destinatar neaprobat? Aceste verificări privesc aplicarea regulilor de către sistem, nu doar ceea ce promite agentul în propriul text.

Repetați testele relevante când schimbați modelul, instrucțiunile, instrumentele sau integrările. O actualizare poate influența acțiunea aleasă de agent și modul în care acesta gestionează erorile. Înregistrați versiunile la care se referă testele, astfel încât un rezultat aprobat anterior să nu fie folosit ca dovadă pentru o altă soluție.

Monitorizați și utilizarea obișnuită. Urmăriți sarcinile care se opresc, apelurile neașteptate către instrumente, acțiunile respinse și feedbackul utilizatorilor. Alegeți semnale concrete pe care cineva are responsabilitatea de a le urmări. Securitatea AI devine parte din operare când compania poate detecta un comportament schimbat și poate ajusta limitele înainte ca problemele să se amplifice.

Testați situațiile de eroare înainte să le întâlnească clienții

Testați ce se întâmplă când premisele nu se confirmă. Un serviciu poate fi indisponibil, un răspuns poate fi incomplet sau o acțiune poate fi executată chiar dacă confirmarea nu ajunge înapoi. Agentul trebuie să gestioneze asemenea situații fără să inventeze un rezultat reușit sau să repete fără discernământ o acțiune sensibilă.

Într-un sistem de comenzi ipotetic, o rambursare poate fi efectuată în timp ce cererea primește o eroare de expirare a timpului de așteptare. Dacă agentul încearcă imediat din nou fără să verifice starea, aceeași rambursare poate fi efectuată de două ori. Instrumentul trebuie construit astfel încât cererile repetate pentru aceeași acțiune să fie gestionate controlat. Testați și modul în care agentul explică incertitudinea persoanei responsabile.

Testați conținut care încearcă să îi dea agentului instrucțiuni noi. Poate fi un e-mail, o pagină web sau un document care cere sistemului să ignore regulile anterioare ori să transmită informații mai departe. Asemenea date nu trebuie să primească automat aceeași autoritate ca instrucțiunile companiei. Examinați atât reacția modelului, cât și dacă instrumentele continuă să aplice limitele.

Includeți lipsa aprobării, oprirea în timpul execuției și sarcinile care se încheie cu modificări parțiale. Poate compania afla ce mai rămâne de făcut? Poate o persoană prelua fără să repete munca deja executată? Un rezultat parțial clar este adesea mai sigur decât încercările agentului de a găsi mereu căi noi pentru a termina.

Când un test dezvăluie o eroare, păstrați-l ca verificare nouă în setul de teste. Corectați vulnerabilitatea respectivă și testați din nou fluxul de lucru afectat. Scopul nu este să demonstrați că agentul nu poate greși niciodată. Scopul este să știți ce limite sunt aplicate, cum sunt detectate erorile și cine poate prelua când automatizarea nu mai este potrivită.

Un început practic pentru companiile norvegiene

Începeți cu o sarcină pe care o puteți descrie și măsura. „Vom folosi AI” este prea general. „Vom primi o propunere de răspuns la întrebări despre termenele de livrare, bazată pe informații aprobate” este concret. Astfel este mai ușor să alegeți informațiile pe care se va baza soluția, să limitați accesul și să găsiți o persoană care poate evalua efectiv rezultatul.

Un proiect-pilot mic poate fi construit în jurul acestor șapte măsuri. Aceasta este prioritizarea noastră practică, nu o reproducere cuvânt cu cuvânt a listei lui Nadella:

• Stabiliți sarcina, datele și accesul minim necesar.
• Separați propunerile de acțiunile în alte sisteme.
• Izolați execuția și verificați că oprirea de urgență funcționează.
• Înregistrați acțiunile importante independent de explicația agentului.
• Folosiți modele de verificare acolo unde aduc valoare și oferiți oamenilor o bază clară pentru decizie.
• Testați neînțelegerile, datele de intrare manipulate și schimbările configurației.
• Asigurați o analiză independentă și un plan de gestionare a incidentelor.

Alegeți, de preferință, un flux de lucru care are un punct natural de oprire înainte să fie afectat clientul. O ciornă de conținut este un exemplu bun de asemenea punct. Un redactor poate vedea textul, verifica sursele și decide dacă acesta trebuie publicat. Sistemul nu are nevoie de drepturi de publicare pentru a contribui la lucru. Această limitare face mai ușor de înțeles consecințele proiectului-pilot.

Definiți și ce doriți să învățați. Poate că proiectul-pilot trebuie să stabilească dacă asistentul găsește informațiile corecte, dacă cere ajutor când îi lipsește baza necesară și dacă specialistul economisește timp după ce includeți și munca de verificare. Înregistrați unde apare muncă suplimentară. Dacă o propunere pare rapidă, dar necesită mult timp pentru corectare și verificare, aceasta este o informație importantă pentru decizia următoare.

Este util să îi includeți pe cei care vor folosi soluția. Un dezvoltator poate demonstra că o regulă de acces funcționează, dar un specialist în relații cu clienții știe ce formulări pot crea așteptări pe care compania nu le poate îndeplini. Un redactor știe ce surse trebuie examinate. Un responsabil de operare știe cine poate reacționa efectiv când ceva se oprește. Securitatea devine mai concretă când aceste perspective se întâlnesc în același flux de lucru.

Ce trebuie să existe înainte ca agentul să primească mai multă responsabilitate?

Scrieți criteriile de acceptare înainte să evaluați extinderea accesului. Un criteriu trebuie să descrie atât rezultatul așteptat, cât și ce trebuie să se întâmple când sistemul nu îl poate oferi. „Răspunsurile par bune” este greu de verificat. „Propunerea folosește informații aprobate despre livrare și semnalează când acestea lipsesc” oferă o bază mai clară.

Pentru un proiect-pilot ipotetic de relații cu clienții, puteți cere ca asistentul să citească numai cazul respectiv, ca un răspuns să nu fie trimis fără aprobare și ca toate încercările de modificare în afara mandatului să fie respinse. Trebuie să fie posibil și să regăsiți ce propunere a fost aprobată, de către cine și pe baza căror date. Lista concretă trebuie adaptată sarcinii și riscului din companie.

O analiză independentă are nevoie de un mandat definit. Cereți persoanei care evaluează soluția să examineze drepturile de acces, procedura de oprire și rezultatele concrete ale testelor. Analiza trebuie să arate clar ce a fost examinat, ce nu a fost examinat și pe ce ipoteze se bazează evaluarea. O etichetă vagă de „aprobat” este mai puțin utilă decât o descriere precisă a constatărilor și limitelor.

Creați și o procedură simplă pentru incidente înainte să aveți nevoie de ea. Stabiliți cine poate opri agentul, cine investighează dacă sunt afectate alte sisteme și cine decide reluarea execuției. Păstrați urmele relevante. Separați oprirea acțiunilor noi de remedierea a ceea ce a fost deja executat. Dacă un mesaj a fost trimis greșit, oprirea modelului nu anulează trimiterea.

În cazul unui incident, responsabilul trebuie să adune informații confirmate: ce s-a făcut, ce date sau persoane pot fi afectate și ce măsuri au fost efectiv aplicate. Comunicarea trebuie să se bazeze pe ceea ce a fost investigat. O explicație generată de agent, singură, nu este o bază suficientă pentru a declara sistemul sigur. Eventualele cerințe de notificare trebuie stabilite în funcție de situația concretă și de acordurile și regulile relevante.

Extindeți mandatul pas cu pas. Dacă ulterior doriți să permiteți trimiterea mesajelor, testați mai întâi o categorie mică și clar delimitată. Păstrați cazurile de test anterioare și executați-le din nou după modificare. Astfel puteți vedea dacă noul beneficiu compensează efectiv noul risc și dacă limitele anterioare continuă să funcționeze.

Un proiect-pilot este reușit când compania are o bază mai bună pentru a decide. Aceasta poate însemna extinderea soluției. Poate însemna și păstrarea ei ca asistent, modificarea fluxului de lucru sau oprirea experimentului. Toate cele trei sunt rezultate rezonabile dacă decizia se bazează pe rezultate observate și nevoi clare.

Întrebări frecvente despre securitatea AI

Spune Nadella că nu putem folosi AI?

Nu. Direcția eseului este întărirea controlului din jurul modelelor. Recomandarea noastră practică este să evaluați utilizarea în funcție de sarcină, acces și consecințe. Un asistent care propune formulări nu are nevoie de aceleași drepturi ca un agent care poate modifica datele clienților. Citiți textul original al lui Nadella.

Este, așadar, mai bine să puneți o întrebare concretă decât să alegeți între încredere totală și respingere totală: ce poate face soluția dacă greșește? Dacă răspunsul este că produce doar o ciornă pe care o persoană o evaluează, riscul este diferit de cel al executării independente a unor acțiuni ireversibile. Fluxul de lucru din jurul modelului determină o mare parte din cerințele pe care compania trebuie să le impună.

Ce înseamnă să tratăm un model ca pe un risc intern?

Înseamnă să planificăm pornind de la posibilitatea ca un actor cu acces să facă ceva greșit sau să fie influențat să își depășească mandatul. O modalitate practică de a aplica ideea este limitarea accesului, controlul acțiunilor importante și posibilitatea ca alte persoane să investigheze ce s-a întâmplat. Aceasta nu presupune neapărat o afirmație despre intenții umane ale modelului.

Gândiți-vă la un asistent care ajută cu un singur caz al unui client. El trebuie să primească informațiile necesare acelui caz. Nu are nevoie automat de acces la întregul registru de clienți. Astfel, securitatea devine o chestiune de drepturi și consecințe, iar compania le poate examina fără să fie nevoie să stabilească ce „vrea cu adevărat” modelul.

Este suficient un model suplimentar pentru verificarea unei decizii importante?

Un model suplimentar poate aduce întrebări utile sau poate descoperi abateri, dar numărul modelelor nu este o dovadă de calitate. Verificarea trebuie să se bazeze pe surse relevante și pe înțelegerea corectă a sarcinii. Dacă ambele modele primesc aceeași bază incompletă, pot ajunge la aceeași eroare.

Recomandăm folosirea modelelor ca sprijin pentru activitatea de verificare, păstrând în același timp reguli clare pentru acțiunile cu consecințe importante. Arătați persoanei responsabile ce urmează să se facă, pe ce informații se bazează propunerea și ce modificări va produce. Un buton de aprobare are valoare limitată dacă ascunde chiar baza deciziei.

Devine agentul sigur dacă modelul rulează local?

Rularea locală descrie locul în care modelul procesează sarcina. Nu spune, prin ea însăși, ce fișiere, rețele sau alte sisteme poate folosi agentul. În evaluarea noastră, rularea locală trebuie, așadar, analizată împreună cu drepturile de acces, instrumentele și fluxul de date.

Un asistent local ipotetic poate avea, de exemplu, un control bun asupra execuției modelului, dar poate folosi în același timp un instrument care trimite un document către un serviciu extern. Compania trebuie atunci să evalueze separat acel transfer. Începeți cu o imagine de ansamblu asupra întregului flux de lucru: colectarea datelor, procesarea de către model, apelurile către instrumente, stocarea și eventualele transferuri. Localizarea este o caracteristică a soluției; nu înlocuiește cartografierea fluxului.

Sunt deja disponibile funcțiile pentru agenți anunțate de Microsoft?

Au stadii diferite de disponibilitate. Analiza noastră este datată 12 octombrie 2026; stadiile și linkurile apar în tabelul de produse de mai sus. Folosiți-l ca punct de pornire și verificați documentația relevantă înainte să planificați o implementare. Planurile produselor și disponibilitatea efectivă se pot schimba.

Cereți și informații pentru configurația voastră concretă. O funcție poate fi prezentată într-o lansare generală fără să fie complet disponibilă pentru toate platformele, categoriile de clienți sau fluxurile de lucru. O întrebare utilă la achiziție este să cereți o demonstrație a funcției pe care o veți folosi efectiv și să clarificați ce componente ale livrării depind de actualizări viitoare.

De unde ar trebui să înceapă o companie mică cu securitatea AI?

Alegeți o singură sarcină delimitată, o persoană responsabilă nominalizată și un punct natural de oprire înaintea unei acțiuni importante. Folosiți un set limitat de date. Testați atât cazurile obișnuite, cât și situațiile în care informațiile sunt incomplete sau contradictorii. Examinați și ce face sistemul când încearcă să folosească un acces pe care nu îl are.

Măsurați rezultatul după ce includeți verificarea și corectarea. O companie mică are nevoie de un răspuns inteligibil despre utilitatea soluției, cine o urmărește și cum este oprită. Extindeți apoi numai componentele care au o justificare clară. Astfel, atât investiția, cât și responsabilitatea sunt mai ușor de gestionat și obțineți experiență mai utilă decât într-un proiect mare cu drepturi neclare.

Concluzie: încrederea trebuie să poată fi verificată

Declarațiile lui Nadella ne oferă ocazia de a pune întrebări mai bune despre agenții pe care îi folosim. Aceleași întrebări trebuie să însoțească întreaga achiziție și implementare: ce sarcină rezolvă sistemul? De ce drepturi are nevoie? Cine controlează acțiunile importante? Cum detectăm și oprim o abatere?

Putem fi interesați de AI și, în același timp, putem cere răspunsuri clare. Un model poate oferi propuneri utile chiar dacă nu îi dăm acces să execute toate acțiunile pe care le propune. Compania poate astfel obține experiență și valoare în limite pe care le înțelege.

Mesajul comercial despre securitate trebuie evaluat cu aceeași luciditate. Un produs poate fi util, dar valoarea lui constă în mecanismele de control care funcționează efectiv în fluxul vostru de lucru. Cereți demonstrații, documentați limitele și oferiți persoanei responsabile o bază reală pentru decizie.

Pentru Kodemagisk, direcția practică este clară: începeți cu nevoia, integrați limitele și extindeți pe baza rezultatelor observate. Dacă luați în calcul un asistent AI într-un site, un portal pentru clienți sau un flux intern de lucru, o primă conversație utilă poate privi sarcina și drepturile necesare. Vedeți cum lucrăm la aplicații web și instrumente interne sau contactați-ne pentru a discuta nevoile voastre.