Governance AI skillů v enterprise: co se stane, když autor odjede na dovolenou

Na jednom governance hovoru s naším enterprise klientem před pár týdny položila AI program lead otázku, která nám zůstala v hlavě. Ne „který model je nejbezpečnější“ ani „jak tohle zalogujeme“. Zeptala se: „Co se stane, když člověk, který postavil náš nejlepší skill, odjede na dovolenou?“

To je celý problém v jedné větě. Někdo v týmu napíše skill, který z dvouhodinové práce udělá dvouminutovou. Chtějí ho všichni. A žije na jednom jediném místě: v session toho člověka, na jeho počítači. Když se odhlásí, odhlásí se s ním i ten skill.

Už dřív jsme psali o tom, jak řídit MCP servery, které firma připojuje, i o tom, co vlastně AI governance znamená. Skilly jsou další artefakt, který potřebuje stejný přístup. Stávají se jednotkou znovupoužití v agentní AI, zabaleným kouskem know-how, který si tým předává. A ve většině firem je dnes neřídí nikdo.

Skill vypadá jako soubor, takže lidé předpokládají, že sdílet ho je jako sdílet soubor. Není, a důvody vyplývají přímo z toho, jak jsou dnes desktopové AI nástroje postavené.

Claude nabízí tři způsoby, jak skill distribuovat, a každý dává jinou míru kontroly.

Vyexportovat zip a poslat ho. Skill si stáhneš, pošleš kolegovi, ten ho nahraje. Na jednorázovku to funguje. Není tu žádná historie verzí, žádný review, žádná disciplína v pojmenování a není na čem stavět governance. Dobré na „hele, zkus tohle“, k ničemu jako firemní praxe.

Publikovat ho celé organizaci. Když to admin povolí, owner pushne skill jedním tlačítkem všem v organizaci. Každý ho vidí v katalogu a může si ho nainstalovat. Pro menší organizaci je to vážně dobré. Dvě výhrady. Za prvé, hygiena pojmenování přestává být volitelná ve chvíli, kdy skillů je víc než pár. Za druhé, na Team plánu vidí všichni všechno; viditelnost omezená na skupiny (aby skilly týmu Legal necpaly katalog Engineeringu) je Enterprise funkce. Na Teamu skupinovou viditelnost nahradíš konvencí názvů.

Postavit ho na Git repozitáři. Admin nasměruje firemní plugin marketplace na privátní nebo interní repo a marketplace se resyncne při každém mergnutém pull requestu. To je varianta, která nese governance, protože Git sám o sobě governance systém je: historie, review, vlastnictví, CI. Je to zároveň varianta s nejostřejšími hranami, k čemuž se ještě dostaneme.

Tady je detail, který celou věc přerámuje, a snadno se přehlédne.

Skill vytvořený během Cowork session nikam dál nedosáhne. Žije ve workspace té jedné session, u toho jednoho člověka, a nic nezaručuje, že session přežije. Nikdo další se do něj nedostane — ani jinou session, ani jiným povrchem. A obecněji: napříč desktopovými povrchy (Chat, Cowork, Code v terminálu, Code ve VS Code) neexistuje sdílené úložiště skillů. Každý povrch je vlastní silo. Claude Code automaticky nevidí skill, který někdo vytvořil v Coworku.

Matyáš Křeček, který u nás vede práci na MCP Gateway a přesně tenhle setup navrhoval pro klienta, popsal důsledek napřímo:

To obrací obvyklou námitku. Týmy někdy repo-first přístup odmítají jako těžkopádný — „proč si lidi nemůžou skilly sdílet prostě napřímo?“ Odpověď je, že žádné spolehlivé „napřímo“ neexistuje. Bez repa skill postavený v Coworku existuje na jediném místě, kam nikdo další nedohlédne. Repozitář není proces navíc nad sdílením. Je to to, co dává skillu existenci mimo jednu session.

