Datové inženýrství v AI době: zajímavá práce nikdy nebyla jen v transformacích

AI umí psát transformace, ale kontext za nás nevyřeší

V posledních měsících se často řeší, co zůstane jádrem softwarového nebo datového inženýrství, když AI zvládá čím dál větší část kódu. A „psaní SQL“ to podle mě určitě není. To bude sice pořád potřeba, jen to přestane být ta nejcennější část práce.

Skutečně těžké věci jsou jinde:

• Co přesně znamená obrat?
• Která definice konverze je správná?
• Kdo vlastní metriku marže?
• Počítáme vratky podle data objednávky, nebo podle data dobropisu?
• Která tabulka je zdroj pravdy?
• A co se stane, když marketing a finance používají stejné slovo pro dvě různá čísla?

Tohle AI sama nevyřeší.

Může navrhnout SQL. Může odhadnout význam sloupce. Může doplnit dokumentaci. Ale nedokáže rozhodnout, čí definice je ta správná. Nedokáže domluvit finance, marketing a obchod na jednom společném významu.

A právě tam začíná ta zajímavá práce.

Skutečný problém není SQL. Skutečný problém je kontext

Představte si jednoduchý požadavek:

„Chceme dashboard s měsíčním obratem.“

Zní to triviálně. Jenže marketing může obrat chápat jako hodnotu objednávek vytvořených v e-shopu. Finance jako fakturovanou hodnotu po odečtení vratek a storen. Obchod jako hodnotu objednávek podle data uzavření. Každý může mít dobrý důvod. Každý může mít „pravdu”, ale v datech to budou tři různá čísla. A když se tohle nerozhodne vědomě, skončí to klasicky. V jedné tabulce vznikne revenue, vedle toho revenue_net, pak revenue_sales, pak revenue_finance_definition a za půl roku se nový člověk v týmu ptá, který sloupec má vlastně použít.

Tohle není problém špatného SQL. To je problém neřízeného významu a čím víc bude AI generovat pipeline, tím víc se tenhle problém zvětší. Protože když je jednoduché vytvořit další transformaci, vznikne jich víc. A s nimi víc míst, kde se definice potichu rozjedou. Dřív jsme to často maskovali tím, že tvorba pipeline byla pomalá. Teď, když ji AI zrychluje, začne být mnohem víc vidět, jestli máme pod kontrolou sémantiku dat.

Dokumentace nestačí

První reakce bývá: tak to lépe zdokumentujme. Napišme definice do katalogu, vytvořme datový slovník atd. To všechno je užitečné, ale samo o sobě to nestačí.

Problém dokumentace je, že je to snapshot. V určitý moment někdo popíše, co sloupec znamená. Jenže pipeline se změní. Zdrojový systém přidá nové pole. Byznys si upraví definici. A dokumentace zůstane stejná. Za chvíli jí nikdo nevěří, protože všichni tuší, že realita už je jinde. Proto podle mě nestačí brát význam dat jako text někde na wiki. Musíme ho brát jako součást infrastruktury.

Kvalitu dat dnes většina týmů testuje. Stejně tak bychom měli testovat i sémantiku — jestli sloupec znamená to, co o něm tvrdíme.

Rozdíl mezi dokumentací a kontraktem je jednoduchý. Dokumentace říká: „Takhle by to mělo být.“ Kontrakt říká: „Když to tak není, pipeline spadne.“ A to je úplně jiná úroveň spolehlivosti.

Kontext musí cestovat spolu s daty

Většina moderních datových platforem stojí na nějaké variantě vrstev typu Bronze, Silver, Gold. Raw data se načtou do Bronze, vyčistí se v Silver a agregují se do Gold. Nad tím vzniknou reporty, datové produkty nebo AI agenti. Jenže v každém kroku se něco ztrácí. Ne nutně hodnota dat, ale jejich původní kontext. Každá transformace dělá nějaké rozhodnutí. Něco filtruje, něco agreguje, něco přejmenuje, něco spojí a když kontext nežije vedle dat, ale jen v hlavě člověka, který pipeline kdysi stavěl, časem zmizí. Proto bude čím dál důležitější lineage, metadata a sémantická vrstva. Ne jako hezká vizualizace do prezentace, ale jako reálná infrastruktura, na které závisí důvěra v data. Agent, analytik nebo manažer by neměl dostat jen číslo. Měl by být schopen zjistit, odkud číslo přišlo, jak se spočítalo, podle jaké definice, s jakým omezením a jestli mu může věřit.

