Odhalování neoprávněných odběrů elektřiny pomocí AI: Jak VSD zefektivnilo práci inspekčního týmu

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?

Problém: Limity tradičního vyhledávání

Tradiční fulltextové vyhledávání, založené na algoritmech jako BM25, má několik zásadních omezení:

1. Překlepy a variace

• Uživatelé často píší dotazy s překlepy nebo používají různé varianty názvů
• Tradiční vyhledávání vyžaduje přesnou shodu nebo velmi podobný text

2. Vyhledávání pouze v názvech

• Fulltextové vyhledávání typicky hledá pouze v konkrétních polích (například název produktu nebo entity)
• Pokud je relevantní informace v popisu nebo v souvisejících entitách, systém ji nenajde

3. Chybějící sémantické porozumění

• Systém nerozpozná synonyma nebo související koncepty
• Například dotaz "auto" nenajde výsledky obsahující "automobil" nebo "vůz", i když jde o stejný koncept
• Mezijazyčné vyhledávání je téměř nemožné – český dotaz nenajde anglické výsledky

4. Kontextové vyhledávání

• Uživatelé často hledají podle kontextu, ne přesných názvů
• Například dotaz "produkty od výrobce X" by měl najít všechny relevantní produkty, i když název výrobce není explicitně uveden v dotazu

‍

Řešení: Hybridní vyhledávání s embeddingy

Řešením je kombinace dvou přístupů: tradičního fulltextového vyhledávání (BM25) a vektorových embeddingů pro sémantické vyhledávání.

Vektorové embeddingy pro sémantické porozumění

Vektorové embeddingy převádějí text do vícerozměrného prostoru, kde podobné významy jsou blízko sebe. To umožňuje:

• Vyhledávání podle významu: Dotaz "notebook" najde výsledky obsahující "laptop", "přenosný počítač" nebo dokonce související koncepty
• Mezijazyčné vyhledávání: Český dotaz může najít anglické výsledky, pokud mají podobný význam
• Kontextové vyhledávání: Systém rozumí vztahům mezi entitami a koncepty
• Vyhledávání v celém obsahu: Embeddingy mohou být vytvořeny z celého dokumentu, nejen z názvu

Proč embeddingy samotné nestačí

I když jsou embeddingy mocným nástrojem, samy o sobě nejsou dostatečné:

• Překlepy: Vektorové embeddingy mohou mít problém s překlepy, protože malá změna v textu může vést k odlišnému embeddingu
• Přesné shody: Někdy chceme najít přesnou shodu názvu, což fulltextové vyhledávání dělá lépe
• Výkon: Vektorové vyhledávání může být pomalejší než optimalizované fulltextové indexy

Hybridní přístup: BM25 + HNSW

Ideální řešení kombinuje oba přístupy:

• BM25 (Best Matching 25): Tradiční fulltextový algoritmus, který exceluje v přesných shodách a zpracování překlepů
• HNSW (Hierarchical Navigable Small World): Efektivní algoritmus pro vyhledávání v prostoru vektorů, který umožňuje rychlé nalezení nejbližších sousedů v embedding prostoru

Kombinací těchto dvou přístupů získáme to nejlepší z obou světů: přesnost fulltextového vyhledávání pro přesné shody a sémantické porozumění embeddingů pro kontextové dotazy.

‍

Výzva: Správné seřazení výsledků

Najít relevantní výsledky je jen první krok. Stejně důležité je je správně seřadit. Uživatelé typicky klikají na první několik výsledků, takže špatné seřazení může výrazně snížit užitečnost vyhledávání.

Proč samotné seřazení (sort by) nestačí

Jednoduché seřazení podle jednoho kritéria (například data) není dostatečné, protože potřebujeme zohlednit více faktorů současně:

• Relevance: Jak dobře výsledek odpovídá dotazu (z fulltextového i vektorového vyhledávání)
• Obchodní hodnota: Výsledky s vyšší marží by měly být výše
• Čerstvost: Novější položky jsou často relevantnější než staré
• Popularita: Populárnější položky mohou být pro uživatele zajímavější

Scoring funkce: Kombinace více faktorů

Místo jednoduchého "sort by" potřebujeme komplexní scoring systém, který kombinuje:

1. Fulltextové skóre: Jak dobře výsledek odpovídá dotazu podle BM25
2. Vektorové distance: Sémantická podobnost podle embeddingů
3. Scoring funkce:
   • Magnitude funkce pro marži/popularitu (vyšší hodnoty = vyšší skóre)
   • Freshness funkce pro čas (novější = vyšší skóre)
   • Další obchodní metriky podle potřeby

