RAG pentru marketing: brand voice și claim-uri aprobate

Echipa de marketing are patruzeci de piese de livrat luna asta. Cere sistemului un paragraf despre modulul nou și primește un răspuns corect, cu citare din fișa tehnică. Îl aruncă: sună a manual.

A doua variantă sună bine — dar afirmă că produsul e „cel mai rapid din categorie”, o formulare aprobată acum doi ani, pentru o singură piață, pe o versiune înlocuită între timp. Nimeni nu observă. Textul trece printr-un review de zece secunde și pleacă public.

Ăsta e primul caz din cluster în care corpusul nu e o constrângere de fapte, ci una de exprimare. La enablement de vânzări, sistemul răspunde unui coleg care are un client anume pe fir. La support, unui client cu o problemă. Aici nu există destinatar identificat: textul pleacă la volum, către oricine, și rămâne acolo.

Ce se schimbă când output-ul e public și la volum

Mecanica RAG rămâne aceeași. Se schimbă ce înseamnă un răspuns bun și cine plătește când nu e.

Corect factual nu înseamnă utilizabil

Vocea de brand e o cerință de output, nu una de input. Nu e scrisă nicăieri sub formă de fapt care să poată fi citat — e o proprietate a întregului text: ritm, lungimea frazei, cât de mult hedging accepți, ce cuvinte nu folosești niciodată.

Retrievalul nu o poate satisface prin citare. Poate aduce o mie de fragmente perfect relevante și tot să producă un paragraf care sună a altă companie. Asta e diferența structurală față de toate cazurile de până acum: acolo, un retrieval mai bun rezolva problema. Aici nu o atinge.

„Adevărat” și „aprobat” sunt două filtre diferite

O afirmație comercială poate fi perfect adevărată și complet interzisă. Claim-urile se aprobă individual, iar aprobarea vine cu un domeniu de valabilitate: pentru ce piață, pentru ce produs și versiune, în ce perioadă, pe ce canal.

Un sistem care verifică doar dacă afirmația se susține în documentație trece testul de grounding și pică testul de conformitate. Sunt două întrebări separate, iar a doua nu se pune aproape niciodată în implementările pe care le vezi.

Volumul scapă de sub review

Un răspuns de helpdesk e citit de un om, o dată. O descriere de produs e citită de mii de oameni și rămâne indexată ani.

Când o echipă produce de patru ori mai mult text, review-ul nu se scalează în același ritm: devine mai rapid, apoi formal, apoi o bifă. Iar eroarea nu se repară cu un mesaj de scuze — e deja publicată, arhivată de terți și, în cazurile proaste, preluată de parteneri.

Restul cazurilor sunt în hub-ul de cazuri enterprise.

Brand voice nu se rezolvă prin retrieval

Prima greșeală de arhitectură e să tratezi ghidul de voce ca pe încă un document din index.

De ce indexarea ghidului de voce nu funcționează

Un ghid de voce e un set de reguli, nu o colecție de fapte. Regăsit ca fragment, ajunge în context ca text descriptiv — „tonul nostru e prietenos, dar profesionist” — pe care modelul îl citește și îl ignoră în proporție covârșitoare, fiindcă nu e o instrucțiune, e o descriere.

Ce funcționează e altceva: exemple canonice. Zece până la douăzeci de texte scurte, deja aprobate, pe tipuri diferite de piesă, alese pentru că sună exact cum vrei. Nu se regăsesc semantic — se atașează fix, pe tip de conținut, în fiecare cerere.

Regulile negative fac mai mult decât cele pozitive

„Scrie clar” nu produce claritate. „Nu folosi «soluție inovatoare», nu începe cu o întrebare retorică, nu depăși 22 de cuvinte pe frază” produce.

Lista de interdicții e cea care se poate verifica automat, iar asta o face de două ori valoroasă: intră și în prompt, și în poarta de ieșire de mai jos. Un termen interzis nu e o chestiune de gust când e prins de o expresie regulată.

