Je vastgelopen AI-POC alsnog werkend in één dag

Veel AI-POCs stranden. Niet altijd omdat het idee fout was, maar omdat de eval ontbrak, de scope te breed werd, of de stack niet meeschaalde naar productie. In één dag kijken we waar het breekt en bouwen we de versie die wel werkt.

Terug naar OneDayBuild
01 / 04

Waar AI-POCs meestal stranden

Drie patronen die we keer op keer terugzien. Niet als verwijt, wel als check.

Geen eval-loop

De POC werkte 'wel ergens'. Maar nooit was gemeten op hoeveel testcases het correct werkte, waar het brak, of hoe vaak. Zonder eval is verbetering gokken.

Scope-creep tijdens de bouw

Begonnen met 'beantwoord factuur-vragen', geëindigd met 'doe alles wat onze klantenservice doet'. De model-kwaliteit wordt slecht naarmate de scope onhanteerbaar wordt.

Stack niet meegeschaald

Een POC met een notebook en hard-coded keys werkt in demo. In productie strandt het op latency, kosten, security of integratie met legacy-systemen die nooit getest waren.

02 / 04

Wat we in één dag wel en niet doen

We diagnostiseren en bouwen. We maken geen marketing-rapport van waarom het mislukte.

Binnen scope
  • Diagnose: waar breekt de huidige POC, waar zit de echte bottleneck.
  • Eval-set opzetten met 10 tot 20 testcases om kwaliteit meetbaar te maken.
  • Versie 2: een herbouw of bijsturing waar de bottleneck zit.
  • Honest verdict aan het eind: werkt nu wel, of werkt nooit met deze aanpak.
Buiten scope
  • Volledige productie-build met monitoring en SSO (apart traject).
  • Volledige migratie naar een andere modelfamilie of stack.
  • Politiek-rapport voor je organisatie over waarom de oorspronkelijke POC mislukte.
  • Doorlopende verbetering na de dag (apart te plannen).
03 / 04

Hoe een rescue-dag eruit ziet

Eerst begrijpen wat er nu niet werkt, dan bouwen wat wel werkt.

  1. 09:00

    Wat was beloofd, wat werkt nu?

    We doorlopen de huidige POC, zien wat hij wel en niet doet, en lijsten de gaten op.

  2. 10:00

    Diagnose

    Eval-set maken, testcases draaien, kijken waar het breekt: model, prompt, tool, data of stack.

  3. 12:00

    Aanpak kiezen

    Versie 2-richting bepalen. Soms is het een prompt-fix, soms een ander model, soms herbouwen op een andere stack.

  4. 13:00

    Bouwen

    Implementeren van de geïdentificeerde fix. Direct testen tegen de eval-set.

  5. 15:30

    Verifiëren met eval

    Draai de eval-set opnieuw. Vergelijk met de oorspronkelijke POC. Documenteer het verschil.

  6. 17:00

    Verdict en handover

    Eerlijke conclusie: het werkt nu, of we hebben geleerd dat deze aanpak niet werkt. In beide gevallen heb je een rapport en eval om mee verder te gaan.

04 / 04

Wat je krijgt aan het eind van de dag

Vier deliverables die je intern overdraagbaar maken.

  • Werkende versie 2 (als de diagnose dat toelaat) met traces die laten zien hoe het loopt.
  • Eval-rapport: hoeveel testcases lopen nu wel, hoeveel niet, met welke confidentie.
  • Root-cause-document: waar zat het probleem in versie 1, wat is er nu anders.
  • Vervolg-aanbeveling: doorbouwen naar productie (en wat dat kost), kleinere scope kiezen, of stoppen.
05 / 05

Veelgestelde vragen

Werkt dit ook als de POC door een ander bureau is gebouwd?

Ja. We hebben geen voorkeur voor onze eigen code. Vraag wel om de bestaande codebase en eventuele documentatie vooraf, zodat we niet de eerste twee uur van de dag aan het reverse-engineeren zijn.

Wat als de POC echt niet te redden valt?

Dan zeggen we dat eerlijk en leg je in het rapport uit waarom. Soms ligt het aan de use case (AI is niet de juiste oplossing voor het probleem), soms aan data-kwaliteit, soms aan ambitie. Beter na één dag weten dan na nog drie maanden investering.

Werkt het ook met agentic AI of alleen klassieke LLM-prompts?

Beide. We kennen de standaard valkuilen van agent-flows (planning loopt vast, tools werken niet zoals verwacht, mens-in-de-lus ontbreekt) en van klassieke RAG/prompt-setups. De diagnose-fase laat zien waar de bottleneck zit.

Mag onze data het pand verlaten?

Bij voorkeur werken we met geanonimiseerde of synthetische data op de dag. Bij gevoelige data kiezen we self-hosted modellen of een lokale eval-loop. Bespreken we in de intake.

Wat na de rescue-dag?

Als versie 2 werkt en je naar productie wil: we rollen door naar een Appfront-traject voor de productie-build met monitoring, security en SSO. Als het project beter gestopt kan worden, helpt het rapport om dat intern uit te leggen.

Vastgelopen AI-POC en deadline in zicht?

Stuur ons een korte beschrijving van wat de POC moest doen en wat hij niet doet. We bekijken in de intake of de rescue-dag past.