Myslitelé

Dalším uživatelem vašeho softwaru bude agent AI. Je vaše architektura připravená?

mm
Přidejte Unite.AI mezi své preferované zdroje na Google

Představte si, že agent AI řeší spor zákazníka ohledně fakturace. Přečte si stížnost, zkontroluje historii účtu a vyhodnotí, že je namístě vystavit dobropis. To vše během několika sekund.

Působivé. Teď ho požádejte, aby dobropis skutečně vystavil.

Smlouva se zákazníkem je v jiném systému. Pravidla pro schvalování jsou ukrytá v kódu aplikace. Fakturační nástroj očekává, že člověk prokliká několik obrazovek.

Agent chápe, co je třeba udělat, ale architektura mu nedovolí úkol dokončit.

Právě s tímto problémem se podle mě bude potýkat stále více podniků, až se agentní AI začne používat v produkčním prostředí. Zvláštní ale je, že překážka, která brání dokončení úkolu, má jen velmi málo společného s inteligencí agenta.

Už léta modernizujeme podnikový software pro lidi, kteří ho používají. Teď ho musíme modernizovat pro agenty, kteří s ním budou stále častěji pracovat.

Uživatelské rozhraní nikdy nebylo celým produktem

Zamyslete se nad tím, jak dnes funguje podnikový software. Lidé otevírají aplikace, procházejí řídicí panely, rozhodují se a převádějí práci z jednoho systému do druhého. Uživatelské rozhraní je způsob, jakým komunikují s firmou.

Agent takové obrazovky nutně nepotřebuje. Může načítat informace a spouštět akce prostřednictvím rozhraní API, serverů protokolu Model Context (MCP) a dalších programových rozhraní. To je součást posunu k bezhlavé architektuře.

Bezhlavá architektura ale neznamená, že aplikace zmizí. Její data, obchodní pravidla, oprávnění a požadavky na dodržování předpisů jsou stále důležité. Řekl bych, že jsou důležitější než kdy dřív.

Dodavatelé softwaru si po léta budovali konkurenční výhodu na propracovaných uživatelských rozhraních, uživatelských návycích a nákladech na přeškolování zaměstnanců. Tyto výhody slábnou, když agenti zvládají více práce, aniž by otevírali uživatelské rozhraní aplikace. Stále cennější je základní systém evidence: důvěryhodná data, ověřená doménová logika, provozní řízení a transakce, které lze auditovat.

Důsledky se projeví i v obchodní oblasti: až 234 miliard dolarů z výdajů na podnikové aplikace může být do roku 2030 ohroženo narušením trhu agentní AI. Jde o výdaje, které může narušení trhu ohrozit, nikoli o výdaje, jež zaručeně zmizí. A když agenti přebírají práci, kterou dříve lidé vykonávali v řídicích panelech, může být účtování za jednotlivé uživatele stále častěji nahrazováno modely založenými na využití, provedených akcích nebo dosažených výsledcích.

Pro dodavatele softwaru jde o výzvu pro obchodní model. Pro podniky, které se na jejich aplikace spoléhají, je to výzva architektonická.

Modernizovali jsme jednotlivé části, nikoli pracovní postupy

Většina podniků se modernizuje už řadu let. Jeden tým aktualizuje zastaralé aplikace. Jiný sjednocuje roztříštěná data na moderní platformě. Třetí vytváří integrace, nebo jednoduše obnovuje uživatelské rozhraní.

Každý projekt může samostatně uspět. Problémy začínají ve chvíli, kdy agent potřebuje provést pracovní postup napříč všemi těmito systémy.

Agentovi můžete poskytnout přesné informace o zákazníkovi, ale pokud aplikace, která na jejich základě jedná, stále skrývá klíčová pravidla ve starém kódu, co se stane dál? Nebo můžete zpřístupnit přehledné rozhraní API, zatímco data za ním zůstávají nesourodá. Agent může jednat, ale můžete jeho rozhodnutí důvěřovat?

V obou případech jsme modernizovali části technologií, ale nikoli samotnou práci.

Agentní AI nezajímá, který modernizační projekt byl úspěšný. Zajímá ji, zda funguje celý pracovní postup.

Takto to vypadá v praxi. Jeden klient potřeboval urychlit přípravu cenových nabídek na složité opravy motorů, u nichž smlouvy určují, které díly lze opravit, vyměnit nebo repasovat. Každá nabídka vyžadovala několik dní, někdy i týdnů ručního rešeršování smluv a příruček pro údržbu. Klient už svou datovou platformu modernizoval, ale příprava nabídek se nezrychlila, protože úzkým místem nikdy nebyla data. Bylo jím rešeršování. Přestavěli jsme tento pracovní postup na základě sady rešeršních agentů, zkrátili dobu rešeršování o 80 % a nabídky se začaly připravovat zcela jiným tempem.

