Artificial intelligence in de praktijk: stack, risico, agents

Kort antwoord: Bouw artificial intelligence als een pipeline, niet als een magische chatbox. Kies eerst gebruiksdoel en risico, implementeer daarna een model- en toollaag (bijv. OpenAI Responses API), voeg evaluatie en logging toe, en beperk impact met een policy laag (toegang, dataminimalisatie, guardrails). Voor governance kun je NIST AI RMF 1.0 gebruiken en je moet de AI Act timing in de gaten houden (met verplichte termijnen die later verschuiven voor sommige onderdelen).

Uitleg hieronder, direct toepasbaar, met concrete checks, beslissingen en voorbeeldcode. Als je al een team hebt dat “agenten” wil, begin met de risicokant en pas daarna pas je modelstack toe.

1) Wat je met “artificial intelligence” bedoelt, in productie-termen

In engineering termen is artificial intelligence meestal: (1) een model of ensemble, (2) een orkestratielaag, (3) tools en data, (4) evaluatie en monitoring, (5) governance en incident response.

Model, maar met context en beperkingen

Een LLM of multimodaal model is alleen het rekenmotor-gedeelte. In een echte applicatie bepaalt de rest of het systeem betrouwbaar is. Denk aan:

• Invoer: welke tekst, documenten, metadata, en welke vorm van prompt templating.
• Output-contract: vrije tekst, JSON, of een genormaliseerd schema.
• Tools: web search, file search, interne API calls, of “function calling”.
• Policy: welke acties mag een agent wel of niet uitvoeren.
• Evaluatie: kwaliteitsmetrics, hallucination checks, en taakgerichte benchmarks.

Agenten zijn orkestratie, geen “magie”

Een agent is een beleidsgestuurde loop die een model laat beslissen welke tool te gebruiken, wanneer te stoppen, en welke guardrails te volgen. De praktische vraag is dus: waar zitten je controlepunten? Je wilt expliciet:

• max stappen per run
• max toolcalls
• datatoegang per rol
• sanity checks op tool parameters
• outputvalidatie voor downstream systemen

2) Referentiekader voor risico: NIST AI RMF en wat je concreet doet

Als je artificial intelligence serieus neemt in een organisatie, heb je een raamwerk nodig dat je omzet naar engineering taken. NIST publiceerde AI RMF 1.0 (vrij beschikbaar) als generiek model voor risicomanagement. NIST benadrukt een living document aanpak, met review en update verwachtingen. (nist.gov)

Vertaal NIST AI RMF naar engineering acties

Gebruik dit als werkvertaling, niet als paperwerk. De kern is dat je het risico per use case afbakent en beheerst.

1. Identify: leg de grenzen vast, wat het systeem wel en niet doet, en welke assets geraakt worden (data, geld, reputatie, veiligheid).
2. Measure: definieer meetbare failures (bijv. schema invalid, tool misuse, PII leakage, misclassificatie, prompt injection effects).
3. Manage: zet mitigaties op die je kunt testen, zoals redaction, least privilege, allowlists, input filtering, output constraints.
4. Govern: logging, audits, incident response, en review cycli voor changes in prompts, modellen, en tools.

GenAI-specifiek: profile en extra aandachtspunten

NIST heeft naast AI RMF 1.0 ook een generative AI profiel publicatie als onderdeel van het ecosysteem rond AI risicobeheer. (nist.gov)

Praktische checklist voor “veilig genoeg om te shippen”

• Je systeem is getest op prompt injection en tool parameter tampering.
• Je output gaat door een schema validator (of strikte parsing) voordat hij downstream acties triggert.
• Je hebt dataminimalisatie (alleen relevante velden, geen extra PII).
• Je logging bevat geen secrets, geen onnodige PII, en je bewaartermijnen zijn gedefinieerd.
• Je hebt fail-safes: fallback naar handmatige review bij onzekerheid of detectie van policy schending.

3) EU AI Act timing: wat je moet plannen voor 2025 tot 2028

EU AI Act is regelgeving, dus timing is cruciaal. De implementatietimeline bevat meerdere fases voor verschillende verplichtingen en categorieën, met later toepasbare termijnen voor sommige onderdelen. Raadpleeg voor planning de officiële implementatie timeline pagina’s.

Waarom je dit in je roadmap zet

• Compliance is niet alleen documentatie, het beïnvloedt product logging, transparantie, modelgebruik en risicomanagement controles.
• Veel teams onderschatten de tijd voor “operationele implementatie”: audits, systeeminventaris, en proceswijzigingen.

Concreet: onderdelen die later actief worden

Voor high-risk regels zijn er in de praktijk uitgestelde toepassingsmomenten in de latere fase. De Consilium timeline noemt voor stand-alone high-risk systemen en high-risk systemen embedded in producten vaste data voor latere toepassing. (consilium.europa.eu)

