How should organisations handle EU AI Act compliance when deadlines are split across different obligations?

Why This Matters for Security Teams

The EU AI Act does not behave like a single compliance date that can be tracked with one project plan. Different obligations land at different times, and some apply immediately because they govern prohibited uses, transparency duties, or general-purpose AI oversight. That means organisations need a structured obligation register, not a waiting strategy. The European Commission’s EU AI Act materials make clear that the regime is risk-based, which is useful for legal interpretation but operationally demanding.

Security, privacy, product, and legal teams often fall into the same trap: they assume the longest deadline governs the whole programme. That approach fails because one AI system can have multiple duties at once, including training-data governance, technical documentation, logging, human oversight, and post-market monitoring. For organisations running large portfolios, the real challenge is prioritisation by obligation type, not by department. Alignment with NIST Cybersecurity Framework 2.0 helps because it forces a control-based view of governance, risk, and continuous monitoring.

In practice, many security teams encounter AI Act non-compliance only after procurement, model deployment, or vendor onboarding has already occurred, rather than through intentional pre-launch governance.

How It Works in Practice

Operationally, the safest approach is to treat the EU AI Act as several parallel compliance tracks. One track covers prohibited or restricted use cases, another covers transparency obligations, another covers general-purpose AI duties, and another covers high-risk system readiness. Each track needs its own owner, evidence set, review cadence, and escalation path. That prevents a common failure mode where one team assumes another team is handling a requirement because the system is "already in scope."

A practical implementation model usually includes:

• An inventory of AI systems, including vendor tools, embedded features, and internal models.
• A classification step that maps each system to its applicable obligations and deadlines.
• A control library that links obligations to security, privacy, model governance, and assurance evidence.
• A remediation backlog with due dates tied to the nearest live requirement, not the broadest future deadline.
• Executive reporting that distinguishes readiness, implementation progress, and residual risk.

Current guidance suggests that this works best when AI governance is integrated with existing security controls rather than built as a separate island. For example, documentation, access control, logging, change management, and supplier assurance can be anchored in NIST SP 800-53 Rev 5 Security and Privacy Controls and an ISO-style management system, especially ISO/IEC 27001:2022 Information Security Management. For high-risk systems, this should include model provenance, dataset governance, testing records, human oversight procedures, and incident response hooks. The point is not only to pass an audit, but to prove that each obligation is owned, measurable, and continuously monitored. These controls tend to break down when AI is procured through decentralised business units because ownership, evidence, and vendor commitments become fragmented.

Common Variations and Edge Cases

Tighter compliance sequencing often increases administrative overhead, requiring organisations to balance faster assurance against the cost of maintaining multiple obligation tracks. That tradeoff becomes sharper when the AI estate includes third-party models, rapid-release products, or experimental use cases.

There is no universal standard for how to group overlapping AI Act duties into one operating model, so best practice is evolving. Some organisations use a legal-first taxonomy, while others start with technical risk tiers and map legal obligations onto them. Either can work if the mapping is consistent and auditable. The main edge case is a system that starts as a low-risk pilot but later becomes a customer-facing feature or a decision-support tool. In that situation, the classification must be revisited, because the compliance obligation can change faster than the deployment model.

Another common complication is supplier dependency. If a vendor claims conformity support but cannot provide enough documentation, the obligation still sits with the deploying organisation. For that reason, procurement clauses, assurance questionnaires, and change-notification terms should be treated as part of compliance design, not as a later contract cleanup. Where organisations handle identity, access, or regulated workflow data, the AI Act programme should also be aligned to broader trust and security controls, including ISO/IEC 27002:2022 Information Security Controls and, where relevant, sector rules such as AML or KYC governance. That is especially important when AI output influences regulated decisions or user onboarding.

Related resources from NHI Mgmt Group

• How should organisations prove EU AI Act compliance across the AI lifecycle?
• How should organisations govern AI use when responsibility is split across security, legal, HR, and compliance?
• How should organisations classify AI systems for EU AI Act compliance?
• How should organisations build an AI compliance strategy across multiple jurisdictions?