Agentní AI a AI agenti: jak vybudovat Center of Excellence

Samotné zpřístupnění Copilotu a vývoj agentů v IT nechávají část firemního know-how bez využití.

Článek ukazuje, jak do řízené tvorby zapojit odborníky z byznysu a propojit jejich odpovědnost s bezpečností, správou platformy, provozem a kontrolou nákladů.

Zjistěte, jak takové CoE uvést do praxe.

Firma zpřístupní zaměstnancům Copilot. IT začne připravovat produkční agenty. Mezi těmito dvěma světy ale zůstává důležitá mezera: zkušení lidé z byznysu, kteří rozumějí konkrétní práci a dokážou své znalosti převést do řešení pro ostatní.

Právě tady vzniká prostor pro Practice AI Guild - komunitu odborníků, kteří vytvářejí a provozují agenty pro svou profesní oblast, region nebo obchodní jednotku. Pokud tato vrstva nemá vlastníka, podporu a jasné podmínky, organizace přichází o část nápadů lidí, kteří žijí v rámci procesů a znají jejich skutečné problémy.

Center of Excellence pro AI proto potřebuje širší zadání než jen schvalování nástrojů. Musí propojit AI Governance, AI Operations a podporu lidí, kteří agenty vytvářejí. V prostředí Microsoftu to znamená především spojit Copilot Studio s řízením Power Platform, životním cyklem řešení a kontrolou nákladů.

CoE musí umožnit bezpečnou práci

Microsoft ve své metodice agentního CoE rozlišuje čtyři funkce: řídit pravidla, podporovat tvůrce, optimalizovat kvalitu a náklady a rozšiřovat ověřená řešení. Současně varuje před centrem, které všechno kontroluje, ale nic neumožňuje.

To odpovídá základnímu problému adopce agentů. Pokud organizace nabídne pouze zákaz nebo dlouhou schvalovací frontu, může lidi motivovat k používání neschválených služeb. Pokud naopak otevře tvorbu bez pravidel, ztrácí přehled o datech, oprávněních, odpovědnosti a výdajích.

Fungující CoE má nabídnout schválenou cestu, kterou lze skutečně použít: připravené prostředí, povolené integrace, vzor řešení, přiměřený rozpočet a dostupnou pomoc.

Nemusí přitom vznikat další samostatné oddělení. Microsoft doporučuje navázat na existující Power Platform či low-code CoE, správu Microsoft 365, bezpečnost, compliance a odpovědnou AI. Agentní CoE doplňuje zejména vlastnictví, rozhodovací pravomoci, životní cyklus a průběžný dohled.

Čtyři vrstvy využití, společná odpovědnost

Pro rozdělení práce navrhuji čtyři vrstvy. Nejde o oficiální produktovou klasifikaci Microsoftu ani o povinný postup, kterým musí každý agent projít. Model popisuje, kdo řešení používá, kdo mu rozumí a kdo za něj odpovídá.

Vrstva	Lidé a rozsah	Data a typ řešení	Vlastnictví a provoz
Knowledge Worker AI — jednotlivec	Zaměstnanec využívající AI pro vlastní práci	Především osobní pracovní obsah a nestrukturovaná data; hotoví asistenti a soukromí znalostní agenti	Uživatel odpovídá za použití výsledku. CoE poskytuje bezpečné podmínky a vzdělávací programy.
Organizational AI — oddělení	Tým, oddělení, obchodní jednotka nebo země	Sdílená strukturovaná i nestrukturovaná data; deklarativní agenti, opakovaně použitelné instrukce a týmové automatizace	Zkušený business uživatel nebo místní tým řešení vlastní a provozuje. CoE zajišťuje platformu, standardy a podporu.
Practice AI Guild — profesní oblast nebo region	Odborníci a pokročilí uživatelé napříč týmy	Oborové know-how, metodiky a vlastní duševní vlastnictví; specializovaní agenti a sdílené komponenty	Profesní komunita vlastní obsah, kvalitu, rozvoj i místní provoz. Určený vlastník odpovídá za výsledek a náklady.
Operational AI — podnikový provoz	IT, vývojáři a specializované provozní týmy	Podniková data, procesy a workflow; interní i externí systémy, agenti provádějící akce	Určený IT nebo produktový tým zajišťuje vývoj, nasazování, provoz, incidenty a sjednanou úroveň služby.

