Hlasový asistent pro dokumentaci, kterou nikdo nepíše

Ze specifikace se dozvíte, že pole existuje a jakého je typu. Málokdy se z ní ale dozvíte, proč tam vůbec je, které dva týmy se o něj měsíc dohadovaly nebo že všichni na projektu vědí, že se u německých zákazníků nevyplňuje kvůli rozhodnutí z roku 2019. Tohle všechno žije v rozhovorech u kafe, ve vláknech na Slacku, která už dávno odjela nahoru, a v poznámkách, které někdo prohodil při sdílení obrazovky.

Obvyklá reakce je požádat lidi, ať to sepíšou. Většinou to ale neudělají. Psaní je pomalé a ten, kdo danou znalost má, je zpravidla právě ten, kdo nemá čas.

Mluvit ale lidé budou, a nejen proto, že je to rychlejší. Polanyi to shrnul větou „víme víc, než dokážeme říct“ [C31]: velká část toho, co expert ví, je tacitní znalost. V praxi se na ni dá spolehnout, ale není v podobě, kterou by mohl jednoduše napsat. Nonaka popisuje, jak organizace takové znalosti převádějí do zaznamenané podoby, a krok od tacitní znalosti k explicitní v tom považuje za samostatný proces, který pohání dialog [C32].

Odpovídá to i naší zkušenosti. Když někoho požádáte, ať vám deset minut nahlas vysvětluje projekt, řekne vám věci, které by nikdy nenapsal, a mezi nimi i takové, o kterých ani nevěděl, že je ví. Proto jsme do Testuvionu přidali hlasového asistenta. Ptá se na projekt v jazyce, kterým se na projektu mluví, a z toho, co v rozhovoru zazní, může vzniknout dokument, se kterým pracuje zbytek platformy.

Pak si ale uvědomíte, co jste vlastně postavili: model s mikrofonem uvnitř produkční aplikace, který mluví o důvěrné práci a má nástroje sahající na skutečná data. To není funkce pro dokumentaci. To je autorizační problém s přívětivým hlasem.

Aby mohl asistent bezpečně běžet v produkční aplikaci, musí splnit tři podmínky.

Jedná jako člověk, který s ním mluví. Každé volání nástroje nese přístupové údaje tohoto uživatele, ať se provede v jeho prohlížeči, nebo na našem serveru. Oprávnění tak hlídá řízení přístupu, které už máme.

Má k dispozici osmnáct nástrojů ze 161. Celý katalog by zabral 40 737 tokenů dřív, než kdokoli promluví. OpenAI doporučuje mít na jeden krok méně než dvacet funkcí, výslovně ale jen jako orientační doporučení [C16].

Nemá nástroje, které by měnily obsah projektu. Katalog přijme jen nástroje deklarované jako read-only, a kdyby někdo přidal jiný, build selže.

Dnes navíc platí dvě věci. Navigační nástroje hlásí jen to, co rozhraní skutečně zobrazilo. A u poskytovatele, kterého teď používáme, se zvuk nedostane k našemu backendu ani k našemu model gateway[C15].

Zápis do projektu zatím není dostupný. Až bude, bude vyžadovat potvrzení uživatele a vynucovat ho bude server.

Člověk otevře projekt v Testuvionu a začne mluvit. Asistent se ptá, k čemu projekt slouží, co systém dělá a která pravidla jsou důležitá, tedy na věci, které specifikace bere jako samozřejmé. Během rozhovoru má k dispozici dokumenty a procesy projektu, stránku, kterou má uživatel právě otevřenou, i to, co naposledy změnil. Jeho otázky proto vycházejí z toho, co už je v projektu zaznamenané, a když odpověď odporuje dokumentaci, může se doptat. Mluvené i psané zprávy skončí ve stejném vlákně.

Když chce uživatel rozhovor uchovat, jedním krokem z celého vlákna vytvoří znalostní dokument. Ten se zařadí mezi projektové dokumenty, ze kterých platforma už dnes generuje testovací případy. Pravidlo, které dosud existovalo jen v něčí hlavě, tak lze dohledat až k testu. Nahrávka porady obvykle skončí jako hodina audia, kterou si málokdo znovu pustí. Cílený rozhovor, který vede systém, jenž už ví, co je zdokumentované, přinese právě tu část, která chyběla.

