Pe parcursul acestui an am descoperit pe internet o categorie nouă de magie profesională: „experți” care au constatat că, dacă introduci suficiente cuvinte precum „ISO 27001”, „risk assessment”, „control effectiveness” și „executive summary” într-un prompt, la final iese ceva care seamănă surprinzător de mult cu un audit. Uneori chiar arată foarte bine: are structură, matrice de riscuri cu culori, constatări, severități și recomandări. Are acel ton sobru, impersonal, care spune „Raportul auditorului” sau ”Gap Analysis” sau….. Mai lipsește doar un detaliu: să fie și corect.

Problema reală a AI-ului în auditul securității cibernetice nu este că poate greși. Oamenii greșesc, instrumentele greșesc, scanerele greșesc. Problema este că AI-ul poate greși foarte convingător. Iar cineva care nu cunoaște fundamentele auditului poate să nu își dea seama unde se termină analiza și unde începe invenția.

Până nu demult, ca să produci un material de audit coerent trebuia să înțelegi măcar mecanismul din spate. Trebuia să știi ce este un criteriu de audit, ce înseamnă probă sau dovadă, care este diferența dintre ”design effectiveness” și ”operating effectiveness”. Trebuia să înțelegi ce este o populație, ce este un eșantion, ce înseamnă o excepție și de ce o observație tehnică nu devine automat constatare. Astăzi poți să sari peste o parte dintre aceste etape și să ajungi …..direct la document.

AI-ul a redus enorm timpul și efortul necesare pentru a produce ceva care arată profesionist. Nu a redus însă și timpul necesar pentru a înțelege meseria.

Un audit serios nu începe cu un prompt care cere

„analizează aceste documente și spune-mi problemele/lipsurile/decalajele”.

Începe cu întrebări mult mai puțin spectaculoase: ce verific, față de ce criteriu, care este populația, ce eșantion aleg, ce dovadă îmi trebuie, ce rezultat ar demonstra conformitatea, ce ar reprezenta o excepție și ce limitări are testul meu?

Aceste întrebări fac diferența dintre audit și producția de text cu vocabular de audit. Dacă nu știi răspunsurile, AI-ul nu rezolvă problema. Cel mult o ascunde mai frumos.

Pentru că AI înseamnă matematică iar matematica este rigoare, modelele au tendința de a umple golurile: dacă le dai informație incompletă, încearcă să o organizeze; dacă le dai o situație ambiguă, încearcă să o interpreteze; dacă le dai jumătate de context, există riscul să construiască restul. În multe situații, aceasta este o calitate, dar în audit, poate deveni o problemă.

Dacă într-un set de documente revizuite nu apare o procedură de răspuns la incidente

„Organizația nu are un proces formal de răspuns la incidente”

poate suna rezonabil și poate fi complet greșit.

Documentul poate să nu fi fost furnizat. Poate exista într-un alt folder/calculator. Poate că procesul există, dar nu în forma pe care modelul se aștepta să o găsească. Într-o asemenea situație, o formulare mai corectă ar putea fi:

„Nu a fost furnizată dovada existenței sau implementării procesului.”

Prima propoziție afirmă ceva despre organizație în timp ce a doua descrie ceea ce se poate demonstra. Diferența dintre cele două este fundamentală.

Dovezi, nu povești

În audit se confundă foarte ușor calitatea formulării cu calitatea constatării: o constatare scrisă simplu poate părea slabă în timp ce una formulată elegant pare automat mai solidă. Dar dacă spui că un control este ineficient, trebuie să poți arăta de ce. Dacă spui că există un risc mare, trebuie să poți explica mecanismul. Dacă susții că organizația nu respectă o cerință, trebuie să poți indica atât criteriul, cât și dovada. Nu contează doar cum sună propoziția ci contează dacă poți demonstra ce afirmi.

Aici apare și problema clasificării riscului: AI-ul produce foarte ușor „High” și „Critical”, mai ales atunci cînd primește rezultate tehnice fără suficient context: Un risc nu este Mare doar pentru că vulnerabilitatea pare gravă. Contează activul afectat, expunerea, probabilitatea, impactul, accesul necesar, datele procesate și controalele compensatorii.

