How to implement AI governance: from tool sprawl to clear approval gates

Start with an inventory, not a policy

Before writing new rules, an organization needs a reliable picture of its current state. This includes AI tools already in use, planned use cases, pilots and the informal paths through which decisions are made today. External development partners and AI features embedded in standard software belong in this inventory as well.

The goal is not a perfect list but a prioritized working basis. A use case with broad reach or sensitive data needs attention earlier than an isolated experiment. The inventory also shows which existing product, IT, legal and data protection processes can be reused.

• Which AI systems and features are already in use?
• Who owns them from a business and technical perspective?
• Which data, user groups and third parties are involved?
• Where and how was adoption or operation approved?

An intake turns ideas into comparable use cases

The intake is the shared entry point for new AI initiatives. It should only request information needed for an initial decision. An excessively long form encourages teams to bypass the process; a form that is too short moves every clarification into endless meetings.

A useful structure brings together business objective, affected users, data, vendors and ownership. The answers do not need to be final. They need to be sufficient to determine the next appropriate review step.

• Problem and expected value: Which work or decision should improve?
• Context: Who uses the system and who is affected by its outputs?
• Data and integrations: Which inputs, sources and adjacent systems are involved?
• Vendor and model: Which third parties or technical dependencies exist?
• Ownership: Who owns the use case and who may approve it?

Gates must enable decisions, not just documents

A gate is an explicit decision point. Typical stages are idea, pilot, controlled use and operation. Not every initiative needs the same review. Risk-based governance adapts review depth and participants to the specific use case.

Each stage needs clear entry criteria and possible outcomes: approve, approve with conditions, hold or stop. A well-reasoned stop is a productive outcome. It prevents sunk effort from pushing an unsuitable initiative forward.

• Idea: Is the problem relevant and is AI a suitable approach?
• Pilot: Are test scope, data, owners and stopping criteria defined?
• Operation: Are usage rules, monitoring, support and escalation paths in place?
• Continued operation: Are changes to model, data, vendor or context reviewed again?

Ownership and documentation belong together

A RACI chart alone makes no decisions. Each gate needs a named role with authority to decide, and involved functions need to contribute at the right time. Product, IT, legal and data protection should review the same use case rather than work in isolated sequential loops.

A concise decision record makes the outcome traceable: What was decided, on which basis, under which conditions and when must the decision be reviewed? This documentation belongs in the team's work and knowledge system, not a separate governance folder.

A lean start for the first 30 days

Start with a small number of real use cases and test the intake and gates against them. An existing pilot, a planned purchase and a tool already in operation provide different perspectives. Fields, roles and decision criteria can then be adjusted before broader rollout.

A regular AI forum can support the model when it prepares or makes actual decisions. Without that mandate, it quickly becomes another information exchange. The EU AI Act provides the legal framework; the operating model makes ownership work in daily practice.