Een eigen AI-oplossing laten bouwen lijkt soms de logische eerste stap. Maar heb je nog niet getest wat jullie AI-platform al kan, dan weet je ook niet wat er ontbreekt. Denk aan een platform als ChatGPT Business, Microsoft 365 Copilot of Claude Team. Zonder die test loop je het risico te betalen voor het bouwen en onderhouden van software die je niet nodig hebt.
Heb je nog geen AI-platform en wil je AI breed in het team gebruiken? Dan is maatwerk meestal niet de eerste stap. Hebben jullie er al een, of zoek je alleen één koppeling of automatisering tussen programma's die jullie al gebruiken? Dan helpt dit artikel je kiezen.
Wachten kan ook onnodig werk opleveren. Zetten medewerkers na een jaar nog steeds dezelfde handmatige stappen, omdat "de AI dat nu eenmaal niet kan"? Dan is het tijd om dat uit te zoeken. Maar wanneer weet je genoeg om te besluiten of bouwen helpt?
Hoe weet je dat het AI-platform tekortschiet?
Ik kijk naar vier signalen samen. Eén signaal is meestal te weinig om een project te beginnen.
- Het werk herhaalt zich
Dezelfde stappen, in dezelfde volgorde, met vergelijkbare informatie. De gevallen zijn niet identiek, maar wel vast genoeg om vooraf te beschrijven wat er moet gebeuren en waar iemand moet meekijken. - Er blijft een concreet gat over
AI kan niet bij software die nodig is. Of de zoekfunctie vindt de juiste passage niet. Of het werk vraagt een overzicht of een akkoordstap (iemand keurt eerst goed) die het platform niet heeft. - Het is geprobeerd
Medewerkers hebben het geprobeerd met de instellingen, projecten, instructies en koppelingen die er al zijn, en het blijft haperen. Je kunt aanwijzen waar en waarom. - Het is de moeite waard
Hoe vaak het voorkomt, hoe lang het duurt of hoeveel fouten erin sluipen, rechtvaardigt bouwen én onderhouden. Een beetje tijdwinst is op zichzelf geen sterke reden om iets te laten bouwen. Weeg ook kwaliteit en risico mee.
Is het nog niet echt geprobeerd met wat er al is? Dan is de conclusie meestal: zoek eerst beter uit wat de huidige instellingen en mogelijkheden kunnen. Dat is verstandiger dan meteen in maatwerk investeren.
Zes vormen, van licht naar zwaar
Een gedeelde instructie is veel minder werk dan een eigen app. Hieronder staan zes vormen, ongeveer van weinig naar veel bouw- en onderhoudswerk. Ik kies de eenvoudigste vorm die het probleem oplost.
| Vorm | Wanneer past het? | Wat komt erbij kijken? |
|---|---|---|
| Gedeelde skill of instructie | Het platform kan het al, maar iedereen doet het anders. Vaak nog binnen het startproject op te lossen. | Een beschrijving, voorbeelden en een test. Geen code en geen onderhoudscontract. |
| Gedeeld project of assistent | Een terugkerende taak met vaste instructies en eigen documenten, voor medewerkers die al op dat platform werken. | Instellingen, documenten kiezen en testen. Blijft binnen het platform, dus er is geen nieuw programma om te leren. |
| MCP-koppeling | AI moet bij software waarvoor het platform zelf geen koppeling heeft: een branchepakket, een intern portaal of een eigen database. MCP is een standaard om AI aan software te koppelen. | Een koppeling die je één keer bouwt en daarna in meerdere AI-platforms kunt aansluiten, zoals ChatGPT, Claude en Copilot. Per platform test je wel de aansluiting, de rechten en de beveiliging. Vraagt technisch onderhoud en afspraken over rechten. |
| Agent buiten de chat | Het werk start bij een gebeurtenis, niet bij een vraag van een medewerker: een mail die binnenkomt, een nieuw document, een status die verandert. | Een startsignaal, een duidelijke taak en een harde grens voor wat AI zelf mag doen. Draait ook als niemand kijkt, dus een logboek en een noodstop zijn geen luxe. |
| Eigen kennisbank met zoekfunctie | Veel eigen documenten, waarbij de standaard zoekfunctie de juiste passage steeds niet vindt, of niet kan laten zien waar iets vandaan komt. | De documenten goed in stukken verdelen, een zoekindex en bij elk antwoord de bron. Zie de volgende paragraaf. |
| Interne software | Het werk past niet in een chatvenster: overzichten, statussen, meerdere rollen, een akkoordstap, een logboek van wie wat deed. | Een echt softwareproject: ontwerpen, bouwen, testen, onderhouden en later vernieuwen. De zwaarste vorm, en zelden de eerste. |
Een eigen zoekfunctie of interne app is veel werk. Daarom test ik eerst of een kleinere uitbreiding genoeg is. Die kunnen jullie snel in het dagelijkse werk uitproberen. Dan wordt snel duidelijk of de aanpak past.
Eigen kennisbank, vectorzoeken en RAG
Een taalmodel kent heel veel algemene taal, maar jullie eigen documenten kent het niet vanzelf. Wil je antwoorden op basis van jullie eigen documenten? Dan moet een zoekfunctie die informatie eerst ophalen en met de opdracht meesturen. Die werkwijze heet Retrieval-Augmented Generation (RAG): eerst de relevante documenten ophalen, dan pas het antwoord schrijven.
Bij dat ophalen kun je zoeken op precies dezelfde woorden, op betekenis of op een combinatie daarvan. Voor zoeken op betekenis knip je de documenten in stukken. Elk stuk zet je om in een reeks getallen die de betekenis van die tekst weergeeft: een embedding. Teksten die ongeveer hetzelfde betekenen, krijgen vergelijkbare getallen en liggen daardoor dicht bij elkaar. Een vectordatabase bewaart die reeksen en kan er snel in zoeken. Zo kan een vraag over "levertijd bij nabestelling" ook een alinea vinden over "doorlooptijd van een vervolgorder", zonder dat er één woord overeenkomt.
Zakelijke AI-platforms kunnen zelf zoeken in de software die je koppelt. Wat ze vinden, hangt af van welke software ze ondersteunen, de toegangsrechten en de manier van zoeken. Staan jullie documenten in gekoppelde software, zoals SharePoint of Google Drive? En kloppen de antwoorden, met de bron erbij? Dan heb je geen eigen zoekfunctie nodig, en zou ik die ook niet bouwen. Een eigen kennisbank wordt pas zinvol als minstens één van deze dingen speelt:
- geen enkele beschikbare koppeling ondersteunt de software waarin de documenten staan;
- de documenten zijn zo opgebouwd dat standaard in stukken knippen misgaat, zoals lange technische specificaties, tabellen, of contracten waarin één clausule het antwoord bepaalt;
- je moet bepalen welke versie van een document geldt, bijvoorbeeld omdat een oude procedure echt schade kan doen;
- je moet aantoonbaar kunnen citeren, tot op de passage, omdat een toezichthouder of klant daarom vraagt.
RAG helpt om antwoorden te onderbouwen met jullie eigen documenten, maar maakt ze niet vanzelf juist. Verouderde informatie blijft verouderd. Documenten die elkaar tegenspreken, blijven elkaar tegenspreken. Koppel je een rommelige verzameling documenten, dan doorzoek je vooral sneller een rommelige verzameling. Informatie opschonen en ordenen blijft daarom belangrijk mensenwerk.
Hoe een maatwerkopdracht loopt
Voor maatwerk maken jullie en ik een aparte opdracht, los van het startproject. Daarin staat wat ik bouw en hoe jullie en ik controleren of het werkt. Zo weten jullie vooraf wat jullie kunnen verwachten.
- Het probleem vastleggen. Welke stappen zet iemand nu, hoe vaak, met welke informatie, en waar gaat het mis? Zonder dat kun je achteraf niet zeggen of het gelukt is.
- De lichtste vorm kiezen. Ik loop met jullie de zes vormen af, van licht naar zwaar. We stoppen bij de eerste vorm die het gat aantoonbaar dicht.
- Grenzen bepalen. Bij welke software mag het, wat mag het alleen lezen, welke handeling gaat pas door als een mens akkoord geeft, en wat gebeurt er als het misgaat?
- Bouwen en testen met echt werk. Ik test met de dossiers, mails en documenten waar de oplossing straks mee moet werken, ook de rommelige gevallen. Niet alleen met een nette demoset.
- Overdragen. Jullie krijgen de instellingen en de documentatie die bij de opdracht horen. Accounts, abonnementen en jullie gegevens staan en blijven op naam van jullie bedrijf. Wat overdracht van de code inhoudt, leggen jullie en ik per opdracht vast.
Ik wil niet dat jullie technisch van mij afhankelijk worden. Daarom leggen jullie en ik vooraf vast wie het daarna onderhoudt, wie toegang heeft en wat ik overdraag. Dat stemmen we af op wat er echt gebouwd wordt.
Wat maatwerk niet oplost
Ook eigen software heeft duidelijke werkafspraken en bruikbare informatie nodig. Een agent kan een onduidelijk proces niet voor je oplossen. Een zoekindex maakt verkeerde informatie alleen makkelijker vindbaar. Gebruikt het team het huidige AI-platform nauwelijks? Zoek dan eerst uit waarom, voordat je er een app bij laat bouwen.
Daarnaast verandert de techniek snel. Wat ik vandaag op maat bouw omdat het platform het niet kan, wordt later misschien een standaardfunctie. Dat hoeft bouwen niet tegen te houden, zolang ik gericht bouw, opschrijf waarom het gemaakt is en af en toe controleer of het nog nodig is. Ik vind het prima om maatwerk weer te vervangen als het platform het inmiddels zelf goed kan.
De volgorde blijft: eerst zorgen dat wat jullie al gebruiken goed werkt. Dan in de praktijk zien wat er nog ontbreekt. En pas daarna bouwen wat aantoonbaar nodig is.
Microsoft legt uit hoe hybride zoeken exacte woorden en vectorzoeken combineert. Voor exacte codes, datums en namen werkt zoeken op woorden vaak juist beter. Dit verklaart de techniek. Het bewijst niet dat ieder AI-platform zo zoekt.
Wat dit artikel niet beantwoordt
- Wat maatwerk kost. Dat hangt af van de gekozen vorm en de omvang, en hoort in een eigen opdracht met duidelijke eisen voor de oplevering.
- Of jullie AI-platform al goed genoeg is ingesteld. Ontbreekt het signaal "het is geprobeerd", dan is deze vraag nog niet aan de orde.
- Rommelige processen of documenten. Maatwerk is zo goed als de informatie en afspraken eronder. Opruimen blijft mensenwerk.