Aceeași vulnerabilitate poate avea implicații complet diferite pe două sisteme. Dacă AI-ul spune „Critic”, întrebarea utilă nu este cum introduci ratingul în raport, ci de ce este „Critic”. Dacă nimeni nu poate explica răspunsul fără să întrebe din nou modelul, avem o problemă.

La fel de riscant este și scenariul opus: AI-ul vede că un control există și presupune că funcționează.

O politică de backup nu demonstrează că restaurarea funcționează. Un proces de revizuire a accesului nu demonstrează că revizuirile chiar au loc. Un SIEM nu demonstrează că alertele sînt investigate, iar un EDR nu demonstrează că agentul este activ pe toate sistemele.

Auditul începe exact acolo unde documentația nu mai este suficientă și trebuie să verifici dacă lucrurile chiar se întâmplă în practică. Și aici apare și problema eșantionării: dacă ai analizat 20 de sisteme dintr-o populație de 2.000, nu poți spune pur și simplu că „sistemele organizației respectă cerința”. Ai demonstrat ceva despre sistemele testate. Poate metodologia îți permite să extinzi concluzia sau poate nu. Dar asta trebuie explicat.

AI-ul generalizează ușor: un caz devine tendință, un eșantion devine populație, o observație punctuală ajunge concluzie generală. De cele mai multe ori, formularea este impecabilă. Problema rămâne însă metodologia.

Un alt risc cunoscut este halucinația: un LLM poate inventa o referință la un control, poate amesteca versiuni ale unui standard sau poate atribui o cerință unui framework greșit. Partea neplăcută este că asemenea erori rareori sună absurd. Din contră, sună foarte competent.

Tocmai de aceea, referințele la CyFun, ISO, NIST, COBIT, CIS, SOC 2 sau alte framework-uri trebuie verificate în sursele originale. Nu pentru că AI-ul greșește mereu, ci pentru că, atunci cînd greșește, o poate face cu foarte multă încredere.

Aceeași problemă apare și la ”false positives” și ”false negatives.” Dacă modelul nu cunoaște controalele compensatorii, poate marca drept problemă o configurație acceptabilă. Dacă vede doar o politică, poate considera eficient un control care în practică nu funcționează. Într-un caz supraevaluează problema iar în celălalt o ratează.

De aceea, AI-ul este util ca instrument de analiză, nu ca arbitru final: contează mult și cum este formulată întrebarea.

Dacă îi spui:

„Explică de ce acest control este ineficient”, de fapt i-ai introdus deja concluzia. Modelul nu mai pornește de la dovezi, ci caută argumente pentru verdictul pe care i l-ai dat.

Mult mai sănătos este să îi ceri să identifice ce susține controlul, ce îl contrazice, ce informații lipsesc, ce controale compensatorii există și ce limitări are analiza.

AI-ul poate fi foarte util pentru a contesta o concluzie. Este mai puțin util atunci cînd este folosit doar pentru a o confirma.

Cînd analiza tehnică începe să semene cu auditul

Un scanner găsește vulnerabilitatea iar LLM-ul o explică, îi atribuie severitatea, scrie recomandarea și pregătește și rezumatul executiv. În câteva minute ai ceva care arată foarte mult ca un audit.

Dar auditul nu este doar forma finală. Trebuie să existe criteriu, test, dovadă, rezultat, context și concluzie. Dacă acestea lipsesc, ai în față doar o analiză tehnică bine împachetată care poate fi chiar foarte utilă. Dar nu este același lucru cu un audit.

La fel se întâmplă și cu recomandările. Este simplu să generezi „Implementați Zero Trust”, „Aplicați least privilege”, „Folosiți MFA”, „Îmbunătățiți monitorizarea” sau „Segmentați rețeaua”. Partea grea începe după aceea.

Unde? Pentru ce sisteme? În ce ordine? Ce risc rezolvă? Ce impact are? Ce dependențe există? Ce control compensatoriu este deja implementat?

Fără context, ai o listă de bune practici. Nu neapărat o recomandare de audit utilă. Apoi apare o întrebare ceva mai incomodă:

Dacă AI-ul face checklist-ul, definește testele, analizează dovezile, propune severitatea, scrie constatările, redactează recomandările și face și revizuirea finală, ce mai face auditorul?

Răspunsul ar trebui să fie: validează. Dar validarea presupune să poți spune „nu, aici modelul greșește”. Dacă nu poți face asta, nu mai validezi, doar aprobi ceea ce ți-a dat modelul. Iar aceasta nu este o diferență de vocabular, este o diferență de competență.

Regula clasică „garbage in, garbage out” rămâne valabilă. Doar că acum „garbage out” poate veni cu rezumat executiv, matrice de riscuri, constatări, recomandări și o formatare impecabilă.

Asta face lucrurile mai complicate pentru un client: este mult mai greu să distingă între un raport care arată bine și un audit care este bun.

Epoca „auditorilor AI”

AI-ul a făcut extrem de simplă producerea de rapoarte, metodologii și analize cu aspect profesionist. În mod inevitabil, pe internet au apărut tot mai mulți „consultanți”, „auditori” și „experți” care pot produce în câteva ore ceea ce înainte necesita zile. Uneori rezultatul este foarte bun. Alteori este doar foarte bine prezentat. Diferența nu se vede neapărat pe prima pagină. Se vede doar dacă începi să întrebi:

• De ce este aceasta o constatare?
• Care este criteriul?
• Care este dovada?
• Care este populația?
• Cum ai ales eșantionul?
• De ce riscul este clasificat astfel?
• Ce control compensatoriu ai verificat?
• Ce informații lipsesc?
• Cum ai testat operating effectiveness?

În acel moment s-a terminat prompt engineering-ul și a început auditul. Sau bîlbîiala.

Pentru un profesionist, AI-ul poate fi un instrument extraordinar: reduce munca repetitivă, accelerează analiza și poate ajuta inclusiv la verificarea unor ipoteze. Pentru cineva care nu stăpânește fundamentele, AI-ul doar accelerează greșelile și poate produce mai repede mai multe pagini, mai multe constatări și mai multe recomandări. Dar asta nu înseamnă neapărat mai mult audit.

Există și varianta în care raportul produs cu AI este introdus într-un alt model pentru quality assurance. Primul model spune că riscul este MARE. Al doilea confirmă dacă constarea este formulată bine. Primul propune și o recomandare. Al doilea o aprobă.

Problema este că două modele care sînt de acord unul cu altul nu demonstrează că sursa originală a fost verificată. Consensul dintre două modele nu este probă.

AI-ul poate genera într-o secundă un program de audit, o matrice de risc, un checklist Cyfun sau o listă de proceduri de test. Ce nu poate genera la fel de repede este experiența necesară pentru a recunoaște cînd toate acestea sînt greșite, incomplete sau nepotrivite pentru context.

De aceea, poate cel mai simplu test pentru management este să ia o constatare și să întrebe:

• Care este cerința?
• Ce ai testat?
• Ce dovadă ai obținut?
• Ce ai observat?
• Care este riscul?
• De ce recomanzi această măsură?

Dacă auditorul nu poate explica răspunsurile clar, fără să se refugieze în raport sau în răspunsul modelului, problema nu se rezolvă cu un prompt mai bun. Este mai fundamentală și ține de ”expert”

AI-ul poate democratiza accesul la instrumente, poate crește enorm viteza de lucru, poate ajuta la analiză, la documentare și la eliminarea unei cantități mari de muncă repetitivă. Dar AI-ul nu democratizează automat și judecata profesională a auditorului

În mâna cuiva competent, AI-ul poate fi un multiplicator foarte bun. În mâna cuiva care nu cunoaște fundamentele, poate transforma presupunerile în constatări, incertitudinea în certitudine și lipsa de experiență într-un PDF impecabil.

AI-ul este o realizare tehnologică impresionantă. Doar că nu este audit. Iar dacă metodologia (de audit) este slabă, AI-ul are o calitate greu de egalat: o poate aplică mult mai repede și o poate prezenta foarte convingător!