AI PoC do produkce: 12bodový kontrolní seznam před nasazením

Od AI PoC k produkci: 12bodový checklist před nasazením

Váš checklist přechodu z AI PoC do produkce začíná platit ve chvíli, kdy demo přestane být demem. Problém je následující: uhlazený prototyp, který v úterý ohromil tým, může tiše spálit účet od OpenAI za 40 000 dolarů, spadnout pod reálným provozem a halucinovat na vstupech, které nikdo netestoval. Gartner v červenci 2024 předpověděl, že minimálně 30 % projektů generativní AI bude po fázi proof of concept opuštěno. Ne proto, že by model byl slabý. Protože nikdo nevybudoval zábradlí před dnem nasazení.

Demo dokazuje, že model to zvládne jednou. Produkce dokazuje, že to zvládne desettisíckrát, v rámci rozpočtu, bez vašeho dohledu. Těchto 12 kontrol je bránou mezi jedním a druhým.

Kdy je AI PoC připravené na produkci?

AI PoC je připravené na produkci ve chvíli, kdy jiný tým dokáže systém provozovat, monitorovat a platit za něj bez osoby, která ho postavila. To znamená práci s reálnými daty, evaluační baseline, kontrolu nákladů, logiku rate limitů a fallbacků, observabilitu a fázované nasazení s plánem rollbacku. Pokud to funguje jen když se autor dívá, je to pořád demo.

Všech 12 bodů na jednom místě, seskupených podle fáze. Každý je rozveden níže.

Proč se většina AI PoC nikdy nedostane do produkce?

Většina přechodů z AI proof of concept do produkce uvázne z provozních důvodů, ne kvůli kvalitě modelu. Demo zvládá happy path; produkce čelí nákladovým špičkám, rate limitům, výpadkům a vstupům, které tvůrce nikdy nepředpokládal. Zaplňte tyto mezery a stejný model nasadíte bez problémů.

Gartner v červenci 2024 předpověděl, že minimálně 30 % projektů generativní AI bude do konce roku 2025 opuštěno po fázi proof of concept, a jako důvody uvedl špatnou kvalitu dat, slabou kontrolu rizik, rostoucí náklady a nejasnou obchodní hodnotu. Berte to jako prognózu, ne hotovou věc, ale přesně pojmenovává selhání.

Zpráva MIT ze srpna 2025, The GenAI Divide, zjistila, že zhruba 95 % pilotů generativní AI nedosahuje měřitelného ROI. Jde o ROI, ne o nasazení, ale vzorec platí: i piloty, které se nasadí, uvíznou na nákladech, spolehlivosti a prokazování kvality výstupů.

Většina AI PoC neselže proto, že model je špatný. Selžou proto, že nikdo nevybudoval zábradlí, nákladové stropy ani fallbackovou cestu před dnem nasazení.

Fáze 1 — Harden: Opravte základy (body 1–4)

Dejte do pořádku data, evaluace, bezpečnost a nákladový model dřív, než se funkce dotkne jediný živý uživatel.

1. Pipeline reálných dat

Nejprve nahraďte syntetické vstupy demo verze skutečnou produkční datovou cestou. Prototypy dostávají čistá, kurátorovaná data; produkce dostává zmršené řádky, zastaralé záznamy a PII, se kterými jste nepočítali. Napojte funkci na živý zdroj, validujte schéma a potvrďte, jaká osobní data systémem protékají. AWS Prescriptive Guidance to označuje za základ funkčního gen AI buildu. Hotovo když: běží end-to-end na živých datech tři a více po sobě jdoucích dní bez ruční přípravy.

2. Evaluační baseline / golden set

Definujte „dostatečně dobré" číslem dřív, než nasadíte. Vytáhněte 30 až 100 reálných vstupů, napište očekávaný výstup pro každý, a máte golden set. Každý build proti němu ohodnoťte průchodovou hranicí (řekněme 90 % a výš), která gateuje nasazení. Bez ní se regrese objeví v support tiketu místo v testovacím běhu. Tady je návod, jak sestavit eval suite. Hotovo když: opakovatelná evaluace hodnotí build proti pevně stanovenému prahu.