Cum măsori tonul fără să spui „sună bine”

Construiește o rubrică de cinci criterii, fiecare cu o definiție operațională și un exemplu de eșec. Apoi evaluează în perechi: două variante, un om alege, se notează care și de ce. Douăzeci de perechi spun mai mult despre deriva de ton decât o sută de note de la 1 la 5 — oamenii sunt buni la comparat și proști la absolutizat.

Rubrica devine și setul de regresie, reluat la fiecare schimbare de model sau de exemple. Principiile de format sunt în cum arată un răspuns bun de RAG; aici constrângerea nu e forma, e vocea.

Vocea reală a clientului e altă sursă

Cea mai bună formulare pentru o problemă e, de obicei, a clientului care a descris-o: tichetele și recenziile conțin limbaj pe care nicio ședință de messaging nu-l produce. Extragi din ele formulări, nu concluzii — agregarea și pragurile de reprezentativitate sunt tratate separat, în sinteza feedbackului clienților.

Registrul de claim-uri: aprobarea are un domeniu de valabilitate

Ăsta e stratul pe care aproape nimeni nu-l construiește și care decide dacă sistemul e utilizabil.

Anatomia unui claim

Un claim înregistrat are șase câmpuri, toate obligatorii:

Ultimul câmp pare birocratic. Nu e: un claim comparativ și unul de mediu au regimuri juridice diferite de unul factual, iar sistemul trebuie să știe asta înainte să genereze, nu după.

De ce nu indexezi claim-urile ca text liber

Aceeași eroare de formă ca la prețuri în enablement de vânzări, dar cu alt obiect. Acolo, prețul era legat de o entitate exactă. Aici, claim-ul e legat de o combinație de condiții — piață, produs, versiune, perioadă — iar potrivirea trebuie să fie exactă pe toate simultan.

Căutarea semantică optimizează similaritatea. „Cel mai rapid din categorie” și „printre cele mai rapide soluții” sunt vecini apropiați în spațiul vectorial și complet diferiți juridic. Deci nu regăsești claim-uri prin similaritate: le selectezi prin filtru structurat pe cele patru dimensiuni, iar retrievalul intră abia după, ca să aducă contextul explicativ. Aceeași confuzie, privită dinspre datele de produs — descrierea care promite față în față cu atributul care măsoară — e tratată în RAG peste catalogul de produse.

Claim-ul expirat și claim-ul migrat

Două moduri în care un registru corect devine greșit fără ca cineva să modifice nimic.

Expirarea. O certificare are termen, iar un rezultat de benchmark ține până la următoarea versiune a concurentului. Un claim fără dată de expirare rămâne valabil pentru totdeauna în sistem, deși în realitate a murit.

Migrarea. Produsul se redenumește, versiunea 3 devine 4, claim-ul rămâne legat de eticheta veche — iar la prima cerere despre numele nou, retrievalul îl aduce oricum, fiindcă textele seamănă. Mecanica de reindexare e în prospețime, ștergeri și reindexare; ce se adaugă aici e că redenumirea trebuie să invalideze explicit, nu să reeticheteze tăcut.

Ce spune legea despre ce ai voie să scrii

Contextul juridic s-a mișcat vizibil în 2026, iar două dintre schimbări intră în vigoare la câteva săptămâni distanță una de alta.

Afirmațiile de mediu: reguli noi din 27 septembrie 2026

Directiva (UE) 2024/825 privind capacitarea consumatorilor pentru tranziția verde a avut termen de transpunere 27 martie 2026 și se aplică de la 27 septembrie 2026. România a transpus-o prin Ordonanța de urgență nr. 18/2026, publicată în Monitorul Oficial nr. 236 din 26 martie 2026, care modifică Legea nr. 363/2007 privind practicile incorecte ale comercianților și OUG nr. 34/2014.

