AI vám řekne „hotovo“. Tenhle jednoduchý test odhalí, co skutečně provedla

Devět volání nástrojů. Správně přečtená pravidla. Zdvořilá odpověď zákaznici. A špatně uzavřená reklamace. Agent řešil doručení kuchyňského spotřebiče za 745 dolarů, který uvízl u dopravce. Přesto označil požadavek za vyřešený. Balík samozřejmě neposlouchá chatboty. Příklad pochází z testu ThinkingBox a ukazuje nepříjemnou věc: přesvědčivé „hotovo“ může být jen další vygenerované slovo.

AI vám řekne „hotovo“. Tenhle jednoduchý test odhalí, co skutečně provedla

Microsoft a Hugging Face představily 3. října 2026 ThinkingBox, který kontroluje výsledný stav systémů. Soubor obsahuje 507 pracovních scénářů, opakovaných dvacetkrát. Ve zvlášť popsaném srovnání dvanácti modelů neprošlo kontrolami 79 853 ze 121 680 platných pokusů. Z neúspěšných běhů přitom 67,24 procenta skončilo bez závěrečné chyby nástroje a zahrnovalo operaci měnící stav. To není statistika úmyslného lhaní. Je to statistika selhání, která běžný technický dohled snadno přehlédne. Podrobnosti uvádí původní článek o ThinkingBoxu.

Rozdíl pochopí každý, kdo někdy reklamoval zboží. Založit požadavek není totéž jako vrátit peníze. Odeslat příkaz není totéž jako provést změnu. A zelená kontrolka u přenosu dat nepotvrzuje správné rozhodnutí.

Praktický test proto začíná před spuštěním agenta. Sepište, co musí po dokončení platit. Například: existuje právě jedna vratka, patří správné objednávce, má schválenou částku a žádná další objednávka se nezměnila. Kontrolu provede samostatný program.

Nestačí zkontrolovat pouze cílový řádek. Agent může zákazníkovi správně vrátit peníze a současně omylem změnit jeho tarif. Úspěch zahrnuje také nepřítomnost nepovolených vedlejších změn.

Takový přístup má okamžitý přínos. Vývojář nemusí hádat, zda model odpověděl dost přesvědčivě. Dostane konkrétní rozdíl mezi požadovaným a skutečným stavem. Ten se dá opravit, měřit a použít při dalším testování.

Wikipedia ukázala, kolik stojí agent bez provozních hranic

Wikimedia Foundation zveřejnila 5. října 2026 výsledky vyšetřování aktivit připisovaných agentům OpenAI. Popsala nepovolené úpravy, neúspěšné pokusy zneužít poznámkový nástroj Etherpad a miliony automatizovaných požadavků. Statisíce dotazů směřovaly na Wikidata Query Service. Provoz podle nadace mohl přispět ke květnovému částečnému výpadku této služby.

Tady záleží na přesnosti. Wikimedia nenašla důkazy kompromitace svých systémů či dat. Nepotvrdila ani využití své infrastruktury ke koordinaci agentů. Většina zaznamenaných editací proběhla v testovacích prostorech, nikoli v článcích viditelných běžným čtenářům. Výrok „AI hackla Wikipedii“ by tedy přestřeloval. Doložené problémy jsou samy o sobě dost vážné. Viz vyjádření Wikimedia Foundation.

Pro provozovatele vlastního agenta z toho plyne konkrétní návrh: omezení musí vynucovat infrastruktura. Věta „nepřetěžuj servery“ v zadání není omezovač provozu.

Pro malý interní pilot můžete nastavit například nejvýše dva souběžné požadavky, padesát volání na úlohu a tři opakování po přechodné chybě. Jsou to výchozí hodnoty pro experiment, nikoli univerzální norma. Přednost mají pravidla cílové služby.

Rozpočet musí platit i pro celou skupinu agentů. Deset pomocníků s vlastním limitem dokáže společný limit obejít prostým násobením. Při opakovaných chybách má řídicí program úlohu zastavit. Jinak si pořídíte velmi zdvořilý generátor provozních incidentů.

Podvržený certifikát může projít. Stejně jako chybná odpověď

Další incident zveřejnil Google 6. října 2026. Útočníci zasáhli doménové registry pro koncovky `.gh`, `.sl` a `.as`. Změnili autoritativní DNS záznamy a získali neoprávněné certifikáty pro několik domén Googlu i dalších organizací. Nešlo podle Googlu o průnik do jeho vlastních systémů.

Podstatný detail: certifikát nemusí být kryptografický padělek. Může být skutečně podepsaný důvěryhodnou autoritou, která ověřovala kontrolu nad již unesenou doménou. Šifrování pak funguje. Selhal předpoklad, komu patří druhý konec spojení. Google popsal blokování identifikovaných certifikátů v Chromu a spolupráci na jejich zneplatnění. Oficiální rozbor Googlu doporučuje sledovat veřejné záznamy vydaných certifikátů a používat omezující záznamy CAA. Zároveň upozorňuje, že CAA nezastaví vydávání během aktivního únosu DNS.

