Firemní AI knowledge base: jak propojit znalosti celé firmy

Znalosti firmy bývají rozdělené mezi sdílený disk, repozitáře, firemní wiki, e-maily a několik interních systémů. Každé z těch míst mívá jiného správce, jiná přístupová práva a jiné zvyky v pojmenovávání. Ani člověk z firmy pak často neumí říct, která verze dokumentu platí.

Otázka, kterou tenhle díl řeší, zní zhruba takhle: „Máme dokumenty, wiki a informace v několika systémech. Jak z nich uděláme společnou znalostní bázi, které se dá ptát?“

Vítejte u prvního dílu seriálu Firemní AI nad vlastními daty. Dnes půjde o firemní AI knowledge base jako celou znalostní platformu. Tedy o to, co se do ní pustí, kdo za obsah odpovídá a jak se udržuje aktuální.

Co znamená udělat z několika systémů jednu znalostní bázi

Technicky jde o jedno vyhledávání nad víc zdroji a nad ním model, který z nalezených úryvků složí odpověď a doloží ji odkazem. Pracnější část projektu je ale podle mé zkušenosti organizační. Firma musí rozhodnout, které zdroje do báze patří, kdo za obsah každého z nich odpovídá a jak se do ní dostanou změny.

Chatovací okno je u takového systému poslední vrstva. Větší část práce tvoří podle mě správa znalostí a vyhledávání, protože na nich stojí kvalita odpovědí. Model se dá vyměnit, po výměně je ale potřeba znovu ověřit odpovědi, citace i provoz. Rozhodnutí o zdrojích a o odpovědnosti za obsah zůstávají.

Od interního chatbota nad jednou složkou směrnic se knowledge base liší rozsahem dodávky. Chatbot nad jedním dobře spravovaným zdrojem vystačí s menším rozsahem pravidel, i u něj je ale potřeba určit platnou verzi, správce a přístup. Báze propojuje víc zdrojů s různými správci, a pravidel proto potřebuje víc.

Z čeho se knowledge base skládá

Když mám popsat rozsah takové dodávky, dělím ji na několik částí. Žádnou z nich podle mě nejde vynechat, protože každá se jinak projeví na kvalitě odpovědí.

• Zdroje. Jmenovitý seznam míst, odkud se obsah bere, a k němu seznam toho, co se z nich záměrně nebere.
• Odpovědnost za obsah. U každé obsahové oblasti nebo sady dokumentů konkrétní člověk, který rozhoduje, co v ní platí, a dohoda, kdo řeší přesahy mezi oblastmi.
• Aktualizace. Jak často se zdroje čtou znovu, jak se pozná nová verze a co se stane se starou.
• Vyhledávání. Jak se z lidské otázky najdou správné úryvky, včetně vnitrofiremních zkratek a hovorových názvů dokumentů.
• Oprávnění. Kdo smí vidět který zdroj. Práva se musí uplatnit dřív, než se podklady dostanou k modelu.
• Odpovědi se zdrojem. Název dokumentu, jeho verze, konkrétní místo v něm a odkaz, na který se dá kliknout.

Poslední dvě části jsem rozebíral ve čtvrtém dílu předchozího seriálu z pohledu zaměstnance, který s odpověďmi pracuje. Tady je beru jako položky zadání, o kterých se rozhoduje dřív, než se začne stavět.

Jak se do báze dostanou wiki, disky, e-maily a interní systémy

Zdroje se nepřipojují stejně snadno a hlavně nemají stejnou hodnotu. Dokumenty na sdíleném disku a stránky ve firemní wiki se čtou poměrně dobře, protože obsahují text a nějakou strukturu. Potíž bývá v tom, co se v nich za ta léta nasbíralo.

Technicky se zdroj připojuje jednou ze dvou cest. U indexované varianty konektor nebo rozhraní zdrojového systému předá obsah, ten se převede na text (u skenů přes rozpoznávání textu) a uloží se do vyhledávacího indexu spolu s údaji o dokumentu, verzi, platnosti a přístupových právech. U živé varianty se zdroj prohledá až při dotazu a trvalá kopie obsahu v indexu nevzniká.

Microsoft tyhle varianty rozlišuje jako synchronizované a federované konektory (přehled konektorů Microsoftu, ověřeno 12. 11. 2026).

