Enterprise AI governance: who may do what, and how to prove it

Governing AI inside a company is not about drafting an ethics charter: it is about answering four operational questions — who may do what, which data may enter a model, how you prove after the fact who produced what, and how far the budget may go. A credible usage policy rests on those four axes, not on principles. And since 2 August 2026 it also has a deadline: the AI Act's transparency obligations (Article 50) apply, and supervision by national authorities is in place — even though the "high-risk" obligations have been pushed back to December 2027 by the Digital Omnibus adopted in June 2026.

This article is written for one reader in particular: the IT director, general secretary, finance director or compliance officer of a mid-market company who has to produce a usage policy people can actually apply — not a legal watch memo. You will find a rights matrix by business function, a data classification, a workable trace model and a method for capping costs. We are a Creative Tech agency based in Vélizy-Villacoublay: our role on this subject is that of an architect-integrator — we help you embed AI into your processes, governance included. We do not sell licences, and we do not give legal advice: on the law, the text governs and your legal counsel decides.

In short

• AI governance is decided on 4 axes: usage rights by business function · permitted data · traceability · cost caps.
• The object that matters is not the charter, it is the matrix: a table of "business function × level of autonomy × data class" that every manager can apply without interpreting it.
• Since 2 August 2026, Article 50 of the AI Act requires you to disclose that a person is interacting with an AI and to mark synthetic content (Regulation (EU) 2024/1689).
• The "high-risk" obligations (Annex III) are deferred to 2 December 2027, and to 2 August 2028 for AI embedded in regulated products (Digital Omnibus, Council of the EU, 29 June 2026).
• Traceability is the real deliverable: without a managed workspace, it is structurally impossible to prove who produced what — personal accounts leave no evidence you can rely on.
• The cost cap is part of governance, not of engineering: budget per team and per use case, alert thresholds, value-versus-cost reviews.

What is enterprise AI governance?

Enterprise AI governance is the set of arrangements through which an organisation decides who may use AI, for what, with which data, under what level of human control, and with what evidence retained. It is a decision and evidence framework, not a manifesto: it produces rules a manager can apply on Monday morning, and traces an auditor can use six months later.

Three documents are routinely confused, and that confusion is expensive:

A useful definition — An AI usage policy is the document that assigns, for each business function and each type of task, a level of autonomy (what AI may do on its own) and a permitted data class (what it may read). Everything else — charter, training, steering committee — is simply how that matrix is implemented.

The most common mistake: starting with the charter. A charter written before the real uses are inventoried describes a company that does not exist. Start by looking at what already happens — including what happens outside the framework.

Where does European regulation stand in 2026?

The European timetable tightens in stages: the AI Act (Regulation (EU) 2024/1689) has applied incrementally since February 2025, Article 50 on transparency came into application on 2 August 2026, and the "high-risk" obligations were pushed back to December 2027 by the Digital Omnibus finally adopted on 29 June 2026. In other words: most of the technical burden has moved, but everything touching day-to-day use, transparency and team competence is already due.

The Digital Omnibus on AI — approved by the European Parliament on 16 June 2026, then finally adopted by the Council of the EU on 29 June 2026 as part of the "Omnibus VII" simplification package — also softened Article 4: the AI literacy requirement moves from an obligation of result ("ensure a sufficient level") to an obligation of means ("support the development of AI literacy" among staff). It has not been removed, and supervision by national authorities has run since 2 August 2026.

Two points for a decision-maker:

• The deferral cancels nothing, it shifts the date. A CV screening system or a credit scoring system remains classified as high risk under Annex III: the date moves, the classification does not. Organisations that use this window to map their uses will arrive ready; the others will discover the subject in 2027.
• The penalties are sized for the executive committee. The AI Act provides for up to €35M or 7% of worldwide turnover for the prohibited practices in Article 5, and up to €15M or 3% for most other breaches. This is no longer a technical team's problem.

Our limit, stated plainly. We are not a law firm and this article is not legal advice: classifying your systems and analysing your obligations is a matter for your legal department and for the text itself. What we bring is the operational layer — turning those obligations into usage rules, tooling and traces, inside your processes.

Who may do what? The rights matrix by business function

The core of workable AI governance is a two-axis matrix: a level of autonomy per type of task, and a permitted data class per business function. Without it, every manager improvises — and the company has no rule it can enforce.

The four levels of autonomy

A level of autonomy describes what AI may do on its own, and where a human takes over. It is the most useful variable in a usage policy, because it is independent of the tool and survives a change of supplier.

The golden rule: N2 is the default, N3 has to be earned. A use case only moves to N3 after running at N2 with a measured error rate, a written scope and logging in place. That is also the point of Article 26 of the AI Act, which requires — for high-risk systems — that human oversight be assigned to people with "the necessary competence, training and authority". In operational terms: an approver who has no power to say no is not oversight.

The matrix by business function

What you allow a lawyer, a salesperson and a developer has no reason to be identical: the risk is not in the tool, it is in the data handled and in how irreversible the output is. Here is a starting matrix, to be adapted — and it is exactly the deliverable we co-build with the business functions concerned.

Worth remembering — A useful matrix fits on one page and reads without a lawyer. If a manager has to interpret your policy to know whether something is allowed, it is already unusable. The test: "can I answer yes or no to an employee's question in ten seconds?"

Which data may enter a model?

No AI governance holds without a data classification first: the question is not "which tool is safe", but "which class of data may go where". A four-level classification is enough for the vast majority of mid-market companies — and it has the advantage of plugging into the one you already have, if you have one.

Four rules make this classification enforceable:

1. A personal account is C0, full stop. An employee logged into a consumer account has no contractual guarantee that binds anything to the company, and the organisation has no access to the logs. It is the simplest boundary to enforce, and the most structuring.
2. Require in writing, in the contract, that your data is not used for training — that is the point to check in enterprise offerings, not on a marketing page.
3. Treat the AI supplier as a processor. Hosting location, retention periods, sub-processors, safeguards for transfers outside the EU: these are clauses, not options. The CNIL publishes recommendations and practical guidance dedicated to AI that map out this work (see Sources).
4. Run an impact assessment when the data calls for it. An HR use case or large-scale processing of sensitive data calls for a DPIA — to be handled with your DPO, before deployment, not after.

The blind spot — The documented risk is not that "AI leaks": it is that your employees are already using tools you did not choose. Microsoft and LinkedIn's Work Trend Index (2024) measured that 75% of knowledge workers were using AI at work and that 78% of those users brought their own tool — a "BYOAI" pattern that exposes company data (see Sources). A policy that ignores this governs nothing: it simply pushes usage into the shadows. The answer is not a ban, it is offering a managed workspace better than the unmanaged tool.

The choice of engine — Claude (Anthropic) as our lead tool, Mistral when French sovereignty weighs on the decision — is an architecture decision, not a governance decision. The rights matrix and the data classification hold whichever model you pick, and that is precisely what makes them durable.

How do you prove after the fact who produced what?

You prove an AI use by keeping, for every sensitive output, a trace that links a person, a system, a purpose, a data class and an act of human validation — and that trace only exists if the work goes through a managed workspace. This is the "how do you prove it" part: without logs, a usage policy is a statement of intent.

The six fields of a usable trace

The four layers of evidence

1. The use register — the living inventory: for each use, the business function, the purpose, the data, the level of autonomy, the named owner. It is the first document opened in an audit, and the one that is almost always missing.
2. Technical logs — the logs generated by systems and integrations. The AI Act requires deployers of high-risk systems to keep logs for at least six months (Article 26(6)): a reasonable retention benchmark to keep in mind even outside high risk, aligned with your own retention policies.
3. Content marking — since 2 August 2026, Article 50 requires disclosure that a person is interacting with an AI and marking of generated or manipulated content (with a grace period until 2 December 2026 for marking on systems already on the market). In practice: an internal convention for marking deliverables produced with AI, and visible disclosure on a public chatbot.
4. The organisational trace — the decision, not the machine: the minutes of the committee that approved the use, the version of the policy in force on that date, evidence that the employees concerned were trained. This is what turns an incident into a "managed deviation" rather than a "missing framework".

The governance test, in one question. Take a deliverable produced three months ago. Can you say who produced it, with which tool, on what data, and who approved it? If the answer means asking someone whether they remember, you have no traceability — you have an oral culture. That is the first diagnosis we run, and it takes half a day.

One reminder with HR consequences: before putting a high-risk AI system into service in the workplace, Article 26(7) requires you to inform workers and their representatives. In France, this connects to the prerogatives of the works council (CSE) — to be handled with your employee relations department. Anticipating this step stops a technically ready project from sitting blocked for six weeks.

How do you cap AI costs without throttling usage?

The cost cap is a governance decision, not a technical setting: it means allocating a budget per team and per use case, setting alert thresholds before the invoice, and regularly reviewing what each use actually returns. It is the building block finance departments ask for, and the one most often missing from usage policies written by IT alone.

The mechanics come in four steps:

1. Make it visible — know who consumes what, by team and by use case, subscriptions and integrations together. You cannot steer an invoice you cannot see.
2. Set the frame — a budget per team or per project, with alerts at 70% of the threshold rather than at 110%. The point is not to police people, it is to make experimentation safe.
3. Optimise — the right model for the right task, caching for repeated contexts, batch processing for non-urgent volumes. The levers are documented and quantifiable.
4. Arbitrate — tie each use to the value it produces, so you can cut or invest with your eyes open.

