Cum alegi o platformă de AI visibility: criterii verificabile

O platformă de AI visibility nu ar trebui aleasă după numărul de „motoare”, un scor proprietar sau un demo favorabil, ci după capacitatea de a produce observații reproductibile, exportabile și verificabile în condițiile reale ale organizației. Înainte de lista de funcții, cumpărătorul are nevoie de gate-uri eliminatorii: scop clar, contract de măsurare, dovezi brute și control de securitate/confidențialitate.

Acest ghid nu recomandă un vendor și nu validează AYSA ori alt produs. Aplică aceleași întrebări unei platforme cumpărate, unui serviciu administrat sau unei soluții construite intern. Criteriile sunt publice; răspunsurile trebuie demonstrate și contractate acolo unde contează.

1. Definim joburile înaintea shortlistului

„Vrem un tool GEO” nu spune ce trebuie să facă. Echipa poate avea nevoie de:

• baseline pentru prezență, recomandare, citare și acuratețe;
• monitorizare pe limbi, piețe și suprafețe;
• rezolvarea brandurilor, produselor și aliasurilor;
• verificarea surselor și a afirmațiilor;
• comparații cu același numitor;
• investigația unei scăderi sau a unei informații greșite;
• propuneri de remediere cu aprobare umană;
• export în warehouse, BI, ticketing ori procese editoriale;
• dovezi pentru management, audit sau clienți.

Pentru fiecare job scriem utilizatorul, decizia, datele necesare, frecvența, riscul și rezultatul acceptabil. Abia apoi evaluăm platforma. O funcție spectaculoasă care nu rezolvă un job nu primește puncte doar fiindcă există.

2. Separăm non-negociabilele de preferințe

O matrice ponderată poate produce rezultate absurde dacă un scor mare la UI compensează lipsa exportului ori a metodologiei. Folosim două trepte:

1. must-pass: cerințe fără de care platforma este eliminată;
2. weighted fit: criterii în care produsele eligibile pot avea trade-off-uri.

Gate-urile sunt legate de risc și utilizare. O echipă mică poate accepta SSO într-o fază ulterioară, dar nu poate accepta un scor imposibil de reconstruit dacă scopul este raportarea auditabilă. O companie reglementată poate avea cerințe eliminatorii suplimentare validate de security și legal.

NIST AI Risk Management Framework organizează activitatea în Govern, Map, Measure și Manage. Nu certifică un produs, dar oferă o disciplină utilă: înțelegem contextul și riscul înainte să măsurăm și să alegem controalele.

3. Gate 1: ce suprafețe sunt măsurate?

„Monitorizăm ChatGPT” sau „măsurăm Google AI” este prea vag. Cerem pentru fiecare suprafață:

• interfața exactă și metoda de acces permisă;
• modelul ori eticheta observabilă și ce se întâmplă când se schimbă;
• căutare web activă sau alt mod relevant;
• limba, geografia și starea autentificării;
• prompt izolat sau conversație multi-turn;
• frecvența, numărul de repetări și fereastra temporală;
• cum sunt păstrate răspunsul, citările și erorile;
• ce se întâmplă când interfața nu este disponibilă.

Google descrie funcții AI care pot folosi query fan-out și sistemele Search existente. OpenAI spune că ChatGPT Search poate reformula întrebarea și continua cu alte căutări. Aceste exemple arată de ce un singur nume de platformă nu definește protocolul.

Vendorul trebuie să publice un coverage contract versionat, nu doar o grilă cu bife. Dacă metoda ori suprafața se schimbă, seria primește un marker și impactul este explicat.

4. Gate 2: contractul de măsurare

Cerem definiția fiecărui eveniment: mențiune, citare, shortlist, recomandare condiționată, alegere principală, excludere și afirmație. Cerem eligibilitatea scenariului, numitorul, deduplicarea, repetările, intervalele de incertitudine și tratarea răspunsurilor eșuate.

Un „visibility score 73” nu este suficient. Echipa trebuie să poată reconstrui scorul din observații și să vadă componentele separate. Ponderile sunt declarate și înghețate înaintea raportului. Dacă vendorul modifică formula, versiunea și series break-ul trebuie să fie vizibile.

