Cum construim o persona pentru un audit de vizibilitate AI

O persona pentru un audit de vizibilitate AI nu este un nume inventat, o fotografie de stock și o vârstă aleasă la întâmplare. Este o configurație documentată de obiectiv, context, constrângeri și criterii care pot schimba întrebarea sau recomandarea.

Dacă două personas produc exact aceleași prompts și aceleași reguli de evaluare, detaliile lor nu contribuie la măsurătoare. Dacă persona include preferința pentru brandul pe care vrem să-l găsim, testul este contaminat înainte să înceapă.

1. Segment, persona, scenariu și prompt

Cele patru niveluri trebuie separate:

• segmentul grupează persoane sau organizații după criterii relevante;
• persona sintetizează un model de nevoi, context și comportament decizional;
• scenariul descrie situația concretă în care apare o nevoie;
• promptul este o formulare observabilă într-o anumită etapă.

Un „manager de marketing” este doar o etichetă. Devine persona de audit când știm ce încearcă să decidă, ce informație are, ce limite îl constrâng și ce dovadă acceptă.

2. Pornim de la o nevoie, nu de la brand

Google PAIR recomandă să începem cu întrebări precum cine sunt utilizatorii, ce valori au, ce problemă trebuie rezolvată și cum definim succesul. Ghidul User Needs + Defining Success pune conversația cu oamenii, observația și datele înaintea soluției tehnice.

Pentru audit, formula de bază este:

Când apare [declanșatorul], persoana încearcă să [obiectiv], în condițiile [constrângeri], și va considera soluția acceptabilă dacă [criterii verificabile].

Brandul nu intră în această frază decât dacă există dovezi că utilizatorul îl cunoaște deja și testăm o etapă de evaluare, nu discovery.

3. Fiecare atribut important are proveniență

O persona poate fi construită din interviuri, cercetare contextuală, tichete de suport, date de căutare, CRM agregat, echipa de vânzări și observația traseelor reale. Nicio sursă nu este perfectă.

GOV.UK cere ca nevoile utilizatorilor să fie bazate pe cercetare, nu pe presupuneri. Pentru fiecare atribut salvăm:

• sursa;
• data și perioada;
• câte observații îl susțin;
• nivelul de încredere;
• contradicțiile;
• data următoarei validări.

Dacă nu avem cercetare, persona poate fi o ipoteză sintetică de test, marcată explicit. Nu o prezentăm ca vocea pieței.

4. Câmpurile care schimbă decizia

Fișa minimă include:

1. job-to-be-done și rezultat dorit;
2. declanșatorul și urgența;
3. etapa deciziei;
4. soluția folosită acum;
5. cunoștințele și termenii pe care îi folosește;
6. constrângerile de eligibilitate;
7. criteriile și trade-off-urile;
8. sursele pe care le consideră credibile;
9. necunoscutele;
10. condiția de oprire.

Locația, limba, dispozitivul, accesibilitatea, industria sau toleranța la risc intră numai când pot modifica cererea ori recomandarea. O caracteristică decorativă crește complexitatea fără să crească validitatea.

5. Fișa de persona

Exemplul nu conține nume, fotografie, vârstă sau gen pentru că acestea nu schimbă problema testată. Dacă o cercetare ar demonstra că accesibilitatea sau cadrul legal variază între grupuri, acel context ar fi introdus cu justificare.

6. Constrângerile devin filtre, nu adjective

„Este ocupat” este vag. „Trebuie să decidă în două săptămâni” produce un efect măsurabil: răspunsul ar trebui să prioritizeze opțiuni evaluabile rapid și să spună ce rămâne neconfirmat.

„Are buget limitat” este incomplet. Avem nevoie de interval, cost total relevant și trade-off. „Preferă calitatea” nu spune dacă fiabilitatea, suportul, securitatea sau integrarea cântărește mai mult.

Fiecare constrângere ar trebui să poată elimina o opțiune, schimba ordinea criteriilor sau declanșa o întrebare de clarificare. Altfel este decor.

7. Persona nu trebuie să șoptească răspunsul

Contaminarea apare când descriem persona astfel: „folosește deja produse similare cu brandul X”, „preferă compania locală X” sau „a auzit lucruri bune despre X”, fără dovadă și fără ca brand awareness să fie obiectul testului.

Pentru discovery folosim formulări neutre. Pentru evaluare putem introduce setul cunoscut, dar păstrăm separat scenariile în care brandurile sunt numite de cele în care trebuie descoperite organic.

Articolul despre conversații multi-turn explică de ce introducerea prematură a brandului schimbă numitorul și traseul.

8. Transformăm persona în inputuri auditabile

Nu lipim întreaga biografie într-un system prompt. Extragem variabile:

• goal: lista scurtă pentru o categorie definită;
• stage: evaluare inițială;
• deadline: două săptămâni;
• must_have: integrare confirmată;
• tradeoff: cost mai mare pentru migrare sigură;
• evidence_rule: surse oficiale și dovezi verificabile;
• unknowns: volum și resurse interne.

Apoi construim scenarii și prompts versionate. Un sistem de evaluare formal, precum OpenAI Evals, separă schema itemului, sursa de date și criteriile de test. Același principiu face persona auditabilă chiar dacă rularea este manuală.

9. Persona trebuie să ceară clarificări

O persona realistă nu furnizează toate datele din primul mesaj. Unele necunoscute apar intenționat pentru a testa dacă sistemul cere informația care poate schimba recomandarea.

Dacă volumul, țara sau integrarea sunt decisive, un răspuns care inventează o presupunere nu este mai bun decât unul care recunoaște limita. Condiția de oprire poate fi: „nu recomandă până când compatibilitatea nu este verificată”.