The detailed figures behind these levers — and why the invoice runs away at scale — are covered in a dedicated article: controlling AI token costs in the enterprise. It is a subject we genuinely tool up, because we design and run AI systems in production ourselves.

The board-level argument — AI spending you can attribute and justify survives budget arbitration; an opaque invoice gets cut at the first squeeze. A cost cap is not a brake on adoption: it is what makes adoption defensible over time. An agent with no scope, meanwhile, consumes overnight while nobody watches.

Where do you start? A six-step path

You install AI governance starting from what exists, not from a blank page: inventory the real uses, classify the data, set the rights matrix, wire up traceability, frame the budget, then train and review. In a mid-market company, the first four steps take a few weeks — the difficulty is not the duration, it is the order.

1. Inventory the real uses — including those that exist outside the framework. One interview per department is enough to reveal the essentials. Without that picture, you write a policy for an imaginary company.
2. Classify the data — four classes (C0 to C3), plugged into your existing classification if you have one. It is the prerequisite for every rule that follows.
3. Set the rights matrix — business function × level of autonomy × data class, on one page, co-built with the business experts: they are the ones who know where the real friction sits.
4. Wire up traceability — managed workspace, SSO, logs, use register, content marking convention. This is the step that makes the policy provable.
5. Frame the budget — allocation per team and per use, alert thresholds, value-versus-cost review.
6. Train and review — the matrix ages: new uses, new models, new regulatory deadlines. A quarterly review, with an identified committee and a named owner per use.

The classic trap — Starting with step 6 (training) or with the charter, without steps 1 to 3. You end up with employees briefed on rules that do not match their actual work — and usage goes back into the shadows. Frame what exists first, train on what has been framed second.

Why bring in support on the governance of your AI use?

Because the difficulty is not knowing the framework — it is public — but translating it into your processes, your tools and your business functions, without turning governance into an administrative layer nobody applies. That is architecture and integration work, at the meeting point of consulting and engineering.

Our legitimacy is concrete and verifiable. We design and run AI systems every day — application development, agents, automations, production of 3D assets, images and video. So we know where the real problems hide: what a log actually captures, what a managed workspace changes in terms of evidence, what an agent consumes when nobody is watching. And we genuinely tool up cost control, the block most often absent from usage policies.

We also have a proven skills-transfer activity with public and private organisations — Grand Angoulême (talk and workshop on agentic AI), Bertrandt (ideation of an AI assistant for CV analysis), Strate and Gocad Lab (training and Design Thinking modules). One point of honesty: this training activity is not certified — we never present it as such.

What we are not, and saying so plainly is part of the service:

• Not a law firm. Classifying your systems under the AI Act and the GDPR is for your legal department and your DPO. We frame the operational layer and refer to the text for the law.
• Not a licence reseller. The choice of engine is an architecture decision we work through with you; we have no licence to place.
• Not a supplier of charter templates. A downloaded charter governs nothing. What governs is the matrix built with your business functions — and the traces it produces.

Method, honestly stated — AI governance is built with your compliance, IT, HR and business teams: they are the ones who know your constraints. We bring the method, the architecture and the tooling; the decisions remain yours. And what we transfer is a repeatable method — not our internal organisation, which stays ours.

Let's frame the governance of your AI use

You have to produce a credible usage policy, and you want neither a document nobody applies nor a brake on adoption. METASENSE (Vélizy-Villacoublay) puts the concrete framework in place: inventory of uses, rights matrix by business function, data classification, provable traceability and cost caps — co-built with your teams, as an architect-integrator.

Explore enterprise AI enablement →

To go further on the neighbouring building blocks: embedding Claude in your company's processes, why AI licences stay under-used, building an AI workflow per business function, sharing Claude Skills across the organisation and orchestrating multi-step agents.

FAQ

What is enterprise AI governance?

Enterprise AI governance is the set of arrangements that decides who may use AI, for what, with which data, under what level of human control, and with what evidence retained. It takes shape as a rights matrix by business function, a data classification, a use register and usable logs.

What is the difference between an AI charter and an AI governance policy?

The charter is the document circulated to everyone: it states what is allowed, supervised or banned, in plain language. The governance policy is the steering document: roles, rights matrix by business function, data classification, thresholds, approval process for a new use. The charter circulates a decision; the policy takes it.

Who may use AI in the company, and for what?

That is decided by a matrix crossing the business function, a level of autonomy (prohibited, assisted, supervised, delegated) and a permitted data class. The "supervised" level — AI produces, a named person approves before anything goes out — is the right default regime. The "delegated" level has to be earned, after the error rate has been measured.

Which data should never be sent to an AI?

