Pod kapotou architektúry:
Ako sa naozaj postaví AI CFO agent

Príspevok #6 z 50 — Séria CFO & AI

Príklady a architektúry v tejto sérii vznikajú ako moje osobné vzdelávacie a nekomerčné experimenty; nejde o ponuku IT alebo poradenských služieb.

V príspevku #2 som popísal, čo AI CFO agent robí — sťahuje dáta, čistí ich, počíta KPI, generuje reporty a odosiela ich. Každý deň. Automaticky. Viacerí sa pýtali na tú logickú otázku: ako? Táto časť je odpoveď.

Fakturačný agent z príspevku #3 a cash flow agent z príspevkov #4–5 sú postavené na rovnakej podkladovej architektúre — sú to samostatné príklady aplikované na rôzne procesy, nie jeden jediný systém.

Slovné spojenie „AI agent" znie zámerne nejasne. Vyvoláva predstavy pipeline strojového učenia, cloudovej infrastruktúry a tímov inžinierov. Realita — pre konkrétny problém automatizácie finančného reportingu vo firme s 50 až 200 ľuďmi — je podstatne prístupnejšia. Nepotrebujete vývojára. Potrebujete jasnú predstavu o tom, čo je prepojené s čím.

Celá architektúra, vrstva po vrstve

AI CFO agent má tri vrstvy: zdrojové systémy (kde žijú dáta), vrstvu agenta (kde sa spracúvajú) a výstupy (kde skončia). Tu je, čo obsahuje každá vrstva a ako sú prepojené.

Agent o financiách nepremýšľa tak, ako CFO. Vykonáva definovaný pracovný postup — spoľahlivo, podľa plánu, s rovnakou logikou každý raz. Táto konzistentnosť je v skutočnosti jedna z jeho hlavných výhod: definície KPI sa nemenia podľa toho, kto model spustil, a report nedorazí neskoro, pretože niekto mal poradu.

Na čom vlastne bežia vrstva agenta

Toto je otázka, ktorú počúvam najčastejšie, keď popisujem túto architektúru. Poctivá odpoveď: závisí to od toho, ako ďaleko chcete ísť. Pre základnú verziu — denné stiahnutie dát, výpočet KPI, e-mailový report — nepotrebujete AI vôbec. Potrebujete plánovanú automatizáciu (Make.com, n8n, alebo aj Python skript) a čisté dátové prepojenia.

AI vrstva sa stáva hodnotnou pri troch konkrétnych úlohách: detekcia anomálií (označenie transakcií, ktoré nesedia do vzoru), generovanie naratívu (písanie komentára k odchýlkam v prirodzenom jazyku) a predikčná prognóza (využitie historických vzorov na zlepšenie 14-dňovej prognózy cash flow). Žiadna z nich nevyžaduje vlastný model. Všetky môžu bežať na univerzálnom LLM s dobre navrhnutým promptom a čistými vstupnými dátami.

Ktoré časti sú naozaj náročné na postavenie

Nie všetko v tejto architektúre je rovnako náročné. Tu je poctivý prehľad toho, kam skutočne ide úsilie — a čo sa pokazí najskôr.

Komponent	Náročnosť nastavenia	Čo sa pokazí / na čo si dať pozor
Pripojenie bankových dát	Jednoduché	Open banking API sú dobre zdokumentované. Hlavný problém: niektoré menšie banky ich ešte nepodporujú — ako záloha slúži manuálny CSV upload.
Export z účtovného softvéru	Stredné	Kvalita API sa líši podľa dodávateľa. Xero a QuickBooks sú výborné. Pohoda (bežná v CEE regióne) vyžaduje viac vlastnej práce. Nekonzistentnosti vo formáte dát sú bežné.
Pravidlá čistenia dát	Náročné	Toto je tá skutočná práca. Účtovná osnova každej firmy je iná. Pravidlá normalizácie treba postaviť manuálne a testovať proti mesiacom reálnych dát, kým sú spoľahlivé.
Logika výpočtu KPI	Jednoduché	Keď sú dáta čisté, vzorce sú priame. Hlavné riziko je posun v definíciách — uistite sa, že sa všetci zhodnú na tom, čo znamená „hrubá marža", skôr než to automatizujete.
Generovanie AI naratívu	Jednoduché	Dobre štruktúrovaný prompt s dátami o zmenách produkuje dobrý komentár k odchýlkam. Prompt treba doladiť na tón a dĺžku, ale ide o hodiny, nie dni.
Doručenie reportu (e-mail/Slack)	Jednoduché	Štandardné integrácie. Hlavný spôsob zlyhania: formátovanie e-mailu sa rozpadne na mobile. Testujte na viacerých klientoch pred nasadením.
14-dňová prognóza cash flow	Stredné	Presnosť závisí od kvality dát o pohľadávkach/záväzkoch. Ak klienti platia neskoro a nepredvídateľne, prognóza sa bude odkláňať. Vo výstupe uveďte úroveň spoľahlivosti, nie len jedno číslo.
Logika prahových upozornení	Jednoduché	Nastavte hranice zo začiatku konzervatívne — pri príliš veľa falošných upozorneniach ich ľudia začnú ignorovať. Dolaďte počas 4–6 týždňov reálnej prevádzky.

Jedna vec, ktorá trvá dlhšie, než by ste čakali

Pri praktickom experimentovaní s týmto typom architektúry sa ukazuje, že vrstva čistenia dát si vyžaduje podstatne viac času, než by sa na prvý pohľad zdalo. Nie preto, že by bola technicky komplexná — ale preto, že nevie, čo je s vašimi dátami v poriadku, kým sa na ne nezačnete pozerať systematicky. Duplicitné záznamy dodávateľov. Transakcie zaúčtované na nesprávne nákladové stredisko. Kategórie faktúr, ktoré sa zmenili, keď niekto pred dvoma rokmi upravil účtovnú osnovu a nikomu to nepovedal.

Toto nie je zlyhanie. Je to v skutočnosti jeden z najhodnotnejších výstupov stavby tohto systému: objavíte, ako naozaj vypadá kvalita vašich dát, a opravíte to natrvalo, namiesto toho, aby ste to obchádzali každý mesiac pri uzatváraní kníh.

Čo si vyžaduje „bez toho, aby na to niekto klikol"

Plná automatizácia — kde má CEO v inboxe čerstvé čísla každé ráno bez ľudského zásahu — vyžaduje, aby boli stabilné tri veci: spoľahlivé dátové prepojenia, plánovač, ktorý beží aj keď sa nikto nepozerá, a vrstva na spracovanie chýb, ktorá zachytí problémy skôr, než vyprodukujú nesprávny výstup.

Plánovač je najjednoduchšia časť. Cloudový cron job (alebo funkcia plánovania v Make.com) to zvládne takmer bez nákladov. Spracovanie chýb je miesto, kde väčšina prvých verzií zaostáva — keď je API banky nedostupné alebo export z účtovníctva je poškodený, agent musí zlyhať viditeľne a nahlas, nie ticho odoslať prázdny alebo nesprávny report.

V praktickom prototype môže byť spracovanie chýb časovo náročnejšie než samotná základná automatizácia. Nie je to okázalé. Ale je to rozdiel medzi demom a systémom, ktorému môžete naozaj dôverovať v pondelok o 7:30 ráno.