AI-productontwikkeling: van modeldemo naar betrouwbare software

Een AI-functie kan tijdens een gecontroleerde demo overtuigen en toch falen in normaal klantgebruik. Mensen geven onvolledige input, onderbreken gesprekken, uploaden onverwachte bestanden en vragen om acties buiten hun toegangsrechten. Modellen produceren soms geloofwaardige maar onjuiste informatie, veranderen tussen versies of zijn tijdelijk niet beschikbaar.

AI-productengineering zorgt ervoor dat zulke onzekere componenten bruikbaar worden binnen betrouwbare software. Het doel is een product dat een echte taak veilig, meetbaar en betaalbaar afrondt, niet alleen een modelantwoord dat overtuigend klinkt.

Deze gids is bedoeld voor CTO's, productverantwoordelijken en engineeringteams die SaaS met AI-functies, gespreksinterfaces en domeinspecifieke processen ontwikkelen.

Begin bij de gebruikerstaak en de gevolgen van fouten

Definieer voordat je een model kiest wat de gebruiker wil bereiken en hoe succes eruitziet.

Een interne kennisassistent moet mogelijk informatie terugvinden met duidelijke bronverwijzingen. Een documentverwerker moet gevalideerde velden produceren. Een spraakassistent moet misschien een begrensde boekings- of supporttaak afronden en met onderbrekingen omgaan.

Toepassingen verdragen verschillende soorten fouten. Een voorstel dat iemand nog beoordeelt, is niet hetzelfde als een autonome handeling die klantrecords wijzigt, berichten verzendt of een aannamebesluit beïnvloedt.

Documenteer verwachte input, toegestane output, neveneffecten, aanvaardbare onzekerheid en escalatie. Is de kerntaak nog niet bij gebruikers gevalideerd, dan kan een gericht MVP-experiment zinvoller zijn dan een groot AI-platform.

Scheid modeloutput van applicatiebevoegdheden

Een taalmodel mag niet zelfstandig beslissen welke data een gebruiker mag zien of welke applicatiestatus verandert.

De applicatie beheert identiteit, toegangsrechten, bedrijfsregels, tooltoegang, opslag en transacties. Een model kan een gestructureerde actie voorstellen, maar servercode moet die controleren tegen de aangemelde gebruiker en de actuele systeemtoestand.

Een AI-assistent kan bijvoorbeeld voorstellen om een sollicitatiegesprek in te plannen. De applicatie controleert dan wie eigenaar is van de vacature, of de kandidaat contact heeft toegestaan, of de uitnodiging mag worden verstuurd en of de actie niet al is uitgevoerd.

Gebruik expliciete toolschema's, validatie van argumenten en toegestane actielijsten. Smalle acties zoals 'toegestaan concept aanmaken' zijn veiliger dan onbeperkte database- of HTTP-toegang.

Een goede systeemprompt geeft richting, maar vervangt nooit server-side autorisatie.

Behandel opgehaalde informatie als onbetrouwbaar

Prompt injection is een productbeveiligingsprobleem, niet alleen een kwestie van betere prompting.

Een website, document, kandidaat-cv of toolantwoord kan instructies bevatten om regels te negeren, gegevens te onthullen of tools aan te roepen. Dat materiaal is taakdata, geen nieuwe autoriteit.

Houd de grens scherp tussen vertrouwde applicatie-instructies en minder betrouwbare bronnen. Beperk acties, controleer rechten vóór het ophalen en opnieuw vóór handelingen met effecten, en minimaliseer welke gevoelige data het model ontvangt.

Test kwaadaardige en onbedoeld instructieachtige teksten in representatieve documenten. Audit acties die records wijzigen, berichten sturen of gevoelige informatie ontsluiten.

Dezelfde regels gelden voor retrieval-augmented generation: relevante passages helpen antwoorden, maar een citaat bewijst niet automatisch dat de bron juist is of voor de gebruiker toegankelijk mag zijn.

Ontwerp gestructureerde output met validatie en herstel

Veel AI-workflows vragen voorspelbare objecten in plaats van vrije tekst: factuurvelden, supportcategorieën, interviewfeedback of voorgestelde vervolgstappen.

Definieer een schema, verplichte velden, toegestane waarden en hoe ontbrekende informatie wordt weergegeven. Valideer de modeloutput in applicatiecode. Wijs foutieve antwoorden af of probeer ze binnen gecontroleerde grenzen opnieuw.

Een geldig schema is niet genoeg. Goed gevormde JSON kan nog steeds een verzonnen factuurnummer, onbewezen kwalificatie of onjuiste datum bevatten. Vergelijk waarden met bronmateriaal en bedrijfsregels.

Laat bij financiële, juridische, arbeidsgerelateerde of andere ingrijpende effecten waar passend expliciete bevestiging of deskundige menselijke review plaatsvinden. Bewaar herkomst van belangrijke claims en maak onzekere modeltekst niet ongemerkt tot officiële data.

Bouw een evaluatieset voordat het gebruik groeit

Een paar geslaagde prompts bewijzen geen productiekwaliteit.

