Jak VSE proměnila zákaznická data v personalizované energetické poradenství

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.

Když se dnes řeší bezpečnost kolem vibe coding toolů, často to zní, jako by šlo o úplně nový problém. Ve skutečnosti nejde o nic nového. Jen jsme si poslední roky zvykli spouštět cizí kód, cizí dependencies a čím dál častěji i cizí shell commandy přímo na svém lokálním stroji, kde máme SSH klíče, .env soubory, přihlášený browser, přístupy do cloudu a často i produkci.

AI tooling ten problém nevymyslel. Jen ho dost zesílil a udělal viditelnější.

Na macOS je to podle mě vidět asi nejlíp. Spousta lidí nechce vyvíjet v Dockeru, protože DX jde rychle dolů a kontejnery na Macu pořád nejsou bez overheadu. Takže reálný default je pořád stejný: všechno běží na host machine a doufá se, že se nic nestane.

Tohle funguje přesně do chvíle, než to nefunguje.

LiteLLM jen připomněl starý problém

24. března 2026 se na PyPI objevily kompromitované verze litellm 1.82.7 a 1.82.8. Nešlo o žádný exotický exploit. Stačilo udělat pip install a do prostředí se dostal škodlivý .pth soubor, který se spouštěl při startu Pythonu.

Ten pak sahal po věcech, které na vývojářském stroji typicky najde snadno:

• SSH klíče
• .env soubory
• cloud credentials
• další secrets a konfigurační soubory

Pak je odesílal na remote server.

Na tomhle incidentu je důležité hlavně to, jak banální ten attack path byl. Nepotřeboval rozbít Python, obejít kernel ani přesvědčit člověka, aby spustil něco extra. Stačilo, že vývojář udělal to, co dělá běžně každý den: nainstaloval si dependency.

Paradoxně se na celou věc přišlo rychleji i proto, že malware nebyl úplně dobře napsaný a na některých strojích odpálil fork bombu. Kdyby se držel při zemi a jen tiše exfiltroval data, je dost možné, že by to déle unikalo pozornosti.

Podle mě by tomuhle podlehla velká část běžných developerů, ne jen lidi, kteří experimentují s vibe codingem. Důvod je jednoduchý: málokdo má lokální Python prostředí opravdu izolované.

A ani JavaScript svět na tom nebyl líp

Tohle mimochodem není jen Python story.

30. a 31. března 2026 se kompromitoval i axios, jedna z nejpoužívanějších knihoven v JavaScript světě. Útočník převzal maintainer účet na npm a publikoval škodlivé verze axios@1.14.1 a axios@0.30.4.

Zajímavé je, že škodlivý payload nebyl přímo v samotném axiosu. Ty verze jen přidaly novou transitive dependency plain-crypto-js, která se spouštěla přes postinstall hook. Jinými slovy: i tady stačilo udělat obyčejný install a z dependency chainu se stal execution chain.

To je přesně důvod, proč mi přijde nebezpečné tvářit se, že supply-chain riziko je jen problém nějakých pochybných balíčků z okraje ekosystému. Není. Minulý týden se to ukázalo i v jednom z nejběžnějších HTTP clientů pro Node.js.

exclude-newer je rozumný default

Jeden z mála levných guardrailů, které dávají smysl skoro každému, je neinstalovat úplně čerstvé releasy balíčků.

V uv jde použít exclude-newer, takže si dependency resolution omezíte jen na balíčky publikované před zvoleným datem:

‍

[tool.uv]
exclude-newer = "2026-03-24"

‍

Tohle není magická obrana. Jen si tím kupujete čas. Když budete držet třeba 14denní odstup, je slušná šance, že se během té doby na kompromitovaný release přijde a někdo ho stáhne nebo alespoň rozjede warningy napříč komunitou.

Úplně stejná logika platí pro AI coding tools

Stejně jako nechcete bezmyšlenkovitě pouštět čerstvé dependencies na hostu, nechcete na hostu pouštět ani code generátor s plným přístupem ke všemu okolo.

Tohle není argument proti Codexu, Claude Code ani jakémukoliv jinému nástroji. Je to argument proti tomu, jak velký trust těm nástrojům dáváme by default.

Lehké sandboxy jsou dobrý začátek. Codex CLI na macOS historicky používal sandbox-exec a umí tím dost omezit, kam proces smí sáhnout. V Claude Code jde sandbox zapnout přes /sandbox. V obou případech je to výrazně lepší než režim, kde agent vidí celý disk a může bez omezení pouštět shell.

Tohle má dvě praktické výhody:

• agent typicky vidí jen repozitář nebo explicitně povolené cesty
• nemusíte potvrzovat každou drobnost jen proto, abyste měli aspoň nějaký control surface

Pro běžné čtení, editaci souborů a část shell práce je to fakt příjemný middle ground.

Kde tenhle model naráží

Problém je, že lehký sandbox není totéž co skutečná izolace.

Jakmile nástroj potřebuje dělat něco trochu praktičtějšího, začnou vylézat hrany:

• instalace balíčků přes uv, pip, npm nebo podobné nástroje často sahá do globálních cache
• browser tooling nemusí uvnitř sandboxu fungovat dobře nebo vůbec
• některé MCP servery potřebují přístup mimo boundary repa
• dřív nebo později narazíte na command, který prostě musíte pustit mimo sandbox

A v ten moment se stejně vyhodí otázka na vibecodera jestli může systém sandbox odejít a většina klikne prostě na "Yes".

Proto mi přijde důležité neplést si "má nějaký sandbox mode" s "je to bezpečně izolované".

Co podle mě dává smysl víc

Pokud chceme agenty nebo code generátory používat vážně, potřebujeme reálný sandbox. Ideálně separátní VM nebo microVM pro každý projekt. Na Macu to může být něco ve stylu Lima nebo obdobné VM-based řešení. Docker sandboxy jsou v principu podobný směr, i když na macOS často naráží na performance a DX.

Pointa ale není konkrétní produkt. Pointa je trust boundary.

Do takového prostředí přesunete jen to, co ten konkrétní projekt opravdu potřebuje:

• checkout repa
• project-scoped credentials
• lokální cache jen pro ten projekt
• případně browser session nebo MCP servery, ale zase jen tam, kde to dává smysl

Tím snížíte blast radius hned dvakrát.

Za prvé: když agent spustí destruktivní command typu rm -rf /, tak zničí maximálně svůj sandbox.

Za druhé: když nainstalujete kompromitovanou dependency typu infikovaného litellm, tak z ní neodtečou všechny credentials z celého laptopu, ale maximálně to, co jste do toho konkrétního prostředí dali. Ideálně jen dev secrets pro jeden projekt.

To pořád není příjemný incident. Ale je to o řád lepší incident.

Classifier je fajn, ale není to sandbox

Claude Code teď přidal i auto mode, kde nad citlivějšími akcemi běží další classifier. Ten vyhodnocuje transcript a jednotlivé tool calls, hlavně Bash commandy a další akce mimo repo, a snaží se blokovat věci jako data exfiltration, credential hunting nebo destruktivní zásahy mimo scope úkolu.

To je rozumný posun. Approval fatigue je reálná a ruční odklikávání všeho není moc udržitelný model.

Ale i tady je podle mě důležité držet si správné očekávání: classifier je guardrail, ne izolace.

Stejně tak to neřeší supply-chain problém. Pokud si uvnitř důvěryhodného prostředí nainstalujete škodlivý balíček, classifier nad Bash commandy vám nepomůže proti tomu, co ten balíček provede při importu nebo startu interpreteru.

Co bych z toho bral jako praktický default

Můj aktuální take je jednoduchý:

• nepouštět úplně čerstvé dependencies bez odstupu
• neprovozovat AI coding tools přímo na host machine s plným přístupem
• když už používám lehký sandbox, nebrat ho jako finální řešení
• pro důležitější práci mít per-project izolované prostředí s omezeným blast radiusem

Tohle všechno platilo už dávno předtím, než někdo vymyslel termín vibe coding.

Jen teď už není moc kam uhýbat. Když dáte agentovi shell, filesystem, browser a credentials, dáváte mu v praxi velmi silné pravomoci. A jak ukázal LiteLLM incident, podobně silné pravomoci dostává i obyčejný package manager ve chvíli, kdy mu bez izolace dovolíte instalovat cizí kód přímo na svůj laptop.

To není niche security debata. To je docela obyčejný engineering default, který jsme měli mít už dávno.

Apple právě pracuje na novém container enginu který tohle všechno bude mít doufám built in. Do té doby se snažím opravdu koukat kdykoliv se spouští příkazy mimo sandbox.

Současná situace

Za posledních pár měsíců se v oblasti AI a e-commerce objevilo několik zásadních novinek:

• Google představil UCP (Universal Commerce Protocol) – otevřený standard pro „agentic commerce“, který sjednocuje, jak AI agent mluví s merchantem: katalog, košík, doprava, platba, objednávka.
• OpenAI a Stripe dříve uvedli ACP (Agentic Commerce Protocol) – standard pro agentní checkout v ekosystému ChatGPT.
• Současně se rozšířil MCP (Model Context Protocol) jako obecný standard pro volání nástrojů a služeb a OpenAI Apps SDK jako produktová/distribuční vrstva pro agentní aplikace.

