Generative AI governance in the enterprise: roles, rules, logs and costs
Governing generative AI is not about writing a charter and hoping people read it. It means deciding who can use which models, with which data, on what budget, and being able to prove it afterwards. This guide sets out the six workstreams that turn scattered usage into an enterprise service.
Published September 22, 2026
What generative AI governance covers
Generative AI governance is the set of decisions and controls that frame its use across the organisation: who may use it, with which tools, on which data, for which actions, at what cost, and with what record. It differs from data governance, which often already exists, on one point: the model does not just store information, it rewords it, combines it and can act on it.
Three properties make the subject unusual:
- Usage is diffuse. A generative AI tool opens in a browser, with no IT project and no dedicated budget. Usage almost always comes before the decision.
- Cost is variable. Billing by volume of text processed grows with usage, sometimes sharply when an agent chains calls.
- Output is probabilistic. A plausible answer can be wrong. Governance must therefore cover what the model produces as much as what it receives.
Roles, the usage policy, the catalogue of approved models.
Access to models, to document sources and to connected tools.
A record of who asked what, with which model, for which action.
The budget, the caps and the tracking of consumption.
Governance is judged on one thing only: the ability to answer these questions with facts, not intentions. A signed charter with no log and no access control answers none of them.
Roles: who decides what
The most common mistake is to hand the subject to a single function. IT treats it as a tooling project, legal as a risk, the business as an opportunity, and each decides in its own corner. A governance model that holds up assigns decisions explicitly.
| Function | What it decides | What it must not decide alone |
|---|---|---|
| Executive management | Objectives, accepted level of risk, overall budget | The choice of models |
| IT department | Architecture, model catalogue, operations, integration with existing systems | Priority business use cases |
| CISO | Security rules, which data classes are admissible, access reviews | The usage budget |
| DPO | Compliance of personal data processing, impact assessments | The technical architecture |
| Business units | Use cases, expected value, validation of results | Onboarding new providers |
| AI champions | Supporting users, reporting needs and incidents | Exceptions to the policy |
Two additions make this split work. First, a small committee that brings these functions together at regular intervals and rules on requests: a new use case, a new model, a new connector. Second, a named owner for every agent or assistant put into service, accountable for its scope, its sources and its rights. An assistant without an owner is an assistant nobody will keep up to date.
A usage policy that actually applies
A useful usage policy fits on one page and crosses two dimensions: how sensitive the data is and which tool is used. A blanket ban does not survive contact with reality: it moves practices out of sight, as our guide on shadow AI explains.
The position of ANSSI, the French national cybersecurity agency, is a solid starting point. Its security recommendations for a generative AI system advise against using public generative AI tools on the internet whenever sensitive data is involved (recommendation R34), naming in particular personal data, contractual, legal or financial data, and secrets such as passwords or API keys.
A workable policy therefore sets out:
- Data categories: public, internal, confidential, personal, secrets. Reuse your existing classification rather than inventing a new one.
- Approved tools for each category: the governed internal tool, a contracted provider, no tool at all.
- Excluded uses: individual decisions without human review, published content without approval, processing of data that must not leave.
- The user's responsibility: read back, check sources, report an error or an incident.
- The request channel: how to obtain a new use, a new model or an exception, and how long it takes.
A policy that bans without offering an approved alternative is bypassed on day one. The rule “no confidential data in a public tool” only holds if an internal tool accepts that data.
A model catalogue and access rights
The model catalogue is the list of models the organisation approves, with, for each one, the provider, where it runs, the data categories allowed and the intended uses. It prevents two opposite drifts: every team contracting its own provider, and a single model forced onto every use.
A good catalogue separates at least three tiers:
- Models run in-house, the only ones allowed for the most sensitive data.
- Models from contracted providers, allowed for data whose transfer is accepted by contract, possibly after pseudonymisation.
- Excluded models, for lack of sufficient guarantees or of an identified need.
Choosing between these tiers is an architecture question, covered in the guide on on-premise generative AI. Governance decides who gets access. Rights are granted by group, not by person, and cover three things: models, the document sources that can be searched, and the connected tools an agent can act on. A document assistant that ignores directory permissions turns internal search into an information leak.
These rights age. ANSSI recommends a regular review of the rights granted to generative AI tools on business applications (recommendation R35), from activation and then at fixed intervals, because product updates can widen access without anyone having decided it.
Traceability: what you must be able to prove
A log serves three audiences: the CISO investigating an incident, the DPO answering an access request or an inspection, and management wanting to know what the tool is really used for. ANSSI recommends logging all processing carried out within the AI system (recommendation R29).
- WhoThe authenticated user, their group, and the agent or assistant used.
- WhatThe type of request, the model and provider called, the sources consulted.
- Which actionAny action executed in a connected tool, with the human approval that authorised it.
- How muchThe volume processed and the cost of each call.
Logging does not mean keeping everything. Storing the full text of every request creates a new pool of sensitive data, with its own retention rules. The log must let you reconstruct what happened without becoming the weak point itself: a defined retention period, restricted access, verifiable integrity.
Agent actions deserve separate treatment. Reading, searching and drafting can run freely; writing, sending or deleting commits the organisation. The guide on human approval details which actions to have confirmed, and how.
Costs: a managed budget, not a bill you discover
Generative AI shifts spending from a fixed licence cost to a variable usage cost, which depends on the number of active users, the length of the documents processed, the model chosen and the number of calls an agent chains. Without management, the first alert is the invoice.
Governance sets three things:
- An envelope per entity: department, project or user group, with an accountable owner.
- Caps and alert thresholds, per user and per group, so that abnormal usage is seen the same day, not at the end of the month.
- A model allocation rule: the most expensive model is not the default, it is reserved for the uses that justify it.
The guide on AI quotas and spending caps explains how to size these limits and run them day to day. The full cost of a platform, which is a purchasing decision, is covered in the guide on the cost of generative AI.
Putting governance in place step by step
Governance is not decreed in one go. It is built from real usage, and tightened as uses become critical.
- Measure what existsWhich tools are already used, by whom, for what. Without this picture, the policy is written for an organisation that does not exist.
- Name the rolesDecision committee, agent owners, champions in the business units.
- Open an approved alternativeA governed internal tool, with a model catalogue and access rights, so that the usage policy can be followed.
- InstrumentLogs, caps, alerts: what lets you move from trust to verification.
- Industrialise the use casesMove the experiments that proved their worth into production, with explicit exit criteria.
The last step is often where projects stall. The guide from proof of concept to production sets out the criteria that decide whether a use case scales.
Regulation matters too. The AI Act made an AI literacy obligation and the ban on certain practices applicable from 2 February 2025. The Digital Omnibus on AI, in force since 27 July 2026, simplified the AI literacy requirement and postponed the obligations for high-risk systems: to 2 December 2027 for the sensitive areas listed in Annex III (employment, education, access to credit, for example), according to the European Commission's AI Act page. The guide on AI Act obligations explains what they mean for a company that deploys AI. To structure the approach over time, the ISO/IEC 42001 standard sets out the requirements for an AI management system.
Frequently asked questions
Do we need a generative AI acceptable use policy?
Yes, but a short one, backed by controls. A policy sets the rule and everyone's responsibility; without an approved alternative, access rights and logs, it does not change behaviour.
Who should own AI governance in the company?
No single function. IT owns architecture and operations, the CISO security, the DPO personal data compliance, the business units the use cases. A shared committee rules on requests, and every agent put into service has a named owner.
What should be logged without creating a new risk?
Who made the request, with which model, on which sources, which action was executed and with what approval, and at what cost. The full text of requests is not essential, and keeping it creates a store of sensitive data that must itself be protected.
Where SmartAGT fits
SmartAGT is a governed AI agent platform deployed on-premise, inside your perimeter. The administrator defines the model catalogue, can restrict it to European providers, and sets quotas and spending caps per user, per group or for everyone, with alerts and hard blocking. Cost is tracked per agent, per model and per provider, in real money.
Every write or execute action is paused until a person approves it, and every decision goes into a verifiable hash-chained audit trail. Details are on the Security page.