Kulturní posun začíná běžným používáním AI v každodenní práci. Pokračuje schopností týmů vytvářet vlastní řešení a končí stavem, kdy organizace při návrhu práce počítá s AI. Samotná dostupnost nástroje tento posun nezajistí.

Komunita s praxí v AI nesmí zůstat dobrovolnou komunitou bez kapacity

Zkušený konzultant, analytik nebo odborník na provoz zná výjimky, které v procesní dokumentaci často chybí. Ví, kdy je podklad neúplný a kdy je nutné rozhodnutí předat člověku. Tato znalost má při návrhu agenta zásadní význam.

Komunita proto potřebuje víc než jen komunikační kanál. Doporučuji jí přidělit vlastníka, čas na údržbu, rozpočet, zastupitelnost a přístup ke společným nástrojům pro testování a monitoring.

Microsoft pro posilování business expertů doporučuje federovaný model. Má však důležitou podmínku: místní tým musí zvládnout celý životní cyklus, nikoli pouze vytvoření agenta.

Business může agenta vlastnit a provozovat, aniž by musel spravovat samotnou platformu. CoE nastavuje prostředí a kontrolní mechanismy; místní vlastník sleduje kvalitu, řeší upozornění a rozhoduje o změnách.

Interní sdílení hodnoty lze podpořit transparentním rozúčtováním nákladů mezi jednotkami. Externí monetizaci bych oddělil do přísnějšího režimu: přináší zákaznické závazky, ochranu duševního vlastnictví a požadavky na podporu, které přesahují běžnou komunitní tvorbu.

Organizační vrstvy nejsou bezpečnostní zóny

Copilot Studio vytváří a spravuje agenty v prostředí Power Platform. Prostředí určují datové hranice, role, povolené integrace a oddělení vývoje od provozu. Governance agentů nelze proto navrhnout mimo Power Platform.

Microsoft rozlišuje tři vývojové zóny:

Zone 1 — Citizen Development: soukromí agenti pro osobní produktivitu, pouze pro čtení a v kontextu uživatele. Metodika sem řadí Agent Builder a SharePoint agenty; sdílení je vypnuté.
Zone 2 — Partnered Development: vyškolení a IT schválení business tvůrci připravují sdílené agenty v Copilot Studiu. Používají řízená prostředí, dohled, verzování a schvalování publikace.
Zone 3 — Professional Development: profesionální vývojáři vytvářejí kritická podniková řešení se standardním řízením životního cyklu a nejsilnějšími kontrolami. Patří sem Copilot Studio i Microsoft Foundry Agent Service.

Knowledge Worker AI má přirozeně blízko k Zone 1. Organizational AI a Practice AI Guild budou často pracovat v Zone 2. Operational AI typicky vyžaduje Zone 3.

Rozhodující však nejsou názvy týmu ani pracovní pozice autora. Agent vytvořený business uživatelem, který mění podniková data nebo obsluhuje zákazníky, může potřebovat profesionální režim. Naopak zkušený vývojář nemusí pro soukromého znalostního pomocníka zavádět celý podnikový provozní model.

Agent Builder, SharePoint agenti a profesionální vývojové platformy tedy zůstávají součástí společné governance. Copilot Studio je zde hlavním implementačním prostředím, nikoli hranicí odpovědnosti CoE.

AI Governance: kdo rozhoduje a za co odpovídá

Organizační governance musí předcházet technické konfiguraci. Doporučuji rozdělit odpovědnosti takto:

