Organisations should separate AI governance into distinct control tracks for classification, disclosure, vendor evidence, and testing. When a delay applies only to high-risk systems, teams still need immediate controls for transparency, inventory, and documentation. The best programmes assign different owners and evidence requirements to each obligation instead of treating the AI Act as one uniform deadline.
How to split AI governance when obligations move at different speeds
When deadlines diverge, the practical answer is to govern by obligation, not by the statute as a single bundle. That means splitting classification, transparency, vendor evidence, testing, and approval into separate workstreams with separate owners, evidence, and due dates. The fastest-moving obligation should set the control cadence for the programme, while slower deadlines stay on their own track.
Why one AI programme should not share one deadline
AI regulation rarely lands evenly. Some duties become active earlier, while others are deferred for higher-risk systems, particular provider types, or later phases of enforcement. If organisations wait for the slowest deadline, they usually miss the immediate controls that create inventory, traceability, and accountability today. A single umbrella project also makes it too easy to hide which obligation is actually late.
Different deadlines usually reflect different control intent. Disclosure and documentation are about visibility, classification is about scoping, vendor evidence is about assurance, and testing is about proving safety or compliance before use. Those are related, but they are not the same control problem, so they should not share one owner, one checklist, or one acceptance decision.
AI Governance Guide is the right starting point when you need to turn a broad AI programme into named roles, use-case registers, oversight, and lifecycle controls.
What a split-control operating model looks like
A workable model assigns each obligation to the team best able to close it. Legal or policy teams usually own classification and disclosure rules. Risk, security, or model governance teams usually own testing evidence and approval gates. Procurement or third-party risk teams usually own vendor evidence and contractual follow-up. Business owners still need to supply the facts, but they should not be the only control owners.
The key design choice is to separate evidence from implementation. A system can be in scope for immediate inventory and disclosure controls even if its deeper testing or higher-risk obligations have a later deadline. That means the organisation can show what it has, who owns it, what data or model is involved, and what evidence exists, without pretending every downstream control is already complete.
AI Governance Platform Buyer's Guide is useful where the hard part is operationalising inventory, classification, and evidence capture across many systems.
How to avoid deadline drift and false compliance
The most common failure is treating “not yet due” as “not yet needed.” That creates blind spots in inventories, weak audit trails, and missing ownership records, especially when a later phase depends on proof that earlier controls already existed. Organisations should therefore separate “this obligation is deferred” from “this control is optional,” because those are not the same thing.
Another trap is using one control owner for everything. If the same team owns the register, the disclosure statement, the vendor questionnaire, and the testing sign-off, deadlines can blur together and exceptions become hard to challenge. Split ownership makes it easier to prove which obligation is delayed, which is live, and which evidence still needs to be collected.
EU AI Act regulatory framework is the authoritative reference for understanding why different obligations and timelines can coexist inside one programme.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST AI RMF, OWASP ASVS, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 42001:2023 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 42001:2023 | 4.1 — Understanding the organization and its context | AI deadline splitting depends on context-specific governance and phased obligations. |
| Recommendation — Separate AI obligations into owned control tracks with evidence by deadline. | ||
| NIST AI RMF | GV.1 — Govern the AI risk management process | The question is about organising governance across differently timed AI obligations. |
| Recommendation — Assign distinct owners and evidence requirements to each AI obligation. | ||
| OWASP ASVS | V16 — Security Logging and Error Handling | Immediate transparency and documentation controls depend on reliable logging and traceability. |
| Recommendation — Capture auditable evidence for classification, disclosure, and testing decisions. | ||
| NIST SP 800-53 Rev 5 | PM-30 — Supply Chain Risk Management Plan | Vendor evidence and assurance are part of governing third-party AI dependencies. |
| Recommendation — Require separate vendor evidence and review it before relying on supplier claims. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Splitting AI governance by obligation is a risk-management strategy for staggered deadlines. |
| Recommendation — Set deadline-specific control owners and track compliance separately. | ||
Practitioner Guidance
Decision rule: If an obligation affects visibility, inventory, or disclosure, treat it as an immediate control track even when higher-risk testing or approval duties are deferred. If a later-phase control depends on earlier evidence, do not allow the later deadline to delay the earlier control.
What to verify: Confirm that each obligation has a named owner, a separate evidence set, and a distinct due date. If any one of those is shared across multiple obligations, the programme is probably too blurred to audit cleanly.
What good looks like: A reviewer can open the register and see which systems are classified, which disclosures are complete, which vendor artefacts are missing, and which tests are still pending without needing to infer status from a single programme plan.
NIST AI Risk Management Framework helps structure the governance logic so that mapping, measurement, and monitoring are not collapsed into one milestone.
Practitioner takeaway: The safest way to handle staggered AI deadlines is to run parallel control tracks, because the moment you merge them into one timeline, visibility and accountability start to fail.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org