U indexované varianty se musí vyřešit i to, co se stane, když se dokument změní nebo smaže. Jinak v indexu zůstane stará kopie a báze z ní bude dál odpovídat.

U wiki a intranetu, tedy typicky v Confluence nebo na SharePointu, se obsah dědí po lidech, kteří už ve firmě nejsou. Stránky mívají autora, ale ne garanta, a často ani datum poslední kontroly. Navrhuji proto před napojením projít seznam prostorů a složek a u každé položky určit, jestli do báze patří celá, částečně, nebo vůbec.

E-maily a chaty bych do společné báze nedával. Obsahují osobní údaje, rozpracované verze a dohady, a to, co se v nich dohodlo, bývá platné jen pro jeden případ. Když je firma do báze přesto chce, patří k tomu předem napsaný účel, rozhodnutí vedení a vymezený rozsah. Celou historii všech schránek bych tam nepouštěl.

Interní systémy jako ERP, CRM nebo evidence zakázek drží data v tabulkách. Jejich hodnota je v aktuálním stavu, který se mění každý den, takže číslo z evidence má chodit přímo z evidence. V bázi může být popis procesu a pravidla. Práci s daty z tabulek a evidencí rozeberu ve čtvrtém dílu o analytickém systému.

Proč se oprávnění uklízí před spuštěním báze

Báze má každému ukázat jen to, co smí vidět ve zdrojovém systému. Přístupová práva se do ní ale automaticky nepřenesou. Při napojení se musí převzít, nebo se při každém dotazu ověřovat přímo ve zdroji, a to je u těchto projektů podle mě častý zdroj nepříjemných překvapení.

Potíže bývají i v samotných zdrojích. Na sdílených discích a ve wiki podle mé zkušenosti bývají složky, ke kterým má přístup víc lidí, než si kdo myslí. Dokud se v nich hledá ručně, většinou na to nikdo nepřijde.

Platí to i pro hotové produkty, které si firma kupuje jako licenci. Microsoft ve své dokumentaci k Microsoft 365 Copilotu uvádí, že pracuje s obsahem v Microsoft Graphu, ke kterému má přihlášený uživatel přístupová práva (dokumentace Microsoftu, ověřeno 12. 11. 2026). Přístup tedy nikomu nerozšíří. Snadno mu ale najde i dokumenty, ke kterým měl přístup jen kvůli špatně nastaveným právům a o kterých vůbec nevěděl.

Microsoft pro omezení nadměrného sdílení nabízí nástroj SharePoint Advanced Management. Jeho přehled uvádí tři cíle: omezit nekontrolované rozrůstání obsahu, spravovat jeho životní cyklus a zabránit nadměrnému sdílení. Mezi funkcemi je i omezení dohledatelnosti, které obsah vybraných webů na SharePointu vyřadí z celofiremního vyhledávání a z hledání v Copilotu (dokumentace Microsoftu, ověřeno 12. 11. 2026). Přístupová práva tím ale zůstávají stejná, takže kdo k dokumentu přístup měl, otevře si ho dál a Copilot mu otevřený dokument i shrne (dokumentace k omezení dohledatelnosti, ověřeno 12. 11. 2026).

Úklid oprávnění proto patří do harmonogramu před spuštěním báze. Postup, který doporučuji, je projít zdroje podle citlivosti, u sporných složek určit vlastníka a teprve pak je napojit.

Práva konkrétního uživatele se musí uplatnit dřív, než se úryvky dostanou k modelu. Odebrání přístupu ve zdroji se má do báze promítnout v dohodnuté lhůtě, včetně vyhledávacího indexu a případných mezipamětí.

U hotových produktů je potřeba zkontrolovat i konektory, které do Copilotu indexují obsah externích systémů. U spojení, které správce zakládá pro celou organizaci, nabízí Microsoft dvě volby: respektovat práva zdrojového systému, nebo zpřístupnit obsah všem v organizaci. Výslovně varuje, že chybná volba může vést k nadměrnému sdílení citlivého obsahu. Dodatečně ji u hotového spojení změnit nejde, spojení se musí smazat a založit znovu (dokumentace Microsoftu ke konektorům, ověřeno 12. 11. 2026).

Modelový scénář: cesta jedné změněné směrnice

