Docs / Compliance Guide

EU AI Act Article 12 Compliance Guide

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

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

EU AI Act — Article 12 (Record-Keeping)

The EU AI Act entered into force August 1, 2024. Phased compliance dates apply. GPAI provisions and general regulatory framework take effect August 2, 2026. High-risk AI systems (Annex III, including credit scoring, recruitment, education, law enforcement, critical infrastructure) must comply with Article 12 record-keeping by December 2, 2027 (delayed from August 2, 2026 via the Digital Omnibus, with the Council and Parliament reaching provisional agreement on May 7, 2026, final adoption expected June 2026). High-risk systems in regulated products (Annex I, including medical devices) have until August 2, 2028.

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

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

What the integrity layer does and does not claim: the layer is classical (HMAC-SHA256 + Ed25519) and is not quantum-resistant. Tamper-evidence plus independent verification protect integrity-after-capture and let a third party verify the chain — but because the signing key is held by the operator, this is not non-repudiation against the operator. Key custody (HSM / KMS / third-party timestamping) is the control for that.

Roadmap: post-quantum signing (experimental, not enabled by default)

Post-quantum signing (ML-DSA-65 / FIPS 204) is under development and is not part of the default integrity guarantee. The shipping integrity layer is classical (HMAC-SHA256 + Ed25519) and is not quantum-resistant. For archives that must remain trustworthy over long horizons, the controls available today are key custody (HSM / KMS) and eIDAS-accredited RFC 3161 timestamping.

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.

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:

• Total events captured, runs promoted
• Per-run integrity check (signed ✓ / TAMPERED)
• Compliance tag block (EU AI Act Art.12, ISO 42001, NIST AI RMF, AIUC-1)
• Hash chain head + Ed25519 signature for independent verification
• Timestamp range (first event → last event)
• Pass/fail verdict

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:

NIST AI Risk Management Framework

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

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

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

• Hash-of-input rather than raw input in reference_only event mode
• summary_only mode that records the decision without the full payload
• Schema-constrained event format — see schemas/REFERENCE_ONLY_WIRE_FORMAT_v1.json

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:

• Force your AI system to be safe — that's still your model and your prompts
• Replace impact assessments, fundamental rights assessments, or conformity assessments
• Substitute for human oversight required by Article 14
• Assess bias on its own — audit-quality flags suspicious patterns but does not certify fairness

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:

• A signed declaration that the SteelSpine version you deploy meets the Article 12 control set above
• Pre-filled control-mapping spreadsheet for ISO 42001 / NIST AI RMF auditor review
• Reference architecture for compliance-officer-held signing keys