AI malo firmám priniesť výhodu. Môže tiež vytvoriť novú závislosť
Ešte pred niekoľkými rokmi sa diskusia o vendor lock-in týkala predovšetkým cloudu, ERP systémov, databáz alebo kľúčových technologických platforiem.
Firmy si kládli otázky: Môžeme presunúť aplikáciu k inému cloud provideroVi?, Môžeme zmeniť databázu?, Môžeme opustiť konkrétny systém?
Dnes k tomuto zoznamu pribúda ďalší prvok – umelá inteligencia.
Organizácie čoraz častejšie budujú systémy využívajúce jazykové modely, generatívnu AI, RAG riešenia, automatizáciu procesov a AI agentov. Modely sa stávajú súčasťou aplikácií, predajných procesov, podpory zákazníkov, analýzy dokumentov, rozhodovacích systémov a každodennej práce tímov.
V praxi to znamená, že firma môže začať byť závislá nielen od konkrétneho softvéru, ale aj od konkrétneho poskytovateľa inteligencie, ktorú jej systémy používajú.
A tu vzniká problém. Pretože iné je využívať službu AI a iné je byť od nej závislý.
To je práve rozdiel medzi vedomou technologickou závislosťou a vendor lock-in.
Čo vlastne znamená AI Vendor Lock-in?
Vendor lock-in znamená situáciu, v ktorej je organizácia tak silno viazaná na jedného poskytovateľa technológií, že prechod na konkurenčné riešenie sa stáva ťažkým, drahým, časovo náročným alebo rizikovým.
Vo svete AI môže nadobúdať omnoho viac foriem než klasická závislosť od jedného API.
Firma môže byť závislá od:
- konkrétneho AI modelu,
- konkrétneho poskytovateľa API,
- určitého formátu komunikácie,
- funkcií dostupných výhradne u jedného poskytovateľa,
- agentového systému,
- cloudovej infraštruktúry,
- spôsobu ukladania dát,
- konkrétneho mechanizmu embeddingov,
- určitého systému RAG,
- spôsobu vyvolávania nástrojov agentmi,
- promptov optimalizovaných pre konkrétny model,
- kompetencií tímu sústredených v jednom ekosystéme.
Preto otázka: „Používame OpenAI?“
je rozhodne príliš jednoduchá.
Lepšia otázka znie: „Ako ťažká by pre nás bola zmena poskytovateľa AI, keby sme to museli urobiť za šesť mesiacov?“
Ak je odpoveď: „Nevieme.“ – môže to byť prvý varovný signál.
OpenAI, Anthropic, Google – záleží na tom, koho vyberieme?
Na trhu dnes funguje niekoľko veľmi silných ekosystémov modelov a AI služieb, medzi inými riešenia od OpenAI, Anthropic a Google.
Každý z týchto poskytovateľov vyvíja vlastné modely, API, nástroje a doplnkové služby.
Problém nie je v tom, že by niekto z nich bol „zlý“. Práve naopak.
Využívanie hotových, kvalitných modelov je často najlepším obchodným riešením. Nie každá firma by mala trénovať vlastný model. Nie každá potrebuje vlastnú GPU infraštruktúru. Nie každá by mala budovať celý AI stack od nuly.
Použitie externého poskytovateľa umožňuje rýchlejší vstup na trh, zníženie počiatočných nákladov a využitie technológie, ktorej vlastná tvorba by bola mimo dosahu väčšiny organizácií.
Problém nastáva, keď firma prestane považovať poskytovateľa za vymeniteľnú súčasť a začne navrhovať celý produkt tak, akoby vybraný poskytovateľ mal existovať v nezmenenej podobe ďalších 10 rokov.
A to sa nedá zaručiť...
Modely sa aktualizujú, staršie verzie sa vyraďujú, ceny sa menia, limity sa menia, API sa menia, objavujú sa nové modely, menia sa licenčné podmienky, menia sa možnosti konkurencie.
To je normálna súčasť technologického trhu.
Preto by AI architektúra mala brať do úvahy nielen otázku: „Ktorý model je dnes najlepší?“
ale aj: „Akú cenu zaplatíme, ak budeme o rok chcieť použiť iný?“
Najväčšia pasca – „veď len zmeníme API“
Na prvý pohľad migrácia môže vyzerať banálne.
Máme aplikáciu. Aplikácia pošle požiadavku modelu. Model odpovie. Zmeníme poskytovateľa. Hotovo...
V skutočnosti to však môže vyzerať úplne inak.
Predstavme si aplikáciu, ktorá bola dva roky vyvíjaná okolo jedného modelu.
Počas tej doby tím:
- vytvoril stovky promptov,
- optimalizoval ich obsah,
- prispôsobil formát odpovedí,
- postavil RAG systém,
- nakonfiguroval tool calling,
- vytvoril agentov,
- navrhol workflow,
- pripravil testy,
- naučil používateľov pracovať so systémom.
Po dvoch rokoch sa zistí, že model už nie je dostupný v doterajšej podobe.
Alebo jeho cena rastie, alebo konkurenčný model je výrazne lepší, alebo firma chce presunúť časť dát do iného prostredia.
Teoreticky stačí zmeniť API – v praxi sa môže ukázať, že treba znovu otestovať celú logiku systému.
Prečo?
Pretože modely nie sú identické:
- Rozdielne interpretujú inštrukcie.
- Rozdielne sú v kvalite odpovedí.
- Rozdielne sa správajú v dlhom kontexte.
- Rozdielne používajú nástroje.
- Rozdielne zvládajú structured output.
- Rozdielne sú v multimodalite.
- Rozdielne sú v rýchlosti.
- Rozdielne sú v cene.
- Rozdielne sú aj v správaní v okrajových situáciách.
Preto migrácia medzi modelmi môže byť viac podobná migrácii celého biznis komponentu než bežnej výmene URL.
Päť úrovní AI Vendor Lock-in
Stojí za to pozrieť sa na vendor lock-in širšie.
1. Lock-in modelu
Najjednoduchšia úroveň.
Aplikácia bola optimalizovaná pre konkrétny model.
Prompt funguje výborne s jedným modelom, ale horšie s iným.
Systém sa spolieha na špecifické schopnosti daného modelu.
Zmena znamená potrebu opätovného doladenia.
2. Lock-in API
Systém používa priamo funkcie konkrétneho poskytovateľa.
Čím viac špecifických funkcií využívame, tým ťažšia môže byť migrácia.
Nejde len o samotné generovanie textu.
Dôležité sú aj:
- structured outputs,
- function calling,
- tool calling,
- multimodalita,
- správa kontextu,
- bezpečnostné mechanizmy,
- agentové systémy.
3. Lock-in dát
Dáta môžu byť uložené spôsobom silno previazaným s konkrétnym ekosystémom.
To sa týka aj:
- embeddingov,
- vektorových indexov,
- metadát,
- histórie interakcií,
- konfigurácie RAG.
Migrácia môže vyžadovať nielen presun dát, ale aj ich opätovné spracovanie.
4. Lock-in architektúry
To je oveľa vážnejšia úroveň.
Celá aplikácia bola navrhnutá okolo jedného poskytovateľa.
Jeho mechanizmy sú prítomné v mnohých častiach systému.
V takom prípade nevymieňate jeden komponent.
Rekonštruujete časť architektúry.
5. Lock-in organizačný
To je často najviac podceňovaný problém.
Tím pozná jeden ekosystém.
Všetky kompetencie sú sústredené okolo jedného riešenia.
Dokumentácia, postupy, testy a know‑how sú viazané na jedného poskytovateľa.
Aj keď technicky je možné zmeniť model, organizácia nemá ľudí, ktorí by takú zmenu vedeli uskutočniť.
A vtedy vendor lock-in prestáva byť len technologickým problémom.
Stáva sa obchodným problémom.
Rieši problém Multi‑Model architektúra?
Prirodzenou odpoveďou býva: „Keď je jeden poskytovateľ riziko, používajme viac.“
To však nie vždy je najlepšia stratégia.
Multi‑modelová architektúra má svoje náklady.
Treba riadiť:
- viacero API,
- rôzne limity,
- rôzne cenové modely,
- rôzne úrovne kvality,
- rôzne formáty odpovedí,
- testovanie,
- monitoring,
- bezpečnosť.
Systém sa stáva zložitejším.
Preto cieľom by nemalo byť: „Musíme používať päť poskytovateľov.“
Cieľom by malo byť: „Musíme mať možnosť zmeniť poskytovateľa, ak to biznis bude potrebovať.“
To je zásadný rozdiel.
Nie každá firma potrebuje Multi‑Model.
Každá firma by však mala vedieť, ako by vyzerala migrácia na iný model.
AI Gateway a Model Gateway – vrstva, ktorá oddelí aplikáciu od poskytovateľa
Jedným zo spôsobov, ako obmedziť závislosť, je zaviesť medzivrstvu.
Môže plniť úlohu AI Gateway alebo Model Gateway.
Zjednodušene môže architektúra vyzerať takto:
Biznis aplikácia
↓
Vrstva abstrakcie AI
↓
Routing modelov
↓
Adapter poskytovateľa
↓
OpenAI / Anthropic / Google / model open‑weight / lokálny model
Vďaka tomu biznis logika aplikácie nemusí priamo poznať detaily každého poskytovateľa.
Môžeme mať vlastnú vrstvu zodpovednú za:
- výber modelu,
- routing,
- fallback,
- kontrolu nákladov,
- monitoring,
- logovanie,
- bezpečnostné politiky,
- správu limitov.
V prípade výpadku jedného poskytovateľa môže systém skúsiť použiť iný model.
V prípade zvýšenia cien môžeme zmeniť routing.
V prípade objavenia lepšieho modelu môžeme urobiť testy a rozhodnúť o migrácii.
To neznamená, že zmena bude vždy bezbolestná.
Znamená to však, že zmena bola navrhnutá ako reálna možnosť.
Model Router – AI nemusí vždy vyberať ten istý model
Ešte zaujímavejším riešením je routing modelov.
Predstavme si systém, ktorý dostáva rôzne úlohy.
Jednoduchá úloha: „Zhrň tento text.“
Môže byť odoslaná do rýchleho a lacného modelu.
Zložitejšia úloha: „Analyzuj dokument a priprav podrobnú odporúčanie.“
Môže ísť do výkonnejšieho modelu.
Úloha vyžadujúca analýzu obrazu môže byť smerovaná do multimodálneho modelu.
Systém tak dynamicky priraďuje model k úlohe.
To umožňuje optimalizovať:
- náklady,
- kvalitu,
- čas odozvy,
- dostupnosť.
V takom prístupe poskytovateľ AI prestáva byť integrálnou súčasťou biznis logiky.
Stáva sa jedným z prvkov infraštruktúry.
A to je veľmi dôležitá architektonická zmena.
Abstrakcia neznamená, že všetky modely sú rovnaké
Tu treba dávať pozor na jednu pascu.
Môžete vytvoriť vlastnú funkciu: generateText() a považovať problém za vyriešený.
Nie je.
Modely nie sú zameniteľné LEGO kocky.
Ak aplikácia využíva špecifické schopnosti daného modelu, jednoduchá abstrakcia môže problém len skryť.
Dobrá architektúra by mala abstraktovať od poskytovateľa, ale súčasne vedome riadiť rozdiely medzi modelmi.
V praxi to znamená, že AI vrstva by mala vedieť, že model môže mať rôzne:
- schopnosti,
- limity,
- náklady,
- úrovne kvality,
- funkcie,
- kontexty,
- parametre.
Preto navrhovanie „provider‑agnostic“ netreba chápať ako predstieranie, že každý model je rovnaký.
Ide o to, aby systém vedel vedome využívať rozdiely medzi modelmi.
Evals – bez nich je migrácia AI hádaním
Jedným z najdôležitejších prvkov architektúry odolnej voči zmene sú evals, teda systematické testy kvality fungovania modelov.
Predpokladajme, že máme 1000 reálnych prípadov použitia. Spustíme ich na súčasnom modeli. Potom spustíme na novom. Porovnáme výsledky.
Kontrolujeme:
- kvalitu,
- správnosť,
- kompletnosť,
- halucinácie,
- zhodnosť s požiadavkami,
- čas odozvy,
- náklad.
Až potom môžeme povedať: „Nový model je dostatočne dobrý.“
Bez evals môže migrácia pôsobiť ako experiment. S evals sa z nej stáva inžiniersky proces.
Preto firma používajúca AI by mala budovať vlastné testovacie sady. Nielen testovať API. Testovať vlastný biznis prípad. To je obrovský rozdiel.
Prompt môže byť tiež zdrojom vendor lock‑inu
Prompty často považujeme za obyčajný text. V praxi sa však môžu stať súčasťou biznis logiky.
Ak tím mesiace optimalizuje inštrukcie pre konkrétny model, prompt môže začať fungovať ako kus kódu.
Mali by byť preto:
- verzionované,
- testované,
- dokumentované,
- monitorované.
Stojí za to vedieť, ktoré prompty sú kritické pre fungovanie systému. Ak zmena modelu zhorší ich účinnosť, musíme vedieť, kde hľadať problém.
Preto by prompt engineering v zrelých AI systémoch mal byť čoraz viac považovaný za súčasť softvérového inžinierstva.
Open‑weight a vlastné modely – únik pred vendor lock‑inom?
Open‑weight modely a možnosť spúšťať modely v vlastnej infraštruktúre zvyšujú kontrolu nad technológiou.
Ale neznamená to automaticky úplnú nezávislosť.
Ak prenesieme model do vlastnej infraštruktúry, stále potrebujeme:
- GPU,
- infraštruktúru,
- MLOps,
- monitoring,
- bezpečnosť,
- aktualizácie,
- kompetencie.
Môžeme teda znížiť závislosť od poskytovateľa modelu, no zároveň zvýšiť závislosť od poskytovateľa infraštruktúry. Môžeme tiež používať cloud na spúšťanie open‑weight modelov – vtedy sa problém čiastočne presunie na inú úroveň. Preto sa oplatí pozerať na technologickú nezávislosť šíršie.
Neexistuje systém úplne bez závislostí.
Existuje však systém, v ktorom sú závislosti:
- známe,
- kontrolované,
- merateľné,
- vymeniteľné.
Najnebezpečnejší vendor lock‑in môže byť v hlavách tímu
Predstavme si firmu, ktorá používa jedného poskytovateľa AI.
Technicky môže zmeniť model. Ale nikto vo firme nevie, ako na to.
Tím nepozná alternatívy.
Nemá benchmarky.
Nemá evals.
Nemá testy.
Nemá skúsenosti s inými modelmi.
Všetky riešenia boli postavené okolo jedného ekosystému.
To je organizačný lock‑in.
Preto odolnosť voči vendor lock‑inu vyžaduje aj investície do kompetencií.
Tím by mal rozumieť:
- ako modely fungujú,
- aké sú rozdiely medzi poskytovateľmi,
- ako budovať vrstvu abstrakcie,
- ako testovať modely,
- ako merať kvalitu,
- ako riadiť náklady,
- ako realizovať migráciu.
Nejde o to, aby každý vývojár poznal každé API.
Ide o to, aby organizácia nebola technologicky oslepená len na jeden ekosystém.
Kedy môže byť vendor lock‑in prijateľný?
Vendor lock‑in nie je vždy zlý.
Niekedy je vedomá závislosť rozumným obchodným rozhodnutím.
Ak:
- poskytovateľ ponúka výnimočnú funkciu,
- riešenie výrazne skracuje čas nasadenia,
- náklady na migráciu sú známe,
- riziko je akceptovateľné,
- alternatívy sú slabšie,
- biznis potrebuje rýchlosť,
tak silné zviazanenie s jedným poskytovateľom môže byť ospravedlniteľné.
Problémom nie je samotný lock‑in. Problémom je nevedomý lock‑in.
Firma by mala vedieť:
- od čoho je závislá,
- prečo je závislá,
- koľko by stálo zmena,
- koľko by trvala migrácia,
- aké sú alternatívy.
Len potom možno hovoriť o vedomom architektonickom rozhodnutí.
Ako zhodnotiť AI Vendor Lock‑in vo vašej firme?
Stojí za to urobiť jednoduchý audit.
Položme si otázky:
Môžeme zmeniť model bez prestavby celej aplikácie?
Je biznis logika nezávislá od poskytovateľa AI?
Sú prompty verzionované?
Máme vlastné evals?
Máme regresné testy pre najdôležitejšie prípady použitia?
Môžeme exportovať a presunúť dáta?
Môžeme zmeniť poskytovateľa embeddingov bez straty dát?
Využívajú agenti vrstvu orchestrácie, alebo sú viazaní priamo na ekosystém?
Máme možnosť použiť alternatívny model?
Máme fallback?
Vieme, koľko by stálo presunutie?
Vieme, ako dlho by migrácia trvala?
Máme ľudí, ktorí ju dokážu realizovať?
Čím viac odpovedí „nie“, tým väčšia je závislosť.
Môžete si tiež vytvoriť vlastné AI Portability Score. Napríklad ohodnotiť organizáciu v piatich oblastiach:
Architektúra – je poskytovateľ vymeniteľný?
Dáta – môžeme ich presunúť?
Modely – máme alternatívy?
Evalvácia – vieme porovnať modely?
Kompetencie – vie tím vykonať migráciu?
Takéto skóre nemusí byť formálnym štandardom. Môže však byť vynikajúcim manažérskym nástrojom.
Lebo niekedy najväčší problém nie je vendor lock‑in. Najväčší problém je, že firma ani nevie, že ho má.
Ako navrhovať AI architektúru odolnú voči zmenám?
Neexistuje jedna univerzálna architektúra. Dá sa však prijať niekoľko praktických zásad.
Zásada 1 – oddelte biznis logiku od poskytovateľa AI
Nestavajte celý systém priamo okolo jedného API.
Zásada 2 – použite vrstvu abstrakcie tam, kde dáva zmysel
AI Gateway alebo Model Gateway môže obmedziť závislosť aplikácie od konkrétneho poskytovateľa.
Zásada 3 – verzionujte prompty
Zaobchádzajte s nimi ako s časťou systému, nie ako s voľným textom.
Zásada 4 – budujte evals
Nedomnievajte sa, že „nový model funguje“. Overte to.
Zásada 5 – testujte alternatívy
Nemusíte ich nasadiť do produkcie. Je však dobré vedieť, ako zvládajú vaše prípady použitia.
Zásada 6 – kontrolujte dáta
Nenechajte svoje obchodné dáta byť rukojemníkom jednej platformy.
Zásada 7 – dokumentujte závislosti
Vedomosť o tom, kde je systém viazaný na konkrétneho poskytovateľa, je súčasťou architektonickej dokumentácie.
Zásada 8 – neabstrahujte nasilu
Neskryte rozdiely medzi modelmi len preto, aby ste získali zdanie prenositeľnosti.
Zásada 9 – merajte náklady migrácie
Nestačí povedať:
„Niekedy môžeme zmeniť poskytovateľa.“
Treba vedieť:
„Potrebujeme na to tri mesiace a päť ľudí.“
Alebo:
„Nie sme schopní to urobiť bez prestavby systému.“
Zásada 10 – robte rozhodnutia vedome
Niekedy je najlepším riešením silné viazanie sa na jedného poskytovateľa.
Ale malo by to byť vedomé riziko.
Nie náhoda.
Otázka, ktorú by si mal položiť každý CTO
Predstavme si, že zajtra poskytovateľ AI:
- zdvihne ceny dvojnásobne,
- stiahne model, ktorý používame,
- zmení limity,
- obmedzí funkciu, od ktorej závisí náš produkt,
- prestane spĺňať naše compliance požiadavky.
Čo urobíme?
Ak odpoveď znie: „Zmeníme poskytovateľa.“
ďalšia otázka by mala byť: „Ako dlho nám to potrvá?“
Deň?
Týždeň?
Mesiac?
Pol roka?
Alebo to nevieme?
To je práve miera našej technologickej odolnosti.
Zhrnutie – nejde o to, aby ste nemali poskytovateľa
Stavať systém úplne nezávislý od externých AI poskytovateľov môže byť neefektívne, zbytočné alebo dokonca nemožné.
Nejde o to.
Cieľ nie je absencia závislostí. Cieľ je vedomé riadenie závislostí.
Môžeme využívať OpenAI. Môžeme využívať Anthropic. Môžeme využívať Google. Môžeme používať open‑weight modely. Môžeme kombinovať rôzne riešenia.
Najdôležitejšie je však vedieť, kde vedie hranica medzi: „používame technológiu“ a „sme od nej závislí“.
Vo svete AI môže byť táto hranica obzvlášť ťažko postrehnuteľná. Vendor lock‑in nevzniká za jeden deň. Vzniká postupne. Najprv integrujeme API. Potom budujeme funkciu. Potom pridáme RAG. Potom agentov. Potom automatizujeme proces. Potom celý tím začne pracovať podľa tohto systému. A zrazu sa ukáže, že zmena modelu už nie je len zmenou modelu – je to zmena časti organizácie.
Preto by AI architektúra mala byť navrhovaná s ohľadom nielen na to, čo funguje dnes, ale aj na to, čo sa stane, keď sa technologický svet zmení zajtra.
Nemusíte stavať systém, ktorý funguje bez OpenAI, Anthropic alebo Google. Mali by ste však stavať systém, ktorý vie fungovať aj vtedy, keď niektorého z nich nebude.
Práve to je rozdiel medzi využívaním AI a vedomým navrhovaním AI technológie.