Výsledné skóre je pak vážená kombinace všech těchto faktorů. Problém je, že správné váhy nejsou zřejmé a musíme je najít experimentálně.

‍

Hyperparameter search: Hledání optimálních vah

Správné nastavení vah pro fulltextové vyhledávání, vektorové embeddingy a scoring funkce je kritické pro kvalitu výsledků. Tento proces se nazývá hyperparameter search.

Vytvoření testovacího datasetu

Základem úspěšného hyperparameter search je kvalitní testovací dataset. Vytvoříme dataset dotazů, u kterých přesně víme, jak by měly vypadat ideální výsledky:

• Referenční výsledky: Pro každý testovací dotaz máme seznam očekávaných výsledků v správném pořadí
• Anotace: Každý výsledek je označen jako relevantní nebo nerelevantní, případně s prioritou
• Reprezentativní vzorky: Dataset by měl pokrývat různé typy dotazů (přesné shody, synonyma, překlepy, kontextové dotazy)

Metriky pro hodnocení kvality

Abychom mohli objektivně posoudit, zda jsou výsledky dobré, potřebujeme metriky, které porovnávají skutečné výsledky s referenčními:

1. Kontrola úplnosti (Recall)

• Obsahují výsledky vše, co by měly obsahovat?
• Jsou všechny relevantní položky přítomny v seznamu výsledků?

2. Kontrola pořadí (Ranking Quality)

• Jsou výsledky ve správném pořadí?
• Jsou nejrelevantnější výsledky na prvních místech?

Mezi konkrétní metriky patří například NDCG (Normalized Discounted Cumulative Gain), která hodnotí jak úplnost, tak správné pořadí výsledků. Další užitečné metriky zahrnují Precision@K (kolik relevantních výsledků je v prvních K pozicích) nebo MRR (Mean Reciprocal Rank), která měří pozici prvního relevantního výsledku.

Iterativní optimalizace

Proces hyperparameter search probíhá iterativně:

1. Nastavení počátečních vah: Začneme s rozumnými výchozími hodnotami
2. Testování kombinací: Systematicky testujeme různé kombinace vah pro:
   • Váhy fulltextových polí (například název produktu vs. popis)
   • Váhy vektorových polí (embeddingy pro různé části dokumentu)
   • Boost hodnoty pro scoring funkce (marže, čas, popularita)
   • Agregační funkce (jak kombinovat různé scoring funkce)
3. Hodnocení výsledků: Pro každou kombinaci spustíme vyhledávání na testovacím datasetu a vypočítáme metriky
4. Výběr nejlepších parametrů: Vybereme kombinaci s nejlepšími metrikami
5. Refinování: Pokud je to potřeba, zúžíme rozsah testování kolem nejlepších hodnot a opakujeme proces

Tento proces může být časově náročný, ale je nezbytný pro dosažení optimálních výsledků. Automatizace tohoto procesu umožňuje testovat stovky nebo tisíce kombinací parametrů a najít ty nejlepší.

‍

Sledování a iterativní zlepšování

I po optimalizaci parametrů je důležité systém kontinuálně sledovat a zlepšovat.

Sledování chování uživatelů

Klíčovou metrikou je, zda uživatelé klikají na výsledky, které jim systém nabízí. Pokud uživatel neklikne na první výsledek, ale až na třetí nebo čtvrtý, je to signál, že seřazení není optimální.

Co sledovat:

• Click-through rate (CTR): Kolik uživatelů klikne na výsledky
• Pozice kliknutí: Na které pozici uživatelé klikají (ideálně by měli klikat na první výsledky)
• Dotazy bez kliknutí: Dotazy, na které uživatelé vůbec nekliknou, mohou indikovat špatné výsledky

Analýza problémových případů

Když identifikujeme dotazy, kde uživatelé neklikají na první výsledky, měli bychom:

1. Zaznamenat tyto případy: Uložit dotaz, vrácené výsledky a pozici, na kterou uživatel klikl
2. Analyzovat: Proč systém vrátil špatné pořadí? Chybí relevantní výsledky? Jsou na špatných pozicích?
3. Přidat do testovacího datasetu: Tyto případy by měly být součástí našeho testovacího datasetu pro budoucí optimalizace
4. Upravit váhy: Na základě analýzy můžeme upravit váhy nebo přidat nová pravidla