Bez toho je AI nad daty jen rychlejší cesta k sebevědomým nesmyslům.

AI agenti potřebují víc než přístup do BigQuery

Tohle je podle mě zásadní hlavně kvůli AI agentům. Když agent dostane přístup do BigQuery a umí napsat SQL, ještě to neznamená, že umí dělat dobrou analýzu. Má data. Ale nemusí mít kontext. Když se zeptá na obrat, musí vědět, který obrat. Hrubý, čistý, fakturovaný, objednávkový, po vratkách, bez DPH, s DPH, podle data objednávky nebo fakturace. 

Člověk se v takové chvíli často doptá. Napíše kolegovi. Ověří si definici. AI agent si často vybere nejpravděpodobnější interpretaci a pokračuje dál. A právě proto musí být význam dat explicitní. Ne schovaný někde v hlavách lidí nebo ve starém dokumentu. Musí být dostupný stejně jako samotná data. To je podle mě nová důležitá práce datových týmů: stavět platformy, které nejsou jen schopné data dodat, ale také vysvětlit, co znamenají.

Datař jako architekt kontextu

Datové inženýrství se tím posouvá. Dřív byla velká část práce o tom, jak data dostat ze zdroje do analytické vrstvy. Jak je vyčistit, transformovat, zorchestrovat, napojit na reporting. To pořád zůstává. Jen větší část té mechaniky převezme AI.

Hodnota dataře se bude víc přesouvat do věcí, které se automatizují mnohem hůř — návrh datových kontraktů, definice metrik, práce s vlastníky dat, governance, validace významu a rozhodování mezi různými byznysovými definicemi. A nakonec do budování důvěry v data napříč týmy.

Jinými slovy: méně „napiš mi transformaci“ a víc „pomoz firmě pochopit, co její data znamenají“, což je mnohem těžší práce. Ne proto, že by byla technicky složitější než SQL. Ale protože je technická i organizační zároveň. Musíte rozumět datům, infrastruktuře, byznysu i lidem, kteří ta čísla používají.

Jak to vidíme my

Pro nás tohle není jen teorie.

Když stavíme Dance nebo našeho Signals AI Analytika, pořád narážíme na stejnou věc: AI je užitečná jen do té míry, do jaké má správný kontext.

Analytik může odpovídat na otázky v přirozeném jazyce jen proto, že nestojí nad náhodnými tabulkami. Stojí nad datovou vrstvou, kde víme, co znamenají metriky, jak se počítají, odkud data přichází a co platí pro konkrétního klienta. AI může posílat smysluplné anomálie jen tehdy, když ví, co je normální chování metriky a jaký má byznysový význam.

A pokaždé, když přidáváme nového klienta nebo nový datový zdroj, vracíme se ke stejným otázkám:

• Kdo vlastní tuhle metriku?
• Kde žije její definice?
• Kdo ji schválil?
• Co se stane, když se změní?
• A jak zajistíme, aby stejný význam pochopil člověk i AI agent?

Tohle je práce, kterou za nás AI neudělá. Ale může nám pomoct ji dělat rychleji a škálovatelněji.

Práce dataře nekončí. Jen se posouvá

Je fér říct, že část práce, která mnoho lidí na datařině bavila, se bude automatizovat.

• Psaní transformační logiky
• Generování modelů
• Doplňování testů
• Refaktoring SQL
• Rutinní orchestrace

Pro někoho to může být ztráta a je zbytečné předstírat, že ne. Ale podle mě se tím datové inženýrství nestává méně zajímavé. Naopak. Méně času strávíme ručním psaním transformací a víc času tím, že budeme řešit důvěru, význam a použitelnost dat.

A to je nakonec možná ta část práce, která byla nejdůležitější vždycky.

Jen jsme ji často schovávali za SQL.