Compliance by Design: An Architecture Reference for EU AI Act Article 12 Logging, NIS2 Reporting Loops, and CRA SBOM

The EU regulation stack has a common failure mode: organizations treat each regulation as a separate project and end up with three compliance programs, each owned by a different team, none of which share an evidence layer. The result is that a single incident triggers three parallel, uncoordinated response processes — and the immutable audit trail each regulation requires either does not exist or exists in incompatible forms that cannot be correlated.

The architecture problem is not satisfying three regulations. It is building one evidence layer that satisfies all three. This post maps the three concrete deliverables: Article 12 traceability logging for the EU AI Act, the NIS2 24/72/1 reporting pipeline, and CRA SBOM generation. Each section names what the regulation demands structurally, what the architect must build, and where the existing stack fits.

Article 12 logging: the bitemporal traceability requirement#

High-risk AI systems must automatically record events over their entire operational lifetime. The architectural interpretation: every inference event must be stamped with two timestamps — the time the event occurred in the system and the time it was recorded in the log store. These two times can diverge due to network delay, batch processing, or clock skew. Regulations that require reconstruction of “what the system knew at a specific moment” require both.

What the architect must build:

A columnar log store with bitemporal partitioning. The data-access layer post establishes why Apache Iceberg is the lakehouse surface — hidden partitioning, snapshot isolation, time-travel. Article 12’s specific demand is the bitemporal schema: every inference event carries two timestamps — event_time (system clock at inference) and record_time (ingestion), the dual axis that lets a regulator reconstruct what the system knew at a given moment. Partition by record_time day for hot-query performance, with event_time as the secondary sort key.

-- Example Iceberg table DDL for Article 12 compliance log
CREATE TABLE ai_audit.inference_log (
  event_time    TIMESTAMPTZ NOT NULL,
  record_time   TIMESTAMPTZ NOT NULL,
  session_id    UUID         NOT NULL,
  model_version VARCHAR(64)  NOT NULL,
  dataset_ref   VARCHAR(256) NOT NULL,
  user_id       VARCHAR(128) NOT NULL,
  user_role     VARCHAR(64)  NOT NULL,
  input_hash    CHAR(64)     NOT NULL,  -- SHA-256 of sanitized input
  output_hash   CHAR(64)     NOT NULL,
  confidence    FLOAT        NOT NULL,
  override_flag BOOLEAN      NOT NULL DEFAULT FALSE,
  override_by   VARCHAR(128),
  override_ts   TIMESTAMPTZ
)
USING iceberg
PARTITIONED BY (days(record_time))
TBLPROPERTIES (
  'write.delete.mode' = 'copy-on-write',
  'history.expire.min-snapshots-to-keep' = '3'
);

Retention: the deployer’s minimum retention obligation is six months under Article 26(6) of the AI Act — Art 12 establishes what must be logged; Art 26(6) sets the floor on how long deployers must keep those logs. Use Iceberg’s lifecycle management to move records to cold storage (AWS S3 Glacier Instant Retrieval or equivalent) after the hot query window closes. Cold records must remain queryable; they just do not need to return in milliseconds.

OPA/Rego decision logs as governance evidence: The OPA/Rego tool-call authorization mechanism — the AI Gateway interception pattern and the Rego policy structure — is the subject of Agent Governance Architecture in Series 1. What matters here is that every policy evaluation is itself a loggable event: the input bundle, the decision (allow/deny), and the policy version. Ingested alongside the Article 12 inference records, these decision logs document the governance layer the architecture imposes — which tool calls were permitted, which denied, and what authorization was presented when a human override occurred. Whether they satisfy Article 12 directly or serve as a companion evidence layer for Article 14 human-oversight purposes is context-dependent; auditors treat them as corroborating evidence, not as the primary Article 12 log.

NIS2 24/72/1 reporting pipeline: detection as architecture#

NIS2’s reporting requirement has a latency implication that most organizations underestimate: the 24-hour early warning requires that a significant incident be detected and classified as warranting notification within one day. In most industrial OT environments, the detection-to-classification latency can run in days to weeks for anything that does not trigger a hard operational alarm.

What the architect must build:

NIS2 Art 23 sets three external deadlines — 24h early warning, 72h notification, 1-month final report. The internal architecture budget below works backward from those deadlines and represents a defensible detection-pipeline design, not a regulatory sub-mandate:

A detection pipeline with three stages, each with a defined maximum latency budget:

Stage 1 — near-real-time triage (budget: < 1 hour): A SIEM or equivalent stream-processing layer ingesting events from OT systems, IT systems, and network telemetry. The triage stage classifies events against a severity taxonomy that maps to NIS2’s “significant incident” definition — severe operational disruption or financial loss with cross-border potential. This classification must be automated; a human reviewing logs 24 hours after an event does not meet the timeline.

# Example detection rule structure (vendor-neutral)
rule:
  id: nis2-sig-incident-detection
  trigger:
    - operational-disruption: severity >= HIGH
    - financial-impact-threshold: EUR 100000  # EXAMPLE — Art 23(3) requires "severe financial loss"; threshold is operator-configured, not set by NIS2
    - cross-border-affected-services: any
  action:
    create_incident_record:
      classification: SIGNIFICANT
      early_warning_deadline: +24h
      notification_deadline: +72h
      final_report_deadline: +30d
    notify:
      - security-operations-center
      - ciso
      - legal-counsel

Stage 2 — forensic state capture (budget: < 4 hours after Stage 1): At the moment of incident classification, capture forensic state — network flows, authentication logs, OT system telemetry, indicators of compromise — into an immutable store. Iceberg’s append-only log semantics handle this naturally; a separate forensics namespace with TBLPROPERTIES ('write.target-file-size-bytes' = '67108864') tunes for write throughput over query speed.

Stage 3 — evidence assembly (budget: 1 month): The final report requires root cause, mitigation steps, and improvement commitments with evidence citations that resolve to specific records in the forensic store. An evidence assembly workflow pulling from Iceberg forensic tables reduces manual effort and ensures citations are reproducible.

CRA SBOM: software bill of materials in CI/CD#

The Cyber Resilience Act mandates that products with digital elements include a software bill of materials — a machine-readable inventory of all software components, including transitive dependencies — as part of the technical documentation, supplied to market surveillance authorities on reasoned request. Publishing the SBOM to customers is optional under the CRA (many vendors do it as a trust signal); what is mandatory is that the SBOM stays current as the manufacturer’s vulnerability-handling process discovers new CVEs in listed components.

What the architect must build:

SBOM generation integrated into the CI/CD pipeline, not as a post-build artifact but as a build-gate. The gate fails the build if any component in the dependency tree matches a known CVE above the organization’s risk threshold.

# CI/CD pipeline step (GitHub Actions example pattern)
- name: Generate SBOM
  uses: anchore/sbom-action@v0
  with:
    format: cyclonedx-json
    output-file: sbom.json

- name: Vulnerability scan against SBOM
  uses: anchore/scan-action@v3
  with:
    sbom: sbom.json
    fail-build: true
    severity-cutoff: high

- name: Publish SBOM to artifact registry
  run: |
    aws s3 cp sbom.json \
      s3://${{ vars.SBOM_BUCKET }}/products/${{ github.event.repository.name }}/${{ github.sha }}/sbom.json \
      --metadata "product-version=${{ github.sha }},build-date=$(date -u +%Y-%m-%dT%H:%M:%SZ)"

The SBOM registry must answer: “which deployed product versions include component X at version Y?” That is a dependency graph query, not a key-value lookup. Store the SBOM data in a queryable format (graph database or component-to-product edge table) alongside the raw artifacts.

The CRA’s 24-hour active exploitation notification requirement mirrors NIS2’s detection timeline. An architect who has built the NIS2 detection pipeline and the SBOM registry has the two components for CRA CVE response — they need a bridge between the CVE feed and the SBOM query layer.

Where the pieces connect#

The three architectures share an evidence layer. Article 12 inference logs, NIS2 forensic captures, and CRA SBOM records are all append-only, immutable, and queried retrospectively by investigators who did not design the systems. Apache Iceberg’s consistent query semantics, schema evolution support, and time-travel capability make it the natural shared storage layer for all three. Organizations that build each compliance artifact in isolation (a separate log database for Article 12, a separate forensic store for NIS2, a separate S3 bucket for SBOMs) end up with three uncoordinated evidence stores that cannot be correlated in a multi-regulation audit.

Build one lakehouse namespace per regulation, with a shared catalog. The catalog is what makes cross-regulation queries possible. For the OT-specific data pipeline that feeds both the Article 12 inference logs and the NIS2 detection layer, see the Apache Iceberg for Industrial OT series.

The organizational accountability frame — why NIS2’s personal liability clause changes what boards demand from architects — is in the companion post on javatask.systems: When the Architecture Is the Liability.

The governance design above this logging layer — the HITL/HOTL decision matrix and the Rego policy structure for EU AI Act high-risk classification — is in Agent Governance Architecture in Series 1.