Acest lucru testează conduita răspunsului, nu doar lista finală de branduri.

10. Acoperirea cere mai multe personas

O singură persona nu reprezintă piața. Construim o matrice între:

• nevoi principale;
• etape ale deciziei;
• constrângeri care schimbă eligibilitatea;
• niveluri de cunoaștere;
• limbi și geografii relevante.

Nu combinăm mecanic toate valorile. Alegem configurații plauzibile și importante, apoi raportăm ce parte din spațiul țintă a fost acoperită. Repetările și problema unui singur prompt sunt tratate în articolul dedicat măsurătorii.

11. Alegem eșantionul după risc și impact

Lista de personas nu trebuie să fie nici exhaustivă, nici comodă. Începem cu celulele care combină frecvență mare, valoare ridicată și risc semnificativ dacă răspunsul este greșit. Adăugăm apoi cazurile-limită care pot schimba eligibilitatea: o țară diferită, o cerință obligatorie de accesibilitate, un termen foarte scurt sau lipsa unei informații decisive.

Pentru fiecare celulă notăm ponderea estimată, motivul includerii și dovezile disponibile. Dacă ponderea provine din trafic sau CRM, precizăm perioada și limitele setului de date. Dacă este doar judecată de expert, o etichetăm ca ipoteză. În felul acesta, scorul agregat nu pretinde o reprezentativitate pe care eșantionul nu o are.

Un eșantion inițial poate conține puține personas, cu condiția să existe o regulă de extindere. Extindem când apar:

• nevoi importante neacoperite în cercetare;
• răspunsuri diferite pentru aceeași configurație;
• o constrângere nouă care schimbă recomandarea;
• piețe sau limbi cu rezultate material diferite;
• un incident care arată că rubrica nu surprinde un risc.

Raportăm separat rezultatele pe celule înainte de a calcula o medie. O medie bună poate ascunde o persona critică pentru care sistemul omite o limitare, recomandă o opțiune neeligibilă sau nu cere clarificarea necesară.

12. Verificăm bias-ul din selecție

Persona poate exclude involuntar utilizatori, poate amplifica stereotipuri sau poate favoriza soluția pe care echipa o vinde. Facem o revizie în care întrebăm:

• ce grupuri relevante lipsesc;
• ce atribute sunt presupuse, nu observate;
• dacă un proxy poate dezvălui o caracteristică sensibilă;
• dacă scenariul favorizează artificial un produs;
• dacă regula de succes reflectă interesul utilizatorului;
• ce efecte secundare nu măsurăm.

Google PAIR recomandă verificarea reprezentativității, provenienței, privacy și protected characteristics atunci când nevoile sunt transformate în date de evaluare.

13. Confidențialitate și minimizarea datelor

Persona nu trebuie să copieze date personale din interviuri, CRM sau tichete. Agregăm și eliminăm identificatorii. Nu includem informații sensibile dacă nu sunt indispensabile întrebării, permise și gestionate printr-un protocol adecvat.

Păstrăm separat dovada internă și fixture-ul publicabil. În raport putem spune „patru interviuri și analiza tichetelor din trimestrul X”, fără a expune cine a spus fiecare lucru.

NIST AI RMF MAP cere documentarea contextului, utilizatorilor, așteptărilor și limitărilor. Documentare nu înseamnă colectare nelimitată.

14. Versionare și series break

O persona are ID, versiune, owner, surse și dată de revizuire. Dacă schimbăm obiectivul, criteriul obligatoriu sau geografia, rezultatele pot să nu mai fie comparabile cu seria veche.

Corecturile minore de formulare se notează. Schimbările care alterează eligibilitatea, traseul sau rubrica produc o versiune nouă și, când este cazul, un series break.

Astfel putem explica dacă vizibilitatea s-a schimbat sau dacă am început să măsurăm o altă persoană.

15. Testele de acceptanță ale unei personas

1. fiecare atribut important are sursă sau eticheta „ipoteză”;
2. obiectivul poate fi formulat fără un brand preselectat;
3. cel puțin o constrângere schimbă eligibilitatea sau ordinea;
4. necunoscutele pot declanșa o clarificare;
5. criteriile pot fi aplicate de doi evaluatori;
6. datele sensibile sunt minimizate;
7. persona este distinctă de celelalte prin comportament, nu cosmetizare;
8. limitările și coverage sunt publicabile.

Dacă persona nu trece aceste teste, nu o multiplicăm în zeci de prompts. Corectăm întâi fixture-ul.

Verdict

Persona de audit este o ipoteză structurată despre o decizie. Devine credibilă când câmpurile provin din dovezi, iar necunoscutele și limitele sunt vizibile.

Nu avem nevoie de biografie bogată. Avem nevoie de obiectiv, declanșator, constrângeri, criterii, surse și condiție de oprire. Acestea produc diferențe verificabile în conversație.

O persona nu reprezintă piața și nu prezice un individ. Ea definește o celulă din cohorta de măsurare; acoperirea vine dintr-un set justificat, versionat și revizuit pentru bias.

Surse

• NIST AI RMF Core — MAP
• NIST AI RMF Playbook — MAP
• Google PAIR — User Needs + Defining Success
• Google PAIR — Mental Models
• Google PAIR — Data Collection + Evaluation
• GOV.UK — Learning about users and their needs
• GOV.UK — Plan user research
• OpenAI API — Evals

Sursele au fost verificate la 2 august 2026. Exemplul de persona este ipotetic și nu afirmă existența unei funcții AYSA de generare, segmentare sau rulare automată.