AI web voor engineers: bouwen, beveiligen, testen

AI web is een webapplicatie die AI-functies aanbiedt via een backend met LLM of multimodale modellen, plus security en evaluatie. Praktisch: je bouwt een API die user input valideert, auth en authorisatie afdwingt, context ophaalt uit gecontroleerde bronnen, en output veilig verwerkt naar een webfront. Hieronder staat een compacte, voorbeeld-eerst aanpak, inclusief hoe je API keys, rate limits, access control en red teaming doet.

1) AI web, in één architectuurplaat (wat je echt bouwt)

Voor AI web heb je bijna altijd dezelfde lagen:

• Webfront: UI, streaming van antwoorden, beperkte clientlogica.
• Backend API: auth, authorisatie, input validatie, policy checks, rate limiting.
• AI Orchestratie: prompt samenstelling, tool calls, retrieval (RAG) indien nodig.
• Data layer: alleen gecontroleerde data bronnen, met audit logs en least privilege.
• Security controls: secret management, bescherming tegen prompt injection, output filtering, en veilige error handling.
• Evaluatie: offline tests, golden datasets, regressietests voor prompts en tools.

Als je dit in 1 zin samenvat: client praat met je backend, backend praat met AI en je systemen; niets vertrouw je toe aan de browser.

Voorbeeld flow

1. Browser stuurt een request naar je backend: user intent, beperkingen, en eventueel een sessie-ID.
2. Backend valideert schema, auth, authorisatie, en throttle.
3. Backend haalt context op (RAG) of maakt een tool-call plan.
4. Backend roept model/API aan met vaste system-instructies en een beperkt tool-registry.
5. Backend normaliseert output, voert safety en policy checks uit, logt alles, en retourneert alleen toegestaan gedrag.

Als je een security-baseline zoekt voor API’s, kijk naar OWASP API Security Top 10 2023. De belangrijkste categorie voor LLM-achtige stacks is vaak authorisatie en object level checks (BOLA), plus misconfiguraties en onbedoeld resource gebruik. (owasp.org)

2) Stackkeuzes en endpoints: minimal viable AI web

Je doel is een kleine maar volledige loop: chat of taken afhandelen, tools aanroepen, en resultaten reproducible maken. Dit zijn de endpoints die je doorgaans nodig hebt:

• POST /v1/chat (of /v1/complete): input, sessie, gewenste capabilities.
• POST /v1/tools/{toolName}/call (optioneel): tool specific, maar wel achter dezelfde auth laag.
• GET /v1/models: optioneel, alleen voor internal use.
• POST /v1/eval/run: testcases draaien in CI of staging.

Minimal backend contract (voorbeeld)

Hou het contract streng. Bijvoorbeeld:

• user_id komt uit auth, niet uit payload.
• messages is gelimiteerd in lengte en aantal.
• capabilities is een enum met whitelists (geen vrije toolnames uit de client).
• context_refs zijn IDs, geen raw data blobs.

Prompts: maak variabelen en beperkingen expliciet

Gebruik een fixed system prompt template plus expliciete policy constraints. Voorbeelden van constraints die je meestal wil:

• Geen secrets uitlezen, geen interne tokens retourneren.
• Alleen tools die in registry staan mogen gebruikt worden.
• Bij onzekerheid: geen gokken, vraag om missing informatie.
• Gebruik gecontroleerde bronnen bij RAG, en citeer niet zomaar.

Als je AI web met OpenAI of andere modelproviders doet, let extra op secret handling. OpenAI adviseert API keys te beveiligen, onder andere via environment variables en secret management. (help.openai.com)

3) Security die je niet kunt overslaan (auth, keys, authorisatie, rate limits)

Dit hoofdstuk is de reden dat AI web vaak faalt in productie: te veel vertrouwen in client input, en te weinig access control rond data en tools.

API keys: nooit in de frontend

• Gebruik geen API key in browser code.
• Stop de key in server-side environment variables en gebruik secret management waar mogelijk.
• Log nooit headers of payloads met secrets.

OpenAI’s help center beschrijft best practices voor API key safety, inclusief het gebruik van environment variables zoals OPENAI_API_KEY, plus het beperken van blootstelling en het gebruik van secret scanning. (help.openai.com)

