Before You Build Anything, Write the Policy.

We’ve all seen the reporting in recent weeks that AI could end the world as we know it. We’ve also seen the reporting for months that AI could usher in some sort of magical utopia where money doesn’t matter and everyone lives in blissful equality.

We try to avoid sweeping generalizations about the future of our society a decade from now. But this much is clear: the opportunity AI presents is unprecedented, and so are the risks.

That is true for any organization. The opportunity and risk this technology presents are both effectively infinite. This doesn’t mean you shouldn’t adopt AI. It means you should, and we’d argue you absolutely need to, but you need to do so thoughtfully and deliberately. In our experience, adopting AI well comes down to two things:

1. Mitigating the risks as much as possible.
2. Actualizing the measurable value as much as possible.

To do those two things, you need two things.

To actualize the value, you need a strategy. You need to be clear about your goals, what you want AI to do for you, and the metrics you care most about. You need to design AI systems that will measurably impact those metrics, and you need to design them thoughtfully.

To mitigate the risk, you need a policy: a robust internal AI policy. A policy is just another word for a risk mitigation strategy. You need to be clear about what shouldn’t be done by AI and what can’t be done by AI lawfully.

Most consultants and AI gurus are obsessed with the first part. They’re obsessed with the opportunity, and rightfully so. So are we. Nearly anything is possible. But in our experience, people already understand that anything is possible. What they don’t understand, what they’re worse at, is developing a thoughtful AI policy that actually mitigates risk while actualizing value. It’s why we see companies investing billions of dollars and getting nothing in return. It’s why we see agents fail, poor maintenance, falling adoption, growing fear, and a host of other problems. Most of these problems are explained by a lack of governance.

The data agrees. IBM’s 2026 Cost of a Data Breach report found that among organizations that suffered an AI-related breach, 92% lacked proper AI access controls. Only 40% of organizations apply access controls to AI models and data at all. Schellman’s 2026 State of AI Governance survey found that 74% of enterprise leaders believe they could pass an AI compliance audit today. Only 27% have a governance program they’d call mature, and only 57% have a formal AI governance policy.

To mitigate the risk this technology presents, you need an AI policy. Here’s how.

The hard part of writing an AI policy is that it could cover anything. So we organize it around five questions. Together they spell GUARD, which is what the policy is for.

Keep the policy itself short and principle-level. Put the detail that changes often, the approved tool list, the thresholds, the state-by-state rules, in referenced standards that can be updated without taking the whole policy back to the board.

Nothing else in the policy works without this. Someone has to own it. Not a committee in the abstract, a named executive whose job includes keeping the policy alive. Under that person, a small cross-functional review body that approves new AI uses, with security as a standing member. IBM found that governance and security coordinate at only 19% of organizations, and the blind spots that creates show up in the breach data.

The governance section also establishes the inventory: a registry of every AI system and every agent in the company, who owns it, what it touches, and what tier of risk it carries. You cannot assess risk, train people, or respond to an incident for systems you don’t know exist.

Finally, it sets the cadence. Given how fast the law is moving, review the policy at least twice a year, and define what counts as an AI incident so it plugs into the incident process you already have.

This is the section most companies have, and it’s usually the only one. It covers what employees may and may not do: which tools are approved, which are banned, whether personal accounts may be used for work, and what has to be verified by a human before it goes out the door.

Two things to get right. First, a ban alone does not work. IBM found shadow AI incidents more than doubled in a year, to 43% of breached organizations, and that breaches involving shadow AI cost more. If you prohibit a tool, provide a sanctioned alternative that is at least as good, or people will route around you. Second, verification scales with stakes. A draft summary for internal use needs a glance. A number in a customer contract needs a human who is accountable for it.

Use also covers training. Distributing the policy does not count. Role-based training, documented, is what the EU AI Act’s literacy obligation expects of companies with European operations, and it’s what makes the rest of the policy real.

This is the section almost every existing policy is missing, and it’s the one that matters most if you’re building anything. A policy written for chatbots does not cover a system that holds credentials, calls tools, and takes actions on your behalf.

