Ve firmách se dnes často mluví o tom, že do datových týmů přijdou AI agenti. Část práce, kterou dřív dělal analytik, BI specialista nebo datový inženýr, může převzít agent. Dostane otázku, najde data, napíše dotaz, vrátí odpověď a ideálně ještě vysvětlí, co z ní plyne.
Ta představa je lákavá hlavně pro vedení firmy: rychlejší reporting, méně čekání na datový tým, víc rozhodnutí opřených o data. Jenže mezi napojením modelu na databázi a důvěryhodným výsledkem je kus práce, který nejde obejít. Nestačí dát agentovi přístup do skladu a čekat, že si zbytek domyslí.
Agent přitom nenahrazuje ETL. Datové toky dál přivádějí a připravují data pro reporting. Agent může změnit další krok: nad připravenými daty přijme otázku, převede ji na dotaz a vrátí odpověď, kterou musí jít ověřit. Právě proto se práce datového týmu přesouvá také k definicím metrik, vztahům mezi daty a kontextu, podle kterého agent otázce rozumí.
Pokud agent nezná firemní definice, datový model, limity zdrojů, doménu a účel otázky, bude se tvářit jistě i ve chvíli, kdy odpovídá špatně. To není jen technická nepříjemnost. Je to manažerské riziko, protože špatná odpověď může vypadat stejně přesvědčivě jako správná.
Hlavní teze je jednoduchá: agentní BI mění hodnotu věcí, které se dřív snadno odkládaly. Kvalitní datové modelování, metadata, popisy sloupců, dobré názvy tabulek, definice metrik a čistota datového skladu nejsou úklid navíc. Jsou infrastruktura, která agentovi umožní napsat míň dotazů, spotřebovat míň tokenů, méně zatížit databázi a hlavně zvýšit šanci, že odpoví správně.
Co myslím agentním BI
Agentem v tomhle článku myslím AI nástroj, který nedostává jen přesný návod typu „klikni na tohle tlačítko“. Dostává cíl. Podle pravidel, oprávnění a dostupných nástrojů se potom rozhoduje, co udělá dál: najde si kontext, napíše SQL, spustí dotaz, zkontroluje výsledek, navrhne úpravu dashboardu nebo pošle změnu do review.
Agentní BI je použití takového agenta nad datovým prostředím firmy. Cílem není jen hezčí chat nad dashboardy. Ambice je větší. Salesák, marketér nebo manažer se nemusí s každou otázkou stavět do fronty za datovým týmem. Může se zeptat agenta, který zná datový sklad, ETL procesy, metriky, dashboardy a firemní pravidla. Agent mu odpoví, případně navrhne, co v dashboardu chybí: filtr, dimenze, metrika nebo jiný pohled na data.
Tím se ale zvyšuje nárok na prostředí. Agent může zvládnout víc, než si dnes mnoho firem připouští. Jenže čím větší část práce mu svěříme, tím důležitější je, z čeho vychází. Potřebuje přípravu, péči, lidský dohled a systém, který se dlouhodobě zlepšuje podle toho, kde agent narazil.
Agentní BI není jen chat nad dashboardy. Je to test, jestli firma umí svoje datové know-how předat dál.
Co vlastně znamená kontext
Kontext je sada informací, znalostí a zkušeností, na základě kterých jsme schopni dělat rozhodnutí. Člověk ho získává roky: z porad, produkčních incidentů, rozhovorů s businessem, historických kompromisů v datech a z nepsaných pravidel, která se ve firmě předávají mezi lidmi.
Pro AI agenta je to podobné. Nestačí mu vědět, kde leží tabulka. Potřebuje chápat, co firma považuje za objednávku. Když se někdo ptá na výsledky, musí vědět, jestli má sáhnout po tržbách, marži, počtu objednávek, nebo marketingové efektivitě. A když se ptá na Slovensko, musí vědět, podle čeho má ve skladu vybrat správné zákazníky nebo objednávky. Stejně tak potřebuje znát časové pásmo, reportingové výjimky a historické artefakty datového skladu.
Neexistuje přitom jeden univerzální kontext. V datových týmech se potkávají minimálně tři vrstvy: obecný business kontext, doménový kontext a datový kontext. Nejsou to oddělené šuplíky. Navzájem se doplňují a dohromady tvoří obraz firmy, ze kterého analytik při odpovědi vychází. Agent tenhle obraz bez explicitní pomoci nemá.
Business kontext je hlavně porozumění tomu, co firma dělá, kam jde, jaké má cíle, jak fungují její procesy a proč se některá rozhodnutí dělají právě teď.
Doménový kontext popisuje, co řeší jednotlivé týmy, v jakých nástrojích fungují, jaké projekty mají otevřené a co od dat očekávají. Datový kontext je potom konkrétní význam metrik, tabulek, sloupců, časů, měn a pravidel ve skladu. Vychází z business a doménového kontextu: když nevíme, jak firma a tým pracují, těžko přesně popíšeme, která tabulka nebo metrika má odpovědět.
U marketingu je to dobře vidět. Pokud má agent odpovídat marketingovému týmu, nestačí, že zná impresi, návštěvnost a konverzi. Potřebuje vědět, na jakých projektech tým pracuje, co ho pálí a co od odpovědi vlastně čeká.
Agent je nový kolega, ne čtenář myšlenek
Dobrý způsob, jak o agentovi přemýšlet, je onboarding nového kolegy. Když do firmy přijde analytik, taky mu nestačí říct: „Tady je databáze, nějak se v ní vyznej.“ Potřebuje vědět, kde jsou zdroje pravdy, které tabulky jsou historické, co znamenají názvy sloupců, jak se počítají hlavní KPI a kdy se má raději zeptat.
Stejné informace potřebuje agent. Jen má jednu nevýhodu: nebyl s vámi na schůzkách, neslyšel historické debaty a neumí číst myšlenky seniorních lidí v týmu. Pokud znalosti zůstávají v hlavách lidí, agent je nemá odkud vzít.
Tým, který má data warehouse, dashboardy a pár lidí, kteří „vědí, kde co je“, nemusí být špatný tým. Jen nemusí být připravený na agentní dobu. To je důležitý rozdíl. Agentní BI netrestá slabé týmy. Jen rychle ukáže, které know-how nebylo nikdy zapsané, otestované ani předatelné.
Jednoduchá otázka často jednoduchá není
Vezměme banální otázku: jak vypočítáš počet objednávek? Model bez kontextu může odpovědět syntakticky správným SQL:
SELECT COUNT(order_id)
FROM ordersJenže správná odpověď ve vaší firmě může vypadat úplně jinak:
SELECT COUNT(DISTINCT order_id)
FROM orders
WHERE order_status <> 'canceled'
AND order_stream = 'online'
V tom rozdílu je celá pointa. Má agent počítat všechny řádky, nebo unikátní objednávky? Patří do čísla stornované objednávky? Řešíme jen online stream, nebo všechny kanály? Bereme jako objednávku už vznik košíku, zaplacení, potvrzení skladu, nebo něco jiného?
Pokud tyhle odpovědi žijí jen v hlavě seniorního analytika, agent je nemá odkud vzít. A pokud je začne odhadovat, firma dostane rychlou odpověď, ale ne nutně odpověď, podle které se dá rozhodovat.
Businessová otázka v sobě schovává technické otázky
Ještě lépe je to vidět na otázce typu: „Jak si vedlo Slovensko v letošní Q1 proti loňsku?“ Na první poslech je to běžná manažerská věta. Pro datového agenta je to ale balík definic a rozhodnutí, která musí někde najít.
Nejdřív musí vědět, čím „vedlo“ měříme: tržbami, marží, objednávkami, počtem zákazníků, retencí, marketingovou efektivitou, nebo kombinací metrik. Musí poznat, kdo se ptá, protože CEO bude často potřebovat jinou odpověď než marketingový tým. A musí vědět, jak ve skladu vyfiltrovat Slovensko: podle země zákazníka, doručovací adresy, trhu, měny, nebo organizační jednotky. Do toho vstupuje Q1, časové pásmo, měna a výběr správných tabulek.
Představte si anonymní e-commerce firmu, která expandovala na Slovensko. Obchod sleduje tržby podle trhu, marketing podle měny kampaní, logistika podle doručovací adresy a finance podle účetní jednotky. Když se CEO zeptá, jak si vede Slovensko, nejde jen o SQL. Nejdřív musí být jasné, která definice slovenského trhu je pro rozhodnutí relevantní.
Tohle není problém LLM. Je to problém nepřipraveného prostředí. Agent bez kontextu neví, které významy jsou ve firmě správné. Umí napsat dotaz, ale nemá jak garantovat, že dotaz odpovídá tomu, co člověk opravdu potřeboval zjistit.
Agentní BI nezačíná výběrem modelu. Začíná tím, že firma vytáhne z hlav lidí pravidla, výjimky a dohody, podle kterých se dnes rozhoduje.
Co musí tvořit datový kontext
Když řeknu, že kontext je infrastruktura, nemyslím tím jeden dlouhý dokument v Notionu. Agent nepotřebuje román o firmě. Potřebuje sadu strojově i lidsky použitelných zdrojů, které umí najít, citovat, ověřit a použít při práci.
V datovém prostředí bych začal těmito bloky. Nejsou to teoretické kategorie. Jsou to místa, kde agent bez přípravy nejčastěji začne hádat.
Definice metrik
Každá důležitá metrika potřebuje jasnou definici: název, kterému rozumí business, popis, entitu, výpočet, primární klíč, výjimky, výchozí filtry a informaci, kde se používá. Ideálně nejde jen o text pro lidi, ale o strukturovaný zdroj, ze kterého může vycházet agent, testy i dokumentace.
{
"entity": "orders",
"business_name": "Objednávky",
"description": "Objednávka představuje potvrzený nákup zákazníka.",
"category": "core_kpi",
"kpi_tier": "main",
"is_main_kpi": true,
"primary_key": "order_id",
"default_metric": {
"name": "Počet objednávek",
"calculation": "count(distinct order_id)"
}
}
Důležité je, že metrika není jen vzoreček. Je to dohoda mezi businessem a datovým týmem. Bez ní bude agent pokaždé znovu rozhodovat o věcech, které už měly být rozhodnuté.
U jednoduchých metrik, jako je počet objednávek nebo celkové revenue, se agent často trefí alespoň přibližně. U složitějších metrik, například marže, to začne bolet rychle. Co všechno patří do nákladů? Jak pracujeme s dopravou, vratkami, slevami, refundy, marketplace poplatky nebo rozdílem mezi účetním a manažerským pohledem? Pokud firma nemá odpověď strukturovaně popsanou, agent si ji doplní podle vzorců, které zná z trénovacích dat. To ale nemusí být vaše definice.
Slide výše je modelový příklad, ne výsledek produkčního měření ani univerzální benchmark. Ilustruje jednoduchý princip: když metrika existuje strukturovaně, agent nemusí při každém dotazu znovu hádat její logiku.
Metadata tabulek a sloupců
Druhá velká oblast jsou metadata. Tedy ne data samotná, ale informace o tom, co tabulky a sloupce znamenají. Tabulky a sloupce musí mít popisky. Stejně pojmenované sloupce napříč tabulkami by měly mít stejný význam i datový typ.
Tady se často lámou zdánlivé detaily. PSČ není celé číslo jen proto, že se skládá z číslic. Měny, časová pásma a jednotky nepatří do domněnek, ale do názvů, popisků a pravidel. Čím víc si musí agent domýšlet, tím větší prostor má pro špatnou interpretaci.
Praktický detail: popisky sloupců se dají využít i jako instrukce pro agenta. Řekněte mu, kdy má sloupec použít, kdy se mu vyhnout a na co si dát pozor. Input pro AI je často levnější než špatný output.
Právě metadata na úrovni sloupců firmy často zanedbávají. Přitom pro agenta jsou to směrovky. Čím lépe popíšete, co sloupec znamená, kdy vzniká, v jakých jednotkách je hodnota a jaké má výjimky, tím méně musí agent zkoušet a hádat.
Čím víc musí agent hádat, tím dražší a méně důvěryhodná bude jeho odpověď.
Popis technické infrastruktury
Vedle významu dat potřebuje agent rozumět i prostředí, ve kterém pracuje. Musí vědět, jaké nástroje firma používá a k čemu slouží: kde běží sklad, kde jsou transformace, kde jsou testy, kde se nasazuje, kde se čtou logy a jaké akce může udělat přes CLI, API nebo MCP.
Pokud je systém ovladatelný jen klikáním v rozhraní, agent se bude dřív nebo později zasekávat. Ne proto, že by neuměl kliknout, ale protože klikací workflow je pomalé, hůř auditovatelné a mnohem hůř se popisuje jako opakovatelný postup.
Popis datového modelu
Datový model potřebuje vlastní rozcestník. Nestačí, že existuje v hlavách lidí, kteří sklad stavěli. Agent potřebuje vědět, jestli používáte star schema, snowflake, Data Vault nebo vlastní vrstvy. Potřebuje chápat, k čemu slouží staging, mart a reportingové tabulky, kde jsou zdroje pravdy a kde jen pracovní mezivýstupy.
Patří sem i testovací principy: co musí nová změna splnit, než se jí dá věřit. Tohle je přesně místo pro `.skills`, repozitářové instrukce a architektonická pravidla. Ne jako dekorace pro AI, ale jako způsob, jak držet konzistenci práce napříč lidmi i agenty.
Datové typy, měny a časová pásma
Pak jsou tu pravidla, která vypadají nudně, ale rozhodují o správnosti odpovědi. Patří sem datové typy, měny, časová pásma, jednotky a pravidla pro výjimky. Člověk, který ve firmě pracuje dlouho, je často bere jako samozřejmost. Agent je ale jako samozřejmost nezná.
Proto je potřeba je napsat. Například: všechny timestampy převádíme na UTC. Finanční hodnoty reportujeme v EUR a kurz bereme z konkrétní tabulky. Refundy patří do stejného období jako původní objednávka, nebo do období zpracování. Bez takových pravidel agent nebude odpovídat podle jedné firemní reality. Vyrobí si vlastní variantu.
Testy, evaluace a datové kontrakty
Jakmile výstupy ovlivňují uživatele, nestačí doufat, že se agent trefí. Potřebujete testy nad daty, evaluace nad typickými otázkami a datové kontrakty mezi zdroji, transformacemi a konzumenty. Nová verze, která může změnit odpovědi, má projít sadou příkladů stejně jako aplikace prochází testy.
Jak poznat čistý sklad pro agenty
Tohle všechno může znít abstraktně, takže bych použil jednoduchý test. Vezměte nového člověka, který umí s danou technologií, ale nezná vaši firmu. Dejte mu přístup do skladu, dokumentaci a popisy. Pokud se zvládne rozumně zorientovat bez toho, aby musel pořád hledat člověka, který „jediný ví, jak to funguje“, máte dobrý základ i pro agenta.
Čistý sklad neznamená dokonalý sklad. Znamená sklad, kde tabulky nesou srozumitelné názvy, sloupce mají popisy, vrstvy modelu dávají smysl, hlavní metriky mají definice a existuje rozcestník, podle kterého se člověk i agent dokážou rozhodnout, odkud vycházet. Perfektní stav není nutný. Předatelný stav je nutný.
Největší riziko není cena tokenů, ale ztráta důvěry
Když agent nemá dobrý kontext, firma to zaplatí několikrát. Část nákladu je vidět hned: agent spotřebuje víc tokenů, protože musí víc přemýšlet a víc si nechat vysvětlovat. Vygeneruje víc SQL dotazů, protože zkouší cesty, které by při dobrém modelu a metadatech nemusel zkoušet. Zatíží databázi, což u velkých firem může být citelný provozní náklad.
Nejhorší náklad je ale ztráta důvěry. Pokud agent začne vracet nespolehlivé odpovědi, nebo dokonce rozbije dashboardy, které tým používá, lidé přestanou věřit nejen agentovi, ale i datovému týmu a číslům obecně. Finanční náklady se dají optimalizovat. Ztráta důvěry v data se opravuje mnohem hůř.
U dotazů je proto důležité rozlišovat objem a efektivitu. Pokud agent generuje hodně query proto, že odpovídá na hodně uživatelských otázek, může to být srozumitelný provozní náklad. Pokud ale na jednu běžnou otázku potřebuje desítky pokusů, je to signál, že mu chybí kontext, metadata nebo správný datový model.
U opakované práce potřebujete agentní workflow řídit
U agentů, kteří opakovaně pracují s firemními daty nebo mění firemní logiku, nestačí samotný prompt. Firma potřebuje řídit, jaký kontext agent čte, jaké akce smí provádět, co změnil a jak se výsledek ověří. CLI, MCP, API, GitHub a CI/CD pipeline dávají praktické způsoby, jak tuto práci zpřístupnit, verzovat a kontrolovat. Proto je považuji za důležitou součást návrhu produkčních datových a agentních systémů.
Proč? Protože agent potřebuje dělat práci opakovatelně. Potřebuje číst kontext, spouštět příkazy, měnit soubory, zakládat pull requesty, pouštět testy, zapisovat výsledky a nechat člověka zkontrolovat diff. Musí být jasné, jakou akci provedl, z čeho vycházel, co změnil a podle čeho poznáme, že výstup prošel.
Proto je potřeba vybírat technologický stack i podle toho, jestli se dá řídit programaticky. Pokud nástroj nemá API, CLI, MCP rozhraní, auditovatelný export, integraci do GitHubu nebo cestu do CI, bude pro agentní workflow slabým místem. Může být dobrý pro člověka v prohlížeči, ale špatný pro systém, který má pracovat opakovaně, testovatelně a pod kontrolou.
Ruční klikání a nejasná oprávnění jsou v agentním prostředí technický dluh. Ne hned první den, ale ve chvíli, kdy má agent pracovat nad produkční logikou, daty nebo rozhodnutími, začne být vidět, že bez programatických rozhraní není co bezpečně řídit.
Klikací nástroj může být dobrý pro člověka. Pro agenta je lepší rozhraní, které jde popsat, spustit, verzovat a zkontrolovat.
V praxi to znamená, že agenti nad daty nejsou jen projekt datového týmu. Týká se to i toho, jak firma verzuje logiku, jak popisuje systémy, jak kontroluje změny, jak ukládá rozhodnutí a jak rychle umí převést nepsané know-how do použitelného kontextu.
Člověk musí zůstat v kolečku
V agentním BI je human-in-the-loop nutnost, ne slabost systému. Česky řečeno: člověk musí zůstat v kolečku. Ze začátku by měl někdo z datového týmu kontrolovat otázky, které agent dostává, SQL dotazy, které generuje, a odpovědi, které vrací. Ne proto, aby agent zůstal navždy ručně řízený, ale aby se systém zlepšoval.
Prakticky to znamená odchytávat otázky, na které agent neuměl odpovědět, nejasné interpretace metrik, drahé nebo zbytečné query a odpovědi, kde si agent nebyl jistý. Část kontroly půjde časem převést do evaluací. Část zůstane u lidí, protože někdo musí rozhodovat, jestli odpověď odpovídá business realitě, ne jen syntaxi SQL.
Důležitý výstup kontroly není jen opravená odpověď. Důležitý výstup je doplněný kontext: lepší popis sloupce, jasnější definice metriky, nový eval příklad, pravidlo pro výjimku nebo dokumentace procesu, který doteď žil jen v hlavě jednoho člověka.
Checklist pro firmu: co připravit před agentem nad daty
Pokud bych měl firmě doporučit první kroky, nezačal bych velkým AI rolloutem. Použil bych tenhle tahák a ověřil, jestli má firma kontextový základ, na kterém se dá stavět.
- Ujasněte si, proč agentní BI chcete a jaký typ rozhodnutí nebo práce má zlepšit.
- Vyberte deset nejčastějších business otázek a zapište, jak na ně dnes odpovídá dobrý analytik.
- Popište hlavní KPI firmy: ty, které jsou v cílech týmů, ve vedení a v pravidelném reportingu.
- U hlavních metrik vytvořte strukturované definice včetně výjimek, filtrů, vlastníka a typických použití.
- Doplňte popisky klíčových tabulek a sloupců, hlavně tam, kde název nestačí nebo může mást.
- Sepište pravidla pro měny, časová pásma, datové typy, refundy, storna a další firemní výjimky.
- Popište vrstvy datového modelu: co je zdroj pravdy, co je pracovní mezivýstup a co je reportingový mart.
- Vytvořte agentní rozcestník: kde jsou data, jak se spouští dotazy, kde jsou testy a co agent dělat nesmí.
- Postavte eval sadu z reálných otázek a očekávaných odpovědí.
- Napojte změny na GitHub, CI a review, aby se kontext i logika měnily kontrolovaně.
- Při výběru nástrojů preferujte ty, které mají API, CLI, MCP nebo jiný programaticky ovladatelný vstup.
Nečekal bych na perfektní popis. Odkládání může být dražší než neúplný začátek. První verze definic metrik a dokumentace nemusí být ideální. Dá se migrovat, zpřesnit a rozšířit. Bez první verze ale agent nemá z čeho vycházet a tým nemá co zlepšovat.
Tohle nezní tak efektně jako demo, kde agent na první dobrou odpoví na otázku v chatu. Jenže právě tahle práce rozhoduje o tom, jestli agent po měsíci skončí jako hračka, nebo jako skutečná součást práce týmu.
Kdy firma ještě není připravená
Největší varovný signál je jednoduchý: klíčové znalosti jsou jen v hlavách lidí. Pokud se opakovaně říká „s tím musíme počkat na Pepu, ten jediný ví, jak to funguje“, agentní BI narazí velmi rychle. Agent nemůže použít znalost, která není nikde dostupná.
To neznamená, že firma nesmí začít. Znamená to, že první práce není výběr modelu ani nákup nového nástroje. První práce je převést kritické znalosti z hlav lidí do metrik, metadat, dokumentace, testů a pravidel, která může použít člověk i agent.
Pointa
AI agenti nezruší potřebu datových týmů. Spíš vytáhnou na světlo všechno, co dobré datové týmy dosud nosily v hlavě: definice, kompromisy, pravidla, doménové znalosti a cit pro to, co otázka opravdu znamená.
Firmy, které chtějí agenty používat vážně, musí tenhle kontext udělat dostupný, strukturovaný, testovatelný a ovladatelný přes nástroje. Pak má agent šanci pomoct. Bez toho bude jen rychlejší způsob, jak vyrábět přesvědčivě znějící nejistotu.
Pokud už rozhodujete, jak propojit data, metriky a AI, podívejte se na návrh architektury datových a AI systémů. Když potřebujete nejprve sladit lidi kolem konkrétní otázky, navazuje na téma firemní workshop Od ETL k AI agentům. Pokud ještě neznáte současný stav svých dat, začněte datovým auditem.