Blog · 29/07/2026

Mijn intranet koppelen aan AI: waarom retrieval niet magisch is

Ik heb een jaar lang een intranet voor Guidance gebouwd. Het werkt. Nu willen we een AI-agent eraan hangen. Maar wat ik heb geleerd over hoe informatie echt werkt, maakt me voorzichtig — en wijzer dan de hype.

Het probleem: een jaar intranet, nu een agent

Ik heb vorig jaar een intranet gebouwd voor Guidance. Dat was het werk: alle informatie centraliseren, zodat iedereen — ongeacht afdeling — kon vinden wat ze nodig hadden. Wie is onze klant X? Wat staat in contract Y? Hoe werkt onboarding? Waar is dat document over die beslissing van vorig jaar?

Het werkt. Iedereen gebruikt het. En ik heb ondertussen geleerd wat het betekent om informatie werkelijk toegankelijk te maken.

Nu willen we het volgende stap zetten: in plaats van zoeken, vragen stellen. Een AI-agent die dat intranet doorzoekt en antwoord geeft. Klinkt simpel. En precies daarom ben ik voorzichtig.

Het probleem is niet dat de AI niet slim genoeg is. De meeste agent-failures komen niet van zwakke modellen, maar van ontbrekende of slechte context. Ik ben bang voor iets anders: dat ik mijn intranet nog niet goed genoeg begrijp om het aan een AI te geven.

Wat een jaar intranet me heeft geleerd

Drie dingen die me voorzichtig maken:

1. Mensen zoeken niet zoals je denkt

Toen we het intranet bouwden, hadden we een zoekfunctie gebouwd die — op papier — logisch was. Categorieën, tags, hiërarchie. Maar hoe mensen het werkelijk gebruiken? Compleet anders. Ze zoeken op trefwoorden die niet in onze structuur zitten. Ze vinden iets, en drie minuten later realiseren ze dat ze iets anders nodig hebben dat niet in de buurt staat. Ze vergeten dat een document überhaupt bestaat totdat iemand anders ernaar verwijst.

Een AI-agent die hetzelfde retrieval-probleem heeft, maar nu “intelligenter” klinkt, zal niet dóór dit probleem heen groeien. Het zal het eerder verbergen: de agent zal zelfverzekerd antwoord geven op basis van een deel van de informatie.

2. Informatie is chaotisch opgeslagen

Ik dacht dat ik het intranet kon vullen en klaar was. Maar informatie in Guidance zit overal: in Git (code, architectuur-beslissingen), in Jira (taken, bugs, discussies), in Notion (processen, templates), in Slack (beslissingen, quick-fixes, context die nooit geëxporteerd wordt), in Google Drive (contracten, analyses). Elk systeem heeft een ander formaat, andere permissies, ander update-ritme.

Om dat allemaal in het intranet te brengen, moest ik normaliseren. Wat betekent “een stuk informatie”? Wat hou ik, wat gooi ik weg? Welke context is onmisbaar, welke is ruis?

Nu wil ik hetzelfde doen voor RAG: die chaos in een vector-database gooien. En ik weet al dat het intranet niet volmaakt is. Dan is mijn AI ook niet volmaakt.

3. Context verdwijnt

Een Jira-ticket zegt: “Fix authenticatie voor API”. Prima. Maar waarom? Welke bug was het? Welke klant was getroffen? Wat was de discussie erover? Dat staat in Slack, of in een vergader-note, of nergens.

Mijn intranet kan dit partly oplossen (we linken tickets aan issues, we schrijven context op). Maar veel context is impliciet: het zit in het hoofd van mensen. Een AI die het ticket leest, ziet alleen het ticket. Dan geeft hij een antwoord dat formeel juist is, maar niet wijzer.

RAG en Memory zijn niet hetzelfde

Ik zie mensen deze door elkaar halen, dus ik zet het scherp.

RAG is: je agent krijgt een vraag, haalt relevante stukken uit je database op (in mijn geval: mijn intranet), geeft die aan het model, en het model antwoordt. Stateless. Elke vraag begint opnieuw.

