The first practical step is to identify every AI system in use, including chatbots, models, and agents, then prioritise the highest-risk deployments. After that, map the relevant obligations, assign ownership, and close gaps in data quality, testing, transparency, and oversight. Starting with critical systems prevents wasted effort and gives leaders a realistic compliance roadmap.
Where teams should begin with EU AI Act readiness
The right first move is not a policy workshop in isolation. Teams need an inventory of every AI system that already exists in the business, including embedded features, external services, internal models, and agentic workflows, because compliance obligations depend on what is actually being used. The EU AI Act regulatory framework is built around risk and role, so a discovery-first approach helps teams avoid treating all AI as one category.
That inventory should be more than a technical list. It should capture who owns each system, what it does, what data it touches, whether it affects employees, customers, or regulated decisions, and whether it may fall into a higher-risk category. Once teams can see the portfolio clearly, they can prioritise the systems most likely to create legal, operational, or trust exposure and avoid wasting time on low-impact use cases while critical gaps remain open. In practice, many organisations discover their highest-risk AI use cases only after procurement, shadow IT, or product teams have already embedded them into live workflows.
How the first compliance step works in practice
Preparation begins with system discovery, then moves into classification. The practical question is not simply “Do we use AI?” but “Where is AI making, supporting, or influencing decisions, and with what level of impact?” That means scanning across business units, procurement records, cloud platforms, model registries, and vendor contracts to identify anything that behaves like an AI system, even if the organisation did not centrally procure it. If the inventory is incomplete, the rest of the compliance plan will be unstable from the start.
After discovery, teams should group systems by risk and obligation. Some systems will only need lightweight governance, while others may require deeper documentation, testing, human oversight, traceability, transparency, or post-market monitoring. The value of the first pass is not perfection. It is to distinguish obvious low-risk uses from systems that could create higher legal exposure if they are left unreviewed. That is why ownership matters early: every system should have a named business owner and a technical steward, otherwise gaps in data quality, logging, validation, and escalation will be missed.
Good preparation also requires checking the evidence trail. Teams should ask whether they can show where the system came from, what data trained or informed it, who approved deployment, and what controls exist around outputs and exceptions. For high-impact use cases, that evidence is part of the compliance posture, not an afterthought. If the organisation cannot trace the system’s purpose, data sources, and decision path, it is not ready to defend the system under scrutiny.
- Discover all AI-enabled tools, including hidden or vendor-supplied functions.
- Classify systems by likely risk level and business impact.
- Assign a named owner for each system before remediation work begins.
- Record the minimum evidence needed to explain use, oversight, and accountability.
This approach breaks down when teams try to rely on one central spreadsheet without business input, because risk classification depends on operational context, not just the model name.
When the “first step” changes for edge cases
Tighter AI oversight often increases coordination overhead, so organisations have to balance speed against the cost of reclassifying every prototype or third-party feature. In practice, that tradeoff is manageable if teams use a triage model rather than a blanket deep review. Experimental tools with no live business impact can sit in a lighter intake queue, while systems that affect hiring, customer decisions, safety, finance, or other regulated outcomes move straight into formal assessment.
There is also a genuine consensus gap in the market around borderline cases such as productivity assistants, embedded analytics, and hybrid agent workflows. Some teams assume these are low risk because they look like ordinary software. Others over-classify them and lose time. The better rule is to treat the system’s actual function and downstream effect as the deciding factor. If the AI can influence a decision, automate a workflow step, or shape an outcome in a way that matters to people or the business, it should be treated as part of the compliance inventory.
One further edge case is supplier dependence. A model or agent provided by a third party still creates obligations if it is deployed under the organisation’s brand, controls, or decision processes. The first step is still discovery, but the inventory must include externally hosted and embedded capabilities that the business relies on, not just internally built systems. That is especially important where teams assume the vendor will handle everything for them.
Risk and Threat Considerations
The main risk in early eu ai act preparation is not starting too slowly, but starting with an incomplete picture. Hidden AI use, fragmented ownership, and poor system classification can leave organisations exposed to regulatory non-compliance, weak oversight, and inconsistent controls over higher-risk deployments. The same discovery gap also creates operational and trust risk when teams cannot explain which systems influenced a decision or where accountability sits.
Failure mechanism: Shadow AI, embedded vendor features, and unowned prototypes bypass central governance until they are already in production. At that point, the organisation may lack the records, testing evidence, transparency measures, and escalation paths needed to classify the system correctly or prove it was controlled as intended.
Impact: Teams can miss higher-risk obligations, misstate their inventory, or fail to identify systems that need deeper review. The result is delayed remediation, inconsistent oversight, and a weaker position if regulators, auditors, customers, or internal assurance functions ask how the organisation manages AI use.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST AI RMF, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while EU AI Act and ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| EU AI Act | GOV-02 — AI System Inventory and Governance | EU AI Act readiness starts with identifying and classifying AI systems. |
| Recommendation — Build and maintain a complete AI system inventory before assigning compliance obligations. | ||
| ISO/IEC 42001:2023 | 4.1 — Understanding the organization and its context | AI management systems begin with context, scope, and system identification. |
| Recommendation — Define AI scope and ownership before extending governance controls. | ||
| NIST AI RMF | GOV-1 — Governance | AI governance requires accountable oversight and role clarity for AI use. |
| Recommendation — Establish accountable AI governance to route systems into the right review path. | ||
| NIST CSF 2.0 | ID.AM-1 — Physical devices and systems are inventoried | Inventory discipline is the first step in understanding AI exposure. |
| Recommendation — Inventory AI-enabled systems so downstream risk decisions rest on known assets. | ||
| CIS Controls v8 | 1.1 — Inventory of Enterprise Assets | Asset inventory is the operational precursor to AI compliance scoping. |
| Recommendation — Maintain an authoritative inventory of AI-related assets and services. | ||
Practitioner Guidance
What to prioritise: Start with a business-wide AI inventory, not a model inventory. The useful unit of analysis is the system in use, including embedded tools, vendors, and agents that can affect real outcomes.
Decision rule: If a use case can influence a regulated, customer-facing, employee-facing, or safety-relevant decision, treat it as priority one for classification and ownership. If it cannot, keep it in the lighter discovery stream until more context is available.
What good looks like: Each system has a named owner, a defined purpose, a risk view, and enough evidence to explain why it was classified the way it was. If any of those are missing, the compliance programme is still at the inventory stage.
Practitioner takeaway: The first real control is visibility, because teams cannot govern what they have not found, and they cannot prioritise what they have not classified.
Related resources from NHI Mgmt Group
- How should security teams structure EU AI Act compliance for AI systems?
- How should enterprises prepare for EU AI Act compliance in regulated AI programmes?
- How should AI teams monitor EU AI Act compliance in production?
- How should security teams prepare AI governance workflows for EU AI Act audits?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