Maak representatieve taakvoorbeelden en bepaal wat het systeem moet doen bij gewone gevallen, ambiguïteit, ontbrekende gegevens, aanvallende input en uitval van afhankelijkheden. Neem ook negatieve gevallen op waarbij verduidelijken of weigeren het correcte gedrag is.

Meet verschillende dimensies: feitelijke correctheid, afgeronde taken, brongetrouwheid, schema-eisen, latency, kosten, veiligheid en begrijpelijkheid voor de gebruiker. Voor sommige taken is onafhankelijke beoordeling door domeinexperts noodzakelijk.

Versioneer prompts, modelkeuzes, evaluatiedata en relevante retrievalinstellingen. Vergelijk wijzigingen met een vaste nulmeting vóór je het verkeer vergroot. Onderzoek foutcategorieën in plaats van moeilijke gevallen achter één gemiddelde score te verbergen.

Een metriek 'accuracy' zegt weinig zonder omschreven taak, representatieve steekproef en transparante methode.

Plan voor modelonzekerheid en fallback

Modellen kunnen vragen verkeerd begrijpen, belangrijke details weglaten of overtuigend informatie verzinnen die niet door bewijs wordt ondersteund.

Toon onzekerheid waar die belangrijk is. Een interface kan bronnen, ontbrekende velden, beperkingen in betrouwbaarheid of een verzoek om menselijke verificatie tonen. Vermijd decoratieve betrouwbaarheidspercentages zonder gekalibreerde evaluatie.

Definieer herstelgedrag voor time-outs, providerstoringen, ongeldige output en onveilige of tegenstrijdige antwoorden. De dienst kan een bruikbare gedeeltelijke status geven, verwerking in een wachtrij zetten of aan een medewerker overdragen.

Onderscheid 'ontvangen', 'in behandeling', 'controle nodig', 'afgerond' en 'mislukt'. Toon geen succesmelding alleen omdat het model tekst heeft teruggegeven.

Graceful degradation is een ontwerpkeuze vooraf, geen noodoplossing na klantproblemen.

Realtime spraak voegt specifieke engineeringbeperkingen toe

Gespreksinterfaces combineren microfoonrechten, audiotransport, spraakherkenning, beurtwisseling, modelredenering, tekst-naar-spraak en afspelen.

Een demo kan uitgaan van stilte en stabiele verbinding. In productie krijg je achtergrondgeluid, onderbrekingen, gedempte microfoons, browserverschillen, opnieuw verbinden en incomplete transcripties.

Meet tijd tot de eerste bruikbare reactie, afhandeling van onderbrekingen, transcriptiefouten, door elkaar praten en herstel na verbindingsverlies. Een snelle modelrespons helpt weinig als audio-opname traag is of de stem robotachtig klinkt.

Als gesproken antwoorden voor een beoordeling worden gebruikt, moet je ruwe opname, transcript en interpretatie gescheiden houden. Technische storingen mogen niet stilzwijgend een negatief oordeel over een kandidaat worden.

Bied waar praktisch nodig toegankelijke alternatieve interacties.

Maak datalevenscyclus en privacy bewust

AI-diensten kunnen documenten, gesprekken, opnames en andere gevoelige gegevens ontvangen. Bepaal welke gegevens echt nodig zijn en beperk wat de gecontroleerde applicatieomgeving verlaat.

Breng de datastroom in kaart tussen frontend, backend, modelprovider, opslag, observability en eventuele spraak- of retrievaldiensten. Leg toestemming of andere wettelijke grondslag, bewaartermijnen, verwijdering, verwerkersafspraken, toegangsrechten en internationale doorgifte vast.

Scheid ontwikkeldata van productiedata. Log niet zonder noodzaak volledige prompts, opnames of persoonsgegevens. Audit verhoogde rechten, bescherm opslag en zorg dat gebruikers uitsluitend hun eigen toegestane gegevens zien.

Onderzoek bij iedere leverancierswissel opnieuw technische en contractuele aannames. Beschikbaarheid van een model-API geeft geen toestemming om klantdata elders voor te hergebruiken.

Kosten zijn een architectuurvoorwaarde

Een AI-product maakt kosten voor tokens, spraakminuten, retrievalverzoeken, toolaanroepen, opslag, bandbreedte, retries, monitoring en menselijke beoordeling.

Meet uitgaven per workflow: een afgeronde analyse, succesvol interview, verwerkt document of nuttig opgelost supportverzoek. Tel mislukte en afgebroken sessies mee; ook die verbruiken middelen zonder klantwaarde.

Beperk inputgrootte, outputlengte, gelijktijdigheid, verzoekduur en retries. Gebruik idempotentie voor acties die niet dubbel mogen plaatsvinden. Caching kan helpen wanneer hergebruik veilig is en duidelijk is hoelang een resultaat geldig blijft.

Een goedkoper model kan goed zijn in extractie en minder geschikt voor genuanceerde redeneringen. Onderzoek afwegingen met representatieve kwaliteits- en fouttests in plaats van alleen op prijs te kiezen.