Every agent gets its own identity with the minimum permissions it needs, scoped and expiring. Agents do not touch production without explicit approval. Every action is logged somewhere the log can’t be edited. Every agent has a kill switch and a spend limit. And certain actions always require a human to approve them before they happen:

• Moving money
• Sending anything externally
• Deleting data
• Deploying code
• Committing the company to anything contractual

This is not theoretical. In 2025, a coding agent at Replit ignored an instruction not to change code and deleted a live production database. The company added automatic separation between development and production afterward. A policy with an approval gate would have had it there before.

The Agents section is also where you set the standard every builder in the company follows: how an agent is scoped, what it must log, what it may never do, and what instructions live in your company’s AI platform so that everyone starts from the same rules. More on that at the end.

The legal floor depends on where you operate, and it is moving fast. Colorado passed an AI law in 2024 and rewrote it in May 2026. The EU moved its high-risk deadlines in July 2026. Texas’s law took effect in January 2026 with penalties up to $200,000 per violation. If your policy body cites a statute by name, it was out of date within months.

So the Regulation section does two things. It names the jurisdictions you operate in and the obligations each imposes, kept in an annex that a named owner updates as the law changes. And it anchors the policy to a framework that moves more slowly than statutes. We recommend the NIST AI Risk Management Framework as the operating model. It maps to the EU’s duties, and in Texas, substantial compliance with it is an affirmative defense.

The point is not to turn your policy into a legal treatise. It is to make sure someone is watching, and that the policy can adapt without being rewritten.

If you only write one section well, write this one. Of the eighteen clauses we’d put in a full policy, uncontrolled data going into AI tools is the single costliest thing to leave out. This is the Samsung pattern: an engineer pasted sensitive source code into a public chatbot, and the company banned generative AI on its devices entirely. The right answer was a data rule, not a ban.

Classify your data into tiers and match each tier to the systems allowed to touch it.

The Data section also sets your vendor terms. At minimum: no training on your data without consent, disclosure of subprocessors, incident notification windows, advance notice of model changes, and the right to get your data back when you leave. Vendor liability does not replace yours. When Air Canada’s chatbot gave a customer wrong information, the tribunal rejected the argument that the chatbot was a separate entity and held the airline responsible.

If you can’t do all five at once, do them in the order of what it costs you to leave them out:

1. Data input rules and classification (Data)
2. Agent permissions, approval gates, logging, and kill switches (Agents)
3. Approved tools and shadow AI detection (Use)
4. Vendor contract terms (Data)
5. An owner and an inventory (Governance)

Here is the part no one is talking about. The problem with most AI policies is not what they say. It’s that no one reads them. A policy that exists in a PDF on a shared drive is not mitigating any risk. For a policy to be followed, it has to be ACE: Accessible, Clear, Enforceable.

Every policy before this one lived in a document and relied on people remembering it. This one doesn’t have to.

Put your agent-building standard directly into the instructions of your company’s AI platform. Put your data tiers there too. Now whenever anyone in the company opens the tool to build an agent, the policy is already in the room. They don’t have to find it or remember it. The system holds them to it by default. An employee who tries to connect an agent to a restricted data source without an approval gate doesn’t get a warning email three weeks later. They get stopped at the moment they try.

This is new. AI is the first technology that can enforce the rules about its own use. But it only works if you actually write the policy into those systems, and that is the step almost no one takes.

It would be easy to read all of this as caution. It isn’t.

The companies we work with are not trying to adopt AI slowly. They are trying to adopt it faster than anyone else in their industry, and the reason they can is that they aren’t afraid of it. Fear is what happens when you don’t know where the edges are. A good policy draws the edges. Once they’re drawn, the people inside them can move at full speed, because they know exactly what they’re allowed to build and exactly what will stop them if they get it wrong.

That is the whole point of governance. Not to slow you down. To let you go faster than you could without it.

We believe the organizations that don’t adopt AI today will be out of business within the next decade. We also believe the organizations that Aictualize the potential of AI now will lead their industries a decade from now. The difference between the two is not courage, and it’s not budget. It’s whether they did it deliberately.

Write the policy. Then build.