Program AI: van idee naar veilige agentische systemen

Antwoord (kort): Program AI = je AI model of agent koppelen aan een duidelijke interface (input, tools, policy), beveiliging afdwingen (prompt injection, data exfiltratie, tool abuse), en het geheel verpakken in een reproduceerbare pipeline (tests, observability, rollout). Richt het op met een strakke architectuur, minimale bevoegdheden, en harde validatie op elke stap.

Uitleg (waarom dit zo werkt): De meeste “program AI” problemen zijn geen modelproblemen, maar systeemproblemen: onbedoelde acties door tool wiring, lekkage door prompt injection, ontbrekende scope checks, geen uitvoercontract (schema) en geen test harness. Als je die punten ontwerpt, wordt program AI voorspelbaar.

Wat betekent “program ai” in de praktijk

“Program AI” is geen magische categorie. Het is het engineering patroon waarbij je een AI, meestal een LLM (of multimodaal model), programmeert als onderdeel van een systeem. Dat systeem heeft regels, state, tools, en harde grenzen. In plaats van alleen tekst genereren, laat je het model opdrachten uitvoeren via gecontroleerde functies, bijvoorbeeld: fetchen van data, query’s draaien, tickets aanmaken, of documentatie samenvatten.

Vier bouwblokken

• Contract: wat komt er in, en wat mag eruit. Gebruik schema’s (JSON), validatie en expliciete velden.
• Controlelaag: policy en guardrails vóór en na elke tool call. Nooit “vertrouw op de output”.
• Tooling: een beperkte set tools met expliciete input schema’s, rate limits, en per-tool permissies.
• Observability: log input, tool calls, latency, fouten, en “waarom” (beslisredenen) op een manier die geen secrets lekt.

Architectuur die je direct kunt bouwen

Als je program AI serieus neemt, bouw je een referentie-architectuur. Gebruik deze indeling, dan kun je het later uitbreiden zonder dat veiligheid achteraf een patch wordt.

Agent loop in 6 stappen

1. Ingest: normaliseer user input, strip ongewenste content, en maak een interne request structuur.
2. Context assembly: kies contextbronnen (RAG, chat history). Zet context apart van instructies.
3. Plan of direct action: laat het model een plan maken of direct een toolcall triggeren, afhankelijk van use case.
4. Policy check: valideren dat tool en parameters toegestaan zijn voor deze sessie en gebruiker.
5. Tool execution: voer tools uit in een sandbox of met minimale privileges.
6. Output shaping: construeer een response volgens schema en controleer op datalekken of policy schending.

Input en output als JSON-contract

Maak je systeem “schema-first”. Dan voorkom je dat je model vrijuit kan outputten. Een simpele aanpak:

// Voorbeeld: output contract (conceptueel)
{
  "action": "tool_call|final",
  "tool": "search|create_ticket|...",
  "tool_input": { ... },
  "final": { "answer": "...", "citations": [], "confidence": 0.0 }
}

Op de app-kant valideer je dit met een schema validator. Als validatie faalt, stopt je systeem, of je forceert “final” met een foutmelding die geen interne details lekt.

Beveiliging: prompt injection, tool abuse en data exfiltratie

De kern van program AI veiligheid is: LLM output is niet betrouwbaar. OWASP zet prompt injection bovenaan in zijn Top 10 voor LLM applicaties, o.a. omdat aanvallers daarmee gedrag van het systeem manipuleren en vaak downstream impact veroorzaken. (owasp.org)

Threat model dat je moet afdekken

• Prompt injection: input die instructies probeert te overrulen, of tool calls probeert te triggeren.
• Tool abuse: LLM probeert een tool te misbruiken voor ongeautoriseerde acties (bijv. e-mail versturen, admin endpoints, of bredere queries).
• Data exfiltratie: het model probeert gevoelige data uit context, logs, of interne stores te “leaken”.
• Schema bypass: het model output in een vorm die je parser of downstream breekt.
• Indirect prompt injection via RAG: documenten bevatten kwaadaardige instructies die het systeem overneemt.