Tento iterativní proces zajišťuje, že systém se neustále zlepšuje a přizpůsobuje se skutečnému chování uživatelů.

‍

Implementace na Azure: AI Search a OpenAI Embeddings

Všechny tyto komponenty můžeme efektivně implementovat pomocí služeb Microsoft Azure.

Azure AI Search

Azure AI Search (dříve Azure Cognitive Search) poskytuje:

• Hybridní vyhledávání: Nativní podpora pro kombinaci fulltextového (BM25) a vektorového vyhledávání
• HNSW indexy: Efektivní implementace HNSW algoritmu pro vektorové vyhledávání
• Scoring profiles: Flexibilní systém pro definování vlastních scoring funkcí
• Text weights: Možnost nastavit váhy pro různá fulltextová pole
• Vector weights: Možnost nastavit váhy pro různá vektorová pole

Azure AI Search umožňuje definovat scoring profiles, které kombinují:

• Magnitude scoring funkce pro numerické hodnoty (marže, popularita)
• Freshness scoring funkce pro časové hodnoty (datum vytvoření, datum aktualizace)
• Text weights pro fulltextová pole
• Vector weights pro vektorová pole
• Agregační funkce pro kombinování různých scoring funkcí

OpenAI Embeddings

Pro vytváření embeddingů používáme OpenAI Embeddings, konkrétně modely jako text-embedding-3-large:

• Kvalitní embeddingy: OpenAI modely poskytují vysoce kvalitní embeddingy, které dobře fungují i pro češtinu
• Konzistentní API: Jednoduchá integrace s Azure AI Search
• Škálovatelnost: OpenAI API zvládne velké objemy požadavků

OpenAI embeddingy jsou zvlášť vhodné pro češtinu, protože byly trénovány na vícejazyčných datech a poskytují dobré výsledky i pro menší jazyky.

Integrace

Azure AI Search umožňuje přímo použít OpenAI embeddingy jako vectorizer, což zjednodušuje integraci. Můžeme definovat vektorová pole v indexu, která automaticky používají OpenAI pro vytváření embeddingů při indexování dokumentů.

‍

1. AI agenti přechází do hlavní role

Hlavním oznámením Microsoftu byl Agent 365, který staví AI agenty do role nové provozní vrstvy digitálního pracovního prostředí. Nabízí centrální místo pro registraci, monitoring, zabezpečení a koordinaci agentů napříč organizací.

Zároveň Microsoft 365 Copilot představil dedikované agenty pro Microsoft Word, Excel a PowerPoint – schopné autonomně generovat, restrukturalizovat a analyzovat obsah podle firemního kontextu.

‍

Proč je to důležité

Uživatelé se posouvají od „ptaní se AI“ k „zadávání práce AI“. Agentní architektury postupně nahradí mnoho jednoúčelových copilotů.

Co mohou firmy udělat

• identifikovat workflow vhodné pro autonomní agenty
• standardizovat chování a oprávnění agentů
• rozhodnout, které workflows je vhodné pro Agent 365
• spustit pilotní nasazení v rámci Microsoft 365

‍

2. Integrace a orchestrace se stávají nezbytností

Microsoft také zdůraznil interoperabilitu skrze Model Context Protocol (MCP). Agenti v Microsoft Teams, Microsoft 365 i třetích stranách mohou sdílet kontext a provádět koordinované vícekrokové workflow.

Proč je to důležité

Skutečná automatizace vyžaduje orchestraci nástrojů, datových zdrojů a týmů – ne izolované asistenty.

Co mohou firmy udělat

• zmapovat workflow napříč aplikacemi
• propojit nástroje produktivity s CRM/ERP a dalšími systémy
• navrhnout agentní ekosystém místo samostatných botů

‍

3. Governance a bezpečnost v popředí

S rostoucí autonomií agentů Microsoft přinesl nové governance možnosti:

• přehled o oprávněních agentů
• monitoring jejich chování
• integrace s Microsoft Defender, Entra a Purview
• centrální řízení politik
• ochrana proti úniku dat

Oficiální Microsoft článek se všemi novinkami ohledně bezpečnostních novinek - Link

‍

Proč je to důležité

AI ve velkém měřítku musí být plně dohledatelná, bezpečná a v souladu s regulacemi.

Co mohou firmy udělat

• definovat, kdo může agenty vytvářet a upravovat
• nastavit auditní a monitorovací standardy
• vytvořit bezpečnostní mantinely ještě před širokým nasazením