Articolul despre numitorii KPI-urilor AI arată de ce două platforme pot afișa procente diferite din același set. În POC le cerem să calculeze aceeași formulă, nu comparăm două scoruri proprietare cu nume asemănătoare.

5. Gate 3: dovezile brute și proveniența

Pentru fiecare observație trebuie să putem recupera cel puțin scenariul, promptul, contextul, suprafața, data/ora, limba, geografia disponibilă, răspunsul, citările, URL-urile, entitățile, clasificările, evaluatorul și reviziile. O captură fără aceste câmpuri nu este un registru.

W3C PROV-O modelează proveniența prin entități, activități și agenți. Platforma nu trebuie să implementeze exact PROV-O, dar trebuie să păstreze un echivalent: ce intrare a produs ce rezultat, prin ce transformare și cu ce actor sau versiune.

Testăm exportul, nu acceptăm promisiunea. Alegem zece observații, exportăm datele și reconstruim manual ratele. Verificăm diacriticele, timestampurile, ID-urile, răspunsurile lungi, citările multiple, valorile necunoscute și istoricul reviziilor. Dacă exportul conține doar agregate, gate-ul nu trece pentru un caz auditabil.

6. Gate 4: securitatea și confidențialitatea

Platforma poate procesa prompturi, pagini publice, liste de concurenți, documente interne, strategii, conturi și propuneri de modificare. Înaintea POC-ului clasificăm datele și folosim materiale sintetice sau publice. Nu încărcăm secrete pentru a „vedea ce poate face”.

Checklistul minim acoperă:

• rolul contractual, scopul și locațiile de prelucrare;
• subprocesatori și notificarea schimbărilor;
• tenant isolation, controlul accesului, MFA/SSO după cerință;
• criptare, logging, backup și incident response;
• retenție, ștergere și recuperarea datelor la exit;
• folosirea datelor pentru antrenare sau îmbunătățire;
• separarea analizării de publicare ori execuție privilegiată;
• artefacte de securitate, scopul și valabilitatea lor.

Cloud Security Alliance Cloud Controls Matrix oferă un vocabular pentru controlul serviciilor cloud. Un chestionar completat este probă de revizuit, nu certificare automată. Regulamentul (UE) 2016/679 rămâne sursa juridică oficială pentru obligațiile aplicabile datelor personale; evaluarea finală aparține rolurilor competente.

7. Starea dovezii trebuie să fie vizibilă

Fiecare răspuns din evaluare primește una dintre stări:

Stare	Ce dovedește	Ce nu dovedește
documented	există document curent și delimitat	că funcția lucrează în mediul nostru
demonstrated	comportamentul a fost arătat controlat	obligație contractuală
contracted	obligația sau limita este în acord	performanță observată
observed	echipa a reprodus comportamentul în POC	acoperire universală
unknown	dovada lipsește ori se contrazice	că răspunsul este negativ

„Da” și „nu” pierd prea mult context. Pentru cerințele critice putem cere două stări: documentată și observată, apoi contractată înainte de semnare. Unknown rămâne vizibil și nu primește automat jumătate din punctaj.

8. Acoperirea se evaluează pe joburi, nu pe logo-uri

După gate-uri, evaluăm dacă platforma acoperă suprafețele, limbile, piețele, conversațiile și frecvențele care contează. Zece integrări inutile nu compensează absența limbii române ori a traseului multi-turn necesar.

Construim o matrice job × suprafață × piață × frecvență. Pentru fiecare celulă notăm suportul, metoda, limitările, costul și dovada. Separăm conectarea prin API de observarea unei interfețe pentru consumatori. Rezultatele nu sunt presupuse echivalente.

Acoperirea declarată primește puncte numai dacă poate fi demonstrată pe eșantionul comun. O bifă „global” fără limbă, locație și scenariu rămâne documentație incompletă.

9. Entity resolution este fundația comparației

Platforma trebuie să distingă compania, brandul, produsul, varianta, sellerul, fondul, persoana și sursa. Testăm aliasuri, diacritice, rebranding, nume identice, filiale, domenii și entități necunoscute. Un unknown bucket este obligatoriu; candidatul ambiguu nu este atribuit automat celui mai cunoscut brand.

Evaluăm:

