Hostování a zabezpečení AI infrastruktury

Kdo provozuje agenty, rychle zjišťuje, že model je tou nejjednodušší částí celé práce. Tento paper popisuje práci, která začíná potom: hostovat modely a agenty na vlastní infrastruktuře, izolovat je v síti, zabezpečit je a provozovat nepřetržitě; tak, jak LSA provozuje Linux infrastrukturu.

1. Teze

Jazykové modely si lze dnes stáhnout a agentní runtime jsou otevřený software: pořízení je vyřešeno. Nevyřešený je stav, který potom nastává: agent, který pracuje ve více krocích, se stává závislým na prostředí, na kterém běží. Potřebuje výpočetní výkon, který v nepřetržitém provozu neselže, síťovou cestu, která ho omezuje, protokoly, které doloží jeho kroky, a obnovu, která nastoupí i tehdy, když nikdo není po ruce.

Naše teze: agenti jsou produkční prostředí; zaslouží si stejnou péči, kterou linuxové týmy již léta investují do hardeningu, monitoringu a zálohování. Pro self-hostery a DevOps praktiky to není nová disciplína, ale další stupeň té jejich. Kdo dnes provozuje servery, zná patch cykly a nacvičil si obnovy, už má základ, na kterém agentní stack běží; nemusí přemýšlet jinak, jen rozšířit stávající.

Rozdíl mezi dobře vedeným agentním stackem a rizikem tedy nevzniká při výběru modelu, ale při hostování, v izolaci a v provozu. Přesně tam je domovem zbytek tohoto paperu.

Co tento paper je a co není

Tento paper není tutoriál, benchmark modelů ani právní poradenství. Je to provozní pohled: perspektiva týmu, který spravuje Linux servery, zabezpečuje prostředí a drží provoz nepřetržitě pod kontrolou. Regulační fakta uvádíme tam, kde se provozu přímo dotýkají; nenahrazují právní posouzení konkrétního případu. Kapitoly následují otázku, která v provozu přichází jako první: Kde to běží (kapitola 3), jak je to omezeno (kapitola 4), jak to zůstává v každodenním provozu zdravé (kapitola 5)?

2. Agenti jsou provozní zátěž

Od chatbota do produkčního prostředí

Chatbot odpovídá, když se někdo zeptá. Agent pracuje ve smyčce: plánuje kroky, volá nástroje, kontroluje mezivýsledky a pokračuje tak dlouho, jak úkol vyžaduje. Z pohledu infrastruktury znamená tento rozdíl konkrétně toto:

1. Nepřetržitý provoz: agenti běží v provozu 24/7; prostředí potřebuje stejné standardy jako každá produkční služba.
2. Volání nástrojů: každá smyčka vytváří přístupy k API, službám a datovým zdrojům; každý jednotlivý přístup musí být protokolován a omezitelný.
3. Využití zdrojů: inferencia modelu je výpočetní zátěž se špičkami; kapacita, která se plánuje, ne taková, která prostě zbyde.

K této provozní zátěži přibývá jedna, která se v pilotech ukazuje zřídka: vytváření řetězců. Jakmile na výstup jednoho agenta navazuje další agent, profil přístupů se umocňuje: každé spojení v řetězu je cesta, kterou je nutno omezovat, protokolovat a v případě potřeby přerušit. Co bylo ve fázi testování jedinou smyčkou, je v provozu malý svazek, se stejně mnoha cestami, jako kdybyste nasadili několik služeb najednou.

Co říkají tržní čísla o provozu

Tržní zprávy popisují situaci; pro odpovědné za provoz zní provozně: McKinsey ve své studii State of AI z března 2025 uvádí, že více než tři čtvrtiny respondentů nasadilo AI alespoň v jedné obchodní funkci. Gartner v tiskové zprávě z 25. června 2025 předpovídá, že do roku 2028 budou agentic schopnosti obsahovat zhruba 33 % aplikací podnikového softwaru, oproti méně než 1 % v roce 2024, a že alespoň 15 % běžných pracovních rozhodnutí bude do roku 2028 přijímáno autonomně agenty.

