Artificial intelligence in de praktijk: van model tot product

Artificial intelligence is geen enkele tool, maar een keten: data en doelen, modelkeuze en architectuur, evaluatie en beveiliging, en vervolgens levering in productie met bewaking en iteratie. Hieronder krijg je een compacte, technisch gerichte aanpak om van idee naar werkende AI-systemen te gaan, inclusief implementatiekeuzes, meetbare evaluatie, en compliance-checks waar het ertoe doet.

1) Wat je in AI altijd moet beslissen (en hoe je het snel goed doet)

Start niet met prompts. Start met een engineering contract: wat is input, wat is output, wat zijn constraints, en hoe meet je succes. Schrijf die contracten eerst, pas daarna kies je technologie.

1.1 Probleemdefinitie in 5 regels

• Input: tekst, code, tabellen, afbeeldingen, logs.
• Output: classificatie, extractie (schema), zoekresultaten, antwoord met citaten, tool-actie, code, ranking.
• Constraints: latentie, kosten, maximale foutkans, stijl, formaat (bijv. JSON Schema), dataverwerking (PII, retentie).
• Meetbaar succes: exact match, F1, token accuracy, pass rate op prompts, menselijke beoordeling, worst-case regressies.
• Risico: wat gebeurt er bij misbruik of verkeerde output (veiligheid, privacy, juridische eisen).

1.2 Architectuurkeuze: LLM is het begin, niet het eind

Voor de meeste praktische use cases wil je ten minste één van deze patronen:

• Retrieval Augmented Generation (RAG): model krijgt relevante context uit je eigen bronnen.
• Tool use: model roept functies aan (search, DB, pricing, workflow, compute).
• Agents met taakplannen, maar met harde begrenzingen en deterministische acties waar mogelijk.
• Structured outputs: dwing output af in een schema zodat downstream code betrouwbaar is.
• Evaluatie-loop: automatische tests op datasets en adversariële cases.

2) Voorbeeld pipeline, van request tot productie

Neem dit als blueprint. Je vervangt de provider en het model, maar de productlogica blijft gelijk.

2.1 Minimal werkend systeem (RAG + schema output)

Doel: geef een antwoord, maar ook een machineleesbaar resultaat voor je applicatie.

Request flow

1. Validatie: check input, rechten, lengte, PII beleid.
2. Retrieval: haal top-k passages op, eventueel met reranking.
3. Prompt assembly: zet system instructions, query, context, en output schema.
4. LLM call: vraag strikt formaat terug.
5. Post-check: schema validatie, confidence heuristieken, veiligheidsfilter.
6. Opslag en observability: log request metadata, niet per se volledige content.
7. Evaluatie: meet per variant, per user-segment, en per bronkwaliteit.

2.2 Output schema dwingen (voorbeeld)

Bij voorkeur valideer je server-side. Conceptueel:

JSON Schema: 
{
  "type": "object",
  "properties": {
    "answer": {"type": "string"},
    "citations": {
      "type": "array",
      "items": {"type": "string"}
    },
    "confidence": {"type": "number"},
    "warnings": {"type": "array", "items": {"type": "string"}}
  },
  "required": ["answer", "citations", "confidence"]
}

De LLM productie-implementatie moet falen als het schema niet klopt. Niet “best effort”.

2.3 Provider-kant, wat je als ontwikkelaar echt moet kennen

Let bij LLM API’s op drie dingen die direct kosten en gedrag beïnvloeden:

• Pricing per tokens: jouw promptlengte en responselengte domineren kosten. OpenAI publiceert actuele API pricing op de officiële API Pricing pagina. (openai.com)
• Welke endpoints: moderne flows gebruiken vaak een “Responses” stijl met tools. OpenAI beschrijft recente tools en features rond de Responses API. (openai.com)
• Context venster: lange context werkt, maar kost meer, en slechte retrieval kan het venster verspillen.

Als je een kostenschatting maakt, modelleer dan: prompt tokens = query tokens + context tokens + instructies tokens + eventuele tool outputs.

3) Data, retrieval en evaluatie die je kan vertrouwen

De grootste fout in veel AI-projecten is: “het model is het product”. In praktijk is je product je data pipeline en je evaluatiestrategie.

3.1 Dataset: maak hem bruikbaar voor test

Je hebt minimaal drie datasets nodig:

• Train/finetune (optioneel): alleen als je echte signalen hebt, niet alleen als je meer voorbeelden wil.
• Eval: representatief, gespreid over intent, moeilijkheid, en domeinvarianten.
• Adversarial: promptinjecties, out-of-domain vragen, policy triggers, en “confident wrong” cases.

3.2 Retrieval kwaliteit meten

Meet retrieval los van generatie. Pas daarna optimaliseer je prompts.

• Recall@k: zit de juiste passage in top-k?
• MRR of NDCG: rangorde kwaliteit.
• Bron-to-antwoord overlap: citeert het model passages die relevant zijn voor de claim?

Gebruik reranking als je retrieval redelijk is maar de top-k net niet klopt.

3.3 Evaluatie voor LLM: niet alleen “goed/ fout”

Voor productioneel gebruik wil je een score die je kunt doorkruisen:

• Format errors: schema klopt niet, citations ontbreken, verboden outputtypen.
• Answer quality: factuality, volledigheid, constraint adherence.
• Safety: policy compliance en leakage checks.
• Latency: p50, p95, p99, inclusief tool calls.
• Kosten: cost per verzoek, en cost per succesvolle pass.

Werk met gates: je deployt alleen varianten die geen regressie veroorzaken op kritieke buckets.

4) Beveiliging, privacy en misbruikpreventie

Behandel artificial intelligence als een systeem dat kan falen op manieren die klassieke software niet kent: promptinjectie, data leakage, tool misuse, en context contaminatie.

4.1 Promptinjectie: reduceer privileges

• Geef model toegang tot tools met een allowlist per use case.
• Tool inputs moeten server-side gevalideerd worden, nooit blind uit modeloutput.
• Gebruik “context origin” labels, zodat je kunt herkennen wat bron is.

4.2 Privacy: PII beleid is geen bijzaak

• Definieer welke velden mogen worden doorgestuurd.
• Tokeniseer en log op veilige wijze: vermijd volledige content logging als het niet nodig is.
• Overweeg redactie, hashing of detach van gevoelige stukken.

4.3 Safety filters: combineer heuristiek en evaluatie

Filters zijn geen garantie. Het doel is risicoreductie plus detectie. Gebruik een combinatie van:

• Input checks (PII, verboden intenties)
• Output checks (schema, policy triggers)
• Post-hoc evaluatie (menselijke review op sampling)

5) Compliance: wat je moet meenemen (EU AI Act als ankerpunt)

Voor EU-context is de EU AI Act relevant. Voor tijdlijnen en wanneer verplichtingen ingaan kun je de implementatie-timeline van de Europese Commissie (AI Act Service Desk) raadplegen. (ai-act-service-desk.ec.europa.eu)

5.1 Praktisch: bouw een compliance checklist

Zelfs als je niet “high-risk” bent, heb je engineering werk:

• Documenteer: data herkomst, evaluatiemethoden, en beperkingen.
• Traceer: welke modelversie, welke prompt-template, welke retrieval indexes.
• Monitor: drifts, safety incidenten, regressies.
• Governance: wie mag deployen, wie beslist over uitzonderingen.

De AI Act kent faseringen. Een belangrijke mijlpaal in de implementatietimeline is dat AI Act verplichtingen voor providers van general-purpose AI modellen volgens de Europese implementatie-tijdlijn van toepassing worden op een specifieke datum. (ai-act-service-desk.ec.europa.eu)

5.2 Risico management raamwerk (NIST)

Voor risicoanalyse kun je het NIST AI Risk Management Framework als referentie gebruiken. NIST meldt de release van AI RMF 1.0 op 26 januari 2023. (nist.gov)

In practice vertaal je dat naar je SDLC, threat model, en evaluatieplan.

6) Implementatiesnelkoppelingen die echt tijd schelen

Je kunt veel tijd winnen door standaard patronen te gebruiken in plaats van ad hoc promptwerk.

6.1 “Varianten” beheren, niet losse prompts

• Maak prompt templates versioned (git + changelog).
• Koppel elke template aan eval buckets.
• Deploy alleen templates met bijbehorende tests.

6.2 Cost control: beperk context en response

• Retrieval top-k klein starten, dan opschalen met recall data.
• Gebruik truncation strategieën die je inhoud behoudt waar het telt.
• Maak output compact, en verplaats details naar follow-up calls als het kan.

6.3 Gebruik tools voor deterministische stappen

Als je wiskunde, lookup, of database queries hebt, laat het model niet “raden”. Laat het tools aanroepen voor deterministische stappen, en laat het model de interpretatie doen.

7) Waar je doorlinkt voor verdieping, bouw, en beheer

Als je snel van concept naar implementatie wilt, zijn dit logische vervolgstappen voor een technische lezer.

• AI OpenAI gids voor developers: API, tools, integratie
• AI in de praktijk: bouw, test en beheer (2026)
• Open AI Chat: ChatGPT Gebruiken en Integreren
• AI Programmeren: Van Concept naar Productie
• AI Web: Webapplicaties Bouwen met AI, Technische Gids
• AI Lab: Experimenteren met AI-Modellen. Brief: Handleiding
• Chai: Chat met AI Friends – Review en Alternatieven
• AI Cursus: Beste Trainingen en Leerpaden. Brief
• AI bij NVIDIA: Hardware, Software en Ecosystem. Brief
• AI Blog Sites en Nieuwsbronnen: Beste Resources

8) Conclusie: zo maak je artificial intelligence productwaardig

Als je maar één aanpak meeneemt: behandel artificial intelligence als een engineering systeem, niet als een knop. Definieer contracten (input, output, constraints), maak retrieval en evaluatie meetbaar, forceer structured outputs met server-side validatie, beperk privileges van tools, en maak compliance een pipeline die je versioneert. Daarna itereren op data en tests, niet op losse intuïtie.

Wil je dat ik dit vertaal naar jouw use case? Geef: domein, input type, gewenste output, latency target, en of je EU users hebt. Dan kan ik een minimale target-architectuur en eval-buckets voorstellen, inclusief een implementatie volgorde.