Wanneer een custom AI tool zin heeft
Niet elke workflow vraagt om AI. Een n8n-flow of een eenvoudig script lost de meeste herhalende taken op zonder het extra gewicht van een taalmodel. Maar er zijn situaties waarbij dat niet werkt. Drie signalen dat een custom AI tool de juiste aanpak is:
- ▸De taak vereist context: de juiste output hangt af van informatie die verspreid staat over het document of de dataset, niet van een vaste regel die je in een if-statement kunt stoppen.
- ▸De invoer varieert te sterk voor een regex of template: vrije tekst, PDF-formulieren, e-mails in wisselende opmaak, afbeeldingen van bonnen. Structurering per hand is ondoenlijk op schaal.
- ▸De beslissingen zijn te fijnmazig voor handmatige regels: support-tickets routeren naar de juiste afdeling op basis van inhoud, toon en urgentie tegelijk, zonder dat een beslismatrix haalbaar is.
- ▸De hoeveelheid is groot maar het werk is te repetitief voor een specialist: 200 offertes per week doorlezen op ontbrekende clausules is werk voor een AI, niet voor een jurist.
Als aan een van deze criteria wordt voldaan, is de stap naar een custom tool de moeite waard om te onderzoeken. Niet om AI erbij te betrekken, maar omdat het de enige aanpak is die het probleem feitelijk oplost.
Wanneer een custom AI tool geen zin heeft
AI is geen antwoord op elk probleem. Ik bouw geen tools als:
- ▸Het probleem op te lossen is met een gewone query, een spreadsheet-formule of een API-koppeling zonder redeneerlaag.
- ▸De business case ontbreekt: 'we willen AI gebruiken' zonder dat er een concreet, meetbaar probleem achter zit.
- ▸Het gaat om marketingcontent genereren zonder specifieke domeinkennis of interne data als input. Dat kan iedereen zelf met ChatGPT.
- ▸De datakwaliteit onvoldoende is om een model op te draaien: garbage in, garbage out geldt ook voor de meest geavanceerde modellen.
Mijn discovery aanpak: audit voor code
Voordat ik een regel code schrijf, breng ik de handmatige taak in kaart. Dat kost niet veel tijd, maar voorkomt dat ik de verkeerde tool bouw. De stappen:
- ▸Intake: beschrijf het proces stap voor stap. Wat is de invoer, wat is de gewenste uitvoer, welke beslissingen worden daartussen genomen?
- ▸Foutanalyse: waar gaat het handmatig mis? Waar verlopen er fouten, worden stappen overgeslagen, of duurt het langer dan het zou moeten?
- ▸POC in 1 tot 3 iteraties: ik bouw een werkend prototype op echte data van jouw organisatie. Geen demo-data, geen ideale gevallen.
- ▸Validatie: jij of een medewerker beoordeelt de output van het prototype. Pas daarna beslis ik of het model geschikt is, of bijgesteld moet worden.
- ▸Iteratie: na validatie pas ik de prompts, de pipeline of de architectuur aan op basis van wat niet klopte. Geen grote release na maanden, maar kleine stappen die aantoonbaar werken.
Dit traject is bewust kort en concreet. Als het prototype al in de eerste iteratie nutteloos blijkt, stop ik daarmee. Dat is eerlijker dan maanden doorontwikkelen op een verkeerd fundament.
Welke modellen ik gebruik en waarom
Modelkeuze hangt af van het probleem, niet van wat er op dit moment het meest besproken wordt. Mijn standaard overweging:
- ▸Claude's nieuwste modellen (Anthropic): voor taken waarbij redeneren over langere context belangrijk is, zoals het doorkruisen van een document op inconsistenties of het genereren van gestructureerde output met meerdere afhankelijke velden.
- ▸OpenAI's snelle model: voor toepassingen waarbij kosten per token zwaarder wegen en de taak minder complexe redeneerketens vereist. Veelgebruikt voor classificatietaken op hoog volume.
- ▸Lokale Llama-varianten (Ollama of vLLM): voor situaties waarbij data het systeem niet mag verlaten. On-premise, geen API-calls naar externe servers, volledig binnen jouw netwerk of server.
- ▸Embeddings + vector store: voor RAG-toepassingen waarbij het model context haalt uit een eigen documentenbase in plaats van uit zijn trainingsdata.
Ik sluit me niet aan bij een enkele provider. Het model dat het probleem het best oplost tegen de laagste lopende kosten, wint.
Architectuur die ik typisch gebruik
Afhankelijk van de tool kan de stack variëren, maar de meeste custom AI tools die ik bouw draaien op een vergelijkbare basis:
- ▸Frontend: Next.js voor webinterfaces, of geen UI als de tool headless draait via API of cron.
- ▸Backend: FastAPI (Python) voor pipelines met veel AI-aanroepen, Node.js voor integraties met bestaande systemen.
- ▸State en opslag: PostgreSQL voor gestructureerde data en beslissingsgeschiedenis, S3-compatible opslag voor bestanden.
- ▸Vector store: pgvector in Postgres voor eenvoudige RAG-setups, of Qdrant voor grotere collecties met meer zoekopties.
- ▸Orchestratie: LangChain of directe API-aanroepen, afhankelijk van of de complexiteit een framework rechtvaardigt.
- ▸Logging: elke AI-beslissing wordt gelogd met input, output en reden. Dat is geen optie, dat is standaard.
-- Anonieme casus A
Context-aware file editing bij een MKB-bedrijf in de logistieke sector
Een MKB-bedrijf in de logistieke sector verwerkte dagelijks batches bestanden waarbij telkens dezelfde typen aanpassingen nodig waren: twee of drie specifieke velden lezen, een contextafhankelijke waarde berekenen of aanpassen, het bestand opslaan in een ander formaat, en uploaden naar een extern systeem. De complicatie zat in het woord 'contextafhankelijk': de juiste waarde hing af van informatie elders in het bestand, niet van een vaste regel.
Een gewoon script kon dat niet aan. Ik bouwde een AI-bot die elk bestand leest, de relevante context extraheert, op basis daarvan beslissingen neemt over de wijzigingen, de aanpassingen doorvoert, het bestand converteert naar het doelformaat en uploadt. De bot logt elke beslissing met reden, zodat een medewerker achteraf kan controleren wat er is gedaan en waar de bot twijfelde.
De bot draait volledig on-premise. Bij afwijkende input stuurt hij een notificatie in plaats van stilletjes fout te gaan. De medewerker die dit eerder handmatig deed, gebruikt die tijd nu voor werk dat menselijk oordeel vereist.
-- Anonieme casus B
Lokale RAG over interne wiki bij een kennisorganisatie
Een interne kennisorganisatie had een uitgebreide wiki met procedures, beleidsdocumenten en technische handleidingen. Het probleem: medewerkers stelden dezelfde vragen aan collega's die de informatie al in de wiki hadden staan, omdat zoeken daarin te traag en te onnauwkeurig was. De informatie was beschikbaar, maar niet vindbaar.
Ik bouwde een lokale RAG-pipeline op een eigen server binnen het netwerk van de organisatie. Alle wiki-documenten worden geindexeerd als embeddings in een vector store. Via een simpele chatinterface stelt een medewerker een vraag en krijgt een antwoord met directe verwijzingen naar de relevante pagina's. Geen data verlaat het netwerk: het model draait lokaal op een Llama-variant via Ollama.
Het systeem is geen vervanging voor de wiki, maar een laag erbovenop. De wiki blijft de bron van waarheid. De RAG-tool maakt die bron bereikbaar zonder dat iemand weet waar precies iets staat.
Wat ik niet doe
Er zijn dingen die ik bewust buiten scope houd:
- ▸Out-of-the-box ChatGPT API-integraties waarbij het enige doel is dat er 'AI' op de website staat. Dat lost geen enkel probleem op.
- ▸AI-features als demo of pilot zonder plan voor productie-inzet. Een prototype dat in de la verdwijnt is weggegooid geld.
- ▸Training van eigen modellen op kleine datasets. Fine-tuning heeft pas zin bij duizenden voorbeelden en een specifieke reden waarom een foundational model tekortschiet.
- ▸Systemen waarbij de output niet gecontroleerd kan worden. Elke AI-beslissing in productie heeft een audit trail nodig. Zonder dat ga ik niet live.
Kosten en scope
Custom AI tools variëren sterk in omvang. Een POC om te valideren of de aanpak werkt, is iets anders dan een productiesysteem met monitoring en logging. Ik geef na de intake een offerte op basis van de werkelijke scope.
Op aanvraag
Geen vaste pakketten. De prijs hangt af van de complexiteit van de taak, het aantal iteraties dat nodig is voor validatie, en of je een retainer wilt voor beheer en monitoring na oplevering.