EU AI Act Art.72 + CRA Vulnerability Disclosure: Building a Combined Monitoring Stack

Post #4 in the EU AI Act + CRA Dual Compliance Developer Series (5 posts)

The first three posts in this series established the conceptual overlap, mapped the cybersecurity requirements between Art.15 and CRA Annex I, and showed how to build a unified incident reporting pipeline for Art.73 and CRA Art.14. This post addresses the continuous monitoring layer underneath all of that: the operational data collection, alerting, and vulnerability scanning infrastructure that both the EU AI Act and the CRA require you to run indefinitely after deployment.

The core insight is that two compliance obligations share the same technical substrate. EU AI Act Art.72 mandates a post-market monitoring plan collecting performance, drift, and harm-signal data from your deployed high-risk AI system. CRA Art.13 mandates a post-market monitoring process specifically for security vulnerabilities affecting your product. Both need: an event-collection pipeline, anomaly detection, an alerting threshold, a remediation track, and a disclosure decision gate. Building these separately doubles cost and creates consistency gaps. Building them as one system halves the work while eliminating the category of bugs where the AI monitoring stack and the security monitoring stack produce conflicting signals about the same incident.

You have two deadlines converging. EU AI Act Art.72 obligations are live from 2 August 2026. CRA Art.14 reporting obligations follow on 11 September 2026. The monitoring stack for Art.72 must be operational six weeks before the CRA monitoring layer is mandatory — which means building them together now avoids an expensive retrofit in late August.

What Art.72 Actually Requires

EU AI Act Art.72 is titled "Post-market monitoring by providers and post-market monitoring plan." It applies to every provider of a high-risk AI system. The regulation does not specify a particular monitoring technology, but it does specify several observable outcomes your monitoring system must be able to produce.

Continuous data collection. Art.72(1) requires providers to "actively and systematically collect, document and analyse relevant data provided by deployers and, where applicable, by users" with the purpose of detecting "any need to apply the corrective actions referred to in Article 20." Article 20 covers corrective actions and duty of information — meaning your monitoring system must be able to trigger a decision about whether a deployed system needs to be updated, retrained, suspended, or removed from service.

Performance against intended purpose. The post-market monitoring plan must include metrics that test whether the system continues to perform within the parameters described in your technical documentation (Art.11). If a high-risk AI system is approved for a specific accuracy band, your monitoring must track whether it remains in that band under live conditions. Drift from the approved performance profile is a potential Art.73 trigger if the drift causes or could cause harm.

Harm signal detection. Art.72(3) specifies that the plan must include "an evaluation of the post-market monitoring data with respect to the risk and benefit assessments." In practice this means your monitoring must be sensitive to signals that users, deployers, or third-party feedback channels surface regarding negative outcomes attributable to the AI system. A closed-loop pipeline from user feedback and operational outcomes back to your monitoring store is required.

Documentation and record-keeping. Everything the monitoring system collects falls under Art.12 (record-keeping) and Art.19 (automatically generated logs). Your monitoring infrastructure is therefore not just an operational tool — it is a primary input to the technical documentation you will produce for regulators under Art.11.

What CRA Art.13 and Art.14 Actually Require

CRA Art.13 is titled "Obligations of manufacturers." Section 5 of Art.13 includes the post-market security monitoring obligation that is most operationally demanding for software teams.

Vulnerability handling policy. Manufacturers must establish and maintain a documented vulnerability handling process. This is not a one-time activity — it requires a live mechanism for receiving vulnerability reports (from internal security testing, external researchers, or automated scanning), triaging them, and tracking remediation progress.

Security updates over the support period. Art.13 requires manufacturers to deploy security updates for the entire expected support period of the product, which for software is typically defined by the manufacturer and documented as part of conformity. For SaaS AI systems this is effectively indefinite while the product is deployed. Your monitoring stack must identify vulnerabilities — including in third-party components via SBOM scanning — and initiate an update pipeline within timelines that satisfy Art.13.

CRA Art.14: the disclosure clock starts when you know. Art.14 is titled "Reporting obligations of manufacturers." Once a manufacturer "becomes aware" of an actively exploited vulnerability or of an incident with a significant impact on the security of the product, the 24-hour clock starts for the early warning to ENISA and the national CSIRT. The 72-hour clock then runs for the intermediate vulnerability notification. A final report follows within 14 days.

