Skip to main content

Netherlands AI Governance: Autoriteit Persoonsgegevens and Practical Compliance

In the Netherlands, practical AI compliance usually starts with the same question the Autoriteit Persoonsgegevens asks about any serious data-processing workflow: what is the lawful, necessary, proportionate, and secure way to do this? There is no separate Dutch AI statute that removes those baseline duties. Instead, organizations work across GDPR, the Dutch GDPR Implementation Act (UAVG), sector rules, and, where relevant, the EU AI Act. Keeptrusts helps by turning those governance choices into route-level technical behavior at the model boundary.

Use this page when​

  • You are introducing AI workflows in a Dutch organization and need a practical governance pattern.
  • You expect scrutiny from privacy, legal, or public-sector accountability teams.
  • You want to separate low-risk drafting routes from higher-risk case-handling or decision-support routes.

Primary audience​

  • Primary: Platform engineers, privacy officers, compliance teams
  • Secondary: Public-sector digital teams, customer-operations teams, internal audit

The problem​

Dutch organizations often approach AI responsibly in principle and still run into trouble in execution.

They perform an initial review, approve one tool, and then let multiple use cases accumulate behind the same route. A municipality uses the route for public-information drafting one week and case-summary support the next. An insurer uses it for internal knowledge retrieval and then begins summarizing customer files. An HR team starts with template assistance and moves toward case recommendations. The formal approval never fully catches up with the operational reality.

That matters because AP-style scrutiny is usually practical rather than abstract. Can the organization explain why personal data enters the route? Can it show that the processing is limited to what is necessary? Can it demonstrate that provider handling was constrained deliberately? Can it prove that high-impact outputs were not treated as self-validating machine decisions?

Without a governed route, the answer is often no. The provider path is vague. Personal data appears in prompts by habit. Output quality is assumed. Evidence is limited to generic logs that do not reveal which control chain was active.

The same issue becomes sharper for public-sector and regulated workflows. If a route contributes to benefits handling, case prioritization, enforcement support, employment decisions, or other high-impact functions, the organization usually needs stronger review and better documentation than a generic assistant path provides.

The solution​

The best Dutch implementation pattern is not one super-policy. It is a route taxonomy.

Create one route for low-risk drafting. Create another for internal summarization with privacy controls. Create a third for high-impact decision support where the output must stop for authorized review. Keeptrusts is effective because its policy chain lets you make those distinctions explicit.

Use prompt-injection to protect the request boundary from adversarial or misleading instructions copied from emails, tickets, or case notes. Use pii-detector to remove obvious identifiers and route-specific dossier references before the provider sees them. Use data-routing-policy to block provider targets that do not match the route's retention and training constraints. Use quality-scorer when the route should meet a clear minimum content standard or include a review note. Use human-oversight for employment, eligibility, or case-management routes where no assistant content should be delivered directly.

As in every other region, be precise about audit-logger: it marks audit logging as active in the chain and supports cleaner evidence interpretation, but durable retention and export behavior are handled elsewhere in the platform.

Implementation​

The example below is a practical route for Dutch case-support summarization. It keeps the request boundary protected, redacts route-specific identifiers, narrows provider eligibility, and rejects outputs that omit a required reviewer note.

pack:
  name: netherlands-case-support-route
  version: "1.0.0"
  enabled: true

providers:
  targets:
    - id: reviewed-dutch-route
      provider: openai
      model: gpt-5.4-mini-mini
      secret_key_ref:
        env: OPENAI_API_KEY
      data_policy:
        zero_data_retention: true
        training_opt_out: true
        retention_days: 0
        accepts_tokenized_input: true

policies:
  chain:
    - prompt-injection
    - pii-detector
    - data-routing-policy
    - quality-scorer
    - audit-logger

policy:
  prompt-injection:
    use_embedding: false
    detection:
      attack_patterns:
        - "ignore.*previous.*instructions"
        - "reveal.*system.*prompt"
    encoding:
      decode_base64: true
      normalize_unicode: true
      detect_homoglyphs: true
    boundaries:
      enforce_delimiters: true
      reject_fake_boundaries: true

  pii-detector:
    action: redact
    detect_patterns:
      - 'ZAAK-\\d{8}'
      - 'CLIENT-\\d{6}'
    redaction:
      marker_format: label
      include_metadata: true
      custom_markers:
        generic_id: "[REDACTED-CASE-ID]"

  data-routing-policy:
    require_zero_data_retention: true
    require_no_training: true
    max_retention_days: 0
    tokenize_sensitive_fields: true
    on_no_compliant_provider: block
    log_provider_selection: true

  quality-scorer:
    min_output_chars: 100
    min_sentences: 2
    assertions:
      - type: contains
        name: requires-reviewer-note
        threshold: 1.0
        mode: enforce
        severity: critical
        config:
          value: "Do not finalize without authorized reviewer approval."

  audit-logger: {}

This configuration is a good middle tier. It is stronger than a generic drafting route, but it is not as restrictive as a full review-stop route with human-oversight. If you are dealing with employment, benefit eligibility, enforcement support, or other high-impact outcomes, you should create a separate route and add human-oversight: { action: escalate } instead of stretching one route beyond its safety assumptions.

To keep the implementation grounded in the rest of the docs, pair this with EU AI Act Compliance, Configuration & Policy Overview, Data Routing Policy, Audit Logger, and the Compliance Officer Guide. Those references make it easier to explain the route internally and maintain the same language across product, compliance, and engineering.

Results and impact​

The practical benefit is that compliance becomes route-specific and testable. Instead of a broad statement that the organization uses AI "carefully," you can show which routes are privacy-limited, which providers are allowed, what output standards apply, and whether a human reviewer is required.

That is useful for ordinary governance and for regulator-facing confidence. Privacy teams gain clearer minimization and routing controls. Engineering teams gain a predictable policy chain. Audit teams gain a decision stream that is easier to interpret than scattered application logs.

It also supports better internal scaling. Once the first governed route exists, new use cases can be classified against it rather than improvised from scratch. That is often the difference between a controlled AI program and a set of disconnected exceptions.

Key takeaways​

  • Dutch AI compliance is usually about turning GDPR and accountability principles into operationally specific route controls.
  • A route taxonomy is more defensible than a single generic AI route used for every purpose.
  • pii-detector and data-routing-policy are strong default controls for Dutch case-handling workflows.
  • Use human-oversight on separate high-impact routes instead of treating review as an optional convention.
  • Keeptrusts improves technical enforcement and evidence quality, but it does not replace lawful basis analysis, DPIAs, or sector-specific governance requirements.

Next steps​