How should organisations use the extra time created by the EU AI Act amendments?

Why This Matters for Security Teams

The extra time created by the EU AI Act amendments is not a reason to pause; it is a chance to turn compliance into repeatable operating practice. Security teams often treat added runway as a documentation exercise, but the real gap is usually governance that cannot survive scale: no live inventory, unclear ownership, inconsistent risk acceptance, and approval steps that sit outside procurement and delivery workflows.

That matters because AI systems, especially those tied to data, tooling, or external models, tend to accrete risk faster than traditional software. If ownership and control evidence are assembled late, every review becomes a scramble. The better use of time is to make the process durable enough that the next model, vendor, or use case follows the same path without heroics. Guidance in NHIMG’s Ultimate Guide to NHIs - Regulatory and Audit Perspectives aligns with that approach: governance only becomes defensible when it is embedded into the lifecycle, not bolted on after deployment.

In practice, many security teams discover their AI readiness gap only after a product team is already asking for sign-off, rather than through planned control design.

How It Works in Practice

Use the extended timeline to move from ad hoc review to a control system that can be repeated for every AI initiative. Start with a live inventory that records the model, owner, business purpose, data sources, deployment context, and third-party dependencies. Then define the approval path for each risk tier so that procurement, legal, security, privacy, and product all know where decisions happen and who signs off.

The operating model should make evidence easy to produce. That means risk assessments, model cards where applicable, supplier attestations, and exception records are captured as part of the workflow rather than recreated for audits. Security teams should also map controls to an established baseline such as NIST SP 800-53 Rev 5 Security and Privacy Controls so that the organisation can translate AI governance into existing control language.

For implementation, the practical sequence is:

• Inventory all AI use cases, including shadow and pilot deployments.
• Assign named business and technical owners for each system.
• Embed risk review gates into procurement, architecture, and release workflows.
• Define evidence standards for approval, exception, and periodic reassessment.
• Track suppliers, data paths, and post-deployment monitoring obligations.

NHIMG’s coverage of the DeepSeek breach is a useful reminder that governance failures are rarely theoretical; they usually surface when exposed data, weak ownership, or unmanaged tooling creates an audit and security problem at the same time. These controls tend to break down when AI adoption is decentralised across many teams because no single workflow captures all models, vendors, and exceptions.

Common Variations and Edge Cases

Tighter AI governance often increases operational overhead, so organisations have to balance speed against assurance. That tradeoff becomes sharper when business teams want to ship pilots quickly, or when a vendor supplies most of the model stack and claims compliance coverage is already handled.

Best practice is evolving on where to draw the line for low-risk experimentation. Current guidance suggests lighter review for internal, non-sensitive proofs of concept, but that should not mean no inventory, no owner, and no exit criteria. The same applies to third-party AI services: if a supplier hosts the model, the customer still needs visibility into data use, retention, logging, and escalation paths. The right question is not whether the use case is “high risk” in abstract terms, but whether the organisation can prove who approved it, on what basis, and with what monitoring.

There is also a common edge case where legal, procurement, and security are aligned, but product delivery teams route around the process because the controls are too slow. That is usually a sign the workflow needs simplification, not exemption. If the extra time is spent refining only the policy text and not the execution path, the organisation will still be unable to show repeatable governance when deadlines arrive.

Related resources from NHI Mgmt Group

• How do organisations reduce the dwell time of exposed credentials at scale?
• How should organisations prove EU AI Act compliance across the AI lifecycle?
• Should organisations use just-in-time access for AI model operations?
• Should organisations use just-in-time access for AI development environments?