AI web: bouw, verbind en beveilig je AI-app (praktisch)

Antwoord: “AI web” betekent, je webapp uitbreiden met een LLM die je backend aanstuurt. Bouw het als pipeline: (1) frontend vraagt, (2) backend valideert en beperkt, (3) LLM gebruikt tools via een server-side API (bij voorkeur OpenAI Responses), (4) je persist en test, (5) je beveiligt tegen prompt injection, datalekken en misbruik. Hieronder staat een concrete opzet met code-achtige commando’s, plus security die je niet overslaat.

1) Wat is “ai web” in de praktijk (en wat niet)

Praktisch gezien is “ai web” geen losse AI-widget. Het is een webtoepassing waarin een LLM onderdeel is van je request loop. Er zijn grofweg drie niveaus:

Chat UI: tekst input naar model, tekst output terug.
Tool-gebonden AI: model roept functies aan om data op te halen, berekeningen te doen, of acties te starten (bijvoorbeeld ticket aanmaken).
Agent in een web context: model navigeert stappen via tools, met regels, limieten en observability.

Wat je meestal niet wil onder “ai web”:

Direct model calls vanaf de browser zonder server-proxy (token leakage, misbruik, geen rate limiting).
Onbeperkt “prompt passthrough” van user content naar tools zonder validatie.
Geen logging, geen evals, geen guardrails.

Als je al begint met een OpenAI-achtige stack: OpenAI heeft de Responses API als centrale interface gepositioneerd en begeleidt migratie vanuit Chat Completions. (developers.openai.com)

2) Referentie-architectuur voor AI web (laag voor laag)

Gebruik deze minimale stack, zodat je snel bouwt en later niet alles hoeft te slopen:

Frontend: UI, input validatie op client, maar echte checks op server.
Edge of backend gateway: één endpoint per use-case. Auth, rate limiting, logging, tool authorisatie.
LLM layer: server-side call naar Responses API, met tool calling.
Tooling: interne functies met expliciete schema’s, timeouts, retries.
Data layer: caching waar het kan, opslag van chats of events waar het moet.
Eval en observability: meet tokens, latency, success rate, tool error rate, en prompt injection triggers.

2.1 Endpoint contract (wat moet je API precies doen)

Maak één endpoint, bijvoorbeeld:

POST /api/ai-web/ask
Request body: { userId, conversationId, prompt, contextRefs, desiredMode }
Response: { outputText, toolEvents, usage, traceId }

Belangrijk: conversationId is alleen een key voor jouw opslag, niet “vertrouw op de client dat de context klopt”.

2.2 LLM call keuzes: Responses vs legacy

OpenAI positioneert de Responses API als de toekomstige richting voor agentic en reasoning workflows. (developers.openai.com)

Je hoeft niet dogmatisch te zijn, maar kies één pad en maak migratie later niet ingewikkeld. Bij OpenAI is ook expliciet een migratiegids beschikbaar. (developers.openai.com)

3) Bouwblok: een werkende “ai web” ask flow (tool calling inbegrepen)

Doel: user prompt gaat naar de LLM, de LLM kan tools gebruiken, de backend voert tools uit en geeft het eindantwoord terug.

3.1 Tool model: definieer functies met strakke input

Je tool signature is je security boundary. Denk in schema’s met minimale velden.

Voorbeeld tools (conceptueel):

get_customer_profile(customerId)
search_docs(query, limit)
create_ticket(subject, severity)

Regels:

Beperk wat de LLM kan lezen of schrijven per user/role.
Valideer inputs server-side, ook als de LLM “het netjes invult”.
Gebruik timeouts en circuit breakers voor tools.

3.2 Request flow met streaming (browser en server)

Frontend streaming kan, maar doe het via je eigen backend stream, niet door direct model events naar de browser te “fan-outen”.

Als je fetch gebruikt in de browser: onthoud dat fetch() de promise niet “reject” bij HTTP error statuses zoals 404, je moet zelf response.ok checken. (developer.mozilla.org)

Frontend patroon (kort):

// frontend
const res = await fetch('/api/ai-web/ask', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify(payload)
});
if (!res.ok) throw new Error('Bad status');
// lees stream of json

3.3 LLM call: Responses API basisconcept

De Responses API is gedocumenteerd, inclusief het basisidee dat je model responses aanroept met text en tool calls. (developers.openai.com)

Praktisch patroon:

Je stuurt de user prompt plus een system instructie (jouw regels).
Je geeft tool definitions mee.
Je verwerkt tool call requests en levert tool outputs terug aan het model.
Je eindigt wanneer het model een eindantwoord produceert.

Lengte beperken: OpenAI noemt dat je de response length expliciet kan sturen, en dat dit ook helpt voor kosten en latency. (help.openai.com)

3.4 Concrete workflow: prompt, retrieval, antwoord

Minimal viable “ai web” die goed presteert:

Input: user prompt.
Retrieval: zoek relevante docs of context via een tool.
Compose: system regels + retrieved snippets + user prompt.
LLM: model antwoord, maximaal X tokens, tool calls alleen als nodig.

