RAG pentru parteneri și distribuitori: acces contractual

Doi distribuitori. Același produs, teritorii vecine, aceeași grilă de comisioane — și o rivalitate reală pentru conturile de la graniță. Amândoi au acces la asistentul RAG construit peste documentația ta tehnică și amândoi întreabă, în aceeași dimineață, ce configurație se recomandă pentru un client din retail cu patruzeci de locații.

Dacă primesc același răspuns, e în regulă. Dacă unul dintre răspunsuri conține o propoziție despre ce a cerut celălalt, ai o problemă cu nume juridic.

Ăsta e primul caz din serie în care omul care întreabă e din afara organizației tale și, totuși, nu e clientul final. Nu e angajat, deci nu apare în nicio organigramă. Nu e client, deci nu întreabă despre propriul lui cont. E o entitate juridică separată, cu interese comerciale proprii, care are voie să vadă o parte din corpusul tău fiindcă așa scrie într-un contract — și doar cât timp scrie acolo.

Mecanica de retrieval rămâne aceeași. Modelul de acces, nu.

Ce se schimbă într-un RAG când utilizatorul nu e al tău

Trei diferențe se propagă în arhitectură, iar prima e o problemă de clasificare, nu de tehnologie.

Trei categorii de „extern” care nu se confundă

Categoria din mijloc e cea neglijată. Pentru clientul final există deja un tipar consacrat, iar granița dintre el și un intermediar e discutată în RAG pentru customer support. Pentru partener nu există: seamănă cu un coleg — întreabă lucruri de insider, are nevoie de detaliu tehnic — și se comportă ca un terț, cu propriile interese, propriii clienți și, adesea, propriii concurenți în rețeaua ta.

Izolarea nu mai e pe rol, e pe entitate juridică

Filtrarea pe rol la retrieval e o problemă rezolvată: cine ce are voie să vadă, cu ce mecanism, în ce motor — toate sunt în controlul accesului în RAG, și nu are rost reluată.

Ce se schimbă e natura graniței. Un rol e definit în sistemele tale și poate fi schimbat de cineva din companie într-o după-amiază. O entitate juridică e definită în afara lor, într-un document semnat de două părți, iar trecerea peste graniță nu se numește configurare greșită, ci încălcare contractuală — și partea vătămată are interes direct să o reclame.

Practic ajungi cu două niveluri suprapuse: întâi entitatea, apoi rolul în interiorul ei. Al doilea e mecanica deja cunoscută. Primul e cel nou.

Nici tiparul multi-tenant clasic nu se transferă. Într-un SaaS, fiecare client interoghează propriile date; aici toți partenerii interoghează datele tale, filtrate diferit, iar drepturile sunt asimetrice — doi parteneri din aceeași categorie pot avea scopuri diferite, fiindcă au negociat diferit. Segmentarea pe cont de client din RAG pentru enablement de vânzări e ruda cea mai apropiată, dar acolo consumatorul răspunsului era colegul tău. Aici e cineva care poate deveni, la următoarea renegociere, parte adversă.

Scopul de acces are dată de început și de sfârșit

A doua diferență: intern, un drept de acces e implicit permanent până când cineva îl retrage. Cu un partener e invers — e temporar prin construcție, iar durata lui e scrisă undeva.

Contractul e schema, nu organigrama

Ce are voie să vadă un partener nu se deduce din funcție. Se citește din anexa de servicii a contractului lui: ce linii de produs acoperă, pe ce teritoriu, cu ce nivel de certificare, până când.

Informația există deja, structurată, în sistemul de management al partenerilor sau în CRM — doar că nimeni nu a modelat-o ca predicat de filtrare. E același tipar ca la profilul de eligibilitate din RAG pentru HR, cu o deosebire care contează: acolo cheia era un atribut al persoanei, aici e o clauză cu dată de expirare.

Cheile de aplicabilitate ale unui fragment expus extern

Fiecare bucată de conținut care poate ajunge la un partener are nevoie de minimum cinci atribute, stabilite la ingestie:

• Nivelul de expunere — intern, partener, public. Trei valori, nu două: majoritatea corpusurilor au doar „intern” și „publicat”, iar zona de mijloc ajunge tratată ad-hoc.
• Categoria de partener îndreptățită — distribuitor, integrator, service autorizat, revânzător.
• Linia de produs la care se referă și teritoriul, acolo unde condițiile diferă pe piețe.
• Perioada de valabilitate a materialului, distinctă de cea a contractului.

Fără ele rămâne o singură variantă: să speri că modelul deduce din text cui i se aplică documentul. Nu deduce.

Trei momente pe care sistemul trebuie să le cunoască

Semnarea și activarea nu coincid aproape niciodată — între ele stau un onboarding, o instruire, uneori o certificare. Actul adițional extinde sau restrânge scopul fără să schimbe contractul. Expirarea e cunoscută dinainte, deci poate fi programată, nu detectată. Același raționament se aplică oricărui angajament cu termen: la o scrisoare de garanție, ziua de expirare stinge dreptul singură, fără niciun act și fără să lase urmă în document — RAG pe scrisori de garanție.

Diferența față de revocarea unei permisiuni interne e că aici ai data dinainte. Un scop care expiră pe 31 decembrie poate fi închis atunci de un job programat în ziua semnării. Nu ai nevoie de detecție, ci de disciplina de a pune data în sistem, nu într-un PDF.

Doi parteneri concurenți pe același index

A treia diferență e că adversarul plauzibil nu mai e un angajat curios, ci o firmă cu motiv comercial și buget de timp.

Ce se scurge fără să treacă vreun document

Canalele laterale clasice — metadate în citare, oracol de existență, agregarea peste fragmente permise — sunt inventariate în articolul despre controlul accesului. Aici se adaugă unul care nu apare intern: agregarea în timp, de un interogator persistent.

Un partener care pune treizeci de întrebări bine alese în trei luni reconstituie lucruri pe care nu i le-ai spus direct: ce integrări sunt în lucru, ce probleme apar frecvent la un produs, ce categorii de clienți sunt acoperite de alții. Fiecare răspuns în parte e legitim. Suma lor e informație competitivă.

Contramăsurile sunt plictisitoare și funcționează: limitare de rată pe cont de partener, refuzul întrebărilor formulate ca inventar („listează toți...”, „câți...”) și jurnal de interogări păstrat pe entitate, nu doar pe utilizator.

Partiție per entitate, nu filtru pe metadate

Costul izolării dure prin partiții separate e discutat în articolul despre controlul accesului. Argumentul care înclină balanța aici nu e tehnic: granița dintre două entități juridice e auditabilă de o terță parte. Un partener poate cere, contractual, dovada că datele lui nu sunt vizibile pentru concurentul lui din rețea, iar „filtrăm pe un câmp de metadate” nu supraviețuiește întrebării „și cine verifică?”. Un filtru uitat într-o ramură de cod produce, intern, un incident. Între două entități, produce o notificare către juridic.

Stratul comun și ce pui în el

Cea mai mare parte a corpusului de partener e comună: documentație de produs, ghiduri de instalare, materiale de instruire, condiții generale. Doar o felie subțire e specifică unei entități — istoricul ei de tichete, volumele ei, condițiile ei.

Structura care rezultă: un index comun, interogat de toți, plus câte o partiție per entitate, cu rezultatele reunite la final. Cu o singură condiție — feliile private nu sunt o listă de excepții peste indexul comun, ci un spațiu separat. Excepțiile se uită; partițiile nu.

Ce ai voie să-i spui unui distribuitor

Aici intervine un set de reguli care nu apare în niciun alt caz din serie: dreptul concurenței. Nu tot ce poți partaja tehnic ai și voie să partajezi.

Când relația devine și orizontală

Distribuția duală e situația în care furnizorul își vinde produsele atât prin distribuitori independenți, cât și direct către clienții finali — deci concurează, în aval, cu propria rețea. Relația rămâne verticală în amonte și devine orizontală în aval.

Regulamentul (UE) 2022/720 al Comisiei — regulamentul de exceptare pe categorii pentru acordurile verticale, adoptat pe 10 mai 2022 — a intrat în vigoare la 1 iunie 2022 și expiră la 31 mai 2034. Exceptarea se aplică în general dacă niciuna dintre părți nu depășește pragul de cotă de piață de 30% pe piețele relevante și dacă acordul nu conține restricții grave. Articolul 2(5) scoate însă din exceptare schimbul de informații care nu e direct legat de implementarea acordului vertical sau nu e necesar pentru îmbunătățirea producției ori distribuției produselor contractuale. Articolul 2(6) exclude complet acordurile privind servicii de intermediere online prestate de furnizori care vând ei înșiși bunuri concurente — platformele cu funcție hibridă.

