Firemní AI pod kontrolou: jak zavést AI platformu pro zaměstnance i agenty

Společné prostředí pro firemní AI dává zaměstnancům schválený chat a aplikacím i agentům řízený přístup k modelům. Firma pak ví, kdo AI používá, do jaké služby posílá data, kolik provoz stojí a co jednotlivé automatizace skutečně provedly.

Langfuse, LLM brána a chatové rozhraní jsou součásti takové platformy. Samy o sobě ale nestačí: hodnotu jí dávají ověřená pravidla pro přístupy, data a provoz.

Komu platforma pomáhá

Typicky menší nebo střední firmě, která už používá více AI nástrojů nebo začíná automatizovat vlastní procesy a má malý IT tým. Podnětů bývá několik: přibývají API klíče, zaměstnanci nevědí, kam smějí vkládat dokumenty, náklady nejde rozdělit podle oddělení nebo není jasné, proč agent provedl chybnou akci.

U výrobce a distributora může společná platforma obsluhovat přípravu nabídek, zpracování objednávek, marketingové texty i vývoj interních aplikací. Každý postup má vlastní oprávnění, rozpočet a pravidla pro data.

Pokud firma potřebuje jen jeden hotový podnikový chat bez vlastních integrací, může jí stačit vhodně nastavená existující služba. Smysl společné platformy roste tam, kde je potřeba propojit zaměstnance, vlastní software, více modelů a odpovědnost za provoz.

Dva způsoby používání se společnými pravidly

LLM brána řeší přístup, směrování a limity. Langfuse sleduje a vyhodnocuje průběh aplikace. Záznam z brány sám o sobě nepokrývá práci agenta v ERP, na webu nebo v souborovém systému. [1][2]

Referenční architektura

flowchart TD
    U["Zaměstnanci přes firemní přihlášení"] --> C["Firemní chat"]
    A["Aplikace a agenti"] --> G["LLM brána a pravidla"]
    C --> G
    G --> M["Schválená cloudová modelová služba"]
    G --> P["Volitelně vlastní modelový server"]
    A --> T["Povolené nástroje a schvalování"]
    T --> D["ERP, CRM a dokumenty"]
    C -. "telemetrie" .-> O["Langfuse a provozní přehledy"]
    A -. "telemetrie" .-> O
    G -. "provozní metriky" .-> O

Schéma vyjadřuje logické role. Podrobný záznam a účtování modelového volání mají určený zdroj, aby se stejné volání při kombinaci aplikační a gateway integrace nezapočítalo dvakrát. Audit cloudových změn, identity a obchodních transakcí Langfuse doplňuje; na schématu není sloučen do jednoho nástroje.

Platforma i Langfuse běží ve vašem cloudovém účtu, s vaším vlastnictvím dat a fakturací cloudové spotřeby; správce má jen omezený přístup. Firma bez vlastního cloudu může platformu provozovat v odděleném prostředí u nás, s jasným rozsahem přístupů a možností exportu a předání.

Co se konkrétně zavádí

Firemní chat

Osvědčeným kandidátem je LibreChat. Podporuje firemní přihlášení přes OIDC/SAML, vlastní modelové endpointy a integraci s Langfuse. Alternativou s podporou OIDC/OAuth a řízení přístupů je Open WebUI. [3][4]

Chat se napojí na Google Workspace nebo Microsoft Entra ID. Klíče k modelům zůstanou na serveru. Uživatelé dostanou přístup jen ke schváleným endpointům; přidávání vlastních poskytovatelů, MCP serverů a externích nástrojů se řídí oprávněními.

Důležité je předání ověřené identity do brány. Jeden společný klíč pro celý chat bez dalšího rozlišení neumožní spolehlivě vynucovat pravidla pro jednotlivé uživatele. Identita se odvozuje z přihlášené relace na serveru a brána tuto vazbu přijímá jen od důvěryhodné služby. Hlavička, kterou může uživatel podvrhnout, nesmí určovat jeho rozpočet ani roli.

Zvlášť se nastaví historie konverzací, soubory, sdílené odkazy a telemetrie. LibreChat má například u dočasných chatů výchozí výjimku z exportu do Langfuse. Úplnost sledování se proto ověřuje pro každý povolený režim, ne jedním testovacím dotazem. [5]

Společná LLM brána

Pro přenositelnou sestavu je kandidátem LiteLLM. Firma v Azure může využít AI gateway v Azure API Management, zvlášť pokud tuto službu už provozuje. Microsoft dokumentuje řízení tokenových kvót, autentizaci, logování a směrování; přesné možnosti závisejí na variantě a konfiguraci. [6]

Brána vede katalog schválených nasazení: poskytovatel, model, endpoint, povolené použití a datové podmínky. Každá aplikace má vlastní identitu a omezení. Náhradní model při výpadku musí splňovat stejná pravidla pro data.

Rate limit, tokenová kvóta a finanční rozpočet znamenají každý něco jiného. U rozpočtů se řeší i souběžné požadavky a zpoždění účtování. LiteLLM pro rozpočty vyžaduje databázi; sdílené limity více instancí závisejí na Redis a na tom, jak se brána zachová při jeho výpadku. Proto má smysl otestované chování, ne neurčitý slib absolutního finančního stropu. [7]

Dohled nad agenty a jejich kvalitou

Langfuse propojí zachycená volání modelů, práci s nástroji, časy, spotřebu, chyby a dostupný kontext. K běhu se přiřadí verze aplikace, promptu a označení obchodního případu. Hodnocení a testovací sady pomáhají porovnávat změny před nasazením. [2]

Začíná se jedním skutečným postupem, například přípravou nabídky z poptávky. Firma uvidí, jaké skladové údaje agent dostal, kterou verzi ceníku použil, co připravil a zda obchodník návrh schválil bez opravy. Náklady se tak dají vztáhnout k užitečnému výsledku.

Oprávnění, časové limity, maximální počet kroků, ochranu proti dvojímu zápisu a schvalování vynucuje aplikace a API nástrojů. Agent nesmí změnit cenu či odeslat závaznou nabídku jen na základě pokynu nalezeného v příloze. Vývojový agent má oddělené prostředí a přístupy.

Co znamená kontrolované nebo izolované LLM

Spravované modely v podnikovém cloudu

Pro běžnou firmu je výchozí volbou model používaný jako služba Azure nebo Google Cloud. Nastaví se přístup, soukromá síťová cesta tam, kde ji daná služba podporuje, vhodný endpoint a doloží se parametry zpracování a uchovávání dat.

Azure: Microsoft u modelů prodávaných Azure, včetně Azure OpenAI, uvádí, že vstupy a výstupy nejsou dostupné poskytovatelům těchto modelů a nejsou bez svolení použity k trénování základních modelů. Současně popisuje uchovávání pro některé funkce a bezpečnostní monitoring. Umístění zpracování se liší mezi regionálními, DataZone a Global nasazeními. Azure OpenAI podporuje připojení přes private endpoint. [8][9]

Google Cloud: Varianta Claude spravovaná Googlem nabízí podle jeho oznámení VPC Service Controls, CMEK a možnosti datové rezidence včetně EU; konkrétní kombinace se ověří pro zvolený model a funkci. Nová varianta spravovaná Anthropicem má jiného zpracovatele dat a jiné podmínky; oznámení Anthropicu k 26. 10. 2026 uvádí US a Global endpointy. Samotná fakturace přes Google Cloud tedy nezaručuje zpracování v EU. [10]

Private endpoint určuje síťovou cestu, datová rezidence místo zpracování nebo uložení, retenční pravidla dobu uchovávání a zákaz trénování účel použití dat. Žádná z těchto vlastností automaticky nezaručuje ostatní. Google dokumentuje také funkce, u kterých je potřeba další ukládání nebo není nulová retence dostupná. [11]

VPC Service Controls chrání vybrané cloudové služby; samo neblokuje všechna internetová API třetích stran. Odchozí přístupy agenta proto vyžadují vlastní síťová pravidla a omezení nástrojů. [12]

Přesný popis takové varianty zní: schválené cloudové modely s řízenými přístupy, datovými toky a doloženými podmínkami zpracování. Stále jde o zpracování cloudovým poskytovatelem, ne o vlastní offline instanci modelu.

Vlastní modelový server

Pokud data nesmí do externího modelového API, lze nasadit model s dostupnými vahami a vhodnou licencí na vlastní GPU infrastrukturu, například pomocí vLLM. [13] V cloudu zůstává poskytovatelem infrastruktury příslušný cloud; nejde automaticky o fyzicky odpojené prostředí.

Tato varianta zahrnuje provoz modelového serveru, řízení kapacity, ověření kvality na vlastních úlohách, aktualizace a všechny související služby. Stejný režim musí respektovat embeddingy, OCR, vyhledávání, hodnocení, telemetrie, zálohy i správcovské přístupy. Náhradní externí model se nepovoluje bez výslovně definované výjimky. Spravované Claude API popsané Googlem instalaci vah modelu na vlastní server neposkytuje. [14]

Přehled a audit mají konkrétní rozsah

Přehled odpoví na čtyři otázky:

• Kdo: ověřený uživatel, tým, aplikace a odpovědný vlastník.
• Kam: schválený endpoint, poskytovatel, konfigurace regionu a navazující nástroje. Přehled nedokazuje fyzický server každého volání uvnitř spravované služby.
• Za kolik: spotřeba modelů, náklady podle týmu a procesu; odděleně infrastruktura, licence, úložiště a placené nástroje.
• S jakým výsledkem: zaznamenaný postup, chyby, schválení a definované hodnocení úspěchu.

Auditní stopa má tři části: změny přístupů a konfigurací, běhy aplikací a obchodní transakce v cílovém systému. Langfuse má vlastní administrativní auditní funkce v Enterprise variantě. Potřebný rozsah se kombinuje s cloudovými a aplikačními záznamy; požadavky na neměnnost a uchování se řeší samostatným úložištěm a řízením práv. [15]

Obsah promptů se neukládá plošně bez rozhodnutí firmy. Pro některé procesy stačí metadata, jiné potřebují omezený a maskovaný obsah pro hledání chyb. Maskování před exportem do Langfuse chrání telemetrii; samo nezajišťuje odstranění údajů před odesláním do modelu. To je jiný bod datového toku. [16]

Přílohy, historie chatů, vektorové databáze, cache, webové vyhledávání a modeloví hodnotitelé mají vlastní řádek v mapě datových toků. U firemního vyhledávání se oprávnění ověřují podle zdroje i při načítání jednotlivých dokumentů.

Jak poznat, že platforma funguje

Předání má obsahovat výsledky testů, ne jen seznam nainstalovaných produktů:

1. Odebraný uživatel ztratí přístup i přes existující relaci v dohodnuté lhůtě.
2. Nepovolený model a nepovolený přímý přístup z řízené aplikace jsou odmítnuty; ověřeno je i náhradní směrování.
3. Limit pro jeden tým nevyčerpá přidělenou kapacitu druhého; otestován je také výpadek počítání spotřeby.
4. U pilotního úkolu lze propojit uživatele či aplikaci, modelové volání, práci s nástrojem a výsledek. Chybějící telemetrie vyvolá provozní signál.
5. Zápis vyžadující schválení nelze provést bez něj a opakování úkolu nevytvoří druhou zakázku.
6. Testovací citlivé údaje se neobjeví v místech, kde mají být odstraněny; otestována jsou oprávnění k dokumentům i záznamům.
7. Zvolená konfigurace regionu, retence, síťových přístupů a záloh odpovídá předané dokumentaci a obnova vybraných dat je ověřená.

Platforma pokrývá napojené aplikace a řízené prostředí. Nezíská automaticky kontrolu nad osobním chatem otevřeným na telefonu ani nad každou externí AI službou. Omezení takového používání patří do navazující správy zařízení, sítě a firemních pravidel.

Takovou platformu zavádíme a provozujeme; podrobnosti jsou na stránce AI platforma.

Vaši lidé mohou využívat AI. Vy víte, v jakém prostředí pracuje a kdo za její provoz odpovídá.

Zdroje

1. Langfuse — What Is an LLM Gateway. Rozdělení rolí mezi bránu a observability.
2. Langfuse — Observability a Evaluation. Tracing, hodnocení a porovnávání změn.
3. LibreChat — Authentication a Custom Endpoints. Autentizace, řízené endpointy a předávání identity.
4. Open WebUI — Security. SSO a řízení přístupů jako alternativní rozhraní.
5. LibreChat — Langfuse Tracing. Integrace, identita, sampling a dočasné chaty.
6. Microsoft — AI gateway in Azure API Management. Řízení přístupu, směrování, kvót a telemetrie.
7. LiteLLM — Budgets and Rate Limits. Rozpočty, databázové závislosti a chování distribuovaných limitů při výpadku.
8. Microsoft — Data privacy for Models sold by Azure. Zpracovatel, trénování, ukládání a typy geografického nasazení.
9. Microsoft — Azure OpenAI networking. Soukromé připojení přes private endpoint.
10. Google Cloud — Expanding Claude availability a Anthropic — Claude Platform on Google Cloud. Varianty spravované Googlem a Anthropicem, zpracovatelé dat a dostupné endpointy.
11. Google Cloud — Zero data retention. Omezení trénování a podmínky uchovávání u jednotlivých funkcí.
12. Google Cloud — VPC Service Controls overview. Bezpečnostní perimetr a jeho hranice vůči internetovým službám.
13. vLLM — Online Serving. Vlastní provoz podporovaných modelů přes API.
14. Google Cloud — Anthropic Claude models. Spravované modelové API.
15. Langfuse — Audit Logs. Administrativní audit a dostupnost v Enterprise variantě.
16. Langfuse — Masking. Ochrana telemetrie před exportem.

Technické možnosti produktů jsou popsány podle dokumentace ověřené 26. října 2026.