AI Governance Is Not an AI Problem

Someone finds an AI tool that looks useful. Maybe it summarizes meetings, connects to your help desk, helps draft content, analyzes documents, or ties directly into Google Drive, Microsoft 365, Salesforce, or another system containing organizational data. Eventually, the question makes its way to IT: “Can we use this?”

That is where AI governance becomes real.

The request might begin as an email, a Teams message, a hallway conversation, or a help desk ticket, and that is perfectly fine. The important thing is to make it easy for people to ask for help before they have already purchased a tool, connected it to company data, or started building a business process around it. Governance works better when the front door is obvious and low-friction.

Once the request is serious enough to evaluate, it should move into the normal help desk or service request process. I do not think AI needs its own bureaucratic universe. If your organization already has a system for technology requests, use it. The help desk gives you a record, an owner, a status, and a place to track the work. More importantly, it keeps the request from becoming one more email thread that disappears into somebody’s inbox.

The requester also should not have to be an AI expert. Their job is to explain what they are trying to accomplish. I want to know what tool they are interested in, what problem they are trying to solve, who will use it, and what they hope it will improve. From there, IT can ask the questions the requester may not even know to ask: what data the tool will access, whether information is uploaded or retained, what systems it connects to, what permissions it requires, whether it can take actions, and whether the request is an experiment, a pilot, or something intended for production.

That is where the actual review begins.

Use AI to help govern AI

One useful thing I have done is use AI itself to help manage the review process.

Rather than starting from scratch every time someone brings me a new tool, I like using an AI Project with a defined set of instructions for how the review should work. The Project becomes the framework for the process, and each request gets its own chat.

That matters more than it may sound.

Without a defined process, reviews tend to be inconsistent. One tool gets a deep security review. Another gets a quick look at the privacy policy. Someone remembers to check whether customer data is used for model training, but forgets to check retention. Another reviewer focuses heavily on SSO and SCIM but misses what permissions a connector actually requests.

A Project with good instructions solves much of that. The instructions can define the questions that should be answered, the organization’s risk criteria, the approval paths, the data classifications that matter, the format of the final assessment, and the point at which additional review is required. Each new request follows the same basic path, while still allowing the review to adapt to the specific use case.

The chat then becomes the working file for that request. Research, follow-up questions, vendor responses, risk notes, and the final recommendation all stay together. That gives the process consistency without forcing every review into a rigid form.

Skills make the process even more useful.

A Skill can perform the repeatable parts of the review: researching the vendor, reading security and privacy documentation, checking terms of service, reviewing a subprocessor list, looking for information about retention, administrative controls, model training, audit logging, data residency, connectors, and authentication.

The key is that I do not want AI to simply give me an answer. I want it to show me where the answer came from. If the Skill says the vendor does not use customer content to train its models, I want the link to the vendor documentation so I can verify it. If the documentation is vague or the answer cannot be found, I want that uncertainty called out instead of filled in with a guess.

That gap can then become the next step in the workflow.

The Skill can draft an email to the vendor asking for clarification about data retention or deletion. It can draft a message back to the requester asking what types of data they plan to use. It can summarize the response when the vendor replies and add the result back into the review.

AI is not making the governance decision. It is helping move the work forward, keeping the process organized, and reducing the amount of repetitive research and administrative work that normally slows these reviews down.

Let AI help with the assessment too

AI can do more than gather information. It can also help evaluate it.

If the Project has a defined review framework, the AI can score or grade the request against that framework. It might assign risk levels across categories such as data sensitivity, vendor security, integrations, permissions, model training, administrative controls, automation, and business impact.

That makes the review easier to scale.

Instead of relying entirely on a reviewer’s memory or intuition, each request can be assessed against the same criteria. The AI can highlight why a tool received a particular score, identify which controls lowered the risk, and call out the gaps that increased it.

For example, an AI tool that only processes public information, has no system integrations, does not retain customer content, and has strong administrative controls might score as low risk. Another tool that connects to email and Drive, requires broad OAuth permissions, has limited audit logging, and cannot restrict features to specific groups might score much higher.