Auth en authorisatie: dwing object level checks af

OWASP API Security Top 10 2023 zet sterk in op authorisatieproblemen. Met AI web krijg je extra risico omdat een model “acties” kan sturen via tools. Als je tool endpoints object-level authorisatie missen, is prompt injection een versneller, niet de oorzaak. (owasp.org)

Concreet, doe dit:

• Autorisatie op elk relevant object: document ID, tenant ID, project ID.
• Whitelists voor wat een gebruiker mag: capabilities, roles, en tool permissies.
• Gebruik server-side checks, nooit alleen in de prompt.

Rate limiting en resource caps

AI web kan snel onbedoeld duur en kwetsbaar worden. Zet daarom caps op:

• requests per minuut per user en per IP (throttle).
• tokens en max output lengte.
• tool call budgets (max tool calls per request).
• timeout op model calls en externe retrieval.

OWASP benoemt als categorie onder andere onbedoeld resource gebruik en ontbreken van adequate mitigaties. (owasp.org)

Prompt injection: ontwerp alsof input vijandig is

Je moet niet gokken dat het model “het wel begrijpt”. Behandel input als untrusted:

• Sta niet toe dat user input system instructies overschrijft.
• Gebruik scheiding tussen instructies en data.
• Filter of markeer retrieval content (bijv. met bron-tags) en stuur het als data, niet als instructie.
• Voor tools: laat alleen het model “kiezen” tussen tool acties, maar valideer tool parameters server-side.

Praktisch: tool-registry + parameter validatie winnen altijd van “we vertrouwen de prompt”.

Logging en audit

Log op zijn minst:

• request ID, user ID, model provider, model versie (als je die krijgt), en parameters die niet-secrets zijn.
• tool calls: toolName, input hashes, en output metadata.
• policy decisions: waarom iets geblokkeerd is.

4) Bouwen met RAG en tools: voorbeeld-eerst

Als je AI web meer wil dan chat, krijg je meestal tool calls en retrieval. Hieronder een voorbeeldpatroon voor “tools met server-side authorisatie”.

Tool registry design

Hou tool definitions server-side. De client mag hooguit aangeven welke intent heeft, niet welke tool willekeurig.

• ToolName is een string uit een whitelist.
• Schema voor tool parameters is afgeleid uit code (bijv. JSON Schema of Pydantic).
• Policy is een functie die user, tenant, en resource object vergelijkt.

Voorbeeld: server-side tool call (pseudo code)

Niet letterlijk kopiëren, wel het patroon.

request = validateRequest(body, authUser)
policy = loadPolicy(authUser)

toolCalls = []
plan = modelSuggestToolPlan(request)

for call in plan.toolCalls:
  assert call.toolName in registry
  params = validateToolParams(call.params)

  resource = resolveResource(params)
  assert authorize(policy, resource, call.toolName)

  result = executeTool(call.toolName, params)
  toolCalls.append({"tool": call.toolName, "resultMeta": meta(result)})

final = modelComposeAnswer(request, toolCalls)
final = postProcessAndFilter(final)
return final

Belangrijk: executeTool draait pas na authorisatie. De model-output stuurt intent, niet permissies.

RAG: retrieval is geen security layer

RAG kan data leken, als je tenant filtering vergeet. Dus:

• Filter retrieval by tenant en permissions.
• Controleer retrieved doc IDs tegen authorisatie, zelfs als je ze uit een index haalt.
• Stuur retrieval chunks als “data”, niet als “instructies”.

Praktische AI web resource links (context)

Als je al richting een build met meer discipline gaat, passen deze handleidingen goed als aanvulling:

• a ai: praktische gids voor bouwen, veilig testen
• Chai chat met AI vrienden: technische gids, veilig bouwen
• Chat AI Open: veilige chatstack met API, security
• AI lab: opzet, tooling, security en evaluatie, praktisch

5) Evaluatie in CI: hoe je regressies voorkomt

Als je AI web in productie zet zonder evaluatie, ontdek je problemen via support tickets. Beter: bouw een evaluatie-lus die je in CI kunt draaien.

Testlagen