Právě proto nelze modernizaci aplikací a dat plánovat jako dva nezávislé pracovní proudy. Architektura musí podporovat dosažení úplného obchodního výsledku.

Rozhraní API samo o sobě systém nepřipraví na práci s agenty

Člověk může snadno nabýt dojmu, že řešení je jednoduché: zpřístupnit koncové body, připojit agenta a je hotovo.

Kéž by to bylo tak snadné.

Načítat informace je jedna věc. Vystavit dobropis, aktualizovat finanční záznam nebo objednat náhradní díl je něco úplně jiného. Tady už mluvíme o provádění činností, ne pouze o přístupu k informacím.

Právě pro to používám termín řídicí rozhraní pro agenty: vymezené a řízené rozhraní, jehož prostřednictvím agenti čtou data ze systémů evidence a zapisují do nich.

Rozhraní API a servery MCP mohou agentům zpřístupňovat nástroje a data. MCP však automaticky nevynucuje vaše firemní pravidla ani nerozhoduje o tom, kdo je oprávněn jednat. Tyto mechanismy je stále nutné zabudovat do základních systémů a pracovních postupů.

Dokáže agent získávat důvěryhodná data z autoritativních zdrojů? Jsou firemní pravidla jasně definována a uplatňována jednotně? Dokáže doporučit postup, ale vykonat pouze ty kroky, k jejichž provedení má oprávnění? Dokážeme v případě problému vysledovat, co se stalo, vyřešit výjimku a případně vše vrátit zpět?

To nejsou problémy, které by sám o sobě vyřešil lepší model. Jde o otázky pracovních postupů, návrhu aplikací, datové architektury, integrace a správy. A je třeba je řešit společně.

Začněte u práce, ne u technologie

Kde tedy začít?

Nezačínal bych tím, že všechny aplikace převedu na bezhlavou architekturu nebo zpřístupním všechna dostupná rozhraní API. Začal bych jedním smysluplným firemním procesem.

Zmapujte ho od začátku do konce. Ve kterých systémech jsou uloženy záznamy? Kde se nachází firemní logika? Kterým datům může agent důvěřovat? Která rozhodnutí vyžadují schválení člověkem? Co se stane, když systém selže v průběhu procesu? Jak se zajišťuje řádná správa?

Odhalíte tak nejdůležitější mezery. To bude váš plán modernizace: koordinovaný seznam úkolů napříč aplikacemi, daty, integracemi a kontrolními mechanismy, který se bude řídit obchodním výsledkem, nikoli nesouvisejícími technologickými projekty.

A podle toho také měřte výsledky. Ne podle počtu zpřístupněných rozhraní API ani množství migrovaných dat, ale podle toho, zda proces spolehlivě doběhne do konce, jak se řeší výjimky a zda se zlepšují obchodní výsledky.

Cílem není všude dosáhnout autonomie. Cílem je spolehlivé a důvěryhodné provádění úkonů a zapojení lidského úsudku tam, kam patří.

Skutečný posun sahá dál než k bezhlavé architektuře

Nejvíc mě nenadchne to, že se zbavíme řídicích panelů. Ale to, co se stane, když lidé už nebudou muset při práci ručně přenášet úkoly mezi nepropojenými systémy.

Toho ale nedosáhneme tím, že nasadíme agenta nad architekturu, která pro něj nikdy nebyla navržena.

Novou generaci podnikového softwaru nebude určovat jen to, co lidem umožňuje vidět. Určovat ji bude také to, co agentům umožňuje spolehlivě a odpovědně dělat.

Guy Merritt, technický ředitel společnosti KMS, je oceňovaným autorem a zkušeným členem vrcholového vedení. Zastával vedoucí pozice v oblasti vývoje cloudových systémů, profesionálních služeb a produktů pro různá průmyslová odvětví, například spotřební elektroniku, telekomunikace, přírodní vědy a výrobu.

Dříve působil jako technologický ředitel ExaLink ve společnosti Deloitte a jako vedoucí pracovník v 5 začínajících firmách, kde odpovídal za strategii, inovace produktů, inženýrství, výrobu a získávání rizikového kapitálu.

Je členem poradního výboru IoT Community a předsedou Intelligence Manufacturing Center of Excellence.

Guy je autorem oceňované knihy „Proaktivní řízení rizik: Zvládání nejistoty při vývoji produktů“. Podílel se také jako autor na druhé knize „Praktická příručka projektového řízení“.