The AI can also help compare the request to earlier reviews. If several tools solve the same problem, it can identify which one has the stronger control set, which one creates less administrative overhead, or which one better fits the organization’s existing environment.

That is where AI becomes especially useful for scale. As the number of requests grows, the reviewer is no longer starting with a blank page every time. The system can perform the initial research, apply the scoring framework, identify exceptions, and produce a preliminary recommendation.

But the recommendation is still preliminary.

A high score should not automatically mean rejection, and a low score should not automatically mean approval. Context matters.

A tool might score higher because it needs access to sensitive data, but the business value could justify that risk if strong compensating controls exist. Another tool might score well technically but provide so little value that there is no reason to introduce another vendor, another contract, and another system to support.

This is why the human-in-the-loop requirement matters.

AI can research the tool, grade the risk, compare it to policy, identify control gaps, and even recommend an outcome. It can make the reviewer faster and more consistent.

It cannot accept risk on behalf of the organization.

A person has to make the final call.

That person needs to understand what the AI found, verify the important evidence, consider the business context, and decide whether the remaining risk is acceptable.

For me, that is a non-negotiable part of the process.

The AI can help us reach the decision. It should not become the decision-maker.

Keep the help desk as the system of record

The AI Project should not become a replacement for the systems the organization already depends on.

The help desk should still track the request.

If the AI platform can connect to your help desk system, a Skill can update the ticket as the review progresses. The status might change from “Under Review” to “Waiting on Vendor,” then to “Approved for Pilot” or “Approved with Conditions.” Notes from the assessment can be added to the ticket so someone looking at the request later can understand what happened without needing access to the entire AI conversation.

That is an important distinction. The AI Project is where the work happens. The help desk is where the service request is managed.

The same approach works for the AI registry.

You do not need to buy an expensive governance platform to get started. The registry can be as simple as an Excel workbook sitting in SharePoint. What matters is that the organization has one place to see which tools have been reviewed, who owns them, what they are used for, what data they touch, what integrations they have, what conditions were placed on their use, and when they should be reviewed again.

A Skill can help populate that registry as part of the review process. Instead of someone manually copying information from the assessment into a spreadsheet, the approved details can be written into the registry in a consistent format.

That gives you a fairly simple but effective operating model: the help desk tracks the request, the Project keeps the review organized, the Skills perform the repeatable work, and the registry preserves the organizational decision.

None of those pieces have to be especially sophisticated. They just need to work together.

An experiment is not the same thing as a pilot

AI governance gets unnecessarily complicated when every request is treated as if it carries the same level of risk.

It does not.

If someone wants to try an approved enterprise AI tool using public or nonsensitive information to see whether an idea has any merit, that is very different from connecting an AI agent to email, Drive, CRM, or another production system.

I like to separate requests into three stages: experiment, pilot, and implementation.

An experiment answers a simple question: can this idea work at all?

Experiments should be intentionally disposable. They should not create production dependencies, use sensitive data, make important automated decisions, or require broad access to production systems. If the experiment fails, nothing important should break. Because the risk is limited, the review should also be lightweight.

A pilot goes a step further. Now the question is not simply whether the idea works, but whether it works in your organization.

Real users may be involved. Limited organizational data may be involved. The tool may connect to a real system. At that point, the boundaries need to be clear. Who is participating? What information can be used? How long will the pilot run? What are we measuring? Who owns the outcome? What happens when the pilot ends?

That last question matters because without governance and process, a pilot can quietly become permanent. Most IT leaders have experienced this.

A pilot should have a defined end date and a decision point. At the end, the organization should deliberately approve it, extend the pilot, change the scope, or shut it down.

Implementation is different again. At that point, the organization intends to depend on the system, which means the review should begin to look like any other production application review. Someone owns it. Someone administers it, provisions and removes users, and handles what happens when an employee leaves. There’s a support model, a logging trail, a plan for outages, and an exit strategy.

Once you get to that point, the fact that the product uses AI is almost secondary. You are managing a production system.

The permissions problem is bigger than most vendors admit