The critical operational question Art.14 creates: how does your monitoring system determine "awareness" triggering the clock? For human-reviewed alerts, awareness is the moment a human receives and does not immediately dismiss an alert. For automated systems, awareness is typically when the alert crosses a confirmation threshold and is marked for review. Your monitoring stack must implement a defined "awareness event" with an auditable timestamp — otherwise you cannot defend your disclosure timeline to regulators.

The Overlap: Why One Stack Serves Both

When you map the monitoring requirements side by side, the shared infrastructure requirements become clear.

Event collection layer. Art.72 needs a stream of AI performance telemetry (inference latency, accuracy proxies, output distribution, harm-signal events). Art.13/14 needs a stream of security events (vulnerability scanner findings, exploit detection alerts, dependency update triggers). Both streams flow into the same event collection infrastructure. Using OpenTelemetry as the collection layer and routing both streams to the same log aggregation backend (Loki, OpenSearch, Elastic on EU-hosted infrastructure) is the natural design choice.

Alert threshold system. Art.72 needs alert thresholds on performance metrics (drift, accuracy degradation, anomalous output patterns). Art.13 needs alert thresholds on security findings (CVSS score exceeding threshold, exploit-in-wild flag from EPSS). Both use the same alerting engine — Prometheus Alertmanager, Grafana, or equivalent. Write them as separate alert rule namespaces in the same system rather than two separate alerting stacks.

Triage and human review queue. Art.72 monitoring findings that exceed threshold require human review to determine whether a corrective action under Art.20 is needed. Art.14 findings that exceed threshold require human review to determine whether the 24-hour disclosure clock has started. In both cases, the human review queue is the same operation: an on-call engineer or compliance officer receiving a notification with sufficient context to make a regulatory decision. A single on-call rotation can cover both if the alert payload is designed to make the regulatory classification obvious.

Remediation tracking. Art.72 remediation (model update, parameter adjustment, deployer notification) and Art.13 remediation (security patch, SBOM update, CVE fix) are distinct processes, but both need a tracked work item with an SLA clock. One issue tracker with separate labels for "AI Act Art.72" and "CRA Art.13" violations satisfies both without the overhead of two separate compliance management systems.

Disclosure decision gate. Art.73 (AI Act serious incident) and Art.14 (CRA vulnerability/incident) both require a decision at the end of the monitoring pipeline: does this finding meet the threshold for regulatory disclosure? That decision logic is different for each regulation, but it can be implemented as two parallel rule checks executed against the same event payload. A single disclosure workflow system — a dedicated Slack channel, a dedicated Jira project, or a purpose-built compliance ticket type — can host both decision tracks.

Architecture: The Combined Monitoring Stack

Here is a concrete architecture that satisfies both regimes on EU-hosted infrastructure.

Tier 1: Data Collection

AI performance telemetry (Art.72 feeds)

Deploy OpenTelemetry SDK in your AI inference service. Collect:

• Inference latency (p50, p95, p99) per model version
• Input feature distribution statistics (for drift detection)
• Output distribution (softmax confidence, prediction class distribution)
• User correction or rejection events (if available from the deployer interface)
• Error and exception rates segmented by input type

Emit these as OpenTelemetry metrics and traces to a EU-hosted collector endpoint. For sota.io or any EU-native PaaS deployment, this means your OTel collector is on Hetzner Germany or equivalent EU infrastructure — which matters for Art.12 record-keeping jurisdiction.

Security telemetry (CRA Art.13 feeds)

Run three classes of scanner in your CI/CD pipeline and as scheduled background jobs:

1. Dependency vulnerability scanning: Trivy or Grype scanning your container images and code dependencies against CVE databases (NVD, OSV, GitHub Security Advisories). Run on every build and daily on deployed images.

2. SBOM freshness tracking: Generate an SBOM on every build (Syft or equivalent). Track whether the SBOM has changed since the last scan and whether any newly listed component has a known CVE above your threshold (typically CVSS ≥ 7.0 for intermediate alert, CVSS ≥ 9.0 for immediate disclosure review).

