Discuțiile despre AI în companii încep aproape mereu cu întrebarea „ce model folosim?”. E întrebarea greșită pentru început. Modelele se schimbă la câteva luni, prețurile se schimbă, regulile despre unde pot rula se schimbă. Dacă tot ce ai construit depinde de un anumit model, construiești pe nisip.
Mai jos, ce am văzut concret lucrând la un AI-asistent pentru o companie de distribuție, în septembrie 2026.
Am schimbat modelul, sistemul a rămas
În aceeași lună, AI-asistentul a trecut prin mai multe configurații: un model local, pe appliance-ul din sediul clientului, apoi un model mai mare, într-un centru de date european, apoi o combinație — modelul local pentru Area Sales Manager-i, cel din cloud doar pentru conversațiile deschise ale conducerii.
La fiecare schimbare, ce nu s-a schimbat a fost:
- datele — CRM-ul firmei, cu facturi, încasări și istoricul fiecărui client;
- uneltele — funcțiile care calculează restanțele, vânzările pe perioadă, grupele de produse în scădere;
- regulile de acces — un Area Sales Manager vede doar clienții lui, directorul vede toată firma, iar modelul nu poate lărgi aceste limite;
- întrebările de test — un set fix de întrebări, cu răspunsurile corecte cunoscute dinainte;
- notițele echipei — ce au aflat oamenii despre fiecare client.
Asta e partea care are valoare pentru companie. Modelul a fost, de fiecare dată, piesa care se putea înlocui.
Cinci lucruri care rămân ale companiei
Când proiectăm un sistem, pornim de la cinci straturi. Doar unul dintre ele are legătură cu modelul, și nici acela direct.
1. Memoria operațională. Ce se întâmplă în firmă: clienți, comenzi, vizite, documente, notițe. Trebuie să fie într-un loc pe care compania îl controlează, cu drepturi de acces pe persoană, echipă și firmă.
2. Registrul de decizii. Ce s-a hotărât, de cine, când și de ce. Exemplu: decizia ca Area Sales Manager-ii să folosească doar comenzi fixe, iar conversațiile deschise să rămână pentru conducere, a fost luată după teste, cu motivul scris. Peste un an, când cineva întreabă „de ce e așa?”, răspunsul există.
3. Standardele proprii de evaluare. Setul de întrebări cu care verifici orice model nou. Nu benchmark-uri publice — întrebările companiei tale, pe datele ei. O configurație intră în producție doar după ce răspunde corect la toate întrebările din set, fiecare într-o conversație nouă.
4. Aplicațiile și agenții. Comenzile, ecranele, integrările. Aici se folosește un model, dar prin interfețe standard, ca să poată fi înlocuit.
5. Acumularea. Fiecare proces validat întărește memoria. Următorul proces pornește de la ea, nu de la zero.
Contractul dintre model și sistem
Între model și restul sistemului există o interfață: numele uneltelor, formatul răspunsurilor, regula că textul cu cifre vine gata scris de server. O tratăm ca pe un contract.
Motivul e practic. Modelele nu citesc instrucțiunile la fel. Unele copiază exact ce scrie în text, altele interpretează. Dacă instrucțiunile numesc o unealtă altfel decât e înregistrată în sistem, un model poate merge, iar altul nu — fără să se fi schimbat nimic în date sau în cod.
De aceea contractul trebuie să fie al tău: scris, testat și verificat la fiecare schimbare de model. Atunci modelul din spate poate fi schimbat fără să se strice ce folosesc oamenii.
Pe scurt
- Nu începe cu alegerea modelului. Începe cu datele, uneltele și întrebările de test.
- Păstrează memoria și deciziile în sistemele companiei, nu în istoricul de conversații al unui furnizor.
- Scrie-ți propriul set de evaluare și rulează-l la fiecare schimbare de model sau de versiune.
- Decide explicit unde rulează fiecare model. E o decizie a conducerii, nu un detaliu tehnic.
Modelul de azi va fi înlocuit. Ce a învățat compania nu trebuie să plece odată cu el.
Vezi și: Quiet Trace, memoria companiei, și Oamenii din teren nu au nevoie de chat liber.