AI-prototype naar productie: wat er nog mist voordat het live kan

Een AI-prototype naar productie brengen kost bijna altijd meer werk dan het bouwen van het prototype zelf. Dat voelt oneerlijk. Je hebt in een middag iets werkends neergezet, het demo’t goed, collega’s zijn enthousiast. En dan blijkt het laatste stuk richting iets waar echte gebruikers op mogen, het grootste stuk te zijn.

Wij zien die situatie sinds dit jaar steeds vaker. Bedrijven bouwen zelf iets met AI, komen tot de rand van bruikbaar, en lopen daar vast. Dit artikel gaat over wat er op dat moment precies ontbreekt, en hoe je bepaalt of je verder bouwt op wat er staat of opnieuw begint.

Waarom zoveel AI-prototypes blijven steken

De cijfers zijn niet vrolijk. Gartner voorspelde in juli 2024 dat minstens 30 procent van de generatieve AI-projecten na de proof of concept zou worden gestaakt, met slechte datakwaliteit, oplopende kosten en onduidelijke bedrijfswaarde als belangrijkste redenen. Onderzoek van het MIT NANDA-initiatief kwam vorig jaar tot een nog scherper beeld: van de bekeken bedrijfspilots leverde het overgrote deel geen meetbaar resultaat op.

Wat in beide onderzoeken opvalt: het model is zelden het probleem. Het gaat mis op integratie, op data en op de vraag wie het straks beheert. Precies de onderwerpen waar een prototype per definitie geen antwoord op geeft, want een prototype is gebouwd om een idee te laten zien, niet om te draaien.

Onze eigen conclusie is iets nuchterder dan de doemcijfers. Een prototype dat blijft steken is geen mislukking, het is een prototype dat zijn werk heeft gedaan. Het heeft laten zien dat het idee klopt. De fout zit erin dat mensen denken dat ze er al bijna zijn.

Wat er standaard ontbreekt in een zelfgebouwd AI-prototype

Bijna elk prototype dat wij onder ogen krijgen mist dezelfde dingen. Niet omdat de bouwer iets fout deed, maar omdat je ze in een demo niet nodig hebt.

Inloggen en rechten. In het prototype is iedereen dezelfde gebruiker. In productie moet je weten wie wat mag zien. Bij AI is dat scherper dan bij gewone software, want het model kan in één antwoord data uit verschillende hoeken van je organisatie combineren.

Foutafhandeling. Modellen geven soms iets terug wat niet klopt, in een verkeerd formaat, of helemaal niets. Een prototype crasht dan of toont onzin. Productiesoftware moet daar een net antwoord op hebben, en moet weten wanneer het beter is om te zeggen dat het antwoord er niet is.

Logging. Als een gebruiker over een week belt dat het systeem iets vreemds zei, moet je terug kunnen kijken. Zonder vastlegging van wat er in en uit ging, is elk probleem onoplosbaar.

Kostenbeheersing. Dit is de post die het vaakst vergeten wordt en het hardst aankomt. Zie de volgende sectie.

Beheer zonder programmeur. Iemand moet prompts kunnen aanpassen, documenten kunnen toevoegen en gebruikers kunnen blokkeren, zonder dat er een developer aan te pas komt. Anders ben je voor elke wijziging afhankelijk van degene die het bouwde.

Een antwoord op de datavraag. Wat gaat er naar het model, waar staat het, en mag dat volgens je eigen afspraken en de AVG. Bij persoonsgegevens of klantdossiers is dit geen formaliteit maar de eerste vraag die je klant gaat stellen.

Tests. Bij gewone software test je of een knop werkt. Bij AI test je of de antwoorden nog goed genoeg zijn nadat je iets aan de prompt of het model hebt veranderd. Dat vraagt een set voorbeeldvragen met verwachte uitkomsten, en die maakt bijna niemand vooraf.

Infrastructuur en schaalbaarheid. Een prototype draait op een laptop of op de gratis tier van een clouddienst, en voor een demo is dat prima. Productie vraagt een antwoord op drie vragen: waar draait het straks, wat kost het als er meer gebruikers bijkomen, en wat gebeurt er bij een piek. Wie daar pas over nadenkt als het druk wordt, denkt er te laat over na.

De kosten die pas zichtbaar worden bij echte gebruikers

In een demo doe je twintig vragen per dag en betaal je een paar euro. Met tweehonderd medewerkers erop verandert dat beeld volledig, en meestal in de verkeerde richting.

Drie dingen bepalen wat het per maand gaat kosten: hoeveel vragen er gesteld worden, hoeveel tekst er per vraag naar het model gaat, en welk model je kiest. Dat laatste is de knop waar de meeste winst zit. Een prototype gebruikt vrijwel altijd het duurste en zwaarste model, omdat je dan het snelst iets goeds ziet. In productie blijkt een lichter model vaak prima te voldoen voor het grootste deel van de vragen.

Wat wij standaard inbouwen: een limiet per gebruiker, een cache voor vragen die vaker terugkomen, en een meting per functie zodat je ziet welk onderdeel het geld opmaakt. Zonder die drie ontdek je pas aan het eind van de maand dat er iets misging.

Wanneer je het prototype beter kunt weggooien

Wij zeggen dit liever meteen: in de meeste gevallen hoeft een AI-prototype niet opnieuw. De prompt-logica, de opzet van de gesprekken en het scherm zelf zijn vaak prima werk, en dat is precies het deel waar de meeste denktijd in zat.

