Bílý dům pustil AI na vládní weby. Podívejte se, co z toho vzniklo

Představte si, že vám doktor řekne "za týden vám AI přepíše celou kartotéku, ušetříme miliony". Přesně tohle se teď děje s americkými vládními weby. Trumpova administrativa spustila plán na kompletní redesign všech .gov domén pomocí umělé inteligence — a první výsledky vypadají, jako by je navrhoval opilý stážista s přístupem k Midjourney. Rozbité navigace, nečitelný kontrast textu, formuláře co mizí uprostřed vyplňování. Vítejte v roce 2026, kdy "AI-first" znamená hlavně "chyba-first".

Není to jen estetický problém. Je to bezpečnostní problém. A je to problém, který se týká i evropských institucí, včetně těch, co spravují energetickou infrastrukturu.

Co přesně se v USA děje

General Services Administration (GSA), agentura co spravuje federální IT, dostala mandát: zredukovat náklady na weby o desítky procent a nasadit AI nástroje na generování obsahu, designu i kódu napříč tisíci vládními doménami. Podle interních dokumentů, které unikly novinářům, mělo jít o "AI-augmented modernizaci" — v praxi to znamenalo nasazení no-code AI generátorů typu Vercel v0, Lovable nebo interních nástrojů postavených na GPT a Claude API, bez pořádného code review.

Výsledek? Weby sociálního zabezpečení s automaticky vygenerovaným CSS, které na mobilu zobrazuje text bílým písmem na bílém pozadí. Formuláře pro žádosti o dávky, kde AI "opravila" validaci polí tak, že rodná čísla procházejí i s písmeny. A nejhorší — několik agentur nasadilo AI-generovaný kód do produkce bez penetračního testu, protože termín byl "příští pondělí" a rozpočet na security audit zmizel ve škrtech.

Tohle není hypotetické strašení. Podobné případy se dějí i mimo USA — ostatně stejný vzorec (rychlost před bezpečností) vidíme i u firem, co nasazují AI do kritické infrastruktury bez auditu. A když se bavíme o kritické infrastruktuře, patří sem i energetika.

Proč je to bezpečnostní katastrofa, ne jen ošklivý design

Rychle vygenerovaný kód od LLM má jednu vlastnost, kterou manažeři rádi ignorují: model neví, co je citlivé. GPT-4.1 nebo Claude vám krásně napíšou formulář na žádost o dávky, ale nezeptají se, jestli má být rate-limitovaný proti brute-force útoku, jestli má input sanitizaci proti SQL injection, nebo jestli session token vůbec expiruje.

Bezpečnostní firma Truffle Security zveřejnila analýzu 40 AI-generovaných vládních prototypů (verze zveřejněná pod FOIA žádostí) a našla: - 12 z nich mělo API klíče natvrdo v client-side JavaScriptu - 8 nemělo žádnou CSRF ochranu na formulářích s citlivými daty - 3 weby posílaly hesla v plaintextu přes HTTP redirect chain

To není selhání AI modelu. To je selhání procesu — nikdo mezi "AI vygenerovala kód" a "kód běží v produkci" nepostavil bránu s lidským review. Přesně tenhle vzorec varuje i NIST ve svém frameworku pro AI risk management: generativní AI umí produkovat funkční kód rychleji než kdy dřív, ale "funkční" a "bezpečné" jsou dvě různé metriky.

Pro firmy a obce v ČR je poučení jasné: pokud uvažujete o AI nástrojích pro vlastní web nebo interní systém (třeba dashboard pro monitoring spotřeby energie), nikdy nepřeskakujte code review jen proto, že "to napsala AI, takže je to hotové". Ověřený proces vypadá takto: AI generuje → statická analýza (Semgrep, CodeQL) → lidský reviewer → penetrační test před produkčním nasazením.

Gemma 4 a hlasová AI: kam se ubírá vývoj

