Your Employees Are Already Using AI Tools Nobody Approved. That's Where Most Real Usage Actually Lives.

It depends on your role (provider or deployer) and the risk tier of each system, obligations range from AI literacy, which is already active, to heavy high-risk requirements phased in later over the coming years. There's no single answer that applies to a whole organisation at once; the honest answer requires classifying each AI system individually before the specific obligations become clear.

In phases, AI literacy and generative-AI transparency apply now; the strictest requirements for high-risk systems apply later, on a staggered timeline set out in the regulation itself. Treating the Act as a single deadline rather than a phased set of obligations is a common and costly misreading, since some requirements are already enforceable while others still have runway to prepare for properly.

Determined per AI application based on whether you built or market the system or simply use it within your own operations, most organisations are deployers for most of their tools, but that's not automatically true for every system, particularly any internally built or heavily customised applications. The classification has to be checked system by system, not assumed for the organisation as a whole.

Combine department interviews, an employee survey, procurement or licensing desk research, and IT usage signals, no single source catches everything, and relying on just one typically misses a significant share of what's actually in use. Department interviews reveal what people know they're using; employee surveys and IT signals tend to surface the tools nobody thought to mention because they'd stopped thinking of them as separate from their normal workflow.

Score each application against the Act's four tiers, unacceptable, high, limited, or minimal risk, based on what the system actually does and who it affects, rather than on how sophisticated or novel the underlying technology seems. A simple system used in a high-stakes context can carry more regulatory risk than a sophisticated one used somewhere low-stakes, which is why classification has to follow use case, not technical complexity.

A currently active requirement to ensure staff understand the AI systems they use, met through role-specific training with registration to prove completion, rather than a single generic training session delivered once to the whole company. Registration matters because the obligation isn't just to provide training; it's to be able to demonstrate, if asked, that the right people actually completed it.

Include them in the inventory via a survey and IT signals rather than only official lists, this is usually where most real usage lives, precisely because it happened outside whatever approval process exists. Treating unapproved usage as something to punish rather than something to inventory tends to just push it further underground, making the actual risk picture harder to see rather than easier.

Define this explicitly per system in the governance framework, roles, escalation paths, and human oversight points must be assigned in advance, because trying to work out accountability after something has already gone wrong is a much harder and more contentious conversation than deciding it calmly beforehand. Every system in the inventory should have a clear answer to this question attached before it goes into production use.

Define which decisions require human sign-off and when, integrated into your existing risk and compliance structure rather than built as a separate parallel process specific to AI. Human oversight that's bolted onto an existing risk framework tends to get maintained; oversight built as its own standalone system tends to be the first thing that quietly stops happening once initial attention moves elsewhere.

Governance and controls, human oversight rules, roles and escalation paths, and ongoing monitoring, aligned to your existing risk process, rather than a standalone document written to satisfy a compliance checkbox and then never referenced again. A policy that isn't integrated into how the organisation already manages risk tends to exist only on paper, disconnected from how AI systems are actually being used day to day.

Maintain a traceable register, which systems, which risk category, who owns them, which obligations are met, and where open risk remains, updated on an ongoing basis rather than assembled retroactively when a regulator actually asks. A register built only when needed is usually incomplete and out of date; one maintained continuously as part of normal governance is the version that actually holds up under scrutiny.

Build monitoring into the governance framework from the start, so it keeps running post-launch rather than stopping once the project closes and everyone's attention moves to the next initiative. A system that was carefully governed during rollout but never monitored afterward tends to drift quietly out of compliance as usage patterns and underlying data change over time.

Yes, standard tools still process company data and support decisions, and the inventory and classification obligations apply regardless of whether you built the system yourself or simply subscribed to it. Using a well-known commercial tool doesn't exempt an organisation from classifying how it's used or ensuring the right oversight is in place around the decisions it influences.

Integrate it into your current structure rather than building a second, parallel process, a standalone AI governance track gets ignored within a year, typically once the initial compliance push that created it has faded from priority. Governance that lives inside the same structure your organisation already uses for other risk types tends to survive because it's maintained by the same ongoing discipline, not a separate one-off effort.

A short, traceable summary, which systems run, in which risk category, who owns them, which obligations are met, and where the open risk sits, rather than a lengthy technical report most board members won't have time to work through in detail. The goal is a board being able to answer, with confidence, whether the organisation actually knows its own AI risk picture, not a comprehensive audit trail for its own sake.