Zažil jsem, že datové pipeline dokončily přepočet, aniž by zahlásily technickou chybu. Některé výsledné tabulky ale byly prázdné. Reporty, které z nich čerpaly, pak neměly čísla pro přepočítávané dny. V přehledu se objevil propad, který popisoval chybějící data místo skutečného dění.
Tohle je pro mě důležitý rozdíl při provozu automatizací. Potřebuji vědět, že úloha proběhla, ale také že vytvořila úplný, aktuální a použitelný výsledek. Kontrolka běhu odpovídá jen na první část.
Člověk si prázdného dashboardu může všimnout. Pokud se na problém přijde až takhle, mohou ho už vidět i koncoví uživatelé. Jako datař chci, aby ho zachytily kontroly dřív, než se lidé podle chybných čísel začnou rozhodovat.
Nejdřív ověřte, co opravdu vzniklo
U dat proto přidávám kontroly jednotlivých částí: zda v tabulce očekávaná data vůbec jsou, zda mají správné typy a zda hodnoty odpovídají domluveným rozsahům. Kontrolní součty a porovnání s obvyklým stavem pak mohou zachytit situaci, kdy tabulka prázdná není, ale část dat v ní chybí.
Pravidla musí vycházet z toho, co daný report znamená. Nula objednávek může být správná, pokud obchod neměl otevřeno. Stejná nula při běžném provozu může znamenat výpadek. Člověk musí posoudit, co se má kontrolovat, kdy je odchylka vysvětlitelná a kdy report raději neodeslat. AI s návrhem kontrol může pomoci; odpovědnost za jejich význam tím nezmizí.
Pro další postup použijme modelový příklad: automatizace každé pondělí spojí tři zdroje do přehledu zakázek a pošle ho týmu. U ní chceme ověřit tři různé věci:
- Běh: úloha se spustila a dokončila potřebné kroky.
- Obsah: report obsahuje očekávaná období a záznamy, hodnoty dávají smysl a zdroje jsou aktuální.
- Doručení a použití: příjemce dostal správnou verzi a může ji použít pro zamýšlené rozhodnutí.
V našem příkladu může nový report použít stejný starý snímek dat jako při minulém spuštění. Soubor vznikl, zpráva odešla a systém nehlásí chybu. Tým ale rozhoduje podle starých údajů. Proto otevřete doručený výsledek a zkontrolujte také období a obsah.
Při prvním ověření pomůže porovnat report s několika konkrétními záznamy ve zdrojovém systému. Pak můžete část kontrol automatizovat: sledovat datum poslední aktualizace, dostupnost zdrojů nebo neobvyklý propad počtu záznamů. Ne každá odchylka znamená chybu, ale měla by jít vysvětlit.
U agentů hlídejte také změnu kvality
U postupů s pevně určenými kroky, třeba v Make, vnímám změnu vstupu často jako příčinu viditelného selhání. U agentních automatizací se víc obávám toho, že práce pokračuje, ale agent začne dodávat něco jiného. Změní se podklady nebo jejich kvalita a původní zadání už nestačí. Ani pevně daný postup ovšem není chráněný před chybným výsledkem; kontroly potřebují oba.
U agenta proto sleduji i to, zda výstup stále odpovídá původnímu účelu. K tomu slouží evaluace: vybrané úlohy s podklady a podmínkami, podle kterých poznáme dobrý výsledek. Po změně zdrojů nebo instrukcí je znovu projdeme a vedle toho občas zkontrolujeme skutečné výstupy z provozu. Podrobněji tento způsob ověřování popisuji v článku o vyhodnocení AI pilotu.
Pokud má agent připravovat články, nestačí sledovat, kolik jich vytvořil. Je potřeba některé přečíst a ověřit, zda se drží zadání, používají správné podklady a přinášejí čtenáři hodnotu. Postupný posun od toho, co jsme chtěli, k něčemu jinému bývá označovaný jako drift. Zelená kontrolka spuštění ho sama neodhalí.
Co když jeden ze zdrojů vypadne?
Při prvním testu obvykle chcete hlavně vidět, že všechno funguje. Pak ale stojí za to zkusit i opačnou situaci: jeden soubor chybí nebo služba neodpovídá. Udělejte to nanečisto, aby zkušební výsledek neodešel kolegům jako běžný report.
Co se stane, když jeden ze tří zdrojů není dostupný? Počká automatizace, nebo vytvoří přehled jen ze zbývajících dvou? Pokud pošle částečný výsledek, musí z něj být zřejmé, co chybí. Jinak může tým nižší počet zakázek považovat za skutečný pokles, přestože se jen nepodařilo část z nich načíst.
Potom vyzkoušejte opakované spuštění. Chybějící potvrzení o odeslání ještě neznamená, že zpráva neodešla. Než ji systém pošle znovu, potřebuje zjistit, co už provedl. Jinak může příjemce dostat zprávu dvakrát. U vytváření objednávek nebo faktur může mít stejná chyba závažnější následky.
Domluvte se, kdo se o problém postará
Upozornění na chybu pomůže jen tehdy, když dorazí někomu, kdo s ní může něco udělat. Obnovení přístupu možná vyřeší správce systému, chybějící údaje doplní obchodník a o odeslání neúplného reportu rozhodne vedoucí týmu. Každý potřebuje jinou informaci. Samotné „něco se pokazilo“ jim moc nepomůže.
Určete člověka, který hlídá výsledek. Musí vědět, komu předat technický problém a kdo rozhoduje o změně pravidel. Zapište také, kde úloha běží, odkud bere data a jak ji pozastavit. Při chybě pak nemusíte nejdřív hledat toho, kdo ji kdysi nastavil.
U našeho vymyšleného reportu by upozornění mohlo znít takto:
Do pondělního reportu se nenačetl jeden ze tří zdrojů. Report jsme zatím neodeslali. Správce má ověřit přístup ke zdroji; vedoucí týmu rozhodne, zda počkáme, nebo odešleme označený neúplný přehled.
Z takové zprávy je zřejmé, co selhalo, co se stalo s výsledkem a kdo má pokračovat.
Malá změna si zaslouží krátké ověření
Pravidla se mění i u zdánlivě jednoduché úlohy. Report má nově chodit v úterý, přibude další tým nebo se přesune zdroj dat. Změna může být hotová během chvíle, přesto stojí za to ověřit, že běžící úloha opravdu používá nové nastavení.
Podívejte se přímo do nástroje, který automatizaci spouští. Je tam správný čas, zadání, zdroj i příjemce? Má úloha potřebné přístupy? Poznámka v dokumentaci nebo potvrzení o uložení ještě neukazuje, co se při dalším spuštění skutečně stane.
Pokud by během úprav mohla odejít chybná zpráva nebo se zapsat nesprávné údaje, úlohu pozastavte. Nový postup nejdřív vyzkoušejte nanečisto. Po zapnutí zkontrolujte první výsledek. Změna času odeslání může potřebovat jen krátkou kontrolu. U nového zdroje projděte také jeho obsah.
Když nepřijde zpráva, je všechno v pořádku?
U pondělního reportu čekáte zprávu každý týden. Když nepřijde, něco chybí. U kontroly, která upozorňuje jen na zakázky po termínu, ale může být ticho správný výsledek. Právě proto je dobré rozlišovat, zda úloha proběhla a nic nenašla, nebo se vůbec nespustila.
Nemusíte kvůli tomu dostávat další zprávu po každé kontrole. Stačí mít možnost dohledat, kdy kontrola naposledy proběhla a s jakým výsledkem. Zpráva má přijít tehdy, když něco selže, úloha vynechá plánované spuštění nebo čeká na vaše rozhodnutí.
Když automatizace posílá příliš mnoho hlášení, lidé si na ně zvyknou a přestanou je číst. Důležitá zpráva pak snadno zapadne mezi desítky potvrzení, že se nic nestalo.
Používá ten report ještě někdo?
Automatizace může technicky fungovat bez chyby, a přesto už nikomu nepomáhat. Tým mezitím přešel na jiný přehled, zprávy chodí lidem, kteří už mají jinou práci, nebo si někdo každý týden přepočítává stejný sloupec.
U vlastní automatizace se ptám, zda pořád dělá to, kvůli čemu vznikla, a dodává očekávaný výsledek. Pokud škodí nebo už nepřináší užitek, je důvod ji pozastavit či vypnout. Údržba stojí čas a běh může stát peníze, i když výsledek nikdo nepotřebuje.
Stejně se ptejte lidí, kteří výsledek používají: Je to pořád užitečné? Co vám chybí? Co musíte dodělávat ručně? Někdy z odpovědí vzejde drobná úprava. Jindy zjistíte, že úlohu můžete úplně vypnout.
Četnost kontrol přizpůsobte následkům chyby. Interní týdenní přehled potřebuje jinou péči než systém, který mění objednávky. Domluvte, kdo a kdy výsledek zkontroluje. Pokud najdete opakovanou chybu, doplňte pro ni automatickou kontrolu, aby ji příště zachytila úloha sama.
Kdy jsem pozastavil výrobu článků
V říjnu 2026 jsme zpřísnili hodnocení obsahu na mých webech. U HeyRupu, Before the Magic, Ježíšek už jede a Registree jsem chtěl nejdřív projít už zveřejněné stránky a dotáhnout ty, které novým pravidlům nevyhovovaly. Novou výrobu jsme proto pozastavili. V tu chvíli dávalo větší smysl zlepšit obsah, který už čtenáři používají, než přidávat další.
Tohle nebylo rozhodnutí, že automatizované psaní už nechci. Změnila se priorita a podmínky, za kterých má výroba pokračovat. Dříve jsme také nahradili samostatné článkové úlohy společným redakčním workflow; staré úlohy zůstaly vypnuté, aby vedle jejich náhrady nevyráběly další obsah. Při kontrole tedy potřebuji znát i důvod vypnutí, ne jen seznam pozastavených úloh.
Stejně bych postupoval u firemního reportu: zapsat, proč úlohu zastavuji, co musí být před obnovením splněné a kdo o něm rozhodne. Dokončená oprava sama o sobě neznamená pokyn znovu zapnout odesílání. Ještě je potřeba ověřit výsledek a potvrdit, že má úloha dál běžet.
Co zkontrolovat u automatizace, kterou už máte
Vyberte si jednu úlohu, na kterou se dnes spoléháte, a projděte si těchto pár otázek:
- Kdy naposledy proběhla a kde je její skutečný výsledek?
- Jak poznáte, že pracovala se správnými a úplnými údaji?
- Co udělá při chybě a komu se ozve?
- Může při opakování provést stejnou akci dvakrát?
- Kdo umí změnit nastavení nebo úlohu zastavit?
- Používá její výsledek ještě někdo a pomáhá mu?
Pokud u některé otázky váháte, začněte právě tam. Třeba stačí doplnit kontrolu aktuálnosti dat nebo změnit příjemce chybových zpráv. Nemusíte předělávat celý systém. I malá úprava může znamenat, že se o problému dozvíte včas a budete vědět, co s ním.
Spolehlivosti nástrojů a AI agentů se věnuje také článek o tom, proč dál platím za SaaS. Pokud chcete začít jedním konkrétním procesem ve firmě, podívejte se na AI workflow sprint.