3. Runtime anomaly detection: Falco or equivalent runtime security tool monitoring for unexpected system calls, container escape attempts, and network behaviour anomalies in your AI serving infrastructure. This catches active exploitation — the Art.14 trigger — that static scanning misses.

Route all scanner output as structured events (JSON with CVE ID, CVSS score, component, EPSS score, exploit-in-wild flag) to the same OpenTelemetry collector, using a separate namespace from the AI performance telemetry.

Tier 2: Storage and Indexing

Store all events in a EU-hosted time-series and log backend. Concrete choices:

• Prometheus (metrics with 90-day retention for Art.72 performance data)
• Loki or OpenSearch (structured log events for security scanner output and incident records)
• MinIO on EU infrastructure (long-term archival of raw telemetry for Art.12 documentation)

The retention requirement is implicit from Art.72 (for the duration you are responsible for the product) and Art.31 (CRA technical documentation). Design for at least 5 years of queryable log retention plus cold archival for the expected product support period.

Tier 3: Alerting and Triage

Prometheus Alertmanager rules (Art.72 triggers)

groups:
  - name: ai_act_art72
    rules:
      - alert: ModelDriftHigh
        expr: model_accuracy_degradation_7d > 0.05
        for: 24h
        labels:
          severity: warning
          regulation: eu_ai_act_art72
        annotations:
          summary: "Model accuracy drift exceeds 5% over 7 days"
          action_required: "Review corrective action per Art.20"

      - alert: HarmSignalThreshold
        expr: increase(user_reported_adverse_outcomes_total[24h]) > 3
        for: 5m
        labels:
          severity: critical
          regulation: eu_ai_act_art72_art73
        annotations:
          summary: "Adverse outcome reports exceed threshold"
          action_required: "Art.73 serious incident assessment required"

Prometheus Alertmanager rules (CRA Art.13/14 triggers)

groups:
  - name: cra_art13_art14
    rules:
      - alert: CriticalCVEDetected
        expr: vulnerability_cvss_score >= 9.0 and vulnerability_exploit_in_wild == 1
        for: 1m
        labels:
          severity: critical
          regulation: cra_art14
        annotations:
          summary: "Critical CVE with active exploit detected"
          action_required: "CRA Art.14 24h ENISA notification clock starts NOW"
          awareness_timestamp: "{{ $value }}"

      - alert: HighCVEDetected
        expr: vulnerability_cvss_score >= 7.0
        for: 30m
        labels:
          severity: warning
          regulation: cra_art13
        annotations:
          summary: "High-severity CVE in production dependency"
          action_required: "Security patch within CRA Art.13 support obligations"

The awareness timestamp problem. For CRA Art.14 compliance, the moment the CriticalCVEDetected alert fires and is received by an on-call engineer without being dismissed is your awareness event. Implement an acknowledgement requirement in your alerting system: alerts must be explicitly acknowledged (not just silenced) with a timestamp that becomes the Art.14 clock start. Store this acknowledgement event in your compliance log with the engineer ID and timestamp.

Tier 4: Disclosure Decision Gate

When a critical alert fires and is acknowledged, route it to a compliance decision workflow:

For Art.73 candidates (AI Act serious incident assessment):

1. Create a compliance ticket with: alert details, affected AI system version, deployer information, preliminary harm category assessment
2. Assign to compliance officer for 24-hour assessment window
3. Decision: Serious incident (→ Art.73 notification to national competent authority within applicable deadline) / Performance issue only (→ Art.20 corrective action, no mandatory notification)
4. Log the decision with rationale for technical documentation

For Art.14 candidates (CRA vulnerability disclosure):