Lista albă și lista neagră din Orientările verticale

Orientările privind restricțiile verticale care însoțesc regulamentul dau două liste neexhaustive. La punctul 99, informația care în general poate fi schimbată: informații tehnice despre produse, informații logistice de producție și distribuție, date despre achizițiile și preferințele clienților în formă agregată, prețurile la care furnizorul vinde către cumpărător, prețurile de revânzare recomandate sau maxime, informații de marketing și campanii promoționale, plus informații de performanță agregate care nu permit identificarea unui anumit cumpărător concurent.

La punctul 100, informația care în general nu se califică: prețurile viitoare la care furnizorul sau cumpărătorul intenționează să vândă în aval, informațiile individuale despre utilizatori finali identificați (cu excepții limitate — adaptarea produsului la cerințele acelui client, implementarea unui acord de distribuție selectivă sau exclusivă) și informațiile despre produsele vândute sub marcă proprie, schimbate cu un producător de mărci concurente.

Comisia menționează măsurile de tip firewall și separarea echipelor ca precauție pentru schimburile din afara listei albe. Merită reținut că autoritățile naționale de concurență și instanțele nu sunt ținute juridic de Orientări — sunt un instrument de autoevaluare, nu o autorizație.

Firewall-ul devine un predicat de retrieval

Într-o organizație clasică, firewall-ul de informații e o măsură organizatorică: echipa de vânzare directă nu primește datele granulare ale distribuitorilor. Într-un sistem RAG devine ceva mai dur și mai verificabil — un predicat aplicat la interogare. Indexul care servește echipa ta de vânzare directă și cel care conține raportările detaliate ale distribuitorilor nu au voie să fie același spațiu interogabil, oricât de convenabil ar fi. Iar întrebarea „ce a vândut distribuitorul X luna trecută, pe client” primește refuz, nu rezultate.

Nimic de mai sus nu ține loc de consultanță juridică. Ce ține loc: o listă de categorii de conținut, revizuită cu juristul, transformată în valori de metadate înainte de prima ingestie.

Rolurile GDPR și lanțul contractual

Când în corpus sau în interogări apar date cu caracter personal — nume de persoane de contact, tichete, note de vizită —, prima întrebare nu e tehnică. E în ce calitate prelucrează partenerul.

Partenerul rareori e „persoană împuternicită”

Împuternicitul prelucrează datele pe baza instrucțiunilor documentate ale operatorului. Un distribuitor care interoghează corpusul tău ca să-și servească propriii clienți nu face asta: urmărește scopuri proprii, deci e, de regulă, operator separat. Confuzia costă — semnezi un acord de prelucrare acolo unde aveai nevoie de o delimitare de responsabilități între doi operatori și rămâi cu un document care nu descrie realitatea. Bazele de prelucrare și mecanica de securitate sunt în RAG și GDPR; aici se adaugă strict relația cu terțul.

Ce trebuie să conțină contractul dacă chiar e împuternicire

Articolul 28 din GDPR cere ca operatorul să folosească doar împuterniciți care oferă garanții suficiente privind măsurile tehnice și organizatorice, iar contractul trebuie să prevadă, între altele: prelucrarea numai pe baza instrucțiunilor documentate, inclusiv pentru transferuri în afara Uniunii; confidențialitatea persoanelor autorizate; măsurile de securitate; condițiile de angajare a unui alt împuternicit; ștergerea sau returnarea datelor la încetarea serviciilor; și punerea la dispoziție a informațiilor necesare pentru audituri.

Ghidul Comitetului European pentru Protecția Datelor privind conceptele de operator și împuternicit avertizează că un asemenea contract nu trebuie să fie o simplă reluare a textului articolului 28 — are nevoie de informații concrete despre cum se îndeplinesc cerințele. Tot acolo: instrucțiunile se documentează, de preferință într-o anexă păstrată împreună cu contractul, iar modificarea unilaterală prin publicarea unor termeni noi pe site-ul împuternicitului nu e conformă.

Lanțul nu se oprește la partener