Role	Hlavní odpovědnost
Výkonný sponzor	Mandát, financování a řešení sporů mezi organizačními jednotkami
CoE a správci platformy	Prostředí, společné standardy, identity, technické kontroly, evidence řešení a podpora tvůrců
Business vlastník agenta	Účel, přínos, kvalita výsledku, financování a rozhodnutí o dalším rozvoji
Provozní vlastník	Monitoring, incidenty, údržba a zastupitelnost; může působit v byznysu i IT
Vlastník dat	Vhodnost zdrojů, jejich aktuálnost a podmínky použití
Bezpečnost, compliance a právní tým	Posouzení rizik, ochrana informací a příslušné organizační či právní požadavky
Finance a FinOps	Nákladový model, rozpočty, přiřazení spotřeby a vyhodnocování ekonomiky

Jedna osoba může zastávat více rolí. Odpovědnosti ale nesmějí zůstat nepojmenované.

Každý sdílený agent by měl mít evidovaný účel, vlastníka a zástupce, publikum, datové zdroje, oprávnění, povolené akce, provozní režim a zdroj financování.

Pravidla mají rozlišovat mezi agentem, který doporučuje postup, a agentem, který podle něj také jedná. U akcí s významným dopadem doporučuji určit hranice autonomie, požadované lidské schválení a způsob zastavení řešení.

Power Platform: od prototypu k řízenému nasazení

Pro sdílené agenty v Zone 2 a Zone 3 doporučuji oddělit Dev, Test a Prod. Microsoft tento tříprostředový model uvádí ve svém checklistu pro připravenost řešení.

Tvůrce připravuje změny ve vývoji. Testovací prostředí slouží k ověření chování, oprávnění a integrací. Do produkce se nasazuje schválená verze prostřednictvím spravovaného řešení — managed solution.

CoE by mělo připravit opakovatelný postup:

Zabalit agenta a související komponenty do solution.
Oddělit konfiguraci pomocí environment variables a connection references.
Verzovat změny a zaznamenávat závislosti.
Nasazovat pomocí pipelines nebo odpovídajících DevOps nástrojů.
Vyžadovat schválení produkčního vydání.
Po nasazení spustit ověřovací testy a mít připravený rollback.

Přístupy mají vycházet ze skupin Microsoft Entra ID a principu nejnižších oprávnění. Datové a konektorové politiky je potřeba nastavit už ve vývoji. Produkční kontrola nemá být prvním okamžikem, kdy někdo zjistí, kam agent posílá data.

Důležitá je také aktuální volba administračních nástrojů. Microsoft uvádí, že Power Platform CoE Starter Kit již není aktivně udržován a jeho základní funkce jsou součástí Power Platform admin center. Nové CoE bych proto stavěl primárně na vestavěných možnostech správy. U existujícího Starter Kitu je vhodné posoudit vlastní úpravy a závislosti před jejich nahrazením.

AI Operations: agent po publikaci nekončí

Microsoft doporučuje zacházet s agenty jako s produkty. Jejich životní cyklus zahrnuje příjem nápadu, posouzení, tvorbu, nasazení, monitoring, zlepšování a vyřazení.

Právě provozní část odlišuje funkční CoE od komise pro schvalování experimentů.

Při návrhu je potřeba určit, co agent řeší a co už řešit nesmí. Orchestrace má popsat výběr nástrojů, předávání práce, podmínky ukončení a eskalaci člověku. U složitějších řešení doporučuji stanovit také omezení opakování a odpovědnost za jednotlivé části.

Před vydáním musí testy ověřit správnost odpovědí i chování akcí. Nestačí několik úspěšných ukázek. Testovací sada má zahrnovat neúplná zadání, nepovolený přístup, nedostupnou integraci a situace, kdy agent nemá pokračovat.

