alle gidsen
AI in productie
van prototype naar productie
Deze gids is de kernsamenvatting van het leerboek Van Prototype naar Productie, getrouw aan de brontekst, in zes vraag-en-antwoordparen. Je leert waarom de meeste generatieve-AI-pilots nooit productie halen, wat evaluatie en monitoring toevoegen, hoe je een cloudplatform kiest zonder vast te lopen bij één leverancier, en wat de EU AI Act per 2 augustus 2026 van je eist. De volledige diepgang, met code, recepten en checklists, staat in de PDF-download.
download de pdf- Waarom stranden de meeste AI-pilots voordat ze productie halen?
- De meeste AI-pilots stranden niet doordat het model tekortschiet, maar doordat de organisatie AI met minimale aanpassing in bestaande processen duwt. MIT's Project NANDA onderzocht in 2025 ruim 300 initiatieven en vond dat 95% van de generatieve-AI-pilots geen meetbare impact op de winst-en-verliesrekening oplevert; slechts 5% haalt wel echte waarde. Onderzoek van ZenML onder 1.200 productie-deployments wijst dezelfde kant op: wat winnaars onderscheidt is context-engineering (het model de juiste informatie meegeven), guardrails in de infrastructuur (ingebouwde veiligheidsfilters), rigoureuze evaluatie en gewone software-fundamenten. Een demo bewijst dat iets kan werken, productie bewijst dat het blijft werken voor echte gebruikers, meetbaar.
- Wat betekenen MLOps, LLMOps en AgentOps voor een bouwer?
- Het zijn drie opeenvolgende lagen boven gewone DevOps, elk met een eigen zwaartepunt. MLOps draait om de levenscyclus van het model zelf: data prepareren, trainen, versioneren, deployen en drift monitoren (drift is de sluipende verslechtering van kwaliteit over tijd). LLMOps begint met een kant-en-klaar getraind model en bouwt eromheen: prompts, retrieval van eigen kennis (RAG), evaluatie, guardrails (veiligheidsfilters) en kosten, waarbij het model juist het minst veranderende onderdeel is. AgentOps komt erbij zodra het systeem zelf beslissingen neemt en tools aanroept: je monitort dan een heel traject van stappen in plaats van één antwoord. De meeste bouwers die "AI in productie" willen, hebben vooral LLMOps-discipline nodig, en zelden de zware MLOps-kant met eigen training.
- Hoe kies je een cloud-AI-platform (AWS, Azure of Google) zonder vast te lopen bij één leverancier?
- In de praktijk is de keuze meestal al gemaakt door je bestaande cloud: zit je data in AWS, dan is Bedrock de voor de hand liggende route, bij Microsoft 365 is dat Azure OpenAI of Foundry, en bij BigQuery Vertex AI. Wat wél in jouw hand ligt, is hoeveel je vastzit: zet een gateway zoals LiteLLM of Portkey tussen je applicatie en de modellen, dan wordt overstappen een configuratiewijziging in plaats van een herschrijving. Houd ook je prompts, je opgehaalde kennis (RAG) en je evaluaties platform-onafhankelijk, want dat zijn je eigen bezittingen die je niet aan één SDK wilt vastnagelen. De kosten worden niet alleen bepaald door de tokenprijs: elk platform rekent apart voor guardrails, kennisbanken, logging of agent-sessies, dus vergelijk platformen op de totale rekening. Multi-cloud "voor de zekerheid" klinkt verstandig, maar verdubbelt meestal de complexiteit zonder echte winst.
- Hoe weet je of je AI-systeem echt goed werkt, en niet toevallig één keer een goed antwoord gaf?
- Dat weet je alleen door evaluatie: outputkwaliteit omzetten in een score op een schaal, herhaalbaar en op schaal getest, in plaats van elk antwoord met de hand na te lezen. Een klassieke test geeft een ja of nee, maar een taalmodel geeft bij dezelfde vraag niet altijd hetzelfde antwoord, dus dat binaire antwoord bestaat hier niet. Je begint met een golden test set: twintig tot vijftig representatieve voorbeelden met een vastgelegd goed antwoord of een beoordelingsrubriek, die groeit zodra een echte fout in productie een nieuw testgeval wordt. Volgens het MIT-onderzoek is dit precies het verschil tussen de 5% die wel waarde haalt uit AI en de 95% die strandt: de eerste groep meet, de tweede vaart op onderbuikgevoel. Zonder evaluatie kun je niet aantonen dat een wijziging een verbetering is, en kun je niet veilig opschalen.
- Wat is er mis met gewone monitoring voor een AI-systeem in productie?
- Gewone monitoring kan groen tonen terwijl het antwoord van je AI inhoudelijk klopt van geen kant, en dat is precies het probleem. Applicatieprestatie-monitoring (APM), zoals Datadog of New Relic, kijkt naar statuscodes, latency en foutmeldingen: voor normale software is dat genoeg, want 500 betekent kapot en 200 betekent goed. Bij een taalmodel werkt die vlieger niet, want het systeem geeft netjes een 200 terug, keurig geformatteerd, terwijl het bijvoorbeeld met overtuiging een beleidsregel verzint die niet bestaat. Daarom bestaat LLM-observability als eigen categorie: je legt niet alleen vast dat er een antwoord kwam, maar ook wat het was, waarop het gebaseerd was, zoals de opgehaalde context of elke tool-aanroep van een agent, en of het klopte via een kwaliteitsscore. Bouw dit vanaf dag één in, want dezelfde vastgelegde gegevens dien je later ook als debug-gereedschap, kostencontrole en bewijslast richting toezichthouders.
- Wat moet je weten over de EU AI Act en de deadline van 2 augustus 2026?
- Vanaf 2 augustus 2026 worden drie onderdelen van de EU AI Act gehandhaafd: AI-geletterdheid (artikel 4, kun je aantonen dat je team getraind is), het verbod op bepaalde praktijken zoals social scoring (artikel 5), en transparantie-eisen (artikel 50), zoals melden dat content door AI is gemaakt en deepfakes labelen. Dat laatste raakt bijna elke organisatie die generatieve AI gebruikt, ook met open source modellen. De zwaarste verplichtingen voor hoog-risico-systemen, zoals bij werving of kredietscoring, schuiven via de Digital Omnibus (7 mei 2026) door naar eind 2027. Boetes kunnen oplopen tot 35 miljoen euro of 7% van de wereldwijde omzet. Het goede nieuws: logging, evaluatie met drempels en human-in-the-loop (een mens houdt toezicht), wat je toch al bouwt voor een betrouwbaar productiesysteem, dekt het grootste deel van de compliance-documentatie voor hoog-risico-systemen.