When AI governance lands on an organization, it usually gets routed to whoever is closest to the models. That instinct is understandable and mostly wrong.
The hard questions are not about architecture. They are about what data may be sent where, under what terms, retained for how long, and who is accountable when the answer turns out to be wrong. That is third-party risk management, data governance, and policy enforcement. GRC has been doing this work for twenty years.
The actual problem: nobody's terms agree
Here is what governing AI usage looks like in practice. Your organization is using — knowingly or otherwise — a handful of model providers and a much larger number of tools with AI features embedded in them. Each one has its own position on:
- Whether your inputs are used to train their models
- How long prompts and outputs are retained, and whether that is configurable
- Which sub-processors see the data, and in what jurisdictions
- Whether enterprise-tier terms differ from the default terms
- What happens to data in the event of an incident or a subpoena
None of these are standardized. The terms change. And the difference between a provider that trains on your data by default and one that contractually does not is the difference between an acceptable tool and a data-loss incident with a EULA attached.
Reconciling a dozen sets of provider terms into one enforceable internal policy is not a novel discipline. It is vendor risk review with unfamiliar vocabulary.
Why the "just ban it" phase fails
Most organizations pass through a stage where the official policy is restrictive and the actual behavior is not. People find the tools useful, the tools are one browser tab away, and a policy nobody can comply with while doing their job is a policy that generates shadow usage rather than preventing it.
The version that works is narrower and more honest: name the tools that are approved, state clearly what classes of data may go into each, and make the approved path genuinely easier than the unapproved one.
What the policy needs to actually say
Vague principles — "use AI responsibly," "maintain human oversight" — are unenforceable. A usable AI usage policy answers concrete questions that someone can check themselves against in ten seconds:
- Which tools are approved, by name. Not "enterprise AI assistants." The specific products, with the specific tier, because free and enterprise tiers often have different data terms.
- What data may go in, by classification. Tie this to your existing data classification scheme. If you do not have one, that is the actual first project.
- What must never go in. Customer data covered by a DPA, regulated data, credentials, anything under a confidentiality obligation that does not permit sub-processing.
- Where human review is mandatory. Anything that reaches a customer, a regulator, or an auditor.
- How to get something new approved. If there is no path, people will skip the process entirely.
Building AI into a product raises the bar
Internal usage policy is the easier half. If your organization ships AI features to customers, you inherit a second set of obligations — and your customers will start asking about them in security questionnaires long before any regulator does.
Expect to be asked, in writing:
- Whether customer data is used to train or fine-tune any model
- Which sub-processors are in the inference path, and where they run
- How model outputs are logged, and for how long
- What the customer's options are for opting out
- How you evaluate and monitor for harmful or incorrect output
These questions arrive through the same channel as every other due-diligence request. If your AI governance documentation is not written in a form your questionnaire responders can quote from, you will answer each one from scratch, inconsistently.
Map to what you already have
The most useful move I have found is refusing to treat AI governance as a greenfield program. Most of what it requires already exists somewhere in your control set:
- Vendor review already handles new-provider onboarding — extend the questionnaire
- Data classification already defines what is sensitive — reference it, do not reinvent it
- Change management already governs what ships — model changes are changes
- Incident response already has a playbook — add the AI-specific failure modes
- Access control already governs who can reach what — AI tooling is a system like any other
Frameworks like the NIST AI Risk Management Framework and ISO/IEC 42001 are useful for structuring the conversation, but neither requires you to start over. They map onto controls you are already operating.
The uncomfortable truth
AI governance is mostly unglamorous work: reading terms of service, maintaining a tool inventory, writing plain-language guidance, and re-reading those terms when they change — which they do, frequently and quietly.
It is not a research problem. It is a program you have to actually run. And that is precisely the thing GRC teams are already good at.