Následující postup je modelový, firma i dokument jsou vymyšlené a nejde o výsledek testu. Ukazuji na něm, jak takový průchod navrhuji, aby se změna dostala až do odpovědí a nezůstala ležet v úložišti.

Modelová firma má směrnici o schvalování nákupů. Dosud platilo, že nákup nad sto tisíc korun schvaluje vedoucí úseku. Od 1. listopadu to má být nad padesát tisíc a navíc se žádostí přes formulář.

Garant novou verzi schválí na začátku října, tedy s předstihem, a systém ji načte při nejbližší kontrole.

1. Garant obsahu, v tomto případě finanční ředitel, uloží novou verzi do úložiště směrnic a doplní k ní datum platnosti a své schválení.
2. Systém při pravidelné kontrole zjistí, že se ve sledované složce změnil soubor, a stáhne ho ke zpracování.
3. Dokument se rozdělí na části podle článků. Ke každé se uloží název dokumentu, číslo verze, platnost od, kdo ji schválil a odkaz na konkrétní místo.
4. Předchozí verze se nemaže. Do 31. října zůstává platná a ke dni účinnosti nové verze se z běžného vyhledávání vyřadí.
5. Při dotazu na schvalovací limit systém vybere úryvky platné ke dni dotazu a zvlášť prohledá i schválené verze s budoucí účinností, samozřejmě při dodržení přístupových práv. Kdo se zeptá 15. října, dostane sto tisíc a upozornění, že od 1. listopadu platí nový limit. Kdo se zeptá 15. listopadu, dostane padesát tisíc.
6. K odpovědi přidá název a verzi směrnice, článek, odkaz a datum, od kterého nové pravidlo platí.
7. Kdo se výslovně ptá na dřívější stav, dostane odpověď z archivu a k ní upozornění, že jde o starší verzi.

Čtvrtý krok podle mě rozhoduje o tom, jestli bude báze důvěryhodná. Ve čtvrtém dílu předchozího seriálu jsem popisoval situaci, kdy systém poctivě odpověděl ze staré směrnice. Ležela v úložišti vedle platné a navenek je nic neodlišovalo.

Na prvním kroku je zároveň vidět, kde projekt stojí a padá. Když u nové verze chybí schválení a datum platnosti, nemá systém spolehlivý podklad pro výběr a klidně odpoví ze staré verze.

Co systém udělá s rozporem mezi dvěma zdroji

Druhá modelová situace nastane po 1. listopadu, kdy nová směrnice začne platit, a je nepříjemnější. Metodika oddělení nákupu říká, že žádost se posílá e-mailem vedoucímu, kdežto nová směrnice mluví o formuláři. Oba dokumenty jsou v tu chvíli platné a oba odpovídají na stejnou otázku.

Aby systém mohl s rozporem něco udělat, musí si firma předem připravit pravidla a určit, kdo podezření posoudí. Postup, který na takovou situaci navrhuji, má čtyři kroky.

1. Firma předem určí pořadí zdrojů. Nahoře bývá zákon a nadřazený předpis, pod ním vnitřní směrnice, pak metodika oddělení a nakonec wiki.
2. Systém najde k dotazu úryvky z obou dokumentů a označí podezření, že ke stejné otázce popisují různý postup.
3. Ukáže oba úryvky s jejich platností, upozorní na možný rozpor a uvede, který zdroj má podle pořadí přednost. Závazný postup ale nevydá, dokud garant neurčí, které pravidlo se na danou situaci vztahuje. Může totiž jít o jiný případ nebo o schválenou výjimku.
4. Podezření zapíše do seznamu pro garanta obsahu. Ten rozhodne, jestli se má dokument opravit nebo vyřadit, nebo jestli stačí upřesnit, pro které případy které pravidlo platí.

U druhého kroku je potřeba být opatrný. Spolehlivé automatické rozpoznání rozporu je podle mě zatím otevřený problém, protože dva texty mohou mluvit o jiné situaci, i když zní podobně.

Proto navrhuji stavět systém tak, aby rozpory označoval jen jako podezření a rozhodnutí nechával na člověku. Samotné pořadí zdrojů na rozhodnutí nestačí. Popisuji tím návrh postupu, který jsem takhle zatím neměřil.

Když báze rozpor najde, je to její užitečný výstup. Firma ho v dokumentech měla i předtím. Bez báze by se o něm nejspíš dozvěděla až ve chvíli, kdy by podle dvou různých pokynů jednali dva lidé.