Er zijn drie situaties waarin we wel adviseren om opnieuw te beginnen. Als er persoonsgegevens of bedrijfsdata rechtstreeks naar een dienst zijn gestuurd zonder dat iemand naar de voorwaarden heeft gekeken, dan is opruimen duurder dan opnieuw opzetten. Als het prototype volledig in een gesloten no-code-omgeving zit waar je de code niet uit krijgt, dan bouw je hoe dan ook opnieuw, alleen ben je dan wel je functionele ontwerp kwijt. En als niemand meer weet waarom bepaalde keuzes gemaakt zijn, wat sneller gebeurt dan je denkt bij door AI gegenereerde code, dan kost begrijpen meer dan bouwen.

Dat laatste punt is nieuw en onderschat. Code die door een AI-assistent is geschreven ziet er netjes uit en doet vaak precies wat er gevraagd is. Maar er zit geen redenering achter die iemand kan navertellen. Bij een probleem heb je dan geen enkel aanknopingspunt.

Wat wij zien bij door AI geschreven specs en prototypes volgt steeds hetzelfde patroon. De demo is overtuigend en de happy flow werkt echt. Wat ontbreekt is alles rond de randen: foutpaden, rechten, beheer. De aannames die in de prompt zaten staan nergens op papier, waardoor niemand later nog kan uitleggen waarom iets zo gebouwd is. En de code is moeilijker uit te breiden dan hij oogt, want onder de nette buitenkant zit zelden een structuur die op verandering is gebouwd.

Hoe wij een AI-prototype naar productie brengen

Een AI-prototype naar productie brengen doen wij in vier stappen, en de eerste twee kosten weinig.

1. Scan van wat er staat. We draaien het prototype, lezen de code en de prompts, en kijken waar de data heen gaat. Daaruit komt een lijst met wat er mist en wat dat ongeveer kost.
2. Eerlijk oordeel. Verder bouwen op wat er staat, gedeeltelijk hergebruiken, of opnieuw. Wij zeggen ook als het derde het goedkoopst is.
3. Productieklaar maken. Rechten, foutafhandeling, logging, kostenrem, beheer en tests. Dit is het echte werk en hier zit het meeste budget.
4. Aansluiten op wat je al hebt. Een AI-functie die los staat van je bestaande systemen wordt zelden gebruikt. Hoe wij dat aanpakken staat in ons artikel over AI integratie in bestaande software.

Wij bouwen AI het liefst in systemen die al draaien. Bij een klant in de technische handel analyseerden we 59.000 orders en 57.000 gesprekslogs en kwamen daaruit met 16 concrete toepassingen. Daarvan draait er nu een zoekfunctie in natuurlijke taal in het platform dat het hele bedrijf dagelijks gebruikt. Niet als losse chatbot ernaast, maar in het scherm waar mensen toch al werkten.

Zit je met een prototype dat stilstaat, of met software die niemand meer onderhoudt, dan kunnen wij dat overnemen en afmaken. Wat het kost om iets nieuws te bouwen lees je op onze pagina over app ontwikkelen kosten.

Veelgestelde vragen

Hoe lang duurt het om een AI-prototype naar productie te brengen?

Dat hangt af van wat er al staat en wat er ontbreekt. Een prototype met een nette opzet waar alleen rechten, logging en foutafhandeling omheen moeten, is een kwestie van weken. Zit de logica verspreid door de code of moet de datastroom eerst uitgezocht worden, dan loopt het op. De scan aan het begin geeft daar antwoord op, en die scan is bewust kort gehouden.

Kunnen we ons prototype hergebruiken of moeten we opnieuw beginnen?

In de meeste gevallen kan het hergebruikt worden. Het denkwerk in de prompts en het schermontwerp is meestal bruikbaar, ook als de code eromheen vervangen wordt. Opnieuw beginnen adviseren we alleen als de data-afhandeling niet te repareren is, als de code vastzit in een gesloten omgeving, of als niemand meer kan uitleggen waarom het werkt zoals het werkt.

Wat kost het om een AI-prototype productieklaar te maken?

Er is geen vast bedrag, want het verschil tussen twee prototypes is enorm. De prijs wordt bepaald door hoeveel er ontbreekt aan rechten, foutafhandeling en beheer, hoeveel koppelingen er met bestaande systemen nodig zijn, en hoe streng de eisen rond data zijn. Wij beginnen daarom altijd met een scan met een vaste prijs, zodat je een onderbouwd bedrag krijgt in plaats van een gok.

Is een AI-prototype hetzelfde als een proof of concept?

Nee, al lopen de termen door elkaar. Een proof of concept beantwoordt de vraag of iets technisch kan. Een prototype laat zien hoe het zou werken voor een gebruiker. Een MVP is de eerste versie die je echt in gebruik neemt. Veel bedrijven denken dat ze een MVP hebben terwijl ze een prototype hebben, en dat verschil is precies waar dit artikel over gaat.

Wij hebben het prototype zelf gebouwd zonder programmeurs. Kunnen jullie daar iets mee?

Ja, en dat is inmiddels een flink deel van dit soort vragen. Zelfgebouwde prototypes zijn vaak functioneel beter doordacht dan wat een extern bureau in dezelfde tijd zou maken, omdat de bouwer het probleem van binnenuit kent. Wat ontbreekt is het technische deel eromheen. Dat is goed toe te voegen zonder jouw werk weg te gooien.

Zullen we ernaar kijken?

Heb je iets staan dat werkt in een demo maar niet in de praktijk, stuur ons dan een paar regels over wat het doet en waar het vastloopt. Je krijgt een eerlijk oordeel over wat er nodig is, ook als dat oordeel is dat je er beter mee kunt stoppen.

Mail naar hallo@appec.nl, bel 024 202 243 5, of plan een gesprek. De koffie is op ons.

Publicatie-metadata (niet meepubliceren)