Why AI Governance Must Start Before Platform Selection
Most organizations eventually get to the same question about AI:
Which platform should we use?
Copilot? ChatGPT? Gemini? Claude? Something else?
It is a fair question.
It is also usually not the first one I would ask.
By the time leadership starts comparing platforms, AI may already be part of the organization’s daily work.
Someone may be using a public tool because it made a task easier. Another employee may have a personal subscription on an expense report. A vendor the organization has used for years may have quietly added an AI feature to a platform people already depend on.
None of that necessarily feels like an “AI implementation.”
That is the part I think gets missed.
Nobody had to make a reckless decision for AI to show up inside the organization. It can happen gradually, one employee, one subscription, or one vendor update at a time.
So before leadership starts debating which AI platform is best, there is a more basic question worth answering:
Do we know where AI is already touching the work?
AI Does Not Wait for a Formal Project
The uncomfortable part is that leadership can be trying to do the responsible thing and still be behind the actual use.
Government leaders are used to technology entering the organization through a recognizable process. A need is identified. Options are reviewed. A purchase is approved. IT implements it. Staff are trained.
AI does not always arrive that way.
Maybe nobody approved an AI project. Maybe no one has selected a platform. Maybe there is not even an AI policy yet.
That does not mean AI is not already there.
Someone may be using a browser-based tool because it made a task easier. A department may be paying for a subscription. A vendor may have added an AI feature to software the organization already relies on.
A police chief may believe the department has not adopted AI because nobody approved an AI project. A city administrator may assume there is still time to develop policy because no enterprise platform has been purchased.
Meanwhile, staff may already be using AI to draft, summarize, search, organize, or process work.
Nobody necessarily did anything wrong. The technology simply arrived differently than leadership is used to seeing technology arrive.
Before leadership can decide what should be allowed, restricted, or standardized, it has to understand what is already happening.
You cannot govern what you cannot see.
Before You Write an AI Policy, Find Out What Is Already Happening
This matters even more in government because the work is rarely generic.
An employee might be working with personnel information, internal communications, resident information, records, investigative material, or other information the organization would not want handled casually.
That does not mean every use of AI is automatically a problem. It means leadership needs to know enough about the use to make a reasonable decision about it.
And that is where policy can get ahead of reality.
An organization can spend a lot of time writing an AI policy that says what employees should and should not do. But if leadership does not know which tools are already being used, which accounts employees are using, what those tools can reach, or what AI features vendors have already introduced, the policy is being written around assumptions.
It may describe the environment leadership wants.
It may not describe the one employees are actually working in.
A Few Questions That Usually Tell You More Than You Expect
You do not need a complicated assessment to start getting a clearer picture.
A few basic questions usually reveal quite a bit:
-
-
- Which AI tools are people actually using?
- Are employees using work accounts or personal accounts?
- Are AI subscriptions already showing up on expense reports?
- Have any existing vendors added AI features?
- What organizational information can those tools reach?
- Which uses were actually approved?
- Is there any usage or audit information available?
-
In Microsoft 365 or Google Workspace, some of those answers may already be available through administrative or usage information. In other cases, leadership may have to ask departments directly.
The point is not to create a perfect inventory on day one.
It is to replace assumptions with something closer to reality.
Once leadership can see what is already happening, the rest of the conversation gets much easier.
AI Can Make Old Permission Problems Matter More
AI is easy to think about as a productivity tool.
Will it save people time? Which platform should we use? What can staff do with it?
Those are reasonable questions.
But in government, there is another issue underneath them: what can the person using AI already access?
Think about something as ordinary as SharePoint. An employee may have accumulated access to sites, Teams, folders, or files over years of changing responsibilities.
Some of that access may still make sense. Some of it may not.
That was already an access problem before AI entered the picture.
What changes is what the employee can now do with that access. AI can make it easier to find, summarize, connect, or work with information that was already sitting inside the account’s reach.
AI did not create the excessive access.
It changed what could be done with it.
That is why I would want leadership to understand permissions before deciding which AI platform feels safest. A more secure AI environment cannot fix access that was never properly governed in the first place.
And permissions are only part of the picture. Another piece is easier to miss: AI showing up through vendors the organization already trusts.
AI Can Show Up Through a Vendor You Already Trust
This is another place where AI can enter without feeling like a new technology decision.
Imagine a records platform your department has used for years adds an AI summarization feature.
Nobody necessarily asked for a new AI product. Nobody sat through a formal selection process. It may just look like another feature in software people already know and trust.
But once that feature starts working with organizational information, the questions change.
What can it access? Where does that information go? How long is it retained? Who reviewed the change? Who decided the feature was appropriate for department use?
Those questions are easy to miss because the vendor itself is not new.
That is the blind spot.
A system that was reviewed and approved three years ago may have capabilities today that did not exist when the original decision was made. That is also why a vendor relationship needs to be reviewed as the technology and the municipality’s dependence on it change over time.
So approving the vendor once cannot automatically mean approving every future use of the organization’s information.
If a new capability materially changes how data is accessed, processed, retained, or shared, someone needs to own that decision.
That is not really an AI problem by itself. It is a governance problem that AI happened to expose.
Then You Can Have a Better Conversation About Which Platform Fits
Once leadership has a clearer picture of what is already being used, what information those tools can reach, and where AI is already showing up through vendors, the platform conversation becomes much more useful.
At that point, the question is not simply:
Which AI is best?
It is:
Which AI environment fits the way we need to manage our information, users, records, and risk?
There is a real difference between a public consumer tool and an enterprise environment with administrative controls, centralized account management, logging, and clearer data-handling rules.
That does not mean free is automatically bad.
It does not mean paid is automatically safe.
It means leadership needs to understand what it is approving.
Can access be managed? Can accounts be controlled centrally? Can usage be reviewed? Does leadership understand how organizational information is handled? Could someone explain why the platform was appropriate for the work being performed?
For a police chief, city administrator, or department leader, those questions usually matter more than which platform writes the best summary.
AI Sprawl Can Hide in the Budget
Sometimes the first sign of unmanaged AI is not an IT report.
It is an expense report.
One employee is paying for one service. Another department has something different. Someone else is using a personal account. Meanwhile, an AI feature may already be included in software the organization is paying for anyway.
None of those decisions may have seemed significant when they happened.
Put them together, though, and leadership can end up with several AI tools, different account types, inconsistent data handling, duplicate spending, and no clear picture of what people are actually using.
The obvious problem is cost.
The bigger problem is control.
If the organization eventually decides to narrow the number of approved AI environments, that can make several things easier at once: managing access, applying consistent rules, reviewing usage, training staff, and understanding how information is being handled.
That does not mean every municipality or department needs one AI platform for everything.
It just means a collection of individual decisions should not quietly become the organization’s AI strategy.
Now the Policy Has Something Real to Govern
Once leadership understands what is actually happening, the policy conversation gets much easier.
Now the organization can make decisions based on real use instead of guessing.
Which tools are approved? Which ones are restricted? What information should never be entered into a public AI tool? Who can approve a new use? Who reviews AI features added by vendors?
Those answers matter because broad language only gets you so far.
A policy that says, “Do not enter sensitive information into AI,” sounds reasonable.
But in the middle of a real workday, that leaves the hardest question with the employee:
What counts as sensitive in the situation I am dealing with right now?
For a police department, that may involve reports, personnel matters, evidence-related information, internal communications, or records. For another department, the details will be different.
The goal is not to make employees interpret a policy on the fly. It is to give them enough clarity to know what is okay, what is not, and who to ask when the answer is not obvious.
If Someone Asked Tomorrow, Could You Explain What You Did?
A policy sitting in a folder does not tell you very much by itself.
The more useful question is whether leadership could explain what it actually did.
If an insurer, auditor, attorney, governing board, regulator, or member of command staff asked how the organization is managing AI, could someone show which tools were identified, which ones were approved, what employees were told not to enter, who reviews new tools or vendor features, and what happens if something goes wrong?
That does not require perfection.
It does require evidence that leadership saw the issue, made decisions, put some controls around it, and kept paying attention as things changed.
That is what makes governance defensible.
Not the existence of a policy.
The ability to show that someone was actually managing the risk.
This Is Not a One-Time Decision
AI governance is not something leadership finishes once and files away.
The environment keeps moving.
Vendors add features. Staff find new uses. Permissions change. New tools appear. A department that was not using AI six months ago may be using it routinely now.
That is why a policy written once will never be enough by itself.
Leadership has to keep looking at what is actually happening, whether the approved tools still make sense, and whether the rules still match the way people are working.
The goal is not to constantly rewrite everything.
It is to make sure the organization does not slowly drift back into the same problem it started with: assumptions taking the place of visibility.
Start With What Is Actually Happening
AI governance does not become real because leadership writes a policy or chooses a platform.
It becomes real when leadership can explain what people are using, what those tools can reach, which uses have been approved, and who is responsible for making those decisions.
That is why I would not start with a product demo.
I would not start with a blanket ban.
And I would not start by assuming nobody is using AI because nobody has formally approved it.
I would start by finding out what is already happening.
That usually tells you what needs attention next.
Maybe the issue is a few personal subscriptions. Maybe it is an AI feature inside a vendor platform. Maybe it is old permissions in Microsoft 365. Maybe leadership discovers the organization is farther along with AI than anyone realized.
In some cases, that use may already have become part of a recurring municipal process the organization depends on.
None of those discoveries means the organization failed.
It just means the conversation is starting from reality instead of assumptions.
And that is a much better place to make the next decision.
Questions Leaders Are Asking
Why should organizations assess current AI use before selecting an AI platform?
By the time leadership starts comparing platforms, AI may already be part of the organization's daily work. Someone may be using a public tool because it made a task easier. Another employee may have a personal subscription on an expense report. A vendor the organization has used for years may have quietly added an AI feature to a platform people already depend on.
What questions should leadership ask to find out how AI is already being used in their organization?
Which AI tools are people actually using? Are employees using work accounts or personal accounts? Are AI subscriptions already showing up on expense reports? Have any existing vendors added AI features? What organizational information can those tools reach? Which uses were actually approved? Is there any usage or audit information available?
How can AI make existing permission and access problems worse in government organizations?
An employee may have accumulated access to sites, Teams, folders, or files over years of changing responsibilities. Some of that access may still make sense. Some of it may not. That was already an access problem before AI entered the picture. What changes is what the employee can now do with that access. AI can make it easier to find, summarize, connect, or work with information that was already sitting inside the account's reach.
How can AI enter a government organization through existing vendors without anyone realizing it?
Imagine a records platform your department has used for years adds an AI summarization feature. Nobody necessarily asked for a new AI product. Nobody sat through a formal selection process. It may just look like another feature in software people already know and trust. But once that feature starts working with organizational information, the questions change.
What makes an AI governance policy defensible to auditors, insurers, or regulators?
If an insurer, auditor, attorney, governing board, regulator, or member of command staff asked how the organization is managing AI, could someone show which tools were identified, which ones were approved, what employees were told not to enter, who reviews new tools or vendor features, and what happens if something goes wrong? That does not require perfection. It does require evidence that leadership saw the issue, made decisions, put some controls around it, and kept paying attention as things changed.