AI governance

AI governance is the set of rules a company uses to steer its own AI use: who may use which tools for which purpose, which data leaves the building, who can overrule an automated decision, and who is accountable when something goes wrong.

What belongs in AI governance?

In practice, five decisions get you further than a policy document nobody reads.

An inventory: which AI tools are in use, in which department, for what purpose. Without that list none of the following questions can be answered, and in most companies it is considerably longer than management assumes.

Data classes: which categories of data may enter which system. Personal data, customer documents, source code, pricing models. A blanket ban gets circumvented; a clear gradation does not.

Accountability: where a human decides, and who that human is. This is human-in-the-loop applied to specific processes rather than held as a principle.

Traceability: what gets logged, for how long, and who may read it. Without a log there is no way to establish what happened after an incident.

Procurement: what review a new tool passes before it touches real data. This is where governance either works or merely exists.

Why is it worth doing?

The obvious reason is legal. The EU AI Act requires documented oversight for certain applications, and the GDPR applies to AI systems as it does to any other processing. Bitkom reports that 53% of German companies name legal uncertainty as a barrier to using AI.

The practical reason matters more. Without rules, AI use happens anyway, just invisibly: staff paste documents into personal accounts because it makes the work easier. Governance is therefore less a brake than an alternative to that.

And the commercial reason: a company that can explain its own rules can also answer customer questions about data processing. Procurement questionnaires now ask precisely that.

What governance should not be

Not a document written once and filed. The tools change faster than any policy, which is why the inventory and the procurement review are worth more than well-phrased principles.

And not a programme that has to conclude before the first project. An AI pilot with a clearly bounded set of data is a better occasion to answer these questions concretely than a workshop with no use case attached.

A version you can have in four weeks

A two-page document is enough to start with, and it comes together in this order.

Week one: the inventory. Ask around the departments which tools are actually in use, with no penalty attached to the answer. Getting an honest answer to that question is the hardest and most valuable part.

Week two: the data classes. Three tiers will do to begin with: unrestricted, internal, confidential. Plus one line each on which tools are approved for them.

Week three: accountability and logging for the two or three applications where a mistake reaches customers. Everything else can wait.

Week four: the procurement route for new tools, on half a page. Who reviews, against what, and who approves.

What comes out of this is deliberately incomplete. A short document that applies and gets read steers more than a comprehensive one stuck in review. Extend it when a specific application raises a question it does not yet answer.