Starý model nikdo nepoužívá. Přesto ho nejde vypnout

Jeden provozní tým měl v evidenci zhruba tři tisíce aplikací a tušení, že velká část z nich už dávno nikomu neslouží. Chyběl seznam, kdo co volá. Tak sáhli po metodě, které se v žargonu provozních inženýrů říká scream test, test křikem: tisícovku aplikací prostě vypnuli a čekali, kdo se ozve. Nezakřičel nikdo. Nikdo si ničeho nevšiml a nikoho to nezajímalo.

Zní to jako úlevná historka a bývá tak i vyprávěná. Ve skutečnosti je to varování. Metoda funguje jen tehdy, když má pod sebou záchrannou síť - možnost vrátit službu zpět prakticky okamžitě a archiv dat pro případ, že se přihlásí opozdilec, třeba měsíční nebo kvartální dávková úloha. Bez té sítě je to hazard. A to, že roky nikdo ve firmě neví, co na čem závisí, není provozní detail. Je to příznak něčeho staršího.

Drahý totiž není ten starý model, který zabírá grafickou kartu a nejde vypnout. Drahé jsou dvě věci, které stojí za ním. Za prvé architektura, ve které jeho vypnutí znamená přepisování aplikací. Za druhé organizace, která nedokáže odpovědět na otázku, co se rozbije, až ho odpojíte. To první je problém kódu, to druhé problém evidence a odpovědnosti - a řešit se musí obojí, protože vyřešit jen jedno nestačí.

Správný životní cyklus modelu se nezačíná nasazením do provozu. Začíná návrhem rozhraní a zápisem do katalogu. Kdo řeší vyřazení až ve chvíli, kdy mu model ukusuje z rozpočtu na výpočetní výkon, prohrál o pár let dřív - u prvního přímého volání dodavatelovy knihovny, které nikdo nezapsal.

Pojmenování toho příznaku není nové. Už v roce 2015 popsala skupina inženýrů z Googlu v práci Hidden Technical Debt in Machine Learning Systems (Sculley a kol., konference NIPS 2015) jev, který sedí na popsaný problém jako klíč do zámku: undeclared consumers, nepřiznaní konzumenti. Výstup modelu bývá volně dostupný a časem se na něj nenápadně napojí další systém jako na svůj vstup - aniž o tom kdokoli vede záznam. Autoři to hodnotí bez obalu: takové vazby jsou v nejlepším případě drahé a v nejhorším nebezpečné, protože vytvářejí skryté těsné provázání. Model pak nejde bezpečně odebrat, protože jeho vazby nikdo nezdokumentoval.

U jazykových modelů se k tomu přidává účet za výpočetní výkon, který na rozdíl od zapomenuté virtuální mašiny nesvítí v přehledu nevyužitých instancí. Náklad na inferenci se schovává uvnitř volání API a nevytížená karta se hledá špatně. Model, který skoro nikdo nevolá, tak může tiše ukusovat paměť a výkon celé měsíce, než si někdo všimne. Anglicky se pro takové opuštěné modely někdy mluví o zombie models - modelech, které nikdo neřídí a nikdo neruší.

Objev konzumentů je proto první krok a naštěstí i nejlépe nástrojově pokrytý. Než sáhnete po testu křikem, zapněte na inferenčním serveru záznam požadavků a rozjeďte distribuované trasování - OpenTelemetry, Jaeger nebo Zipkin dokážou z propagovaných hlaviček poskládat graf, kdo koho volá, a odhalit vazby, které vznikly organicky a nikdo je nenakreslil. Metriky inferenčních serverů typu Triton, KServe, vLLM nebo Ray Serve navíc řeknou, kolik požadavků na daný model reálně teče. Model s nulovým provozem je kandidát na odchod; teprve na něm má smysl scream test, a i tak s připraveným návratem a archivací dat. Pořadí je podstatné: telemetrie první, křik až potom.

Když víte, kdo model volá, přichází na řadu formální stránka věci. Model není buď „živý“, nebo „mrtvý“; prochází stavovým automatem, a ten automat musí být čitelný strojem.