One of the most frustrating parts of AI governance today: many products advertise enterprise controls while offering surprisingly little granularity.

A setting may be organization-wide. A connector may be available to everyone or no one. A new capability may be turned on for the entire tenant. A user may inherit all of the permissions they already have in another system, even when you only wanted to test a narrow use case.

That becomes a real problem when trying to run a controlled pilot.

On paper, a ten-person pilot sounds easy. Give ten people access, let them test the feature, evaluate the results, and expand later if it works.

In practice, the vendor may not give you the ability to do that.

You may discover the feature can only be enabled for the entire organization — all or nothing, not scoped to ten people. Maybe you can restrict licensing but not the feature itself. Disable a connector, sure, but not just for a pilot group. Control the application at the identity layer — but not what happens inside it.

That changes the governance decision.

If I want ten people to test a feature but the vendor requires me to enable it tenant-wide, I do not have a technically isolated pilot. I have an organization-wide capability that I am trying to govern through process and policy.

Those are not the same thing.

Sometimes there is a workaround. Licensing may effectively limit access. An identity group may control who can launch the application. A separate workspace or test tenant may be available. Connectors may be restricted even if the core feature cannot be.

When those controls do not exist, the review needs to say so clearly.

Maybe the compensating controls are acceptable. Perhaps connectors remain disabled, the pilot is limited to nonsensitive information, only the pilot group receives training, and usage is reviewed through available audit logs. Maybe the risk is low enough to accept temporarily.

Or maybe the lack of granularity makes the pilot inappropriate in the production tenant.

The important thing is to document the actual control gap rather than pretending the vendor gives you a capability it does not.

This is also why “enterprise controls” is no longer enough for me as a product description. I want to know exactly how granular those controls are. Can I enable a feature for one group? Can I restrict individual connectors? Can I control who creates agents? Can I prevent users from enabling integrations themselves? Can different teams have different settings?

Those answers often matter more than the vendor’s marketing language.

The review should end in a decision

A governance process is not complete because the research is finished.

Someone still has to make a decision.

For most tools, I do not want a forty-page assessment. I want a concise decision record that explains what the organization is trying to do, what data and systems are involved, what we learned about the vendor, what risks or control gaps were identified, how the request scored against our framework, and what was decided.

The supporting research can remain behind the assessment. The decision itself should be easy to understand.

The AI can help generate that final assessment. It can summarize the evidence, explain the scoring, highlight unresolved risks, compare the request against internal policy, and recommend an outcome such as approved for experiment, approved for limited pilot, approved with conditions, or not recommended.

Then the reviewer takes over — verifying the important findings, adjusting the grading if context warrants it, weighing the business value, and making the final call.

Once that decision is made, it should be recorded in the help desk and the AI registry. If the tool moves into production, it should have an owner, an administrative model, lifecycle processes, support expectations, and a future review date.

At that point, the review is complete and the organization can move on to the next request using the same process.

Make it easy to ask, and disciplined to approve

For me, that is what practical AI governance looks like.

Someone can start with an email. They do not need to know the approval process or understand AI risk. They just need an easy way to ask for help.

From there, the request moves into the normal service workflow. A dedicated AI Project keeps the review consistent and organized. Skills perform the repetitive research, provide source links for verification, draft follow-up communications, update the help desk, populate the registry, and help score the request against a repeatable framework.

AI can do a lot of the heavy lifting. It can research faster than I can, keep the process consistent, compare requests, identify gaps, score risk, and draft a recommendation.

What it cannot do is own the decision.

A human has to remain in the loop because someone has to understand the context, challenge the AI when necessary, weigh the business value against the risk, and accept responsibility for the outcome.

I have built this AI review process as a reusable Project and set of Skills because I do not want to recreate the review every time someone finds a new tool. The structure keeps the process consistent, while the Skills handle much of the administrative work around it.

If you want to see how I built the Project or the Skills behind the review process, ask me. I am happy to share them.

AI governance does not need another layer of bureaucracy. It needs an obvious front door, a repeatable process, and someone willing to own the decision at the end of it.