Bring-Your-Own AI: Writing a Policy That Survives Contact With Reality

The 2026 numbers are consistent enough to plan around. Roughly a third of employees use AI tools their employer does not know about. Among those who use AI at work at all, a large majority bring tools that were never approved. Around a quarter to a third have entered confidential company data into a public AI tool.

Meanwhile roughly eighty percent of organizations say they worry about data leaking through generative AI, and a majority have no strategy addressing it. Frameworks exist, including the NIST AI Risk Management Framework, and most organizations have not applied one.

So bring-your-own AI is not a hypothetical to be prevented. It is the current state, and a policy has to start from there rather than from a preferred alternative.

Why The Standard Policy Fails

Most AI policies are written as prohibitions with an approval process attached. They fail for three predictable reasons.

They lose the argument on merit. The employee knows the tool made their email better. A policy that asks them to produce worse work with no alternative offered will be followed in the presence of a manager and ignored otherwise.

They move the behavior out of sight. Blocking access at the network level pushes it onto personal phones, where there is no logging at all. The policy succeeded and the actual risk increased. We wrote about the employee experience of this in what to do when your company blocks ChatGPT.

They require judgment at the wrong moment. “Do not input sensitive information” asks someone at 18:30, three minutes before a deadline, to classify their own draft against an abstract term. Judgment under time pressure produces the outcome the policy was meant to prevent.

The Three Things A Working Policy Needs

A sanctioned tool that is genuinely good and genuinely fast. This is the whole game, and everything else is secondary. If the approved option is slower or worse than the browser tab, people use the browser tab. Latency matters more than the feature list: a tool that responds in two seconds gets used a dozen times a day; a tool requiring a browser switch, a page load, and a wait gets used twice and abandoned.

Concrete categories instead of abstract terms. “Client names, financial figures, personnel matters, and contract language” is a rule someone can apply without thinking. “Sensitive information” is not.

A default that is safe when someone does not think. If the private option is also the default and the fast one, the failure mode becomes harmless. This is why a local model matters more than a training module: it removes the need for a correct judgment call rather than relying on one.

A Policy Worth Copying

Before, the version that generates violations:

Employees must not input any confidential, proprietary, or personally identifiable information into external artificial intelligence services. Use of AI tools for work purposes requires prior written approval from the information security team. Unauthorized use may result in disciplinary action.

After, the version people follow:

AI tools at work

Use the local rewriting tool on your workstation for anything involving client names, financial figures, personnel matters, contract language, or anything a client has marked confidential. It runs on your machine and sends nothing externally, so no approval is needed and you do not have to decide whether something qualifies. If in doubt, use it; it is never the wrong choice.

For general drafting that contains none of the above, the approved cloud tool is fine. It is covered by an agreement that excludes our content from training.

Do not paste work content into personal AI accounts on any device, including your phone. This is the one rule with no exceptions, because we have no visibility into those accounts and no agreement covering them.

If you want to use a tool that is not on the approved list, tell us. We would rather add it than not know about it. Nobody gets in trouble for asking.

Questions go to the team channel, not to a form.

That last line does more work than it appears to. A policy with a friction-free path for asking gets asked; a policy with an approval form gets circumvented.

Rewrite Your Existing Policy

Most organizations already have an AI policy that reads like the “before” example. Rewriting it is a twenty-minute job and it is exactly the sort of task a rewriting tool handles well, provided you constrain it properly.

A Wrivio Context for policy writing could say:

Rewrite this as a workplace policy for a general professional audience. Clear and direct, complete sentences, no contractions. Replace abstract terms like sensitive, appropriate, and as needed with concrete categories and specific instructions. Keep every rule, exception, and precedence statement exactly as written. Do not add approval steps or requirements that are not in the original, and do not soften a prohibition into a recommendation.

Press Ctrl+Shift+Space, paste the policy section, and read the diff carefully. The failure mode is specific: concrete rules dissolving back into advisory language, which is how you end up with a document that reads well and prevents nothing. There is a fuller template in how to write an AI use policy for a small team.

What To Measure

A policy you do not measure is a document rather than a control.

1. Ask anonymously what people actually use, and promise no consequences for honest answers. You will learn more in one survey than from a year of network logs, because the phone usage never appears in your logs.
2. Track whether the sanctioned tool is being used, not just whether it is installed. Installed and unused means it lost to the alternative.
3. Re-ask quarterly. New tools appear constantly, and last quarter’s inventory is already stale.
4. Keep a record of which tools were reviewed, when, and what was decided, since this is what a client or auditor will ask for.

There is a process for the inventory in how to run an AI tool audit for your team and for the records in how to document your AI workflow for an auditor.

The Framing That Makes This Tractable

Shadow AI is usually discussed as a discipline problem. It is more accurately an internal product problem: the sanctioned option is worse than the unsanctioned one, so people route around it.

That reframing is useful because it is actionable. You cannot train away a genuine productivity gap, and attempting to produces resentment plus the original exposure. You can close the gap, and closing it means providing something fast, private, and good enough that the browser tab stops being tempting.

A local model that responds in two seconds and never transmits your text is the closest thing to a structural fix, because it wins on the dimension that caused the problem in the first place.

Common Questions

Should we just ban AI entirely?

It does not work. The behavior moves to personal devices where you have no visibility, and you lose the productivity along with the oversight. Providing a good option is the only approach with evidence behind it.

Does an enterprise agreement solve the problem?

For the tool it covers, substantially. It does nothing about personal accounts on personal phones, which is where the invisible exposure lives.

How do we handle contractors and freelancers?

Same categories, stated in the contract rather than in an internal policy. Contractors frequently have their own AI habits and no visibility into your rules unless you write them down. See freelancer client data in AI tools.

What if someone has already pasted confidential data into a public tool?

Treat it as a disclosure incident: find out what and when, check the provider’s retention terms, request deletion where available, and record it. Then fix the gap that caused it, which is usually the absence of a good alternative.

Download Wrivio for Windows to give your team a private option that is faster than the tool they are currently using without telling you.