Organization
Part VI. Compliance: proof through telemetry
For: architects · finance, risk and compliancePrerequisites: Have read part I; notions of logging and data retention.
22. Regulatory evidence matrix
Section titled “22. Regulatory evidence matrix”Principle: good instrumentation produces, as a by-product, the evidence regulation requires. The matrix below links an obligation to its theme, to whoever bears it and to the telemetry signal that constitutes its proof. The precise article-by-article mapping must be validated with legal and the DPO. This is a working matrix, not legal advice.
The AI Act sets obligations according to the role (the provider places the system on the market, the deployer uses it) and according to the risk level. Most of its rows below apply only to high-risk systems; Article 50, however, covers any system that interacts with people or generates content, whatever its risk level.
| Obligation theme | Text and article | Who, for which systems | Telemetry signal that produces proof |
|---|---|---|---|
| Logging and traceability: the system automatically records events throughout its lifetime | AI Act, Art. 12 | provider, high risk | Timestamped end-to-end traces with trace_id, tool invocation log, model and pipeline versions in the spans |
| Technical documentation: description of the system, the data, the evaluation and monitoring methods | AI Act, Art. 11 | provider, high risk | Evaluation history, versioned configuration |
| Transparency and information to deployers: instructions for use (expected performance, limits, means to collect and interpret logs) | AI Act, Art. 13 | provider, high risk | Model attribution, controlled content capture, prompt versioning, documented dashboards and thresholds |
| Human oversight | AI Act, Art. 14 | provider, high risk | Human handoff rate, validation points, traced guardrails |
| Accuracy, robustness and cybersecurity | AI Act, Art. 15 | provider, high risk | Quality SLOs, continuous evals, drift detection |
| Post-market monitoring: collect and analyze performance data throughout the life of the system | AI Act, Art. 72 | provider, high risk | Quality scores, drift, cost, alerts |
| Monitoring of operation: monitor the system according to the instructions, report risks | AI Act, Art. 26(5) | deployer, high risk | Alerts, escalation procedures toward the provider |
| Retention of automatically generated logs: at least six months, unless Union or national law provides otherwise | AI Act, Art. 19 (providers) and Art. 26(6) (deployers) | provider and deployer, high risk | Documented retention policy, timestamped trace and log retention set accordingly |
| Transparency toward people: inform people that they are dealing with an AI, mark generated content | AI Act, Art. 50 | provider and deployer, any system that interacts with people or generates content | The obligation belongs to the product, not to observability; telemetry can only record that the “you are talking to an AI” notice was shown and that content was marked |
| Incident handling | NIS2, Art. 21(2)(b) | essential and important entities | Security alerting, SOC escalation, measured MTTD and MTTR |
| Incident notification: early warning within 24 hours, notification within 72 hours, final report within one month | NIS2, Art. 23 | essential and important entities | Detection timestamp, timeline rebuilt from traces |
| Supply chain security | NIS2, Art. 21(2)(d) | essential and important entities | Tool pinning, mutation detection, authentication failures |
| Data minimization | GDPR, Art. 5(1)(c) | controller | Content opt-in, masking at the collector |
| Data protection by design and by default | GDPR, Art. 25 | controller | No content capture by default, separate retention, traceability of personal data |
Texts: AI Act, Regulation (EU) 2024/1689; NIS2, Directive (EU) 2022/2555; GDPR, Regulation (EU) 2016/679. Articles checked on 2 October 2026; the rows for Articles 11 and 72 and for Article 26(5) come from the provider and deployer table of the course, module 5, merged here on 4 October 2026. NIS2 obligations apply through the national transposition law.
A well-built OpenTelemetry stack provides the technical material for these obligations: logs, performance measurements, history. What remains is to qualify your system and your role, to document, and to maintain the setup over time.
23. Content and metadata separation
Section titled “23. Content and metadata separation”Structuring compliance rule: separate content (sensitive, short retention, restricted access, redacted) from telemetry metadata (low cardinality, long retention, freely usable). This is the OpenTelemetry external content pattern generalized to the whole stack. Sovereignty: self-hosting the backends (for example VictoriaMetrics or Prometheus, VictoriaLogs or Loki, Grafana, Langfuse or Phoenix) lets you choose where the data resides.
Revised on 2 October 2026: added the articles of each text and the timeline from Regulation (EU) 2026/1744 amending the AI Act.
Revised on 4 October 2026: merged the AI Act provider and deployer table from the course (module 5) into the matrix, which gains a “who” column, Articles 11 and 72 and Article 26(5); the timeline is given only once, in the box.