AI agent v účetnictví dnes umí fér věci: přečte fakturu, najde nespárované platby, ověří sazbu DPH, upozorní na doklad, který chybí před uzávěrkou. A právě proto je pokušení obrovské — nechat ho rovnou zapisovat ty opravy za tebe. Jenže v účetnictví neexistuje tlačítko Zpět. Špatně přesunutá položka, přepsaná sazba DPH nebo smazaný doklad se neprojeví hned, ale až u daňové kontroly, kdy už nikoho nezajímá, že to udělal agent, a ne ty.
Proto tu je pravidlo, které dnes používají týmy, co agenty v účetnictví opravdu provozují: agent čte, kontroluje a navrhuje. Zapisuje až člověk — nebo automatizace, kterou člověk explicitně schválil. V tomto článku ti ukážu, jak tuhle zásadu rozvést do tří konkrétních vrstev: read-only brány, logu každého kroku a schvalování před zápisem. Bez ohledu na to, jestli agenta postavíš v n8n, Make nebo přes MCP nad Claude.
Proč AI v účetnictví nefunguje bez zábradlí
Většinu firemních dat si agent může pokazit a svět se nezboří. Marketing pokazí kampaň? Přepíšeš copy. Kodér smaže branch? Git vrátí. Účetnictví je jiné ze tří důvodů:
- Záznamy mají právní váhu. Za správnost účetnictví odpovídá konkrétní člověk — podnikatel nebo účetní. Agent není účetní jednotka a žádný zákon o účetnictví mu odpovědnost nepřenechá.
- Chyby se projeví se zpožděním. Nesprávné účtování vyplave až v daňovém přiznání, během auditu nebo u kontroly. Opravit záznamy zpětně jde, ale každá oprava musí být doložitelná a zdůvodněná.
- Agent nezná kontext, který účetní zná. Proč je náklad uznatelný, proč je záloha stále záloha, proč se faktura účtuje jinak — tohle si agent domyslí s sebevědomím, které nemá čím pokrýt.
Pozor největší riziko není agent, který nic neumí. Je to agent, který umí skoro všechno — a kterého necháš psát, protože v 95 % případů to zvládne správně. Právě těch 5 % tě v účetnictví položí.
Není to jen feeling — popisuje to i Anthropic v textu Building Effective Agents (prosinec 2024): agent pracuje samostatně, ale u rozhodnutí vyžadujících lidský úsudek se vrací člověku. Účetnictví je přesně ten případ.
Read-only brána: agent smí jen číst
První vrstva je technická a nediplomatická: agent dostane přístup, se kterým fyzicky nedokáže zapsat ani znak. Říká se tomu read-only brána a staví se třemi způsoby:
- Databázový uživatel jen se právem SELECT. Pokud agent čte přímo z databáze (např. nad exportem z účetního programu), vytvoř mu uživatele, který umí jen číst. Žádné UPDATE, žádné DELETE.
- API klíč s nejnižšími oprávněními. Většina API (Fakturoid, e-shop, banka) umožňuje klíč omezit jen na čtení. Pokud read-only klíč neexistuje, použij separatní účet s omezením na úrovni aplikace.
- MCP server s read-only nástroji. Pokud agenta připojuješ přes Model Context Protocol, deklaruj nástroje s anotací
readOnlyHint: true. Oficiální blog MCP (16. 3. 2026) k anotacím nástrojů uvádí, že specifikace (revize z 26. 3. 2025) je v tomhle záměrně pesimistická: nástroj bez anotace se považuje za potenciálně destruktivní. Nech ho tak — a write operace do MCP serveru prostě nedoplníš.
Vrstva funguje i opačně: i když agenta někdo přesvědčí, aby „něco jen rychle opravil", pokus skončí na chybě oprávnění. Není to procesní pravidlo, které se dá obejít dobrým promptem. Je to zeď.
Druhý bonus: read-only agent může číst všechno, co potřebuje. Neřešíš, co mu ukázat a co skrýt — kontrola nesrovnalostí totiž vyžaduje vidět celý obrázek, ne výběr.
Log: každé čtení i návrh pod dohledem
Druhá vrstva je historie. Když agent pracuje s účetními daty, musí být záznam o tom, co četl, co našel a co navrhl — s časem a s odkazem na konkrétní doklad. Ne proto, že bys agentovi nedůvěřoval, ale proto, že:
- Opravy potřebují zdůvodnění. Když agent navrhne přeúčtovat dvacet položek, musí u každé stát proč. Ten důvod je součástí logu.
- Rekonstrukce musí být možná. Účetní si u uzávěrky musí umět ověřit, na základě jakých dat agent vyhodnotil nesrovnalost — i měsíc poté.
- Chyby agenta se hledají v logu. Bez něj nevíš, jestli agent našel málo, protože četl špatná data, nebo protože jeho pravidla byla špatně nastavená.
Prakticky: každý běh agenta zapisuje do jedné tabulky (stačí Google Sheets nebo tabulka v databázi) — čas, rozsah zkontrolovaných dokladů, nalezené nesrovnalosti, návrh opravy a stav (navrženo / schváleno / zamítnuto). Tím máš zároveň třetí vrstvu zadarmo.
Schvalování před zápisem: rozhoduje člověk
Třetí vrstva je procesní. Každý návrh agenta končí ve schvalovací frontě — jedno místo, kde účetní vidí, co agent navrhuje, a jedním klikem buď schválí, nebo zamítne. Teprve po schválení zápis provede automatizace, a to pod svou vlastní identitou (vlastní API klíč, vlastní uživatel), aby bylo navždy vidět, že zapsal proces, ne člověk ručně.
Dvě zásady, které schvalování drží při zemi:
- Schvaluješ dávkově, ne po jednom. Pokud má účetní klikat 140 návrhů po jednom, schvalovací frontu za týden obejde a vrátí se k ruční kontrole. Správná fronta nabízí hromadné schválení skupin, které se liší jen ID dokladu.
- Zamítnutí je také data. Když účetní návrh třikrát zamítne, agent (nebo jeho pravidla) je špatně nastavený. Log zamítnutí ti řekne, kde přesně.
Tím se mění role účetního: z člověka, který doklady ručně prochází, se stává kontrolor výjimek. Náročnost uzávěrky se přesouvá z „projití všeho" na „schválení toho, co agent označil".
Jak agenta v účetnictví postavit krok za krokem
Konkrétní postavu, kterou dnes doporučuji pro malou firmu nebo účetní praxi, zvládneš postavit za odpoledne. Nástroje vol podle sebe — architektura je stejná.
Krok 1: Vytvoř jen read-only přístup
Vytvoř databázového uživatele s právem SELECT nebo API klíč omezený na čtení (Fakturoid, bankovní API, export z účetního programu). Přístup agenta do účetního programu záměrně neřeš — zatím.
Krok 2: Připoj data k agentovi
V n8n nebo Make postav workflow, které data stáhne (nové faktury, nepárované platby, doklady bez účtování) a předá je agentovi. Pokud používáš Claude s MCP, napiš malý MCP server se čtecími nástroji a anotuj je jako read-only.
Krok 3: Nastav, co agent kontroluje
Nejlepší první kontroly, které se vyplatí hned:
- nepárované platby v bankě proti fakturám,
- faktury se sazbou DPH, která nesedí na typ dokladu,
- chybějící doklady k nákladům před uzávěrkou,
- duplicitní čísla dokladů.
Krok 4: Návrhy posílej do schvalovací fronty
Výstup agenta zapisuj do sdílené tabulky nebo schvalovacího kroku ve workflow (n8n na tohle má krok typu čekání na schválení). Účetní dostane upozornění — e-mailem nebo do Slacku — a schválí hromadně.
Krok 5: Zápis provede automatizace po schválení
Teprve po schválení spustí workflow zápis — importem do účetního programu, přes API, nebo aspoň vygenerováním importního souboru, který účetní nahraje ručně. První měsíc stačí ten importní soubor; automatizaci zápisu přidej, až frontě důvěřuješ.
Od prvního dne si piš, kolik návrhů prošlo, kolik zamítnuto a kolik času kontrolor ušetřil. Tohle číslo rozhodne, jestli projekt přežije první uzávěrku.
Co svěřit agentovi hned a co držet u sebe
Hned kontroly (nesrovnalosti, chybějící doklady, sazby DPH), hlídání termínů (splatnosti, uzávěrky), příprava návrhů účtování, srovnávání banky proti fakturám, kontrola duplicit.
Ještě ne zápis účtování, odeslání daňového přiznání, mazání a úprava dokladů, komunikace s finančním úřadem, cokoli, co mění záznam, který už jednou existuje.
Hranice se posouvá pomalu a daty: až agent tři uzávěrky po sobě navrhne opravy s > 95 % přesností a nízkou mírou falešných poplachů, můžeš přistoupit k automatickému zápisu pro úzkou, dobře definovanou třídu oprav. Ostatní nech ve frontě.
Pokud hledáš, které nástroje do účetnictví dnes vůbec sáhnout, máme přehled pěti AI nástrojů pro účetnictví a 10 promptů pro účetní do ChatGPT. Obecnější pravidla pro bezpečné nasazení agentů shrnuje článek Jak bezpečně nasadit Claude agenty a Jak chránit data před AI agentem. Podobný read-only vzorec využívá i reporting agent nad firemními daty — čte, nic nemění. Kompletní přehled AI role pro účetní najdeš na stránce AI pro účetní.
Časté otázky
Může AI agent vést účetnictví místo účetní?
Ne. Agent zvládne kontroly, připomínky a návrhy, ale právní odpovědnost za účetnictví zůstává člověku. Firmy, které agenty v účetnictví provozují, je používají jako kontrolora a přípravkáře — zápis je vždy schválený člověkem.
Co je read-only přístup konkrétně?
Je to přístupová práva, se kterými agent dokáže data jen číst — databázový uživatel s právem SELECT, API klíč omezený na čtení nebo MCP nástroje s anotací readOnlyHint. I když se agent pokusí zapsat, operace selže na oprávněních.
Jak schvalování před zápisem funguje v praxi?
Agent vkládá návrhy oprav do schvalovací fronty (tabulka, Slack, e-mail). Účetní je projde, hromadně schválí nebo zamítne a teprve potom automatizace provede zápis — pod svou identitou, takže je vždy dohledatelné, kdo/co zapsal.
Není logování agenta zbytečný byrokratický režim?
Naopak. Log ti dá odpověď na otázku „na základě čeho agent navrhl tuhle opravu", kterou si účetní položí u každé uzávěrky — a bez něj nemáš jak ladit, proč agent chybuje.
Kdy můžu agenta pustit k zápisům?
Až máš měřená data: několik uzávěrek po sobě s vysokou přesností návrhů a malým podílem falešných poplachů. I pak doporučuji automatický zápis jen pro úzkou třídu dobře definovaných oprav, vše ostatní zůstává ve schvalovací frontě.
AI agent v účetnictví není náhrada účetní, ale nejrychlejší kontrolor, jakého kdy měla. Nech ho číst všechno, psát nic a mluvit jen do schvalovací fronty. Až ti jednou projde první uzávěrka, kde jsi místo procházení dokladů jen klikal Schválit, pochopíš, proč je tohle první pravidlo, které se v účetnictví s agenty učí.
Chceš agenty v účetnictví rozjet? Mrkni na AI pro účetní — návody, prompty i lead magnety pro praxi.