‍

4. Windows, Cloud PC a vzestup AI-first pracovního prostředí

Microsoft prezentoval Windows 11 a Windows 365 jako klíčové komponenty pracovního prostředí připraveného na AI. Novinky zahrnují:

• AI-vylepšené Cloud PC
• podporu sdílených a frontline zařízení
• lokální inference agentů na podporovaném hardware
• automatizaci na úrovni endpointu

Proč je to důležité

Distribuované týmy získají konsistentní a bezpečné prostředí s nativní AI podporou.

Co mohou firmy udělat

• zhodnotit využití Cloud PC ve svém prostředí
• modernizovat digitální workplace pro AI workflow
• zvážit AI-ready zařízení pro provozní týmy

‍

5. AI infrastruktura a vývoj Azure

Microsoft Ignite přinesl další posun v Azure AI, včetně:

• rychlejšího a stabilnějšího hostingu a verzování modelů
• hybridního CPU/GPU inferencování
• efektivnějších deployment pipeline
• úspornějšího fine-tuningu
• vylepšené governance trénovacích datasetů

Celý report najdete zde - Link

‍

Proč je to důležité

Robustní datová a modelová infrastruktura je základem pro agentní ekosystém.

Co mohou firmy udělat

• modernizovat datovou architekturu pro AI-ready stav
• implementovat vektorové vyhledávání a RAG pipeline
• optimalizovat náklady na provoz modelů

‍

6. Copilot Studio a ekosystém pluginů se výrazně rozšiřují

Copilot Studio prošlo výraznou modernizací a posunulo se směrem k centrálnímu integračnímu a automatizačnímu nástroji. Novinky zahrnují:

• vizuální tvorbu vlastních agentů
• no-code vícekrokové workflow
• pluginy propojené s interními API
• lepší grounding a práci s podnikovými daty
• rozšířenou sadu konektorů pro CRM/ERP/event platformy

Proč je to důležité

Firmy mohou vytvořit oborové asistenty napojené na interní systémy a procesy.

Co mohou firmy udělat

• vyvíjet specializované copiloty pro konkrétní role a oddělení
• integrovat stávající systémy skrze konektory
• využívat vizuální logiku pro rychlé prototypy

‍

7. Propojení Fabric a Azure AI na nové úrovni

Microsoft Fabric přidal výrazné AI funkce:

• hlubší propojení s Azure AI Studio
• automatizované pipeline pro přípravu dat pro AI
• vektorové indexy a RAG v rámci OneLake
• posílenou datovou lineage a governance
• lepší výkon analytiky ve velkém měřítku

Proč je to důležité

AI agenti potřebují čistá, aktuální a dobře spravovaná data. Fabric umožňuje vytvořit a spravovat konsolidované prostředí pro data i AI.

Co mohou firmy udělat

• konsolidovat roztříštěné pipeline do Fabricu
• implementovat interní znalostní vyhledávání pomocí RAG
• vytvářet governance-ready AI datasety

‍

Co to znamená pro firmy

Napříč všemi novinkami je jasné, že AI se stává provozní vrstvou, nikoli doplňkem.

Firmy by měly počítat s tím, že:

• přichází přesun od experimentů k reálnému nasazení
• multi-agentní ekosystémy porostou rychleji
• governance je základní podmínka škálování
• propojení nástrojů a dat je zásadní
• AI bude součástí nástrojů, které lidé používají každý den
• konkurenční výhodu určí kvalita workflow, ne samotný model

‍

Jak se připravit na rok 2026

Doporučené kroky:

1. Zmapujte workflow s vysokou hodnotou pro agentní automatizaci

Identifikujte opakované a mezi-týmové procesy, kde autonomní agenti přinášejí největší efekt.

2. Vytvořte governance framework pro agenty

Nastavte role, oprávnění, audit, monitoring a provozní dohled.

3. Připravte datovou infrastrukturu

Zajistěte kvalitní, spravovaná a přístupná data, která mohou agenti bezpečně využívat.

4. Integrujte produktivní nástroje

Propojte Microsoft Teams, Microsoft 365 a MCP-kompatibilní aplikace pro plynulý provoz.

5. Začněte pilotem

Vyberte jednu oblast nebo tým a otestujte agentní workflow pod dohledem.

6. Plánujte škálování

Po ověření guardrailů začněte agentní systém rozšiřovat do dalších částí firmy.