Lista practicilor înșelătoare se extinde, din 27 septembrie 2026, cu: afișarea unei etichete de durabilitate care nu se bazează pe un sistem de certificare sau nu e stabilită de autorități publice; o afirmație generică legată de mediu pentru care comerciantul nu poate demonstra o performanță de mediu excelentă recunoscută; o afirmație despre întregul produs sau despre întreaga activitate atunci când ea privește doar o componentă.

Tradus în cerință de sistem: „eco”, „verde”, „prietenos cu mediul” fără dovadă atașată nu mai sunt o chestiune de stil, ci o categorie de claim cu prag propriu, pe care registrul trebuie s-o marcheze ca atare.

Green Claims: propunerea e blocată, nu construi procesul pe ea

Propunerea de Directivă privind afirmațiile ecologice (2023/0085(COD)) a ajuns în trilog, iar pe 20 iunie 2025 Comisia a anunțat intenția de a o retrage; al treilea trilog, programat pe 23 iunie 2025, a fost anulat. Programul de lucru al Comisiei pentru 2026 o listează în continuare ca pendinte, iar fișa Parlamentului European o marca la 20 aprilie 2026 cu statutul „blocată”.

Nu e retrasă formal și nu e adoptată. Concluzia practică: îți construiești procesul pe ce se aplică deja — 2024/825, transpusă — nu pe un text care poate să apară sau nu.

În B2B, comparația are condiții cumulative

Când publicul tău e format din firme, o parte din mesaje intră sub Legea nr. 158/2008 privind publicitatea înșelătoare și publicitatea comparativă, care protejează comercianții și stabilește condițiile în care comparația e permisă. Condițiile sunt cumulative: toate, nu majoritatea.

Consecința de arhitectură e dură și simplă — orice text generat care numește un concurent iese automat pe traseul de review juridic. Nu e o decizie editorială, e o regulă de rutare.

AI Act, articolul 50: ce se aplică din 2 august 2026 și ce nu

Obligațiile de transparență din articolul 50 se aplică de la 2 august 2026 și nu au fost amânate de pachetul de simplificare care a mutat regimul sistemelor cu risc ridicat în 2027 și 2028. Ele se aplică indiferent de clasificarea de risc. Clasificarea ca atare e discutată pe cazul juridic în RAG pe contracte și documente juridice — nu o relua aici.

Ce te privește direct, dacă publici conținut:

• Chatbot-ul de pe site trebuie să spună că e AI, cel târziu la prima interacțiune, clar și distinguibil — nu într-o notă de subsol.
• Marcarea machine-readable a conținutului sintetic e o obligație a furnizorului sistemului generativ, nu a ta ca utilizator. Pentru sistemele deja pe piață înainte de 2 august 2026, textul adoptat prevede o tranziție până la 2 decembrie 2026.
• Deepfake-urile — imagine, audio sau video care par autentice — trebuie declarate de cel care le publică.
• Textul generat cu AI trebuie declarat doar dacă e publicat cu scopul de a informa publicul asupra unor chestiuni de interes public. Declanșatorul e scopul publicării, nu subiectul. Iar obligația nu se aplică dacă textul a trecut printr-un proces de verificare umană și cineva poartă răspundere editorială pentru publicare — cu precizarea că verificarea trebuie să fie substanțială, nu o aprobare formală.

Ultima linie merită citită de două ori. O descriere de produs nu e text de interes public, deci nu intră automat sub obligația de etichetare. Dar excepția care contează în cazurile care intră e exact procesul pe care ar trebui să-l ai oricum: review real, cu un responsabil numit. Pe 20 iulie 2026 Comisia a publicat ghidurile de implementare pentru articolul 50, cu câteva săptămâni înainte de termen.

Arhitectura: trei straturi și o poartă de ieșire

Pipeline-ul care ține la volum separă strict ce se regăsește, ce se filtrează și ce se impune.

Ce intră în index și ce nu

Trei regimuri, ca la orice bază de cunoștințe bine pregătită, dar cu alte praguri.

