EU AI Act

Structural Conformance Under the EU AI Act

Satisfying Articles 9 through 15 and Article 43 conformity assessment with pre-execution agent envelopes

May 14, 2026AnankeLabs

High-risk and agentic AI systems under Regulation (EU) 2024/1689 require continuous risk management, automatic event logging, effective human oversight, and documented robustness. How the KAIROS AI safety adapter turns each obligation into a replayable runtime record.

The high-risk obligations of the EU AI Act (Regulation 2024/1689) apply from 2 August 2026. Providers and deployers of autonomous and high-risk AI systems face a decisive shift: Articles 9 through 15 require continuous, verifiable runtime evidence rather than static pre-deployment paperwork.

When an AI system reasons over a context window, chains external tool calls, and mutates production infrastructure, static holdout benchmarks and system-prompt policies cannot prove that the system stayed inside its operational envelope. KAIROS governs the agent at the tool-execution boundary and produces the deterministic runtime evidence that Articles 9 through 15 and Article 43 demand.

What the High-Risk Regime Demands

Articles 9 through 15 define the substantive engineering obligations for high-risk AI systems:

  • Article 9 (Risk Management System): A continuous, iterative risk management process maintained across the entire lifecycle of the system, rather than a one-time design document.
  • Article 11 & Annex IV (Technical Documentation): Complete documentation of system architecture, control boundaries, validation procedures, and oversight thresholds before the system is placed on the market.
  • Article 12 (Record-Keeping): Automatic recording of events (logs) throughout the lifetime of the system to ensure traceability of its operation and identify situations that may result in risk.
  • Article 14 (Human Oversight): Oversight measures built into the system so that natural persons can monitor operation, intervene, or halt execution on a “stop” button without falling victim to automation bias or alert fatigue.
  • Article 15 (Accuracy, Robustness, and Cybersecurity): Resilience against errors, faults, inconsistencies, and adversarial attempts to alter the system’s use or performance (such as indirect prompt injection or goal drift).

Under Article 43, demonstrating conformance with these requirements is the prerequisite for CE marking and European market access, either through internal control (Annex VI) or third-party Notified Body assessment (Annex VII).

Why Semantic Guardrails and Standard Logs Fall Short

Most AI stacks try to answer Articles 9 through 15 with two artifacts: pre-deployment benchmark tables and runtime chain-of-thought logs. Neither satisfies an engineering audit.

A static benchmark measures how a model behaved on a test dataset weeks before deployment; it places no constraint on what an agent does when it encounters an adversarial payload or an unfamiliar tool-call sequence in production. Meanwhile, chain-of-thought tokens are generated by the same probabilistic weights that propose the action: they are an uncalibrated narrative, not a causal record of the safety boundary.

Human oversight fails just as quickly when implemented through naive permission prompts. Asking an operator to approve every file write or API call produces immediate alert fatigue; the operator either rubber-stamps the queue or disables the gate entirely.

How KAIROS Maps to Articles 9 Through 15

The KAIROS AI safety adapter sits directly between the agent harness and external tool execution, turning each statutory requirement into a concrete runtime mechanism:

Article 9 (Continuous Risk Management). Across every step of an agent session, KAIROS continuously weighs capability pressure against alignment posture against a signed deployment policy. Risk management operates as a live numerical trajectory on every call rather than a static document.

Article 11 & Annex IV (Technical Documentation). The safety boundary is defined in a cryptographically signed policy bundle and a calibration artifact. Both files are versioned engineering objects that drop directly into the Annex IV technical file, specifying the alignment floor, action-gating rules, and escalation thresholds in force.

Article 12 (Automatic Record-Keeping). Every candidate tool call produces a hash-bound evaluation envelope before execution. The envelope captures the session posture reading, the pre-execution tool-call preview, the forward criticality horizon, the retry state, and the cryptographic digest of the policy in force.

Article 14 (Human Oversight Without Alert Fatigue). KAIROS returns its response envelope to both the operator dashboard and the agent’s own context window. When a tool call approaches the boundary, the agent receives remaining stability headroom and an explicit directive to reformulate within a bounded retry budget. In the BND-001 boundary study, cooperative agents used that feedback to reformulate onto a safe path on their own, cutting human escalations by 88% (from 2.50 escalations per run under a stateless gate to 0.30). Human operators are paged only when recovery headroom is exhausted, and any operator exception requires a signed override token bound to the exact request digest.

Article 15 (Robustness and Cybersecurity). Because KAIROS evaluates structural session trajectory and previews every tool call before execution, an adversarial prompt injection that attempts to escalate from read-only inspection to external data exfiltration is caught by the action gate regardless of how benign the surrounding text appears. Across 120 evaluation runs in BND-001, KAIROS blocked 100% of unsafe tool executions (48 of 48) while preserving 100% completion on cooperative tasks (20 of 20).

The Assessor as a Replayer

Under Article 43 (Conformity Assessment) and Article 72 (Post-Market Monitoring), an auditor or Notified Body reviewing a KAIROS-governed agent does not have to take a prose risk assessment on trust.

The provider supplies three items in the Annex IV dossier: the signed deployment policy, the calibration artifact, and the recorded trajectory envelopes. Using the verification runner, the assessor replays the recorded trajectories and reproduces every margin calculation, tool-call block, self-correction loop, and human override receipt.

Continue Reading

Assessing regulatory fit for your own stack? We read everything that comes in.

Get in touch