Je hebt een idee. Misschien wil je dat een AI automatisch de inkoopfacturen leest die binnenkomen, of dat je medewerkers in gewone taal vragen kunnen stellen over de data in je voorraadsysteem, of je wilt het makkelijker maken om jouw voorraad te posten op social media. Het klinkt goed, maar je weet niet of het echt werkt met jouw documenten en jouw systemen. En je wilt er geen half jaar en een fors budget in steken om er dan pas achter te komen. Daar is een proof of concept voor: een kleine, afgebakende test om binnen zo'n twee tot drie weken te zien of het idee hout snijdt.
Wat is een proof of concept eigenlijk?
Een proof of concept (vaak afgekort tot POC) is een werkende. miniatuur. Geen volledige applicatie met inlogscherm en knoppen, maar het kale bewijs dat de kern van je idee technisch haalbaar is. Bij AI gaat het meestal om één vraag: kan een AI-model dit specifieke probleem voldoende goed oplossen met de data die jij hebt?
Het verschil met een echt project is de scope. Een POC pakt niet je hele proces aan, maar één duidelijk afgebakend stukje. Niet "automatiseer onze hele administratie", maar "lees uit deze 50 inkoopfacturen het factuurnummer, de datum en het totaalbedrag, en zet dat in een tabel". Klein genoeg om snel te bouwen, concreet genoeg om er een eerlijk oordeel over te vellen.
Waarom we klein en afgebakend beginnen
AI is grillig. Een taalmodel (de techniek achter tools als ChatGPT en Claude) is verbluffend goed in sommige taken en (nog) verrassend slecht in andere, en je weet vooraf niet altijd welke van de twee jouw geval is. Een tekst samenvatten gaat bijna altijd goed. Een bedrag exact overnemen uit een rommelig gescande factuur is een ander verhaal. Pas als je het op jouw eigen data loslaat, zie je waar het wringt.
Daarom investeren we liever eerst twee weken dan meteen drie maanden. Een POC kost weinig vergeleken met een volledig traject, en het beantwoordt de belangrijkste vraag het eerst: gaat dit überhaupt werken? Blijkt het idee niet haalbaar, dan heb je dat snel en goedkoop geleerd. Blijkt het wel te werken, dan bouw je verder op een fundament dat je al met eigen ogen hebt zien draaien, in plaats van op een mooie belofte.
Klein beginnen heeft nog een voordeel: je houdt het overzichtelijk. Één databron, één type document, één duidelijke vraag. Zodra je er tien dingen tegelijk in stopt, weet je bij een teleurstellend resultaat niet meer waar het misging. Door af te bakenen kun je gericht testen en bijsturen.
Hoe zo'n traject van twee weken eruitziet
We werken een POC graag in een vast ritme af. De exacte invulling verschilt per idee, maar de stappen zijn steeds vergelijkbaar.
Week 1: Scherpstellen en bouwen
- Dag 1 tot 2: De vraag aanscherpen. We gaan samen zitten en maken het idee zo concreet mogelijk. Wat moet de AI precies doen, met welke input, en wanneer noemen we het geslaagd? Die laatste vraag is cruciaal. Zonder afgesproken succescriterium blijft het gevoelsmatig of het "goed genoeg" werkt.
- Dag 2 tot 3: Data verzamelen. Jij levert een representatief stukje van je echte data aan: een setje documenten, een export uit je systeem, of toegang tot een testomgeving. Echte data, geen verzonnen voorbeelden, want juist de rommelige randgevallen bepalen of iets werkt.
- Dag 3 tot 5: Bouwen en koppelen. We zetten het model aan het werk op jouw data. Soms is dat een directe koppeling met een bestaand systeem, soms verwerken we de aangeleverde set. We schaven aan de instructies (de prompts) en kijken stap voor stap of de output klopt.
Week 2: Testen, bijsturen en oordelen
- Dag 6 tot 8: Testen op de lastige gevallen. Niet alleen de mooie voorbeelden, maar juist de uitzonderingen: de factuur met twee pagina's, de scan die scheef staat, de vraag die net iets anders geformuleerd is. Hier blijkt hoe robuust het is.
- Dag 8 tot 9: Meten tegen het succescriterium. We leggen de resultaten naast de afspraak van dag 1. Hoe vaak klopt het, waar gaat het mis, en valt dat met bijsturen op te lossen of zit er een hardere grens aan?
- Dag 10: Oplevering en go/no-go. Je krijgt een werkend voorbeeld te zien plus een eerlijk advies: dit werkt en is het waard om door te ontwikkelen, of dit werkt nog niet betrouwbaar genoeg en dit zou er nodig zijn om dat wel te bereiken.
Een concreet voorbeeld
Stel, je krijgt elke week tientallen inkoopfacturen binnen als pdf, en iemand typt die handmatig over in de boekhouding. Het idee: laat een AI de facturen lezen en er de belangrijke velden uit halen, zodat dat overtypen vervalt.
In de POC pakken we niet meteen de koppeling met je boekhoudpakket aan. We nemen een set van jouw echte facturen, van verschillende leveranciers, en laten het model daaruit het factuurnummer, de factuurdatum, het btw-bedrag en het totaal halen. Daarna leggen we de uitkomst naast wat een mens eruit zou halen. Klopt 90 van de 100 facturen meteen, en zien we duidelijk welke 10 afwijken en waarom? Dan weet je dat het idee werkt en kun je een afgewogen beslissing nemen over de volgende stap.
Een ander veelvoorkomend voorbeeld: een AI die vragen beantwoordt over data uit een bestaand systeem. "Welke klanten hebben dit kwartaal niets besteld?" rechtstreeks beantwoord uit je verkoopdata, zonder dat iemand een rapport hoeft te draaien. Ook dat valt prima in een POC te testen op een afgebakend stukje van je gegevens. Hoe je AI veilig aan zulke systemen koppelt, hebben we uitgebreid beschreven in dit artikel over AI koppelen aan je bedrijfssystemen.
Wat jij zelf aanlevert
Een POC is samenwerken. Om binnen twee weken iets zinnigs op te leveren, hebben we van jou drie dingen nodig:
- Een duidelijke vraag: Hoe scherper het probleem, hoe beter de uitkomst. "Het moet slimmer" is geen vraag. "Kan de AI uit deze documenten betrouwbaar de leverdatum halen?" wel.
- Echte data: Een representatieve set documenten, een export, of toegang tot een (test)omgeving van je systeem. Liefst inclusief de uitzonderlijke gevallen, want die zijn het meest leerzaam.
- Iemand die meekijkt: Een collega die het probleem goed kent en kan beoordelen of de output klopt. AI-output ziet er namelijk altijd overtuigend uit, ook als het fout is. Iemand met domeinkennis is onmisbaar om dat te toetsen.
Hoe beter je deze drie aanlevert, hoe meer waarde je uit die twee weken haalt.
Wat een proof of concept níet is
Hier zijn we eerlijk over, want het voorkomt teleurstelling. Een POC is geen productieklare oplossing. Het is bewust kaal: er zit waarschijnlijk nog geen mooi scherm omheen, geen gebruikersbeheer, geen foutafhandeling voor elk denkbaar scenario, en geen garantie dat het bij honderdduizend documenten net zo goed draait als bij vijftig.
Een POC bewijst dat de kern werkt. Het is het startpunt, niet het eindpunt. Werkt het, dan volgt de stap naar een echte, betrouwbare toepassing met de juiste koppelingen, beveiliging en onderhoud. Die weg van een geslaagd experiment naar een werkend systeem in je dagelijkse processen is een traject op zich, waar je de tijd voor wilt nemen.
Wat een POC dus vooral oplevert, is een onderbouwde beslissing. Geen onderbuikgevoel en geen verkooppraatje, maar een werkend voorbeeld dat je zelf hebt zien draaien, plus een heldere go of no-go. Twijfel je of jouw idee überhaupt geschikt is voor AI, neem gerust contact met ons op om jouw idee te bespreken. Wil je weten hoe we breder met AI en automatisering werken? Kijk dan op onze pagina over AI en automatisering.
Klein beginnen, slim doorpakken
Je hoeft niet direct groot in te zetten om met AI aan de slag te gaan. Sterker nog, dat raden we juist af. Begin met één afgebakend idee, test het in twee weken op je eigen data, en beslis daarna pas of het de moeite waard is om door te bouwen. Zo houd je de risico's klein en de leereffecten groot.
Heb je een idee waarvan je je afvraagt of AI het kan oplossen? Leg het ons voor. We denken vrijblijvend met je mee over of een proof of concept zin heeft en hoe we het zouden aanpakken.