‍

Jinými slovy: internet si začíná definovat standardizované „koleje“, po kterých budou AI agenti nakupovat. A trh se posouvá od režimu „AI něco doporučí“ k režimu „AI nákup skutečně provede“.

‍

V článku probereme:

• co znamená agentic commerce v praxi,
• jak spolu souvisí UCP, MCP, Apps SDK a ACP,
• co tyto protokoly řeší – a co naopak neřeší,
• a kde dává smysl custom agentic commerce – přesně typ práce, které se věnujeme v BigHub.

‍

Co je agentic commerce

Agentic commerce je forma digitálního obchodování, kdy autonomní AI agent obslouží část nebo celý nákupní proces za člověka či firmu – od hledání přes porovnávání až po zaplacení.

Typický scénář:

„Najdi mi běžecké boty na maraton do 3 000 Kč, které mi stihnou přijít do dvou týdnů.“

‍

Agent poté:

1. pochopí zadání,
2. projde nabídky více obchodníků,
3. porovná parametry, recenze, cenu a dopravu,
4. připraví shortlist,
5. po schválení uživatelem nákup dokončí – ideálně bez toho, aby člověk musel řešit klasický webový košík.

‍

Podobné scénáře se netýkají jen B2C. Stejný princip lze použít pro:

• interní nákup materiálu,
• B2B objednávky,
• opakované doplňování zásob,
• servisní a reklamační procesy.

‍

Směr je jasný: AI se posouvá z roviny „pomoz mi vybrat“ do roviny „postarej se o to“.

‍

MCP, Apps SDK, UCP, ACP

MCP – obecný standard pro nástroje a capabilities

MCP (Model Context Protocol) je:

• obecný standard pro to, jak agent volá nástroje, API a služby,
• doménově neutrální vrstva („umím mluvit s CRM, pricingem, katalogem, ERP…“),
• způsob, jak agent „vidí“ svět skrz capabilities, které má k dispozici.

Zjednodušeně: MCP = jak agent sahá do vašich systémů.

‍

OpenAI Apps SDK – produktová a distribuční vrstva

OpenAI Apps SDK:

• řeší UI, runtime a distribuci agentů (ChatGPT Apps, rozhraní pro uživatele),
• umožňuje rychle zabalit agenta do produktu:
  • chat, formuláře, akce,
  • publikace do ekosystému ChatGPT,
  • základní správu a běh.

Zjednodušeně: Apps SDK = jak z agenta udělat reálně používaný produkt.

‍

UCP – doménový standard pro commerce workflow

UCP (Universal Commerce Protocol) od Google a partnerů:

• je doménový standard pro commerce,
• sjednocuje, jak agent mluví s merchantem o:
  • katalogu, variantách a cenách,
  • košíku, dopravě, platbě, objednávce,
  • slevách, věrnostních programech, refundech a trackingu,
• je navržený tak, aby fungoval napříč Google Search, Gemini a dalšími AI surfaces.

Zjednodušeně: UCP = konkrétní jazyk a workflow nákupu.

ACP – standard pro agentní checkout v ChatGPT

ACP (Agentic Commerce Protocol) od OpenAI/Stripe:

• řeší podobnou doménu z pohledu ChatGPT ekosystému,
• soustředí se silně na checkout, platby a objednávku,
• stojí za funkcemi typu Instant Checkout v ChatGPT.

Z pohledu obchodníka jsou UCP a ACP konkurenční commerce standardy (nikdo nechce tři různé integrace).

Z pohledu architektury jde ale o možné „dialekty“, které může agent používat podle kanálu, odkud přichází (ChatGPT vs. Google / Gemini).

Co tyto standardy řeší – a co ne

Společné je jedno - UCP ani ACP z agenta neudělají „mozek“. Jen mu dají jednotný jazyk.

Standardy typicky řeší:

• jak agent formálně komunikuje s merchantem a checkoutem,
• jak strukturovaně vypadají nabídky a objednávky,
• jak bezpečně probíhá platba a autorizace,
• jak se dá nákup zpracovat napříč různými AI kanály.

‍

Neřeší (a ani nemůžou řešit):

• kvalitu a strukturu produktového katalogu, atributů a dostupnosti,
• integraci do ERP, WMS/OMS, CRM, věrnostního systému, pricing enginu, kampaní,
• business logiku – marže vs. SLA vs. zákaznická zkušenost vs. obrat,
• governance, risk, schvalování – kdo má právo co objednat, kdy musí zasáhnout člověk, jak se auditují rozhodnutí.