Orkestreer ingewikkelde processen als expliciete toestanden

Een workflow met verschillende modellen of tools mag niet afhankelijk zijn van het geheugen van het taalmodel over eerdere statuswisselingen.

Leg duurzame voortgang in de applicatie vast: taken, toestemmingen, inputversies, voltooide stappen, retries en openstaande menselijke goedkeuringen.

Een interviewfeedbackproces kan bijvoorbeeld fasen hebben voor toegestane opname, transcriptie, koppeling van vragen en antwoorden, analyse, menselijke beoordeling en definitief delen. Iedere fase krijgt expliciete input, output en foutafhandeling.

Queues helpen bij langlopende taken, maar vereisen observability, time-outs, retrybudgetten en dead-letterafhandeling. Herhaalde berichten mogen niet leiden tot dubbele externe acties.

Statusmachines en auditlogs lijken minder spectaculair dan 'autonome agents', maar leveren de voorspelbaarheid die bedrijven nodig hebben.

Voorbeeld: een overtuigende AI-demo die in praktijk faalt

Stel dat een AI-interviewer tijdens een demo vloeiende vragen stelt. In een echt gesprek onderbreekt de kandidaat een vraag, de audioverbinding valt kort weg en het transcript plaatst een antwoord bij de verkeerde vraag.

Het model genereert vervolgens een coherent maar niet onderbouwd beoordelingsverslag. Als het product dat zonder herkomst of review opslaat, veranderen technische fouten in schijnbare feiten.

Een beter proces bewaart tijdstempels, registreert onderbrekingen en opnieuw verbinden, scheidt onzekerheid in transcriptie van technische conclusies en laat een deskundige reviewer de oorspronkelijke antwoorden bekijken. Het kan een incomplete sessie markeren voor opvolging in plaats van een definitieve score te forceren.

Dit is een fictief scenario, geen gemeld incident bij een specifieke klant.

Wat ScaleTwice leert over productgrenzen

Het werk van Onectus aan ScaleTwice biedt echte engineeringcontext voor functierelevante vraagplanning, gespreksinterfaces, transcriptie, gestructureerde feedback en kandidaatprocessen.

Deze onderwerpen kennen samenhangende eisen: consistente vragen, latency, browsergedrag, traceerbaarheid van bewijs, toegangsrechten, modelkosten en herstelbare sessies.

Die ervaring bewijst geen universele accuratesse, discriminatievrije AI of gegarandeerde voordelen voor ieder wervingsbedrijf. Productfuncties en productiegeschiktheid moeten per implementatie worden gecontroleerd.

De overdraagbare les is dat het model één onderdeel is van een verantwoordelijke applicatiearchitectuur, niet het volledige product.

Van prototype naar productie in stappen

Fase één — definiëren: bepaal taak, gebruiker, beslissingsgrenzen, mogelijke gevolgen van fouten en succescriteria.

Fase twee — het risicovolste testen: controleer modelgedrag, retrievalkwaliteit, spraaktiming of integratie met representatieve gevallen.

Fase drie — gecontroleerde workflow bouwen: implementeer rechtencontroles, gevalideerde output, statussen, herstel, auditbaarheid en passend menselijk toezicht.

Fase vier — evalueren: voer regressie- en aanvalstests uit en toets kwaliteit, latency en kosten met realistische belasting en apparaten.

Fase vijf — gefaseerd uitrollen: monitor gebruikersprocessen en foutcategorieën, behoud mogelijkheden tot ingrijpen en breid alleen uit wanneer de gegevens dat ondersteunen.

Dit zijn technische beslismomenten, geen gegarandeerde lanceringsplanning.

Veelgestelde vragen

Kan een werkende AI-demo meteen naar klanten?

Meestal niet zonder aanvullende beoordeling. Productiesoftware vereist geverifieerde rechten, betrouwbare foutafhandeling, passende monitoring, evaluatie, privacycontroles en herstel.

Mag een AI-agent zelfstandig acties uitvoeren?

Alleen binnen duidelijke en technisch afgedwongen bevoegdheden en risicogrenzen. Gevoelige of onomkeerbare handelingen kunnen expliciete gebruikersbevestiging of menselijke controle vereisen. Een prompt alleen biedt onvoldoende bescherming.

Hoe meten we de kwaliteit van een AI-functie?

Meet de echte taak: correcte en succesvolle resultaten, brononderbouwing, begrip bij gebruikers, veiligheidsincidenten, latency en kosten. Combineer gecontroleerde evaluaties met productiefeedback en waar nodig menselijke domeinexperts.

Engineering maakt AI tot een bruikbaar product

Succesvolle AI-ontwikkeling betekent betrouwbare processen, controleerbaar bewijs, veilige interfaces en onderhoudbare operatie ontwerpen rond onzeker modelgedrag.

Bekijk Onectus software engineering voor productarchitectuur en implementatie of staff augmentation voor gerichte specialistische expertise. Voor ingrijpende AI-toepassingen is ook onze gids over AI in recruitment relevant.