Data in the "secret" class: industrial and trade secrets, core code, sensitive personal data (health, biometrics). It is prohibited by default and may only circulate in a dedicated environment approved case by case. One absolute, non-negotiable rule: never put secrets, keys or access tokens in a prompt.

How do you prove who produced what with AI?

By keeping six elements for every sensitive output: timestamp, author identity, system and version, declared purpose, input data class, and the act of human validation. That trace only exists if the work goes through a managed workspace: a personal account leaves the company no evidence it can rely on.

What does the AI Act change on 2 August 2026 for a mid-market company?

Since 2 August 2026, Article 50 of Regulation (EU) 2024/1689 requires you to inform people that they are interacting with an AI, to mark generated or manipulated content and to flag deepfakes. General application of the regulation and supervision by national authorities also take effect on that date.

Have the AI Act's "high-risk" obligations been deferred?

Yes. The Digital Omnibus on AI, approved by the European Parliament on 16 June 2026 and adopted by the Council of the EU on 29 June 2026, defers stand-alone high-risk systems under Annex III to 2 December 2027, and AI embedded in regulated products (Annex I) to 2 August 2028. The classification itself does not change.

Has the AI training obligation disappeared?

No. Article 4 of the AI Act, applicable since 2 February 2025, was softened by the Digital Omnibus: it moves from an obligation to ensure a sufficient level of AI literacy to an obligation to support its development among staff. The obligation remains, and supervision by national authorities has run since 2 August 2026.

Do you have to inform the works council before deploying AI at work?

Article 26(7) of the AI Act requires an employer-deployer to inform workers and their representatives before putting a high-risk AI system into service in the workplace. In France, this connects to the prerogatives of the works council (CSE): to be handled with your employee relations department and your legal counsel, ahead of the project.

How do you cap AI costs without throttling usage?

In four steps: make consumption visible by team and by use case, set the frame with budgets and alerts triggered before the invoice, optimise (right model per task, caching for repeated contexts, batch processing), then arbitrate the value produced use by use. The cap makes experimentation safe rather than slowing it down.

Does AI governance slow adoption down?

No: it is the absence of a framework that slows it down. With no clear rule, employees use unmanaged tools — usage that is invisible, untraceable and indefensible, and that ends up banned outright. A readable matrix and a comfortable managed workspace produce the opposite: broader usage, and usage you can steer.

How long does it take to install AI governance?

In a mid-market company, the inventory of uses, the data classification, the rights matrix and wiring up traceability take a few weeks. The difficulty is not the duration but the order: frame before you train, and co-build the matrix with the business functions rather than imposing it on them.

Sources

1. EUR-Lex — Regulation (EU) 2024/1689 (AI Act), consolidated text: https://eur-lex.europa.eu/eli/reg/2024/1689/oj?locale=fr — entry into force, staged application, Articles 4, 5, 26, 50, 99.
2. Council of the European Union — press release of 29 June 2026, Artificial intelligence: Council gives final green light to simplify and streamline rules ("Omnibus VII" package; deferral to 2 December 2027 for stand-alone high-risk systems and to 2 August 2028 for AI embedded in products): https://www.consilium.europa.eu/en/press/press-releases/2026/06/29/artificial-intelligence-council-gives-final-green-light-to-simplify-and-streamline-rules/
3. European Commission — AI Act Service Desk, Article 26 (deployer obligations: competent human oversight, retention of logs for at least six months, information of workers and their representatives): https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-26
4. K&L Gates / Cyber Law Watch — EU Digital Omnibus on AI Enters Into Force (31 July 2026): published in the Official Journal on 24 July 2026, in force on 27 July 2026, Regulation (EU) 2026/1744; Article 50 applicable on 2 August 2026; new prohibited practices on 2 December 2026: https://www.cyberlawwatch.com/2026/07/31/eu-digital-omnibus-on-ai-enters-into-force/
5. Gibson Dunn — EU AI Act Omnibus Agreement: Postponed High-Risk Deadlines and Other Key Changes: Article 4 reclassified as an obligation of means; grace period until 2 December 2026 for marking under Article 50(2): https://www.gibsondunn.com/eu-ai-act-omnibus-agreement-postponed-high-risk-deadlines-and-other-key-changes/
6. CNIL — recommendations and practical guidance on AI (applying the GDPR to the development and deployment of AI systems): https://www.cnil.fr/fr/les-fiches-pratiques-ia
7. Microsoft & LinkedIn — Work Trend Index 2024, AI at Work Is Here. Now Comes the Hard Part (75% of knowledge workers use AI at work; 78% of users bring their own tool — "BYOAI"): https://www.microsoft.com/en-us/worklab/work-trend-index/ai-at-work-is-here-now-comes-the-hard-part