1. The awareness timestamp is already recorded in the alert acknowledgement
2. Create a compliance ticket with: CVE ID, CVSS, EPSS, exploit-in-wild status, affected component and version, SBOM snapshot
3. Art.14 early warning to ENISA within 24 hours of awareness (via ENISA's dedicated reporting platform)
4. Full vulnerability notification to ENISA within 72 hours
5. Final report within 14 days
6. Log all disclosure timestamps for Art.14 documentation obligations

When the same event triggers both: An actively exploited vulnerability in your AI inference engine that causes the AI to produce seriously harmful outputs triggers both Art.73 and Art.14. Your disclosure decision gate should detect this dual-trigger condition and create a combined compliance ticket that runs both tracks in parallel. The clocks are different (Art.73: 2/10/15 days depending on harm category; Art.14: 24h/72h/14 days), so the parallel tracks have different SLA deadlines even though they originate from the same event.

Tooling Stack Recommendations

For teams starting from zero on EU-native infrastructure:

The key constraint across this entire stack: every component that processes personal data from users, deployers, or AI system outputs must be deployed on EU-jurisdiction infrastructure to satisfy Art.12 record-keeping obligations under the EU AI Act, and to avoid the CLOUD Act exposure problem detailed in earlier posts in this series.

The Deadline Sequencing Problem

You have a six-week gap between the two activation dates:

2 August 2026: EU AI Act Art.72 post-market monitoring obligations apply. Your monitoring plan must be operational, your performance telemetry must be collecting, and your Art.72 alert thresholds must be live.

11 September 2026: CRA Art.14 reporting obligations apply. Your vulnerability scanning infrastructure must be operational, your awareness-event protocol must be defined, and your ENISA notification process must be tested.

The practical implication: Build the combined stack before 2 August. The AI performance monitoring components (Tiers 1-3 for Art.72 feeds) must be production-ready first. The CRA security monitoring components can be at late-stage testing on 2 August, but they must be fully operational by 11 September.

Do not treat these as two sequential projects. The shared infrastructure (OTel collection, Prometheus, Loki, Alertmanager) is the same for both. Stand it up once, bring up the Art.72 alert rules first, then layer in the CRA rules. You save approximately 40% of the engineering time compared to two separate implementations.

Gap Assessment: Are You Ready?

Work through this checklist for your deployed high-risk AI system. Each "no" is a gap that needs to be closed before August 2026.

Art.72 monitoring gaps:

• Performance metrics for my AI system are collected in a queryable store with >90-day retention
• I have defined numeric alert thresholds for accuracy drift, output distribution shift, and harm-signal events
• My monitoring plan is documented and attached to my Art.11 technical documentation
• I have a process for converting monitoring alerts into Art.20 corrective action assessments
• All telemetry data is stored on EU-jurisdiction infrastructure

CRA vulnerability disclosure gaps:

• I run automated vulnerability scanning on every build and at least daily on production
• I have an SBOM for my deployed system that is updated on every dependency change
• I have defined the "awareness event" protocol — how an engineer acknowledges an alert and starts the CRA Art.14 clock
• I have tested the ENISA notification process with a dry run
• I have a 14-day-capable documentation process for the final vulnerability report

Combined stack gaps:

• My Art.72 alerts and CRA Art.13/14 alerts route to the same on-call rotation
• I have a dual-trigger detection rule that identifies events qualifying under both Art.73 and Art.14
• My disclosure decision workflow produces auditable records for both regulatory tracks
• My monitoring infrastructure is on EU-hosted infrastructure with appropriate data residency documentation

What Comes Next in This Series

Post 5 (the finale) will synthesize all four prior posts into a complete dual-compliance developer checklist — a single reference document covering Art.15 cybersecurity requirements, unified incident reporting under Art.73 and Art.14, and the combined monitoring stack from this post. It will also cover the edge cases: what happens when your AI system is a GPAI model under Art.50 and also a CRA product, and how the August-to-September deadline gap should be staffed.

If your team is building the combined monitoring stack now, the architecture described in this post is designed to serve both compliance obligations without over-engineering. Start with the collection and alerting tiers — those are prerequisite for both deadlines — and add the disclosure decision gate last.

EU-native hosting matters here beyond mere jurisdiction compliance. When your monitoring data is on Hetzner Germany via sota.io, the telemetry itself — which may include user behaviour signals, output logs, and security scanner findings — is outside CLOUD Act reach. That is relevant not just for GDPR purposes but because Art.14 vulnerability disclosures to ENISA that include product telemetry should not be accessible to non-EU authorities through the hosting provider's US parent company. Architecture decisions made at the infrastructure layer enforce compliance properties that policy documents cannot.