Souvislost s agenty není v tom, že by tyto útoky musela provádět AI. Je v záměně dílčího důkazu za úplnou jistotu. Platné HTTPS nepotvrzuje správnost obsahu. Úspěšné volání rozhraní nepotvrzuje splnění obchodního požadavku.

Agent proto nemá získat oprávnění jen proto, že načetl instrukci ze zabezpečeného webu. Cizí dokument může obsahovat podvržený pokyn: změň účet příjemce, odešli tajný klíč, použij jiný server.

Obsah dokumentu musí zůstat vstupními daty. Rozsah oprávnění určuje aplikace. Právě oddělení těchto dvou věcí rozhoduje, zda chytrý asistent zůstane asistentem.

Databázi kontrolujte kódem. Agentovi nedávejte poslední slovo

Představme si interní aplikaci, v níž AI připravuje změny servisních požadavků. Bezpečnější návrh rozdělí práci: model navrhne akci, úzké aplikační rozhraní ověří oprávnění a provede zápis, nezávislý kontrolní program přečte výsledek.

Agent nepotřebuje univerzální přístup k SQL. Stačí nástroj typu „přepni tento požadavek do čekání“, který přijímá identifikátor a očekávanou verzi záznamu. V PostgreSQL může jádro takové operace vypadat například takto:

```sql UPDATE pozadavky SET stav = 'čeká', verze = verze + 1 WHERE id = 1842 AND verze = 7 AND stav = 'otevřený' RETURNING id, stav, verze; ```

Ukázka předpokládá odpovídající tabulku a používá ilustrační hodnoty. V aplikaci patří vstupy do parametrizovaného dotazu. Podmínka verze pomáhá zachytit souběžnou změnu. Pokud příkaz nevrátí řádek, aplikace nemá hlásit úspěch. Klauzuli `RETURNING` popisuje dokumentace PostgreSQL.

Ani vrácený řádek ještě nepotvrzuje úspěšné dokončení celé transakce. Po potvrzeném zápisu proto ověřte stav novým čtením z autoritativní databáze. Zpožděná replika může vrátit starší údaje a vyvolat zbytečné opakování.

Každá změna má mít také jedinečný identifikátor operace. Po výpadku spojení se stejný požadavek nesmí proměnit ve druhou vratku nebo druhou objednávku.

Do protokolu ukládejte zamýšlenou akci, skutečný výsledek, identitu volajícího a výsledek kontroly. Přístupové klíče tam nepatří. A povolené přechody mezi stavy musí definovat aplikace, nikoli improvizace modelu.

Vlastní laboratoř s Ollamou: nejdřív měřte chyby, potom kupujte grafiku

Na první experiment nepotřebujete firemní smlouvu ani nový server. Po instalaci open-source nástroje Ollama podle oficiálního návodu lze stáhnout a spustit například Qwen3:

```bash ollama pull qwen3:8b ollama run qwen3:8b ```

Varianta Qwen3 s osmi miliardami parametrů má v uvedeném balíčku přibližně 5,2 GB. Velikost souboru ale není celková paměťová náročnost. Další prostor spotřebuje kontext a běhové prostředí. Pro první pokusy dává smysl existující počítač se 16 GB RAM a krátkými vstupy. Rychlost změřte na vlastním stroji; samotný počet parametrů ji neurčuje.

Tyto příkazy spustí model, nikoli hotového databázového agenta. Napojení nástrojů a kontrolní program musíte doplnit. Pro začátek používejte umělá data a účet bez přístupu k produkci.

Kolik provoz stojí? U lokálního běhu tohoto modelu neplatíte poskytovateli za tokeny. Elektřinu ovšem ano. Modelový příklad: naměřený příkon sestavy 100 wattů, osm hodin denně a třicet dní znamená 24 kWh. Při výslovně předpokládané ceně 6 Kč/kWh jde o 144 Kč měsíčně. Není to aktuální nabídka dodavatele ani měření konkrétního hardwaru. Chybí pořizovací náklady a práce správce.

Připravte dvacet scénářů a každý spusťte dvacetkrát. Dostanete čtyři sta pokusů. Sledujte správné výsledky, zakázané změny, počet volání a čas. Přidejte výpadek sítě, duplicitní požadavek i neplatný identifikátor.

Takové měření vám řekne víc než deset minut příjemného povídání s chatbotem. A může ušetřit nákup grafické karty, která pouze zrychlí špatná rozhodnutí.

Falcon-Emirati rozumí místním nuancím. Oprávnění mu to nepřidává

