AI trebuia să ofere companiilor avantaj. Poate și crea o nouă dependență
Acum câțiva ani discuția despre vendor lock-in se referea mai ales la cloud, sisteme ERP, baze de date sau platforme tehnologice critice.
Companiile își puneau întrebări: Putem muta aplicația la alt cloud provider?, Putem schimba baza de date?, Putem renunța la un anumit sistem?
Astăzi la această listă se adaugă un nou element - inteligența artificială.
Organizațiile tot mai des construiesc sisteme care folosesc modele de limbaj, AI generativ, soluții RAG, automatizări de procese și agenți AI. Modelele devin parte din aplicații, procese de vânzare, suport clienți, analiză de documente, sisteme decizionale și munca zilnică a echipelor.
În practică asta înseamnă că o companie poate deveni dependentă nu doar de un anumit software, ci și de un anumit furnizor al inteligenței folosite de sistemele ei.
Și aici apare problema. Pentru că e o diferență între a folosi un serviciu AI și a fi dependent de el.
Aceasta este tocmai diferența între o dependență tehnologică conștientă și vendor lock-in.
Ce este, de fapt, AI Vendor Lock-in?
Vendor lock-in înseamnă o situație în care o organizație este atât de strâns legată de un furnizor de tehnologie, încât trecerea la o soluție concurentă devine dificilă, costisitoare, consumatoare de timp sau riscantă.
În lumea AI poate lua mult mai multe forme decât dependența clasică de un singur API.
O companie poate fi dependentă de:
- unui anumit model AI,
- unui anumit furnizor de API,
- unui format de comunicare specific,
- funcționalităților disponibile exclusiv la un singur furnizor,
- unui sistem de agenți,
- infrastructurii cloud,
- modului de stocare a datelor,
- unui mecanism concret de embeddings,
- unui sistem RAG specific,
- modului în care agenții apelează uneltele,
- prompturilor optimizate pentru un model anume,
- competențelor echipei legate de un ecosistem anume.
Întrebarea: "Folosim OpenAI?"
este mult prea simplă.
O întrebare mai bună este: "Cât de dificil ar fi pentru noi să schimbăm furnizorul de AI dacă ar fi nevoie peste șase luni?"
Dacă răspunsul este: "Nu știm." - atunci acesta poate fi primul semnal de alarmă.
OpenAI, Anthropic, Google - contează alegerea furnizorului?
Pe piață există astăzi câteva ecosisteme foarte puternice de modele și servicii AI, între altele soluțiile oferite de OpenAI, Anthropic și Google.
Fiecare dintre acești furnizori dezvoltă propriile modele, API-uri, unelte și servicii adiționale.
Problema nu este că vreunul e "rău". Dimpotrivă.
Folosirea de modele gata făcute, de calitate înaltă, este adesea cea mai bună alegere de business. Nu fiecare companie ar trebui să antreneze un model propriu. Nu fiecare are nevoie de infrastructură GPU proprie. Nu fiecare ar trebui să construiască întregul stack AI de la zero.
Utilizarea unui furnizor extern permite intrarea mai rapidă pe piață, reducerea costurilor inițiale și acces la tehnologie pe care crearea ei internă ar face-o inaccesibilă majorității organizațiilor.
Problema apare când compania încetează să mai considere furnizorul un component înlocuibil și proiectează produsul ca și cum furnizorul ales ar rămâne neschimbat pentru următorii 10 ani.
Iar asta nu poate fi garantat...
Modelele sunt actualizate, versiunile vechi sunt retrase, prețurile se schimbă, limitele se schimbă, API-urile se schimbă, apar modele noi, se modifică condițiile licențiale, cresc capabilitățile concurenței.
Este o parte normală a pieței tehnologice.
De aceea arhitectura AI ar trebui să ia în considerare nu doar întrebarea: "Care model e cel mai bun astăzi?"
ci și: "Ce preț vom plăti dacă peste un an vom dori să folosim altul?"
Cea mai mare capcană - „până la urmă vom schimba API-ul"
La prima vedere migrația poate părea banală.
Avem o aplicație. Aplicația trimite o cerere către model. Modelul răspunde. Schimbăm furnizorul. Gata...
În realitate situația poate arăta complet diferit.
Imaginați-vă o aplicație care a fost dezvoltată timp de doi ani în jurul unui singur model.
În acest timp echipa a:
- creat sute de prompturi,
- optimizat conținutul lor,
- adaptat formatul răspunsurilor,
- construit un sistem RAG,
- configurat tool calling,
- creat agenți,
- proiectat workflow-uri,
- pregătit teste,
- instruit utilizatorii să lucreze cu sistemul.
După doi ani se dovedește că modelul nu mai este disponibil în forma anterioară.
Sau prețul lui crește, sau un model concurent devine semnificativ mai bun, sau compania vrea să mute o parte din date într-un alt mediu.
Teoretic ar trebui doar să schimbăm API-ul. Practic s-ar putea să fie nevoie să retestăm întreaga logică a sistemului.
De ce?
Pentru că modelele nu sunt identice:
- se diferențiază prin modul de interpretare a instrucțiunilor,
- se diferențiază prin calitatea răspunsurilor,
- se diferențiază prin comportamentul în contexte lungi,
- se diferențiază prin utilizarea uneltelor,
- se diferențiază prin suportul pentru structured output,
- se diferențiază prin capabilități multimodale,
- se diferențiază prin viteză,
- se diferențiază prin preț,
- se diferențiază și prin comportament în situații de margine.
De aceea migrația între modele poate fi mai asemănătoare cu migrația unui întreg component de business decât cu simpla înlocuire a unui URL.
Cinci niveluri de AI Vendor Lock-in
Merită să privim vendor lock-in mai larg.
1. Lock-in al modelului
Cel mai simplu nivel.
Aplicația a fost optimizată pentru un model anume.
Promptul funcționează excelent cu un model, dar mai prost cu altul.
Sistemul se bazează pe capabilități specifice modelului respectiv.
Schimbarea implică retragerea fină a parametrilor.
2. Lock-in API
Sistemul folosește direct funcții ale unui anumit furnizor.
Cu cât folosim mai multe funcții specifice, cu atât migrația poate fi mai dificilă.
Nu e vorba doar de generarea de text.
Contează și:
- structured outputs,
- function calling,
- tool calling,
- multimodalitate,
- gestionarea contextului,
- mecanisme de securitate,
- sisteme de agenți.
3. Lock-in al datelor
Datele pot fi stocate într-un mod strâns legat de un anumit ecosistem.
Asta include:
- embeddings,
- indici vectoriali,
- metadate,
- istoricul interacțiunilor,
- configurații RAG.
Migrația poate necesita nu doar mutarea datelor, ci și reprocesarea lor.
4. Lock-in al arhitecturii
Acesta este un nivel mult mai serios.
Întreaga aplicație a fost proiectată în jurul unui furnizor.
Mecanismele lui sunt prezente în multe locuri ale sistemului.
În acest caz nu înlocuim doar un component.
Refacem o parte din arhitectură.
5. Lock-in organizațional
Acesta este adesea cel mai subestimat problem.
Echipa cunoaște un singur ecosistem.
Toate competențele se concentrează în jurul unei singure soluții.
Documentația, procedurile, testele și know-how-ul sunt legate de un furnizor.
Chiar dacă tehnic e posibil să schimbăm modelul, organizația nu are oameni care să facă aceste schimbări.
Atunci vendor lock-in nu mai este doar o problemă tehnică.
Devine o problemă de business.
Rezolvă Multi-Model problema?
Răspunsul natural: "Dacă un furnizor e risc, folosește mai mulți."
Dar nu e întotdeauna cea mai bună strategie.
Arhitectura multi-model are costurile ei.
Trebuie să gestionăm:
- mai multe API-uri,
- limite diferite,
- modele de preț diferite,
- niveluri diferite de calitate,
- formate de răspuns variate,
- teste,
- monitorizare,
- securitate.
Sistemul devine mai complex.
De aceea obiectivul nu ar trebui să fie: "Trebuie să folosim cinci furnizori."
Obiectivul ar trebui să fie: "Trebuie să avem posibilitatea de a schimba furnizorul dacă business-ul va cere."
Aceasta este diferența esențială.
Nu fiecare companie are nevoie de Multi-Model.
Dar fiecare ar trebui să știe cum ar arăta migrația către alt model.
AI Gateway și Model Gateway - stratul care separă aplicația de furnizor
Un mod de a limita dependența este introducerea unui strat intermediar.
Acesta poate funcționa ca un AI Gateway sau Model Gateway.
Schița arhitecturii ar putea arăta astfel:
Aplicație business
↓
Strat de abstractizare AI
↓
Routing modele
↓
Adaptor furnizor
↓
OpenAI / Anthropic / Google / model open-weight / model local
Astfel logica business nu trebuie să cunoască direct detaliile fiecărui furnizor.
Putem avea un strat responsabil pentru:
- selectarea modelului,
- routing,
- fallback,
- control costuri,
- monitoring,
- logare,
- politici de securitate,
- gestionarea limitelor.
La căderea unui furnizor sistemul poate încerca un alt model.
La creșterea prețurilor putem schimba routing-ul.
La apariția unui model mai bun putem rula teste și decide migrația.
Nu înseamnă că schimbarea va fi întotdeauna fără durere.
Înseamnă însă că schimbarea a fost proiectată ca o posibilitate reală.
Model Router - AI nu trebuie să aleagă mereu același model
O soluție și mai interesantă este routing-ul modelelor.
Imaginați-vă un sistem care primește sarcini diferite.
Sarcină simplă: "Rezumați acest text."
Poate fi trimisă către un model rapid și ieftin.
Sarcină mai complexă: "Analizează documentul și pregătește o recomandare detaliată."
Poate merge către un model mai puternic.
O sarcină care necesită analiză de imagine poate merge către un model multimodal.
Sistemul poate selecta dinamic modelul potrivit pentru fiecare task.
Asta optimizează:
- costurile,
- calitatea,
- timpul de răspuns,
- disponibilitatea.
În această abordare furnizorul AI încetează să fie o parte integrantă a logicii de business.
Devine un element al infrastructurii.
Și aceasta este o schimbare arhitecturală importantă.
Abstracția nu înseamnă că toate modelele sunt la fel
Aici trebuie atenție la o capcană.
Poți crea propria funcție: generateText() și crede că problema e rezolvată.
Nu e rezolvată.
Modelele nu sunt blocuri LEGO interschimbabile.
Dacă aplicația folosește capabilități specifice unui model, o abstracție simplă poate doar ascunde problema.
O arhitectură bună ar trebui să abstractizeze furnizorul, dar în același timp să gestioneze conștient diferențele între modele.
Practic asta înseamnă că stratul AI ar trebui să știe că un model poate avea diferite:
- capabilități,
- limite,
- costuri,
- niveluri de calitate,
- funcții,
- contexturi,
- parametri.
Deci proiectarea provider-agnostic nu trebuie să însemne a pretinde că toate modelele sunt identice.
Trebuie să însemne că sistemul folosește conștient diferențele între modele.
Evals - fără ele migrația AI este o ghicire
Unul dintre cele mai importante elemente ale unei arhitecturi rezistente la schimbare sunt evals, adică teste sistematice ale calității modelelor.
Să presupunem că avem 1000 de cazuri reale de utilizare. Le rulăm pe modelul curent. Apoi le rulăm pe cel nou. Comparăm rezultatele.
Verificăm:
- calitatea,
- corectitudinea,
- completitudinea,
- halucinațiile,
- conformitatea cu cerințele,
- timpul de răspuns,
- costul.
Abia atunci putem spune: "Modelul nou este suficient de bun."
Fără evals migrația poate părea un experiment. Cu evals devine un proces inginerești.
De aceea o companie care folosește AI ar trebui să construiască propriile seturi de teste. Să testeze nu doar API-ul, ci cazul lor de business. Aceasta e o diferență majoră.
Promptul poate fi și el sursă de vendor lock-in
Prompturile le tratăm adesea ca texte. În practică pot deveni parte din logica de business.
Dacă timp de luni de zile echipa optimizează instrucțiuni pentru un model anume, promptul poate începe să funcționeze ca un fragment de cod.
Așadar promptul ar trebui să fie:
- versionat,
- testat,
- documentat,
- monitorizat.
E util să știm care prompturi sunt critice pentru funcționarea sistemului. Dacă schimbarea modelului le degradează, trebuie să știm unde să căutăm problema.
De aceea prompt engineering în sisteme mature ar trebui tratat tot mai mult ca element al ingineriei software.
Open-weight și modelele proprii - fuga de vendor lock-in?
Modelele open-weight și posibilitatea de a rula modele în propria infrastructură cresc controlul asupra tehnologiei.
Dar nu înseamnă automat independență totală.
Dacă mutăm modelul în infrastructura proprie avem în continuare nevoie de:
- GPU,
- infrastructură,
- MLOps,
- monitoring,
- securitate,
- actualizări,
- competențe.
Putem astfel diminua dependența de furnizorul modelului, dar creștem dependența de furnizorul infrastructurii. Putem folosi și cloud pentru a rula modele open-weight. Atunci problema se mută la un alt nivel. De aceea e util să privim independența tehnologică mai larg.
Nu există un sistem complet lipsit de dependențe.
Există însă un sistem în care dependențele sunt:
- cunoscute,
- controlate,
- măsurabile,
- înlocuibile posibil.
Cea mai periculoasă formă de vendor lock-in poate fi în mintea echipei
Imaginați-vă o companie care folosește un singur furnizor AI.
Tehnic poate schimba modelul. Dar nimeni din companie nu știe cum să o facă.
Echipa nu cunoaște alternativele.
Nu există benchmark-uri, nu există evals, nu există teste, nu există experiență cu alte modele.
Toate soluțiile au fost construite în jurul unui singur ecosistem.
Aceasta este dependența organizațională.
De aceea reziliența la vendor lock-in cere și investiții în competențe.
Echipa ar trebui să înțeleagă:
- cum funcționează modelele,
- care sunt diferențele între furnizori,
- cum să construiească stratul de abstractizare,
- cum să testeze modelele,
- cum să măsoare calitatea,
- cum să gestioneze costurile,
- cum să orchestreze o migrație.
Nu e nevoie ca fiecare programator să știe fiecare API.
Ci ca organizația să nu fie orbește legată de un singur ecosistem.
Când vendor lock-in poate fi acceptabil?
Vendor lock-in nu e întotdeauna rău.
Uneori o dependență conștientă este o decizie de business rațională.
Dacă:
- furnizorul oferă o funcție excepțională,
- soluția reduce mult timpul de lansare,
- costul migrației este cunoscut,
- riscul este acceptabil,
- alternativele sunt slabe,
- business-ul are nevoie de viteză,
atunci o legătură mai strânsă cu un furnizor poate fi justificată.
Problema nu e lock-in-ul în sine. Problema e lock-in-ul inconștient.
Compania ar trebui să știe:
- de ce depinde,
- de ce e dependentă,
- cât ar costa schimbarea,
- cât ar dura migrația,
- care sunt alternativele.
Abia atunci poate fi considerată o decizie arhitecturală conștientă.
Cum să evaluezi AI Vendor Lock-in în compania ta?
Merită făcut un audit simplu.
Să ne punem întrebări:
Putem schimba modelul fără a reconstrui întreaga aplicație?
Este logica de business independentă de furnizorul AI?
Prompturile sunt versionate?
Avem evals proprii?
Avem teste de regresie pentru cele mai importante cazuri de utilizare?
Putem exporta și migra datele?
Putem schimba furnizorul embeddings fără pierdere de date?
Agenții folosesc un strat de orchestrare sau sunt legați direct de un ecosistem?
Avem posibilitatea de a folosi un model alternativ?
Avem fallback?
Știm cât ar costa migrația?
Știm cât ar dura migrația?
Avem oameni care pot realiza migrația?
Cu cât mai multe răspunsuri "nu", cu atât mai mare e dependența.
Se poate de asemenea crea un AI Portability Score intern. De exemplu evaluând organizația în cinci arii:
Arhitectură - este furnizorul înlocuibil?
Date - le putem muta?
Modele - avem alternative?
Evalue - putem compara modele?
Competențe - echipa poate conduce migrația?
Un astfel de scor nu trebuie să devină un standard formal. Poate fi însă un instrument managerial foarte util.
Pentru că uneori cea mai mare problemă nu e vendor lock-in. Cea mai mare problemă e că compania nu știe că îl are.
Cum să proiectezi o arhitectură AI rezistentă la schimbări?
Nu există o arhitectură universală. Totuși poți urma câteva principii practice.
Principiul 1 - separă logica business de furnizorul AI
Nu construi întregul sistem direct în jurul unui singur API.
Principiul 2 - folosește strat de abstractizare acolo unde are sens
AI Gateway sau Model Gateway pot reduce dependența aplicației de un furnizor specific.
Principiul 3 - versionează prompturile
Tratează-le ca parte din sistem, nu ca texte libere.
Principiul 4 - construiește evals
Nu presupune că "modelul nou funcționează".
Verifică asta.
Principiul 5 - testează alternative
Nu trebuie să le folosești în producție. Merită însă să știi cum se descurcă pe cazurile tale de utilizare.
Principiul 6 - controlează datele
Nu lăsa datele de business să devină ostatici ai unei singure platforme.
Principiul 7 - documentează dependențele
Cunoașterea locurilor în care sistemul e legat de un furnizor este parte din documentația arhitecturală.
Principiul 8 - nu abstractiza forțat
Nu ascunde diferențele între modele doar ca să obții o aparentă portabilitate.
Principiul 9 - măsoară costul migrației
Nu e suficient să spui:
"Vom schimba furnizorul cândva."
Trebuie să știi:
"Avem nevoie de trei luni și cinci persoane."
Sau:
"Nu putem face asta fără a reconstrui sistemul."
Principiul 10 - ia decizii conștiente
Uneori cea mai bună soluție este o legătură puternică cu un singur furnizor.
Dar aceasta trebuie să fie un risc conștient.
Nu un accident.
Întrebarea pe care orice CTO ar trebui să o pună
Imaginați-vă că mâine furnizorul AI:
- își dublează prețurile,
- retrag modelul pe care îl folosim,
- schimbă limitele,
- restricționează o funcție de care depinde produsul nostru,
- încetează să îndeplinească cerințele noastre de compliance.
Ce facem?
Dacă răspunsul este: "Schimbăm furnizorul."
întrebarea următoare trebuie să fie: "Cât timp ne ia asta?"
O zi?
O săptămână?
O lună?
Jumătate de an?
Sau poate nu știm?
Aceasta e măsura rezilienței noastre tehnologice.
Concluzie - nu e vorba să nu folosești niciun furnizor
Construirea unui sistem complet independent de furnizorii externi de AI poate fi neprofitabilă, inutilă sau chiar imposibilă.
Nu despre asta e vorba.
Scopul nu e lipsa dependențelor. Scopul este gestionarea conștientă a dependențelor.
Putem folosi OpenAI. Putem folosi Anthropic. Putem folosi Google. Putem folosi modele open-weight. Putem combina diverse soluții.
Cel mai important este să știi unde trece granița dintre: "folosim tehnologia" și "suntem dependenți de ea".
În lumea AI această graniță poate fi deosebit de greu de observat. Pentru că vendor lock-in nu apare într-o zi. Se dezvoltă treptat. Mai întâi integrăm API-ul. Apoi construim o funcție. Apoi adăugăm RAG. Apoi agenți. Apoi automatizăm procesul. Apoi întreaga echipă începe să lucreze după acel sistem. Și brusc schimbarea modelului nu mai e doar o schimbare de model - e o schimbare a unei părți a organizației.
De aceea arhitectura AI trebuie proiectată având în vedere nu doar ce funcționează azi, ci și ce se întâmplă dacă lumea tehnologiei se schimbă mâine.
Nu trebuie să construiești un sistem care funcționează fără OpenAI, Anthropic sau Google. Trebuie însă să construiești un sistem care poate funcționa și când unul dintre ei lipsește.
Aceasta este diferența între a folosi AI și a proiecta conștient tehnologia AI.