Druhá část téže prognózy patří do poctivého výpočtu: podle Gartneru bude do konce roku 2027 zrušeno více než 40 % projektů agentní AI, a to kvůli rostoucím nákladům, nejasnému podnikovému přínosu nebo nedostatečné kontrole rizik. Obě tvrzení platí současně: nasazení je široké, míra selhání vysoká. Pro infrastrukturní týmy má toto jediné jasné vyznění: důvody zrušení jsou provozní a právě proto spadají do vlastní odpovědnosti. Kontrola nákladů znamená plánovatelnou kapacitu (kapitola 3); kontrola přínosu znamená měřitelné pracovní procesy a jednoho vlastníka na agenta (kapitola 6); kontrola rizik znamená izolaci, protokoly a obnovitelnost (kapitoly 4 a 5). Každý tržní důvod zrušení je v tomto pohledu stavební kámen architektury, který lze postavit předem.

Agentní frameworky běží u několika našich zákazníků již aktivně. V prostředích, která stojí a drží, je rozdíl zřídka v modelu; je v základu, na kterém běží. Není náhodou, že rada ve stejném textu Gartneru zní: nasazovat agenty jen tam, kde je rozpoznatelná hodnota nebo ROI. Nečteme to jako prodejní zákaz, ale jako plánovací pravidlo; platí i pro infrastrukturu, kterou si k tomu postavíte.

Kde dnes agenti reálně nesou užitek, rozhoduje pracovní allodennost: opakované procesy, dobře vymezené, odolné vůči chybám: rutinní diagnostika, čtení protokolů, předběžné třídění incidentů, správa ticketů. V našem blogovém příspěvku o roli AI ve správě Linux serverů (AI ve správě Linux serverů) popisujeme provozní stránku téhož tématu: modely, které mohou dnes běžet lokálně, a monitoring, který k tomu patří.

3. Hostování: on-premise, colocation, cloud

Kde vaše modely žijí: rozhodujete vy

Existují tři smysluplná místa pro agentní stacky a žádné z nich nevyžaduje rozhodnutí z přesvědčení: on-premise na vašem hardwaru, colocation v datacentru podle vašeho výběru, nebo cloud region, který ovládáte. Rozdíl nespočívá v modelu, ale v datové cestě a rozsahu odpovědnosti: co se zpracovává na vašich strojích, neopouští váš perimetr; co běží v cloud regionu, podléhá jeho provozní smlouvě; obě cesty jsou legitimní, pokud zůstanou pod kontrolou protokoly, přístupy a obnova.

Sami provozujeme prostředí ve všech třech formách (on-premise v Mnichově, colocation ve Frankfurtu, cloud nativní v cloud regionu) a formu doporučujeme podle pracovní zátěže a potřeb ochrany dat, ne z principu. Výstavbu a migraci cloudových prostředí uvádíme v nabídce služeb; cloud regiony v EU jsou při potřebách ochrany dat standardním případem.

Dedikované GPU hostování v jádru znamená: kapacita za vašimi inferenčními workloaity stojí pod stejnou provozní disciplínou jako zbytek vašeho stacku; společně s vámi dimenzovaná, patchovaná, monitorovaná a restartovatelná, bez ohledu na to, kde GPU stojí. Konkrétní forma je tím závazně stanovena: dedikované GPU servery v našem vlastním datacentru a provoz GPU hardwaru ve vlastnictví zákazníka.

Lokální modely: provozní realita

Lokální modely mají nespornou výhodu: datová cesta zůstává krátká a ve vašem perimetru a stack škáluje podle vaší dimenze, ne podle využití. K tomu patří nezkreslená druhá polovina: lokálně neznamená automaticky bezpečně. I lokální stack zapisuje protokoly, drží kontexty v paměti a potřebuje model oprávnění; architektura rozhoduje, zda tato plocha zůstane malá. Co lokálně odpadá, je podíl poskytovatele na datové cestě; co lokálně přibývá, je vlastní provozní podíl.

