Převzetí AI aplikace: co je jiné a kde jsou hlavní rizika.

Klasický software má relativně jasné vrstvy — backend, frontend, databáze, infrastruktura. Když ho přebíráte, kontrolujete kód, testy, deployment, dokumentaci. AI aplikace má všechno tohle plus tři další vrstvy, které z hand-off dokumentace často úplně chybí.

První vrstva je model — base model, případně fine-tuning, system prompts, parametry inference, API klíče u providera. Pokud projekt používá fine-tuned model, kdo ho vlastní? Je verzovaný? Existuje reproduktibilní training pipeline, nebo je váha modelu jediný artefakt v Drive složce bývalého CTO?

Druhá vrstva je datová pipeline — odkud tečou trénovací nebo vyhledávací data, jak se anotují, kde se ukládají embeddingy, jak se invaliduje vector index. U RAG aplikací je tato vrstva často kritičtější než kód okolo, ale v dokumentaci pro převzetí na ni narážíme nejméně.

Třetí vrstva je evaluace — eval set s benchmarky, regresní testy na hallucinace, A/B framework, monitoring kvality v produkci. Pokud nic z toho neexistuje, nemáte jak poznat, že vaše první změna zhoršila kvalitu odpovědí o 8 procentních bodů — uvidíte to až na ticketech od zákazníků.

Šablonu pro AI převzetí jsme upravili po stabilizaci startupu **AiLuvio** (real-time překlad video hovorů, 30+ jazyků, mobile iOS/Android). Tam jsme prošli čtyřmi fázemi, které se nám teď opakují u dalších projektů.

Fáze 1 — stabilizace. Cílem je dostat aplikaci do měřitelně funkčního stavu. U AiLuvio to znamenalo opravit build errors, vyřešit null/undefined avatar loading, problémy s crypto knihovnou pro mobile, stabilizovat reCAPTCHA a file handling. AI komponenta v této fázi není priorita — priorita je, aby aplikace nepadala.

Fáze 2 — audit AI vrstvy. Sepíšeme model registry (jaké modely se používají, kdo je vlastník, jaká je cena za milion tokenů), prompt registry (kde žijí prompty, jak se mění, kdo je schvaluje) a data pipeline (zdroj, čistota, retention). Souběžně postavíme základní eval set — typicky 50 až 200 reprezentativních vstupů s očekávaným výstupem.

Fáze 3 — produkční monitoring. Bez monitoringu AI komponenty letíte naslepo. Nasazujeme logování každé inference (vstup, výstup, model, latence, cena), telemetrii pro hallucinace a uživatelský feedback signál. Bez tohoto kroku nelze fázi 4 dělat zodpovědně.

Fáze 4 — první vlastní změna. Refactor jedné komponenty, výměna jednoho modelu, úprava jednoho promptu — vše s před/po měřením proti eval setu. U českého B2C SaaS startupu pre-Series A jsme v této fázi převzali dvě AI doporučovací komponenty a refactorovali je pro produkční stabilitu, včetně due diligence dokumentace pro investora.

Audit AI vrstvy má v naší metodice 11 bodů. Tři z nich považujeme za kritické a zmiňujeme je v každém reportu, i když výsledek je dobrý — protože to je rámec, který se klientovi po hand-offu může dál hodit.

Vlastnictví modelu a klíčů. API klíče OpenAI, Anthropic nebo Mistral byly často vystavené na účet bývalého CTO osobně. Migrace na firemní účet, rotace klíčů, nastavení usage limits a billing alertů jsou prvních 48 hodin práce, kterou nelze odložit. U **AiLuvio** to bylo součástí publikační fáze před launchem do App Store.

Reproducibilita fine-tuningu. Pokud projekt používá fine-tuned model, ptáme se: máme trénovací data? Máme parametry? Umíme model vyrobit znovu z čistého base modelu? Pokud ne, model je technický dluh — ne aktivum.

Eval set a regresní testy. Bez evaluace neumíte AI komponentu měnit zodpovědně. U převzatého SaaS startupu jsme v prvním měsíci postavili eval set z 80 reprezentativních dotazů s očekávaným výstupem a do CI pipeline napojili regresní test, který blokuje merge, pokud kvalita klesne pod baseline. To samé bychom napsali u běžného softwaru o testech jednotky — u AI to ale typicky chybí.

Po několika převzetích AI projektů máme tři opakující se nálezy, které se vyplatí ohlídat na začátku, ne až v produkci.

Hallucinace bez monitoringu. AI odpovídá sebevědomě a samolibě i tehdy, když si vymýšlí. Bez monitoringu vstupů, výstupů a uživatelské zpětné vazby se hallucinace projeví až jako stížnosti. U převzaté aplikace pre-Series A jsme našli endpoint, který za 3 měsíce produkce nikdo nelogoval — a 12 % odpovědí nesedělo k databázové realitě.

Prompt injection a chybějící rate limit. AI endpointy, které přijímají uživatelský vstup, jsou vektor pro prompt injection a pro neúměrné spotřebování tokenů. U auditu B2C SaaS startupu jsme identifikovali kritické zranitelnosti včetně SQL injection ve dvou endpointech a vystavených env vars — a chybějící rate limit na endpointu, který volal LLM.

Cena, která utíká. Bez billing alertů a bez logu cen za inference nikdo nevidí, že váš měsíční účet u OpenAI tiše vyrostl o 40 % po nasazení nové verze promptu, který je delší o 600 tokenů. Audit nákladů je v naší šabloně standard — typicky najdeme úsporu 15 až 30 % během prvních dvou měsíců.

Ne každý projekt má smysl přebírat. V některých případech je rewrite levnější a méně rizikový. V naší praxi rozhodujeme podle čtyř kritérií, které se týkají specificky AI vrstvy.

Stav datové pipeline. Pokud projekt nemá zdokumentovanou datovou pipeline, ale data sama jsou kvalitní a jsou ve vlastnictví klienta, převzetí dává smysl — pipeline lze obnovit. Pokud data sama jsou špatná nebo neexistují, AI vrstva je k ničemu a rewrite je upřímnější varianta.

Vendor lock-in na úrovni modelu. Pokud aplikace používá obskurní vendor s drahým API a žádnou exit strategií, převzetí znamená i migrační projekt. Spočítejte si, jestli by rewrite na vendor-neutral architekturu (LiteLLM, abstrakční vrstva) nebyl rychlejší než postupná oprava.

Kvalita base architektury. Pokud kolem AI komponenty je jinak rozumný kód, dokumentace a CI, převzetí je obvykle 30 až 60 % nákladů rewritu. Pokud kód je vibe-coded přes Cursor a Lovable bez testů, audit často odhalí, že rewrite vyjde podobně nákladově a bez technického dluhu.

Časový tlak. AI startupy mají často tvrdý termín — Series A, mezinárodní launch, soutěž. Převzetí typicky umí dodat funkční stav rychleji, rewrite je čistší, ale pomalejší. U **AiLuvio** jsme volili převzetí kvůli launchi do App Store a Google Play, u jiných projektů jsme klientovi rewrite naopak doporučili.

Pokud zvažujete převzetí AI projektu nebo potřebujete nezávislý audit AI vrstvy před investorským kolem, ozvěte se nám. Úvodní audit v rozsahu 4 až 6 týdnů zahrnuje vlastnictví modelů, datovou pipeline, eval set i bezpečnostní pohled — a výstupem je dokumentace použitelná i v due diligence.