Skip to main content

EU AI Act Conformity Assessment: Preparing for Regulatory Audits

EU AI Act conformity assessment is where a lot of AI governance programs discover whether they built a control system or just a presentation. For high-risk systems, the regulation expects documented risk management, data governance, technical documentation, logging, human oversight, accuracy and robustness controls, and a governance model that can survive inspection. Keeptrusts can support part of that work by enforcing route-level controls and generating operational evidence. It cannot perform a conformity assessment for you, certify a system, or replace the product and quality management obligations that sit outside the gateway.

That is the right way to frame the work. Conformity assessment is not a single checklist event near launch. It is the process of proving that the system you describe in documentation is the same system users actually encounter in operation.

Use this page when​

  • You are preparing a high-risk AI system or a high-risk subsystem for EU AI Act assessment.
  • You need to connect route-level controls to a broader audit and evidence program.
  • You want a practical way to show how Keeptrusts contributes to oversight, logging, and controlled runtime behavior.

Primary audience​

  • Primary: Compliance officers, quality managers, risk managers
  • Secondary: Platform engineers, product counsel, internal audit

The problem​

Many organizations treat conformity assessment as a documentation sprint. They collect policies, write process descriptions, and map control owners, but they do not verify whether the runtime path actually reflects those claims.

That gap becomes obvious in high-risk use cases. An organization says the system uses only approved providers, but the route can still fall back to a general-purpose model path. It says human oversight is mandatory, but the workflow returns output directly to an operator with no enforced stop. It says the system logs critical activity, but the logging is fragmented across several services and the evidence is difficult to reconstruct. When an auditor or notified body asks how the control works in practice, the answer becomes narrative rather than proof.

The problem is not only regulatory. Weak operational alignment also makes internal sign-off harder. Product teams cannot tell what evidence they should gather. Risk teams cannot see where the model boundary is actually controlled. Engineering treats audit preparation as external paperwork rather than a design constraint. That drives rework late in the process.

Conformity assessment is easier when runtime controls are explicit. The gateway does not solve every requirement, but it can make a defined part of the system explainable. That matters because many high-risk systems rely on model-assisted subflows such as document classification, analyst support, eligibility review support, or operator copilots. Those subflows need their own enforceable boundary.

The solution​

Treat Keeptrusts as one controllable evidence-producing layer inside the broader EU AI Act control stack.

For high-risk or potentially high-risk workflows, define routes that are conservative by default. Use prompt-injection to protect the boundary from hostile or malformed instructions. Use pii-detector where the route processes personal data and minimization is needed. Use data-routing-policy to make provider selection auditable and deterministic. Add human-oversight when the model output should never become operative without a person reviewing it. Keep audit-logger in the chain so the decision stream records that audit logging was active for the route.

This does two useful things for conformity assessment. First, it narrows the evidence problem. Instead of describing vague organizational intent, you can point to the exact controls on the assisted route. Second, it improves traceability. The organization can show which route was in force, which policy chain executed, and where escalation or blocking occurred. That is not the whole assessment, but it is exactly the kind of operational grounding that audit programs usually lack.

The discipline also scales. Once a route is defined this way, quality, legal, engineering, and audit teams can discuss a shared artifact instead of arguing from separate diagrams.

Implementation​

The example below shows a conservative route for a high-risk operator-support workflow. It protects the input boundary, minimizes personal data, limits providers, and forces escalation before the model output can be used in a consequential downstream step.

pack:
  name: eu-ai-act-high-risk-operator-support
  version: "1.0.0"
  enabled: true

providers:
  targets:
    - id: high-risk-approved-provider
      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
    - human-oversight
    - 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
    redaction:
      marker_format: label
      include_metadata: true

  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

  human-oversight:
    action: escalate

  audit-logger: {}

This route is not a conformity assessment in itself. What it does give you is a clear technical statement about a sensitive assisted subflow: the provider is constrained, the input is minimized, the output cannot bypass review, and the decision path records that audit logging was active. That is the kind of concrete operating behavior you can connect to the larger technical documentation and quality management package.

The most relevant support pages are EU AI Act, Human Oversight, Audit Logger, Pass Compliance Audits, Reviewing Alerts and Evidence, and Export Evidence for a Review. Those pages help teams connect configuration choices to the evidence and review workflow an audit actually needs.

Results and impact​

The immediate benefit is that assessment preparation becomes less abstract. Teams can distinguish between controls that exist on paper and controls that actually execute on the route. That reduces late-stage surprises and helps internal reviewers see whether the system is really operating as described.

The other benefit is evidence reuse. A well-defined route with a clear control chain can support readiness reviews, internal audit, and later regulator conversations without being rebuilt each time. The control story becomes more stable because the runtime path is stable.

Key takeaways​

  • EU AI Act conformity assessment is about proving that the live system matches the documented control model.
  • Keeptrusts can support assessment readiness by enforcing route controls and improving traceability, but it is only one part of the overall obligation set.
  • human-oversight and audit-logger are especially useful when a model-assisted subflow sits inside a high-risk system.
  • Provider restrictions and data minimization should be explicit if the route handles sensitive or regulated content.
  • Evidence is easier to audit when the route architecture is conservative and deterministic.

Next steps​