Pro tip: als je retrieval misgaat, krijg je hallucinations. Dus log retrieval: welke bronnen, welke scores, welke tokens in context.

4) Security voor ai web: prompt injection, datalekken, misbruik

Als je ai web bouwt zonder security, ga je later “patchen”. Patchen werkt slecht bij prompt injection. Bouw in tegenmeasures vanaf dag 1.

4.1 Prompt injection: behandel user en web content als onbetrouwbaar

OWASP beschrijft prompt injection in de context van LLM toepassingen, waaronder het idee dat inputs instructies kunnen manipuleren die anders niet bedoeld zijn. (owasp.org)

Mitigaties die in ai web direct impact hebben:

Scheiding van rollen: system rules blijven system, user content blijft user.
Tool gating: laat het model geen tools aanroepen buiten een whitelist per endpoint en per user role.
Content filtering: strip of label tekst afkomstig van web sources als “untrusted instructions”.
Context caps: beperk context window en lengte, zodat context truncation je regels niet vernietigt.

Laat je LLM niet bepalen of hij extra data mag lezen, dat moet je backend beslissen.

4.2 Classic web security, maar dan in je toollaag

Veel aanvallen lijken op gewone injection. OWASP heeft algemene guidance over injection preventie, inclusief het belang van untrusted input flow naar gevaarlijke sinks. (cheatsheetseries.owasp.org)

In ai web betekent dat:

Gebruik parameterized queries voor database calls.
Command execution via shell vermijden; nooit tool input direct naar een OS command.
Output encoding voor elke UI context.

4.3 Rate limiting, auth en budgetten

LLM misbruik is een kostenprobleem en soms ook een data probleem.

Rate limit per userId en per IP (en per tenant).
Auth verplicht voor “tool-enabled” endpoints.
Budget per request: maximaal tokens en maximaal tool calls.

OpenAI noemt expliciet dat response length sturen helpt voor kosten en latency. (help.openai.com)

4.4 Observability: je wil traces, niet alleen logs

Minimale set:

traceId per request.
LLM usage: input tokens, output tokens (waar beschikbaar).
Tool events: naam, input hash, duur, status.
Failures: timeouts, schema errors, parsing errors.

Daarnaast: voeg een “prompt injection detector” laag toe die heuristisch prioriteert op verdachte patronen, en maak een manual review queue.

5) Performance en kosten: tokens, caching, en micro-architectuur

AI web wordt duur door ongedefinieerd gedrag. Maak kosten voorspelbaar.

5.1 Tokens beheren: context en output caps

OW/LLM token guidance: OpenAI beschrijft hoe token usage kan worden gemeten en dat je op tokens moet sturen in plaats van alleen zichtbare response length. (help.openai.com)

Praktisch:

Stuur een strikte output cap.
Maak context retrieval slim: top K, korte snippets.
Gebruik summarization alleen gecontroleerd, met evals.

5.2 Caching waar het echt werkt

Caching werkt vooral op retrieval en deterministische tool calls:

Docs retrieval op (tenantId, query, topK).
Klantprofiel op (customerId, etag).
Model answers alleen als je prompt varianten beperkt en je geen persoonlijkheid wil.

5.3 Latency: paralleliseer tool calls, maar controleer races

Als je meerdere tools nodig hebt, paralleliseer dan retrieval calls, maar zorg dat tool outputs niet door elkaar gaan bij compose.

Regel: tool results moeten in een deterministische volgorde in de context.

5.4 Streaming tuning

Streaming verlaagt perceptie van latency. Maar het is extra complexiteit:

Stop streaming bij timeouts en schema errors.
Buffer events zodat je UI niet flickert.
Houd server memory bounded, zeker bij meerdere gelijktijdige requests.

6) Voorbeeld eerst: concrete use-cases en snelle bouwroutes

Als je snel wil leren door te bouwen, pak een use-case die je meteen aan tools en security koppelt. Hieronder staan relevante routes:

6.1 Snelle projectstart: “ask met retrieval”

Scope: 1 use-case, 2 tools, 1 evaluator.

Tool 1: search_docs
Tool 2: get_doc_snippet of direct in search
Geen writes, alleen read
Evalueer op 20 vaste queries

Daarna pas uitbreiden naar writes (tickets, acties).

6.2 “Agent”-achtig, maar beheerst

Wil je web navigation of meerdere stappen? Doe het als een deterministic state machine in je backend, niet als “laat de LLM alles doen”.

Staten: plan, fetch, verify, respond
Elke state heeft eigen tool set
Beperk iteraties, bijvoorbeeld max 3 tool rounds

Conclusie: ai web als engineering, niet als losse prompt

“ai web” bouwen is drie dingen goed doen: (1) server-side architectuur met duidelijke endpoint contracten, (2) tool calling met schema’s en gating, (3) security en kostencontrole als default. Als je dit op dag 1 als engineering randvoorwaarden implementeert, kun je daarna snel itereren op quality via retrieval, evals en latency tuning.

Als je nu één volgende stap wil: start met “ask met retrieval” (read only), voeg logging en evals toe, en pas daarna writes en agent states. Daarmee voorkom je dat je later systemen moet herontwerpen om prompt injection en misbruik te beperken.