Memory is: je agent onthoudt wat hij in vorige gesprekken heeft gedaan, welke patronen hij heeft gezien. Stateful. Context accumuleert.

Je agent heeft beide nodig. Zonder RAG antwoordt hij op basis van wat het basismodel “weet” — dus halfslecht. Zonder Memory begint elke vraag opnieuw.

Voor mijn intranet: RAG betekent dat de agent Jira-tickets, wiki-pagina’s, contracten ophaalt. Memory betekent dat hij onthoudt: “Deze persoon vraagt veel over onboarding — volgende keer sneller aanbieden, gerelateerde documenten voorstellen.” Het ene vervangt het andere niet.

Privacy is je voordeel, maar alleen als je het echt doet

Hier ben ik eerlijk: mijn bedrijf wil zijn informatie niet in OpenAI’s servers. Dat is logisch. Dus we bouwen intern.

Maar: als ik Claude of Open AI gebruik voor het redeneren — en dat zal waarschijnlijk nodig zijn — dan upload ik context naar hun servers. Dus: niet helemaal privé. En als ik mijn vector-database outsource naar Pinecone (gemak, schaal), dan is ook dat niet binnenboord.

Mijn privacy-voordeel werkt alleen als ik consequent ben. Wat betekent: mogelijk lokale models, mogelijk zelf hosten, mogelijk data-extractie voordat ik upload. Dat kost meer dan “we zetten Claude op”.

Dit is niet een reden om niet te beginnen. Dit is een reden om voorzichtig te zijn. Privacy-voordeel verdient voorzichtigheid.

De integratieketen: waar het échte werk begint

Mijn intranet vult zichzelf uit zes bronnen: Git, Jira, Notion, wiki, Google Drive, Slack (partial). Elk met zijn eigen sync-patroon, schema, permissies. Dit was al moeilijk.

Nu wil ik hetzelfde doen voor de AI: dezelfde bronnen, maar nu in een vector-database. Dat voegt toe:

Latency: hoe snel is mijn data beschikbaar in de vector-database? Realtime? Nachtelijk batch?
Synchroon: een Jira-ticket verandert; mijn vector-database weet dit wanneer?
Failure-points: als één connector breekt, wat dan? Geeft de agent oude informatie?
Permissies: welke informatie mag welke persoon via de agent zien? Dit moet je normalizeir voordat je indexeert.

Progress zegt: “Dit is enkele weken werk.” Dat is technisch waar. Het telt alleen niet de integratie-pijn die ik al ken.

Drie voorzorgsmaatregelen voordat ik code schrijf

1. Definieer je metriek — nu, niet later

Mijn intranet-baseline: hoelang duurt het nu om informatie te vinden? 5 minuten? 15? Wie zoekt het? Hoe vaak? Welke vragen worden herhaald?

Ik heb dit data. Nu moet ik het harden in “succes-criteria”:

Als de AI hetzelfde antwoord geeft als het intranet, maar in 30 seconden, is dat een win.
Als de AI 90% van de vragen correct beantwoordt (na optimalisering), is dat acceptabel.
Als mijn team hem in 2 van de 5 werkdagen niet gebruikt, stop ik.

Zonder deze criteria weet ik niet of ik iets heb bereikt.

2. Test je retrieval voordat je je agent live zet

DoorDash en Grab gebruiken beiden: RAG + verificatie + menselijke escalatie. Dat leren me: retrieval alleen is niet genoeg. Als mijn vector-database slechte relevante stukken ophaalt, geeft mijn agent slecht antwoord. Geen model lost dat op.

Mijn voorstel: voordat ik live ga, test ik handmatig. “Hoe haalt mijn retrieval informatie op voor deze 10 vragen?” Werkt het? Wat mist er? Daarna optimaliseer ik. Daarna live.

3. Bepaal wie wat mag zien — voordat je indexeert

Mijn intranet heeft permissies: niet iedereen ziet contracten, niet iedereen ziet salarissen. Als mijn AI dat niet respecteert, geef ik vertrouwelijke informatie aan iedereen. Dat is een permissie-probleem, niet tech.