‍

Prakticky to znamená:

• můžete být formálně „UCP/ACP ready“,
• ale agentická zkušenost bude pořád špatná, pokud:
  • data jsou nekonzistentní,
  • doručovací sliby se nedají splnit,
  • pricing a promo logika nedrží v multi-channel světě pohromadě,
  • agent nemá přístup k reálným stavům a interním pravidlům.

‍

Standard je nutné technické minimum, ne hotové řešení.

‍

Jak k agentic commerce přistupujeme v BigHub

V BigHub vnímáme UCP, MCP, ACP a Apps SDK jako stavební bloky infrastruktury. Na projektech se soustředíme na to, co nad nimi vytvoří skutečnou konkurenční výhodu.

Stavíme ML-powered commerce agenty, kteří umí:

• dynamické nabídky a cenotvorbu (bundly, alternativy, chytré trade-offy podle marže, SLA a priorit),

• personalizované vyhledávání a shortlist (kontext zákazníka, preference, rozpočet, historie interakcí),

• argumentaci a práci s námitkami (proč právě tahle varianta, srovnání možností, vysvětlení trade-offů),

• a v neposlední řadě hladký checkout, přes platbu a finální nákup.

Nad tím stavíme integrační vrstvu přes MCP (capabilities + napojení na core systémy). Jako UI a distribuční vrstvu často používáme OpenAI Apps SDK, když potřebujeme rychle dostat agenta k reálným uživatelům. Tam, kde to dává smysl, využíváme standardy jako UCP/ACP, místo abychom psali proprietární integrace pro každý kanál zvlášť.

‍

Kde dává smysl custom agentic commerce

Standardy (UCP/ACP/MCP) mají velkou hodnotu tam, kde:

• nechcete vymýšlet vlastní protokol pro napojení na AI kanály,
• potřebujete interoperabilitu (ChatGPT, Google/Gemini, další),
• chcete snížit integrační zátěž na straně merchantů.

Custom přístup dává největší smysl v těchto oblastech:

‍

1) Propojení agenta s core systémy

• ERP, WMS/OMS, CRM, věrnostní programy, pricing engine, reklamace, call centrum…
• agent musí žít v reálné provozní architektuře, ne v izolovaném sandboxu.

Typicky je potřeba vlastní integrační a orchestrace vrstva, která:

• „nahoru“ mluví UCP/ACP/MCP,
• „dolů“ mluví vašimi konkrétními systémy a API.

‍

2) Doménová logika a business pravidla

Tady vzniká skutečná konkurenční výhoda:

• kdy může agent objednat autonomně a kdy má jen doporučovat,
• jak balancuje marži, SLA, dostupnost, zákaznickou zkušenost a obrat,
• jak zachází s akcemi, věrnostními body, cross-sell / up-sell scénáři.

Tohle už není otázka protokolu, ale konkrétních pravidel nad daty a KPI vaší firmy.

‍

3) Multi-kanál a mix B2C / B2B / interních agentů

Reálný svět vypadá takto:

• B2C e-shop,
• B2B portál,
• interní agent pro nákup,
• prodejní asistent na prodejně,
• agent v zákaznické péči.

Custom framework umožní:

• sdílet logiku napříč rolemi a kanály,
• pracovat s oprávněními a limity,
• řešit scénáře typu „AI začne v chatu, dokončí na pobočce“.

‍

4) Evropský kontext: regulace, bezpečnost, data residency

U evropských firem hraje velkou roli:

• regulace (EU AI Act, GDPR, sektorová regulace),
• bezpečnostní politika, interní audity,
• kde běží data a modely (US vs. EU),
• jak vysvětlitelná a auditovatelná jsou rozhodnutí agenta.

Standardy jsou globální, ale architektura a governance musí být lokální a na míru.

‍

Co si z UCP a spol. odnést jako retailer / enterprise

Pokud přemýšlíte o agentic commerce, stojí za to položit si několik praktických otázek:

• Jsme „agent-ready“ nejen na úrovni protokolu, ale i dat a procesů?
• Ve kterých use-casech chceme, aby agent nákup opravdu provedl, a kde má zůstat jen u doporučení?
• Jak agentic commerce zapadne do našich stávajících systémů, pricingu, kampaní a SLA?
• Kdo u nás vlastní agentní iniciativy (KPI, P&L) a jak je budeme měřit?
• Které části dává smysl řešit přes standardy (UCP/ACP/MCP) a kde už potřebujeme vlastní agentní framework?