V provozu je nutné spojit technickou telemetrii s hodnocením výsledků. Microsoft doporučuje Application Insights nebo odpovídající telemetrii, přehledy chyb, využití a latence, kontrolu konverzací a upozornění na selhání integrací.

Provozní přehled by měl pokrývat:

Zdraví řešení: dostupnost, chyby, odezvu a neúspěšná volání.
Kvalitu: správnost výsledků, dokončení úloh a předání člověku.
Bezpečnost: citlivé operace, porušení pravidel a neobvyklé chování.
Ekonomiku: spotřebu kreditů a náklady na úspěšné dokončení úlohy.
Přínos: změna času, chybovosti nebo jiné business metriky oproti výchozímu stavu.

Monitoring a evaluace se doplňují. Monitoring ukazuje, že integrace vrací chyby. Evaluace může odhalit, že technicky funkční agent po změně podkladů poskytuje nesprávné odpovědi.

CoE poskytuje společné nástroje a standardy. Vlastník musí na výsledky reagovat. Pokud agent nemá správce, nepřináší hodnotu nebo už nesplňuje požadavky, patří k odpovědnému provozu i jeho vyřazení a odebrání přístupů.

FinOps: rozpočet nestačí pouze přidělit

Copilot Credits jsou měrnou jednotkou spotřeby, nikoli pevným počtem konverzací. Náklady závisí na použitých funkcích, složitosti řešení, orchestraci a způsobu využití. Microsoft v licenčním průvodci uvádí pay-as-you-go cenu $0.01 za Copilot Credit; ceny jsou v USD a mohou se změnit.

CoE proto musí oddělit experimentování od financovaného provozu. Pro každý režim doporučuji určit:

kdo spotřebu financuje a komu se přiřazuje;
jaká pravidla platí pro čerpání kreditů a případné další účtování;
kdo sleduje upozornění a schvaluje navýšení;
co se stane při vyčerpání limitu;
jak se porovnávají náklady s dosaženým výsledkem.

Přísný limit může ochránit experimentální rozpočet. U kritického procesu ale musí organizace současně rozhodnout, jak zajistí kontinuitu služby. FinOps je zde společné rozhodování financí, vlastníka procesu a provozu.

Správa nákladů se může přesunout mezi administračními centry

Aktuální dokumentace již popisuje možnost převést správu nákladů Copilot Studia do Microsoft 365 admin center pomocí resource-based spending policies.

Dokud organizace tuto možnost nezapne pro daný rozsah, platí příslušná konfigurace v Power Platform admin center. Pro pokryté prostředí nová politika nahrazuje jeho původní kapacitní alokace a propojené billing plans.

Přechod proto nelze chápat jako další nezávislou pojistku. Mění místo, které skutečně řídí výdaje.

Microsoft současně upozorňuje na důležité podmínky:

Politika může pokrývat jednotlivé agenty nebo prostředí. Samostatnou aplikaci či workflow nelze vybrat v seznamu agentů; pro jejich pokrytí se používá prostředí.
Tyto resource-based politiky se nevztahují na AI Builder a jeho spotřebu. Dokumentace nedoporučuje přesouvat řešení využívající AI Builder do tohoto režimu.
Při překryvu politik stejného typu se uplatňuje nejvyšší příslušný limit, nikoli automaticky nejpřísnější omezení.
Po propojení prostředí může uplatnění politiky trvat až 12 minut.

CoE tedy potřebuje evidovat nejen částku, ale také působnost politiky a její přednost vůči ostatním kontrolám.

Copilot Code rozšiřuje odpovědnost o vznikající aplikace

K 6. listopadu 2026 popisuje Microsoft Copilot Code jako funkci v programu Frontier preview. Copilot Managed Runtime je veden jako Paid Public Preview. Tyto stavy je nutné odlišovat od obecné dostupnosti.

