EU AI Act Compliance Automation Stack Finale: The Complete Developer Checklist for August 2026

Post #1586 in the sota.io EU AI Act Compliance Automation Series (5/5)

The August 2026 deadline for Regulation (EU) 2024/1689 is 55 days away. If you are building or deploying a high-risk AI system, or a general-purpose AI system with systemic risk, the four obligations covered in this series are not optional: post-market monitoring under Art.72, serious incident reporting under Art.73, technical documentation under Art.11 and Annex IV, and transparency obligations including GPAI content labelling under Art.50.

Each of those four areas has its own pipeline, its own tooling, and its own compliance evidence artefacts. The teams that will be in difficulty in August are not the ones who failed to read the regulation — they are the ones who built each pipeline independently, in isolation, with no shared data bus between them. An incident that your Art.73 pipeline detects should automatically update your Annex IV documentation. A model change that triggers your Art.72 monitoring should prompt a re-evaluation of your Art.50 watermarking configuration. A risk management update that your Art.9 process generates should flow into both your Annex IV records and your post-market monitoring plan.

This is the fifth and final post in the EU AI Act Compliance Automation series. The previous four posts cover the individual pillars: Art.72 post-market monitoring, Art.73 incident detection and reporting, Annex IV documentation automation, and Art.50 GPAI watermarking pipelines. This post shows how to connect them.

The Architecture of a Unified Compliance Stack

A unified compliance automation stack has three layers.

The evidence layer is where all compliance artefacts are produced and stored: monitoring metrics, incident records, technical documentation packages, watermarking audit logs, risk management outputs. Every artefact has a version, a timestamp, and a reference to the system version that produced it.

The event bus layer is what makes the stack coherent rather than just a collection of tools. When something changes — a model is retrained, an incident is detected, a risk threshold is crossed — an event propagates through the bus and every downstream system that cares about that event receives it. The Art.73 incident reporter publishes to the bus. The Annex IV documentation generator subscribes to incidents and triggers a documentation review. The Art.72 monitoring dashboard subscribes to model retraining events and resets its drift baselines.

The audit layer is where the evidence layer is read by regulators, auditors, and notified bodies. It is read-only, versioned, and complete. Every query to the audit layer returns the state of the system at a specific point in time, not the current state. This temporal completeness is what Art.15 requires when it demands that high-risk AI systems achieve appropriate levels of accuracy and robustness, and what Annex IV implicitly requires when it asks for a description of changes to the system over time.

Connecting Art.72 to the Rest of the Stack

Under Art.72, providers of high-risk AI systems must establish and document a post-market monitoring system and implement a post-market monitoring plan. The monitoring plan must be part of the technical documentation from day one, not added later.

The connection to the rest of the stack works as follows. Your Art.72 monitoring pipeline produces three categories of output:

Performance metrics: accuracy, precision, recall, F1, or whatever metrics are appropriate for the system. These metrics should be stored with the model version identifier, the dataset identifier, and the timestamp. When a metric falls below a defined threshold, the monitoring pipeline emits a performance_degradation event.

Drift signals: statistical distance between the distribution of production inputs and the distribution of training inputs. Tools like Evidently AI, Alibi Detect, or WhyLogs calculate this continuously. When drift exceeds a threshold, the monitoring pipeline emits a distribution_shift event.

Anomaly alerts: outlier detection, unexpected output patterns, high-confidence errors. When the monitoring pipeline detects a pattern that could indicate a serious malfunction, it emits a monitoring_anomaly event, which feeds directly into the Art.73 incident detection pipeline.

The Annex IV documentation generator subscribes to all three event types. When a performance_degradation event arrives, it triggers an update to Section 6 (testing and validation) of the Annex IV package, flagging that the current production accuracy differs from the documented baseline. When a distribution_shift event arrives, it triggers an update to Section 3 (training dataset description), flagging that the operational data distribution has deviated from the training distribution. Both updates are logged as pending human review actions, not automatic commits.

Connecting Art.73 to the Rest of the Stack

Art.73 requires providers of high-risk AI systems to report serious incidents to the market surveillance authorities of the Member States where the incident occurred. A serious incident means any incident that directly or indirectly causes death, serious harm to health, serious damage to property, or significant harm to fundamental rights.

Your Art.73 incident pipeline has two triggers: automatic triggers from your Art.72 monitoring (monitoring_anomaly events) and manual triggers from your incident response team. Both triggers enter the same pipeline and produce the same artefacts: an incident record with a unique identifier, a severity assessment, an impact assessment, a timeline of the incident, and the regulatory notification package.

The connection to the rest of the stack: every incident that reaches severity level P1 (serious incident under Art.73) automatically:

1. Creates a new entry in the Annex IV documentation under Section 4 (risk management), linking the incident to the risk management system record that was supposed to mitigate it.
2. Creates a new entry in the Annex IV documentation under Section 6 (testing and validation), recording that a real-world condition occurred that the test suite did not catch.
3. Emits an incident_closed event when resolved, which triggers the Art.72 monitoring pipeline to recalibrate its anomaly detection thresholds based on the incident characteristics.
4. For GPAI systems, emits a gpai_incident event that feeds into the Art.50 watermarking pipeline, which logs whether the content involved in the incident was properly labelled.

The key implementation detail: the regulatory notification package must be generated within the timelines specified in the DORA RTS guidance and the AI Office's operational guidance — initial notification within days of detecting a serious incident, not weeks after investigation. Your pipeline must generate a draft notification automatically at detection time, even if the final notification requires human review and approval.

Connecting Annex IV to the Rest of the Stack

Under Art.11, technical documentation must be kept up to date throughout the AI system's operational lifetime. Under Annex IV, that documentation spans eight sections covering the system description, development process, training methodology, risk management, human oversight, testing, standards applied, and capabilities and limitations.

The documentation generator connects to the rest of the stack by subscribing to events from every other pipeline:

• model_retrained from your ML pipeline → triggers Section 3 update (training methodology and datasets)
• model_deployed from your deployment pipeline → triggers Section 1 update (general description, version identifier)
• risk_assessment_updated from your Art.9 risk management system → triggers Section 4 update (risk management system description)
• performance_degradation from Art.72 monitoring → triggers Section 6 update (testing and validation)
• incident_closed from Art.73 pipeline → triggers Section 4 update (risk management, incident integration)
• watermarking_config_changed from Art.50 pipeline → triggers Section 2 update (system description, transparency mechanisms)

The output of the documentation generator is not a document. It is a structured object: a JSON or YAML file per Annex IV section, stored in your version control system, with a full history of every change. The "document" that auditors see is generated on demand from those structured objects. This means the documentation is always at a specific commit hash, which is also the commit hash of the system it describes.

Connecting Art.50 to the Rest of the Stack

Art.50 imposes transparency obligations on providers and deployers of certain AI systems — including systems that interact with natural persons, systems that generate synthetic audio or visual content, and GPAI systems placed on the market. For GPAI providers, Art.50(2) requires that outputs are marked in a machine-readable format and detectable as artificially generated content where technically feasible.

The C2PA watermarking pipeline connects to the rest of the stack in both directions. It receives model_deployed events and, for each new deployment, re-validates that the watermarking configuration is active and correctly configured for the deployed model version. It emits watermarking_audit_log events continuously, recording for each request: the request identifier, the model version, whether watermarking was applied, the C2PA manifest hash, and any exceptions (technically infeasible cases that must be documented).

The audit log connects to Annex IV Section 2 (system description, disclosure and transparency mechanisms) and to your Art.72 monitoring pipeline, which tracks the rate of technically-infeasible watermarking exceptions as a compliance metric.

The 55-Item Developer Checklist

The following checklist covers all four compliance automation pillars. Items marked [HARD DEADLINE] must be complete before 2 August 2026. Items marked [ONGOING] must be operational continuously after that date.

Art.72 Post-Market Monitoring

1. [HARD DEADLINE] Post-market monitoring plan documented in Annex IV Section 4 before first deployment
2. [HARD DEADLINE] Performance metrics defined and baselines established from validation dataset
3. [HARD DEADLINE] Monitoring thresholds set for performance degradation alerts
4. [ONGOING] Continuous drift monitoring running in production (daily at minimum)
5. [ONGOING] Monitoring pipeline emits structured events to compliance event bus
6. [ONGOING] All monitoring data retained with version and timestamp labels
7. [ONGOING] Monitoring data stored in EU-resident infrastructure (jurisdiction compliance for surveillance authority access)
8. [ONGOING] Human review workflow triggered for every threshold breach
9. [ONGOING] Monitoring results reported to Art.73 incident pipeline when anomalies exceed severity threshold
10. [ONGOING] Post-market monitoring plan reviewed and updated after every major model version change

Art.73 Incident Detection and Reporting

1. [HARD DEADLINE] Incident severity classification scheme defined and documented before deployment
2. [HARD DEADLINE] Draft notification template prepared for serious incidents in the languages of relevant Member States
3. [HARD DEADLINE] Contact details of national market surveillance authority identified for each deployment jurisdiction
4. [HARD DEADLINE] Internal escalation path defined: who reviews and approves regulatory notifications
5. [ONGOING] Incident records created automatically for all P1 events from Art.72 monitoring
6. [ONGOING] Every incident record includes: unique ID, timestamp, affected system version, impact assessment, affected users, and Member States involved
7. [ONGOING] Regulatory notification package generated automatically at P1 detection, pending human approval
8. [ONGOING] Incident record linked to risk management entry in Annex IV
9. [ONGOING] Post-incident review process feeds back into Art.72 monitoring thresholds
10. [ONGOING] Incident audit trail retained for minimum 10 years (aligned with Art.18 EU declaration of conformity retention obligations)

Annex IV Technical Documentation

1. [HARD DEADLINE] All eight Annex IV sections drafted and stored in version control before deployment
2. [HARD DEADLINE] Section 1: General description includes system version identifier linked to model registry
3. [HARD DEADLINE] Section 2: System architecture diagram generated from actual infrastructure (not hand-drawn)
4. [HARD DEADLINE] Section 3: Training dataset documented including provenance, licence, and bias assessment
5. [HARD DEADLINE] Section 4: Risk management system documented with risk register linked to Art.9 records
6. [HARD DEADLINE] Section 5: Human oversight mechanisms described with evidence that override capability exists
7. [HARD DEADLINE] Section 6: Test results documented with quantitative metrics, not narrative summaries
8. [HARD DEADLINE] Section 7: Standards applied listed; where no harmonised standard exists, alternative compliance pathway documented
9. [HARD DEADLINE] Section 8: Capabilities and limitations documented including known failure modes
10. [ONGOING] Documentation generator subscribed to all pipeline events that could trigger a required update
11. [ONGOING] Every documentation update creates a new versioned record in the audit layer
12. [ONGOING] Documentation review workflow triggered for every automated update (human approval required for material changes)
13. [ONGOING] Current documentation version linked to current model deployment version in model registry
14. [ONGOING] Documentation accessible to deployers under Art.13 in machine-readable format
15. [ONGOING] Documentation package exportable to national market surveillance authority in standardised format

Art.50 GPAI Watermarking and Transparency

1. [HARD DEADLINE] Technical feasibility assessment completed for watermarking on each output modality (text, audio, image, video)
2. [HARD DEADLINE] C2PA or equivalent manifest format implemented for technically feasible cases
3. [HARD DEADLINE] Technically infeasible cases documented with specific technical justification (not generic "not feasible")
4. [HARD DEADLINE] Disclosure mechanism implemented for AI-generated synthetic content visible to users
5. [HARD DEADLINE] Watermarking configuration included in Annex IV Section 2
6. [ONGOING] Watermarking applied at inference time, not as a post-processing step
7. [ONGOING] C2PA manifest hash logged for every output, linked to request identifier and model version
8. [ONGOING] Exception rate (technically infeasible cases) monitored as compliance metric in Art.72 dashboard
9. [ONGOING] Watermarking configuration re-validated after every model version change
10. [ONGOING] Audit log retained and queryable for regulatory review

Integration and Infrastructure

1. [HARD DEADLINE] Compliance event bus operational before first deployment
2. [HARD DEADLINE] All four pipeline integrations tested end-to-end in staging environment
3. [HARD DEADLINE] Audit layer accessible to compliance team without access to production systems
4. [HARD DEADLINE] All compliance data stored in EU-resident infrastructure
5. [HARD DEADLINE] Access controls to compliance data documented (who can query, who can modify)
6. [ONGOING] Event bus reliability: compliance events must not be lost on system failure (durable queue)
7. [ONGOING] Compliance pipeline health monitoring separate from application monitoring
8. [ONGOING] Quarterly compliance stack review: verify all integrations still functioning after infrastructure changes
9. [ONGOING] Annual review of all Annex IV documentation for accuracy against current system state
10. [ONGOING] Succession planning: compliance pipeline runbook maintained so any engineer can operate it

EU-Native Infrastructure Considerations

Several items in the checklist reference EU-resident infrastructure — monitoring data in item 7, incident records in item 20, all compliance data in item 49. This is not an optional recommendation. Compliance evidence that is stored on infrastructure subject to foreign jurisdiction orders (including the US CLOUD Act, which applies to AWS, Azure, and Google Cloud regardless of data centre location) creates a legal exposure: a foreign government could compel access to your compliance data without going through EU legal channels. For a system under supervision by EU national market surveillance authorities, that exposure is material.

Art.9 requires that the risk management system be continuous and iterative. That includes the risks associated with your compliance infrastructure, not just the risks of the AI system itself. If your Art.73 incident records are stored on AWS Frankfurt, your compliance data is legally reachable by US government order. That is a risk that belongs in your risk register.

EU-native managed infrastructure — where the provider has no US parent company and is not subject to CLOUD Act jurisdiction — avoids this exposure by construction. sota.io runs on Hetzner Germany with no US parent. Your monitoring data, incident records, technical documentation, and watermarking audit logs stay under EU jurisdiction.

The Timeline

The August 2026 deadline is not a soft target. Articles 6 to 49 of Regulation (EU) 2024/1689 — covering the requirements for high-risk AI systems including Art.9 (risk management), Art.11 (technical documentation), Art.13 (transparency), Art.14 (human oversight), and Art.15 (accuracy and robustness) — apply from 2 August 2026. Art.50 (transparency obligations for GPAI systems) applies from the same date. Art.72 (post-market monitoring) and Art.73 (serious incident reporting) apply from the same date.

Teams that begin their compliance automation work in July will not complete it. The 55-item checklist above has hard deadline items that require weeks of implementation, testing, and human review before they are complete. Infrastructure choices (item 49) take time to migrate. Annex IV documentation (items 21-29) cannot be written in a day if it is to be accurate.

The series is complete. The architecture is described. The checklist is specific. What happens next is an engineering decision.

This is the fifth and final post in the sota.io EU AI Act Compliance Automation Series. Previous posts: Art.72 Post-Market Monitoring, Art.73 Incident Detection, Annex IV Documentation Automation, Art.50 GPAI Watermarking Pipeline.