Kort antwoord: Als je met program ai bedoelt: een applicatie bouwen die AI aanstuurt via programma-instructies, tools en gecontroleerde inputs, dan is je succesfactor een “AI pipeline” met (1) strikte input, (2) tool-calls met least privilege, (3) output-validatie, (4) threat modeling tegen prompt injection en (5) meetbare evaluatie. Gebruik een state machine of job runner, log alles, en behandel elke LLM-call als onbetrouwbaar gedrag dat je moet beperken.
Hieronder krijg je een direct, voorbeeld-eerst plan om dit werkend, testbaar en veilig op te zetten. Geen theorie zonder implementatie.
1) Wat betekent “program ai” in engineering termen?
In technische context is “program ai” meestal geen losse chatbot-vraag, maar een ontwerpstijl:
- Je programmeert het gedrag van een AI met een vaste policy: prompts, tool contracts, en route-regels.
- Je programmeert de omgeving die de AI tools laat gebruiken (API’s, file access, web access, databases).
- Je programmeert de controles: input sanitization, output schema-validatie, retries, rate limits, en incident logging.
De kern is dat je de LLM niet vertrouwt als “command execution engine”. De LLM is een voorstelgenerator; jij controleert wat uitgevoerd wordt.
Minimum-architectuur (werkbaar in een weekend)
- Ingest: user input naar een canonical vorm, met lengte- en typebeperkingen.
- Orchestratie: bepaal stap voor stap (state machine) wat de LLM mag doen.
- Tool layer: elk gereedschap heeft een contract, auth, en least privilege.
- Validation: output moet voldoen aan een schema, of je faalt vroeg.
- Eval: je test met een set prompts, adversarial cases, en meet of je policy wordt nageleefd.
Voor de “waarom” kun je OWASP’s LLM Top 10 als checklist gebruiken, met focus op prompt injection en data exfiltratie. (owasp.org)
2) Bouw een “program ai” pipeline: van prompt naar gecontroleerde acties
We werken met een contract-first aanpak. Eerst defineer je wat een AI mag teruggeven. Daarna koppel je dat aan tool-calls.
2.1 Prompt als policy, niet als instructie voor willekeurige actie
Een nuttige basis is: systeembeleid + taak + “wat mag wel, wat mag niet”. OpenAI publiceert best practices voor prompt engineering en benadrukt onder meer het beperken van input om prompt injection te verminderen. (help.openai.com)
2.2 Tool-calls: maak uitvoering deterministisch
In plaats van “laat de AI zelf code draaien”, laat de AI een tool request doen die jouw server valideert en uitvoert.
Voorbeeld: tool contract + state machine (Python pseudo-realistisch)
from dataclasses import dataclass
from typing import Literal, Optional
@dataclass
class ToolRequest:
tool: Literal["search_docs", "run_sql", "create_ticket"]
input: dict
class PolicyError(Exception):
pass
ALLOWED_TOOLS = {"search_docs", "run_sql", "create_ticket"}
def validate_tool_request(req: ToolRequest, user_role: str) -> None:
if req.tool not in ALLOWED_TOOLS:
raise PolicyError("Tool niet toegestaan")
# least privilege voorbeeld
if req.tool == "run_sql" and user_role != "admin":
raise PolicyError("SQL alleen voor admin")
# input shape checks
if req.tool == "run_sql":
q = req.input.get("query", "")
if not isinstance(q, str) or len(q) > 2000:
raise PolicyError("Query ongeldige vorm")
# extra: block mutaties
forbidden = ["insert", "update", "delete", "drop", "alter"]
if any(tok in q.lower() for tok in forbidden):
raise PolicyError("Alleen read-only SQL")
# state machine
def next_step(state: str, tool_outcome: Optional[dict]=None) -> str:
if state == "plan":
return "act"
if state == "act":
return "finalize"
return "finalize"
Belangrijk: je policy is code. Je validatie is code. De LLM krijgt geen “verrassingsruimte”.
3) Beveiliging: prompt injection, tool misbruik en data exfiltratie
Prompt injection is een frontlijnrisico. OpenAI beschrijft prompt injection als een aanval waarbij untrusted tekst of data instructies probeert te laten prevaleren, met mogelijk data exfiltratie. (platform.openai.com)
3.1 Threat model in 10 minuten (praktisch)
- Assets: API keys, klantdata, interne documenten, DB read access.
- Entry points: user prompt, web content, file retrieval, tool outputs.
- Trust boundaries: LLM output is onbetrouwbaar, tool input is onbetrouwbaar, externe data is onbetrouwbaar.
- Attacks: indirect prompt injection, system prompt leakage, tool output poisoning.
3.2 Input beperken en canonicaliseren
OpenAI’s safety best practices benoemen het beperken van de hoeveelheid tekst in de prompt om prompt injection te vermijden. (platform.openai.com)
Praktisch betekent dit:
- Leg harde limieten op tokenlengte of characters.
- Strapvorm: whitelist van velden, geen vrije “blob” integreren.
- Sanitize markdown en HTML content, of strip naar plain text.
- Annotaties: voeg bronmeta toe, maar behandel die meta als data, niet als instructie.
3.3 Tool-level security, least privilege en output filtering
Als een tool kan lezen, dan kan een attacker proberen te lezen wat niet mag. Dus:
- Scope tokens: elke tool een eigen service-account met beperkte rechten.
- Allow-list: tool names, parameters en output types.
- Read-only DB waar mogelijk.
- No secrets in context: laat geen api keys of interne system prompts in de context.
- Output validation: schema checks, plus content filters voor PII en secrets.
3.4 “AI firewalling” is niet genoeg, maar helpend
OpenAI bespreekt verdediging tegen prompt injection bij agents en noemt onder andere intermediary filtering, met de kanttekening dat dit niet alle gevallen vangt. (openai.com)
Dus gebruik AI filtering als extra laag, niet als enige beveiliging.
3.5 Test tegen adversarial cases (niet alleen “blijft netjes”)
Je test suite moet ten minste deze categorieën bevatten:
- Direct injection: “negeer vorige instructies”.
- Indirect injection: instructies verborgen in web content of retrieved passages.
- Tool output poisoning: een tool response die “nieuwe instructies” bevat.
- Data exfil: prompts die zoeken naar secret patterns of interne ids.
OWASP LLM Top 10 is een startpunt voor deze categorieën. (owasp.org)
4) Models, API keuzes en praktische implementatiekeuzes
Je hoeft niet elke keer een nieuwe endpoint te begrijpen om “program ai” goed te doen, maar je wil wel weten hoe je models beheert.
4.1 Model catalog en endpoint realiteit
OpenAI publiceert een “All models” lijst binnen hun API doc, inclusief modelgroepen en opties zoals audio en realtime. (developers.openai.com)
Gebruik dit om je deploy pipeline te koppelen aan stabiele model IDs en om te zien welke families compatibel zijn met jouw type input/output.
4.2 Responses API versus Chat Completions
OpenAI heeft updates gepubliceerd rond tools en features in de Responses API. (openai.com)
Praktisch advies:
- Als je tool-calls, multi-stap agents en evaluatie wil, standaardiseer op één orchestratie stijl (en houd die consistent).
- Houd je request/response logging bij, want je wil later debuggen waarom een tool-call werd afgekeurd.
4.3 Voorbeeld: “planner” geeft alleen een schema, geen vrije tekst
Een simpele maar krachtige pattern:
- Stap 1: LLM output in JSON met velden {action, params}.
- Stap 2: Server valideert JSON schema en policy.
- Stap 3: Server execute tool, server maakt samenvattende output voor user.
def llm_plan(user_text: str) -> dict:
# return alleen json conform je schema
# laat de LLM geen vrije “execution text” genereren
return {
"action": "search_docs",
"params": {"query": user_text[:200]}
}
5) Evaluatie en observability: meet of je program ai klopt
Als je geen meting hebt, weet je niet of je beveiliging werkt, of je tools correct worden aangeroepen, of je budget en latency binnen grenzen blijven.
5.1 Evaluatie rubric (minimaal)
- Policy adherence: wordt verboden acties geweigerd?
- Schema compliance: validatie faalt of slaagt, en hoe vaak?
- Tool correctness: juiste tool gekozen, juiste parameters?
- Safety: geen secret leakage, geen ongeautoriseerde data teruggeven.
- Cost: tokens per stap, tool-call count.
5.2 Logging die je later echt gebruikt
Log op z’n minst:
- LLM input metadata (lengte, bron type), nooit secrets.
- LLM output raw, plus gevalideerde extractie (na schema check).
- Tool request en tool response, inclusief duration en auth context.
- Policy decision trace (welke regel faalde).
5.3 Reproducibility: maak “eval jobs” deterministisch
- Fix je test sets en versies.
- Fix je model parameters waar mogelijk.
- Bewaar prompt templates versie.
- Bewaar tool contract versie.
6) Snelle route naar productieklaar, met referentiebouwstenen
Als je direct wil versnellen, pak een bestaande aanpak voor stack, security, en evaluatie als referentie. Deze bronnen passen goed bij het “program ai” patroon, omdat ze engineering focus leggen op build, security en testen:
- AI blog site voor engineers: stack, security, hosting
- AI web voor engineers: bouwen, beveiligen, testen
- a ai: praktische gids voor bouwen, veilig testen
- Chai chat met AI vrienden: technische gids, veilig bouwen
Voor specifieke security en API keuzes, zijn deze links handig om je tool layer en chat stack te structureren:
- Open AI online gebruiken: API, modellen en security
- OpenAI AI: praktische gids voor API, modellen en security
- Chat AI Open: veilige chatstack met API, security
En als je liever modulair bouwt, kijk naar bouwblokken en evaluatie tooling:
- elementsofai uitgelegd voor engineers: bouwblokken
- AI lab: opzet, tooling, security en evaluatie, praktisch
Tot slot, als je ook business of datastromen wil begrijpen voor je engineering keuzes (dat bepaalt je security surface):
Conclusie: program ai is pipeline engineering, geen prompt kunst
Als je “program ai” werkend wil krijgen, focus dan op vijf dingen:
- Policy als code: tool allow-lists, least privilege, schema validatie.
- Strikte trust boundaries: LLM en externe data zijn onbetrouwbaar.
- Security tegen prompt injection: beperken van input, tool output niet als instructie behandelen, en test adversarial cases. (platform.openai.com)
- Observability: logging waarmee je failures reproduceert en beleidsfouten traceert.
- Evaluatie: meet schema compliance en policy adherence, niet alleen “antwoord ziet er goed uit”.
Laat de LLM plannen, maar laat jouw server beslissen. Dat is het verschil tussen een demo en een systeem dat je kunt uitrollen.
