EU AI Act — Article 12 Logging & Evidence Packs
Article 12 requires high-risk AI systems to technically enable automatic event recording over the system lifetime. Sigigo is the evidence layer on that logging duty — signed, chained events you can export and verify offline.
What Article 12 requires — and what Sigigo adds
For high-risk AI systems, Article 12 requires providers to technically enable automatic recording of events over the lifetime of the system (risk identification, post-market monitoring, and deployer oversight). Article 26(6) requires deployers to retain those logs for at least six months (longer where sector law applies).
Sigigo witnesses inference and oversight boundaries as signed, chained events with exportable proofs — so the Article 12 record remains checkable when someone outside the operator questions it. Sensitive payloads stay in your vault under Private Commitment Mode by default.
Cryptographic integrity and independent verification are Sigigo's product layer. Article 12 itself does not prescribe hashes, signatures, or third-party witnessing — see the FAQ below.
Who is in scope
High-risk AI under Annex III — employment screening, credit and insurance, education, essential services, biometrics, law enforcement, and migration — with stricter minimum fields for biometric identification (Article 12(3)).
- Providers embed logging in the product (Articles 12, 19, 72).
- Deployers monitor operation, retain logs, and evidence human oversight (Article 26).
Logging vs defensible evidence
| Typical approach | Article 12 fit | Trust under scrutiny |
|---|---|---|
| Application stdout / CloudWatch | May capture events | Mutable; admins can rewrite history |
| Vendor-only audit UI | May satisfy retention | Verifier must trust the vendor |
| Manual compliance notes | Fails automatic recording | Not a system log |
| SIEM retention | Operational storage | Weak integrity when challenged |
| Sigigo evidence packs | Automatic capture layer | Signed chain; offline verify |
Article 12 field map → ai_act.* events
Map instrumentation to signed ai_act.* events at inference and oversight boundaries. Prefer references and commitments over raw PII in canonical payloads.
| Audit expectation | Sigigo action | Key metadata |
|---|---|---|
| Timestamp (automatic, UTC) | All events | timestamp (ISO8601) |
| Operator / session | ai_act.inference_started | session_id, actor, deployer_id |
| AI input (or verifiable reference) | ai_act.input_received | input_hash, input_ref — commitment mode by default |
| Retrieved context / RAG | ai_act.context_retrieved | source_ids[], retrieval_query_hash |
| AI output | ai_act.output_generated | output_hash, confidence |
| Model version / ID | ai_act.inference_started / completed | gpai_model_id, gpai_model_version |
| Human oversight / override | ai_act.human_review_completed, ai_act.human_override | overseer_id, decision |
| Downstream action | ai_act.action_executed | action_type, target_ref |
| Serious incident | ai_act.serious_incident_reported | incident_id, notified_authorities[] |
| Retention ≥ 6 months | Tenant policy | retentionDays ≥ 180 |
Minimal inference session chain
ai_act.inference_started
→ ai_act.input_received
→ ai_act.context_retrieved (if RAG / agent)
→ ai_act.output_generated
→ ai_act.human_review_completed (if oversight)
→ ai_act.action_executed (if automated action)
→ ai_act.inference_completed
Link steps with the same session_id. For multi-service agent flows, use completion assertions to prove no silent gaps in the chain.
Evidence pack export
For surveillance requests, export a self-contained evidence pack covering the retention window — not a dashboard screenshot. The API path /v1/audit-package/{chain_id} returns an evidence pack with:
manifest.json— pack metadata and chain scopeevents/— canonical signed eventsproofs/— Merkle inclusion paths and signaturesVERIFY.md— offline verification instructions
Sigigo exports runtime cryptographic evidence only — not Annex IV technical documentation, ISO 42001 dossiers, or legal conformity certificates. Pair with your legal and conformity assessment partners.
Deployment patterns
| Provider embed | Deployer overlay |
|---|---|
| AI vendor integrates SDK in product | Enterprise wraps vendor API at inference boundary |
| Logging ships with your high-risk feature | You meet Article 26 duties directly |
| Supports Articles 12, 19, 72 | Monitoring and retention under your control |
Regulatory timeline
| Date | Milestone |
|---|---|
| Feb 2025 | Prohibited AI practices — in force |
| Aug 2025 | GPAI provider rules — in force |
| Aug 2026 | Transparency, deployer duties, post-market monitoring — in force |
| Dec 2027 | Annex III standalone high-risk systems — primary deadline |
| Aug 2028 | High-risk AI embedded in regulated physical products |
Teams starting logging in 2026 enter surveillance with a defensible history. Starting in late 2027 leaves a lifetime gap.
Article 50 transparency (August 2026)
From 2 August 2026, Article 50 requires disclosure when users interact with AI or encounter synthetic content — for most generative-AI deployers, not only Annex III high-risk systems. UI labels satisfy UX; they do not produce tamper-evident proof. Witness disclosures with ai_act.transparency_disclosure at the first interaction or output boundary.
Full field map, engineering checklist, and FAQ: Article 50 transparency evidence guide.
Article 12 FAQ
- Does Article 12 require cryptographic proof of non-tampering?
- No. Article 12 requires high-risk systems to technically enable automatic lifetime event recording. Cryptographic integrity, independent verification, and evidence packs are how Sigigo makes those logs defensibly checkable — not a separate statutory mandate.
- Does Article 12 apply to every AI system?
- No. The Article 12 logging duty applies to high-risk AI systems. Other rules (for example Article 50 transparency) can apply more broadly. Classify role and risk with legal counsel or the FLI Compliance Checker before treating logging as in scope.
Article 50 FAQ
- Is Article 50 only for high-risk AI?
- No. Chatbots, synthetic media, and deepfake use cases trigger transparency duties even when Annex III high-risk rules do not apply. High-risk systems still need Article 12 automatic logging in addition.
- We already label our chatbot — is that enough?
- Labels are necessary UX, not audit evidence. Emit ai_act.transparency_disclosure when the user first sees the notice, linked to the inference session via session_id.
- Does Sigigo replace watermarking or EU AI labels?
- No. Article 50(2) machine-readable marking is a separate concern (Code of Practice, C2PA). Sigigo logs marking_applied and disclosure events — it does not render marks.
- How do I determine legal scope first?
- Start with the FLI Compliance Checker for role and risk tier, then map technical evidence using the field tables on this page.
EU-sovereign defaults
- Region-pinned storage on AWS or Azure EU-sovereign deployment
- Public blockchain anchoring off by default
- Private Commitment Mode for prompts, completions, and retrieved context
- Independent offline verification without trusting a vendor dashboard
EU AI Act guide cluster
- Article 12 evidence readiness quiz — technical gaps (not legal classification)
- Financial services — credit & insurance AI + Act impact
- Healthcare — clinical / healthtech AI + Act impact
- Article 50 transparency evidence — August 2026 deadline
- SME Article 12 evidence — narrow technical guide for small deployers
- Staffing & recruitment evidence — Annex III employment
- ISO 42001 + EU AI Act — governance programme vs runtime evidence
- Deployer duties (Article 26) — monitoring, retention, human oversight
Map your high-risk AI flow to ai_act.* events — start with the readiness quiz, then get in touch.
This guide supports qualification and architecture planning — it is not legal advice. Work with your legal and compliance teams on classification, DPAs, and deployment approvals. See also our Regulatory & Compliance page.