• Unit: schema validatie, policy authorisatie, tool parameter checks.
• Integration: model call stub, tool execution met test data, output normalization.
• Golden set: vaste prompts met verwachte uitkomstklassen (niet alleen exact string match).
• Safety tests: adversarial prompts voor prompt injection en policy bypass pogingen.

Evaluatie metrics die werken

• Policy adherence: percentage outputs dat policy followt.
• Tool correctness: tool calls die parameters correct valideren.
• Context correctness: juiste bron selectie (bij RAG) en geen cross-tenant leaks.
• Latency en cost: tokens, aantal calls, timeouts.

CI pipeline voorbeeld (command first)

Een voorbeeld van een job indeling die je kunt vertalen naar je stack:

pytest tests/unit
pytest tests/integration
python -m eval.run --suite golden --out artifacts/eval
python -m eval.run --suite safety --out artifacts/safety
python -m eval.report --fail-on policy_fail --fail-on tool_schema_fail

Wat je als eerste eval-beslissing maakt

• Maak “policy fail” een harde fail in CI.
• Maak tool schema errors ook hard fail.
• Laat text similarity tests als waarschuwing, niet als blokkering, tenzij je heel string-gebonden bent.

6) AI web operationeel: observability, kosten, en veilige deploys

Na build komt de realiteit: latency spikes, provider regressies, en incidentele prompt injection pogingen. Zet observability vroeg.

Observability minimum

• Tracing: request ID end to end.
• Logs: policy decisions, tool calls, error categories.
• Metrics: p95 latency, model tokens, tool call counts, throttling rate.
• Dashboards: per tenant, per route, per model.

Kosten beheersen

AI web kosten zijn meestal lineair in tokens, en exponentieel in retries en tool loops. Doe:

• Max input size per request.
• Max output tokens.
• Tool call budget.
• Backoff en circuit breakers op provider errors.

Veilige deploy strategie

• Blue green of canary voor de AI backend routes.
• Feature flags voor nieuwe prompts, nieuwe tools, en nieuwe retrieval indices.
• Laat evaluatie suite draaien op staging data.

Als je specifiek API security en modelkeuzes wil operationaliseren, helpen deze contextpagina’s:

• Open AI online gebruiken: API, modellen en security
• OpenAI AI: praktische gids voor API, modellen en security
• AI Open: praktische handleiding voor API, security
• AI online: direct bouwen met modellen, API en security

7) Veelgemaakte fouten (en hoe je ze voorkomt)

• Key leak: API key in frontend, in logs, of in error traces. Gebruik environment variables en secret management. (help.openai.com)
• Broken object authorization: tool of retrieval accepteert resource IDs zonder server-side authorisatie. Volg OWASP’s focus op authorization. (owasp.org)
• Geen rate limits: onbeperkte requests, onbeperkte tokens, of onbeperkte tool loops.
• Geen parameter validatie: tool parameters gaan ongesanctioneerd door, waardoor model output directe systeemactie wordt.
• Evaluatie alleen in de hand: geen golden set, geen safety suite, geen regressie gating.

“Maar het werkt toch in demo”

Demo’s hebben meestal: kleine users, gecontroleerde input, en weinig adversarial testen. AI web krijgt in het wild input die je niet kunt voorspellen. Daarom is de evaluatie suite plus policy checks de kern.

Conclusie: AI web bouwen zonder spijt achteraf

AI web is niet “een chatbox met een model”. Je bouwt een backend-first stack met strikte auth en authorisatie, veilige secret handling, server-side tool governance, en een evaluatie loop die regressies stopt. Als je vandaag begint, doe dit in volgorde:

1. Definieer je backend contract en whitelists voor capabilities en tools.
2. Implementeer auth, object-level authorisatie, en rate limiting voor elke AI route.
3. Beveilig API keys met environment variables en secret management. (help.openai.com)
4. Maak tool execution server-side en valideer tool parameters altijd.
5. Bouw golden tests en safety tests, draai ze in CI en gate op policy fail.

Als je nog een stap terug wil naar bouwblokken en praktische structuren, lees ook elementsofai uitgelegd voor engineers: bouwblokken. En als je eerst het geheel wil kaderen naast modellen en data, zie AI market uitgelegd voor engineers: kansen, modellen, data.