Ve chvíli, kdy řekneš „Git repozitář“, většina organizace vypne. Legal, ops, finance — tedy lidé, kteří často stavějí ty nejcennější doménové skilly — commit messages psát nebudou. Cílem návrhu tedy je: nechat repo jako source of truth a zařídit, aby nikdo mimo engineering vůbec nemusel vědět, že tam je.

To dnes jde, a nevyžaduje to, aby netechnický člověk vůbec sáhl na Claude Code.

Mechanismem je příkaz /sync-skill, distribuovaný uvnitř core pluginu, který admin označí jako auto-installed, takže ho má každý od prvního dne. Cowork umí spouštět příkazy ve své VM a má GitHub konektor. Když tedy někdo z Legal dodělá skill a napíše /sync-skill, příkaz může vzít aktuální složku skillu, založit branch, commitnout soubory a přes GitHub konektor otevřít pull request. Člověk odpoví na pár otázek — název, popis, tým — a o Git nezavadí.

Vyhledávání vypadne ze stejné struktury. Skilly z pluginu jsou namespacované jako /nazev-pluginu:skill, takže plugin legal dá /legal:smlouva-review a kdokoli najde skilly svého týmu tím, že napíše /legal. Konvence názvů, kterou jsi stejně potřeboval kvůli limitu viditelnosti na Team plánu, je ta samá, která dělá skilly dohledatelné.

Repo-backed marketplace je správná architektura, ale dvě jeho hrany zabolí, když je přehlídneš. Obě patří do governance pravidel hned od začátku.

Validuj v CI před mergem, vždy. Marketplace se resyncne při mergi, a když sync selže, pluginy můžou celému týmu dočasně zmizet. To z jednoho špatného mergu udělá výpadek. CI validace — lint marketplace manifestu, kontrola povinných frontmatter polí, vynucení konvence názvů — tedy není nice-to-have, které přidáš později. Je to to, co zabrání jednomu rozbitému skillu položit toolbox všem.

Ber přibalené MCP servery jako privilegovaný kód. Plugin může obsahovat lokální MCP servery a ty běží na počítači uživatele se stejnými právy jako jakýkoli jiný program. Na Enterprise plánu může admin lokální MCP servery centrálně zakázat; na Team plánu to z centra vynutit nejde. Praktické pravidlo, které z toho plyne: skilly od netechnických lidí jsou jen SKILL.md plus referenční soubory — žádné MCP servery, žádné hooky. Cokoli, co přináší spustitelný povrch, jde přes technický review. Je to stejný instinkt jako brát kontext jako otázku architektury, ne jako otázku promptování: riziko je v tom, co artefakt umí udělat, ne v tom, co říká.

Nepotřebuješ celý setup, aby ses rozjel. Postup vypadá zhruba takhle:

Mimochodem, stejné repo poslouží i Claude Code. Admin marketplace dosáhne na Cowork a Chat automaticky, ale na Code ne; vývojáři si totéž repo přidají ručně jedním marketplace příkazem. Jeden source of truth, tři povrchy, různé distribuční kanály.

Vrať se k otázce, kterou to celé začalo. Co se stane, když autor tvého nejlepšího skillu odjede na dovolenou? Bez governance je poctivá odpověď: skill odjede s ním a zjistíš to tvrdě.

S repo-backed marketplace, cestou přes /sync-skill pro netechnické přispěvatele a s CI, které odmítne rozbít toolbox týmu, je odpověď: nestane se nic. Skill je v repu, má vlastníka v CODEOWNERS, prošel reviewem a všichni ho už umí použít tím, že napíšou jeho název.

Tohle ti governance skillů koupí. Je to stejná disciplína, jakou přinášíme k MCP serverům, které enterprise připojuje, namířená na jiný artefakt. Pokud řešíš, kde má v tvojí organizaci sedět řídicí vrstva pro AI nástroje, je to konverzace za naší prací na MCP Gateway Enterprise — a skilly jsou teď její součástí.

Skill, který žije jen v session jednoho člověka, není aktivum. Je to riziko, které čeká na dovolenou.