3. Bezpečnostní a privacy review

Zauditujte, čeho se váš model může dotknout: API klíče, nástroje, databáze, uživatelská data. Prompt-injected vstup by neměl být schopen číst tajné klíče ani volat nástroj, který nemá. Redagujte PII dřív, než dorazí k providerovi, a zkontrolujte podmínky retence dat (kde to jde, odhlaste se z trénování). Hotovo když: review datových toků a přístupů je podepsáno, žádné tajné klíče nejsou v promptech a redakce PII běží před jakýmkoli externím voláním.

4. Nákladový model a tokenový rozpočet

Znejte svůj náklad na běh a měsíční strop před nasazením, ne z prvního děsivého faktury. Vynásobte tokenový náklad jednoho typického požadavku očekávaným objemem, pak nastavte hard cap a alert. Páky níže to číslo sníží, aniž by se dotkly kvality.

Aktuální sazby najdete v návodu, jak snížit náklady na LLM API; pro nastavení limitů a směrování na jednom místě směrujte přes LLM gateway. Hotovo když: znáte náklad na běh a měsíční strop, s alertem na 80 % rozpočtu a hard stopem na 100 %.

Fáze 2 — Stabilize: Přežije to reálný provoz? (body 5–9)

Model je v pořádku. Teď zajistěte, aby systém kolem něj přežil zátěž, výpadky a špatné vstupy, aniž by vzbudil kohokoli ve tři ráno.

5. Rate limiting + retry/backoff

Demo, na které kliká jeden člověk, přežije cokoli; stejný kód pod reálným provozem narazí na rate limity providera během minut. Nastavte limity požadavků na uživatele, retry s exponenciálním backoffem a jitterem a respektujte hlavičky 429 a Retry-After providera místo bušení do něj. Po několika po sobě jdoucích selháních aktivujte circuit breaker, aby se jeden výpadek nešířil kaskádově.

call model
on 429 or timeout: wait (2 ^ attempt) seconds + jitter, retry up to 3x
after 5 consecutive failures: open circuit, use the fallback

LLM gateway za vás vyřeší retry i limity, pokud si to nechcete stavět sami. Hotovo když: limity na uživatele jsou nastaveny a retry respektují 429 od providera.

6. Fallback / graceful degradation

Rozhodněte teď, co uživatel uvidí, když bude API modelu pomalé nebo nedostupné — protože bude. Postavte fallbackový řetězec: cachovaná poslední známá dobrá odpověď, levnější nebo sekundární model, nebo deterministická cesta, která model obejde. Nastavte timeout na p95 plus rezervu, u většiny synchronních funkcí kolem 8 sekund, pak aktivujte fallback. Hotovo když: otestovaná degradační cesta se spustí při timeoutu nebo chybě, takže se funkce nikdy prostě nezasekne.

7. Cíl latence + zátěžový test

Stanovte cíl p95 latence a dokažte, že ho dosáhnete pod zátěží. Pro synchronní UX miřte na p95 pod 3 sekundy; u delších generací streamujte tokeny, aby uživatel viděl progres. Zátěžový test dělejte na dvojnásobek až trojnásobek očekávané špičkové souběžnosti. Funkce, která vám odpoví za 900 ms, může při příchodu 50 lidí najednou dosáhnout 12 sekund. Hotovo když: cíl p95 je stanoven a funkce prošla zátěžovým testem při reálné souběžnosti.

8. Observabilita a logování

Nemůžete opravit, co nevidíte, proto logujte každý běh: vstup, výstup, latenci, počet tokenů a náklad na běh. Směrujte je do dashboardu, abyste se o problému dozvěděli z alertu, ne od naštvaného uživatele. Nastavte triggery: alert, když chybovost překročí 2 % za pět minut, nebo náklad na běh vyskočí nad baseline. Platforma pro AI observabilitu vám dá tracy a alerty bez nutnosti stavět to sami. Hotovo když: každý běh je logován a alerty na náklady a selhání jsou zapojeny.