Zatímco vládní IT řeší průšvihy, komerční AI scéna jede dál. Hugging Face spolu s Cerebras Systems oznámili nasazení Gemma 4 (nástupce Googlího open-weight modelu) pro real-time hlasovou konverzaci s latencí pod 150 milisekund — díky Cerebras Wafer-Scale Engine, čipu, co má na jednom waferu 900 000 jader.

Proč je to zajímavé i mimo AI bublinu? Protože ukazuje rozdíl mezi promyšleným nasazením AI a tím, co se stalo u .gov webů. Cerebras a Hugging Face investovali měsíce do optimalizace inference, kvantizace modelu (Gemma 4 běží v INT4 s minimální ztrátou přesnosti) a testování na reálném provozu, než cokoliv pustili ven. Model je navíc dostupný jako open-weight na Hugging Face, takže si ho můžete stáhnout a spustit lokálně přes Ollama (`ollama pull gemma3` — Gemma 4 weights se do Ollama registry dostávají postupně) nebo přes llama.cpp na běžné herní grafické kartě s 12GB VRAM.

Cena za API přístup k hostovanému Gemma 4 přes Cerebras Cloud se pohybuje kolem 0,10 USD za milion vstupních tokenů — řádově levněji než GPT-4.1, což z něj dělá zajímavou volbu pro startupy, co chtějí stavět hlasové asistenty (třeba pro zákaznickou podporu energetických firem) bez měsíčních účtů v tisících dolarů. Pokud stavíte něco podobného pro monitoring FVE nebo bateriového úložiště, kde chcete hlasové rozhraní pro techniky v terénu, tohle je aktuálně nejlevnější cesta k latenci srovnatelné s telefonátem.

ScarfBench: benchmark, co ukazuje limity AI agentů

Třetí zajímavost týdne: nový benchmark ScarfBench testuje, jak si AI agenti (Claude Code, Cursor, GitHub Copilot Workspace, Devin) vedou při migraci enterprise Java frameworků — třeba přechod ze Spring Boot 2 na Spring Boot 3, nebo z Java 8 na Java 21 s odstraněním deprecated API.

Výsledky nejsou moc povzbuzující. Nejlepší agent (podle zveřejněných čísel Claude-based agentní pipeline) zvládl samostatně dokončit jen 34 % migračních úkolů bez lidského zásahu. Zbytek skončil buď kompilační chybou, nebo — což je horší — kódem, co se zkompiluje, ale za běhu vyhazuje výjimky na edge case, které testovací sada nepokryla.

Proč to zmiňuji vedle vládních webů? Protože stejná agentura GSA, co teď redesignuje .gov weby přes AI, má v plánu i modernizaci starých COBOL a Java backendů, na kterých běží třeba výplaty sociálního zabezpečení. Pokud nejlepší dostupné nástroje zvládnou jen třetinu úkolů samostatně, nasazení "na férovku" bez lidského dohledu je recept na katastrofu srovnatelnou s tou, co vidíme na frontendu. ScarfBench je dobrá připomínka, že AI agenti jsou skvělý multiplikátor produktivity zkušeného vývojáře, ale mizerná náhrada za něj.

Co si z toho vzít pro vlastní projekty

Pokud spravujete web nebo systém, kde jde o peníze nebo citlivá data — třeba portál pro sdílení elektřiny, fakturační systém, nebo dashboard s daty ze spotových trhů — tady je praktický checklist, co se z amerického fiaska dá naučit:

Nikdy nepouštěj AI-generovaný kód přímo do produkce. Vždy mezikrok: statická analýza + lidský review + test na stagingu.
Rate-limiting a input validace nejsou volitelné. AI modely je často "zapomenou", protože nejsou explicitně v promptu.
Testuj s reálnými daty, ne s ukázkovým JSON. Diakritika, dlouhá jména, edge cases v rodných číslech — AI generátory tohle běžně přehlédnou.
Otevřené modely (Gemma, Llama, Mistral) dávají kontrolu nad tím, co se děje s daty — na rozdíl od closed-source API, kde nevíte, jak přesně se prompt zpracovává. Pro cokoliv s osobními nebo citlivými daty je self-hosted řešení přes Ollama nebo vLLM bezpečnější volba.
LoRA fine-tuning na vlastních datech (třeba historii podpory) je levnější a bezpečnější než posílat citlivá data do třetí strany. Trénink LoRA adaptéru na 7B modelu vyjde na desítky dolarů výpočetního času na RunPod nebo Vast.ai.

