Nabídky na automatizaci s umělou inteligencí slibují, že systém přečte příchozí zprávu, vytáhne z ní podstatné a připraví odpověď. Skoro nikdy ale neříkají tu druhou půlku věty: kam se ta zpráva při čtení odešle, komu tam patří server a jak dlouho ji tam někdo má.
Přitom to je otázka, kterou si zákazník zodpoví sám během jednoho odpoledne, pokud ví, na co se ptát. Tenhle text popisuje, kde se dá text před odesláním zastavit, a končí sedmi otázkami, které fungují na kteroukoli nabídku, nejen na naši.
Jedna hranice předem: níže je popsaná technika, ne právní posouzení. Jestli konkrétní zpracování dat smíte provést, řekne právník, ne dodavatel automatizace.
Model nepotřebuje vidět všechno, co je ve zprávě
Pojem, který v nabídkách chybí nejčastěji, je anonymizace před odesláním. Znamená, že mezi vaším systémem a modelem stojí krok, který citlivé údaje nahradí zástupnými hodnotami dřív, než zpráva opustí vaši infrastrukturu. Model dostane strukturu a smysl, ne totožnost.
U jednoho projektu z léta 2026 to bylo požadavkem od začátku. Interně jsme si to formulovali 31. 5. 2026 a klientovi popsali 17. 6. 2026: mezi systémem a modelem běží vlastní anonymizátor, který citlivé údaje před odesláním nahradí, a k tomu oddělená infrastruktura.
Praktický dopad je v tom, co všechno není potřeba posílat. Model, který má připravit návrh dokumentu, potřebuje typ dokumentu, vztahy mezi stranami, lhůty a částky. Nepotřebuje jméno, rodné číslo, adresu ani číslo účtu - ty se doplní až do hotového dokumentu na vaší straně, po tom, co se text vrátí.
Nahrazování má jednu podmínku, na které se láme: musí být obousměrné a konzistentní. Když se ze dvou různých osob stane v jednom dokumentu jedna zástupná hodnota, model vrátí nesmysl, který vypadá dobře.
Nejlepší způsob, jak něco neposlat, je neposlat to vůbec
Anonymizace řeší data, která model vidět musí. Zbývá druhá skupina: dotazy, u kterých model nepřidává nic a riziko přidává.
U našeho vlastního bota, který informuje klienty o stavu jejich věci, je to rozhodnuté od 10. 3. 2026 takhle: dotaz na konkrétní spis obsluhuje skriptovaná větev, nikoli model. Model smí vidět název věci a nadpisy záznamů, cokoli, co identifikuje člověka, ne. Bot tím nepřestal být užitečný - obecné dotazy, formulace a shrnutí dál dělá model, jen se k němu nedostane ta jediná část, kde by chyba stála nejvíc.
Tohle rozhodnutí se dělá jednou, na papíře, a je levné. Když se neudělá, udělá se samo: všechno poteče do modelu, protože to je jednodušší cesta implementace.
Brána místo přímého napojení na jednoho dodavatele
Třetí místo, kde se rozhoduje o datech, je architektura napojení.
Ve zmíněném projektu jádro nekomunikuje s poskytovateli modelů přímo, ale přes jednu bránu, která umí formáty víc dodavatelů zároveň. Rozhodnuto 12. 6. 2026, a důvod byl vysloven nahlas: nebýt závislý na jednom poskytovateli. Doprovodné rozhodnutí z 9. 6. 2026: žádné krabicové řešení typu plug-and-play; systém přepíná mezi modely podle typu úlohy.
Pro zákazníka z toho plynou dvě věci, které jsou vidět až za rok. Když poskytovatel zdraží, změní podmínky nebo model stáhne, mění se konfigurace, ne systém. A když se ukáže, že určitá úloha nesmí opustit určité území nebo určitého poskytovatele, jde ta úloha přesměrovat samostatně, bez přestavby zbytku.
Na koho je účet a kde stojí server
Nejpraktičtější otázka z celého seznamu a odpověď se dá zjistit za minutu.
U téhož projektu si server i účet u poskytovatele modelů zřídil klient sám, na sebe, 24. 6. 2026. Není to formalita: majitel účtu vidí historii volání, platí přímo, může kdykoli změnit heslo a při rozchodu s dodavatelem nemusí nic přebírat, protože nikdy nic neopustilo jeho jméno.
Opačné uspořádání, kdy všechno běží na účtech dodavatele, není samo o sobě špatné a u malých automatizací je běžné. Musí ale být vědomé a musí být napsané, co se stane při ukončení spolupráce. O tom je samostatný text komu patří scénáře a účty.
Čím se systém krmí, je stejná otázka jako to, co z něj odchází
Poslední vrstva se týká znalostí, nikoli provozu. Systém, který má odpovídat podle vašich pravidel, je potřeba naplnit obsahem. Tady jsou dvě cesty a liší se závislostí.
Cizí uzavřená databáze je rychlá a přináší vazbu na dodavatele obsahu: jeho ceník, jeho podmínky, jeho rozhodnutí o tom, co v ní zůstane. Vlastní know-how plus otevřené veřejné registry je pomalejší start a majetek, který vám zůstane. V projektu z léta 2026 jsme se 17. 6. 2026 rozhodli pro druhou cestu a systém plnili interními materiály klienta.
Souvisí s tím i způsob učení. Když má systém víc dílčích agentů, každý pro jinou úlohu, učí se každý odděleně na svých datech. Jeden agent tak nezná materiál, který k jeho úloze nepatří, a to je nejlevnější způsob, jak omezit rozsah případné chyby.
Sedm otázek, které položte každému dodavateli
Odpovědi si nechte písemně, ideálně v nabídce.
- Který konkrétní poskytovatel modelu zpracovává naše zprávy a kde fyzicky běží?
- Které údaje ze zprávy odejdou a které se nahradí před odesláním?
- Existuje větev, která se k modelu vůbec nedostane, a co do ní patří?
- Na koho je účet u poskytovatele a kdo za něj platí?
- Kdo vidí historii dotazů a odpovědí, jak dlouho se uchovává a kdo ji umí smazat?
- Použijí se naše data k trénování? Pokud ne, čím je to doložené - nastavením účtu, smlouvou, nebo obojím?
- Co se stane, když poskytovatel zdraží nebo model stáhne? Kolik práce je přepnout jinam?
Sedmá otázka odhalí architekturu spolehlivěji než první šest. Dodavatel, který na ni odpoví „to je zabudované, přepnout nejde“, odpověděl i na otázku, čí je to systém.
Chcete si nechat prověřit konkrétní nabídku
Pošlete nám nabídku, kterou máte na stole, i kdyby byla od někoho jiného. Vrátíme seznam míst, kde není řečeno, co se s daty stane, a formulace, kterými si to vyžádáte.
Systémy, kde model pracuje jen s tím, co vidět musí, stavíme v rámci automatizace firemních procesů.
Napište na info@lamapixel.com nebo volejte +420 775 599 009.