Co se stane bez člověka odpovědného za obsah

Všechny kroky výše předpokládají, že někdo ve firmě rozhoduje, co platí. V rozpočtech se tahle role snadno přehlédne, protože nevypadá jako práce na AI projektu, a přitom na ní stojí výsledek.

Ve čtvrtém dílu předchozího seriálu jsem popsal projekt, kde příčina nekonzistentních odpovědí nebyla v nastavení vyhledávání, ale v dokumentech, které vznikaly živelně bez určené odpovědnosti za obsah. Nebudu to tady opakovat, ten popis je v dílu o běžném dni s dokumenty.

Garanta obsahu proto navrhuji určit v zadání pro každou obsahovou oblast zvlášť. V jedné wiki nebo na jednom SharePointu bývají finanční, technické i personální předpisy a o každé oblasti má rozhodovat člověk, který za ni odpovídá a rozumí jí.

Kolik je to práce, se dá odhadnout z toho, kolik dokumentů se ve firmě ročně mění. První úklid před spuštěním bývá podle mě výrazně pracnější než pozdější pravidelná kontrola. Navrhuji ho proto plánovat jako samostatnou položku harmonogramu i rozpočtu.

Kdy vlastní knowledge base nepotřebujete

Někdy je odpověď na úvodní otázku ta, že stačí uklidit a použít, co firma už má. Takové situace poznávám podle tří věcí.

• Skoro celý obsah leží v jedné platformě. Když jsou dokumenty, wiki i komunikace v jednom prostředí a přístupová práva v něm odpovídají skutečnosti, mohou vyhledávání a asistent té platformy stačit.
• Dokumentů je málo a mají jasného vlastníka. U několika desítek směrnic s pořádkem v názvech a verzích bych nejdřív zkusil přehlednou rozcestníkovou stránku. Když lidem stačí k nalezení toho, co hledají, vyjde to levněji než stavět systém.
• Hotový produkt obstojí ve zkoušce na vašich datech. Když asistent platformy na reprezentativní sadě vašich otázek, zdrojů a přístupových práv odpovídá správně a se zdrojem a sedí i místo zpracování a celkové náklady, vlastní bázi stavět nemusíte.

Rozhodnutí mezi firemní licencí hotového nástroje a vlastním systémem rozeberu v sedmém dílu, včetně odkazů na aktuální dokumentaci výrobců. Cenu vlastního řešení a to, co musí dodat firma, jsem rozebíral ve druhém dílu předchozího seriálu.

Co bude dál

Ve druhém dílu rozeberu interní AI chatbot v privátním cloudu, tedy co má být v zadání, když firma nechce provozovat vlastní servery. Projdu cestu dat krok za krokem. K tomu přidám tabulku požadavků s tím, kdo za který odpovídá a jak se dá při převzetí ověřit.

👉 Rizika veřejných nástrojů, vývoj, cenu i návratnost vlastního chatbota jsem rozebíral v seriálu Zabezpečený firemní AI chatbot. Zajímá vás technická stránka? Projděte si seriály Lokální RAG chatbot a Agentní RAG chatbot. Jak vypadá hotové nasazení u klienta, jsem popsal v případové studii interního AI agenta.

Celý seriál: Firemní AI nad vlastními daty: Kompletní průvodce

Všechny díly
1) Firemní AI knowledge base: jak propojit znalosti celé firmy (právě čtete)
2) Interní AI chatbot v privátním cloudu: co má obsahovat bezpečné řešení (připravuje se)
3) Lokální firemní AI v uzavřené síti: co musí zůstat uvnitř firmy (připravuje se)
4) Analytický AI systém: odborný report z firemních dat, který schvaluje člověk (připravuje se)
5) Vlastní AI pro studenty: lokální AI tutor nad poznámkami, knihami a přednáškami (připravuje se)
6) Analýza vztahů ve firemních datech: kdy má smysl znalostní graf (připravuje se)
7) Hotová firemní AI, nebo vlastní systém? Rozhodnutí podle vašich dat (připravuje se)
8) Jak otestovat firemní AI před převzetím: zadání pro dodavatele (připravuje se)
9) Jak vybrat dodavatele firemního AI systému a převzít hotové řešení (připravuje se)