Jak bezpečně spustit interního asistenta nad firemními znalostmi?

Začněte úzkou sadou dokumentů a ověřeným přístupem

Bezpečné spuštění interního asistenta nad firemními znalostmi má čtyři kroky v pevném pořadí: vybrat úzkou a dobře popsanou první sadu dokumentů, ověřit, že asistent nikomu nezobrazí obsah mimo jeho přístupová práva, ukázat u každé odpovědi zdroj, ze kterého vychází, a teprve po týdnech ostrého provozu na této sadě rozšířit okruh dokumentů i uživatelů o další krok. Přeskočení tohoto pořadí, třeba spuštění rovnou na celém sdíleném disku, znamená, že první chyba přístupových práv se objeví až ve chvíli, kdy ji uvidí desítky lidí najednou, místo aby ji odhalil úzký pilotní okruh.

Proč úzká první sada dokumentů vyhrává

Široký záběr na začátku vypadá efektivněji, protože slibuje, že asistent bude od prvního dne užitečný pro víc otázek. V praxi ale platí opak: čím víc dokumentů je v prohledávaném prostoru hned na začátku, tím těžší je ověřit, že žádný z nich neobsahuje citlivý údaj, zastaralou informaci nebo obsah, který nemá vidět každý, kdo se zeptá. Úzká sada, například dokumentace jednoho procesu nebo znalostní báze jednoho týmu, dovolí vlastníkovi projektu skutečně přečíst každý dokument, který do prostoru vstupuje, a rozhodnout, zda tam patří. Rozšíření přichází až po ověření, že tento menší rozsah funguje bezpečně a odpovědi jsou věcně správné; teprve pak dává smysl přidat další oddělení nebo další typ dokumentu.

Řízení přístupu: asistent nesmí zobrazit víc, než uživatel smí vidět

Pokud asistent čerpá z dokumentů, ke kterým mají různí uživatelé různá oprávnění, musí toto rozlišení respektovat i on; jinak se stává cestou k nahlédnutí do mzdových podkladů, personálních záznamů nebo smluv, ke kterým by daný uživatel jinak přístup neměl. Kontrola spočívá v tom, že se oprávnění uživatele promítne do každého jednotlivého dotazu, a to nad rámec pouhého přihlášení k nástroji: člověk s omezeným přístupem musí dostat omezenou odpověď, i kdyby plný dokument obsahoval přesnější informaci. Otestujte to přímo, tedy nespoléhejte pouze na popis od dodavatele nástroje: přihlaste se pod účtem s omezeným oprávněním a položte dotaz, na který existuje přesná odpověď jen v dokumentu mimo jeho dosah. Správným výsledkem je odmítnutí odpovědi nebo obecnější formulace; citace nedostupného textu znamená, že kontrola selhala a rozšíření přístupu musí počkat na opravu. Širší souvislosti tohoto testu v rámci celkového zabezpečení popisuje článek jak zabezpečit AI ve firmě a otázky kolem zpracování osobních údajů rozvádí text můžu zpracovávat osobní údaje pomocí AI. Zda takto nastavený přístup splňuje požadavky GDPR na zabezpečení a minimalizaci zpracování, posuzuje pověřenec pro ochranu osobních údajů nebo bezpečnostní garant firmy; tento text popisuje samotnou kontrolu a způsob jejího otestování, právní posouzení dostatečnosti do něj nepatří.

Odkud odpověď pochází: viditelnost zdroje

Každá odpověď by měla vedle textu ukazovat i dokument nebo úsek, ze kterého vychází. Princip, podle kterého si prohledávací mechanismus vybírá zdroje pro odpověď, popisuje článek co je RAG. Bez viditelného odkazu nemá uživatel ani vlastník projektu způsob, jak rychle poznat, že asistent čerpal ze zastaralé verze nebo z dokumentu, který do jeho prohledávaného prostoru vůbec neměl patřit. Zobrazení zdroje má i druhý účel: umožňuje uživateli rozpoznat, kdy je vhodné odpovědi věřit bez dalšího ověření a kdy je namístě nahlédnout do původního dokumentu sám, například u čísel, termínů nebo přesných formulací. Pokud zvažovaný nástroj zdroj u odpovědi neumí zobrazit, jde o zásadní omezení k posouzení ještě před spuštěním; řešení tohoto nedostatku až po spuštění výrazně prodražuje a znejišťuje každou další kontrolu popsanou v tomto článku.

Artefakt: sekvence spuštění s branou před rozšířením

Následující sekvence popisuje pořadí kroků od přípravy po rozšíření přístupu. Krok 5 je brána: dokud není potvrzen, okruh dokumentů ani uživatelů se dál nerozšiřuje.

Krok	Co se v něm děje	Kdo jej potvrzuje
1. Výběr první sady	vybere se úzká, dobře popsaná skupina dokumentů jednoho procesu nebo týmu	vlastník projektu
2. Kontrola obsahu	každý dokument v sadě je přečten a zbaven obsahu, který nemá být zdrojem odpovědi	vlastník projektu a majitel dat
3. Nastavení přístupových práv	oprávnění uživatelů se promítnou do každého dotazu nad rámec přihlášení	správce nástroje a bezpečnostní garant
4. Test omezeného přístupu	pod účtem s omezeným oprávněním se ověří, že nedostupný obsah skutečně nejde získat	bezpečnostní garant
5. Brána před rozšířením	posouzení, zda kroky 2 až 4 proběhly bez otevřeného nálezu	vlastník projektu, bezpečnostní garant, případně pověřenec pro ochranu osobních údajů
6. Provoz s úzkým okruhem uživatelů	pilotní skupina asistenta používá a hlásí nesrovnalosti	vlastník projektu
7. Rozšíření o další sadu nebo skupinu	teprve po potvrzené bráně se přidává další dokumentová sada nebo skupina uživatelů	vlastník projektu

Co smí uživatelé zadávat a vkládat v prvních týdnech

V prvních týdnech provozu má smysl mít krátké a jasně napsané pravidlo, co uživatelé smí vkládat jako doplňující text k dotazu, například vlastní poznámku nebo úryvek e-mailu, a co do něj naopak nepatří, například osobní údaje třetích osob mimo firmu nebo obsah označený jako důvěrný nad rámec schválené sady. Podobná pravidla platí i pro veřejně dostupné nástroje, jak popisuje článek je bezpečné vkládat firemní data do ChatGPT; u interního asistenta jsou o to důležitější, že si uživatelé mohou mylně myslet, že jde o zcela uzavřené prostředí bez rizika. Pravidlo má být viditelné přímo v rozhraní; uložení pouze do samostatného dokumentu, který si nikdo nepřečte před prvním použitím, svůj účel nesplní. Stejně důležité je napsat, na jaké otázky asistent úmyslně neodpovídá, třeba na žádosti o právní nebo mzdové rozhodnutí týkající se konkrétního člověka, a kam se taková žádost má přesměrovat. Zpětná vazba z prvních týdnů, tedy nahlášené nesrovnalosti a dotazy mimo stanovený rozsah, je hlavním podkladem pro rozhodnutí u brány v kroku 5 artefaktu výše.

Stav zdrojů a omezení

Zdroje k tomuto textu, ověřené 5. 8. 2026, pokrývají obecné zásady řízení rizik AI systémů a povinnosti podle GDPR; nejde o certifikaci ani schválení konkrétního postupu spuštění popsaného výše. Funkce Govern a Map v NIST AI RMF podporují myšlenku odstupňovaného zavádění a jmenované odpovědnosti, aniž určují počet kroků sekvence nebo obsah brány v kroku 5, což je návrh CIAD. Články GDPR o zabezpečení a záměrné ochraně údajů se týkají zpracování osobních údajů obecně; text z nich vychází při formulaci testu přístupových práv, ale netvrdí, že projití tohoto testu samo o sobě znamená soulad s GDPR jako celkem. Konkrétní volbu nástroje, architektury nebo dodavatele tento článek úmyslně neřeší a nedoporučuje; to je rozhodnutí, které má u sebe mít IT vedení firmy společně s bezpečnostním garantem a pověřencem pro ochranu osobních údajů.