AI agent nad firemními daty: reportování, které odpovídá za sekundu

Znáš to: potřebuješ vědět, jaká kampaň minulý měsíc vydělala nejvíc marže, a odpověď ti putuje e-mailem tři dny. Nejdřív análytik, pak výkazník, pak někdo, kdo „musí jen doplnit jeden sloupeček". Mezitím rozhodnutí, kvůli kterému jsi se ptal, už dávno nemá smysl. Přitom ta data někde jsou — v e-shopu, v CRM, v reklamních účtech, v účetnictví. Problém není v datech, ale v ceně jedné otázky.

AI agenti začínají tuhle cenu lámat. Washington Post nedávno popsal, jak postavil síť agentů nad interními daty: agent čte firemní datové sady, řídí se oprávněním toho, kdo se ptá, a vrací odpovědi na otázky z obsahu, předplatného i reklamy v řádu minut. A McKinsey ve svém průzkumu „State of AI 2026" uvádí, že podíl velkých firem, které škálují agenty alespoň v jedné funkci, vzrostl za rok z 27 na 40 %. Tohle už není demo z keynote, je to běžná provozní praxe.

Dobrá zpráva: nemusíš být Washington Post ani mít datový tým. Stejnou myšlenku postavíš v malém měřítku za víkend. V tomto návodu ti ukážu, jak na to krok za krokem — a hlavně jak to udělat tak, abys agentovi mohl věřit.

Co je to reportovací agent (a co není)

