compliance · the EU AI Act
Wytness and the EU AI Act
Article 12 evidence, generated on demand.
The EU AI Act's enforcement window for high-risk AI systems opened 2 August 2026. Article 12 requires automated logging of events relevant to identifying risks and substantial modifications. Wytness captures and structures those events in a form your auditor can use — and we're explicit below about which articles we evidence versus support.
the artefact
What's in the pack
An EU AI Act pack bundles agent inventories, tool capability descriptions, signed event samples, anomaly history, and control-by-control attestations into one report — printable for the file, and downloadable as a signed, dated JSON pack with the signed events attached.
Every claim in the pack is traceable: each control cites the events behind it, and each event carries the signature your own key produced. The pack is sealed, so an auditor can confirm it reached them unaltered.
A real sealed pack is published — nothing here is a mock-up. Download the specimen and check it yourself on the verify page, in your browser, without uploading it. It is a SOC 2 (Trust Services Criteria) pack — the seal and the per-event signatures work identically whichever framework you generate.
// What the pack asserts about itself:
// control_mapping[] — 9 criteria, each carrying
// its evidence and a metric measured over your period:
…// + 5 more, in the table below
// Every control cites events an auditor can re-verify:
the mapping
What we map to what
| Article | Subject | What Wytness provides |
|---|---|---|
| Article 9 | Risk management cycle | Wytness logs are the input to the customer's Article 9 cycle, not the cycle itself. Continuous anomaly detection across 7 rules (see Anomaly Rules section of this pack) provides Art. 9(2)(c) continuous-monitoring evidence; per-org anomaly rate available via /anomalies; integrity-checker three-way reconciliation provides post-deployment performance metrics. |
| Article 12 | Record-keeping | Full event audit trail retained for the organisation's declared period (up to seven years) by a storage lifecycle policy, written once by the API with no update path exposed. A tamper-evident SHA-256 hash chain and per-event Ed25519 signatures with customer-held private keys make alteration detectable; the hosted archive carries no storage-tier immutability lock. |
| Article 12(2)(a–d) | Logging content | Sub-clause coverage of the Article 12 record. Period of use: each event carries its own capture timestamp plus an ingest-side timestamp, so drift between the two is visible. Involved persons: human_operator_id on every event, with any PII pseudonymised at the SDK before transmission (encrypted_token_map, re-identifiable only by the customer). Input data and reference sources: inputs_source and inputs_classification record provenance and sensitivity class rather than raw payloads. Acting identity: agent_id, agent_version and agent_instance_id pin which deployment of which agent acted. |
| Article 13 | Transparency | Event schema captures inputs, outputs, reasoning_summary, tool_parameters, inputs_classification, and human_operator_id — the customer assembles downstream disclosures from this record; Wytness preserves the evidence trail. |
| Article 14 | Human oversight (record-keeping support) | Wytness records `human_operator_id` on every event so the customer's human-in-the-loop workflow has a tamper-evident audit trail; per-agent operator attribution visible on the AgentDetail page. Wytness does NOT implement HITL gating itself — that is the customer's workflow. Wytness preserves the evidence that HITL occurred. |
| Article 15 | Accuracy, robustness and cybersecurity | Security-relevant robustness evidence for the audit trail: per-event Ed25519 signatures with customer-held keys, a tamper-evident SHA-256 hash chain verified by link, three-way ingest / query-store / archive reconciliation, and long-term retention (storage lifecycle policy). Wytness evidences the cybersecurity of the record; model-level accuracy and adversarial robustness of the AI system remain the customer's. |
| Article 17 | Quality management (record-keeping support) | Wytness evidences the record-keeping limb of the quality-management obligation, not the system itself. Events are retained for the organisation's declared retention period by a storage lifecycle policy anchored to creation. Alteration is made evident rather than prevented: the SHA-256 hash chain and per-event Ed25519 signatures expose any change, and chain breaks raise anomalies. Wytness-hosted storage carries no immutability lock; customers who require one use bring-your-own-storage and set the policy on their own container. Design control, testing and post-market monitoring remain the provider's. |
| Article 19 | Automatic logs | SDK auto-capture of all agent actions, SHA-256 hash chain, UTC timestamps, and a durable archive written once by the API and retained by lifecycle policy. |
| Article 26(5) | Operational monitoring | Dashboard surfaces event rate, error rate (status='failure' or 'error'), anomaly count, and chain-integrity status with an explicit `as_of` freshness signal; per-agent + per-session drilldown; the Verify page provides cryptographic monitoring of every agent's chain. |
the boundary
What Wytness does not establish
- —Conformity assessment: Wytness is not a notified body. We do not certify your system as conformant.
- —Risk classification: we map events to the high-risk categories you identify; the categorisation itself is the operator's call.
- —Bias testing: testing your model for protected-class bias is out of scope. We log activity; we do not evaluate fairness.
- —Substantive obligations: Wytness produces evidence. Whether the evidence demonstrates compliance is a legal question for your counsel.