AI web betekent: een webapp die AI gebruikt via API’s (chat, RAG, tools, agents) met een echte engineering aanpak voor gegevens, security, kosten en evaluatie. Start met een schema: (1) UI, (2) backend gateway, (3) modelprovider, (4) tools met toegangscontrole, (5) retrieval, (6) observability en testen. Dit artikel geeft je een concreet bouwpad met code en controlepunten.
AI web in één diagram: wat je moet bouwen
Als je “ai web” zegt, bedoel je meestal een stack waarin de browser niet direct met de modelprovider praat, maar via jouw backend. Dat is niet alleen “best practice”, het is waar je security, rate limiting, logging en tool-executie controleert.
Minimale referentie-architectuur
- Frontend: chat UI, streaming responses, upload of integraties (optioneel).
- Backend API: gateway die requests validereert, auth toepast, prompt samenstelt, tools aanroept, en alleen dan bij de modelprovider uitkomt.
- Model laag: provider API (OpenAI of alternatief), met duidelijke output constraints (JSON schema, lengte, policy).
- Tools: functies met een whitelist (bijvoorbeeld zoeken, fact-checking, ticket aanmaken) en harde input validatie.
- Retrieval (optioneel maar vaak nodig): indexeren, embeddings, zoekquery’s, en context trimming.
- Observability: correlatie-IDs, tracing, audit logs, kosten per request.
Waarom de backend gateway centraal staat
Omdat prompt injection, datalekken, tool misuse en policy omzeiling vrijwel altijd ontstaan wanneer de model toegang krijgt tot dingen die je niet hard begrenst. OWASP publiceert een specifiek Top 10 kader voor LLM applicaties, inclusief categorieën rond prompt injection, dataverlies en andere risico’s. Dat kader is een goede checklist voor jouw “AI web” veiligheidslaag. (owasp.org)
Recept: een ai web endpoint dat veilig en voorspelbaar is
Je kunt in de praktijk sneller bouwen als je één endpoint als “contract” definieert en daar alles aan ophangt. Hieronder een pattern dat werkt voor chat en tool-gedreven flows. Voor de modelprovider gebruik je in elk geval een API die je response kunt sturen en controleren. OpenAI documenteert bijvoorbeeld hoe je lengte en output beheerst, zodat je kosten en latency niet laat ontsporen. (help.openai.com)
Request schema (voorbeeld)
POST /api/ai-web/chat
Content-Type: application/json
{
"conversation_id": "...",
"user_message": "...",
"session": {
"user_id": "...",
"plan": "pro"
},
"options": {
"max_output_tokens": 400,
"mode": "tool_use"
}
}Backend flow (stappen)
- Auth: verifieer sessie, gebruikersrechten, en tenant.
- Input validatie: user_message normaliseren, lengte limieten, rate limit.
- Context build: retrieval halen (optioneel), plus system/policy prompts.
- Model call: stuur messages en constraints (max tokens, output format).
- Tool gating: als de model een tool request produceert, valideer arguments en check rechten.
- Audit log: log tool calls, retrieval queries, model parameters (geen secrets).
- Output: stream naar frontend, of verzamel en retourneer JSON.
Voorbeeld code, TypeScript, pseudo “gateway”
Geen SDK magic, alleen de kern: validatie, tool whitelist, en JSON output discipline.
// tools.ts
export type ToolName = 'search_docs' | 'create_ticket';
export const toolWhitelist: Record<ToolName, (args: unknown, ctx: any) => Promise<any>> = {
search_docs: async (args, ctx) => {
// TODO: valideer args expliciet
return { hits: [{ title: '...', snippet: '...' }] };
},
create_ticket: async (args, ctx) => {
// TODO: valideer rechten + args
return { ticket_id: 'TCK-123' };
}
};// ai-web route (schets)
import { toolWhitelist } from './tools';
function assertJsonObject(x: unknown): asserts x is Record<string, any> {
if (!x || typeof x !== 'object' || Array.isArray(x)) throw new Error('invalid json');
}
export async function postAiWebChat(req: Request) {
const body = await req.json();
// 1) auth + rate limit (pseudo)
const ctx = { user_id: body.session.user_id };
// 2) input limits
if (!body.user_message || body.user_message.length > 5000) {
return new Response('bad request', { status: 400 });
}
// 3) context (optioneel)
const retrievalContext = null; // TODO
// 4) model call
// Belangrijk: forceer output format waar mogelijk
const modelOutput = await callModel({
mode: body.options.mode,
conversation_id: body.conversation_id,
user_message: body.user_message,
retrievalContext,
max_output_tokens: body.options.max_output_tokens ?? 400
});
// 5) tool execution
// Neem aan dat callModel een tool-plan teruggeeft in JSON.
assertJsonObject(modelOutput);
if (modelOutput.tool_calls) {
for (const t of modelOutput.tool_calls) {
const name = t.name;
if (!(name in toolWhitelist)) throw new Error('tool not allowed');
const fn = toolWhitelist[name as keyof typeof toolWhitelist];
const args = t.args;
// Hard validate args per tool
// Controleer ook user rechten via ctx
await fn(args, ctx);
}
}
// 6) return
return new Response(JSON.stringify(modelOutput), {
headers: { 'Content-Type': 'application/json' }
});
}Output constraints zijn geen “nice to have”
Als je wil dat je UI stabiel is, dwing je output: max tokens, structuur (JSON schema), en defensieve parsing. OpenAI bespreekt expliciet dat het beperken van output lengte helpt voor kosten, latency en relevantie, en dat tokenlimieten bij de modeldocumentatie horen. (help.openai.com)
Agents en tools: ontwerp voor minimale permissies
In een echte ai web-app wil de gebruiker meestal acties, niet alleen tekst. Denk: “zoek in docs”, “maak een ticket”, “vat een pull request samen en voeg commentaar toe”. Dat is tools en agent gedrag.
Tool contract: whitelisten, typen, en scope
- Whitelist per tool: niet “execute arbitrary function”.
- Argument schema: strikt, per tool, met server-side validatie.
- Scope checks: user mag alleen binnen zijn tenant, workspace, en resource scope werken.
- Idempotency: acties zoals “create_ticket” moeten bij retries dezelfde intent kunnen afhandelen.
- Audit: log tool name, input hash, en resultaat-ID.
Prompt injection mitigation in de praktijk
OWASP noemt prompt injection als een kernrisico bij LLM applicaties, en de OWASP Top 10:2025 publiceert details en mitigaties per risicocategorie. Gebruik dit als checklist: welke data komt van de gebruiker, welke van retrieval, en waar kan de model outputs misbruiken? (owasp.org)
Concrete implementatie: “tool chooser” zonder fantasy
Een gangbaar patroon is: de model produceert een tool-call plan in JSON, jouw backend valideert en execute. Maak het plan expres beperkt:
- Geen willekeurige URLs.
- Geen commando’s als tekst, alleen tool name en argumenten volgens schema.
- Hard limit op aantal tool calls per request (bijvoorbeeld max 3).
Voorbeeld: tool call plan JSON
{
"final": null,
"tool_calls": [
{ "name": "search_docs", "args": { "query": "reset password" } }
],
"max_tool_calls": 3
}Jij voert uit, voegt retrieval results toe aan de volgende modelronde, en produceert dan de eindtekst of de eind-JSON.
RAG voor ai web: retrieval, trimming, en evaluatie
Als je ai web-app antwoordsnelheid en correctheid nodig heeft, gebruik retrieval. Maar RAG is ook waar veel teams over de rand gaan met context stuffing, datalekken, en irrelevantie. Bouw daarom RAG als een pipeline, niet als “we gooien alle stukken in de prompt”.
RAG pipeline (compact)
- Ingest: crawl of sync bronnen, chunking, metadata (tenant, rechten, bron, datum).
- Index: embeddings, opslag, en filtering op metadata.
- Query: user_message plus intent routing.
- Retrieve: similarity search met hard filters (tenant, permissions).
- Rerank (optioneel): betere volgorde, lagere noise.
- Trim: context window budget, top-k of tokens budget.
- Answer: model met citations of bron-ID’s (als je dat wil).
Context trimming als engineering control
- Budgeteer tokens voor context apart van output.
- Gebruik max aantal passages, plus min score threshold.
- Weiger passages die niet binnen rechten vallen, ook al zijn ze semantisch relevant.
Evaluatie: meet wat je wil verbeteren
In ai web is “werkt voor mij” niet genoeg. Je wil minimaal:
- Faithfulness: antwoord klopt met retrieval.
- Safety: model lekt geen verboden info.
- Latentie: p95 end-to-end, inclusief retrieval en tool calls.
- Kosten: tokens per request, tool call overhead.
Als je een praktische aanpak zoekt voor bouwen, tooling en evaluatie, past dit waarschijnlijk bij je workflow: AI Lab: praktische aanpak, tooling en evaluatie (2026).
Provider keuze en integratie: kies een API contract
“AI web” kan met meerdere providers. De werkelijke engineering uitdaging is minder “welk model is beter”, en meer “welk API contract is consistent met jouw tool en output constraints”.
Modelprovider en response API’s
OpenAI heeft een Responses aanpak die in documentatie vaak centraal staat voor interacties met model outputs. Voor exacte endpoint details moet je de officiële docs volgen, maar het punt voor jouw architectuur is: ontwerp je code zo dat provider-specifieke details in één adapterlaag zitten.
Adapter pattern, praktisch
// adapter.ts
export interface AiAdapter {
generateAndOptionallyTools(input: {
conversation_id: string;
user_message: string;
retrievalContext: any;
max_output_tokens: number;
}): Promise<{
tool_calls?: Array<{ name: string; args: any }>;
final?: string;
raw?: any;
}>
}Dan kun je providers wisselen zonder dat je backend tools, auth, en RAG logica herschrijft.
Google AI Studio en full-stack AI web
Als je liever met een web-based dev omgeving werkt, documenteert Google AI for Developers hoe je met Google AI Studio web apps kunt bouwen met full-stack runtimes en hoe de integraties met server-side benadering werken. (ai.google.dev)
Gebruik dit als inspiratie, maar laat je security nog steeds door je eigen backend controls bepalen, ook als je een studio interface gebruikt.
Als je OpenAI gebruikt: bouw eerst je online flow
Wil je meteen een werkend pad voor “online gebruiken”, stappen en tools, dan is dit relevant: OpenAI online gebruiken: stappen, tools en bouwtips.
Security checklist voor ai web (hard, niet vaag)
Je hebt OWASP als kader, maar je moet het vertalen naar concrete controles in code en deploy. Hieronder een checklist die je direct kunt implementeren.
Checklist per risicocluster
- Prompt injection: scheid instructies van data, sanitize tool inputs, enforceer tool argument schemas, weiger onbedoelde instructies.
- Data en model poisoning: verifieer ingest bron, maak training gescheiden van retrieval, en bewaak welke data in index komt.
- Supply chain: pin dependencies, controleer build artifacts, en beperk permissions van CI jobs.
- Auth en authorization: RAG filtering op tenant en permissions, tools checken rechten op resource ID’s.
- Output safety: gebruik refusals, enforceer JSON-only waar nodig, en bouw een content policy laag.
- Logging: log intent en IDs, niet onnodige secrets of volle PII.
Het OWASP LLM Top 10:2025 document is expliciet bedoeld om risico’s en mitigaties over de lifecycle te structureren. (owasp.org)
Minimale security implementaties die je vandaag nog kunt doen
- Tool args schema’s: hard validate, geen “string maps” die later alsnog worden geïnterpreteerd.
- Max tool calls: per request en per sessie.
- Rate limiting: per gebruiker en per IP, plus backoff.
- Output caps: max tokens en lengte limieten.
- RAG permissions filtering: retrieval moet rechten meenemen als hard filter.
Bouwpad in 7 stappen, van nul naar productie
Je wil niet lezen, je wil bouwen. Dit is een stappenplan dat je in een week of twee kunt doorlopen afhankelijk van scope.
Stap 1: definieer het AI web contract
- Wat is een request? (user_message, session, options)
- Wat is een response? (stream tekst, of JSON met tool plan en final output)
Stap 2: maak de backend gateway
- Auth en rate limiting
- Prompt builder
- Model adapter
Stap 3: tool whitelist en input validatie
- Maak 2 tot 5 tools voor je eerste versie
- Schrijf server-side validators
Stap 4: voeg retrieval toe (alleen als het nodig is)
- Index klein starten
- Filtering op tenant en permissions
Stap 5: observability en kosten
- Log token usage, latency buckets
- Correlatie-ID’s in frontend en backend
Stap 6: evaluatie set opbouwen
- Maak testcases met verwachte output criteria
- Test tool calls, safety, en retrieval fidelity
Stap 7: herhaal met gecontroleerde veranderingen
- Provider of prompt wijzigingen via feature flags
- Model output constraints eerst, tuning later
Extra context en gerichte bouwinfo
Als je vooral architectuur en veiligheid wil combineren, helpt dit: a ai uitgelegd: bouwbare architectuur, APIs en veiligheid.
Voor een agent-achtige chat ervaring met focus op snel bouwen en veilig gebruik, kijk hier: Chai chat met AI friends: snel bouwen en veilig gebruik.
Voor architectuur plus migratie en API tooling patterns zijn deze relevant: Chat AI Open: bouw, API, tools en migratie (2026) en OpenAI AI: Responses API, modellen en bouwtips voor 2026.
Als je wil kaderen wat “open” betekent, licensing en API patterns, dan past: AI Open uitgelegd: betekenis, licensing en API patterns.
Voor een overzicht van engineer-proof stappenplan: ElementsofAI: het engineer-proof overzicht en stappenplan.
En als je een breder beeld wil van “ai web” tools, agents, en een praktische gids: AI online: praktische gids voor bouwen, tools en agents.
Voor platform en markt context, bottlenecks en een bouwpad: AI market in 2026: kansen, bottlenecks en bouwpad.
Veelgemaakte fouten bij ai web (en de fix)
- Fout: frontend direct naar modelprovider sturen.
Fix: zet een backend gateway neer met auth, rate limiting, tool gating en logging. - Fout: “tools” als vrije tekst commando’s.
Fix: tool calls als JSON, strikt schema, hard validate en whitelisten. - Fout: geen output caps, geen streaming budget.
Fix: max output tokens, lengte limieten, en controleer latency p95. - Fout: RAG zonder permissions filtering.
Fix: metadata filters als hard constraints in retrieval. - Fout: “eval” is alleen keyword match.
Fix: testcases op faithfulness, tool correctness, safety en refusals.
Conclusie: ai web bouw je als software, niet als demo
Een succesvolle ai web-app is geen UX laag met een model call, maar een engineering stack met een contract, een backend gateway, tool whitelisting, RAG met permissions, en evaluatie die latency, kosten en veiligheid meet. Begin met een minimaal endpoint, dwing output constraints af, voer tools alleen via server-side validatie uit, en breid pas uit met retrieval en agents als je tests en observability klaar zijn.
Als je één volgende stap wil: kies 2 tools, bouw de gateway, forceer JSON schema output, voeg tool gating toe, en maak daarna pas je RAG en evaluatieset. Dat is de kortste route naar “werkt, blijft werken, en is niet triviaal te misbruiken”.