Ik moet voordat ik indexeer bepalen: welke documenten uit het intranet mogen alle werknemers zien via de AI? Welke alleen leidinggevenden? Dit moet in mijn vector-database en retrievalogen zitten.

Waar dit breekt en hoe ik het zien aankomen

Onvolledige informatie

Mijn intranet is niet compleet. Oude Slack-threads zitten er niet in. Verwijderde Google Docs ook niet. Mijn AI zal zeggen: “daar is niets over bekend” — technisch juist, voor gebruikers nutteloos.

Dit voorkomen: ik accepteer dat gaten bestaan, of ik vul ze op voorhand. Niets tussendoor.

Context-verlies door normalisatie

Een Slack-thread heeft nuance. Discussie. Context. Wanneer ik dat in twee zinnen samenvat voor het intranet, verdwijnt nuance. Mijn AI ziet alleen die twee zinnen. Dan geeft hij simplistisch antwoord.

Dit is onvermijdelijk. Ik kan het minimaliseren: links toevoegen, backreferences, duidelijk zeggen waar volle context zit. Maar volledig voorkomen? Nee.

Synchroon-lag

Een contract wordt bijgewerkt. Mijn intranet ziet dit vandaag. Mijn vector-database ziet dit morgen (als ik nachtelijke sync heb) of nooit (als ik het vergeet). Mijn AI geeft oude informatie.

Dit bepaalt mijn architecture: realtime-sync (duurder, complexer) of batch (langzamer, riskanter)? Ik moet dit kiezen en accepteren wat dat betekent.

Hallucinations met autoriteit

Dit is mijn grootste angst: een agent die fout antwoord geeft, maar het zo zelfverzekerd zegt dat mensen het geloven. Mijn intranet zegt “dit weet ik niet”. Mijn AI zegt “dit is zo” — maar het is fout.

Dit voorkomen: guardrails. Verificatie. Confidence-scores. En training voor mijn team: “dit is een assistent, niet een bron van waarheid.”

Hoe ik begin

Week 1-2: Ik indexeer één datasource — laten we zeggen mijn wiki-pagina’s en Jira-tickets. Test: “Hoe haalt mijn vector-database informatie op voor deze 10 vragen?” Wat werkt? Wat mist er?

Week 3-4: Ik test een eerste agent. Vragen stellen. Zien wat fout gaat. Noteer false negatives (vragen die geen antwoord geven maar hadden moeten) en hallucinations (foutieve antwoorden).

Week 5-6: Ik fix wat ik heb geleerd. Chunking aanpassen? Vector-model wisselen? Context toevoegen? Dit bepaalt of week 7 live gaat.

Week 7+: Pas voeg ik de volgende datasource toe. Niet alles tegelijk. Stap voor stap, telkens meetend.

Dit is niet langzaam. Dit is voorzichtig. Groot verschil.

De exit-strategie

Voordat ik begin: wanneer stop ik?

Ik zeg hardop:

Als mijn team na vier weken ziet “dit gebruiken we niet, we zoeken nog steeds zelf”, stop ik.
Als onderhoud meer kost dan besparing (engineering-uren groter dan intranet-zoekvragen bespaard), stop ik.
Als hallucinations boven 15% liggen nadat ik heb geoptimaliseerd, stop ik.
Als mijn vector-database constant out-of-sync is, stop ik.

Dit zeggen maakt stoppen niet voelen als falen. Het voelt als voorzichtigheid.

Waarom dit nu logisch is

Ik heb een jaar aan informatie-architectuur gedaan. Ik weet hoe mensen echt zoeken. Ik weet waar data zit, wat chaotisch is, wat werkt. Dat is een sterke basis.

Een AI-agent die mijn intranet kan querien, kan sneller antwoord geven dan mensen handmatig zoeken. Dat loont zich. Maar alleen als ik voorzichtig ben. Alleen als ik test. Alleen als ik stop wanneer het niet werkt.

Dit artikel is voor mezelf geschreven. Ik wil het over zes maanden terugread en denken: ja, dit hebben we goed zien aankomen.