Se indexează și se citează: fișe tehnice, specificații, documentație de produs, studii de caz aprobate, materiale de presă publicate.

Se atașează fix, nu se regăsește: exemplele canonice de voce, lista de termeni interziși, claim-urile valabile pentru cererea curentă.

Nu intră deloc: drafturi neaprobate, materiale retrase, conținut generat anterior de sistem. Ultimul e capcana tăcută — dacă output-ul se întoarce în index, în trei cicluri nimeni nu mai știe care formulare a fost aprobată de un om și care s-a auto-confirmat.

Poarta de ieșire: ce verifici determinist

Înainte ca textul să ajungă la omul care aprobă, patru verificări care nu au nevoie de model:

1. Claim neînregistrat — orice afirmație de performanță, superlativ sau cifră care nu se mapează pe un claim din registru.
2. Domeniu nepotrivit — claim valid, dar piața, produsul, versiunea sau perioada din cerere nu se încadrează.
3. Termen interzis — lista de cuvinte și tipare din ghidul de voce, plus formulările de mediu fără dovadă atașată.
4. Menționarea unui concurent — rutare automată spre review juridic, fără excepții.

Poarta nu îmbunătățește textul. Îl oprește. Diferența contează: un sistem care „corectează” automat un claim problematic produce o a doua formulare neaprobată, la fel de nesupravegheată ca prima.

Ce rămâne obligatoriu uman

Aprobarea unui claim nou. Sign-off-ul pe orice text comparativ sau cu afirmații de mediu. Și decizia finală de publicare, fiindcă acolo stă răspunderea.

Ce câștigi nu e eliminarea review-ului, ci concentrarea lui: oamenii se uită la ce a marcat poarta, nu la tot. Iar dacă registrul nu există încă, problema ta nu e de retrieval — pragurile de decizie sunt în când nu folosești RAG.

Trasabilitate: de la textul publicat înapoi la dovadă

Un sistem de conținut care nu poate răspunde la întrebarea „de unde vine afirmația asta” e util până la prima contestație.

Ce loghezi per piesă

Pentru fiecare text publicat: identificatorii claim-urilor folosite și versiunea lor, ce a marcat poarta și cum s-a rezolvat, cine a aprobat și când. Nu e o cerință de audit — e condiția ca retragerea de mai jos să fie posibilă.

Retragerea, care e partea grea

Când un claim pică — expiră certificarea, concurentul publică un benchmark mai bun, juridicul retrage o formulare — ai nevoie de indexul invers: de la claim către toate piesele publicate care îl folosesc. Fără el, retragerea e o căutare manuală prin site, newsletter, social și materiale de partener, care se termină de obicei incomplet. Cu el, e o listă.

Aprobarea și trasabilitatea în forma lor strictă sunt tratate separat; aici ai nevoie doar de legătura claim → conținut, nu de o pistă de audit completă.

Datele personale din corpus

Studiile de caz și transcrierile de interviu conțin nume, funcții și uneori informații pe care clientul nu a agreat să le vadă publicate. Regimul e cel din RAG și GDPR, iar consimțământul pentru publicare se marchează ca metadată — nu se presupune din faptul că documentul stă în Drive.

Ce măsori și ce cifre din piață nu merită încrederea

Patru indicatori care spun ceva

Rata de piese publicate fără corecție post-review. Din textele care au trecut de poartă și de om, câte au necesitat modificări după publicare. E metrica de calitate reală a lanțului.

Claim-uri neînregistrate prinse de poartă. Dacă numărul e zero, poarta nu funcționează. Dacă e foarte mare, registrul e incomplet — ambele sunt semnale, în direcții diferite.

Rata de refuz corect. Câte cereri au primit „nu există un claim aprobat pentru asta” în loc de un paragraf plauzibil. Un sistem fără refuzuri pe categoria asta nu e productiv, e periculos.

Timpul până la prima versiune acceptabilă. Nu timpul de generare, ci timpul până la un text pe care omul îl duce mai departe fără rescriere. Restul metricilor se construiesc ca în cum evaluezi un sistem RAG, pe fidelitatea față de sursă.