9. Human-in-the-loop a guardrails

Validujte, co jde do modelu i co z něj vychází. Blokujte nebo redagujte nebezpečný obsah, před nasazením prověřte adversariální a okrajové vstupy a směrujte výstupy s nízkou confidence nebo vysokými sázkami na člověka. Nastavte práh confidence, který spouští lidskou kontrolu; schválení refundace by nemělo projít na první odhad modelu. Hotovo když: validace vstupu a výstupu je aktivní a cesta s nízkou confidence směruje na člověka.

Fáze 3 — Deploy: Nasaďte bez dramatu (body 10–12)

Nasazení je regulátor, ne vypínač. Otáčejte pomalu, sledujte čísla a mějte cestu zpět. Každá položka tady je rozhodnutí před nasazením.

10. Canary / fázované nasazení

Nejprve nasaďte na výsek uživatelů a sledujte čísla, než otevřete brány. Postupujte na 5 %, pak 25 %, pak 100 % a v každé fázi kontrolujte průchodnost eval, chybovost, latenci a náklady. Každou fázi držte 24 až 48 hodin a postupujte dál, jen pokud chybovost zůstane pod 2 % a náklady jsou v rozpočtu. Canary znamená nasadit nejprve na 5 % a přesně vědět, jaká chybovost vás donutí couvnout. Hotovo když: nasazení je fázované s písemnými kritérii postupu.

11. Plán rollbacku + on-call

Mějte otestovaný způsob, jak funkci během sekund vypnout, plus člověka, kterému přijde page. Feature flag nebo připnutá předchozí verze je váš rollback; zdokumentujte přesné triggery. Nastavte je konkrétně: automatický rollback, pokud chybovost překročí 5 % po dobu 10 minut nebo náklad na běh přesáhne dvojnásobek vašeho limitu, a page jmenovaného on-call vlastníka. Neotestovaný rollback není rollback. Hotovo když: rollback je otestován, triggery jsou explicitní a jeden jmenovaný člověk vlastní pager.

12. Vlastnictví po nasazení a kadence

Pojmenujte, kdo vlastní tuto funkci v pondělí ráno, dřív než ji v pátek nasadíte. Produkční AI driftuje: vstupy se mění, provideři aktualizují modely a eval skóre z minulého měsíce klesá. Naplánujte opakované eval a kontroly driftu (nejprve týdně, pak měsíčně) a veďte changelog pro každou verzi promptu a modelu. Hotovo když: vlastník je jmenován v runbooku, první opakovaná evaluace je naplánována a existuje log verzí.

Jak k tomu přistupuje Techsy

Náš delivery proces se mapuje na stejné tři fáze. Discover a Design pokrývají práci ve fázi Harden: fixujeme reálná data, stavíme eval set, děláme bezpečnostní review a modelujeme náklady dřív, než napíšeme víc kódu. Build je fáze, kde stabilizujeme — retry, timeouty, fallbackové řetězce, observabilita a guardrails přicházejí během vývoje. Operate je Deploy a vše po něm: canary nasazení, otestovaný rollback, on-call a kadence re-evaluací.

Než jakýkoli klientský AI build půjde živě, provedeme stejný go-live gate. Ověříme hard měsíční nákladový strop s alertem, politiku retry a timeoutů s deterministickým fallbackem, evaluaci, která musí projít, než přepneme flag, a jmenovaného on-call vlastníka. Pokud build neprojde všemi čtyřmi, nenasadí se.

Už jste funkci nasadili a chcete ji vytvrdit? Náš průvodce přidáním AI funkcí do vaší aplikace pokrývá samotný build; tento checklist je cesta k tomu, aby byla připravená na nasazení. Podívejte se na naši práci s AI integracemi, jak dostáváme AI funkce do produkce.

O autorovi