Daarnaast bevat de Europese Commissie informatie over wanneer verboden praktijken en AI literacy verplichtingen ingaan, en een set regels voor high-risk AI systemen volgens de AI Act structuur. (digital-strategy.ec.europa.eu)

Als je liever een engineering-gericht overzicht wilt, kijkt de AI Act Service Desk ook naar de implementatie timeline, inclusief overgangstermijnen. (ai-act-service-desk.ec.europa.eu)

Engineering planning: wat je nu al kunt doen

Ook als je niet 1-op-1 “high-risk” bent, kun je dezelfde controlelaag opzetten:

• inventaris van AI componenten (modellen, prompts, tools)
• risk assessments per use case
• output en decision logging met toestemming en privacy grenzen
• mens-in-de-loop waar nodig
• kwaliteit en drift monitoring

4) Stack in 2026: orkestratie, Responses API, tools, en evaluatie

Je stack is doorgaans: backend service, prompt templates, model API, tool adapters, evaluatie harness, en een policy engine. Als je bouwt met de moderne OpenAI API richting Responses, sluit je applicatie aan op de Responses API als pad richting agentische workflows. (cdn.openai.com)

Model selectie: wat je minimaal moet vastleggen

Leg per use case vast:

• input modality (tekst, beeld)
• latency budget
• kosten budget per run
• output format (free text versus JSON)
• veiligheidsvereisten (PII, browsing, file access)

OpenAI’s model documentatie laat zien dat modellen via de Responses API en SDK’s beschikbaar zijn, en dat je capability en opties per model moet bekijken. (developers.openai.com)

Voorbeeld: Responses call met tool ondersteuning (schematisch)

Dit is een minimale opzet. Pas het aan aan je tool contracts en output schema validatie.

import json
from openai import OpenAI

client = OpenAI()

schema = {
  "type": "object",
  "properties": {
    "answer": {"type": "string"},
    "citations": {"type": "array", "items": {"type": "string"}}
  },
  "required": ["answer"]
}

resp = client.responses.create(
  model="gpt-5.6",
  input="Geef een korte samenvatting en noem bronnen als je die gebruikt.",
  # In echte code verbind je hier tools en je outputvalidatie
)

print(resp.output_text)

De exacte parameters hangen af van je implementatie, maar het belangrijke punt is dat je output niet vertrouwt zonder parsing of validatie, en dat tool calls alleen mogen binnen een geautoriseerd contract. De OpenAI Responses API documentatie beschrijft het gebruik rond responses, tools en het bouwen met tool ondersteuning. (developers.openai.com)

Evaluatie harness: minimal viable, maar niet overslaan

Voor artificial intelligence in productie wil je minstens:

• Unit tests op prompt templates (zelfde input, zelfde expected schema)
• Regression set van representatieve prompts en edge cases
• Adversarial set voor injection, schema bypass, en tool misuse attempts
• Cost tracking per variant (latency en tokens)

Monitoring: drift en incidenten

• Log model version, prompt hash, en tool call resultaten.
• Meet failure rates per type, niet alleen “overall pass/fail”.
• Bij incidenten: reproduceer met dezelfde input en dezelfde policy configuratie.

5) Veilige agent-architectuur: policy laag, allowlists, en stopcondities

Agenten vergroten je aanvalsoppervlak, omdat er meer stappen en meer tool privileges zijn. Je lost dit op met een expliciete policy engine en contractgebaseerde tool interfaces.

Policy engine: ontwerpregels

• Least privilege: agent krijgt alleen keys en scopes die hij nodig heeft.
• Allowlist: tool names en parameter ranges zijn hard gecodeerd.
• Schema-first: agent output moet altijd door validatie.
• Stop rules: max iteraties, max toolcalls, en “no further action” bij onzekerheid.
• Human gate: bij acties die geld, rechten, of productie-impact hebben.

Guardrails voor prompt injection

Voorbeelden van waar je op moet testen:

• Agent die probeert een tool prompt te omzeilen met “negeer eerdere instructies”.
• Malafide tekst die lijkt op systeemberichten of tool instructions.
• Induced tool parameter tampering (bijv. een id buiten allowed set).

Mitigaties:

• scheid “instructions” van “user content” (prompt templating discipline)
• tool parameters valideren server side, nooit alleen op basis van model output
• content filtering en redaction waar relevant

Voorbeeld: tool call contract met server-side validatie

ALLOWED_ACTIONS = {"search_docs", "create_ticket"}
ALLOWED_TICKET_URIS = {"urn:dept:it", "urn:dept:security"}

def validate_tool_call(action, params):
  if action not in ALLOWED_ACTIONS:
    raise ValueError("actie niet toegestaan")

  if action == "create_ticket":
    uri = params.get("scope_uri")
    if uri not in ALLOWED_TICKET_URIS:
      raise ValueError("scope_uri niet toegestaan")

  # type checks en bounds checks
  if "priority" in params:
    if params["priority"] not in {"low","medium","high"}:
      raise ValueError("priority ongeldig")

  return True

6) Data, privacy en integraties: waar het vaak misgaat