Dimenzování je řemeslo, ne tajné vědění. Ukázkový výpočet (výslovně označen jako příklad): varianta 8B modelu Meta Llama 3.1 má podle model karty kontextové okno 128k; kvantovaná verze Q4_K_M v knihovně Ollama má velikost modelu zhruba 4,9 GB (8,03B parametrů). Takové modely běží na hardwaru, který self-hostery provozují stejně tak, přičemž praxe vyžaduje mnohem větší kalkulační prostor než samotná velikost modelu: operační paměť pro kontext a cache, úložný prostor pro protokoly a artefakty, vyvážení CPU a GPU podle typu úkolu. Kdo zná velikost modelů, může naplánovat i zbytek: aktualizace modelů přicházejí v cyklu, jak je přinášejí jiné softwarové aktualizace, a rollback na testovanou verzi není extra, ale součást balíku.

Velké modely v řízeném cloud regionu zůstávají doplňkovým pólem pro úkoly s vysokými nároky na kvalitu; mix se určuje podle úkolu, ne jako jednorázové rozhodnutí. Vektorová úložiště (vector stores) a komponenty retrieval běží v tomto obrazu jako každá jiná služba: verzované, zálohované, monitorované; nic z toho není „prostě embedding“.

Model-Serving a agentní runtime

Trvalý provoz agentního stacku se člení na dvě provozní komponenty:

1. Model-Serving: modely běží kontejnerizované (Docker, Podman, Kubernetes), verzované a restartovatelné; aktualizace modelů následují stejné vzory jako jiné softwarové aktualizace: testované, protokolované, vratné. Rollback cesty se neimprovizují, ale plánují.
2. Agentní runtime: agenti dostávají vlastní trať: sandboxy s credentials dle principu least privilege místo administrátorských klíčů; otevřené agentní frameworky (například OpenClaw nebo Hermes) jako orchestrace, která přistupuje k vašim systémům výhradně přes definované cesty. Každý agent má vlastní identitu, žádné sdílené klíče; co agent smí volat, stojí na místě přístupu, ne v orchestraci.

Obě komponenty sdílejí stejný princip: runtime rozhoduje, co agent dělá; vrstva oprávnění a přístupů rozhoduje, co smí. Jen tam jsou oprávnění auditovatelná, jen tam odebratelná.

4. Zabezpečení: síťová izolace a hardening

Segmenty, allowlisty, VPN přístup

Agentní stack patří do vlastních síťových segmentů, oddělených od vaší produkční dopravy, vašeho backoffice a všeho, co tam nemusí patřit. Vzory pro to jsou standardním DevOps řemeslem; pro agenty jsou povinností, ne volbou. Důvod leží ve vzoru volání: agenti ze své podstaty překračují hranice důvěry; berou kontext z jednoho systému, aby jednali v jiném. Bez segmentů a pravidel allowlistu je každé toto překročení hranice tichou povolenkou:

• ▸Vlastní síťové segmenty a pravidla firewallu pro agentní workloaity, sladěné s vámi
• ▸Agenti dosahují vašich systémů výhradně přes explicitní pravidla allowlistu, žádné otevřené cesty
• ▸Administrátorský přístup pouze přes VPN; správa agentů a ostatní admin provoz odděleny

Tato struktura vám dává dvě věci, které jsou jinak těžko dosažitelné: malou, vysvětlitelnou plochu útoku a schopnost v případě poruchy dohledat, čeho agent právě dosáhl. S segmentací se porucha mění z „někde ve svazku“ na „v agentním segmentu“: vymezitelná, zúžitelná, znovu uvolnitelná.

Secrets a credentials

Přístupové údaje nemají v agentním stacku místo v pracovním kontextu: žádné klíče v promtech, žádné společné admin přístupy, žádné v orchestraci natvrdo zapsané cesty. Tajemství se spravují jako tajemství a za běhu se injektují, neukládají se v kontextu agenta. Rotace patří k tomu: credentials, která se pravidelně mění, učiní zvládnutelným i případ, kdy se chování agenta stane podezřelým; odebrání oprávnění je pak administrativní úkon, ne demolice.

Hardening jako pracovní standard

Agentní prostředí si nezaslouží speciální nástroj, ale stejný standard hardeningu jako každý produkční server, s jedním dodatkem: hostují systém, který volá sám sebe. Osvědčilo se v našem každodenním provozu:

• ▸Orientace na CIS benchmarky, CVE patching a SSH hardening jako pevný standard
• ▸Limity rychlosti a zdrojů: agent, který se rozjede, nemůže strhnout své sousedy
• ▸Úplné logování akcí na agenta, napojené na kontrolu audit logů, protokolující i to, kdo oprávnění přiděluje nebo odebírá

Logová stopa je víc než doklad; je surovou podobou každé pozdější analýzy: debugging, audit, hlášení incidentů. Kdo ji vyžaduje od začátku, provozuje systém; kdo ji zavede až po prvním incidentu, popisuje do té doby experiment. K logové stopě patří i doba uchování: stanovte, jak dlouho zůstanou protokoly akcí k dispozici; ukládání nastavíme tak, aby zpětné dotazy nekončily ve vzduchu.

Držet to malé, zastavit to rychle

Dvě otázky rozhodují o bezpečnosti: jak málo smí agent? A jak rychle ho zastavíte? Odpověď na první zní least privilege: na agenta vlastní credentials, vázané na konkrétní úkol, odebratelné a vypršející. Odpověď na druhou zní úroveň kontroly: nevratné akce probíhají přes potvrzené kroky; každý proces agenta je zastavitelný; nouzové procedury se nacvičují, nejen dokumentují. Agent, kterého nikdo nepozoruje, není provoz; je to experiment, který čeká na svůj incident. A protože se oprávnění přidělují a odejímají, patří i tato předhistorie do protokolu: kdo, kdy a kterému agentovi jaké oprávnění dal, je nejpozději při zpětném dotazu po incidentu relevantní.

5. Provoz: monitoring, zálohy, obnova

Monitoring, který vidí smyčku

Agenti nespí; infrastruktura za nimi nesmí také. GPU hosty, model serving a agentní runtime zařazujeme do monitoringu (Grafana a Prometheus, vaše instance nebo naše), s metrikami pro dobu běhu, chybovost, volání nástrojů a kapacitu. Agentní stack má nad rámec klasických serverových metrik vlastní signály, které je nejdřív nutné vést: trvá volání nástroje déle než obvykle, hromadí se opakování, zpomaluje se smyčka, roste fronta u GPU; to vše jsou stavy, které vidíte, když je měříte, a přehlédnete, když je neměříte. Alarmy jdou do kanálů, které již používáte, místo zakládání nového ostrůvku. Proaktivní monitoring a alerting patří u každého nasazení do dodávky, ne jako doplněk.

Zálohy s testovanou obnovou

Modelové artefakty, stavy agentů a konfigurace potřebují promyšlené strategie zálohování a procesy obnovy, které skutečně byly testovány; ne „funguje to nejspíš“. Rozdíl oproti klasickým zálohám spočívá v tempu systémů: stavy agentů se mění během provozu; obnova proto musí odpovědět i na otázku, jakou konzistenci potřebujete: poslední potvrzenou akci, ne poslední zapsaný stav. Restore nasazený bez tréninku není restore, ale hledání.

Provoz pod povinnostmi hlášení a transparentnosti: bez právního poradenství

Nejsme právníci a v této kapitole nestojí žádné právní poradenství. Ale regulační situace je provozní situace a agentní stacky se jí dotýká konkrétně: podle směrnice NIS2 (směrnice (EU) 2022/2555) platí požadavky od 18. října 2024 a u významných incidentů vyžaduje článek 23 řetěz z včasného varování (neprodleně, v každém případě do 24 hodin), hlášení (do 72 hodin) a závěrečnou zprávu (do jednoho měsíce od hlášení). V těchto lhůtách lze nahlásit jen to, co vlastní systémy doloží: kdo byl zapojen, co bylo změněno, která data byla dotčena. Agentní stack bez úplného logování akcí vytváří přesně tu mezeru, která tyto lhůty činí nevyplnitelnými.

