Pro OBD-II port svého auta jsem postavil MCP server, který jen čte, a nic, co by měnilo stav auta, jsem do něj nepustil. MCP je protokol, přes který AI asistent volá nástroje jiného systému. Oprávnění AI agenta v CRM nebo ERP otevírejte postupně: nejdřív jen čtení přes vlastního uživatele a roli, modul po modulu, potom zápis tam, kde jde změnu vrátit a dohledat, a peníze, ceny a trvalé mazání až nakonec, pokud vůbec.
Proč tak opatrně? Agent, který jen čte, se může splést v odpovědi, ale data v systému zůstanou, jak byla. Jakmile smí zapisovat, každá jeho chyba skončí přímo v kartě zákazníka nebo v objednávce. Proto začněte u čtení a práva přidávejte podle toho, jak si agent vede.
Co v CRM nebo ERP znamená „jen pro čtení“?
Jen pro čtení není jeden přepínač pro celý systém. Nastavuje se po modulech a v každém modulu jsou čtení a zápis dvě samostatná práva.
Takhle to funguje v našem Bitvea CRM. AI asistent se do něj připojuje přes MCP pod určitou rolí. Když má ta role kontakty jen pro čtení, asistent je taky může jen číst. Jak samotné MCP funguje a proč oprávnění nechává na serveru, rozebírá článek co je MCP a co přes něj AI zvládne.
Pak je tu třetí věc. Pokud role nemá k modulu čtení ani zápis, asistent nástroje toho modulu vůbec neuvidí. Nemusíte tedy spoléhat na to, že model poslechne pokyn „na faktury nesahej“. Pro agenta ten modul zkrátka neexistuje.
Než agenta napojíte na jakýkoli systém, ověřte si u dodavatele, jestli tohle umí. Pokud jde nastavit jen „všechno, nebo nic“, budete agentovi muset věřit víc, než je zdrávo.
V jakém pořadí agentovi oprávnění přidávat?
Práva přidávejte ve čtyřech krocích, od čtení až po akce, které se nedají vrátit.
Jako modelový příklad, ne případ klienta, vezměme vedoucí obchodu ve firmě se 30 lidmi, která chce, aby jí agent pomáhal s CRM. Pro její tým by kroky vypadaly takhle.
Krok | Co agent smí | Proč právě teď | Kdy jít o krok výš |
|---|---|---|---|
1. Číst | Prohlížet zákazníky, kontakty a obchodní případy | Nic nezmění a hned vidíte, jestli odpovídá správně | jeho odpovědi se shodují s tím, co váš tým najde ručně |
2. Zakládat drobnosti | Přidávat nové úkoly a poznámky | Špatnou poznámku někdo smaže a nic dalšího se nerozbije | lidé používají, co agent založil, a nemusejí to opravovat |
3. Upravovat vratné záznamy | Mazat kontakty měkkým smazáním, takže jdou obnovit | Chybu jde vrátit | nemuseli jste nic opravovat ručně |
4. Nakonec, nebo nikdy | Platby, ceny, trvalé mazání | Chyba stojí peníze nebo se nedá vzít zpět | každou takovou akci stejně schvaluje člověk |
Další krok otevřete, až když ten předchozí běží bez překvapení. Každý krok přitom dostane jen moduly, které agent pro svou práci opravdu potřebuje. Agent, který připravuje podklady pro obchodníky, k účetnictví přístup nemá, a díky oddělení po modulech o něm ani neví.
Čtvrtý krok klidně nedělejte vůbec. Platba nebo změna ceníku jsou přesně ty akce, u kterých má mít poslední slovo člověk.
Proč má mít agent vlastního uživatele, klíč s expirací a vypínač?
Agent nemá pracovat pod účtem žádného z kolegů. V Bitvea CRM pro něj správce založí samostatného technického uživatele, který není svázaný s žádným skutečným člověkem. Tomu uživateli pak dáte roli s právy přesně pro agentovu práci, nezávisle na tom, co smí obchodní ředitel.
Druhá pojistka je klíč, kterému už při vytvoření nastavíte automatickou expiraci. Po zkušebním provozu tak nezůstane viset přístup, na který všichni zapomněli.
Třetí je vypínač. Když agent udělá něco, co neměl, klíč zneplatníte a MCP server ho odmítne. Nemusíte nic přeprogramovat.
Tyhle tři věci si nechte předvést dřív, než agentovi dáte první právo k zápisu. Pokud systém samostatného uživatele, expiraci nebo zneplatnění klíče neumí, je to úkol na první fázi projektu.
Jak zařídit, aby šel každý zápis vrátit a agent nehádal?
První zápisy mají být vratné. Když v Bitvea CRM asistent smaže kontakt, je to měkké smazání a kontakt jde obnovit. Omyl agenta tak není konečný.
Druhá zásada je méně vidět, a přitom chrání data stejně. Agent nemá zapisovat hodnoty, které si domýšlí. Když pošle zákazníka, kterého systém nezná, kód produktu, který v katalogu není, nebo neexistující ceník, systém ho nemá uložit, ale vrátit agentovi zpátky. V našem CRM to tak funguje u jednoho ze sdílených číselníků: název, který v něm systém nenajde, neuloží a vrátí jako nespárovaný. Číselník se tak nezaplní duplicitními variantami, kterých si nikdo nevšimne.
Stejný přístup jsem zvolil u serveru pro auto. Repozitář má příkaz, který mění stav: mazání chybových kódů. Vyžaduje výslovné potvrzení, a přesto jsem ho do profilu jen pro čtení nezařadil. DTC databáze obsahuje i diagnostické postupy, které by šly zabalit jako nástroje. Záměrně jsem to neudělal.
Pro firemní systém z toho plyne jednoduché pravidlo. Co nejde vrátit, do první verze agenta nepatří, ani když je to schované za potvrzení.
Proč agenta nejdřív pustit do tichého režimu?
Než agentovi dáte zápis naostro, nechte ho pracovat v tichém režimu: připravuje návrhy a lidé je schvalují. Přesně tak začínal náš AI agent pro zákaznickou podporu. Než odpověděl prvnímu zákazníkovi, psal návrhy odpovědí na živé tickety a operátoři je před odesláním kontrolovali a opravovali.
V CRM to vypadá podobně. Agent navrhne úkol, poznámku nebo úpravu kontaktu a člověk ji potvrdí nebo zahodí. Z toho, kolik návrhů lidé opravují, poznáte, jestli je čas na další krok.
Tichý režim sám nestačí, potřebujete k němu ještě dvě věci. Zaprvé předání člověku. Když stejný agent dostane rozzlobenou nebo nejasnou zprávu, spor o fakturu nebo dotaz, ke kterému nenajde spolehlivý podklad, předá ho člověku i se svým návrhem. Zadruhé záznam. Agent loguje každou akci v helpdesku, takže zpětně dohledáte, co udělal.
Dohledatelnost usnadňují i pojmenované nástroje. U serveru pro auto jsem díky nim přesně viděl, na co se Claude ptal, co adaptér vrátil a odkud se vzalo výsledné vysvětlení. Agent, který smí jen volat několik jasně pojmenovaných nástrojů, se kontroluje mnohem snáz než agent s volným přístupem do databáze.
Kdy čtení přestane stačit?
Ani agent, který jen čte, není bez rizika. Čte totiž osobní údaje zákazníků a posílá je jazykovému modelu. U agenta pro podporu se proto citlivá pole před odesláním do modelu odstraní nebo zamaskují. Stejnou otázku si položte i u CRM: potřebuje model vidět rodné číslo nebo číslo účtu, aby odpověděl na dotaz obchodníka?
Agent jen pro čtení se taky může mýlit. Nic sice nepřepíše, ale špatnou odpovědí může obchodníka poslat špatným směrem. Proto i tady platí předání člověku, když si agent není jistý.
Jsou ale práce, kde čtení prostě nestačí. Když má agent přepisovat objednávky z e-mailů nebo zakládat kontakty z vizitek, bez zápisu nic neudělá. Projděte tedy první krok rychle a soustřeďte se na druhý a třetí: vratné zápisy, tichý režim a předání člověku. Pokud teprve vybíráte, kterou práci svěřit agentovi jako první, pomůže vám přehled procesů vhodných k automatizaci.
Chcete agenta napojit na vlastní CRM nebo ERP a nastavit mu práva správně od začátku? AI agenty stavíme na míru od 80 000 Kč. Povězte nám, co má agent ve vašem systému dělat, a společně navrhneme, kde začít.
