Generati

Program AI: van prompt naar productie (praktisch)

·

Dino Hensen
Program AI: van prompt naar productie (praktisch)

Program AI betekent: je vertaalt een AI-taak naar software-artefacten (prompts, tool calls, schema-outputs, validatie, tests, observability en security), zodat het systeem voorspelbaar werkt in productie. Start met structured outputs (json_schema), voeg tooling toe met strikte input validatie, en behandel prompts en model-output als onbetrouwbare input. Hieronder krijg je een voorbeeld-eerst aanpak, inclusief codepaden voor “programmeerbare” AI.

Antwoord eerst, daarna de aanpak

Als je een “program AI” systeem wil bouwen dat niet kapot gaat bij randgevallen, volg deze volgorde:

  1. Model output vastzetten met Structured Outputs, zodat je geen losse tekst hoeft te parsen.
  2. Contracten afdwingen (JSON Schema, strikte validatie, fallback flow).
  3. Tools inlijsten (whitelist tools, strikte parameters, least privilege).
  4. Testen als systeem (unit tests voor prompts en parsers, integratietests voor tool routing, red-teaming voor LLM aanvallen).
  5. Observeren en bijsturen (logging, cost controls, rate limits, policy checks).
  6. Beveiliging als vereiste (input sanitization, output encoding, permission checks, prompt-injection verdediging).

Waarom dit werkt: OpenAI’s API ondersteunt Structured Outputs via JSON Schema, zodat de output betrouwbaar aan een contract voldoet. (developers.openai.com)

Voorbeeld: “programmeerbare” AI met structured outputs

Doel: je wil dat het model altijd hetzelfde datatype teruggeeft. Niet “ongeveer dit”, maar exact een schema met velden die je code kan gebruiken.

Stap 1: definieer een outputcontract

Voorbeeld: een functie die een uservraag omzet naar een queryplan. Output bevat:

  • intent (enum)
  • filters (optioneel lijstje met sleutel-waarde)
  • riskFlags (lijst, bv. “PII”, “jailbreak”)
  • answer (korte toelichting voor UI)

In de praktijk maak je dit contract klein en stabiel. Hoe kleiner, hoe minder breekbaar.

Stap 2: API call met json_schema en strict

Onderstaande pseudocode gebruikt de gedachte uit OpenAI’s Structured Outputs guide: gebruik response_format met type: json_schema en strict: true. (developers.openai.com)

{
  "response_format": {
    "type": "json_schema",
    "json_schema": {
      "name": "query_plan",
      "schema": {
        "type": "object",
        "additionalProperties": false,
        "properties": {
          "intent": {"type": "string", "enum": ["search", "explain", "summarize"]},
          "filters": {
            "type": "array",
            "items": {
              "type": "object",
              "additionalProperties": false,
              "properties": {
                "key": {"type": "string"},
                "value": {"type": "string"}
              },
              "required": ["key", "value"]
            },
            "default": []
          },
          "riskFlags": {
            "type": "array",
            "items": {"type": "string"},
            "default": []
          },
          "answer": {"type": "string"}
        },
        "required": ["intent", "filters", "riskFlags", "answer"]
      }
    },
    "strict": true
  }
}

Stap 3: gebruik het contract als runtime check

Je code doet drie dingen:

  • Parseert de JSON.
  • Validatie faalt? Dan ga je naar fallback, bv. “vraag verduidelijking”.
  • riskFlags aanwezig? Dan blokkeer of beperk acties.
plan = call_model(...)
validate_json_schema(plan, QueryPlanSchema)
if "PII" in plan.riskFlags:
    return deny_and_guide_user()
route_to_tool(plan.intent, plan.filters)

Dit is “program AI”: je maakt het gesprek geen vrije tekst pipeline meer, maar een deterministisch contract plus een set gecontroleerde acties.

Tooling en agent routing: van tekst naar uitvoerbare acties

Zodra je tools toevoegt (zoeken, tickets aanmaken, DB calls, webhooks), krijg je een nieuw aanvalsvlak. “Program AI” betekent dus: je programmeert ook de controlelaag.

Ontwerpregel 1: tool whitelist, geen vrije tool names

Laat het model niet beslissen welke tool het “wel leuk vindt”. Je routering bepaalt welke tools beschikbaar zijn voor het huidige intent en context. Dan is de agent een dispatcher, geen universele shell.

TOOL_WHITELIST = {
  "search": ["kb_search"],
  "explain": ["kb_search", "doc_lookup"],
  "summarize": ["doc_lookup"]
}

