The wrong time to create an AI policy is after everyone in the company has already selected their own tools.
By then, employees may be using free accounts, uploading company information into public systems, and creating client-facing content with no consistent review process.
The horse isn’t just out of the barn.
It has opened a free AI account and uploaded your client list.
That is why my position is simple:
“You want to have a policy for that before we turn it on.”
Governance should come before broad enablement.
That does not mean you need to spend six months developing a complicated policy that nobody understands. In fact, a policy that is too long may create the appearance of control without changing anyone’s behavior.
Someone receives a 12-page document. They scroll to the bottom, click “I agree,” and move on with their day.
Technically, they accepted the policy.
Practically, nothing was governed.
Keep It Simple Enough to Follow
A usable AI policy could begin as a single page with three columns:
Approved for business use
Approved with restrictions
Not approved
That structure gives an employee a decision map.
It answers the questions people have:
Can I use this tool?
Can I put this information into it?
Does someone need to review the output?
Is this a process we are willing to automate?
Those are practical questions. The policy should provide practical answers.
Approved for Business Use
This category should identify the platforms and activities that employees may use as part of their normal work.
The approved tool list should be specific. Don’t write “AI tools may be used for internal productivity.” Name the approved platforms and the approved account type.
One of my baseline requirements is:
“You require business accounts; no free anything.”
Free accounts are designed primarily for individuals experimenting with a service. They may lack the administrative controls, contractual protections, retention options, security settings, and account-management capabilities a business needs.
An organization should be able to manage access.
It should be able to disable an account when an employee leaves.
It should understand what happens to the information being entered.
It should know which terms apply to business data.
If the organization cannot manage the account, the organization does not have meaningful control over its use.
Approved With Restrictions
Some AI use cases can be valuable but require additional controls.
For example, an approved business platform may be used to create a first draft of client-facing material, but the draft should not go directly to the client.
My baseline rule is:
“No sensitive data, no client-facing output without a human review.”
Human review is not an expression of distrust in the technology.
It is accountability.
AI can create an answer that sounds confident, polished, and completely reasonable while still being wrong. The cleaner the writing, the easier it can be to miss the error.
Someone who understands the subject needs to review the work before it leaves the organization.
Restricted use cases may require:
- An approved business account
- Specific types of permitted information
- A documented prompt or application
- Review by a qualified employee
- Approval before external distribution
- Retention of the supporting source material
The exact controls will depend on the work. The important thing is that employees shouldn’t have to invent the rules while they are doing it.
Not Approved
Some activities should simply be prohibited.
The clearest example is putting sensitive information into an unapproved public tool.
“You’re not allowed to put any sensitive data in any public tools.”
That should include information the company has a legal, contractual, regulatory, or ethical responsibility to protect.
The policy should explain sensitive information in plain language. Don’t assume every employee understands terms such as regulated data, personally identifiable information, protected health information, or confidential business information.
Give examples that fit your organization.
Your “not approved” category should also include unapproved tools, personal accounts used for company work, and processes where the potential damage from an incorrect result exceeds the current ability to control the risk.
Create a “Do Not Automate Yet” List
Not every process should be automated simply because automation is technically possible.
I recommend maintaining a specific do not automate yet list.
The word “yet” is important.
It communicates that the organization is not permanently opposed to the idea. It simply has not established sufficient reliability, control, or oversight to automate that process today.
Maybe the potential impact is too high.
Maybe the source data is inconsistent.
Maybe the model has not performed reliably.
Maybe the organization has not yet defined what successful output looks like.
Restraint should be a deliberate governance decision, not an informal assumption.
A documented list also protects employees from feeling pressured to automate something merely because leadership has made AI adoption a priority.
The objective is not maximum automation.
It is appropriate automation.
Policy Is Only the Beginning
A one-page policy is a strong starting point, but it still needs an owner.
Someone should be responsible for:
- Maintaining the approved tool list
- Reviewing proposed use cases
- Updating data restrictions
- Monitoring vendor-term changes
- Managing business accounts
- Coordinating employee education
- Reassessing items on the do-not-automate-yet list
AI tools and business use cases will change.
The policy needs to be reviewed as the organization learns.
That does not mean rewriting it every week. It means establishing a reasonable process to evaluate changes instead of allowing AI adoption to happen one unsupervised employee at a time.
Governance Is an Enabler
Some leaders hear “AI governance” and picture a committee whose primary purpose is to say no.
That is the wrong outcome.
Good governance creates enough clarity for people to move forward confidently.
Employees know which tools they can use.
They know which information is prohibited.
They know when human review is required.
They know where to bring a new idea.
They know which processes should not be automated today.
That reduces fear, uncertainty, inconsistency, and unnecessary risk.
Turn the FUD into facts, clear decisions, and responsible action.
You do not need a 12-page policy that nobody reads.
You need clear rules your people can understand and follow.
Start with one page.
Three columns.
Approved. Restricted. Not approved.
Then turn it into the way your organization works.