Registry modelů si tím prošly a poučily se. MLflow historicky nabízel čtyři pevné fáze (None, Staging, Production, Archived), jenže od verze 2.9 je označuje za překonané a posílá uživatele k aliasům a štítkům. Rozdíl není kosmetický: alias je pohyblivý pojmenovaný ukazatel, třeba @champion, a na jednu verzi jich může mířit víc, což pevná fáze neuměla. Vertex AI od Googlu jde ještě dál a žádnou konvenci nepředepisuje: jediný alias, který registr zná sám od sebe, se jmenuje default a určuje verzi, která se použije, když nikdo neřekne jinak. Všechno ostatní, tedy production, staging, challenger nebo cokoli jiného, si pojmenujete sami. Zní to jako absence návrhu; ve skutečnosti je to jeho jádro. Registr nemá vnucovat proces, má nabídnout ukazatel, kterým se dá pohnout.

Proč na tom trvám? Protože „je to deprecated“ napsané ve wiki nikdo nepřečte a žádná automatika na to nezareaguje. Kdežto stav vyčtený z registru přes API se dá zapojit do CI, do alertu, do brány, do přehledu. Rozdíl mezi organizací, která ví, a organizací, která tuší, není v tom, jestli to má napsané - je v tom, jestli to má napsané tam, kde se to dá přečíst bez člověka.

Protokolová rovina na to má vlastní nástroje, jen se skoro nepoužívají. Hlavičku Sunset, která ohlašuje datum, kdy zdroj přestane odpovídat, definoval Erik Wilde v RFC 8594 už v květnu 2019; její mladší sestra Deprecation prošla do standardu jako RFC 9745 teprve v březnu 2025. Doprovodný odkaz Link míří na migračního průvodce a po datu odstávky se typicky vrací stavový kód 410 Gone. Upřímně řečeno, většina API tyto hlavičky neposílá a běžné HTTP knihovny je tiše zahodí, takže samy o sobě nespasí nic; hodnota vzniká z disciplíny okolo. Zajímavější je, co si o svém životním cyklu píší sami dodavatelé modelů - protože to jsou lhůty, podle kterých si můžete nastavit vlastní.

A ty lhůty se dají číst jako ceník trpělivosti. OpenAI slibuje u běžně dostupných modelů odklad nejméně šest měsíců, u specializovaných variant tři a u preview klidně jen dva týdny. Azure drží běžně dostupné verze minimálně dvanáct měsíců a před vyřazením dává aspoň šedesátidenní varování. Amazon má u modelů v Bedrocku tři stavy (Active, Legacy a EOL), které se dají přečíst programově z pole modelLifecycle, a garantuje dvanáct měsíců na platformě a šest měsíců ve stavu Legacy; od února 2026 k tomu přidal fázi, která stojí za pozornost každému, kdo si myslí, že setrvání na starém modelu je zadarmo: po třech měsících v Legacy model přechází do režimu veřejného rozšířeného přístupu, kde dál běží - ale za vyšší cenu, kterou určuje jeho poskytovatel. Odklad migrace tím dostal fakturu.

Anthropic pak dělá něco, co v tomhle odvětví nemá obdoby. Kromě šedesátidenní lhůty u veřejně vydaných modelů se zavázal uchovat váhy všech takových modelů minimálně po dobu existence firmy a před vyřazením s modelem vede takzvaný retirement interview - rozhovor, ve kterém se ptá, jestli si model něco nepřeje. Claude Opus 3 prošel 5. ledna 2026 celým tímto procesem jako první; formálně je vyřazený, prakticky zůstává dostupný předplatitelům a přes API na požádání. Firma k tomu přidává větu, která celý článek shrnuje lépe než já: náklad na udržování dostupnosti roste zhruba lineárně s každým dalším obsluhovaným modelem. Právě proto se modely vůbec vyřazují - a právě proto se to jednou bude týkat i vás.

Všechno výše popsané je ale pořád hašení. Pokud vás vyřazení modelu bolí, není problém v tom, že neumíte vypínat - je v tom, jak jste to zapnuli. A lék je starý několik desetiletí.