Tohle platí i pro energetický sektor. Pokud provozujete FVE, bateriové úložiště nebo agregujete flexibilitu, vaše monitorovací systémy jsou stejně tak kritická infrastruktura jako vládní portál — jen o tom nikdo nemluví, dokud se něco nestane. Platforma pro sdílení elektřiny jako SmartEnergyShare musí splňovat podobné nároky na bezpečnost jako státní systémy, protože pracuje s citlivými daty o spotřebě a výrobě.

Jak se to týká českého energetického sektoru

Zní to jako vzdálený americký problém, ale paralela je blízko. ERÚ i OTE postupně digitalizují své systémy a tlak na "AI modernizaci" přijde i sem — ostatně evropská Komise už tlačí na AI Act compliance a zároveň na digitalizaci veřejné správy. Když se dostaneme do fáze, kdy někdo řekne "necháme AI přepsat portál pro hlášení výroby elektřiny", chceme mít z amerického případu poučení, ne opakovat stejné chyby.

Pro firmy, co uvažují o sdílení elektřiny pro firmy nebo chtějí zapojit IoT monitoring do svého provozu, platí totéž co pro vládní agentury: AI vám ušetří týdny práce na frontendu a boilerplate kódu, ale bezpečnostní audit a penetrační test nikdy nesmí odpadnout jen proto, že "to napsal Claude". Podobně jako u dashboardu pro obchodování s flexibilitou, kde chyba v kódu může znamenat špatně odeslaný signál do sítě — to není kosmetická vada, to je reálné riziko.

Pokud chcete vidět, jak vypadá promyšlená (ne AI-narychlo-vygenerovaná) implementace energetického monitoringu, mrkněte na ShareElectric.cz, kde rozebírají technické detaily komunitní energetiky, nebo na Sdílenienergie.info, pokud vás zajímá legislativní rámec sdílení energie v ČR.

Závěr: AI je nástroj, ne alibi

Trumpova administrativa se dopustila klasické chyby — spletla si "AI umí generovat kód rychle" s "AI umí generovat bezpečný a použitelný kód rychle". Tohle jsou dvě naprosto odlišné věci a rozdíl mezi nimi stojí buď pár týdnů navíc na code review, nebo miliony dolarů na sanaci úniku dat po nasazení.

Můj odhad na příští rok: uvidíme minimálně jeden vážný bezpečnostní incident na .gov doméně, co bude přímo trasovatelný k AI-generovanému kódu bez review. A stejně tak si troufám tvrdit, že open-weight modely jako Gemma 4 postupně vytlačí closed-source API tam, kde jde o citlivá data — prostě proto, že self-hosting dává kontrolu, kterou regulátoři budou čím dál víc vyžadovat. Kdo chce experimentovat s podobnými nástroji ve vlastním energetickém nebo firemním provozu, ať začne u vysvětlení, jak funguje sdílení elektřiny — a teprve pak přidává AI vrstvu navrch, ne obráceně.

Zdroje

Obchodujete s batteriovými úložišti nebo hledáte partnera pro flexibilitu a day trading elektřiny? SmartEnergyShare nabízí kompletní řešení pro BESS projekty od 50 do 250 kW — obchodování flexibility, SVR služby a IoT monitoring. Zjistěte víc →

Další články na toto téma najdete na: SdileniEnergie.info SmartEnergyShare není dodavatel elektřiny: Jak funguje el... Vice o renesance jaderné