allowed = TOOL_WHITELIST[plan.intent]
assert selected_tool in allowed

Ontwerpregel 2: strikte tool parameters met validatie

Voor elke tool definieer je een eigen schema. Niet alleen JSON Schema voor model-output, ook voor tool input. Als de tool input niet klopt, wordt de request geweigerd of naar “repair” gestuurd.

Ontwerpregel 3: permissions en least privilege

Als je tool “maak klantcontact aan” heeft, geef je de service-account alleen die rechten. Niet admin. Ook niet “API key met alles”.

Ontwerpregel 4: definieer een policy voor refusal en incomplete output

OpenAI’s Structured Outputs documentatie beschrijft dat je programmatic control krijgt om te detecteren of de response matcht of weigert, in lijn met de Structured Outputs aanpak. (openai.com)

In je program AI maak je dit een expliciete state machine:

  • OK, contract klopt
  • REFUSED, ga naar gebruiker uitleg of fallback
  • INVALID, repair of verduidelijking

Als je dit verder wil doortrekken richting web en end-to-end beveiliging, zie ook: AI web: bouw, verbind en beveilig je AI-app (praktisch).

Security en betrouwbaarheid: behandel het model als onbetrouwbaar

Een “program AI” systeem is geen prompt met extra stappen. Het is een security-critical applicatie waar model-output een niet vertrouwde input is.

Checklists en standaarden om je engineering te sturen

  • NIST AI RMF 1.0 biedt vrijwillige guidance voor AI risico management, bedoeld voor organisaties die AI ontwerpen, ontwikkelen, deployen of gebruiken. (nist.gov)
  • OWASP AI Security Verification Standard (AISVS) is een checklist voor het hele lifecycle traject, gemodelleerd op OWASP ASVS, met focus op AI applicaties. (owasp.github.io)
  • OWASP ASVS is een security verification framework voor moderne web applicaties, handig om je weblaag te onderbouwen. (asvs.owasp.org)
  • OWASP LLM security testing richtlijn behandelt red-teaming en dat je het hele systeem als attack surface ziet, inclusief prompt, retrieval pipeline, tools en permissies. (owasp.github.io)

Praktische dreigingen, praktische mitigaties

1) Prompt injection

Behandeling: scheid instructies van data. Zet tool inputs nooit direct om van user tekst naar admin acties. Gebruik content filtering op de tool-parameterlaag, niet alleen “in de prompt zeggen”.

2) Tool misbruik via model output

Behandeling: voer altijd parameter validatie uit, en routeer alleen naar whitelisted tools. Laat model niet bepalen welke rechten het gebruikt.

3) Onbetrouwbare data in retrieval

Behandeling: retrieval is ook input. Log retrieval bronnen, voeg confidence checks toe, en voer output policy checks uit voordat je actions triggert.

4) Datakwaliteit en drift

Behandeling: voeg test suites toe met vaste sets vragen, meet output contract failures, en doe regelmatige revalidatie van schema’s en prompts.

Testen als onderdeel van “program AI”

Minimal set tests:

  • Prompt unit tests: dezelfde input moet dezelfde contractvorm opleveren.
  • Schema contract tests: invalid JSON of ontbrekende velden moet altijd een voorspelbare fallback triggeren.
  • Tool integration tests: tool routing en parameter mapping moeten deterministisch zijn.
  • Security red-teaming: test jailbreak, prompt injection, data exfil poging via tools.

Als je AI testen en deployen in één lijn wil trekken, past ook: A AI: praktische gids voor bouwen, testen en veilig deployen.

Implementatiepatronen: architectures die schaalbaar blijven

Hier zijn patronen die je “program AI” rechtop houden, zelfs als prompts en modellen veranderen.

Patroon 1: Contract eerst, model daarna

Je begint met JSON Schema en tool parameter schema’s. Dan pas maak je prompts die dat contract vullen. Schema’s zijn je stabiliteit.

Patroon 2: State machine in plaats van “call model en klaar”

Je agent heeft fases:

  • classify intent
  • plan generation
  • policy checks
  • tool execution
  • final answer generation

Elke fase heeft een eigen schema en eigen checks. Je systeem wordt onderhoudbaar.

Patroon 3: Observability vanaf dag 1

Log per request:

  • prompt versie
  • output schema version
  • contract validity (pass/fail)
  • tool calls (welke tool, welke parameters, resultaat status)
  • cost metrics (tokens, latency)

Patroon 4: “Repair” pipeline voor schema failures