Jmenuje se anti-corruption layer, antikorupční vrstva, a poprvé ji popsal Eric Evans v knize Domain-Driven Design z roku 2003; dnes ji má v katalogu vzorů i Microsoft. Její smysl je jediný: nedovolit, aby model vnějšího, proměnlivého subsystému „nakazil“ návrh vaší aplikace. Přeloženo do řeči jazykových modelů - vaše aplikace nikdy nevolá knihovnu dodavatele přímo. Mluví s vaším vlastním rozhraním a překlad na konkrétního dodavatele obstará adaptér schovaný za tím rozhraním. Když měníte model, měníte nebo přidáváte adaptér; doména zůstává netknutá. Je to táž myšlenka jako hexagonální architektura, porty a adaptéry, nebo dobře známé návrhové vzory adaptér a strategie. Nic převratného, jen konečně použité na tu nejrychleji zastarávající součástku ve stacku.

V dnešní praxi tuhle vrstvu nejčastěji ztělesňuje takzvaná AI brána, gateway. Jediný interní endpoint, za kterým se skrývá mnoho modelů a dodavatelů. Open source LiteLLM se hlásí ke stovce a více poskytovatelů pod jedním rozhraním a mezi svými produkčními uživateli uvádí Netflix nebo Lemonade; Cloudflare, Kong, Portkey, MLflow AI Gateway nebo v TypeScriptu Vercel AI SDK slibují v jádru totéž - přepnutí modelu se stane změnou konfigurace, ne kódu. Že to není jen marketing, ukazuje DoorDash, který svého AI recenzenta kódu staví vědomě modelově agnosticky, aby mohl sahat po nejlepším modelu napříč dodavateli i open source a poměřovat je stejnou sadou testů.

Právě rozhraní kompatibilní s OpenAI se přitom stalo faktickým průmyslovým standardem - mluví jím vLLM, TGI, Ollama, llama.cpp i kompatibilní endpointy dalších velkých dodavatelů, takže v ideálním případě model vyměníte tím, že přepíšete adresu serveru a jméno modelu. Jen si od té kompatibility nesmíte slibovat víc, než unese. Mechanická výměna ano; shoda chování nikdy zaručená. Tým FutureSearch, který denně žene desetitisíce volání napříč třemi velkými dodavateli, to shrnuje tak, že rozhraní vypadají na papíře zaměnitelně, ale rozdíly vám rozbijí kód - jiné schéma volání nástrojů, jiné vynucování strukturovaného výstupu, jiné zacházení se systémovým promptem, jiná mechanika ukládání promptu do cache, jinak (ne)podporovaná teplota. Sám Anthropic u své kompatibilní vrstvy varuje, že je určená hlavně k testování a srovnávání, ne jako produkční řešení, a otevřeně přiznává, co se v ní ztrácí: systémové zprávy se slévají do jedné, vynucení schématu u volání nástrojů se ignoruje, ukládání promptu do cache nefunguje. Brána tedy sjednotí těch osmdesát procent, která jsou společná; zbylých dvacet, kde se dodavatelé liší, je přesně tam, kde bydlí jejich konkurenční výhody i vaše migrační riziko.

K rozhraní patří ještě dvě věci, na které se zapomíná. Prompty nejsou součást kódu, jsou to verzované artefakty - patří do registru (Langfuse, Portkey a další), kde na verzi ukazuje pohyblivý štítek produkce a v kódu se odkazuje jen ten štítek, takže povýšení i návrat jdou bez nasazení. A embeddingy jsou vůbec nejtěžší případ přenositelnosti, protože vektorový prostor je vázaný na konkrétní model: dotazem přes model B prostě nenajdete vektory uložené modelem A. Jméno, verzi i dimenzi embedding modelu je proto potřeba připíchnout do konfigurace a každou jeho změnu brát jako migraci schématu.

Tady se ukazuje, proč sama hezká brána nestačí. Přepnout aplikaci z modelu na model umí brána udělat triviálně - je to změna váhy na routě, ne nové nasazení. To je podstata blue/green nasazení, jak ho v roce 2010 popsal Martin Fowler: dvě co nejpodobnější prostředí, okamžité přepnutí, okamžitý návrat. Modrá je starý model, zelená nový, a brána je ten přepínač.

Jenže k tomu vzoru později přibyl odstavec, který je u AI systémů úplně zásadní: databázi je potřeba změnit dřív než aplikaci a tak, aby po dobu přechodu obsloužila starou i novou verzi zároveň. Teprve tehdy máte kam couvnout. A vyhledávání postavené nad vektorovým indexem tuhle podmínku z principu nesplňuje - staré a nové vektory leží v neslučitelných prostorech, jak jsem popsal výše. Blue/green aplikace bez blue/green indexu je iluze bezpečí.

