Nová generace aplikací v provozu: Čtyři věci, které byste měli vyřešit dříve, než vám přijdou do správy.

Aplikace se mění méně, než myslíte. Runtime kontrakt se mění víc, než čekáte.

Aplikace dnes přicházejí do provozu dvěma novými cestami. První - často přehlížená - jsou běžné aplikace bez jakékoliv AI komponenty v runtime, ale postavené v agentické pipeline, kde několik agentů napíše kód, vybere knihovny a sestaví build. Z pohledu provozu vypadá výsledek jako každá jiná aplikace, ale jak vznikla, mění některá rizika. Druhou cestou jsou aplikace, které mají AI jako runtime komponentu - volají model při zpracování requestů.

Tento článek se týká obou kategorií. Tři ze čtyř témat platí pro obojí, FinOps se týká primárně té druhé skupiny, kde inference znamená skutečné peníze za každý request na model.

Záměrně se nebavíme o čistě „vibe-codovaných" aplikacích, které vznikají mimo firemní ekosystém. V prostředí s integrací, governance a auditem by měly být okrajové.

Tyto čtyři body jsou:

• Většina problémů není v modelu, ale v životním cyklu.
• Bez předávacího balíčku se každý incident stává vaším.
• Bezpečnostní rizika jsou převážně provozní, ne kryptografická.
• U aplikací s AI integrací je inference nový OPEX bez stropu - pokud strop nepostavíte vy.

1) Problém je v životním cyklu, ne v modelu

Když se mluví o AI v produkci, debata se rychle stočí k volbě modelu, kvalitě výstupu a halucinacím. To jsou otázky, které řeší vývoj. Provoz řeší něco jiného: co se stane, až tu aplikaci bude chtít někdo upravit za dva roky, a původní vývojáři už ve firmě nebudou.

A přesně tady se obě kategorie aplikací potkávají.

Pro aplikace postavené agentickou pipeline je hlavním rizikem původ závislostí. Agent dnes umí vybrat knihovnu, kterou nikdo z týmu nikdy nečetl. Za dva roky, když přijde 0-day CVE na tuto knihovnu, otázka „které naše image to obsahují" musí mít odpověď v minutách, ne v týdnech. Jediný způsob, jak to mít, je SBOM (CycloneDX nebo SPDX) generovaný v každém buildu a uložený jako artefakt vedle image. Bez něj se rebuild pro mitigaci 0-day stává pátráním — a SRE tým, který kód udržuje při životě bez původních autorů, to bude muset řešit.

Pro aplikace s AI v runtime přibývá navíc lifecycle samotného modelu. Aktualizace modelu je svým dopadem release aplikace: mění chování, mění latenci, může rozbít navazující systémy. Přesto se v praxi často děje jako konfigurační změna, bez change recordu a bez rollback testu.

Co je potřeba narovnat:

• Verze modelu se pinuje v konfiguraci nasazení. Nikdy latest.
• Hash vah modelu se ověřuje při stažení i při startu kontejneru.
• Rollback postup je dokumentovaný a otestovaný, ne hypotetický.
• Triggery rollbacku jsou definované předem: například behaviorální drift přes threshold, překračované SLO na latence (pozor, model latencí má jinou statistickou distribuci, než na jako jsme v provozu tradičně zvyklí), selhání prompt regresních testů, bezpečnostní advisory na váhy modelu.

V obou případech platí stejné: vyjednejte si disciplínu dřív, než aplikaci dostanete do správy - všechny náklady neřešení dopadnou na provoz.

2) Předávací balíček není volitelný

Pokud něco není v předávacím balíčku, stane se to vaším incidentem.

V klasické aplikaci je tolerance pro chybějící artefakty vyšší — logiku kódu vývojáři znají, závislosti vývojář řešil, chování je (pro běžný kód) víceméně deterministické. Aplikace vzniklá agentickou pipeline tuto toleranci snižuje (kód a závislosti existují, ale znalost rozhodnutí za nimi často chybí). Aplikace s AI v runtime ji ztrácí úplně - bez specifikovaných hranic agenta nevíte, co smí a co nesmí; bez katalogu failure modes nevíte, co je incident; bez prompt regresních testů neumíte říct, jestli je drift po update modelu závadou nebo zlepšením.

Minimální předávací balíček pro předání aplikace do provozu by měl obsahovat alespoň toto:

• Architekturní artefakty. Hranice agenta - co smí číst, co smí měnit, co je explicitně zakázáno. Mapa závislostí na další systémy a datové toky s klasifikací citlivosti. Seznam mimofunkčních požadavků obsahující SLO na latence, token budgety a dostupnostními cíli.
• Operační artefakty. Katalog failure modes (typicky agent loop, halucinace, selhání toolu, timeout). Krok-po-kroku otestovaný rollback postup pro model i pro aplikaci. Eskalační strom včetně bodů, kdy se má volat human-in-the-loop.
• Testy a compliance. Prompt regresní test suite spustitelný v CI, deterministický baseline threshold, SBOM uložený s image, schéma a retenční politika audit logu. Agenti občas ignorují základní bezpečnostní nastavení, testování tak musí být velmi kvalitní a vyčer

Toto není luxus — je to podmínka udržovatelnosti v okamžiku, kdy vývojový tým aplikaci opustí. A opustí ji vždycky.

3) Bezpečnost je převážně provozní disciplína

Většina rizik, která dopadnou na Ops, není o kryptografii ani o jailbreak technikách. Jsou to provozní problémy s analogiemi, které všichni důvěrně známe.

Prompt injection je svým mechanismem ekvivalent SQL injection — škodlivý vstup přebírá kontrolu nad agentem. Mitigace je provozní: validace vstupů, sandboxing výstupů, least-privilege přístup k nástrojům. Jeden tool scope per bounded context, žádný master agent s přístupem ke všemu. To pokrývá zároveň riziko nadměrných oprávnění agenta, což znamená velký blast radius.

Mezery v audit logu mohou být regulatorní problém. V takovém případě jednoznačně dává smysl logování prompt + response, a to s verzí modelu a timestampem. Standardní app logging nemusí stačit.

Integrita vah modelu - ověřujte hash při stažení a startu, používejte safetensors formát místo pickle.

A ten případ rebuildu pro 0-day mitigaci, který zazněl výše? Je to primárně bezpečnostní scénář a platí pro obě kategorie aplikací — agentická pipeline pro produkční kód i runtime AI integrace zavádějí závislosti rychleji než kdy dřív.

OWASP Top 10 pro LLM aplikace by dnes měl být povinnou četbou pro každý tým, který takovou aplikaci provozuje.

4) FinOps: nový OPEX bez stropu, pokud ho nepostavíte vy

Tato sekce platí pro aplikace, které volají AI v runtime. U aplikací postavených agentickou pipeline FinOps disciplíny pokrývají standardní cloud cost management — inference v produkci tam neplatíte.

Tam, kde aplikace ale inferenci skutečně volá, jsou tři důvody, proč to není teoretické cvičení:

• Per-token model je variabilní OPEX bez stropu. Bez kvóty dokáže agent loop za noc vygenerovat účet, kterého si bezesporu všimnete.
• Agentic smyčky jsou násobitel tokenů. Jeden uživatelský požadavek může spustit desítky interních volání modelu. Bez měření per agent / per bounded context nemáte šanci provádět smysluplný chargeback.
• Ceny pravděpodobně porostou. Tlak energetické kapacity, HW investic a poptávky směřuje prémiové modely k více jak dvojnásobnému zdražení do 2027.

Praktické minimum

• AI gateway jako jediný vstupní bod pro veškerou inference. Bez ní nemáte ani viditelnost, ani vynucování kvót.
• Token budget per agent, ne jen per aplikace.
• Tagovací konvence (tým / bounded context / prostředí) v každém requestu, jinak nebude fungovat chargeback.

Efektivní využití inference dnes je strategická výhoda zítra. Pokud chargeback nefunguje, neefektivitu nikdy neuvidíte.

Co si odnést

Aplikace, která vám přijde do správy, vypadá jako každá jiná. Kubernetes, kontejnery, HTTP API. Co se mění, není stack — mění se runtime kontrakt: závislosti vybrané bez auditní stopy, model jako verzovaná závislost, předávací balíček jako podmínka udržovatelnosti, bezpečnost jako provozní disciplína a u AI-integrovaných aplikací inference jako OPEX, který si žádá svou gateway.

Pokud máte dnes možnost ovlivnit, jak vám tyto aplikace budou předávány, je to ten správný okamžik to udělat.