AI policy is probably one of the least exciting parts of AI. Nobody watches an impressive AI demo and thinks they cannot wait to write the policy for it.
We are drawn to what AI can do: write the proposal, analyse the contract, search thousands of company documents, help with code, summarise a meeting, and turn three hours of work into twenty minutes.
The policy usually arrives later, often after someone asks the uncomfortable question: what happens to the information we put into this thing?
That question matters more than it first appears. Imagine a professional services firm where an employee has a client contract open before a meeting. They know AI could summarise the contract quickly. They also vaguely remember an email warning them not to put confidential client information into public AI tools. With the meeting approaching, they may still paste the contract into the tool they use at home. Not because they are reckless, but because it works.
That small moment is where most AI policies succeed or fail.
The policy probably is not the problem
Most company AI policies are sensible. They usually say things like:
- Do not upload confidential information to unapproved systems.
- Do not use AI to make employee decisions without human oversight.
- Protect personal information.
- Use approved tools.
- Check important outputs before relying on them.
There is nothing wrong with those rules. The problem is where they live.
A policy sitting in SharePoint, a PDF, an employee handbook or an email somebody read once is not present when the real decision happens. The real decision happens when someone has a document open at 4:45pm and wants an answer before 5.
That is why static AI governance breaks down. It relies on every employee remembering the rule, correctly classifying the data, understanding which systems are approved, and making the right decision under pressure.
What Policy as Code teaches AI governance
Technology teams have seen this problem before. Security policies, deployment rules and architecture standards existed long before teams had good ways to enforce them automatically.
Eventually, DevOps and infrastructure teams stopped expecting engineers to remember every rule every time they made a change. They put the rules into the systems themselves. If a server should not be publicly accessible, the platform can prevent it. If a deployment must meet a security requirement, the pipeline can check it. If a developer is not authorised for production access, the system can enforce that too.
This developed into Policy as Code: storing policy definitions in machine-readable form so they can be applied consistently. The CNCF also describes policy as code as a way to codify, version and automatically evaluate operational and security guidelines.
AI governance needs the same shift. Your company should still have a normal AI policy written for humans. But the operational version of that policy needs to be enforceable by software.
For example, the human rule might say: client-confidential information must only be processed through AI systems approved for confidential work.
The software rule is more direct: if a task contains a client-confidential document, do not send it to a public AI provider. Route it through a private environment and record the decision.
Not every AI task needs the same route
This is where AI policy can easily become too blunt. Once a business starts thinking seriously about AI risk, there is a temptation to treat everything as sensitive.
But rewriting a public press release is not the same as analysing a client contract. Improving the wording of an internal newsletter is not the same as asking AI to read an employee performance review.
A useful AI policy needs more answers than yes and no. Each task needs a route:
- A marketing rewrite can be approved and logged.
- A customer email containing personal information can trigger a warning and require review before it is sent.
- A confidential contract can be routed privately.
- An attempt to access an HR record from the wrong role can be refused.
Those are four different situations, but they can all happen through the same approved front door. The employee does not need to understand data classification, model hosting or AI policy routing. They need to do their job, and the system needs to apply the right control.
That distinction sits at the heart of the Kubrius AI Control Portal. The Portal checks requests against company rules, can warn or restrict users, applies role-aware access controls, and can route sensitive work into Kubrius Core rather than a public AI service. The decision and outcome can then be recorded as evidence.
Shadow AI is usually a workflow problem
Shadow AI is often discussed as though employees are the problem. That misses the more useful lesson.
People have found tools that make parts of their job easier, and they are using them. Microsoft and LinkedIn's 2024 Work Trend Index research found that 80% of SMB employees were bringing their own AI tools to work, while 49% were reluctant to admit using AI for important tasks.
If the approved way of doing something is harder than the unapproved way, people will eventually find the easier route. Blocking public AI tools does not remove the desire to use AI. Sending another policy email does not remove it either.
The better answer is to build an approved route that is useful enough for people to choose it. Do not just close the back door. Build a better front door.
Where trust becomes the real product
For some businesses this matters more than others. Accountancy firms, law firms, recruiters, consultancies, financial advisers and other professional services businesses are trusted with information clients would never publish on a website: contracts, financial records, employee information, commercial plans and intellectual property.
As AI spreads across the workforce, clients will increasingly ask whether their documents are being put into AI. Saying no may become less credible. Saying yes without controls is hardly reassuring.
A stronger answer is: yes, we use AI, and we can show you how we control it.
That changes the conversation. You can explain which systems are approved, how confidential information is handled, which work is kept private, where human review is required, and what evidence proves those controls were applied.
Evidence changes the conversation
Audit logging is not a phrase that gets people rushing to a product demo. But consider the alternative.
A client asks how their information was handled during a piece of AI-assisted work. Without evidence, someone has to reconstruct the answer. Which employee did it? Which AI tool did they use? Was the document uploaded? Which model processed it? Was company policy followed? Was the output checked by a person?
The company may have a policy saying what should have happened. That is not the same thing as proof.
When the control is built into the workflow, the company can show that a Contract Review task was submitted, the document was identified as confidential, public processing was rejected, the request was routed privately, human review was required and the action was logged.
The policy becomes evidence, and evidence is more valuable than intention.
The risk is becoming less theoretical
This is no longer only an architecture concern. IBM's 2025 Cost of a Data Breach research found that 97% of organisations reporting an AI-related security incident lacked proper AI access controls. IBM also reported that 63% of breached organisations either lacked an AI governance policy or were still developing one, and that high levels of shadow AI were associated with an average $670,000 in higher breach costs than low or no shadow AI.
Those numbers include larger organisations as well as smaller ones, so they should not be used to frighten every SME into assuming disaster is imminent. The practical lesson is narrower and more useful: AI has moved into everyday business workflows faster than the controls around it.
Frequently Asked Questions
What does AI policy as code mean?
AI policy as code means turning AI governance rules into machine-readable controls that can be checked, enforced, versioned and audited inside the AI workflow. The human policy still exists, but software applies the operational rules when work is happening.
Why is a PDF AI policy not enough?
A PDF policy explains what should happen, but it does not shape the decision when an employee is using AI under time pressure. Enforceable controls can warn, block, route or log the task while there is still time for the decision to matter.
Does every AI task need private AI?
No. Low-risk tasks can often use approved external AI services. Sensitive work may need warnings, review, tighter role-based access or private routing. The useful control is matching the task to the right route instead of treating every prompt the same way.
How does this reduce shadow AI?
Shadow AI is often a workflow problem. If the approved route is slower or less useful than a personal AI tool, staff will bypass it. A controlled AI workspace reduces that pressure by making the approved route useful, visible and safer.
What evidence should AI governance produce?
Useful evidence includes who used AI, which workflow was used, what sensitivity was detected, which policy decision was applied, whether public processing was blocked or private routing was used, and whether human review was required.
If you want the broader operating model behind this, read what an AI management system actually needs to work. For a practical first step, use the Kubrius AI Policy-to-Control Mapper to turn one written clause into a draft operational control map.