Articolul 28(4) impune ca aceleași obligații din contractul inițial să fie transferate mai departe către orice sub-împuternicit, iar împuternicitul inițial rămâne pe deplin răspunzător față de operator. În Opinia 22/2024, adoptată în octombrie 2024, Comitetul European pentru Protecția Datelor a mers mai departe: operatorul trebuie să dispună în orice moment de identitatea tuturor împuterniciților și sub-împuterniciților din lanț, cu descrierea prelucrării și o delimitare clară a responsabilităților — indiferent de riscul asociat.

Consecința pentru cazul de față: dacă partenerul îți conectează indexul la asistentul lui, furnizorul lui de model intră în lanț. Întrebarea „cine mai vede fragmentele returnate” nu se oprește la firma cu care ai semnat.

O notă de prospețime: pachetul „Digital Omnibus”, propus de Comisia Europeană pe 19 noiembrie 2025, ar modifica mai multe acte din domeniul datelor, inclusiv GDPR. Comitetul European pentru Protecția Datelor și Autoritatea Europeană pentru Protecția Datelor au adoptat o opinie comună pe 11 februarie 2026, iar textul e în continuare în procedura legislativă. Până la adoptare rămâne o propunere, nu o bază de arhitectură.

Dacă platforma ta intermediază

Portalul prin care partenerii primesc lead-uri sau vând poate intra sub Regulamentul (UE) 2019/1150 privind echitatea și transparența pentru utilizatorii comerciali ai serviciilor de intermediere online: termeni și condiții clare, cu preaviz de cel puțin 15 zile la modificări; motivarea restricționării, suspendării sau încetării; parametrii principali de ierarhizare; descrierea accesului la date; sistem intern de soluționare a plângerilor. Dacă asistentul explică oricare dintre ele, explicația devine ea însăși comunicare reglementată.

Output-ul pleacă co-branded

Într-un asistent intern, un răspuns greșit produce o încercare eșuată. Aici, răspunsul trece printr-un om care îl repetă clientului lui, adesea sub logo comun.

Greșeala ta devine afirmația partenerului

Inginerul partenerului citește pe ecran „configurația e compatibilă” și o spune mai departe. Pentru clientul final, afirmația vine de la partener. Pentru partener, vine de la tine. Când se dovedește greșită, discuția nu mai e despre calitatea retrievalului, ci despre cine suportă costul remedierii.

Asta ridică pragul pentru două lucruri deja tratate în cluster: angajamentele comerciale accidentale, din RAG pentru enablement de vânzări, și claim-urile despre produs, din RAG pentru marketing și conținut. Ce se schimbă e că bariera de la ieșire nu mai protejează un coleg, ci limitează ce poate afirma o altă firmă în numele tău.

Marcajul de sursă nu e o notă de subsol

Formatul minim pentru un răspuns care pleacă în exterior: afirmația, documentul-sursă cu versiune și dată, plus o etichetă explicită de statut — confirmat, orientativ sau neconfirmat. Un răspuns fără versiune e inutilizabil într-o discuție de garanție șase luni mai târziu. Principiile de sinteză și de refuz sunt în cum arată un răspuns bun de RAG; constrângerea suplimentară aici e că răspunsul trebuie să reziste citat în afara contextului în care a fost dat.

Ce nu are voie sistemul să afirme

Trei clase, în ordinea gravității: condiții comerciale (preț, termen, disponibilitate), care merg către sursa care le deține; informații despre alt partener, în orice formă, inclusiv agregată dacă rețeaua e mică; capabilități neconfirmate de documentația oficială. Pentru toate trei, comportamentul corect e refuzul cu redirecționare, nu formularea prudentă.

Offboarding, retragere și ce poți dovedi

Ultima diferență e cea mai concretă: contractul se termină. Într-o relație internă, plecarea unui om e un eveniment în sistemul de HR. Aici e o dată din contract, iar consecințele trec dincolo de sistemele tale.

Retragerea e un eveniment cu oră

Trei declanșatoare, cu urgențe diferite: expirarea la termen (cunoscută dinainte, programabilă), rezilierea (imediată, adesea într-un context tensionat) și restrângerea de scop printr-un act adițional (parțială, cea mai ușor de ratat). Pentru toate trei mecanismul e același — verificare la interogare pe apartenența la entitate, citită din sursa de adevăr, nu materializată în index. Ștergerea și reindexarea sunt în prospețime, ștergeri și reindexare.

Ce nu se mai poate retrage