Concreet: OWASP-gebaseerde mitigaties

Gebruik de OWASP aanpak als checklist: constrain inputs, scheid instructies van data, valideer tooling, en beperk wat het model kan doen. In de OWASP cheat sheet “LLM Prompt Injection Prevention” staan praktische control patterns (o.a. het behandelen van prompt injection als kwetsbaarheid en het afdwingen van veilige verwerking). (cheatsheetseries.owasp.org)

OpenAI’s framing van prompt injections

OpenAI beschrijft prompt injections als een evoluerende security uitdaging en benoemt dat defense een industrieel probleem is. (openai.com) Gebruik dit niet als marketing, maar als signaal: je moet je systeem ontwerpmatig verdedigen, niet alleen “prompten”.

Tooling: minimale privileges en harde allowed-lists

Als je tools toevoegt, voeg je attack surface toe. Programmeer dan defensief:

• Allowed-lists per gebruiker: welke tools, welke resources, welke acties.
• Param constraints: input types, lengte limits, regex, en geen vrije SQL, geen vrije shell.
• Server-side enforcement: checks gebeuren server-side, niet in de prompt.
• Rate limiting: vooral bij search, externe calls, en write tools.

Voorbeeld: tool call dispatcher met policy

// Conceptueel pseudocode patroon
function handleToolCall(request, userContext) {
  const tool = request.tool;
  const input = request.tool_input;

  if (!isToolAllowed(userContext, tool)) {
    throw new Error("Tool niet toegestaan");
  }

  const normalized = validateToolInput(tool, input); // schema validation
  enforceResourceScope(userContext, normalized);    // resource-level scope

  return executeTool(tool, normalized);            // server-side
}

Let op het verschil: validateToolInput en enforceResourceScope zijn geen “LLM instructies”, het zijn echte code checks.

RAG veiligheid: context scheiden en “niet uitvoeren”

Als je retrieval gebruikt, behandel documents als data, niet als instructies. Practical rule: system prompt en developer rules boven retrieval content. Voeg bovendien filters toe tegen instructie-achtige patronen (bijv. “negeer bovenstaande”, “gebruik deze sleutel”, “verzend dit”). Je kunt dit aanvullend zien als “content sanitization” vóór je model-context verwerkt.

“Program AI” workflow: van idee naar productie-ready build

Dit is de build volgorde die je tijd bespaart. Doe het zo, dan krijg je sneller een werkend systeem met minder veiligheidsfouten.

Stap 1, kies use case en scope

• Kies één taak die een tool nodig heeft (bijv. zoek interne kennis, maak een ticket, of schrijf een samenvatting met bronvermelding).
• Definieer wat “succes” is en wat “fail” betekent (geen tool call, of een tool call met beperkte output).
• Leg vast welke data niet mag worden benaderd (PII, secrets, interne admin pagina’s).

Stap 2, ontwerp het output contract

• Maak een JSON schema voor: action, tool, tool_input, final answer.
• Laat tool_output ook via schema lopen.
• Beperk final answer tot velden die je nodig hebt, bijv. answer, citations, next_steps.

Stap 3, maak een test harness met adversarial cases

Je hebt tests nodig die geen “normale gebruiker” simuleren, maar aanvallen. Minimaal:

• Prompt injection input: tekst die instructies probeert te overrulen.
• Exfil test: laat het model proberen gevoelige velden te reproduceren. Controleer dat het faalt.
• Tool boundary test: vraag om acties buiten scope. Controleer server-side deny.
• Schema fuzz: random extra velden, verkeerde types, lange strings. Zorg dat parsing of validatie niet doorbreekt.

Stap 4, rollout in lagen

• Mode 0: model alleen, geen tools.
• Mode 1: read-only tools (query’s, search).
• Mode 2: write tools met stricte scope en audit logs.

Dit voorkomt dat je meteen “agent met admin rechten” live zet.