De ce nu găsești aici „AI crește conversia cu X%”

Spațiul cifrelor despre AI în marketing e, practic, integral produs de furnizori care vând exact instrumentul măsurat. Problema nu e reaua-credință, ci metodologia: aproape niciun studiu nu declară numitorul, aproape niciunul nu are grup de control, iar creșterile raportate coincid de obicei cu schimbări simultane de canal, de segment sau de buget.

Un procent de conversie fără canal, perioadă și populație nu înseamnă nimic. Dacă vrei un număr pentru un business case, produ-l tu: rulează piesele generate și cele scrise manual în paralel, pe același canal și în aceeași perioadă. Va fi mai mic decât în broșuri și va fi al tău.

La orice cifră din piață: caută forma originală, verifică anul, verifică numitorul. Dacă lanțul se rupe după doi pași, nu o folosi — cu atât mai puțin într-un text public, care devine el însuși o afirmație pe care o susții.

Ce arăți în primele șase săptămâni

Un pilot onest e îngust: un singur tip de piesă — descrieri de produs, de obicei — o singură piață, registrul construit manual pentru o linie de produs, exemplele canonice alese din materiale deja aprobate și poarta cu două verificări din patru.

Livrabilul nu e un generator de conținut. E registrul de claim-uri și rata de piese care trec fără corecție. Restul se adaugă după, când stratul de dedesubt e corect.

Întrebări frecvente

Trebuie să etichetez ca „generat cu AI” textele de marketing?

Nu automat. Obligația din articolul 50 pentru text se aplică publicării făcute cu scopul de a informa publicul asupra unor chestiuni de interes public, iar o descriere de produs nu intră acolo. Chatbot-ul de pe site și conținutul de tip deepfake sunt situații distincte, cu obligații proprii. Analiza pe cazul tău se face cu juridicul, nu după un articol.

Pot antrena modelul pe arhiva de conținut în loc să folosesc exemple?

Poți, dar rezolvi altă problemă. Fine-tuningul mută tonul mediu al modelului spre corpusul tău, dar nu îți dă control asupra claim-urilor și nu se actualizează când juridicul retrage o formulare. Compromisul e în RAG vs fine-tuning; în practică, exemple canonice plus registru acoperă mai mult, mai ieftin și reversibil.

Cine ține registrul de claim-uri?

Cineva anume, cu nume. Unde funcționează, e product marketing pentru enunț și dovadă, juridic pentru tip și domeniu de valabilitate. Un registru fără proprietar se degradează în șase luni și devine mai periculos decât absența lui, fiindcă inspiră încredere.

Cum împiedic derapajele de ton între limbi?

Nu traduci textul aprobat, îl regenerezi din aceleași fapte cu exemple canonice în limba țintă. Traducerea automată păstrează structura frazei din limba sursă și produce texte corecte gramatical care sună străin. Pentru română, testează pe materiale reale, nu pe traduceri din engleză.

Merge același sistem și pentru echipa de vânzări?

Parțial. Stratul de fapte se suprapune, dar destinatarul schimbă tot: acolo răspunsul e pentru un client anume, cu presiune de timp și cu risc de angajament contractual, nu pentru public. Diferențele de router, format și permisiuni sunt în RAG pentru enablement de vânzări.

Un RAG pentru marketing nu e un generator de text peste Drive. E un mecanism care decide ce are voie compania să afirme public, în ce formulare și pe baza cărei dovezi. Fapte regăsite, claim-uri filtrate pe domeniu de valabilitate, voce impusă prin exemple, o poartă care oprește în loc să corecteze și o legătură inversă de la textul publicat înapoi la dovadă.

Dacă vrei să construiești unul — sau doar să afli dacă problema ta e de retrieval ori de registru — scrie-ne. Restul cazurilor și al arhitecturilor sunt în secțiunea despre AI și RAG.