Start by mapping each AI system to the laws and sector rules that already apply to it, then separate facility compliance from model governance. If the framework regulates the building but not the system, the first control is a reliable inventory of deployed use cases and a named owner for each one.
Start with the rules already governing the system, not the building
When a new AI framework only addresses infrastructure, the first job is to identify which laws, sector rules, contractual duties, and internal policies already govern each AI system. That creates the real control boundary. A facility or platform standard may shape hosting and operations, but it does not automatically answer who owns the system, what the system is allowed to do, or which use cases are in scope.
That distinction matters because AI risk usually lands at the system and use-case level, not the rack, cluster, or data centre level. If you treat infrastructure compliance as enough, you can end up with strong building controls and weak oversight of deployed models, prompts, data flows, and business decisions.
A useful first step is to map each system to the applicable legal and sector obligations, then note where the infrastructure framework overlaps and where it stops. For broader AI governance structure, AI Governance Guide gives the control-plane view that sits above infrastructure, while NIST AI RMF Guide helps separate governance, mapping, measurement, and management from pure hosting concerns.
Why inventory and ownership come before framework alignment
If the framework regulates the building but not the system, the first practical control is a reliable inventory of deployed use cases and a named owner for each one. Without that, teams cannot tell which models are in production, which business process they support, which data they touch, or which exceptions have been granted informally. The inventory is what turns an abstract policy discussion into something auditable.
This is also the point where organisations should separate facility compliance from model governance. Facility compliance answers whether the environment is acceptable. Model governance answers whether a specific AI system may be used, by whom, for what purpose, under what review, and with what accountability. Those are different decisions, and they should not be collapsed into a single infrastructure sign-off.
For an operating model that treats use cases, roles, and decommissioning as first-class governance objects, the AI Governance Guide is the closest internal reference point. It reinforces the idea that the inventory is not a spreadsheet exercise, it is the control record that makes ownership and review possible.
Where AI systems depend on hosted pipelines, registries, notebooks, or inference endpoints, the AI Infrastructure Workload Identity Guide becomes relevant once the inventory exists, because infrastructure governance is only useful if you can still identify which workload is acting, which credentials it uses, and which platform component it depends on.
What practitioners should do when the framework stops at infrastructure
The correct response is not to wait for a fuller standard. Start with scoping, then layer the rest of the governance. That means mapping each use case to its legal and sector obligations, recording the accountable owner, and documenting any gap between the infrastructure framework and the actual system risk. If the framework does not address model behaviour, data use, human oversight, approval thresholds, or retirement, those topics need to be governed elsewhere.
In practice, the first decision rule is simple: if you can describe the AI system only in terms of hosting, you do not yet have enough governance to rely on the framework alone. You need an inventory that can survive audit, incident response, and change management. You also need a path to review exceptions, because infrastructure controls rarely capture business justification or downstream impact.
For organisations building the control stack around AI deployments, the AI Security Maturity Model is useful for seeing how inventory, ownership, and governance fit into a broader operating model. At the external level, ISO/IEC 42001:2023 AI Management System Standard is the most direct authority for distinguishing AI management from infrastructure management.
Risk and Threat Considerations
When organisations mistake infrastructure compliance for AI governance, the main risk is blind spots: systems get deployed, but no one can prove who approved them, what obligations apply, or whether the use case is still acceptable. That creates exposure not only to policy failure, but also to unmanaged data use, unsafe business decisions, and control gaps during incidents or audits.
Failure mechanism: The framework covers the environment, but not the deployed AI system, so ownership, scope, and accountability remain implicit and can be bypassed through informal deployment.
Impact: Teams may pass infrastructure reviews while shipping ungoverned AI use cases that lack clear approval, monitoring, decommissioning, or legal mapping.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets 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 systems must be mapped to applicable legal and sector obligations. |
| 5.2 — AI policy | A policy is needed to separate facility compliance from AI system governance. | |
| 8.1 — Operational planning and control | Operational control depends on a reliable inventory and accountable ownership. | |
| Recommendation — Map each AI system to its legal and sector obligations before treating infrastructure controls as sufficient. Define an AI policy that distinguishes platform compliance from model governance responsibilities. Maintain an auditable inventory of AI use cases and assign a named owner for each one. | ||
| NIST SP 800-53 Rev 5 | PM-5 — System Inventory | A current inventory is the first control when system scope is unclear. |
| CA-6 — Authorization | AI use cases need formal authorization beyond infrastructure approval. | |
| Recommendation — Maintain a current inventory of AI systems and their responsible owners. Authorize each AI system separately instead of relying on infrastructure sign-off alone. | ||
Practitioner Guidance
What to prioritise: Build the inventory first, then assign a named owner, a business purpose, and the governing rule set for each AI system. If those three items are missing, any further framework mapping will be incomplete.
What to verify: Confirm that every deployed use case has an accountable owner who can answer where it runs, what it does, which rules apply, and when it must be reviewed or retired. If the answer is “the platform team,” ownership is probably too vague.
Practitioner takeaway: Infrastructure controls are a starting line, not a substitute for AI governance, and the earliest reliable control is an auditable system inventory tied to explicit ownership.
Related resources from NHI Mgmt Group
- Should organisations prioritise external exposure or internal credential governance first?
- How should organisations govern AI use without writing a huge new policy first?
- When should organisations use traditional FinOps controls for AI infrastructure, and when do they need new governance rules?
- What should organisations do first when an AI service is hit by an apparent DDoS attack and new registrations are disrupted?