Reportovací AI agent je softwarový proces, kterému dáš přístup k firemním datům a který na přirozenou otázku („Které produkty klesly v prodeji meziměsíčně?") sám napíše dotaz, spustí ho a odpoví ti česky i s čísly. Není to chatbot, který si data vymýšlí z tréninku. Není to ani dashboard, který ti ukáže všechno kromě odpovědi na tvou otázku. Je to kolega, který umí SQL, zná schéma tvých tabulek a je dostupný okamžitě.

Rozdíl proti klasickému BI nástroji je zásadní: dashboard odpovídá na otázky, které někdo předem položil. Agent odpovídá na otázku, kterou máš právě teď. A pokud má přístup k historii, dokáže i vysvětlit proč se čísla změnila — ne jen že se změnila.

Krok 1: Svaž data do jednoho místa

Agent je jen tak dobrý, jako jsou dobré tabulky, ze kterých čte. Pokud jsou tvá data roztříštěná v deseti systémech, agent ti nepomůže — bude ti sdělovat polopravdy z pěti zdrojů najednou.

Začni jednoduše. Vyber jednu oblast (třeba prodej + reklamy) a pravidelně ji exportuj do jedné databáze. Pro menší tým bohatě stačí PostgreSQL — je zdarma, umí JSON, views i row-level security. O tom, kdy PostgreSQL jako jediná databáze stačí a kdy sáhnout vedle, jsme psali v samostatném článku. Pokud zatím žiješ v tabulkách, zvládneš rozumný start i ve Google Sheets s AI funkcemi — návod máme tady. Ale počítej s tím, že u desítek tisíc řádků a více už chce databáze méně údržby než sdílený sešit.

Důležitá je kanonická vrstva: pár pojmenovaných view (v_daily_sales, v_ad_spend, v_customer_orders), které mají čisté názvy sloupců a definovaný význam. Agent pak nekouká do stovek surových tabulek, ale do deseti srozumitelných pohledů. Míň místa na chybu, levnější dotazy, rychlejší odpovědi.

Krok 2: Read-only přístup, žádné PII

Tady se dělá nejvíc chyb, takže to řeknu na rovinu: agent dostane vlastního databázového uživatele, který umí jen číst, a navíc čte jen z views. Žádný přímý přístup k tabulkám s osobními údaji, e-maily zákazníků nebo cenami nákupů. To je trvalé pravidlo, ne doporučení.

V PostgreSQL to znamená pár řádků: vytvoříš uživatele agent_ro, dáš mu SELECT na views a nic víc. Osobní data řeší druhá vrstva — view, které hashuje nebo rovnou vynechává sloupce s PII. Podrobný postup, včetně rolí a auditu, jsem popsal v článku o oprávněních pro AI agenty na datové vrstvě. Má to jeden příjemný vedlejší efekt: i když agenta někdy oklame prompt injection, fyzicky nemá čím způsobit škodu — číst může, psát ne.

Krok 3: Připoj agenta k datům

Máš tři cesty podle toho, kolik chceš programovat:

1. Claude nebo ChatGPT s datovým konektorem. Nejrychlejší start. Nástroje jako Claude s MCP serverem k databázi nebo ChatGPT s firemními konektory umí připojit tvou databázi a dotazovat se na ni přirozeným jazykem. Hodí se na první ověření, že data dávají smysl. Pro citlivá data si přečteš, kde konkrétně běží zpracování — u osobních údajů je to v Česku požadavek, ne formalita.

2. N8N workflow s AI uzlem. Zlatá střední cesta pro automatizaci. V N8N postavíš flow: schedule nebo webhook → LLM uzel napíše SQL → databázový uzel ho spustí → výsledek se pošle na Slack nebo e-mail. Zvládneš to bez kódu a výsledek běží sám. Jak na scraping a dotažení externích dat do N8N popisuje tento návod.

3. Vlastní agent v kódu (Claude Code, SDK). Pro maximální kontrolu. Agent dostane tool definice (run_sql, list_views), ty mu v systémovém promptu popíšeš schéma a pravidla, a on si dotazy skládá sám. Nejvíc práce, ale taky nejvíc jistoty nad tím, co přesně se děje.

Ať vybereš kteroukoli cestu, začni stejně: denní KPI report do Slacku. Jediná zpráva, každé ráno v 8:00, pět čísel a odstavec „co se změnilo a proč". Je to nejjednodušší use case s nejvyšší šancí, že ho lidi začnou reálně používat.

Krok 4: Audit log a schvalování všeho, co mění data

Reporting je ze své podstaty read-only operace — a právě proto je to ideální první agent. I tak ale nastav dvě pojistky:

Audit log. Každý dotaz, který agent spustil, ukládej s časem, otázkou, SQL a uživatelem. Ne kvůli byrokracii, ale kvůli důvěře. Když ti někdo řekne „to číslo nemůže být pravda", do pěti minut zjistíš, jak ho agent spočítal. Většina chyb agentů totiž není v SQL, ale v tom, že si dotazovaný představoval jinou definici „prodeje" než tabulka. Log ti to ukáže.

Human sign-off pro zápis. Až agenta jednou rozšíříš o akce (upravit rozpočet kampaně, přesunout objednávku), žádná změna dat nesmí proběhnout bez explicitního schválení člověka. Washington Post to má jako pevné pravidlo a ty to měj taky. Jak dohlížet na běžící agenty obecně popisuje článek o observability AI agentů v produkci.

Kde to celé selhává

Tři nejběžnější způsoby, jak si týmy projekt rozbijí:

• Všechno hned. Agent napojený na deset systémů v první den vrátí poloviční odpovědi a ztratí důvěru týmu na měsíce. Jedna oblast, jeden report, jednou denně.
• Neřešené definice. „Prodej", „marže" a „nový zákazník" musí mít v kanonických views jednu jednoznačnou podobu. Jinak agent odpovídá správně na špatně položenou otázku.
• Žádný log. Bez auditu se každá chyba agenta stále nedohledatelnou hádankou a lidé se vrátí k tabulkám. Log je levný, důvěra drahá.

A jeden technický detail na závěr: nech agenta vždy vracet i SQL, které spustil. Ne proto, že bys ho kontroloval ručně, ale protože ho můžeš nechat automaticky ukládat a jednou za čas vzorkovat. Jde o laciný zpětnovazební mechanismus, který ti za pár týdnů odhalí, kde má schéma nejasné názvy.

Kolik tě to stojí

Realisticky: víkend konsolidace dat, den na nastavení přístupů a den na agenta s prvním reportem. Provoz malého reportovacího agenta se vejde do desítek dolarů měsíčně v API — vytížení je nízké, protože čtení KPI tabulek jsou krátké dotazy. Pro srovnání: jedna hodina análytika týdně tě stojí víc a odpoví pomalu.

Závěr: začni jednou otázkou

Reportovací agent není o nahrazení lidí. Je o tom, že se cena jedné otázky o vlastní firmě sníží z dnů na sekundy — a ty se pak ptáš častěji, na hlubší věci a s aktuálnějšími daty. Vyber si jednu otázku, kterou si kladete každý týden, postav nad ní kanonické view, připoj agenta s read-only přístupem a nech si odpověď posílat do Slacku. Až to pár týdnů pojede bez toho, že bys musel něco opravovat, rozšiřuj dál.

Data už máš. Chybí jen někdo, kdo na ně umí odpovídat rychle — a s tímhle postupem ho postavíš za víkend.