Als een AI-assistent een fout antwoord geeft, kijkt iedereen naar het model. Ik kijk eerst naar de map waar hij uit leest. Daar ligt het probleem veel vaker.
Een AI-kennisbank is geen technisch onderdeel dat je één keer aansluit. Het is content met een houdbaarheidsdatum. Zonder eigenaar wordt het een archief dat met grote stelligheid oude antwoorden geeft.
- RAG (de assistent zoekt eerst in je eigen documenten) maakt antwoorden niet automatisch juist. Het maakt ze zo juist als je bronnen.
- Oude, dubbele en tegenstrijdige documenten zijn de stille oorzaak van veel “hallucinaties”.
- Rechten op de kennisbank zijn net zo belangrijk als de inhoud: wat de assistent kan vinden, kan hij ook vertellen.
- Geef elke bron een eigenaar, een datum en een plek om fouten te melden. Dat is meer werk dan techniek.
Wat er gebeurde
Het patroon is bekend. Een organisatie wil een interne assistent die vragen over HR, procedures of producten beantwoordt. Iemand koppelt de bestaande SharePoint, Google Drive of wiki. De demo is indrukwekkend: binnen seconden een antwoord, met bronvermelding erbij.
Een paar weken later komen de klachten. Het verlofbeleid klopt niet meer. De assistent noemt een tarief van vorig jaar. Hij citeert een werkinstructie die al twee keer is vervangen, omdat de oude versie gewoon nog in dezelfde map staat. Niemand had die map ooit opgeruimd, want tot nu toe las niemand hem.
Dat is het punt. Een mens die een document uit 2022 opent, ziet de datum en twijfelt. Een assistent die drie fragmenten combineert, presenteert het als één glad antwoord. De twijfel verdwijnt, de fout blijft.
Een AI-assistent maakt je documentatie niet beter. Hij maakt het verschil tussen goede en slechte documentatie alleen sneller zichtbaar.
Waarom de AI-kennisbank nu relevant is
RAG wordt vaak verkocht als het antwoord op hallucinaties. Dat klopt half. De OWASP Top 10 voor LLM-toepassingen (LLM09: Misinformation) noemt RAG inderdaad als maatregel, maar dan met informatie uit geverifieerde en betrouwbare bronnen. Dat woord “geverifieerd” is precies het werk dat in de meeste projecten overgeslagen wordt.
Dezelfde lijst heeft een apart risico voor de kennisbank zelf: OWASP LLM08: Vector and Embedding Weaknesses. Daarin staan onder meer lekken door verkeerde toegangsrechten, tegenstrijdige kennis uit verschillende bronnen en vervuilde data, die ook onbedoeld kan ontstaan. De aanbevolen maatregelen zijn opvallend saai: rechten per groep, bronnen valideren, de kennisbank regelmatig auditen en content labelen.
Microsoft zegt het in de praktijk ook. Met Restricted Content Discovery kun je SharePoint-sites tijdelijk buiten Copilot en organisatiebrede zoekresultaten houden, juist omdat organisaties eerst tijd nodig hebben om rechten en inhoud te controleren. Dat is een leverancier die je vertelt: sluit niet zomaar alles aan.
Waar het in een AI-kennisbank meestal misgaat:
- Versies naast elkaar. “Beleid_v3_definitief” en “Beleid_v4” staan allebei in de bron. De assistent kiest wat het best op de vraag lijkt, niet wat het nieuwst is.
- Geen datum, geen eigenaar. Niemand weet wie een document mag aanpassen, dus niemand doet het.
- Te ruime rechten. Een map die “iedereen in de organisatie” kon zien maar die niemand vond, is ineens doorzoekbaar via één vraag. Hetzelfde principe als bij agents die overal bij mogen.
- Geen terugkoppeling. Een medewerker ziet een fout antwoord, haalt zijn schouders op en zoekt het zelf op. De bron blijft fout, de volgende krijgt hetzelfde antwoord.
Wat je nu kunt doen: een AI-kennisbank die bij blijft
Je hebt hiervoor geen nieuw platform nodig. Wel een paar afspraken die je normaal pas maakt als het al misgaat. Dat onderhoud hoort bij elke AI-automatisering voor je processen, niet alleen bij de eerste bouw.
- Begin klein en bewust. Sluit niet “de hele SharePoint” aan, maar één afgebakende set bronnen voor één type vraag. Breid pas uit als die set op orde is.
- Wijs per bron een eigenaar aan. Een naam, geen afdeling. Die persoon beslist wat erin hoort en wat eruit gaat.
- Geef documenten een geldigheidsdatum. Verlopen documenten gaan automatisch uit de index of krijgen een duidelijke markering, tot de eigenaar ze opnieuw goedkeurt.
- Ruim versies op vóór je indexeert. Eén geldende versie per onderwerp. Oude versies naar een archief dat de assistent niet leest.
- Controleer rechten voordat de assistent ze erft. Wat iemand niet mag lezen, mag de assistent ook niet voor die persoon samenvatten. Tools zoals de data access governance-rapporten van SharePoint helpen om overdeling eerst te vinden.
- Bouw een meldroute in. Een duim omlaag die bij de eigenaar van de bron landt, niet in een dashboard dat niemand opent.
- Test met echte vragen. Houd een vaste lijst van twintig vragen met het juiste antwoord bij en draai die na elke grote wijziging in de bronnen. Dat is dezelfde discipline als bij model drift, maar dan voor je eigen content.
Wat “goed genoeg” vandaag al is
Voor je belangrijkste assistent: een lijst van de bronnen die hij leest, met per bron een eigenaar en de datum van de laatste controle. Als je die lijst niet kunt maken, weet je ook niet waar zijn antwoorden vandaan komen. Dat is geen technisch probleem, dat is AI-governance die alleen op papier bestaat.
Wil je een assistent of agent die met beheerde bronnen werkt, met eigenaarschap en tests vanaf dag één? Dan past managed AI-agents. Of plan een kort gesprek via contact en we kijken samen naar je huidige bronnen.
Weet jij waar je AI-assistent zijn antwoorden vandaan haalt?
We lopen samen je AI-kennisbank door: welke bronnen, welke rechten, wie is eigenaar en wat is verouderd. Je krijgt een korte lijst met wat eruit moet en wat eerst op orde moet.