EU AI Act Article 12 Compliance Guide

How SteelSpine satisfies the record-keeping, monitoring, and auditability requirements of major AI regulatory frameworks.

The deliverable in one command:
steelspine verify-run --compliance-html > audit.html

Open the resulting file in any browser. Self-contained. Independently verifiable. EU AI Act Article 12 + ISO 42001 + NIST AI RMF + AIUC-1 tags included by default.

EU AI Act — Article 12 (Record-Keeping)

The EU AI Act takes effect August 2, 2026. For high-risk AI systems (Article 6 and Annex III — including credit scoring, recruitment, education, law enforcement, critical infrastructure, and more), Article 12 mandates automatic event logging.

What Article 12 requires

Article 12 requires that high-risk AI systems:

  1. Automatically record events ("logs") over the lifetime of the system — no manual logging by operators
  2. Logs must enable monitoring of operation with respect to risk identification (Article 9) and substantial modification (Article 43)
  3. Logs must be retained for an appropriate period given the system's intended purpose, minimum 6 months unless other Union or national law specifies longer
  4. For systems referred to in Annex III, point 1(a) (biometric ID systems): logs must include each use, the reference database, the input data leading to a match, and the staff identification
  5. The provider must keep the logs while under their control, including from systems put into service

How SteelSpine satisfies each clause

Article 12 ClauseSteelSpine FeatureCommand
Automatic event loggingsteelspine run captures every stdout/stderr/exit-code, plus structured events from instrumented agentssteelspine run python3 my_agent.py
Logs enable risk monitoringHash-chained event log with timestamps, exit codes, failure classifications, divergence detectionsteelspine compare, steelspine diagnose
Logs retained ≥ 6 monthsConfigurable retention in config.json (default 30 days; set to 180+ for AI Act compliance)steelspine storage
Logs tamper-evidentEvery event signed with HMAC-SHA256; Ed25519 chain seal; auditor verifies independentlysteelspine verify-run
Logs include input → output linkageEvery event records input_refoutput_ref; replay-run reconstructs the decisionsteelspine replay-run <run_id>
Provider keeps logsLocal storage by default; export bundles with pack-create; signed packets verifiable offlinesteelspine pack-create, steelspine pack-verify

Recommended configuration for EU AI Act compliance

Edit ~/.prime/config.json:

{
  "compliance_mode": true,
  "retention_days": 180,
  "auto_rotate": true,
  "archive_on_prune": true,
  "archive_dir": "/secure/path/to/audit-archive"
}

Setting compliance_mode: true auto-enables RFC 3161 third-party notarization on every captured run, defaulting to an eIDAS-accredited Timestamp Authority (Sectigo). Each run gets an independently-verifiable cryptographic timestamp proving it existed at a specific moment, signed by an authority whose signature is legally recognized in the EU — separate from SteelSpine's own signing key. Override via notarize: false in config or --no-notarize per run.

For multi-user deployments, the signing key should be held by the compliance officer (auditor), not the AI developer:

export STEELSPINE_ORG_KEY=/path/managed/by/compliance/signing.key

Optional: post-quantum signing (--pq-sign)

For long-archive use cases (medical records, legal evidence, government, defense) where signatures must remain valid past the arrival of cryptographically-relevant quantum computers, SteelSpine offers an additive post-quantum signature option using ML-DSA-65 (NIST FIPS 204):

steelspine run --pq-sign python3 my_agent.py

Both Ed25519 and ML-DSA-65 signatures coexist in the run record. Verifiers can check either or both. Requires pip install liboqs-python. Forward-looking targets: CNSA 2.0 (US gov), forthcoming EU eIDAS 2 PQ profiles, and high-security regulated industries (banking, healthcare, defense). Median analyst estimate for cryptographically-relevant quantum computers: 2030–2040 — any audit signature you need to remain valid past that horizon should use --pq-sign.

EU AI Act — Article 14 (Human Oversight)

Article 14 requires that high-risk AI systems can be effectively overseen by natural persons during operation. SteelSpine adds an opt-in approval gate that pauses a run before the wrapped command executes:

steelspine run --require-approval python3 my_agent.py

The operator sees a summary (command, project, user, timestamp) and is asked to approve or decline. Approval reason is optional; decline reason is required. The decision is sealed into run_meta.json as article_14_approval and surfaced in verify-run audit reports.

Declined runs do not execute. A decline record is saved with final_state: "declined_at_oversight" — the refusal itself is part of the audit trail, proving human oversight was performed and the run was refused.

For CI / non-interactive contexts where TTY prompting isn't possible but external approval workflows exist:

steelspine run --require-approval \
  --auto-approved-by "compliance@example.com" \
  --auto-approval-reason "Approved per ticket COMP-1234" \
  python3 my_agent.py

Without --auto-approved-by in a non-TTY shell, --require-approval declines safely. Silent auto-approval would defeat the oversight requirement.

What Article 14 oversight does NOT do:

Generating an Article 12 audit deliverable

steelspine verify-run --compliance-html > article_12_audit.html

This produces a single self-contained HTML file the auditor can open in any browser, showing:

ISO/IEC 42001 (AI Management System)

ISO 42001 (published December 2023) is the international standard for AI management systems. SteelSpine supports the operational controls in Annex A:

Annex A ControlCoverage
A.6.2.7 AI system documentationCaptured automatically — every run is documented
A.6.2.8 Operations recordssteelspine run is exactly this
A.7.4 AI system data qualitysteelspine compare + audit-quality flag drift
A.8.5 Process documentationReplay capability proves what was actually executed
A.10.4 Incident managementsteelspine patterns surfaces recurring failures

NIST AI Risk Management Framework

The NIST AI RMF (1.0) names four functions: GOVERN, MAP, MEASURE, MANAGE. SteelSpine slots into MEASURE and MANAGE:

RMF FunctionSteelSpine Mechanism
MEASURE 2.5 — track AI system performancesteelspine eval, steelspine stats
MEASURE 2.7 — privacy and security of AITamper-evident logs, key-managed signing
MANAGE 4.1 — continuous monitoringsteelspine monitor daemon
MANAGE 4.3 — risk responsessteelspine policy pre-execution guardrails

AIUC-1 (AI Use Case 1 — Pseudonymized Audit)

For deployments where personal data must be pseudonymized in audit trails, SteelSpine supports:

Verification by an external auditor

A compliance officer or external auditor can verify a SteelSpine deployment without access to the source system:

  1. Customer exports a portable audit packet:
    steelspine pack-create <event_index>
  2. Customer sends the .spine.tgz file to the auditor.
  3. Auditor verifies the packet on their own machine — no SteelSpine install needed for verification, just the public key:
    steelspine pack-verify <packet.spine.tgz>
  4. Auditor's tooling can independently check the hash chain and Ed25519 signature against the published public key.

This means a regulator, an ISO 42001 auditor, or a court can verify the integrity of any specific decision without trusting the AI provider's word for it.

What SteelSpine does not do (be explicit with your auditor)

SteelSpine logs and seals the events your AI system emits. It does not:

SteelSpine is the logging and verification layer. Combine it with your model governance, evaluation harness, and human-in-the-loop processes to satisfy the full regulatory burden.

Questions

For deployment in regulated environments, reach out via hello@steelspine.ai. We can provide: