Who is accountable for AI Act compliance when guidance changes over time?

Why This Matters for Security Teams

AI Act compliance is not a one-time legal interpretation exercise. Guidance changes, delegated acts evolve, and implementation expectations can shift as regulators publish clarifications. That means accountability has to be anchored in the organisation’s operating model, not in a temporary reading of the law. The practical question is who owns the control, who signs off on evidence, and who drives remediation when requirements are reinterpreted.

This is where many programmes fail. Legal may track the rule text, privacy may own data impact assessments, security may own technical safeguards, and AI governance may manage model approvals, but none of those functions alone can absorb the whole obligation. A stable accountability model needs named owners for inventory, classification, documentation, monitoring, and change management. The NIST Cybersecurity Framework 2.0 is useful here because it treats governance as an ongoing discipline rather than a static compliance event.

For AI Act programmes, the strongest control designs assume that guidance will change and that evidence will need to be refreshed without waiting for a new project cycle. In practice, many security teams encounter accountability gaps only after a regulator, auditor, or incident forces a reclassification or remediation decision, rather than through intentional governance review.

How It Works in Practice

Operational accountability should be mapped to a control owner model with clear escalation paths. The business owner remains accountable for the AI system’s intended use and risk acceptance. Legal and privacy own interpretation, notification thresholds, and regulatory alignment. Security owns technical safeguards, monitoring, and incident handling. AI governance or model risk teams coordinate classification, documentation, and lifecycle reviews. Enterprise risk or compliance should track unresolved gaps and report them upward.

That division of labour works best when it is backed by evidence and change control. Organisations typically need a living inventory of AI systems, a risk classification record, a documentation pack, approval logs, and a cadence for reassessment when guidance changes. The control set should be tied to a recognised management system such as ISO/IEC 27001:2022 Information Security Management and supported by specific safeguards from NIST SP 800-53 Rev 5 Security and Privacy Controls.

• Assign one accountable executive for AI governance, then name separate control owners for legal, privacy, security, and model risk.
• Maintain a system inventory that records use case, model type, data sources, deployment context, and regulatory classification.
• Route regulatory updates through a formal change process so control text, evidence templates, and approval criteria can be revised consistently.
• Keep a decision log that shows why a system was classified a certain way at a certain time.
• Test whether monitoring, documentation, and incident response still match the current guidance after each major interpretation update.

The accountability model should also preserve auditability across the full lifecycle, from initial assessment to decommissioning. These controls tend to break down when AI systems are distributed across business units with no central inventory, because no single team can prove which guidance applies or who approved the latest control interpretation.

Common Variations and Edge Cases

Tighter governance often increases coordination overhead, requiring organisations to balance regulatory precision against delivery speed. That tradeoff becomes more visible when guidance is still maturing, because teams may be tempted to wait for certainty before assigning accountability. Current guidance suggests that waiting is the wrong move: accountability should be fixed early, while the interpretation layer remains revisable.

There is no universal standard for how often AI Act interpretations must be re-reviewed, so organisations should set a review cadence based on risk, change frequency, and supervisory exposure. High-risk systems usually need more frequent review than internal productivity tools. Where the AI system supports identity workflows, fraud screening, or customer decisions, the accountability model should also reflect adjacent obligations such as privacy, consumer protection, or financial controls. In those environments, compliance ownership may overlap with digital identity governance and, in some cases, AML or KYC oversight. The ISO/IEC 27002:2022 Information Security Controls helps translate that overlap into practical control expectations.

For organisations with cross-border deployments, the best practice is to maintain a core accountability model and then layer jurisdiction-specific obligations on top. That avoids rebuilding ownership every time guidance changes, while still allowing local legal review. If the system is part of a regulated service, mapping to the EU AI Act should be coordinated with broader governance controls, not treated as a standalone legal task.

Related resources from NHI Mgmt Group

• Who remains accountable when AI-assisted onboarding recommends configuration changes that administrators must approve?
• Why does over-retained data create a larger security and compliance burden for AI programmes?
• Who is accountable for reducing over-retained data when business, security, and compliance teams all depend on it?
• Who is accountable when AI-assisted code changes affect compliance evidence?