Copilot Code umožňuje vytvářet software pomocí přirozeného jazyka, pracovat lokálně nebo v cloudu a propojit projekt s GitHubem. Výsledkem může být aplikace, dashboard, automatizace nebo skript. Cloudové aplikace lze publikovat do Copilot Managed Runtime.

CoE proto musí pokrýt také životní cyklus takto vzniklého softwaru: kontrolu vygenerovaného řešení, vlastnictví zdrojového kódu, závislosti, testování, publikaci, provoz a případné předání vývojářům.

Náklady vznikají už při tvorbě. Microsoft uvádí pro Copilot Code orientační spotřebu:

Typ úlohy	Odhad spotřeby
Lehká	25–60 Copilot Credits
Střední	75–100 Copilot Credits
Náročná	Více než 200 Copilot Credits

7 8

Jde o plánovací odhady, nikoli o garantovanou cenu. Kredity se spotřebovávají při vytváření, úpravách a publikování řešení.

Samostatnou složkou je provoz aplikace. U provozu Copilot Managed Runtime účtovaného kreditu uvádí Microsoft sazbu 0.1 Copilot Credits za API volání. Další použité AI služby mohou mít vlastní účtování.

CoE musí sledovat náklady na vytvoření i náklady na používání. Tvorba se řídí nastavením produktu, ve kterém aplikace vzniká; provozní spending policies se spravují samostatně v Microsoft 365 admin center.

Převzetí existujících organizačních politik runtime prostředím přitom neověřuje správnost business logiky. Funkční prototyp ještě není připravená podniková služba.

Kdy má řešení přejít do přísnějšího režimu

Přechod nesmí záviset pouze na počtu uživatelů. Doporučuji nové posouzení při změně publika, dat, oprávnění, provozní závislosti nebo nákladů.

Ilustrační příklad: odborník vytvoří osobního pomocníka na základě vlastní metodiky. Později jej začne používat regionální tým. Agent pak dostane přístup do CRM a možnost zapisovat výsledky.

První změna vyžaduje sdílené vlastnictví obsahu, podporu a řízené publikování. Druhá přidává kontrolu nad akcemi, oprávnění, testování a provozní odpovědnost. Nestačí původního agenta pouze nasdílet.

Obdobné pravidlo má platit pro aplikaci vytvořenou v Copilot Code. Pokud na ní začne záviset provoz nebo přesáhne možnosti místního týmu, musí být připravena cesta k předání přes repozitář, revizi kódu a profesionální správu. Doménový expert přitom zůstává součástí řešení jako business vlastník.

Jak CoE uvést do praxe

Začal bych omezeným, ale úplným provozním modelem:

Získat mandát a financování. Určit sponzora, vedoucího CoE a rozhodovací pravomoci.
Popsat všechny čtyři vrstvy. Zahrnout osobní využití, sdílenou business tvorbu, Practice AI Guild i podnikový provoz.
Připravit bezpečnou cestu. Prostředí, přístupy, datové politiky, šablony a pravidla financování.
Zavést evidenci a příjem nápadů. Posuzovat přínos, riziko a možnost opětovného použití.
Ověřit celý životní cyklus. Projít s vybranými řešeními tvorbu, nasazení, monitoring, změnu i vyřazení.
Rozšiřovat samostatnost podle schopností týmů. Delegovat dodávku a provoz tam, kde je místní tým skutečně zvládne.

Úspěch bych neposuzoval podle počtu vytvořených agentů. Důležitější je, zda mají vlastníky, přiměřené kontroly, měřitelnou kvalitu a obhajitelné náklady.

Největší slabinou modelu „zaměstnanci mají Copilot a produkční agenty staví IT“ je opomenutí odborné vrstvy mezi nimi. Právě tam lze převést znalost práce do opakovaně využitelného řešení.

Dobré CoE této vrstvě dává prostor i odpovědnost. Organizaci pak umožňuje rozhodovat podle rizika a výsledků místo plošného zákazu nebo nekontrolovaného experimentování.