The EU AI Act for AI agents: a requirement-to-control map

Human oversight for AI agents (Article 14 and Article 26)

Article 14 requires that high-risk AI systems can be effectively overseen by natural persons, and Article 26 puts oversight duties on deployers: competent humans who understand the system and can intervene. In Quox, that oversight is a control, not a checkbox. Gated agent actions land in the HITL approval inbox and pause there until a human approves or denies them; nothing behind a real gate runs on its own.

The agent surfaces the exact approval command, so the person deciding sees precisely what would execute. And a hard invariant holds: a resident agent cannot self-approve a real gate. Every approve and deny is recorded, which means the oversight you exercised is oversight you can evidence, not just assert.

AI agent audit trail and six month log retention (Article 12 and Article 26)

Article 12 asks for automatic recording of events over the system’s lifetime, and Article 26 requires deployers to retain those logs for at least six months. Quox writes its trail with WARD: write-once, hash-chained, externally timestamped receipts, paired with VOLT, the verifiable operations ledger.

The chain is tamper-evident by construction: alter a stored turn and verification breaks at that link. Logging happens automatically for every governed action, and the record is retained. What you hand an auditor is not a folder of mutable text files; it is a chain whose integrity can be recomputed.

Article 12 logging without storing personal data

Article 12 asks for automatic recording of events over a high-risk system’s lifetime, not for a copy of every event’s personal data landing in a retained log. Retention duty attaches to the log; data minimisation attaches to what the log contains, and those are two different obligations, answered by two different design choices, not one trade-off between them.

VOLT events record metadata: tool names, operation types, durations, exit codes, rather than raw inputs or outputs, so personal data in a payload is non-conformant by design, and any field that must be present but is sensitive carries an explicit redaction flag.

WARD then witnesses the VOLT chain with content-free hash digests: an external timestamp on a hash of the chain tip, never the underlying event. What is retained for six months under Article 26 is a chain of tamper-evident hashes and event fingerprints proving nothing in the log was altered, not a store of the personal data the agent touched.

Risk management enforced at runtime (Article 9)

Article 9 requires a risk management system that runs across the lifecycle: risks identified, mitigations applied, and the whole thing reviewed on an ongoing basis. A document written once does not satisfy that. Quox enforces policy at the moment of execution through the AOCL policy gate.

Policies like blocking PII from reaching LLMs, blocking dangerous commands, rate limits, and warn-gates on production-destructive operations are applied when the agent acts, not merely written down. Policies marked audit-required need a second person to approve any change, and every change lands in an append-only history an assessor can read. A simulator for testing a policy before it goes live is planned, not shipped. The enforced policy set becomes a living artifact of your risk process.

Transparency and traceability (Article 13)

Article 13 requires that a high-risk system’s operation is sufficiently transparent for deployers to interpret its output and use it appropriately, with clear information provided. Quox captures every governed run as a replayable trace in the Trace Explorer, built on the AEE envelope standard: what the agent saw, what it decided, and what it called, in order.

You can filter runs by outcome, by denials, by HITL involvement. When someone asks why the agent did what it did, the answer is a record you open, not a reconstruction from memory.

Robustness, security and a stop path (Article 15)

Article 15 asks for accuracy, robustness and cybersecurity appropriate to the system’s purpose, including resilience against attempts to alter its behaviour. Quox contributes the security spine and the stop path: E-STOP to halt agents, a DEFCON posture that steps the whole instance down, Ed25519-signed job execution so hosts only run what was actually issued, governed SSH through Bastion, and scoped capability tokens instead of broad credentials.

The accuracy of your models remains your work. The platform’s job is that the system stays controllable, and that its execution paths stay signed and scoped.

Data governance and conformity evidence (Articles 10, 11, 17)

Article 10 requires governance over the data the system uses. Articles 11 and 17 require technical documentation and a quality management system. Conformity assessment then requires that someone outside your walls can verify what you claim. Quox’s contributions: QuoxVault holds credentials KEK-wrapped with scoped access, STATUS_AND_LIMITS maturity docs state what works and what does not, and DoneEngine records the evidence behind every "done".

For the assessor, VOLT evidence bundles export and verify offline, with no Quox account needed. The governed pipeline itself is a documented, witnessed process rather than a diagram of one.