AI vendor lock-in — když model není jediná závislost

Lock-in není jen logo na modelu

U klasického SaaS se závislost na dodavateli často pozná podle dat, API a smlouvy. U AI je záludnější: model je viditelná část, ale závislost vzniká i v šablonách promptů, nástrojích, testovacích sadách, bezpečnostních výjimkách, interních schváleních a způsobu účtování. Firma si nemění jen dodavatele. Mění pracovní proces, který kolem modelu vyrostl.

Proto je slabé ptát se jen „který model je nejlepší“. Lepší otázka zní: co všechno se rozbije, když tenhle model, cloud nebo agentní platformu za půl roku vyměníme?

Kde se závislost lepí k systému

První vrstva je smluvní: závazek odběru cloudových služeb, podniková dohoda, regionální dostupnost a podmínky zpracování dat. Druhá vrstva je technická: podoba API, formáty volání nástrojů, embeddingy, výstupy dotrénování, izolované prostředí, logování a napojení na interní systémy. Třetí vrstva je provozní: kdo schvaluje změny, kdo platí tokeny, jak se měří kvalita a jak rychle tým umí incident zastavit.

Technická závislost není novinka výhradně generativní AI. Studie Hidden Technical Debt in Machine Learning Systems popisuje, jak vazby mezi daty, modely a okolním kódem prodražují údržbu celého systému. Na migraci dodavatele se tento problém snadno projeví.

Nejhůř se odhaduje závislost, která vypadá jako pohodlí. Jedno tlačítko, jeden dodavatel, jeden účet, jedna integrace. Krásné při pilotu. Drahé ve chvíli, kdy se změní cena, požadavky na soulad s pravidly nebo kvalita modelu.

Přenositelnost není zadarmo

Architektura s více modely zní lákavě, ale není kouzelná pojistka. Každý model má jiné limity, chování, ceny a způsoby selhání. Pokud aplikace jen přepíná endpoint, ale nemá testy kvality, rozhraní pro nástroje, testovací data a předem určený postup při chybě, je to spíš přepínač chaosu než strategie. Náhradní model se nesmí tiše použít pro data, která k němu podle pravidel nesmějí odejít.

Dobrá přenositelnost znamená vědomě oddělit části systému: mít exportovatelná doménová data, vlastní testy kvality, rozhraní nástrojů oddělené od konkrétního SDK a logy umožňující porovnání před změnou a po ní. Například MCP standardizuje propojení aplikací s nástroji a kontextem. Z toho ale neplyne, že různé modely provedou úlohu stejně dobře. Přenositelnost je potřeba prokázat zkouškou.

Co má hlídat nákup, vývoj i právník

Nákup sleduje cenu, závazky a možnost ukončení. Vývoj sleduje latenci, kvalitu, API, pozorovatelnost systému a práci s chybami. Právník a bezpečnostní tým sledují data, audit, jurisdikci, odpovědnost a relevantní omezení. U AI spolu tyhle pohledy souvisejí, protože změna ceny může změnit architekturu a změna architektury může změnit riziko.

Praktický test je jednoduchý: umíme vyjmenovat pět nejdražších míst, kde nás dnešní AI dodavatel drží? Pokud ne, lock-in už možná existuje, jen nemá jméno.

Jak stavět s únikovým východem

Začni malým seznamem zásad. Kritický pracovní postup má mít testovací sadu a auditní log. Citlivá data nemají zbytečně končit ve formátu závislém na dodavateli. Prompty, schémata nástrojů a postup vyhledávání podkladů mají být verzované jako kód. Rozhodnutí o modelu má mít datum další revize, ne náboženský status.

Únikový východ neznamená, že každý systém musí běžet na pěti modelech. Znamená, že víš, co by stálo odejít, co by se muselo přepsat a které úlohy jsou tak důležité, že si zaslouží druhou možnost. Lock-in není vždy špatný. Špatný je lock-in, o kterém se tým dozví až ve chvíli, kdy ho potřebuje opustit.

Příklad: zkušební přesun podpůrného asistenta

Vyber sadu schválených testovacích dotazů bez osobních údajů a spusť ji nad původním i náhradním řešením. Porovnej správnost odpovědí, citace, chybná volání nástrojů, cenu a dobu odezvy. Sečti také práci na exportu dokumentů a přestavbě vyhledávání. Pokud potřebuješ nové embeddingy, počítej s přepočtem indexu. Výsledkem má být seznam konkrétních závislostí a nákladů, nikoli samotná zelená odpověď API.

Zdroje

• Hidden Technical Debt in Machine Learning Systems — systémové závislosti a náklady údržby ML.
• MCP: Architecture overview — rozsah standardizace přístupu k nástrojům a kontextu.