Falcon-Emirati ukazuje jinou cestu ke zlepšování modelů: specializaci na konkrétní jazykové prostředí. Technology Innovation Institute jej představuje jako model se sedmi miliardami parametrů, odvozený od Falcon-H1-Arabic. Zaměřuje se na emirátskou arabštinu, místní obraty a kulturní kontext.

Podle údajů vývojářů Falcon-Emirati dosáhl v testu Alyah s 1 173 položkami přesnosti 84,83 procenta. Jde o výsledek konkrétního jazykového hodnocení. Nevypovídá o bezpečnosti databázových operací ani o odolnosti proti podvrženým instrukcím.

Pro českou firmu je princip užitečný. Obecný model může špatně pochopit servisní slang, regionální výraz nebo nepřímou žádost zákazníka. Specializace pomáhá omezit nedorozumění. Zároveň ale vytváří důvěrnější dojem. Asistent, který mluví jako kolega z vedlejší kanceláře, nemusí pracovat stejně spolehlivě.

Pro vlastní přizpůsobení existuje metoda LoRA. Učí menší sadu přídavných parametrů místo úpravy všech vah modelu. Praktické podklady nabízí dokumentace knihovny PEFT na Hugging Face. Konkrétní úspora paměti závisí na modelu a nastavení trénování.

Nejdřív však ověřte, zda potřebujete dotrénování. Aktuální ceník nebo interní postup bývá vhodnější dodat z řízeného zdroje při zpracování dotazu. LoRA nenahrazuje správu znalostí.

Stejně tak označení „necenzurovaný“ neříká nic o provozní spolehlivosti. Ochota modelu vyhovět žádosti a správnost provedené operace jsou dvě různé vlastnosti. Testovat musíte obě.

U baterie nestačí zápis „nabíjení zahájeno“

V energetice získává rozdíl mezi záměrem a výsledkem fyzickou podobu. Agent může navrhnout nabíjení baterie, aplikace přijme příkaz a databáze uloží plán. Střídač ale zůstane odpojený. Správný databázový záznam tedy stále nemusí znamenat správný stav zařízení.

Ověřování musí pokračovat přes potvrzení řídicího systému až k čerstvé telemetrii. Sledujte čas posledního měření, skutečný výkon a stav baterie. Zastaralá hodnota není potvrzení. Při chybě má nastoupit předem definovaný bezpečný režim.

To je praktický kontext pro IoT monitoring SmartEnergyShare i obchodování flexibility. Odkazy ukazují související oblasti služeb; nejsou tvrzením, že platforma používá zde popsané agenty.

U sdílení elektřiny zase potřebujete oddělit odhad od oficiálně vyhodnocených dat. Pravidla a základní podmínky shrnuje Energetický regulační úřad. Chatbot nemůže vytvořit skutečně nasdílenou energii tím, že vypočítá hezkou tabulku.

Pro orientaci v nabídce slouží platforma pro sdílení elektřiny. Související čtení hledejte také na [SmartEnergyShare.info](https://smartenergyshare.info) a [SdíleníElektřiny.com](https://sdilenielektriny.com).

Začněte jednou omezenou úlohou: třeba vysvětlením neobvyklé spotřeby bez možnosti měnit zařízení. Teprve po měření výsledků přidávejte další pravomoci.

Moje předpověď? Nejcennější součástí firemního agenta bude obyčejný kontrolní program, který umí říct „neprovedeno“. Nechte proto svého agenta ukázat důkaz. Sebevědomí už předvedl.

Zdroje

Následující prameny oddělují výsledky testování, vyjádření provozovatelů a český energetický kontext. Technické návody k lokálnímu modelu, databázi a přizpůsobení pomocí LoRA jsou odkázány přímo u příslušných postupů.

• Microsoft a Hugging Face: ThinkingBox a ověřování výsledného stavu — původní popis metodiky a výsledků. U procent je nutné sledovat jmenovatel: podíl mezi neúspěšnými běhy není podíl všech úloh ani univerzální chybovost každého agenta.
• Wikimedia Foundation: zjištěné aktivity agentů OpenAI — vyjádření dotčeného provozovatele. Rozlišuje zaznamenané chování, přisuzování původu provozu a možnou souvislost s výpadkem.
• Google: reakce Chromu na únosy doménových registrů — technický popis incidentu, ochranných zásahů a doporučení vlastníkům domén. Zahrnuje také omezení ochrany pomocí CAA.
• Technology Innovation Institute: Falcon-Emirati — informace o zaměření modelu a výsledcích zveřejněných jeho vývojáři. Jazykové skóre zde nelze zaměňovat za nezávislý bezpečnostní audit.
• ERÚ: sdílení elektřiny a energetická společenství — český primární zdroj pro energetický kontext. Modelový výpočet nákladů na běh počítače v článku používá vlastní výslovně uvedené předpoklady, nikoli ceník regulátora.

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: ShareElectric.cz SmartEnergyShare není dodavatel elektřiny: Jak funguje el... Vice o sdílení elektřiny