Artificial intelligence in de praktijk: stack, veiligheid

Artificial intelligence in de praktijk: stack, veiligheid

Geschreven door

in

Artificial intelligence in de praktijk, snel en controleerbaar: kies een use case, modelleer risico, ontwerp een data- en evaluatielus, bouw met guardrails en observability, en maak compliance haalbaar met een EU AI Act check. Hieronder krijg je een direct toepasbaar bouwplan, inclusief technische keuzes, voorbeeld-API flows en veiligheidsmaatregelen.

1) Wat je met artificial intelligence gaat bouwen (en wat niet)

De snelste route naar waarde is niet “welk model”, maar “welke eigenschap” die je nodig hebt. Maak een korte beslissingstabel voor je AI systeem, bijvoorbeeld:

  • Input type: tekst, code, afbeeldingen, audio.
  • Output type: antwoord, extractie, classificatie, planning, tool call, generatie.
  • Interactie: single-shot, chat, agent met tools, realtime streaming.
  • Betrouwbaarheid: moet je kunnen terugvallen op regels, retrieval, of menselijke review?
  • Risico: kan output schade veroorzaken, bijvoorbeeld juridisch, medisch, financieel, of privacygevoelig?

Voorbeeld: je wil “klantvragen beantwoorden” met policy-teksten. Dan wil je waarschijnlijk RAG plus strikte afhandeling van onbekende vragen, i.p.v. vrij genereren uit je eigen modelrepresentatie.

Risico eerst, model later

Je kunt artificial intelligence technisch prima maken en toch juridisch of operationeel falen. Voor de EU geldt een risicogebaseerde structuur in de Artificial Intelligence Act. De verordening trad in werking op 1 augustus 2024 en is 2 jaar later volledig van toepassing op 2 augustus 2026, met uitzonderingen voor specifieke bepalingen. (commission.europa.eu)

Praktisch betekent dit: classificeer je systeem vroeg. Als je systeem onder “high-risk” valt, heb je extra eisen rond risicomanagement, documentatie, toezicht en levenscyclusbeheer. De kern: ontwerp engineering als audit trail, niet als bijzaak.

2) Architectuur die schaalbaar blijft: van prompt naar systeem

Een production-ready artificial intelligence stack bestaat meestal uit dezelfde bouwstenen. Hieronder een compacte referentiearchitectuur die je kunt aanpassen.

2.1 Data en kennis: retrieval boven gokken

Als je beslissingen of antwoorden moeten aansluiten op bedrijfskennis, is Retrieval-Augmented Generation (RAG) meestal de baseline. Bouw het als een pipeline:

  1. Ingest: bronteksten opschonen, chunking, metadata toevoegen.
  2. Index: embeddings opslaan, vector search koppelen.
  3. Retrieval: top-k, rerank, en contextlimieten.
  4. Grounding: model mag alleen antwoorden op basis van retrieved context, of expliciet “ik weet het niet” doen.

Praktische tip: maak retrieval reproduceerbaar. Log query, retrieved ids, scores en context tokens, zodat je later evaluatie en regressies kunt doen.

2.2 Modellaag: kies per taak, niet per hype

De modelkeuze hoort af te hangen van je constraints:

  • Latency: realtime streaming, of offline batch.
  • Cost: input-output token ratio en caching mogelijk?
  • Tools: heb je function calling nodig, of pipeline met aparte modellen?
  • Control: kun je deterministische stappen afdwingen (schema validatie, regex, retries)?

Als je toch API’s gebruikt, plan dan caching, rate limiting en retry policy vanaf dag 1. Je wil geen “mystery costs” door herhaalde prompts zonder stabilisatie.

2.3 Agentlaag: tools alleen met een contract

Bij agenten met tools is de gouden regel: tools mogen alleen aangeroepen worden met een goed gedefinieerd input schema en een validatiepad. Dus:

  • Gebruik structured outputs (JSON schema of vergelijkbaar).
  • Valideer server-side, weiger bij invalid JSON of semantische onzin.
  • Laat de agent geen “free form” acties doen, maar via expliciete capabilities.

Voorbeeld (conceptueel): model produceert tool call arguments volgens een schema; je backend valideert, voert uit, en geeft alleen de relevante tool output terug aan het model.

3) Veiligheid en guardrails: minimaliseer schade, maximaliseer controle

De meeste artificial intelligence incidenten komen niet door “het model is dom”, maar door ontbrekende controle rond output, input en omgeving. Bouw daarom guardrails op drie niveaus: prompt-level, policy-level, en runtime-level.

3.1 Content policy en output gating

Voor runtime gating heb je minimaal nodig:

  • PII detectie: stuur output door een detector, redigeer of blokkeer.
  • Refusal policy: als retrieval geen basis levert, forceer “niet zeker” of “vraag om bron”.
  • Juridisch en financieel gedrag: laat het model geen harde claims doen zonder disclaimers en onderliggende bronvermelding.

In guardrail-implementaties werkt “dezelfde configuratie, zowel in dev als prod” het best. Sommige stacks bieden guardrails als library plus productiecontainer, bijvoorbeeld via NVIDIA NeMo Guardrails, dat zowel developer-facing Python als een productie-ready microservice levert. (docs.nvidia.com)

3.2 Prompt injection, jailbreaks, en tool misbruik

Neem aan dat de gebruiker of de retrieved context aanvallen bevat. Dan moet je:

  • Untrusted context apart markeren en model expliciet laten negeren waar het niet klopt.
  • Tool authorization toevoegen: niet alles mag altijd.
  • Rate limits en budgets per gebruiker of tenant instellen.

3.3 Observability als veiligheidsfeature