Týž princip, druhá vrstva pravidel: převažující část nařízení EU o AI platí od 2. srpna 2026, mezi nimi pravidla transparentnosti podle článku 50 (časová osa: Evropská komise, AI Act Service Desk). Sledovatelnost se tím stává požadavkem na návrh; logová struktura, kterou potřebujete pro incidenty, je tatáž, kterou požaduje transparentnost. Dva časové rámce, jeden základ: kdo vede protokoly tak, aby incidenty byly zodpovězeny v oknech NIS2, má tím již základ, který požadují povinnosti transparentnosti, bez provozování dvou oddělených log světů.

Pro posouzení vašich povinností v konkrétním případě si zajistěte právní poradenství. Naším dílem je provoz, který tyto požadavky činí splnitelnými: protokoly, které odpovídají na otázky, a procedury, které v případě poruchy nastoupí.

Provoz za tímto paperem nese stejné závazky, které publikujeme pro zbytek našeho stacku: dostupnost 24/7, cíl dostupnosti 99,9 % a reakční doba pod 1 hodinu. Nejsou to záměry vymyšlené pro tento paper; jsou to ukazatele, na kterých náš linuxový provoz již běží, beze změn převzaté pro agentní stacky a GPU hosty, protože za oběma stojí tentýž tým, tentýž monitoring a tytéž eskalační cesty. Nepřetržitý provoz je základ, který tato kapitola popisovala od začátku (monitoring, testovaná obnova, protokolované akce), a je základem, který váš agentní stack zdědí.

6. Od paperu ke spolupráci

Paper zůstává papírem, dokud ho někdo nepoužije na vaše prostředí. Spolupráce s LSA proto nezačíná výstavbou stacku, ale inventarizací, a po každém kroku následuje vaše rozhodnutí:

1. 1

   První kontakt

   Stručně popište, kde mají agenti ve vašich procesech pracovat nebo již pracují; přes formulář, e-mail nebo WhatsApp. Ozveme se a rozhodne se, zda je inventarizace správný vstupní bod.

2. 2

   Inventarizace

   Zaznamenáme, co běží (servery, sítě, přístupové cesty, datové toky, stávající automatizace) a z pracujícího provozu, ne z dialogu ve formuláři, vymezíme procesy, ve kterých může agent převzít víceúrovňovou práci. Kdo nám již svěřil správu svých serverů, má zde náskok: prostředí, historie a bezpečnostní úroveň jsou částečně známy; snímání nezačíná od nuly.

3. 3

   Doporučení a roadmapa

   Doporučení stacku, prioritizované případy užití a bezpečnostní rámec stojí písemně, včetně otevřené odpovědi, kde agenti (ještě) nesou užitek. Zdůvodnění vám vysvětlíme v briefingu; schvalování je vaše, ne naše.

4. 4

   Výstavba a provoz

   Po vašem schválení stavíme: GPU kapacitu, model serving, izolované runtime, monitoring a strategie zálohování; vše dokumentováno tak, aby váš tým nebo každý pozdější provozovatel mohl prostředí bezpečně uvést do provozu, a provozujeme to potom trvale. Váš tým má kdykoli plný přístup.

Vedou nás stejný měřítko, které Gartner klade ve stejné prognóze: agenty nasazovat jen tam, kde je rozpoznatelná hodnota nebo ROI. Inventarizace proto může skončit odpovědí, že agenti ve vašem prostředí dnes nepřinášejí přidanou hodnotu. Tato odpověď je výsledek, ne zanedbání, a je to nejlevnější okamžik, kdy to vědět.

Postup je záměrně postaven tak, aby každá fáze zanechala písemný mezivýsledek, který patří vám: po každé fázi můžete zastavit, posunout nebo pokračovat. Co se v žádném bodě tohoto postupu nestane: stack nevzniká bez vašeho písemného schválení; roadmapa je rozhodovací dokument, nikoli plná moc.

7. Závěr

Agenti přesouvají skutečnou práci na začátek projektu: než model startuje, rozhoduje základ. Hostování (on-premise, colocation nebo cloud, podle pracovní zátěže a potřeb ochrany dat), izolace (segmenty, allowlisty, oddělené runtime) a provoz (monitoring, protokolované akce, testovaná obnova). Disciplínu, kterou agentní stacky potřebují, dobře vedená linuxová prostředí již vlastní; doplňuje se o izolaci, logování akcí a správu oprávnění. Nic z toho nevyžaduje restart vaší praxe; je to tatáž praxe, rozšířená o nový stavební kámen.

Pokud chcete posoudit, kde agenti ve vašich procesech nesou užitek a co základ dnes již dovoluje: promluvte si s námi o vašem prostředí. Infrastrukturní briefing je bezplatný a rozhodnutí zůstává u vás.

Zdroje

1. Gartner, Inc.: "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027" (tisková zpráva, 25.06.2025); hlavní tvrzení: "Over 40% of agentic AI projects will be canceled by the end of 2027, due to escalating costs, unclear business value or inadequate risk controls"; dále v textu: "33% of enterprise software applications will include agentic AI by 2028, up from less than 1% in 2024"; "at least 15% of day-to-day work decisions will be made autonomously through agentic AI by 2028, up from 0% in 2024"; "Gartner recommends agentic AI only be pursued where it delivers clear value or ROI". Přímý fetch blokován; ověřeno přes snapshot webarchivu (20250926185809, web.archive.org, přístup 2026-11-01).https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027
2. McKinsey & Company: "The state of AI: How organizations are rewiring to capture value" (12.03.2025); hlavní tvrzení: "More than three-quarters of respondents now say that their organizations use AI in at least one business function." Přímý fetch bot-omezen (timeout); ověřeno přes snapshot webarchivu (20251229181420, web.archive.org, přístup 2026-11-01); přesné procentní hodnoty (78/72/55) se v textu archivu neobjevují, proto záměrně jako „více než tři čtvrtiny“.https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai-how-organizations-are-rewiring-to-capture-value
3. Směrnice (EU) 2022/2555 (NIS2), oficiální text EUR-Lex (CELEX 32022L2555); článek 41(1): "By 17 October 2024, Member States shall adopt and publish the measures necessary to comply with this Directive. … They shall apply those measures from 18 October 2024."; článek 23: včasné varování "within 24 hours of becoming aware of the significant incident", hlášení "within 72 hours", závěrečná zpráva "not later than one month after the incident notification". Přímý fetch blokován; ověřeno přes snapshot webarchivu ELI permalinku (20261005173546, web.archive.org, přístup 2026-11-01).https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng
4. Evropská komise: "Timeline for the Implementation of the EU AI Act" (AI Act Service Desk); milník 02 Aug 2026: "The majority of rules of the AI Act come into force and enforcement starts for applicable rules. Transparency rules (Article 50) start to apply." (živě přístup 2026-11-01).https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act
5. Meta: model karta Llama-3.1 (meta-llama/Llama-3.1-8B-Instruct, Hugging Face); 8B/70B/405B, kontextové okno "128k" (živě přístup 2026-11-01). Dále Ollama Library: llama3.1:8b-instruct-q4_K_M; "4.9GB", "model arch llama · parameters 8.03B · quantization Q4_K_M" (živě přístup 2026-11-01).https://huggingface.co/meta-llama/Llama-3.1-8B-Instructhttps://ollama.com/library/llama3.1:8b-instruct-q4_K_M
6. LSA živý inventář (vlastní fetches 2026-11-01): věta o prostředí na všech třech titulních stranách (DE: „Ob On-Premise in München, Colocation in Frankfurt oder Cloud-Native in [Anbieter-Region, podle kopírovací pravidla (d) z 2026-11-01 nepřevzato]: Wir passen uns Ihrer Sprache und Ihrem Stack an.“); řádky výkonů na /service-support („Sicherheitshärtung & Audits CIS-Benchmarks, CVE-Patching, SSH-Härtung, Audit-Log-Review“; „Netzwerk & Firewall Firewall-Konfiguration, VPN-Setups“); řádek tech stacku („Linux · Nginx · systemd · Docker/Podman · Kubernetes · Ansible · Terraform · [název poskytovatele, pravidlo (d)] · Grafana · Prometheus“); cloud karta („[názvy poskytovatelů, pravidlo (d)], Aufbau und Migration von Cloud-Umgebungen“); AI blogové příspěvky živě na všech třech doménách (.de slug ai-transforming-linux-server-admin, .com slug stejný, .cz slug jak-ai-meni-spravu-linux-serveru).