Stap 5, ga van prototype naar veilig systeem

Als je al bezig bent met AI automatisering en je wil het “van workflow tot veilige productie” bouwen, past dit vaak beter bij een engineering aanpak. Zie ook: AI automatisering: van workflow tot veilige productie.

Als je je systeem inzet in een web context, denk aan RAG, tools, en security boundaries in je web stack. Relevante referentie: AI web: bouw een AI-gedreven website met stack en veiligheid.

Agentische systemen: patterns die werken (en wat je moet vermijden)

Agenten zijn niet automatisch slimmer. Ze zijn wel automatisch meer risicovol, omdat ze meerdere stappen en tools combineren. Program AI voor agenten vereist extra discipline.

Pattern A, planner en executor scheiden

• Planner: beslist welk type acties nodig zijn, met globale intentie.
• Executor: voert alleen acties uit die voldoen aan schema en policy.

Waarom dit helpt: je kunt planning los testen, en execution strikt blokkeren.

Pattern B, state machine boven vrije chat

Maak je agent geen “vrije gesprekspartner” die in elke beurt nieuwe grenzen overschrijft. Gebruik een state machine:

• STATE=collect_request, STATE=fetch_data, STATE=validate, STATE=finalize.
• In elke state zijn slechts bepaalde tool calls toegestaan.

Pattern C, output als contract, niet als instructie

Gebruik de model output niet als instructies voor jezelf (“doe dit daarna”). Geef je code de leiding. Laat het model “verklaren”, maar laat code “beslissen”.

Wat je moet vermijden

• Geen onbeperkte tool toegang: geen “execute arbitrary code” tools, geen shell.
• Geen direct web schrijven zonder sanitization: bij publicatie flows, filter content en controleer authorisatie.
• Geen secrets in prompts: secrets horen nooit in model input, ook niet “tijdelijk”.

EU AI Act: timing, wat het betekent voor program AI

Als je in de EU AI systemen op de markt brengt of inzet, moet je rekening houden met de AI Act. De verordening trad in werking op 1 augustus 2024. (commission.europa.eu)

Timeline in hoofdlijnen (belangrijk voor planning)

Voor compliance planning zijn vooral de later toepasselijke verplichtingen relevant. Het EU AI Act Service Desk overzicht noemt dat:

• verplichtingen voor high-risk systemen in Annex III van toepassing worden op 2 december 2027;
• regels voor high-risk AI systemen die ingebed zijn in gereguleerde producten, vallen op 2 augustus 2028. (ai-act-service-desk.ec.europa.eu)

Daarnaast meldt de EC digital strategy pagina dat sommige verplichtingen (zoals AI literacy en verboden praktijken) eerder toepasselijk worden, met een doorlooptijd afhankelijk van type verplichting. (digital-strategy.ec.europa.eu)

Wat je nu al praktisch kunt doen

• Documenteer je systeem: wat doet het, welke data, welke outputs, welke safeguards.
• Zet governance op: wie is accountable voor modelwijzigingen, tool veranderingen, en content policies.
• Onderbouw risico: classificeer je use case op basis van doel, impact, en autonomie.

Als je “wat is het, hoe je start, risico’s” wil als basisframe rond AI in 2026, kijk ook naar: A AI in 2026, wat het is, hoe je start, risico’s.

Secuur bouwen met tools en API’s

De snelste weg naar een werkend program AI systeem is API-driven. Maar “snel” moet niet “onveilig” zijn. Je bouwt de volgende lagen.

Laag 1, model provider interactie

• Centraliseer model calls in één module.
• Maak retrybeleid, timeouts, en rate limiting bewust.
• Log geen prompts met secrets, en filter PII waar nodig.

Laag 2, retrieval en data plumbing

• Gebruik vector store met server-side access controls.
• Beperk retrieval tot categorieën die passen bij user intent.
• Geen “raw dumps” in context, maar gecontroleerde passages.