Je wil niet alleen “logs”, je wil bewijslast. Log voor elke request:

  • prompt en input features (met redactie voor PII)
  • retrieval context ids en scores
  • tool calls, arguments, tool results
  • model output en postprocessing stappen
  • final safety verdict (allow, deny, redact)

Daarna bouw je dashboards op meetwaarden, zoals safety rejects per type, hallucinatie-indicatoren (bron mismatch), en regressies per modelversie.

4) Evaluatie en regressietests: maak kwaliteit meetbaar

Als je kunstmatige intelligentie niet test, test je uiteindelijk je klanten. Bouw een evaluatielus die je in CI of periodiek kunt draaien.

4.1 Metrics die echt iets zeggen

Voor technische teams werken deze categorieën het best:

  • Task accuracy: exact match, F1, of rubric scoring.
  • Groundedness: verwijst output naar retrieved context? Zijn claims traceerbaar?
  • Schema validity: percentage valid JSON, valid tool args.
  • Safety: rate op refusals, PII leakage, policy violations.
  • Latency en cost: p95 latency, gemiddelde token usage.

4.2 Golden set plus adversarial set

Maak twee datasets:

  • Golden set: bekende goede gevallen, inclusief edge cases.
  • Adversarial set: prompt injection, jailbreak, en tool misbruik pogingen.

Dan kun je bij model updates, retrieval tuning, of prompt wijzigingen snel zien of de kwaliteit of veiligheid verslechtert.

4.3 Evaluatie als code

Gebruik een evaluatiescript dat reproduceerbaar is, inclusief seed waar relevant, vaste retrieval parameters, en opslag van alle tussenstappen. Hou de evaluatie los van je runtime pad, zodat je niet productiegedrag beïnvloedt.

5) EU AI Act, compliance en engineering: wat je nu al kunt doen

Je hoeft niet te gokken. De EU AI Act is per 1 augustus 2024 in werking getreden en wordt 2 jaar later volledig van toepassing op 2 augustus 2026, met uitzonderingen voor specifieke bepalingen. (commission.europa.eu)

Omdat je technisch publiek of klanten beïnvloedt, is compliance niet alleen juridisch. Het is engineering discipline in documentatie en lifecycle management.

5.1 Praktische compliance checklist voor teams

  • Systeemdefinitie: beschrijf wat je AI systeem doet, input, output, en beoogd gebruik.
  • Risico-inschatting: waarvoor kan het misgaan, en welke mitigaties zijn ingebouwd?
  • Datagovernance: waar komen datasets vandaan, welke licenties, welke kwaliteit?
  • Logging en documentatie: kun je later aantonen waarom je systeem besloot zoals het deed?
  • Wijzigingsbeheer: hoe ga je om met updates aan model, prompts, retrieval, en tools?

5.2 Timebox: wat je in 1 tot 2 sprints regelt

Als je tijd hebt, start klein maar effectief:

  1. Maak een risicoregister per use case.
  2. Leg een evaluatie-harnas vast (golden en adversarial set).
  3. Werk een audit-log schema uit met redactie voor PII.
  4. Leg je model en prompt versiebeleid vast (geen “latest” in prod zonder changelog).

6) Build routekaart, voorbeeld-eerst: van idee naar deployment

Hier is een directe route die je kunt volgen. Ik geef eerst het output eindresultaat, daarna de stappen.

Voorbeelddoel

Je bouwt een API endpoint dat:

  • input valideert
  • retrieval doet op policy docs
  • LLM antwoord genereert met grounding
  • output veilig gate’t (PII en policy)
  • alles logt voor evaluatie en compliance

Stap 1, contracten en schemas vastleggen

  • Definieer request schema, response schema, en tool schemas.
  • Schrijf downstream regels, bijvoorbeeld wat de UI wel of niet toont.

Stap 2, retrieval en grounding implementeren

  • Chunking beleid vastleggen.
  • Reranking inschakelen als relevance issues zichtbaar zijn.
  • Forceer “answer only from context” of “cite context ids” als je workflow dat toelaat.

Stap 3, guardrails inbouwen

  • Policy checks voor input en output.
  • Refusal gedrag wanneer context onvoldoende is.
  • Tool gating: alleen acties binnen allowed capabilities.

Stap 4, evaluatie draaien bij elke wijziging

  • Golden set scoring, schema validity, en safety metrics.
  • Regressietests voor prompt en retrieval wijzigingen.

Stap 5, deployment met budgetten en observability

  • Rate limits per tenant.
  • Cost budgets per request type.
  • Tracing, metrics, en alerts op safety denies en latency p95.

7) Handige vervolgstappen en stack keuzes

Als je stackkeuzes wil vergelijken of een roadmap wil bouwen, gebruik gerichte gidsen in plaats van losse blogposts. Deze passen goed bij een bouwplan dat security en regels meeneemt:

Conclusie

Artificial intelligence werkt pas goed als je het als systeem ontwerpt, niet als losse prompt. Laat risico het ontwerp sturen, bouw retrieval en grounding waar het moet, implementeer guardrails op input en output, en maak evaluatie en audit logs een first-class onderdeel van je pipeline. Voor EU compliance: houd de AI Act tijdlijn aan, met inwerkingtreding op 1 augustus 2024 en volledige toepasselijkheid op 2 augustus 2026, en vertaal dat naar engineering taken in documentatie, lifecycle updates en meetbare veiligheid. (commission.europa.eu)

Als je nu begint: pak één use case, maak een risicoregister, bouw een evaluatie-harnas, en implementeer output gating. Daarna pas uitbreiden naar agenten, complexere tools, en schaal.

Reacties

Geef een reactie

Je e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *