Firmy, které dnes z AI získávají největší hodnotu, nemají nutně lepší modely. Mají lepší datové základy.
Je dobré si přiznat, jak výrazně se samotný model propadl na seznamu věcí, které rozhodují o úspěchu AI projektu. Nejnovější jazykové a embeddingové modely jsou dnes dostupné prakticky všem a působivé demo lze postavit během několika dní.
Demo je jednoduché. Systém za ním už ne. Rozdíl mezi proof of conceptem a řešením, kterému může velká firma skutečně důvěřovat, proto většinou není v modelu. Rozhoduje, jestli se AI může opřít o data, která lze používat opakovaně, bezpečně a konzistentně.
Napříč více než 500 projekty pro více než 100 velkých firem od roku 2016 se opakovaně setkáváme se stejnými varovnými signály. Spadají do tří oblastí: zda lze věřit samotným datům, zda je současná architektura dokáže správně poskytovat a zda AI umí bezpečně pracovat s firemními znalostmi. Tady je deset nejdůležitějších a konkrétní doporučení, jak je řešit.
Nejdřív musíte věřit vlastním číslům
Ještě před architekturou a modely si položte jednodušší otázku: věří lidé ve vaší firmě číslům, se kterými už dnes pracují? Často ne. A AI tento problém velmi rychle odhalí.
1. Stejné KPI znamená pro každý tým něco jiného
Zeptejte se tří oddělení na tržby za minulý měsíc a možná dostanete tři různá čísla. Finance počítají vyfakturované tržby bez DPH, obchod pracuje s uzavřenými objednávkami a dashboard ukazuje ještě třetí hodnotu. Dlouho se s tím dalo žít, protože někdo v místnosti obvykle věděl, které číslo je v daném kontextu správné. AI asistent takový instinkt nemá. Použije definici, ke které dostal přístup. Jakmile vedení firmy dostane od stejného systému dvě protichůdné odpovědi, důvěra v něj mizí velmi rychle.
Řešení je méně technické, než se může zdát. Pro klíčové metriky stanovte jednu společnou definici a jasného vlastníka. Jakoukoli změnu definice řešte jako vědomé a komunikované rozhodnutí, ne jako úpravu, kterou si jeden tým provede sám pro sebe. Společný jazyk pro nejdůležitější KPI umožní AI spory o čísla řešit, ne vytvářet nové.
Co vidíme v praxi
Organizace se často domnívají, že mají problém s kvalitou dat.
Ve skutečnosti mají problém s konzistencí.
Data existují. Firma se prostě neshodne na tom, co znamenají.
2. Data vznikají jako reporty, ne jako datové produkty
V řadě firem data stále vznikají postaru. Někdo položí otázku, analytik vytvoří export, ručně ho vyčistí a pošle dál. Při další otázce celý proces začíná znovu. Samotný report nemusí být chybný. Problém je, že není znovu použitelný. Dva analytici tak mohou na stejnou otázku odpovědět dvěma různými čísly, aniž by bylo jasné, kdo za rozdíl odpovídá.
Přístup data jako produkt tento vztah mění. Kritický dataset už nevzniká pokaždé na objednávku, ale funguje jako dlouhodobě spravovaná služba. Má svého vlastníka, definovanou kvalitu a aktuálnost, jasný význam a plán dalšího rozvoje. Nejde o proces pro proces. Právě díky tomu se může AI zítra spolehnout na stejná data, ze kterých vycházela dnes.
3. Když se něco pokazí v datech, nikdo se to nedozví včas
Datové problémy většinou nepřicházejí s hlasitým alarmem. Feed dorazí pozdě, datová dávka se načte jen částečně nebo se nečekaně změní struktura některého pole. Dashboard přesto dál ukazuje číslo, jako by se nic nestalo.Ve světě reportingu si toho někdo dříve nebo později všimne. Ve světě AI už se mezitím chybná data mohla dostat do odpovědi zákazníkovi. Reporting dokáže pozdní data odpustit. AI ne.
První instinkt bývá monitorovat všechno. To ale většinou vede jen k záplavě alertů, které postupně všichni začnou ignorovat. Začněte datasety, na kterých závisejí vaše první AI use cases, a sledujte tři nejčastější problémy: zda data dorazila včas, zda se jejich objem výrazně neodchýlil od normálu a zda se bez upozornění nezměnila jejich struktura. Každý alert musí mít vlastníka a jednoduchý postup, co dělat dál. Monitorovat všechno vytváří šum. Monitorovat data, na kterých vaše AI skutečně závisí, vytváří důvěru.
I důvěryhodná data mohou narazit na špatnou architekturu
Řada firem si sjednotí definice a zlepší kvalitu dat, ale AI projekty přesto začnou narážet na další bariéru. AI totiž přináší typ workloadu, pro který většina současných datových systémů původně nevznikla. BI vysvětluje, co se stalo. AI stále častěji pomáhá rozhodovat o tom, co se má stát dál, a k tomu potřebuje vědět, co se děje právě teď. Právě tento rozdíl odhaluje limity architektury, které firmy dříve nemusely řešit.
Co vidíme v praxi
Firmy málokdy přestavují svou architekturu jen kvůli AI.
Častěji AI jen odhalí úzká hrdla, která tam byla vždy.
Architektura nebyla nikdy špatná. Byla jen postavena pro jiný typ otázek.
4. Všechno stále běží přes jeden monolitický datový sklad
Datový sklad je skvělý pro včerejšek. AI stále častěji potřebuje vědět, co se děje teď.
Klasický warehouse vznikal pro dávkové zpracování, historické agregace a SQL analytiku. Jakmile od něj začnete vyžadovat rychlé provozní dotazy s nízkou latencí, začnou se objevovat jeho limity. Platíte za výkonné úložiště i u dat, která takový výkon nepotřebují, eventová a nestrukturovaná data do něj zapadají obtížně a protože je velká část systému vzájemně propojená, jediná změna může ovlivnit desítky reportů. Všechno běží jednou rychlostí a ta jen málokdy odpovídá tomu, co potřebuje AI.
Řešením není další velká migrace. Je potřeba přijmout, že různé workloady mají různé požadavky. Historická analytika a operativní AI by neměly soupeřit o stejnou architekturu. Data mají svou „teplotu“. Historie, analytika a trénování modelů patří do lakehouse. Aktuální stavová data dávají větší smysl v rychlejší operativní vrstvě, která je pro tento účel navržená. Oddělením těchto dvou světů přestanete škálovat jeden drahý systém kvůli workloadům, které do něj nikdy nepatřily.
5. AI musí mít přístup k vašim klíčovým systémům, aby věděla, co se děje právě teď
Skutečná hodnota AI se často začne ukazovat ve chvíli, kdy dokáže odpovídat na provozní otázky. Vedoucí skladu chce vědět, které objednávky jsou právě teď blokované kvůli chybějícím zásobám. Likvidátor potřebuje zjistit, které případy dnes vyžadují manuální kontrolu. Finance se ptají, zda už byla konkrétní faktura zaplacena.
A právě tehdy řada firem zjistí, že jejich architektura nikdy nebyla navržená tak, aby dokázala bezpečně poskytovat aktuální provozní data. Jedinou možností pak bývá dotazovat se přímo ERP, CRM nebo SAPu. To může být pomalé, drahé a natolik rizikové, že to IT odmítne. A oprávněně.
Právě tady dává smysl operational data store (ODS). ODS funguje jako vrstva mezi core systémy a aplikacemi, které jejich data potřebují. Přes integrační vrstvu do něj proudí pouze relevantní aktuální stav. AI díky tomu dokáže rychle odpovídat na provozní otázky, aniž by zbytečně zatěžovala systémy, na kterých firma stojí. Zároveň vznikne jasná hranice mezi aktuálními provozními daty v ODS a historickými daty v lakehouse.
ODS ale nestavte pro všechno. Začněte třemi až pěti otázkami s nejvyšší obchodní hodnotou.
Co vidíme v praxi
Problém málokdy bývá technický.
Nikdo nikdy nemusel zpřístupnit provozní data mimo hlavní systém, takže neexistuje žádná bezpečná cesta, jak to udělat.
ODS je stejně tak organizační rozhodnutí jako architektonické.
6. „Real-time“ ve skutečnosti neznamená nic konkrétního
Téměř každá velká firma dnes tvrdí, že má real-time data. Když se ale zeptáte, co přesně tím myslí, definice se začne rozpadat. Pro jeden tým jde o kopii dat z core systémů aktualizovanou každých několik minut, pro jiný o hodinovou agregaci streamovaných dat. Další očekává event feed s garantovanou latencí v řádu sekund.
Někdy real-time vrstva existuje hlavně na architektonickém diagramu. Události sice proudí, ale není jasné kudy, nikdo nekontroluje jejich úplnost a nikdo nehlídá, zda skutečně dorazily včas. U AI může být důsledek nenápadný, ale drahý: systém reaguje pozdě a odpověď, která je technicky správná, už v okamžiku doručení nemusí platit.
Začněte proto definicí, ne technologií. Každý use case musí mít jasně stanovené, co pro něj „real-time“ znamená. Pak stačí relativně neatraktivní, ale spolehlivý základ: jasná cesta od zdroje ke konzumentovi, základní validace, monitoring úplnosti a včasnosti dat a člověk, který reaguje, když něco nefunguje. Poznáte, že systém funguje, když zpoždění zachytíte dřív než zákazník.
7. API vzniklo pro jednu aplikaci. A je to na něm vidět.
API je v mnoha firmách historický vedlejší produkt první webové nebo mobilní aplikace, která ho potřebovala. Funguje dobře, dokud se nepokusíte připojit něco dalšího: AI agenta, partnera nebo jiný interní tým. Pak začnou problémy. API je křehké, nemá verzování, každá změna rozbije jiného konzumenta a připojení čehokoli nového se mění v samostatný projekt. Právě tato třecí plocha často odděluje pilot od skutečného škálování.
Změna přístupu je jednoduchá: přestaňte API vnímat jako technické „potrubí“ jedné aplikace a začněte s ním pracovat jako s produktem. Stabilním, verzovaným a řízeným, navrženým kolem konkrétních business capabilities, ne jednotlivých kanálů. Pokud AI dostane stabilní rozhraní k aktuálním a jednoznačně definovaným datům, zmizí velká část workaroundů a ručně slepovaných integrací, na kterých AI projekty často zbytečně ztroskotají.
Co vidíme v praxi
Projekty AI málokdy selžou kvůli chybějícímu API.
Selhávají proto, že každé API bylo postaveno kolem jiné aplikace.
Řešením málokdy bývá více API. Řešením je méně, ale lepších API.
Jakmile AI začne pracovat s dokumenty, disciplína je důležitější než model
Strukturovaná data jsou pouze polovina problému. Velká část nejhodnotnějších AI use cases pracuje s dokumenty: interními směrnicemi, smlouvami, procesy, produktovou dokumentací nebo firemním know-how. A právě zde rozdíl mezi efektním demem a spolehlivým systémem téměř vždy stojí na disciplíně kolem dat.
8. AI odpovídá z vašich dokumentů. Nikdo ale neví z kterých.
Asistent sebevědomě odpoví na otázku týkající se HR směrnice nebo konkrétního ustanovení smlouvy. Odpověď zní správně. Nikdo ale nedokáže říct, z jakého dokumentu ji AI získala, a už vůbec ne, jestli je daný dokument stále platný.
Z našich zkušeností bývá skutečným rizikem málokdy samotný model. Problémem je obsah pod ním: zastaralé soubory, několik verzí stejného dokumentu, chybějící source of truth nebo dokumenty bez jasného vlastníka. AI totiž může vytvořit správnou odpověď ze špatného dokumentu. A v takovém okamžiku důvěra rychle mizí.
Bezpečná AI pracující s firemními znalostmi proto stojí na několika základních principech: používat pouze schválené zdroje, každému zdroji přiřadit vlastníka, respektovat přístupová oprávnění uživatele, pracovat pouze s aktuální verzí a u každé odpovědi uvádět zdroje.
Technicky jde o retrieval-grounded generation. Schválené dokumenty jsou uložené v dokumentovém úložišti s vektorovým indexem, systém vyhledá relevantní pasáže a odpověď vždy propojí s konkrétními podklady. Tím se z odpovědi, která pouze působí věrohodně, stává odpověď, kterou lze obhájit.
Co vidíme v praxi
Nejtěžší částí práce s dokumenty v AI je málokdy samotné vyhledávání.
Je to zjištění, kolik zdrojů pravdy je zastaralých, duplicitních nebo nemá žádného vlastníka.
AI tento problém nevytváří. Jen ho činí nemožným ignorovat.
9. Nikdo ve skutečnosti neví, jestli AI odpovídá a doručuje dobře
Zeptejte se většiny týmů, jak dobře jejich AI funguje, a často dostanete dojem místo měření: „Vypadá to dobře.“ To ale není kontrolní mechanismus.
Právě tak postupně proklouznou problémy: odpověď mimo téma, tvrzení bez zdroje nebo informace, kterou daný uživatel vůbec neměl vidět. A nikdo si toho nevšimne, dokud problém jako první neobjeví zákazník nebo auditor.
Měřit kvalitu přitom není tak složité. Sestavte sadu dvaceti až padesáti skutečných otázek z reálného používání a každou odpověď vyhodnocujte podle tří kritérií: je relevantní, opírá se o konkrétní zdroj a respektuje oprávnění uživatele? Test zopakujte pokaždé, když změníte zdroje nebo proces.
Vedle toho sledujte několik provozních signálů: jak často AI eskaluje požadavek na člověka, jak často odpověď nenajde a kolik odpovědí obsahuje citaci zdroje. Cílem není perfektní skóre. Cílem je mít dostatek důkazů pro rozhodnutí: tohle můžeme škálovat, tohle musíme upravit a tohle bychom měli zastavit.
10. AI patří všem. Takže za ni neodpovídá nikdo.
Poslední signál často rozhoduje o tom, zda se podaří vyřešit i těch předchozích devět. Pokud AI use case nemá vlastníka a každý scénář prochází stejným procesem, firma obvykle skončí v jednom ze dvou extrémů: buď je příliš opatrná na to, aby cokoli nasadila, nebo příliš benevolentní na to, aby AI používala bezpečně.
Stejný asistent může být téměř bez rizika při sumarizaci interního FAQ a zároveň představovat podstatně větší problém ve chvíli, kdy připravuje výstup, podle kterého se rozhoduje zákazník. Přesto firmy často oba případy řídí stejně.
Dobře nastavená AI governance není byrokracie. Je to mechanismus, který umožňuje AI rozšiřovat bez zbytečného strachu. Praktický přístup může být relativně jednoduchý: každý use case musí mít vlastníka, jasně definovanou úroveň rizika a kontrolní mechanismy odpovídající tomuto riziku. Nízkorizikové scénáře mohou běžet automaticky, pokud existuje záznam o jejich činnosti. U rizikovějších případů přidejte lidskou kontrolu, omezené zdroje a jasný eskalační proces.
Pod tím vším stačí pět základů: vlastník, schválené zdroje, přístupová pravidla, auditní stopa a proces pro řešení incidentů. Smyslem není AI zpomalovat. Naopak. Cílem je vytvořit takové podmínky, aby ji firma mohla rozšiřovat s dostatečnou kontrolou a důvěrou.
Shrnutí
Základem je strategie. Těchto deset bodů nejsou oddělené problémy. Jsou to různé projevy jedné základní otázky: Dokáže vaše firma svým vlastním datům důvěřovat natolik, aby na nich mohla stavět opakovaně, bez toho, že u každého dalšího AI projektu začne znovu od nuly?
Stejný vzorec se opakuje od prvního bodu až po poslední. AI tyto nedostatky nevytvořila. Pouze je odkryla ve chvíli, kdy na nich začalo něco skutečně záviset.
Debata o AI ve firmách stále často začíná u modelů. V organizacích, kterým se AI daří, ale začíná u dat. Jazykové modely jsou každým měsícem dostupnější. Důvěryhodná firemní data ne.
Postavit AI je dnes překvapivě snadné. Postavit AI, které může firma důvěřovat, stále není.
Rozdíl není v modelu, frameworku ani cloudové platformě. Je v tom, zda má firma datový základ, o který se AI může opírat opakovaně, bezpečně a ve větším měřítku. A právě to ve skutečnosti znamená být připravený na AI.
.avif)