Celá funkce stojí na jednom rozhodnutí: rozhovor běží na speech-to-speech modelu. Dovnitř jde zvuk, ven jde zvuk a nic vaše slova nepřepisuje na text dřív, než na ně model odpoví. Alternativou je řetězec, ve kterém se řeč převede na text, text zpracuje jazykový model a výsledek se zase převede na řeč. Průvodce od OpenAI dělí obě cesty stejně: realtime varianta se podle něj nejlépe hodí pro „řeč, uvažování a používání nástrojů v jedné relaci“, řetězená pro situace, kdy „každý krok musí být viditelný nebo nahraditelný“ [C47].

Každý krok řetězené varianty prodlužuje čekání na první zvuk odpovědi a ve dvou textových krocích se k modelu přestane dostávat tón, váhání i přerušení [[C47](https://developers.openai.com/api/docs/guides/voice-agents)]. Používáme variantu s jedním krokem.

U rozhovoru, který má vytáhnout znalosti, na tom záleží. Podle naší zkušenosti lidé, kteří musí před každou odpovědí čekat, přejdou do diktování: mluví krátce, v celých větách a opatrně, a v takovém režimu to podstatné zazní jen málokdy. Potřebujete, aby člověk přemýšlel nahlas, odbíhal, opravoval se a skočil asistentovi do řeči, když ho pochopil špatně. K tomu musí odpovědi přicházet tak rychle, aby to pořád působilo jako rozhovor.

Ze stejného důvodu při otevřeném mikrofonu používáme sémantickou detekci konce promluvy. Nesleduje jen to, jestli jste zmlkli, ale i to, jestli jste dokončili myšlenku. Pauza, kdy si vybavujete, proč v roce 2019 padlo určité rozhodnutí, tak nemusí hned ukončit vaši promluvu. Kde se otevřený mikrofon nehodí, běží stejný rozhovor v režimu push-to-talk a stiskem tlačítka asistenta přerušíte.

Čeština přidává ještě jedno omezení. Realtime model mluví česky s anglickou fonetikou a žádný prompt, který jsme vyzkoušeli, to nezměnil. Během relace také může přejít do angličtiny, což je problém hlášený u více jazyků. Tohle už se promptem ovlivnit dá: asistent pro český projekt běží na promptu napsaném česky, který obsahuje pozitivně formulované pravidlo, že přizpůsobení se přízvuku mluvčího nikdy nemění jazyk odpovědi. Jak často k přepnutí přesto dochází, jsme zatím neměřili.

Hlasem se dá také pohybovat po aplikaci. Řeknete si o dokument a otevře se. Zeptáte se na proces a zobrazí se ve stromu. Zeptáte se, odkud pochází určité tvrzení, a stránka odroluje na příslušnou pasáž a zvýrazní ji. Ve velké aplikaci je jednodušší říct, co chcete, než si pamatovat, kde to je.

Asistent tedy čte a naviguje, ale obsah projektu nemění. Zajistit, aby to tak zůstalo, dalo nejvíc práce.

Jakmile agentovi zpřístupníte aplikaci, musíte rozhodnout, pod čí identitou bude jednat. Open Worldwide Application Security Project (OWASP), jehož žebříčky Top 10 váš bezpečnostní tým už čte, uvádí jednu z možných odpovědí jako jednu z hlavních příčin rizika Excessive Agency: integraci, která má jednat za jednoho člověka, ale k navazujícím systémům přistupuje „s obecnou vysoce privilegovanou identitou“, například čtečku dokumentů připojenou „pod privilegovaným účtem, který má přístup k souborům všech uživatelů“ [C20]. Jako nápravu doporučuje provádět akce „v kontextu konkrétního uživatele a s minimálními nezbytnými oprávněními“ [C21].

Takové pravidlo se ale časem může rozmělnit, a proto jsme ho zabudovali přímo do architektury: asistent nemá žádnou vlastní identitu. Každé volání nástroje vzniká v prohlížeči přihlášeného uživatele a nese jeho přístupové údaje. Tři nástroje pracují s obrazovkou a běží přímo v prohlížeči. Ostatní volání míří na jediný endpoint našeho backendu. Ten nástroj vyhledá v katalogu, odmítne všechno, co v katalogu není, a provede ho s oprávněními člověka, jehož přístupové údaje přišly s požadavkem. Jsou to stejná oprávnění, která by pro tohoto člověka platila na stránce dokumentů nebo ve stromu procesů. Endpoint vyžaduje jen oprávnění ke čtení, protože nic za ním nezapisuje.

Model v tomto návrhu nikdy nedostane žádný náš API credential. Pouze pojmenuje nástroj a zbytek obstará kód, což je druhé doporučení OWASP: tyto funkce má obsluhovat kód, nemají se svěřovat modelu [C18].

Nemusíme tedy zvlášť rozhodovat, co asistent smí vidět. Odpověď dává řízení přístupu, které pro přihlášené uživatele potřebujeme tak jako tak. Nevzniká žádná identita asistenta, kterou by bylo nutné spravovat, ani druhý model oprávnění, který by se musel udržovat v souladu s prvním. Pokud nějaký dokument nemůžete otevřít vy, nemůže ho otevřít ani hlas, který s vámi o projektu mluví.

U zvuku se nejsnáz řekne víc, než skutečně platí. Náš backend vystaví krátkodobý přístupový údaj pro relaci a předá prohlížeči URL. Spojení si pak prohlížeč vyjedná sám. Náš model gateway jen předává handshake a jeho dokumentace uvádí, že „audio nikdy neprochází přes proxy“ [C15]. Řeč se tak nedostane k našemu aplikačnímu backendu ani k našemu gateway. K poskytovateli modelu se ale dostane, a právě to je podstatné, pokud řešíte, kde vaše data leží. Platí to navíc jen díky poskytovateli a prostředníkovi, které dnes používáme, a obojí je věc konfigurace. Když jedno z nich změníte, může se změnit i odpověď.

Z prohlížeče vycházejí dva kanály a každý nese jinou identitu:

Zvuk jde k poskytovateli, model gateway předává jen handshake[[C15](https://docs.litellm.ai/docs/proxy/realtime_webrtc)]. Každé volání nástroje, které opustí prohlížeč, přichází do našeho API pod identitou mluvícího uživatele a platí pro něj stejné řízení přístupu jako ve zbytku produktu.

Nejjednodušší cesta k užitečnému hlasovému asistentovi je dát mu všechno. Celý náš backend už zpřístupňujeme jako kurátorovaný katalog přes Model Context Protocol (MCP), otevřený standard, kterým se agentům nabízejí nástroje a kontext. Katalog obsahuje 161 nástrojů a připojit ho k hlasové relaci je jen změna konfigurace.

Změřili jsme, co by to stálo. Definice všech 161 nástrojů v podobě, v jaké je dostává model, mají 40 737 tokenů. Osmnáct nástrojů, které hlasová relace skutečně dostává, má 2 156 tokenů. Rozdíl se zaplatí při každé relaci jako vstup, ještě před prvním slovem a před jakoukoli cache na straně poskytovatele.

Druhou námitkou je přesnost. OpenAI doporučuje „mít na začátku kroku k dispozici méně než 20 funkcí, jde ale jen o orientační doporučení“, a počet držet nízko „kvůli vyšší přesnosti“ [C16]. Osmnáct je těsně pod touto hranicí. Nástrojů je tolik proto, že hlasový a textový asistent sdílejí jeden katalog, a co textový asistent potřebuje ke čtení, dostane i hlasový. Kvůli schopnostem asistenta to přijímáme, rezerva je ale menší, než bychom chtěli.

Obvyklým řešením velkého katalogu je odložené načítání: modelu se nabídne jen několik nástrojů a ostatní se doplní, až když jsou potřeba. Stejný průvodce to i doporučuje [C16]. My to plánujeme o úroveň výš. Hlasový asistent zůstane malý a cokoli většího by předal agentovi na serveru, který má za něj k dispozici celý katalog. Nástroje se tedy nedoplňují uvnitř jedné relace, ale na rozhraní dvou agentů. Průvodce OpenAI tento tvar popisuje jako svou třetí architekturu: live model, který „předává uvažování a práci s nástroji samostatnému backendu“ [C47]. Druhou možností je filtrovat seznam nástrojů v každém kroku přímo uvnitř relace. Tu jsme zatím nevyhodnotili.

Jednu variantu jsme odmítli rovnou: aby se hlasová relace připojovala k našemu katalogu nástrojů přímo z infrastruktury poskytovatele. Spojení by pak nevznikalo v prohlížeči. Náš endpoint by musel být dostupný z infrastruktury poskytovatele a přístupové údaje uživatele by ležely ve stavu relace na jeho straně. Z autorizačního návrhu by se tak stala cesta k úniku přístupových údajů, a proto přístupové údaje zůstávají v prohlížeči.

Agent vám řekne, že něco udělal, a hlasové rozhraní vám bere obvyklý způsob, jak to ověřit. Na obrazovce není zpráva, kterou byste mohli porovnat se skutečností, jen sebejistá věta, kterou už jste slyšeli. Tam, kde jde o důvěryhodný záznam, je agent, který bezstarostně tvrdí, že něco uložil, horší než žádný agent.

Nástroje, které mění to, co máte před sebou, hlásí jen to, co rozhraní potvrdí. Když má asistent zvýraznit pasáž, zadá požadavek, přejde na dokument a počká, až stránka, která se skutečně zobrazila, odpoví: nalezeno, nebo nenalezeno. Opožděná odpověď na starší požadavek se nepřiřadí k novějšímu. Když do sedmi sekund nepřijde žádná odpověď nebo byl požadavek mezitím zrušen, nástroj vrátí „pending“. To znamená, že výsledek nikdo nezjistil, což je něco jiného než pasáž, která se nenašla. V Testuvionu neexistuje cesta, po které by nástroj vrátil úspěch, aniž by ho nastavila stránka dokumentu.

Právě tohle se dá přenést i na jiné agenty: poctivost je zabudovaná ve výsledku volání nástroje. Systémový prompt, který model žádá, aby netvrdil nic neověřeného, je prosba. Nástroj, který může vrátit jen to, co potvrdilo rozhraní, je omezení.

Přepis rozhovoru takovou kontrolu zatím nemá. Speech-to-speech model nám text toho, co jste řekli, nedává. Text, který ukládáme, pochází ze samostatné transkripce, kterou poskytovatel pořizuje souběžně s rozhovorem, a protože se zvuk k nám nedostane, posílá nám ho zpět prohlížeč. Na naší straně ho nic znovu nevytváří. OpenAI přesně tohle uvádí jako výhodu řetězené varianty: „přepis můžete uložit a ještě před odpovědí textového agenta na něj spustit kontroly pravidel“ [C47]. Ověřit náš přepis by znamenalo porovnat, co bylo zapsáno, s tím, co bylo řečeno. Takový mechanismus je složitější než potvrzení zvýraznění a zatím jsme ho nepostavili. Pro znalostní dokument, který si člověk projde, stačí záznam, který přijímáme na důvěru. Kdyby měl takový záznam někdy rozhodnout spor, stačit nebude.

Užitečnější verze této funkce by naplánovala schůzku, vytvořila testovací případ a upravila dokument. Tuhle část jsme záměrně neotevřeli, protože zabezpečení musí být promyšlené dřív než samotná schopnost.

Dnes žádný nástroj hlasového asistenta nemůže změnit obsah projektu a hlídá to build. Každý nástroj, který asistent může zavolat, je deklarovaný v jednom katalogu a katalog se odmítne načíst, pokud některá položka není označená jako read-only. Jeden test shodí build, pokud se v modulu katalogu jen objeví zápis do databáze, druhý ho shodí, pokud někdo deklaruje hlasový nástroj mimo tento katalog. Endpoint, který nástroje spouští, přijme jen názvy, které katalog zná. Odhodlaný vývojář by přesto mohl zápis označit jako čtení, takže jde o kontrolu, která shodí build, nikoli o důkaz. Tato vlastnost ale nestojí na tom, že si na ni někdo vzpomene, a na tom se dá stavět kontrola pro zápis.

OWASP uvádí, že u prompt injection „není jasné, zda existují spolehlivé metody prevence“ [C17], a k pravidlu o kontextu uživatele přidává druhé: u akcí s velkým dopadem vyžadovat schválení člověkem [C21]. Simon Willison to formuluje ostřeji: jakmile agent zpracoval nedůvěryhodný vstup, „musí být omezen tak, aby tento vstup nemohl vyvolat žádnou akci s vážnými důsledky“ [C19]. Ne nepravděpodobné, ale nemožné. Asistent, který sbírá znalosti, přitom celý den zpracovává obsah, který napsali jiní lidé. Je to jeho práce.

Návrh proto dělí všechny nástroje do tří úrovní. Nástroje pro čtení zůstanou povolené bez dalšího, tak jako dnes. Prostřední úroveň by mohla věci měnit, ale jen ve dvou krocích. V prvním kroku by tyto nástroje vůbec nešly zavolat: asistent by připravil plán, ujasnil si, co jste mysleli, a vrátil by se se shrnutím a krátkodobým podepsaným tokenem. Provést akci by mohl až druhý krok, který nese tento token i vaše potvrzení. Třetí úroveň by hlasem nebyla dostupná nikdy, ať má uživatel jakákoli oprávnění: smazání projektu, odebrání člena týmu nebo změna přístupových údajů integrací. Řeč je ztrátový kanál, mikrofon může být otevřený a některé operace by nemělo jít spustit jedinou větou.

Dvoufázové potvrzení podle návrhu.

Rozhodující je, kde se potvrzení vynucuje. V tomto návrhu nemůže první krok zapisující nástroj vůbec zavolat. Token, který vrátí, je krátkodobý a vázaný na relaci i na konkrétní plán ve shrnutí, takže pozdější krok nemůže provést jinou akci, než jakou člověk slyšel. K zápisu je pak potřeba druhý krok s tímto tokenem, a to až po potvrzení, které člověk vidí v prohlížeči. Otrávený dokument může asistenta přimět, aby něco navrhl, potvrzení ale nepřeskočí a plán nevymění. Jedna otázka zůstává v návrhu otevřená: zda stačí vyslovené „ano“, nebo zda by některé zápisy měly vždy vyžadovat klepnutí na potvrzovací kartu na obrazovce.

Nic z toho zatím není v provozu. Dnes asistent nemá čím zapisovat, protože katalog odmítne zaregistrovat nástroj, který zapisuje. Až zápis přijde, přijde jen s touto kontrolou.

Nic z toho nezávisí na hlasu ani na našem stacku. Pokud máte agenta, který pracuje se skutečnou aplikací, můžete si ještě dnes odpoledne odpovědět na tři otázky.

Pod jakou identitou jedná? Podívejte se, čí přístupové údaje jsou v požadavku, když něco dělá. Pokud je to service account, může agent dosáhnout všude, kam dosáhne tento účet. Kde má účet víc oprávnění než člověk, který s agentem pracuje, má je i agent, a žádný prompt na tom nic nezmění.

Kdyby ho někdo k něčemu přemluvil, co by ho zastavilo? Odpovězte mechanismem. „V instrukcích má, že to dělat nesmí“ se nepočítá: instrukce jsou prosba a prompt injection existuje právě proto, že prosbu lze přeargumentovat. Hledejte místo, kde záměr kompromitovaného modelu nejde dotáhnout do konce: oprávnění, které nemá, kontrolu, kterou nedokáže obejít, podpis, který nedokáže vytvořit. Pokud vás chrání jen instrukce v promptu, akci technicky nic nebrání.

Může některý nástroj ohlásit úspěch, kterého nedosáhl? Najděte nástroj, který mění stav systému nebo to, co uživatel vidí, a projděte, jak vzniká výsledek jeho volání. Pokud existuje cesta zpět, která neověřuje skutečný stav, agent jí dřív nebo později půjde.

U nás je první otázka vyřešená samotným návrhem a třetí platí všude, kde jsme si ji položili. Druhá má dvě odpovědi. Pro čtení je to katalog, který odmítne všechno, co není deklarované jako read-only, a k tomu kontroly, které shodí build. Pro zápis je to kontrola, kterou máme navrženou, ale zatím ne postavenou, a proto ta část funkce, která by něco měnila, není otevřená.

Znalosti, které se nikdy nezapíšou, stojí za to zachytit, protože zajištění kvality se podle nich stejně rozhoduje. Pravidlo, které žije jen v něčí hlavě, nejde dohledat k testu, zpochybnit při review ani znovu ověřit, když se systém změní. Hlas je další způsob, jak takové pravidlo dostat do systému, a přidává povinnost ověřit, co jste nasbírali. To, čím je sbíráte, je model s mikrofonem uvnitř vašeho produkčního systému, a zaslouží si stejnou pozornost jako cokoli jiného, co tomuto popisu odpovídá.

Asistent mluví prostřednictvím hostovaného realtime řečového modelu, který se vybírá v konfiguraci a není zapsaný natvrdo v kódu. Znalostní dokument z rozhovoru vytváří Claude Sonnet. Ani jeden z modelů nevidí nic, co by mluvící uživatel nemohl sám otevřít.

Tokeny jsme měřili 17. září 2026 nad připnutým snapshotem katalogu se stejnými 161 nástroji jako živá verze a nad osmnácti nástroji hlasové relace. Hodnoty se mění s každou změnou jednoho nebo druhého a znovu je změříme v březnu 2027. Popisují změřenou konfiguraci, nikoli pevnou cenu.