Řešení je architektura dvou indexů, navržená od začátku. Nový index se sází vedle starého: dávková úloha na pozadí přepočítá celý korpus novým modelem, zatímco starý index dál obsluhuje živý provoz. Nové příchozí dokumenty se zapisují do obou. Na oddělené sadě dotazů se ověří, že nový index nezhoršil úplnost ani relevanci výsledků. A teprve pak se přepne - atomicky, přehozením ukazatele: v Elasticsearchu nebo OpenSearchi aliasem, v Milvu záměnou kolekce, nad pgvectorem výměnou tabulky či pohledu. Žádný dotaz nikdy neuvidí napůl přepočítaný index. Dominantní cena tu není úložiště, ale jeden výpočetní průchod přes celý korpus. Zní to jako práce navíc; je to táž práce, jakou byste odvedli u migrace databázového schématu, jen aplikovaná na místo, kde se na ni obvykle zapomíná.

Samotné přepnutí pak nemá být skok. Osvědčená posloupnost vede od offline vyhodnocení na zlaté sadě přes stínový provoz, kdy nový model dostává kopii produkčních požadavků a jeho výstupy se logují, ale nikomu neservírují, přes canary s postupně rostoucím podílem provozu až po plné přepnutí, se starým modelem drženým v teple pro případ návratu. SageMaker má stínové testování zabudované přímo v sobě a povýšení stínové varianty na produkční řeší pod kapotou právě jako blue/green, bez výpadku dostupnosti. Ve světě strojového učení má tenhle vzor i vlastní jméno: champion/challenger. V produkci je vždy jen jeden vítěz, který obsluhuje veškerý provoz, zatímco vyzyvatelé běží ve stínu - soustavná soutěž, ne jednorázová migrace. Její vedlejší produkt je přesně to, co potřebujete v okamžiku deprekace: čerstvé srovnání starého a nového modelu na živých datech, ne domněnka.

I kdybyste postavili dokonalou bránu, měli prompty ve verzích a index za pohyblivým ukazatelem, pořád vám zbývá otázka, na kterou žádná vrstva kódu neodpoví: kdo se rozbije? Představte si čtyřicet aplikací, deset vlastníků a jeden sdílený embedding model, který má jít k ledu. Tady se lámou velké firmy, zatímco malé to nepocítí - ne proto, že by to dělaly líp, ale protože jim celý stack sedí v jedné hlavě.

Uber ve svém inženýrském blogu o platformě Michelangelo uvedl v roce 2024 čísla, která stojí za chvíli ticha: zhruba čtyři sta aktivních projektů strojového učení, přes dvacet tisíc trénovacích běhů měsíčně, více než pět tisíc modelů v produkci a ve špičce deset milionů predikcí v reálném čase za sekundu. Pět tisíc modelů se v hlavě neunese. Uber je uřídil tím, že platforma - ne jednotlivé aplikace - ví, který model kde běží, a je postavená jako zásuvné komponenty, které jdou vyměnit.

Registr modelů řekne, co existuje. Neřekne, kdo to volá. Na to je katalog služeb - nejznámější je Backstage, který vznikl ve Spotify a je dnes darovaný nadaci CNCF. Jeho softwarový katalog sleduje vlastnictví a metadata veškerého softwaru, výslovně včetně služeb, webů, knihoven, datových pipeline i modelů strojového učení, a skládá z nich graf závislostí. To je právě ten seznam, který chyběl týmu z úvodní historky.

Druhá vrstva je dokumentace samotného modelu. Model cards popsala Margaret Mitchellová se spoluautory v roce 2019 na konferenci FAT* (arXiv:1810.03993): standardizovaný list o devíti sekcích, kde stojí zamýšlené použití, metriky, limity, kdo model vytvořil a v jaké verzi. Dnes je to páteř governance a mimo jiné i vstupní surovina pro povinnosti podle evropského nařízení o umělé inteligenci. Model bez model card je v roce 2026 zhruba to, co byla knihovna bez README v roce 2010.