Veel artificial intelligence projecten falen niet op het model, maar op data. Denk aan datakwaliteit, datalek risico’s, en onbedoelde koppelingen.

Dataminimalisatie als default

• Stuur alleen velden die je nodig hebt.
• Redact PII waar mogelijk, of tokenize en scheid identifiers.
• Bewaar zo weinig mogelijk op raw prompts en tool outputs.

Integraties met tools

Als je agent interne systemen aanroept, zet je integratie achter een backend endpoint met policy enforcement. De modelkant beslist, maar de backend beslist uiteindelijk.

Content provenance en bronnen

Als je output gebaseerd is op documenten of web content, wil je:

• traceerbaarheid naar bronsegmenten
• consequentie in citatie format
• weigeren bij missing provenance als dat policy vereist

7) “Voorbeeld-eerst” route naar bouwen en veilig inzetten

Als je weinig tijd hebt, volg dit pad van concept naar production. Dit is geen theorie route.

Stap 1, use case en risicoprofiel

• Wat is de taak, en wat is de maximale schade als het misgaat?
• Welke data raakt het systeem?
• Zijn er acties, niet alleen tekst output?

Stap 2, defineer output-contract en tool contracts

• JSON schema of genormaliseerd formaat
• Tool interfaces met expliciete parameters
• Server-side validatie

Stap 3, bouw evaluatie en adversarial tests

• Regression set voor regressie en kwaliteit
• Injection tests voor veiligheid
• Cost tests, tokens en latency

Stap 4, governance en compliance planning

• NIST AI RMF vertaling naar je interne processen (nist.gov)
• AI Act timing en dataverzameling aanpassen aan implementatie fases (consilium.europa.eu)

Verdiepende interne content, als je door wil

• AI OpenAI in de praktijk: Responses, tools en agents
• AI in 2026, praktische gids voor bouwen en veilig inzetten
• AI nieuws in 2026, wat je moet weten en doen

8) Snelle implementatie voorbeelden, inclusief “agent safety” keuzes

Hier zijn keuzes die je in code en architectuur terugziet, met directe impact.

Keuze A, free-text output vermijden bij acties

Als je agent iets gaat doen, eis een schema, en parse op de server. Geen vrije tekst die vervolgens een actie triggert.

Keuze B, tool call budget per run

• max 3 iteraties voor simpele taken
• max 5 toolcalls voor document retrieval taken
• bij meer, escalate naar batch processing of human review

Keuze C, “tool-first” retrieval bij RAG

Als je context nodig hebt, haal bronnen op met tools en geef dan pas antwoord. Dat verlaagt hallucination en maakt evaluatie eenvoudiger.

Keuze D, fail gesloten bij policy mismatch

Als policy mist of validatie faalt, stop. Niet “probeer nog eens”.

9) Leren en versnellen: interne cursuspaden voor prompt tot veilige agenten

Als je team nog niet systematisch werkt met policy, schema, evaluatie en logging, dan helpt een kort cursuspad met praktische opdrachten.

• AI cursus online: van prompt tot veilige agenten
• Cursus AI: praktische route van prompt tot veilige agenten
• AI cursus: van prompt tot veilige agenten, praktisch
• AI alsmaar intelligenter: van modellen tot veilige agenten

10) Wat je vandaag kunt checken, voordat je meer bouwt

Gebruik deze “done list” om te voorkomen dat je doorontwikkelt op een onveilige basis.

• Output schema is verplicht voor alle action triggers.
• Tool validatie zit server side, niet alleen in prompt instructions.
• Adversarial tests bestaan en falen niet, inclusief prompt injection cases.
• Logging is voldoende voor debugging, maar behept met privacy grenzen.
• Risicobeoordeling is per use case gedaan met NIST AI RMF vertaling als structuur. (nist.gov)
• Regelgeving timeline is gecheckt, met implementatie momenten voor latere AI Act onderdelen in je roadmap. (consilium.europa.eu)

Als je stack en ontwikkelingen wil volgen

• Kunstmatige intelligentie nieuws: updates, trends, stack
• Kunstmatige intelligentie blog: start, stack, veiligheid
• AI NVIDIA in 2026: stack, drivers, agenten, kosten

Conclusie

Artificial intelligence is pas nuttig als je het als systeem ontwerpt: model plus orkestratie, tools plus server-side contractvalidatie, evaluatie plus monitoring, en governance plus risicomanagement. Start niet met “welke modelversie”, start met “welke failures accepteren we niet”. Gebruik NIST AI RMF 1.0 als vertaalbare structuur voor risicobeheer. (nist.gov) Verwerk tegelijk de EU AI Act timing in je roadmap, omdat verplichtingen en overgangsdatums je productprocessen raken. (consilium.europa.eu)

Als je een agent bouwt, zet je policy laag, stopcondities, output schema validatie, en tool allowlists op als eerste-klasse componenten. Dan pas ga je itereren op prompts en modelkeuze.