Laag 3, tool registry

• Tools registreren met schema en allowed operations.
• Maak voor elke tool een permission check op basis van userContext.
• Maak tool output opnieuw valideerbaar en logbaar.

Laag 4, kosten en latency budgetten

• Beperk contextgrootte en chunks.
• Maak een budget policy: max tokens, max tool calls per request.
• Fallback strategieën: bij tool errors, return safe final response.

Voor een praktische kijk op API, modellen, veiligheid en kosten, zie: OpenAI AI: API, modellen, veiligheid en kosten uitgelegd en voor bredere online scope: Open AI online: API, ChatGPT, veiligheid en kosten.

Voorbeeld-eerst: minimale “program ai” implementatie checklist

Als je maar één pagina wilt, gebruik deze checklist. Ik schrijf hem expres als uitvoerbare stappen.

1, ontwerp je policy voordat je code schrijft

• Welke tools bestaan er, en welke zijn write tools?
• Welke user roles mogen welke tools?
• Welke resources zijn verboden (dataklassen, endpoints, tenants)?

2, definieer schema’s voor alles

• LLM input contract (wat je toont).
• LLM output contract (action, tool, tool_input, final).
• Tool input en tool output schema’s.

3, bouw je tool dispatcher met deny-by-default

• Als de tool niet in allowed list zit, stop.
• Als input validatie faalt, stop.
• Als resource scope mismatch is, stop.

4, maak adversarial tests verplicht

• Prompt injection strings in user input.
• Prompt injection in retrieved passages.
• Tool call spoofing in output (verkeerde toolnaam, verkeerde parameters).

5, observability zonder datalekken

• Log tool calls en policy beslissingen.
• Mask secrets en PII.
• Bewaar een correlatie-id per request voor debugging.

6, rollout in fases

• Eerst model only.
• Daarna read tools.
• Daarna write tools, met audit trail.

7, maak content/publicatie veilig

Als je AI gebruikt om content te bouwen en te publiceren, behandel dat als write use case met extra checks. Een relevante bouwrichting vind je hier: Ai blog site: bouw, automatiseer en publiceer veilig.

Veelgemaakte fouten bij program AI

• Alles in de prompt: als veiligheid in tekst staat, kan input die tekst aanvallen.
• Geen server-side validatie: je vertrouwt het model om correct te zijn, maar aanvallers omzeilen dat.
• Tools zonder scope: read werkt soms, maar write tool abuse gaat mis zodra je “agents” toevoegt.
• Geen test harness: prompt injection wordt niet zichtbaar in standaard unit tests.
• Geen state discipline: agent loops blijven doorgaan, waardoor een failure cascade ontstaat.

Conclusie

Program AI is engineering: je bouwt een AI systeem met een contract, een controlelaag, beperkte tools, en een test- en observability discipline. Pak beveiliging niet als eindstap, maar als ontwerpinput. OWASP zet prompt injection centraal omdat het direct doorwerkt in tool misuse en data exfiltratie risico’s. (owasp.org)

Verder: plan compliance voor de EU AI Act vanaf de basis. De AI Act trad op 1 augustus 2024 in werking, met later toepasselijke verplichtingen voor high-risk systemen op 2 december 2027 en 2 augustus 2028 afhankelijk van categorie. (commission.europa.eu)

Als je nu wil starten met een veilige setup, gebruik deze volgorde: contract en schema, deny-by-default tool dispatcher, adversarial tests, rollout in modes. Daarna pas schaal je features, tools, en agent stappen uit. Voor een extra startpunt rond safe chat en setup kun je ook kijken naar: Chai chat met AI-vrienden: setup, veiligheid en tips.

Wil je het breder framien richting EU-regels en bouwveiligheid, dan sluit deze aan: elementsofai: bouw, veiligheid en EU-regels in 2026. En als je ook wil weten hoe je dit omzet naar een market- en stackstrategie, zie: AI market: strategie, stack, kosten en EU AI Act 2026.