Maatwerk heeft in AI-land een timingprobleem. Het wordt vaak aan het begin verkocht, wanneer niemand nog weet wat het standaardplatform eigenlijk al kan. Dan bouw je een oplossing voor een probleem dat je nog niet hebt gemeten, en betaal je voor onderhoud van code die achteraf overbodig blijkt.
Het omgekeerde kost overigens net zo veel geld. Een organisatie die na een jaar dagelijks gebruik nog steeds dezelfde vier handmatige stappen zet omdat "de AI dat nu eenmaal niet kan", laat structureel werk liggen dat prima te ondersteunen was. De vraag is dus wanneer je genoeg weet om die beslissing te nemen.
Breukr-uitgangspunt
Maatwerk is bij mij bewust de tweede stap. Ik bouw pas iets eigens wanneer dagelijks gebruik van de beheerde basis een concreet hiaat heeft laten zien, en wanneer een lichtere oplossing dat hiaat niet meer dicht. Wat er dan komt, krijgt een eigen scope, prijs, eigenaar en acceptatiecriteria.
Hoe herken je dat je de grens hebt bereikt?
Een maatwerkvraag wordt serieus wanneer vier signalen tegelijk optreden. Eén los signaal is meestal geen reden om te bouwen.
- Het proces herhaalt zich Dezelfde stappen, in dezelfde volgorde, op vergelijkbare informatie. De gevallen zijn niet identiek, maar wel stabiel genoeg om vooraf te beschrijven wat er moet gebeuren en waar iemand moet meekijken.
- De bron is niet bereikbaar Het werk leunt op een systeem waar geen goedgekeurde standaardconnector voor bestaat, of op informatie die achter een interface zit die niets naar buiten geeft.
- Het is geprobeerd Medewerkers hebben het met de bestaande instellingen, projecten, instructies en connectors geprobeerd en het blijft haperen. Je kunt aanwijzen waar en waarom.
- Het is de moeite waard De frequentie, doorlooptijd of foutgevoeligheid rechtvaardigt bouwen én onderhouden. Maatwerk dat één keer per kwartaal een half uur bespaart, verdient zich nooit terug.
Ontbreekt het derde signaal, dan is de eerlijkste conclusie meestal dat de basis nog niet goed genoeg is ingericht of dat medewerkers de mogelijkheden nog niet kennen. Dat is een goedkoper probleem om op te lossen.
Zes vormen, van licht naar zwaar
"Maatwerk" klinkt als één ding, maar in de praktijk is het een ladder. Iedere trede kost meer om te bouwen en meer om te onderhouden. Mijn regel: pak de lichtste vorm die het aangetoonde probleem oplost.
| Vorm | Wanneer passend | Wat het vraagt |
|---|---|---|
| Gedeelde skill of instructie | Het platform kan het al, maar iedereen doet het anders. Vaak nog binnen de pilot op te lossen. | Beschrijving, voorbeelden, een test. Geen code, geen onderhoudscontract. |
| Eigen app in ChatGPT of Claude | Een terugkerende taak met vaste instructies en een eigen set documenten, voor medewerkers die al in die omgeving werken. | Configuratie, bronselectie en tests. Blijft binnen het platform, dus geen nieuw programma om te leren. |
| MCP-koppeling | De AI moet bij een systeem waar het platform zelf geen connector voor heeft: een branchepakket, een intern portaal, een eigen database. | Een koppeling die je één keer bouwt en die door meerdere AI-applicaties gebruikt kan worden. Vraagt technisch beheer en rechtenafspraken. |
| Agent buiten de chat | Het werk start bij een gebeurtenis in plaats van bij een vraag van een medewerker: een binnenkomende mail, een nieuw document, een gewijzigde status. | Een trigger, een afgebakende taak en een expliciete controlegrens. Draait ook als niemand kijkt, dus logging en een noodrem zijn geen luxe. |
| Eigen kennisbank met zoeklaag | Veel eigen documenten, waarbij de standaardzoekfunctie de juiste passage structureel niet vindt of niet kan aanwijzen waar iets vandaan komt. | Doordachte opdeling van documenten, een zoekindex en bronvermelding per antwoord. Zie de volgende paragraaf. |
| Interne werksoftware | Het werk past niet in een chatvenster: overzichten, statussen, meerdere rollen, een akkoordflow, een audittrail. | Een echt softwareproject met ontwerp, bouw, testen, beheer en een levenscyclus. De zwaarste trede, en zelden de eerste. |
De onderste twee treden zijn technisch het interessantst en voor een leverancier het aantrekkelijkst om te verkopen. Precies daarom moet je ze het strengst toetsen. Ik begin liever met een eigen app die volgende week draait dan met software die over vier maanden af is en dan pas leert wat de organisatie eigenlijk nodig had.
Voorbeeld: van hiaat naar koppeling
Bij een installatiebedrijf als Atlas staat de servicehistorie in een branchepakket dat geen enkele AI-connector ondersteunt. Medewerkers beantwoorden klantvragen door eerst in dat pakket te zoeken, dan de bijbehorende werkbon te openen en pas daarna te antwoorden. De basis lost de eerste en de derde stap prima op. De tweede blijft handwerk, elke dag opnieuw.
Dat hiaat voldoet aan alle vier de signalen. De lichtste oplossing is hier een koppeling die precies dat ene systeem leesbaar maakt voor de AI, zonder er iets in te kunnen wijzigen. De medewerker blijft dezelfde vraag stellen in dezelfde omgeving; alleen komt het antwoord nu compleet terug, met vermelding van de werkbon waar het vandaan kwam.
Eigen kennisbank, vectorzoeken en RAG
Een taalmodel kent heel veel taal, maar jullie documenten kent het niet. Wil je dat het antwoord geeft op basis van eigen materiaal, dan moet dat materiaal eerst worden opgezocht en als context worden meegegeven. Die werkwijze heet retrieval-augmented generation, meestal afgekort tot RAG: eerst ophalen, dan pas formuleren.
Het ophalen gebeurt zelden op exacte woorden. Documenten worden in stukken geknipt en per stuk omgezet naar een reeks getallen die de betekenis van die tekst weergeeft, een embedding. Teksten met een vergelijkbare betekenis krijgen vergelijkbare getallen en komen daardoor dicht bij elkaar te liggen. Een vectordatabase bewaart die reeksen en kan er snel in zoeken. Zo vindt een vraag over "levertijd bij nabestelling" ook een alinea die het over "doorlooptijd van een vervolgorder" heeft, zonder dat er één woord overeenkomt.
Belangrijk: de meeste zakelijke platformen doen dit inmiddels zelf voor bronnen die ze ondersteunen. Als jullie documenten in een gekoppelde omgeving staan en de antwoorden kloppen met bronvermelding erbij, dan heb je geen eigen zoeklaag nodig en zou ik die ook niet bouwen. Een eigen kennisbank wordt pas verdedigbaar wanneer minstens één van deze dingen speelt:
- de bron wordt door geen enkele beschikbare connector ondersteund;
- de documenten hebben een structuur waar generieke opdeling op stukloopt, zoals lange technische specificaties, tabellen of contracten waarin één clausule het antwoord bepaalt;
- je hebt controle nodig over welke versie van een document leidend is, bijvoorbeeld omdat een verouderde procedure zichtbaar schade kan doen;
- er moet aantoonbaar en herleidbaar geciteerd worden, tot op de passage, omdat een toezichthouder of klant dat vraagt.
Eén verwachting hoort er meteen bij: RAG maakt antwoorden herleidbaar, maar nog niet automatisch juist. Een goede zoeklaag verkleint de kans op een verzonnen antwoord aanzienlijk, maar neemt die niet weg, en verouderde of tegenstrijdige brondocumenten blijven verouderd en tegenstrijdig. Wie zijn documentenchaos aansluit, krijgt vooral een snellere manier om die chaos te doorzoeken. Opruimen blijft mensenwerk, en dat is vaak de eerste echte opbrengst van zo’n traject.
Hoe een maatwerktraject loopt
Maatwerk krijgt bij mij altijd een eigen opdracht, los van de pilot. Bouwen vraagt andere afspraken dan begeleiden: zonder acceptatiecriteria kom je uit op een oplossing waar niemand blij van wordt.
- Het probleem vastleggen. Welke stappen zet iemand nu, hoe vaak, met welke bronnen, en waar gaat het mis? Zonder dat is er geen manier om achteraf te bepalen of het gelukt is.
- De lichtste vorm kiezen. We lopen de ladder van licht naar zwaar af en stoppen bij de eerste trede die het gat aantoonbaar dicht.
- Grenzen bepalen. Welke bronnen mag het raken, wat mag het alleen lezen, welke handeling gaat pas door na akkoord van een mens, en wat gebeurt er als het misgaat?
- Bouwen en toetsen op echt werk. We testen op de dossiers, mails en documenten waar de oplossing straks mee moet werken, inclusief de rommelige gevallen, en niet alleen op een nette demoset.
- Overdragen. Jullie krijgen de code, de configuratie en de documentatie. Wat ik bouw draait op accounts en abonnementen van jullie bedrijf, niet op die van mij.
Dat laatste punt is een bewuste keuze. Ik wil niet dat jullie technisch van mij afhankelijk worden: als jullie na een jaar met iemand anders verder willen, moet dat kunnen zonder dat er iets omvalt.
Wat maatwerk niet oplost
Een gebouwde oplossing erft de kwaliteit van wat eronder ligt. Een onduidelijk proces wordt niet helder doordat er een agent overheen loopt, en slechte brondata wordt door indexeren hooguit sneller vindbaar. Ook een team dat de standaardomgeving nauwelijks gebruikt, gaat een specialistische applicatie zelden vaker gebruiken.
En maatwerk veroudert. Wat je vandaag bouwt omdat het platform het niet kan, kan over twee kwartalen een standaardfunctie zijn. Dat hoeft bouwen niet tegen te houden, zolang je klein bouwt, opschrijft waarom iets is gemaakt en periodiek controleert of het nog bestaansrecht heeft. Ik vind het prima om iets wat ik gebouwd heb weer weg te halen als het platform het inmiddels beter doet.
De volgorde blijft daarom staan: eerst een basis die werkt, dan meten waar het schuurt, en pas daarna bouwen wat aantoonbaar ontbreekt.
Volgende stap
Twijfel je of jullie probleem maatwerk rechtvaardigt?
Leg het proces naast de vier signalen. Klopt het beeld, dan bakenen we in een gesprek af wat er precies gebouwd moet worden en wat het lichtste alternatief is. Klopt het niet, dan zeg ik dat ook. De AI-nulmeting is in voorbereiding en nog niet te bestellen.