Třetí vrstva je ta, kterou většina firem nemá, a přitom je nejúčinnější. Jmenuje se kontrakty řízené konzumentem a formuloval je Ian Robinson v roce 2006 v textu Consumer-Driven Contracts: A Service Evolution Pattern - publikovaném na Fowlerově webu, což je mimochodem důvod, proč se autorství tak často mýlí. Princip jde proti intuici: kontrakt nedefinuje poskytovatel, ale každá spotřebovávající aplikace publikuje tu část, na které skutečně závisí. Poskytovatel pak z těch dílčích kontraktů vidí, co smí změnit a co ne. Robinson pojmenoval i chorobu, kterou to léčí: bez kontraktů musí poskytovatel a všichni jeho konzumenti skočit najednou. Nástroj, který to dělá v praxi, se jmenuje Pact a má příkaz s výmluvným názvem can-i-deploy - brána v CI, která odpoví na otázku „smím tuhle verzi modelu vyřadit, aniž někoho rozbiju?“ strojově, ne po e-mailu.

Zbývá poslední kus: jak těch čtyřicet aplikací převést ze starého modelu na nový, když každou vlastní někdo jiný a nikdo nemá čas. Odpověď má téhož autora jako blue/green a je ještě starší, z roku 2004 - strangler fig, škrtící fíkovník. Ten strom v přírodě obroste hostitele, postupně ho nahradí a nakonec z původního kmene zbude prázdné místo. V softwaru to znamená, že před starý model postavíte fasádu (což je, mimochodem, táž brána, o které byla řeč výše), a ta pak směruje každou aplikaci buď na starý model, nebo na nový. Migrujete po jedné. Když přejde poslední, starý model se odpojí a nikdo si toho nevšimne, protože už na něj nikdo nevolá. Katalogy vzorů obou velkých cloudů se přitom shodují, že po dobu soužití obou modelů je potřeba fíkovník kombinovat s antikorupční vrstvou - v mezidobí musí staré i nové koexistovat, aniž se navzájem otráví.

Kde se v tomhle nachází vaše firma, se dá i změřit. Google ve svém textu o MLOps rozlišuje tři úrovně - od nulté, kde je všechno ruční, přes automatizovanou ML pipeline až po plnou automatizaci CI/CD. Microsoft má v architektonickém centru pětistupňový model zralosti od „žádné MLOps“ po „plně automatizovaný provoz“. Nemá cenu předstírat, že se dá skočit z nuly na čtyřku. Má ale cenu vědět, na které příčce stojíte, protože to určuje, jestli je vaše další investice katalog, nebo kontraktové testy.

Teď poctivě proti všemu výše. Námitky jsou dvě a obě jsou silné.

První se týká architektury. Nezní „je to moc práce“; zní „je to špatná práce“. Kdo abstrahuje k přenositelnému rozhraní, dobrovolně se vzdává dodavatelových superschopností - efektivního ukládání promptu do cache, nativního volání nástrojů, režimů uvažování, dávkových API, doladění na míru. Nejostřeji to formuloval jeden dodavatel finančního AI ve svém firemním blogu o vendor lock-inu: „model-agnostic“ v důsledku znamená „suboptimální na všech modelech“. Zdroj má na téhle tezi zjevný obchodní zájem, ale to ji nedělá falešnou. Kdo staví na nejmenšího společného jmenovatele, dostane strop na úrovni nejslabšího z dodavatelů. K tomu se přidává mýtus přenositelných promptů: prompt vyladěný na jeden model na jiném často spadne - ne proto, že by byl špatný, ale protože počítá se sdíleným kontextem, který jinde neplatí. Migrace není zadarmo ani s dokonalou bránou. A brána sama je nová závislost: přidává síťový skok a latenci, je to další služba k provozu a v krajním případě se z ní stane nový lock-in, jen o patro výš. Pro startup, který potřebuje být první na trhu, může být vědomé hluboké napojení na jednoho dodavatele racionální sázka. Rada „nikdy nepoužívej dodavatelovy specifické funkce“ je pro takovou firmu prostě špatná.

