AI mělo firmám přinést konkurenční výhodu. Může ale také vytvořit novou závislost
Ještě před několika lety se diskuse o vendor lock-in týkala především cloudu, ERP systémů, databází nebo klíčových technologických platforem.
Firmy si kladly otázky: Můžeme přenést aplikaci k jinému cloud provideru?, Můžeme změnit databázi?, Může naše organizace odejít od konkrétního systému?
Dnes se k tomuto seznamu přidává další prvek - umělá inteligence.
Organizace stále častěji budují systémy využívající jazykové modely, generativní AI, řešení RAG, automatizaci procesů a AI agenty. Modely se stávají součástí aplikací, prodejních procesů, zákaznické podpory, analýzy dokumentů, rozhodovacích systémů a každodenní práce týmů.
V praxi to znamená, že firma může začít být závislá nejen na konkrétním softwaru, ale také na konkrétním dodavateli inteligence, kterou její systémy využívají.
A tady je problém. Protože něco jiného je využívat službu AI, a něco jiného je být na ní závislý.
To je právě rozdíl mezi vědomou technologickou závislostí a vendor lock-in.
Co vlastně znamená AI Vendor Lock-in?
Vendor lock-in znamená situaci, kdy je organizace natolik spjatá s jedním dodavatelem technologie, že přechod na konkurenční řešení je obtížný, nákladný, časově náročný nebo rizikový.
Ve světě AI může mít lock-in mnohem více podob než klasická závislost jen na jednom API.
Firma může být závislá na:
- konkrétním AI modelu,
- konkrétním poskytovateli API,
- specifickém formátu komunikace,
- funkcích dostupných pouze u jednoho dodavatele,
- agentovém systému,
- cloudové infrastruktuře,
- způsobu ukládání dat,
- konkrétním mechanismu embeddingů,
- určitém RAG systému,
- způsobu volání nástrojů agenty,
- promptech optimalizovaných pro konkrétní model,
- kompetencích týmu vázaných na jeden ekosystém.
Proto otázka: „Používáme OpenAI?“
je rozhodně příliš jednoduchá.
Lepší otázka je: „Jak obtížné by pro nás bylo změnit dodavatele AI, kdybychom to museli udělat za šest měsíců?“
Pokud je odpověď: „Nevíme.“ - může to být první varovný signál.
OpenAI, Anthropic, Google - má volba dodavatele význam?
Na trhu dnes funguje několik velmi silných ekosystémů modelů a AI služeb, mezi nimi řešení nabízená OpenAI, Anthropic a Google.
Každý z těchto dodavatelů vyvíjí vlastní modely, API, nástroje a doplňkové služby.
Problém není v tom, že by některý z nich byl „špatný“. Naopak.
Využití hotových, kvalitních modelů je často nejlepší byznysovou volbou. Ne každá firma by měla trénovat vlastní model. Ne každá potřebuje vlastní GPU infrastrukturu. Ne každá by měla budovat celý AI stack od nuly.
Použití externího dodavatele umožňuje rychlejší vstup na trh, snížení počátečních nákladů a využití technologie, jejíž vlastní vývoj by byl mimo dosah většiny organizací.
Problém nastává, když firma přestane považovat dodavatele za zaměnitelnou součást a začne navrhovat celý produkt, jako by vybraný dodavatel zůstal v nezměněné podobě příštích 10 let.
A to nelze zaručit...
Modely se aktualizují, starší verze se vyřazují, ceny se mění, limity se mění, API se mění, objevují se nové modely, mění se licenční podmínky, mění se konkurenční možnosti.
To je normální součást technologického trhu.
Proto by AI architektura měla zohlednit nejen otázku: „Který model je dnes nejlepší?“
ale také: „Jakou cenu zaplatíme, pokud za rok budeme chtít používat jiný?“
Největší past - „přece jen API vyměníme“
Na první pohled se migrace může zdát triviální.
Máme aplikaci. Aplikace posílá dotaz modelu. Model odpoví. Změníme dodavatele. Hotovo...
Ve skutečnosti to může vypadat úplně jinak.
Představme si aplikaci, která byla dva roky vyvíjena kolem jednoho modelu.
Během té doby tým:
- vytvořil stovky promptů,
- optimalizoval jejich obsah,
- přizpůsobil formát odpovědí,
- postavil RAG systém,
- nastavil tool calling,
- vytvořil agenty,
- navrhl workflow,
- připravil testy,
- zaškolil uživatele.
Po dvou letech se ukáže, že model již není dostupný ve stejné verzi.
Nebo jeho cena roste, nebo konkurenční model je výrazně lepší, nebo firma chce část dat přesunout do jiného prostředí.
Teoreticky stačí změnit API - prakticky se může ukázat, že je třeba znovu otestovat celou logiku systému.
Proč?
Protože modely nejsou identické:
- Liší se ve způsobu interpretace instrukcí.
- Liší se kvalitou odpovědí.
- Liší se chováním v dlouhém kontextu.
- Liší se způsobem využívání nástrojů.
- Liší se podporou strukturovaného výstupu.
- Liší se multimodalitou.
- Liší se rychlostí.
- Liší se cenou.
- Liší se také chováním v hraničních situacích.
Proto může být migrace mezi modely více podobná migraci celého byznysového komponentu než pouhé výměně URL.
Pět úrovní AI Vendor Lock-in
Stojí za to podívat se na lock-in šířeji.
1. Lock-in modelu
Nejjednodušší úroveň.
Aplikace byla optimalizovaná pro konkrétní model.
Prompt funguje skvěle s jedním modelem, ale hůře s jiným.
Systém se opírá o specifické schopnosti daného modelu.
Změna znamená nutnost opětovného doladění.
2. Lock-in API
Systém využívá přímo funkce konkrétního poskytovatele.
Čím více specifických funkcí používáme, tím těžší může být migrace.
Nejde jen o generování textu.
Důležité jsou také:
- structured outputs,
- function calling,
- tool calling,
- multimodalita,
- správa kontextu,
- bezpečnostní mechanismy,
- agentové systémy.
3. Lock-in dat
Data mohou být uložena způsobem silně vázaným na konkrétní ekosystém.
To se týká také:
- embeddingů,
- vektorových indexů,
- metadat,
- historie interakcí,
- konfigurace RAG.
Migrace může vyžadovat nejen přenos dat, ale i jejich znovuzpracování.
4. Lock-in architektury
To je mnohem vážnější úroveň.
Celá aplikace byla navržena kolem jednoho dodavatele.
Jeho mechanismy jsou přítomné v mnoha částech systému.
V takovém případě nevyměňujeme jen jeden komponent.
Přestavujeme část architektury.
5. Lock-in organizační
To je často nejvíce podceňovaný problém.
Tým zná jen jeden ekosystém.
Veškeré kompetence se soustředí kolem jednoho řešení.
Dokumentace, procedury, testy a know‑how jsou svázané s jedním dodavatelem.
I když technicky lze model změnit, organizace nemá lidi, kteří by takovou změnu provedli.
A pak vendor lock-in přestává být pouze technologickým problémem.
Stává se obchodním problémem.
Vyřeší problém Multi-Model?
Přirozenou odpovědí bývá: „Jelikož jeden dodavatel je riziko, použijme několik.“
To ale není vždy nejlepší strategie.
Více-modelová architektura má své náklady.
Je třeba řídit:
- mnoho API,
- různé limity,
- různé cenové modely,
- různou kvalitu,
- různé formáty odpovědí,
- testy,
- monitoring,
- bezpečnost.
Systém se stává složitějším.
Cílem tedy nemusí být: „Musíme používat pět dodavatelů.“
Cílem by mělo být: „Musíme mít možnost změnit dodavatele, pokud to bude byznys vyžadovat.“
To je zásadní rozdíl.
Ne každá firma potřebuje multi-model.
Každá firma by ale měla vědět, jak by vypadala migrace na jiný model.
AI Gateway a Model Gateway - vrstva oddělující aplikaci od dodavatele
Jedním ze způsobů, jak omezit závislost, je použití mezivrstvy.
Ta může sloužit jako AI Gateway nebo Model Gateway.
Zjednodušeně může architektura vypadat takto:
Byznysová aplikace
↓
Vrstva abstrakce AI
↓
Routing modelů
↓
Adapter dodavatele
↓
OpenAI / Anthropic / Google / open-weight model / lokální model
Díky tomu by byznysová logika aplikace nemusela znát detaily každého dodavatele.
Můžeme mít vlastní vrstvu odpovědnou za:
- výběr modelu,
- routing,
- fallback,
- kontrolu nákladů,
- monitoring,
- logování,
- bezpečnostní politiky,
- správu limitů.
V případě výpadku jednoho dodavatele může systém zkusit použít jiný model.
Při růstu cen můžeme změnit routing.
Při objevení lepšího modelu lze provést testy a rozhodnout o migraci.
To neznamená, že změna bude vždy bezbolestná.
Znamená to však, že byla navržena jako reálná možnost.
Model Router - AI nemusí vždy vybírat ten samý model
Ještě zajímavějším řešením je routing modelů.
Představme si systém, který dostává různorodé úkoly.
Jednoduchý úkol: „Shrň tento text.“
Může být poslán do rychlého a levného modelu.
Složitější úkol: „Analyzuj dokument a připrav detailní doporučení.“
Může být předán silnějšímu modelu.
Úkol zahrnující analýzu obrázku může jít do multimodálního modelu.
Systém tedy může dynamicky vybírat model pro konkrétní úlohu.
To umožňuje optimalizovat:
- náklady,
- kvalitu,
- doba odpovědi,
- dostupnost.
V takovém přístupu se dodavatel AI přestává stát integrální součástí byznysové logiky.
Stává se jedním z prvků infrastruktury.
A to je velmi důležitá architektonická změna.
Abstrakce neznamená, že všechny modely jsou stejné
Zde je třeba dát pozor na jednu past.
Můžete vytvořit vlastní funkci: generateText() a předpokládat, že problém je vyřešen.
Není.
Modely nejsou zaměnitelné LEGO kostičky.
Pokud aplikace využívá specifické schopnosti modelu, jednoduchá abstrakce problém jen skryje.
Dobrá architektura by tedy měla abstraktovat od dodavatele, ale současně vědomě řídit rozdíly mezi modely.
V praxi to znamená, že AI vrstva by měla vědět, že model může mít různé:
- schopnosti,
- limity,
- náklady,
- úrovně kvality,
- funkce,
- kontexty,
- parametry.
Proto „provider-agnostic“ design by neměl předstírat, že každý model je stejný.
Měl by znamenat, že systém umí vědomě využívat rozdíly mezi modely.
Evals - bez nich je migrace AI hádáním
Jedním z nejdůležitějších prvků architektury odolné vůči změnám jsou evals, tedy systematické testy kvality chování modelů.
Předpokládejme, že máme 1000 reálných případů použití. Spustíme je na současném modelu. Pak je spustíme na novém. Porovnáme výsledky.
Kontrolujeme:
- kvalitu,
- správnost,
- úplnost,
- halucinace,
- shodu s požadavky,
- doba odpovědi,
- náklady.
Až pak můžeme říct: „Nový model je dostatečně dobrý.“
Bez evals může migrace vypadat jako experiment. S evals se z ní stává inženýrský proces.
Proto by firma využívající AI měla budovat vlastní testovací sady. Nejen testovat API. Testovat vlastní byznysový případ. To je zásadní rozdíl.
Prompt může být také zdrojem vendor lock-in
Prompt často vnímáme jako prostý text. Ve skutečnosti se může stát součástí byznysové logiky.
Pokud tým měsíce optimalizuje instrukce pro konkrétní model, prompt může začít fungovat jako kus kódu.
Měl by být:
- verzionovaný,
- testovaný,
- dokumentovaný,
- monitorovaný.
Je dobré vědět, které prompty jsou kritické pro fungování systému. Pokud změna modelu zhorší jejich účinnost, musíme vědět, kde hledat problém.
Proto by v dozrálých AI systémech měl být prompt engineering více považován za součást softwarového inženýrství.
Open-weight a vlastní modely - únik od vendor lock-in?
Open-weight modely a možnost provozovat modely ve vlastní infrastruktuře zvyšují kontrolu nad technologií.
Neznamená to však automaticky plnou nezávislost.
Pokud přesuneme model do vlastní infrastruktury, stále potřebujeme:
- GPU,
- infrastrukturu,
- MLOps,
- monitoring,
- bezpečnost,
- aktualizace,
- kompetence.
Můžeme tak omezit závislost na dodavateli modelu, ale zvýšit závislost na dodavateli infrastruktury. Můžeme také provozovat open-weight modely v cloudu. V tom případě se problém částečně přesune na jinou úroveň. Proto je třeba se na technologickou nezávislost dívat šířeji.
Neexistuje systém zcela bez závislostí.
Existuje ale systém, ve kterém jsou závislosti:
- známé,
- kontrolované,
- měřitelné,
- nahraditelné.
Nejhorší vendor lock-in může být v hlavách týmu
Představme si firmu, která používá jediného dodavatele AI.
Technicky může model změnit. Ale nikdo ve firmě neví, jak na to.
Tým nezná alternativy.
Neexistují benchmarky.
Nejsou evals.
Nejsou testy.
Chybí zkušenosti s jinými modely.
Všechny řešení byly postavené kolem jednoho ekosystému.
To je organizační lock-in.
Proto odolnost vůči vendor lock-in vyžaduje také investice do kompetencí.
Tým by měl rozumět:
- jak modely fungují,
- jaké jsou rozdíly mezi dodavateli,
- jak budovat vrstvu abstrakce,
- jak testovat modely,
- jak měřit kvalitu,
- jak řídit náklady,
- jak provést migraci.
Nejde o to, aby každý vývojář znal každé API.
Jde o to, aby organizace nebyla technologicky slepá vůči jednomu ekosystému.
Kdy může být vendor lock-in přijatelný?
Vendor lock-in není vždy špatný.
Někdy je vědomá závislost rozumným obchodním rozhodnutím.
Pokud:
- dodavatel nabízí výjimečnou funkci,
- řešení výrazně zkracuje čas zavedení,
- náklady na migraci jsou známy,
- riziko je akceptovatelné,
- alternativy jsou slabší,
- byznys potřebuje rychlost,
může být silnější svázání s jedním dodavatelem odůvodněné.
Problémem není samotný lock-in. Problémem je neuvědomělý lock-in.
Firma by měla vědět:
- na čem je závislá,
- proč je závislá,
- kolik by změna stála,
- jak dlouho by migrace trvala,
- jaké jsou alternativy.
Až pak lze hovořit o vědomém architektonickém rozhodnutí.
Jak posoudit AI Vendor Lock-in ve vaší firmě?
Vyplatí se udělat jednoduchý audit.
Zeptejte se:
Můžeme změnit model bez přestavby celé aplikace?
Je byznysová logika nezávislá na dodavateli AI?
Jsou prompty verzionované?
Máme vlastní evals?
Máme regresní testy pro klíčové případy použití?
Můžeme data exportovat a přenést?
Můžeme změnit poskytovatele embeddingů bez ztráty dat?
Používají agenti orchestraci, nebo jsou vázaní přímo na ekosystém?
Můžeme použít alternativní model?
Máme fallback?
Víme, kolik by migrace stála?
Víme, jak dlouho by migrace trvala?
Máme lidi, kteří ji dokážou provést?
Čím více odpovědí „ne“, tím větší závislost.
Můžete také vytvořit vlastní AI Portability Score. Například hodnotit organizaci v pěti oblastech:
Architektura - je dodavatel vyměnitelný?
Data - můžeme je přenést?
Modely - máme alternativy?
Evaluace - umíme porovnat modely?
Kompetence - dokáže tým provést migraci?
Takové skóre nemusí být formálním standardem. Může být ale velmi užitečným manažerským nástrojem.
Protože někdy největší problém není vendor lock-in. Největší problém je, že firma neví, že ho má.
Jak navrhovat AI architekturu odolnou vůči změnám?
Neexistuje univerzální architektura. Lze ale přijmout několik praktických zásad.
Zásada 1 - oddělte byznysovou logiku od dodavatele AI
Nestavte celý systém přímo kolem jednoho API.
Zásada 2 - použijte abstrakční vrstvu tam, kde to dává smysl
AI Gateway nebo Model Gateway může omezit závislost aplikace na konkrétním dodavateli.
Zásada 3 - verzionujte prompty
Zacházejte s nimi jako s částí systému, ne jen jako s volným textem.
Zásada 4 - budujte evals
Nedomnívejte se, že „nový model funguje“.
Ověřte to.
Zásada 5 - testujte alternativy
Nemusíte je používat v produkci.
Stojí ale za to vědět, jak si poradí s vašimi případy použití.
Zásada 6 - kontrolujte data
Nedovolte, aby se vaše byznysová data stala rukojmím jedné platformy.
Zásada 7 - dokumentujte závislosti
Vědět, kde je systém vázaný na konkrétního dodavatele, patří do architektonické dokumentace.
Zásada 8 - neabstrahujte násilně
Nezakrývejte rozdíly mezi modely jen proto, abyste získali zdánlivou přenositelnost.
Zásada 9 - měřte náklady migrace
Ne stačí říct:
„Někdy můžeme změnit dodavatele.“
Je třeba vědět:
„Potřebujeme na to tři měsíce a pět lidí.“
Nebo:
„Nedokážeme to udělat bez přestavby systému.“
Zásada 10 - dělejte rozhodnutí vědomě
Někdy je nejlepší řešení pevné svázání s jedním dodavatelem.
Mělo by to ale být vědomé riziko.
Ne náhoda.
Otázka, kterou by měl každý CTO položit
Představme si, že zítra dodavatel AI:
- zdvojnásobí ceny,
- vypne model, který používáme,
- změní limity,
- omezí funkci, na které závisí náš produkt,
- přestane splňovat naše compliance požadavky.
Co děláme?
Pokud odpověď je: „Změníme dodavatele.“
další otázka by měla znít: „Jak dlouho nám to zabere?“
Den?
Týden?
Měsíc?
Půl roku?
Nebo to nevíme?
To je právě měřítko naší technologické odolnosti.
Souhrn - nejde o to, nebýt vázán na dodavatele
Vytvořit systém zcela nezávislý na externích AI dodavatelích může být nákladné, zbytečné nebo dokonce nemožné.
Ne o to jde.
Cílem není absence závislostí. Cílem je vědomé řízení závislostí.
Můžeme používat OpenAI. Můžeme používat Anthropic. Můžeme používat Google. Můžeme používat open-weight modely. Můžeme kombinovat různá řešení.
Nejdůležitější je vědět, kde leží hranice mezi: „používáme technologii“ a „jsme na ní závislí“.
Ve světě AI může být tato hranice obzvlášť těžko zpozorovatelná. Vendor lock-in nevzniká za jeden den. Vzniká postupně. Nejprve integrujeme API. Pak postavíme funkci. Pak přidáme RAG. Pak agenty. Pak automatizujeme proces. Pak celý tým začne pracovat podle tohoto systému. A najednou změna modelu už není změnou modelu - je změnou části organizace.
Proto by AI architektura měla být navrhována nejen s ohledem na to, co funguje dnes, ale také na to, co se stane, pokud se technologický svět změní zítra.
Nemusíte stavět systém, který funguje bez OpenAI, Anthropic nebo Google. Měli byste ale stavět systém, který dokáže fungovat i tehdy, když někoho z nich postrádá.
To je právě rozdíl mezi využíváním AI a vědomým navrhováním AI technologie.