• ID-ul canonic și relațiile dintre entități;
• regulile de alias și aprobarea manuală;
• proveniența fiecărei potriviri;
• confidence sau starea de incertitudine;
• corectarea fără rescrierea tăcută a istoriei;
• deduplicarea mențiunilor în aceeași observație;
• exportul mappingului și al reviziilor.

O eroare de entity resolution se propagă în share of voice, recomandare și rapoarte competitive. De aceea, verificăm identitatea înaintea scorurilor.

10. Sursele și afirmațiile trebuie separate

O platformă matură nu se oprește la „răspunsul are trei linkuri”. Leagă citarea de pasaj și descompune afirmațiile decisive: corect, incorect, neconfirmat sau depășit. Păstrează momentul, tipul sursei și reviewerul.

Testăm trei situații:

1. linkul există și susține afirmația;
2. linkul există, dar nu susține afirmația;
3. afirmația decisivă nu are sursă verificabilă.

Ghidul despre verificarea legăturii dintre citare și afirmație oferă contractul editorial. În POC comparăm verdictul platformei cu o referință manuală pe un subset, fără să pretindem că reviewerul uman este infailibil.

11. Workflow-ul trebuie să păstreze controlul

Dacă platforma propune modificări, cerem separarea dintre măsoară, explică, propune, aprobă, execută și verifică. Rolurile, permisiunile, difful, sursele, riscul, rollback-ul și logul nu sunt detalii opționale.

OWASP descrie prompt injection, inclusiv prin conținut extern. Excessive Agency arată riscul funcțiilor, permisiunilor sau autonomiei excesive. Un crawler care citește pagini neîncredere nu trebuie legat direct de publicare privilegiată.

Un produs exclusiv de măsurare poate trece fără execuție, dacă acesta este jobul. O platformă care pretinde execuție controlată trebuie să demonstreze gate-urile. Nu penalizăm lipsa unei funcții în afara scopului, dar nu acceptăm formulări ambigue.

12. Integrările și exportul se testează cu erori

Documentația API și webhook-urile sunt începutul. În POC verificăm schema, autentificarea, rate limits, paginarea, incremental sync, idempotency, retry, duplicate, timeout, date lipsă și versionare. Testăm importul într-un spreadsheet ori warehouse ales, nu doar exportul descărcat.

Cerem:

• date brute și agregate, cu ID-uri stabile;
• schema și changelogul exportului;
• API ori export programat potrivit volumului;
• webhook pentru evenimente importante, dacă este necesar;
• mecanism de backfill și corecție;
• limite și costuri pe volum;
• export complet la încetarea contractului.

Portabilitatea nu înseamnă un PDF. Echipa trebuie să poată continua analiza cu propriile date și să păstreze audit trail-ul conform obligațiilor sale.

13. Ponderile vin din risc și valoare

Pentru candidații care trec gate-urile, stabilim ponderile înaintea demo-urilor. Un exemplu intern poate prioritiza calitatea măsurării și exportul; altul poate prioritiza acoperirea multi-market și workflow-ul. Nu există un scorecard universal de 100 de puncte.

Șase familii utile sunt:

• acoperire relevantă;
• entity resolution;
• source și claim intelligence;
• workflow și control;
• integrări și export;
• implementare și cost total.

Fiecare criteriu are definiție, scală, dovadă minimă, owner și regulă pentru unknown. Nu acordăm puncte din impresie. Dacă diferența dintre doi candidați este sub incertitudinea evaluării, raportăm egalitate practică și alegem pe risc, contract ori cost.

14. POC-ul trebuie să fie același pentru toți

Construim 20–40 de scenarii fixe: branduite, nebranduite, recomandare, citare, afirmații, ambiguitate și multi-turn. Folosim același pașaport de entitate, aceleași aliasuri, aceeași fereastră și criterii de acceptare.

POC-ul include:

• două rulări prestabilite acolo unde evaluăm variabilitatea;
• un subset adnotat manual de doi revieweri;
• o entitate ambiguă și o afirmație fără dovadă;
• un răspuns eșuat sau o suprafață indisponibilă;
• un export brut reconstruit separat;
• un test de corecție și păstrare a istoricului;
• un test de permisiune, retenție și ștergere cu date sintetice;
• măsurarea timpului uman, nu doar a runtime-ului.