Druhá námitka se týká governance a je stejně nepříjemná. Katalogy zastarávají. Povinné pole „vlastník“ je za rok po zavedení vyplněné jménem člověka, který už ve firmě nepracuje. Model card se napíše jednou, při nasazení, a pak už nikdy. Kontraktové testy jsou další sada testů k údržbě. A celá governance je daň, která nevynáší nic, dokud nehoří - a když hoří, stejně se sáhne po vypnutí a čekání, kdo zakřičí. Ruční metadata jsou divadlo, protože skutečná odpovědnost z formuláře nevzniká.

Obě námitky jsou z velké části pravdivé a nemá smysl je obcházet. Odpověď na ně existuje a v obou případech je to odpověď o míře, ne o principu.

U architektury je rozdíl mezi tenkou a maximalistickou vrstvou. Cílem není postavit univerzální adaptér, který zakáže cokoli specifického. Cílem je dost dobrý šev - takový, u kterého si můžete později rozmyslet názor. Že to není akademické, ukázal začátkem července 2026 znovu DoorDash: protože je architektura jeho recenzenta kódu modelově agnostická, je model skauta i model recenzenta samostatně vyměnitelná proměnná. Když je protočili proti stovce reálných pull requestů z vlastního repozitáře, ukázalo se, že jejich produkční sestava není ta nejlepší - vítězná kombinace, s open source modelem v roli skauta, našla víc skutečných nálezů a vyšla o něco levněji. Firma sama upozorňuje, že čísla platí pro její kód a její kritéria. Ale pointa drží: kdo je uzamčený u jednoho dodavatele, tuhle otázku nemůže ani položit. Námitka „suboptimální na všech modelech“ platí pro architekturu bez měření. S měřením se z ní stává její opak.

Přesto ji nechci odbýt úplně. Když je nějaká dodavatelova funkce pro danou úlohu rozhodující, klidně ji použijte - jen si vzniklý lock-in zapište jako vědomý, ohraničený a oceněný náklad, ne jako náhodu, kterou objevíte až u odstávky. Dá se řídit jako technický dluh: spočítat cenu úniku, držet ji v mezích a splácet ji záměrně.

U governance je rozdíl v tom, jestli se údaje odvozují z reality, nebo vyplňují do formuláře. Kdo je vlastník? Ten, kdo commituje do repozitáře - vytáhněte to z gitu, ne z tabulky. Kdo model volá? Ten, kdo se objevuje v trasování a v přístupových logách brány - vygenerujte graf závislostí z telemetrie, ne z dotazníku. Na čem konzumenti závisí? Na tom, co jim projde kontraktovým testem v CI, ne na tom, co si myslí. Katalog, který je zrcadlem provozu, nezastará, protože nemá jak. Katalog, který se vyplňuje z povinnosti, zastará vždycky. (Backstage sám v dokumentaci radí opak: automatiku prý použít jen na vygenerování prvního souboru a dál mají metadata udržovat lidé. Mám za to, že rozdíl je v povaze údaje. Co plyne z faktu - kdo commituje, kdo volá, co projde testem - odvozujte a nedovolte to přepsat rukou. Co plyne z úmyslu, tedy k čemu ten model vlastně je a kde se nesmí použít, musí napsat člověk a smířit se s tím, že to zestárne.)

Tým, který vypnul tisíc aplikací a nikdo nezakřičel, měl štěstí. Firma, která svůj starý model za pár let bez bolesti odpojí a uvolní výpočetní kapacitu, štěstí mít nebude muset - bude mít graf závislostí z telemetrie, prompty ve verzích, index za pohyblivým ukazatelem, kontrakt v CI a bránu, na které je přepnutí modelu otázkou jednoho řádku v konfiguraci.

Takže poslední otázka, a je nepříjemně konkrétní: zkuste si teď hned tipnout, kolik aplikací ve vaší firmě volá váš nejstarší nasazený model. Pak to zjistěte. Rozdíl mezi tím tipem a tím číslem je přesně velikost problému, který jednou budete muset zaplatit.

Text vznikl na základě hloubkové rešerše primárních zdrojů (dokumentace poskytovatelů, inženýrské blogy, akademické práce, kanonické popisy návrhových vzorů) a byl následně větu po větě přeověřen.