Ce a fost citit a fost citit. Ce a fost exportat a plecat. Nicio revocare nu le aduce înapoi, iar asta mută efortul în perioada în care accesul e activ:

• Fără export în masă. Interfața răspunde la întrebări, nu livrează corpusul: fără arhive descărcabile, fără endpoint care returnează sute de fragmente.
• Limitare de rată pe entitate, nu doar pe utilizator. Zece conturi ale aceluiași partener sunt un singur interogator.
• Jurnal de interogări păstrat pe entitate, cu filtrul de securitate efectiv aplicat — singura formă de dovadă care rămâne după încheierea relației, și singura care leagă un fragment reapărut altundeva de o sursă.

Ce ștergi și ce dovedești

Dacă relația a fost de împuternicire, obligația de ștergere sau returnare din articolul 28 funcționează în ambele sensuri: ștergi datele partenerului din indexul tău, ceri dovada ștergerii datelor tale de la el și păstrezi jurnalul care arată ce a fost accesat cât timp accesul a existat. Forma de trasabilitate cerută de un audit e în RAG pentru conformitate și audit intern.

Trei indicatori pe care îi urmărești

Rata de scurgere între entități — câte răspunsuri au inclus conținut dintr-o partiție străină. Ținta e zero; orice abatere e incident, nu defect de calitate.

Latența de retragere — de la semnalul contractual până la prima interogare refuzată. O măsori revocând un scop într-un mediu de test și cronometrând.

Rata de refuz corect pe întrebări în afara scopului. Un sistem care nu refuză nimic aici nu e permisiv, e nedelimitat.

Setul de evaluare se construiește pe perechi de entitate și întrebare: același set rulat pentru cinci-șase profiluri de partener sintetice, cu răspunsul corect diferit pentru fiecare. Instrumentarul general rămâne cel din metricile de evaluare RAG, iar pragul de la care problema nu mai e de retrieval e în când NU folosești RAG.

Întrebări frecvente

Pot să le dau partenerilor acces la aceeași aplicație internă?

Nu, decât dacă aplicația a fost construită de la început cu entitatea ca dimensiune de filtrare. O aplicație internă presupune că toți utilizatorii sunt din aceeași organizație și că granițele sunt de rol. Adăugarea unei entități externe peste presupunerea asta se face, în practică, prin excepții în cod — exact ce se uită la următorul refactor.

Partenerul vrea să conecteze indexul la asistentul lui. Ce ceri în schimb?

Trei lucruri: identitatea completă a lanțului lui de prelucrare, inclusiv furnizorul de model; interdicția contractuală de a folosi conținutul returnat pentru antrenare sau pentru un corpus derivat; și un mecanism verificabil prin care accesul se închide la încetarea contractului. Fără al treilea, primele două sunt declarații.

Cum tratez un partener care e și concurent?

Ca pe o entitate cu scop restrâns, nu ca pe o excepție. Restrângerea se face pe categorii de conținut definite în avans, nu prin decizii punctuale la fiecare cerere. Iar dacă relația e de distribuție duală, delimitarea se face cu juristul, pe listele din Orientările verticale, înainte de prima ingestie.

Ce fac cu întrebările despre alți parteneri?

Refuz explicit, formulat identic indiferent dacă informația există sau nu. Un mesaj diferit pentru „nu există” față de „nu ai voie” transformă sistemul într-un instrument de confirmare pentru cine vrea să afle cine altcineva e în rețea. Aceeași regulă se aplică și agregatelor: „media pe rețea” devine o cifră despre concurent când rețeaua are trei membri.

Un asistent deschis către rețeaua de parteneri se construiește în ordinea asta: nivelul de expunere pe fiecare fragment, scopul contractual cu datele lui, partițiile pe entitate, barierele de la ieșire și, abia la final, retrieval-ul. Ordinea inversă — retrieval întâi, granițe după — produce discuția neplăcută cu juridicul la șase luni după lansare. Iar când relația nu e o rețea permanentă, ci o fereastră cu termen deschisă peste corpusul altei companii, aceleași principii se rearanjează complet — cazul e tratat în RAG pentru due diligence.

Restul cazurilor documentate stau în cazuri de utilizare enterprise, stratul de permisiuni în control acces RAG, protecția informației în securitatea datelor, iar imaginea completă a unui sistem livrat end-to-end în hub-ul de soluții AI și RAG.