Nu schimbăm eșantionul după primele rezultate. Demo-urile vendorilor pot arăta capabilități suplimentare, dar scorecardul comparativ folosește aceeași probă.

15. Costul total include oamenii și ieșirea

Prețul abonamentului este doar o componentă. Calculăm:

• setup și integrare;
• curățarea entităților și construirea scenariilor;
• unitatea tarifată: prompt, răspuns, motor, proiect, utilizator sau export;
• overage, retenție și stocare;
• reviewerii și aprobările;
• training, suport și servicii profesionale;
• schimbări de metodologie și refacerea baseline-ului;
• migrare, export și ștergere la exit.

Simulăm un an normal și un vârf de utilizare. Cerem prețul pentru aceleași volume POC extrapolate. Un plan aparent ieftin poate deveni scump dacă exportul, reviewerii sau retenția sunt extra.

16. Contractul păstrează ceea ce demo-ul a dovedit

Înainte de semnare, transformăm cerințele critice în anexă: suprafețe și limitări, schema exportului, disponibilitate, suport, incident notification, retenție, ștergere, subprocesatori, schimbări materiale, portabilitate și termen de exit. Nu toate funcțiile au nevoie de SLA, dar fiecare promisiune critică are nevoie de text clar.

Profilul NIST pentru generative AI subliniază tratarea riscurilor pe parcursul ciclului de viață. Selecția nu se încheie la procurement: monitorizăm schimbările de model, suprafață, metodologie, securitate și performanță.

17. Întrebări care expun rapid un demo superficial

1. Pot reconstrui acest scor din observațiile exportate?
2. Ce numitor folosește și ce răspunsuri sunt excluse?
3. Ce suprafață exactă a produs această observație?
4. Cum păstrați promptul, contextul, citările și erorile?
5. Cum diferențiați brandul, produsul și aliasurile ambigue?
6. Cum marcați afirmațiile neconfirmate?
7. Ce se întâmplă când o interfață ori metodă se schimbă?
8. Pot exporta mappingul entităților și reviziile?
9. Ce date folosiți pentru îmbunătățirea serviciului?
10. Cine poate aproba și executa o schimbare?
11. Cât costă POC-ul extrapolat, inclusiv review și export?
12. Cum îmi recuperez și șterg datele la ieșire?

18. Ce nu facem

• nu alegem după numărul de logo-uri sau „modele suportate”;
• nu comparăm scoruri proprietare fără contract metodologic;
• nu lăsăm UI-ul să compenseze lipsa datelor brute;
• nu încărcăm date sensibile într-un demo neaprobat;
• nu echivalăm certificarea, demo-ul, contractul și observația;
• nu acordăm unknown-ului puncte presupuse;
• nu acceptăm publicarea automată fără limite și aprobare;
• nu schimbăm POC-ul pentru fiecare vendor;
• nu ignorăm costul oamenilor și al exitului;
• nu declarăm câștigător dacă diferența nu este materială;
• nu folosim acest articol drept dovadă că AYSA îndeplinește criteriile.

Verdict

Cea mai bună platformă de AI visibility nu este cea cu cele mai multe bife, ci cea care trece cerințele critice și rezolvă joburile organizației cu dovezi ce pot fi reconstruite. Gate-urile protejează metodologia, datele și controlul. Ponderile aleg între candidații eligibili, nu repară lipsurile fundamentale.

Decizia finală trebuie să poată răspunde simplu: ce observă platforma, cum măsoară, ce păstrează, ce putem exporta, cum verificăm, cine aprobă, ce risc asumăm, cât costă și cum ieșim. Dacă răspunsurile rămân în demo, slotul este încă necunoscut.

Surse

• NIST — AI Risk Management Framework
• NIST — Generative AI Profile
• W3C — PROV-O
• Cloud Security Alliance — Cloud Controls Matrix
• OWASP — Prompt Injection
• OWASP — Excessive Agency
• EUR-Lex — Regulation (EU) 2016/679
• Google Search Central — AI features and your website
• OpenAI — ChatGPT Search

Ghidul este independent de vendor și nu constituie audit de securitate, consultanță juridică ori recomandare de achiziție. Orice furnizor, inclusiv un produs propriu, trebuie verificat direct prin aceleași gate-uri, dovezi și teste.