Wanneer contract validatie faalt, doe je niet blind een retry met dezelfde prompt. Je stuurt een repair prompt waarin je expliciet vraagt om het outputcontract exact te respecteren.

if !valid(plan):
  plan = call_model_repair(bad_output=plan_raw, schema=QueryPlanSchema)
  if !valid(plan):
    return ask_user_to_clarify()

Patroon 5: Automatiseer met guardrails

Als je AI gebruikt voor automatisering, moet je guardrails ook in je workflow engine zitten. Zie ook: AI automatisering: van idee naar veilig geautomatiseerd systeem.

“Program AI” in praktijk: agent, API, en UI

Je eindproduct is een API die deterministisch gedraagt, plus een UI die correct omgaat met states (loading, denied, needs clarification).

Stapsgewijze roadmap

  1. Maak een kleine kernel: één endpoint, één contract, één tool of zelfs alleen read-only.
  2. Voeg contract afdwinging toe: structured outputs met json_schema, strict validation.
  3. Voeg policies toe: riskFlags, permission checks, deny rules.
  4. Voeg observability toe: log en meet contract failure rate.
  5. Voeg tool execution toe: integratie tests, retries met backoff, timeouts.
  6. Voeg red-teaming toe: prompt injection en tool misbruik scenario’s.
  7. Schrijf deploy runbooks: schema migraties, prompt versie management, rollback plan.

Waar developers vaak struikelen

  • Tekst-parsen in plaats van contract validatie.
  • Tools zonder schema en zonder parameter validatie.
  • Geen fallback voor refusal en invalid output.
  • Security checks alleen in de prompt, niet in code.

Voor een bredere technical start kun je ook gebruiken: Open AI online: snel starten met chat, API en security en OpenAI AI voor developers: modellen, API en security.

Voorbeeld UI flow (compact)

  • User request
  • API call returns state: OK, DENIED, NEEDS_CLARIFICATION
  • UI toont ofwel resultaat, ofwel “niet toegestaan”, ofwel extra vraag

Als je voice of real-time conversatie bouwt, zie ook: Chai chat met AI-vrienden: bouw een snelle voice chat.

Program AI en modelkeuze: minimalistische beslissingen

Modelkeuze is niet het onderwerp, maar je engineering moet het wel aankunnen. Je wil contracten die vrijwel onafhankelijk zijn van specifieke model output stijlen.

Praktisch: abstraheer “model” onder een interface

Maak een interface als:

  • input: user request + context + schema id
  • output: contract object + metadata

Daarmee kun je model A naar model B wisselen zonder je rest code te breken.

Waarom dit relevant is voor “program AI”

Structured Outputs ondersteunt het idee van contract matching op basis van schema’s, waardoor je systeem gedrag meer voorspelbaar wordt bij modelwijzigingen. (developers.openai.com)

Als je ook strategisch wil kijken naar de markt en keuzes, past: AI market: marktdefinitie, spelers, modellen, strategie.

Checklist: “program AI” betekent dit minimaal

  • Structured Outputs met json_schema, strict, contract checks. (developers.openai.com)
  • Tool routing met whitelist, niet vrij keuzegedrag.
  • Tool parameters gevalideerd met schema, timeouts, retries met backoff.
  • Policy engine voor deny, allowed actions, risk flags.
  • Security testing als systeem (prompt, retrieval, tools, permissies). (owasp.github.io)
  • Logging en metrics voor contract failure rate en tool errors.
  • Runbooks voor schema/prompt versiebeheer en rollback.

Wil je extra technische handleiding met concrete voorbeelden, dan is dit relevant: Chat AI Open: technische handleiding met voorbeelden en Elementsofai: technische gids om AI-systemen te bouwen.

Conclusie

Program AI is software-engineering voor AI: je bouwt contracten, je dwingt schema’s af, je valideert tool inputs, en je test en beveiligt het hele systeem als attack surface. Start klein met één outputcontract en één route naar een tool of read-only data. Breid daarna uit met een state machine, policy checks, observability en red-teaming.

Als je één beslissing vandaag wil nemen: kies structured outputs met json_schema en strict validatie als kern. Alles wat daarna komt, wordt makkelijker omdat je AI niet langer “tekst produceert”, maar “data produceert die je code kan uitvoeren”. (developers.openai.com)

Over de auteur

Dino Hensen

Dino Hensen is softwareontwikkelaar bij Hensen Software Services. Op Generati schrijft Dino over kunstmatige intelligentie, AI-agents en het automatiseren van SEO, met de nadruk op wat je er in de praktijk mee kunt.

Meer over Generati →