Schneider Electric ukazuje, proč AI agenti ve firmách potřebují LLMOps dřív než další model

TL;DR:

• LangChain publikoval případ Schneider Electric, kde firma staví LLMOps základy pro více než 60 AI produktů a agentských řešení.
• Nejdůležitější zpráva pro AI v práci není samotný LangSmith, ale disciplína: observability, evaluace, deployment a zapojení expertů z provozu.
• AI agenti v kritické infrastruktuře potřebují trace-level kontrolu, datovou rezidenci, guardrails a jasný způsob, jak se produkční chyby vrací do testů.
• Praktické AI workflow ve firmě nemá být jeden centrální agent pro všechno, ale sada produktů s vlastním runtime, odpovědností a měřením kvality.
• Pokud firma uvažuje o automatizaci práce pomocí AI, měla by řešit LLMOps smyčku dřív, než začne škálu agentů měřit jen počtem nasazených případů.

LangChain zveřejnil detailní pohled na to, jak Schneider Electric staví LLMOps pro enterprise AI. Na první pohled je to partnerský case study k LangSmithu. Pod povrchem je ale mnohem zajímavější zpráva: velké firmy začínají s AI agenty narážet na stejné otázky jako u seriózního softwaru. Jak vidět, co agent dělá? Jak poznat, že nová verze je lepší? Jak zapojit experty z provozu? A kdo nese odpovědnost, když agent pracuje v prostředí, kde chyba není jen kosmetická?

Schneider Electric má podle článku interní AI Hub se stovkami expertů a více než 60 AI produktů v aktivním vývoji nebo produkci. Use-casy sahají od energetické optimalizace přes asistenty pro zaměstnance až po kopiloty pro zákaznickou péči a dokumentové workflow. To je přesně prostředí, kde přestává stačit demo a začíná záležet na provozní disciplíně.

LLMOps jako základ důvěry, ne administrativní vrstva

Schneider popisuje tři pilíře: observability, evaluation a deployment. V českém kontextu by se to dalo říct jednodušeji: vidět, co se děje; rozhodnout, jestli změna zlepšuje výsledek; a nasadit systém tak, aby nespadl na prvním reálném omezení.

Observability v tomto případě znamená trace-level pohled na práci agentů. Ne jen aplikační logy, ale záznamy konverzací, mezikroků a rozhodnutí, které později mohou sloužit jako materiál pro evaluace. Schneider u svého interního asistenta One Jo popisuje, že produkční traces používá pro regresní datasety a sledování driftu.

To je pro AI workflow klíčové. Pokud se model nebo prompt změní, nestačí říct, že odpověď vypadá lépe. Tým potřebuje přehrát reálné případy a zjistit, jestli nová verze nerozbila důležité chování.

Expert v oboru patří přímo do hodnoticí smyčky

Jedna z nejpraktičtějších částí článku je zapojení SME, tedy subject matter expertů. Schneider mapoval experty z domény do role, která jim umožňuje anotovat produkční příklady a pracovat s datasety, aniž by museli mít vývojářský přístup do celé platformy.

To je dobrá lekce i pro menší týmy. Kvalitu AI agenta často nedokáže posoudit jen vývojář nebo majitel nástroje. U finančního reportingu, zákaznické podpory, technické dokumentace nebo compliance musí do smyčky vstoupit člověk, který zná reálný provoz. Ne jako poslední schvalovatel náhodné ukázky, ale jako součást systému, který určuje, co je správně, co je rizikové a co se má testovat příště.

Schneider uvádí, že zhruba 20 procent AI produktů má aktivní annotation queue se zapojením expertů. To číslo není pointa samo o sobě. Pointa je, že firma nespoléhá jen na abstraktní modelovou kvalitu. Skládá si vlastní měřicí vrstvu nad reálnou prací.

Jeden runtime pro všechno je pohodlný, ale riskantní

Zajímavé je i rozhodnutí nespouštět všechny agenty přes jeden centrální runtime. Schneider zvolil model jeden runtime na produkt. Důvody jsou pragmatické: tým, který produkt staví, ho také provozuje; a problém v jednom agentovi nemá shodit všechny ostatní.

To má cenu. Více infrastruktury, více upgradů, více koordinace. Ale v prostředí kritické infrastruktury dává oddělení rizik smysl. Pro firmy, které dnes přemýšlejí o AI agentech pro CRM, podporu, interní znalosti nebo dokumentové workflow, je to užitečná protiváha k představě jednoho univerzálního agenta, který dostane přístup ke všemu.

Praktická otázka nezní jen: co může agent dělat? Stejně důležité je: kde běží, kdo ho vlastní, jak se měří jeho kvalita, kdo schvaluje změny a co se stane, když začne chybovat?

Automatizace není jen rychlost, ale návrat chyb do systému

Schneider popisuje i dokumentové workflow v oblasti Digital Energy, kde agent analyzuje požadavky a technické dokumenty pro nabídky. Práce, která dřív zabrala hodiny nebo dny, může podle článku běžet v minutách. To je lákavá část AI automatizace. Ale důležitější je, že běží v task-queue modelu a v prostředí, kde se výsledky dají sledovat, hodnotit a zlepšovat.

U dlouhých agentských úloh je to zásadní. Čím delší workflow, tím víc prostoru pro tiché chyby. Agent může správně přečíst část dokumentu, špatně pochopit omezení, vynechat výjimku nebo vyrobit dobrý mezivýstup, který se v dalším kroku použije špatně. Bez traces a evaluací se takové chyby hledají až v důsledcích.

Co si z toho odnést pro české týmy

Schneider Electric je obří firma, ale vzorec je přenositelný. I malý tým může začít jednoduše: u každého důležitého AI workflow uchovávat vzorky vstupů a výstupů, označovat dobré a špatné běhy, dělat malý regresní set před změnou promptu nebo modelu a nechat oborového člověka pravidelně kontrolovat reálné příklady.

LLMOps nemusí začít jako velká platforma. Může začít jako zvyk, že agentské workflow není hotové ve chvíli, kdy poprvé odpoví. Hotové začíná být až ve chvíli, kdy tým ví, jak se bude chování měřit, kdo může změny schválit a jak se chyba přemění na nový test.

Pro AI v práci je to střízlivé a důležité. Firmy, které budou chtít škálovat AI agenty, nevyhrají jen výběrem modelu. Vyhrají schopností řídit kvalitu, odpovědnost a zpětnou vazbu v každém workflow.

Zdroj

Zdroj: LangChain - https://www.langchain.com/blog/how-schneider-electric-built-their-llmops-foundations-at-enterprise-scale-with-langsmith