Imagine someone in your operations team builds a reporting tool with an AI coding assistant. It saves them a tedious job, so they share it. A few weeks later, another team is using it and the weekly meeting depends on its numbers.
Nobody decided to make it a company system. People simply started relying on it. The hosting account might still belong to its creator, and its calculations may have been checked against just one example. If it breaks on Monday morning, who fixes it?
Before adding features, someone needs to take responsibility for running it.
AI governance for internal tools means deciding who owns them, what data they may use, and what needs checking before other people rely on them. Those decisions need to stay with the tool as it changes.
Adoption can get ahead of oversight
Microsoft and LinkedIn’s 2024 Work Trend Index found that 78% of surveyed AI users brought their own AI tools to work. That measures AI use, rather than the number of internal applications being built. It does show why a company should ask what people are already using before planning its next rollout.
IBM’s 2025 breach study found that 63% of the 600 breached organisations studied lacked an AI governance policy or were still developing one. The sample was made up of organisations that had experienced breaches; it is not a percentage for all companies.
For a tool already in use, I’d ask what it can access and whether anyone has checked it before sharing it.
Check how AI is involved
An application written with an AI assistant might contain no AI once it is running. It can still have incorrect calculations, missing permission checks, or dependencies nobody maintains. It needs the same care you would expect of other software used in the business.
A tool that calls an AI model while running adds another question: what happens when the output is wrong? A person may be able to review a draft report. An error is harder to contain if the output directly changes a customer record.
The development process needs attention too. OWASP’s Secure Coding with AI guidance covers risks such as sensitive information entering a coding assistant’s context, unsafe dependencies, and agents operating with broad permissions. Reviewing the finished screen will not reveal all of those problems.
Start with a tool people already use
For the reporting tool in our example, I would start by asking its creator to walk through a real task with the person who uses the report. Follow the data from its source to the final number. Ask where the tool runs and what happens when an input is missing or has changed format.
Then write down enough for someone else to understand its role:
- The business task and the people who depend on the result.
- The data it reads, where that data goes, and what it can change.
- The company owner, the technical maintainer, and who controls the accounts.
- The checks needed before a change is released.
- How to report a problem and carry on working if the tool is unavailable.
If nobody knows who controls the hosting account, record that and assign someone to find out.
Match the review to the consequences
A formatting experiment using invented data needs a different review from an application handling employee records. Start with the information involved, the decisions supported, and the changes the tool can make.
For the reporting example, compare results with independently checked calculations. Include incomplete and unexpected inputs. A test written by the same assistant that produced the calculation may repeat the same assumption, so someone needs to check the rule being tested.
Test access as well. A successful login does not establish which records a person should be able to read or change.
If an AI agent can act in other systems, permissions deserve particular attention. OWASP’s guidance on excessive agency recommends limiting what an agent can do and requiring approval for actions with significant consequences. Those restrictions need to be enforced by the connected systems. An instruction in a prompt is not an access control.
Give experiments a route into everyday use
People need to know how to move a useful experiment forward. That route can start with a small sandbox using sample data, then a review before the tool is shared or connected to business systems.
Decide whether the tool is ready for its intended use and record any restrictions or changes needed first. Sometimes maintaining it will cost more than the time it saves.
Keep that decision with the tool’s documentation and name the person responsible for following it up. Revisit it when the tool gains a new integration or starts serving a different purpose. The reporting script used by two colleagues may eventually support a decision that its original checks never covered.
For companies wanting a broader structure, the NIST AI Risk Management Framework is a voluntary reference for managing AI risks. A small team can begin with one workflow and a short record of its decisions.
Start with one tool your team already uses. We can review it with the people who build and use it, document what needs attention, and agree the next steps. Our AI governance consultancy explains what that review can cover.