Ask a vendor whether their platform has governance and you will almost always hear yes. Ask what they mean and the answers diverge wildly: role assignments, resource inventory, content filters, quota controls, compliance reports. All useful. Most of it is not governance.
This is not vendors being slippery. It is a young category using a word before it settled on a definition. So here is ours, stated plainly enough to be argued with.
Governance is the ability to identify enterprise AI subjects, objects, actions, and context; assign ownership; express policy over their relationships; enforce that policy during operation; and preserve an auditable lifecycle.
Or, in the language a budget holder uses: governance answers who may use which enterprise AI capability, what that capability may know and do, under which business conditions, with whose approval, and with what accountability.
Why cloud IAM is not enough
Cloud identity and access management is excellent at its job, and its job is deciding which technical principal may perform which operation on which resource. Every enterprise needs that. It is a foundation.
Now try to express these in it:
- A claims specialist may use the claims assistant, but may not authorize a payment through it.
- This agent may retrieve approved policy documents, but not draft material.
- A refund above five thousand requires a manager's approval before it executes.
- A knowledge steward must sign off on a source before it reaches production.
- The support application may query customer records, but only for the customer currently in session.
None of these are resource permissions. Every one of them connects an identity to a business meaning, a permitted action, a context, and an accountable party. They are also, notably, exactly the rules an auditor asks about.
The missing subject
Here is the structural reason the gap exists. Most AI platforms model three kinds of identity: administrators, developers, and service identities. All three are people or processes that operate the platform.
What is usually missing is a model of the application's end users -- the thousands of employees or customers who will actually interact with what you built. If the platform has no representation of them, then no policy can be written about them, and every application team ends up inventing its own user model, its own permission scheme, and its own audit format. Ten teams, ten answers, and no way to ask a portfolio-wide question.
This is why an identity model is the load-bearing piece of AI governance rather than a checkbox. Without canonical principals and groups, "governance" can only ever mean resource control.
What we built
FireFoundry's Identity Service † provides a canonical model of principals, groups, and permissions that is deliberately independent of your identity provider. It works alongside whatever directory you already run rather than asking you to migrate to ours, and it gives policy something to name besides service accounts.
With that in place, the rest becomes expressible. Access control, policy and PII redaction, and human approval sit on the request path itself rather than being bolted on afterwards, and every step is written to the audit log. Knowledge access controls can name applications, agents, end users and groups †. Data access can reflect user identity and business purpose without making every end user a database principal.
Note the ordering. Governance is not a feature you add once the prototype succeeds. By then the architectural decisions are already in the code, credentials are distributed, and ownership is ambiguous. Retrofitting it is the expensive path, which is why it belongs in the second stage of the lifecycle and not the last.
† In beta or active development.
A fair concession
Cloud platforms are not failing at this. They are succeeding at something else. Their control planes are organized around their own resource models, which is the correct design for a cloud, and their IAM is genuinely good at governing cloud resources. The gap is not competence. It is that resource-level control and business-level policy are different problems, and only one of them is what your risk function is asking about.
Necessary foundations become governance only when they can express and enforce the enterprise's decisions about its own AI capabilities. Until then they are, precisely, foundations.
More on the definition and where it came from in Introducing FireFoundry, or see how it plays out across the lifecycle in What Production AI Actually Requires.