Mert Batur Gurbuz je spoluzakladatel Techsy.io, kde tým dodává AI agenty, automatizační systémy a voice/SDR pipeline pro B2B klienty. Studuje na University of Birmingham a píše o LLM tooling stacku, který tým Techsy skutečně používá v produkci.

Spoluzakladatel, Techsy.io — University of Birmingham. Spojte se na LinkedIn.

Často kladené otázky

Kdy je AI PoC připravené na produkci?

Když jiný tým dokáže systém provozovat, monitorovat a platit za něj bez osoby, která ho postavila: reálná produkční data, prošlá evaluace, nákladové stropy a alerty, retry a fallback a fázované nasazení s otestovaným rollbackem. Pokud to funguje jen když se autor dívá, je to demo.

Proč se většina AI PoC nikdy nedostane do produkce?

Z provozních důvodů, ne kvůli kvalitě modelu. Gartner v červenci 2024 předpověděl, že minimálně 30 % projektů generativní AI bude do konce 2025 opuštěno po fázi proof of concept, s odkazem na špatnou kvalitu dat, slabou kontrolu rizik, rostoucí náklady a nejasnou hodnotu. Zábradlí nebylo nikdy postaveno.

Jak dlouho trvá přesun AI PoC do produkce?

Pro jednu funkci plánujte zhruba 4 až 12 týdnů, často 90denní cestu: první měsíc na hardening (data, evaluace, bezpečnost, náklady), druhý měsíc na stabilizaci (retry, fallback, observabilita), třetí měsíc na nasazení (canary, rollback, vlastnictví). Složití agenti nebo přísný compliance to prodlouží.

Co AI demo vynechává a produkce potřebuje?

Demo ukáže happy path jednou. Produkce přidá to, co přeskočilo: nepořádná reálná data, kontrolu nákladů, rate limiting a retry, fallback pro výpadky, cíle latence pod zátěží, guardrails a plán rollbacku. Model je často stejný; chybí lešení kolem něj.

Jak kontrolovat náklady na AI/LLM před nasazením?

Vynásobte tokenový náklad jednoho typického běhu očekávaným objemem, pak nastavte hard cap a alert na 80 % rozpočtu. Snižte ho prompt cachingem, směrováním na levnější model, max-token limity a dávkováním. Nikdy nenasazujte, aniž byste znali náklad na běh.

Co je evaluační baseline a opravdu ji potřebuji?

Je to golden set 30 až 100 reálných vstupů s očekávanými výstupy, proti kterému hodnotíte každý build, s číselnou průchodovou hranicí, která gateuje nasazení. Ano: bez ní se regrese objevují ze support tiketů, ne z testovacího běhu. Je to nejlevnější pojištění na celém checklistu.

Co je graceful degradation (fallback) pro AI funkci?

Je to, co vaše funkce dělá, když je API modelu pomalé nebo nedostupné. Místo zaseknutí použije fallback: cachovanou odpověď, levnější model nebo deterministickou cestu. Nastavte timeout na p95 plus rezervu, pak ho aktivujte. Uživatel dostane mírně horší odpověď, ne chybu.

Mám produkční verzi stavět interně, nebo si najmout pomoc?

Stavte interně, pokud máte inženýry, kteří už LLM funkci nasadili a provozovali, a kapacitu na on-call. Najměte si pomoc, když je to váš první produkční AI systém, termín hoří nebo nikdo nevlastní provozní zátěž. Techsy to dělá, ale pokud váš tým zvládne go-live gate dobře, nechte to interně.

Shrnutí

Tři závěry. Funkční demo není produkční systém; jen dokazuje, že model zvládne úkol jednou. Většina AI funkcí, které uvíznou, umírá na provozních mezerách — náklady, rate limity, fallback — ne na kvalitě modelu. Řešení je projít těchto 12 bodů fázi po fázi (harden, stabilize, deploy) dřív, než přepnete flag. Udělejte nejdřív tu nudnou práci a den nasazení bude klidný. Pokud na to nechcete být sami, získejte bezplatnou konzultaci produkční připravenosti.