Časově citlivé údaje. Lhůty deprekace jednotlivých poskytovatelů, datum vyřazení Claude Opus 3 (5. 1. 2026), režim rozšířeného přístupu v Bedrocku a čísla o objemu modelů na platformě Uber Michelangelo (rok 2024) pocházejí z veřejných materiálů těchto firem a mění se řádově měsíčně. Vše ověřeno k 11. červenci 2026; při pozdější publikaci je nutné je znovu porovnat s aktuální dokumentací.

Co není doloženo. Historka z úvodu koluje v provozní komunitě a její primární zdroj se mi nepodařilo dohledat; uvádím ji bez identifikace firmy, jako ilustraci metody, ne jako doložený případ.

Co je sporné. Otázka přenositelnosti versus vědomý lock-in je strategicky sporná a existují silné argumenty pro obě strany. Formulace, že „model-agnostic“ znamená „suboptimální na všech modelech“, pochází z firemního blogu dodavatele finančního AI, tedy ze zdroje se zájmem na výsledku; v textu proto vystupuje jako nejsilnější podoba námitky, ne jako doložené zjištění. Čísla z benchmarku DoorDashe platí pro jeho vlastní kód a jeho vlastní kritéria; firma to sama zdůrazňuje a nelze je přenášet jinam.

Klíčové primární zdroje. Sculley, D. a kol.: Hidden Technical Debt in Machine Learning Systems, NIPS 2015 (papers.nips.cc) - koncept undeclared consumers. Evans, E.: Domain-Driven Design (2003) - Anti-Corruption Layer; Microsoft Azure Architecture Center, Cloud Design Patterns - moderní popis vzoru. Fowler, M.: BlueGreenDeployment (2010) a StranglerFigApplication (2004), martinfowler.com. Robinson, I.: Consumer-Driven Contracts: A Service Evolution Pattern (2006), martinfowler.com; Pact - dokumentace příkazu can-i-deploy. RFC 8594 (The Sunset HTTP Header Field, E. Wilde, květen 2019) a RFC 9745 (The Deprecation HTTP Response Header Field, S. Dalal a E. Wilde, březen 2025), datatracker.ietf.org. OpenAI - Deprecations (developers.openai.com); Microsoft Learn - Azure OpenAI model retirements; AWS - Bedrock model lifecycle (pole modelLifecycle, režim rozšířeného přístupu od 1. 2. 2026) a SageMaker shadow testing; Anthropic - Commitments on model deprecation and preservation a An update on our model deprecation commitments for Claude Opus 3, dále OpenAI SDK compatibility (platform.claude.com). MLflow - dokumentace Model Registry (fáze překonané od verze 2.9 ve prospěch aliasů); Google Cloud - Vertex AI Model Registry, How to use model version aliases. LiteLLM (github.com/BerriAI/litellm), Cloudflare AI Gateway, Kong AI Gateway, Portkey, MLflow AI Gateway, Vercel AI SDK. FutureSearch: LLM API Differences That Break Your Code (futuresearch.ai). DoorDash Engineering: How DoorDash built an AI code reviewer engineers actually listen to a How we learned to trust our AI code reviewer at DoorDash (6. 7. 2026). Backstage - dokumentace Software Catalog (backstage.io), projekt darován CNCF; Mitchell, M. a kol.: Model Cards for Model Reporting, FAT* 2019, arXiv:1810.03993. Uber Engineering: From Predictive to Generative - How Michelangelo Accelerates Uber’s AI Journey (2024). Google Cloud: MLOps: Continuous delivery and automation pipelines in machine learning - úrovně 0 až 2; Microsoft: MLOps maturity model - pět stupňů.

Koncepce, struktura a redakční linie článku jsou dílem autora, který vypracoval obsahovou skicu, stanovil klíčové teze a řídil celý proces tvorby. Generativní AI (Claude, Anthropic) byla využita jako nástroj pro rešerši, vyhledávání primárních zdrojů a formulační rozpracování autorovy obsahové skici.

Autor výstupy průběžně redigoval, ověřil klíčová zjištění a schválil finální znění. Žádná část textu nebyla publikována bez lidské kontroly. Všechny faktické údaje byly ověřeny proti veřejně dostupným zdrojům uvedeným v textu.

Postup je v souladu s požadavky čl. 50 Nařízení EU 2024/1689 (AI Act) na transparentnost AI-generovaného obsahu. #poweredByAI