Building AI
Governance Policy:
Rules That Actually Hold Up
Most companies adopted AI before writing the rules for it.
That sequence is backwards, and it shows. Engineering teams picked up coding assistants. Marketing started running prompts through public chatbots. Finance built spreadsheets that call out to an API. None of it waited for a policy, because there wasn’t one to wait for.
An AI governance policy is supposed to close that gap. It’s the document that defines approved AI tools, what data can touch them, and who owns the risk. Most organisations don’t have one. The ones that do often wrote it once, in a hurry, and haven’t looked at it since.
The same pressure is building across financial institutions in Switzerland and Germany, and healthcare providers in France and the Netherlands. Enterprise software firms across the EU and the US feel it too. Different regulators, same question: who is accountable for what the AI does, and can you prove it?
1. Why a Verbal Understanding Isn’t a Policy
Ask five people what they’re allowed to put into ChatGPT, and you’ll get five different answers. That inconsistency is not a training problem. It’s a policy gap.
A 2024 study by Cyberhaven found that 11% of data employees paste into AI chat tools is classified as confidential. Multiply that across a workforce of any size. The absence of a written AI governance policy isn’t a minor oversight – it’s an open door.
The cost of that gap shows up in two places:
- GDPR exposure. Personal data entered into a third-party AI tool without a data processing agreement is a clear violation. Fines run up to 4% of global annual revenue.
- Audit failure. Regulators ask for the policy document first. “We trust our people” doesn’t survive a real review.
A governance policy doesn’t eliminate these risks by itself. It creates the accountability structure that makes managing them possible.
2. What an AI Governance Policy Should Actually Contain
Quick answer:
A complete AI governance policy covers six areas: scope, ownership, risk classification, usage rules, security requirements, and compliance mapping. Most policy drafts fail because they cover only one or two – typically a list of banned tools – and skip the ownership structure that makes the rest enforceable.
A policy that only lists prohibited tools is not a governance policy. It’s a blocklist, and blocklists age out within a quarter.
A functioning AI governance policy needs to define:
- Scope. Which systems, teams, and AI categories are covered. This includes AI embedded in vendor software, not just tools employees choose themselves.
- Ownership. Who approves new tools, owns the risk register, and can suspend access when something looks wrong.
- Risk classification. A grammar checker and a credit-scoring model don’t belong in the same review tier.
- Usage rules. What employees can and cannot do with approved tools – covered below.
- Security requirements. Access control, data handling, and vendor due diligence – also covered below.
- Compliance mapping. Which regulations apply to which use cases, and how the policy proves it.
Skip any one of these, and the policy collapses. It won’t survive the first question it wasn’t written to answer.
3. Usage Policies: Who Can Use What, and How
Quick answer:
An AI usage policy defines a tiered list of approved tools, the data classifications allowed for each tier, and the approval process for adding new tools. The goal isn’t to restrict AI use. It’s to make the sanctioned path easier than the unsanctioned one, so shadow AI has nowhere to hide.
Banning AI tools outright is understandable, and almost always counterproductive. Employees who can’t use a sanctioned tool will use an unsanctioned one instead. The policy has to compete with convenience, not just prohibit risk.
A working AI usage policy typically tiers tools into three categories:
- Approved for general use. Enterprise-tier tools with contractual data protection and no training on customer inputs. Open to all employees for non-sensitive work.
- Approved with restrictions. Usable only for specific tasks, roles, or data classifications. A coding assistant might be approved for internal tooling but restricted from a regulated module.
- Not approved. Consumer-grade tools with no enterprise data agreement, or any platform that hasn’t passed security review.
For each tier, specify the data classification allowed, who can request a new tool, and how long that takes. A process that takes six weeks guarantees employees won’t use it – they’ll use something else instead.
4. Security Restrictions: Closing the Shadow AI Gap
Quick answer:
AI security restrictions cover access control, vendor due diligence, and logging – the same controls organisations already apply elsewhere, extended to AI-specific risks like prompt injection and unmonitored agentic actions. The most common gap isn’t weak controls. It’s the absence of an inventory: you cannot secure AI systems you don’t know exist.
Shadow AI is the use of tools that IT never approved – by employees and engineering teams alike. It’s the gap most AI security policy sections fail to close. Most policies assume a visibility into AI use that doesn’t exist.
The starting point is always an inventory. You cannot write enforceable security restrictions for AI systems you haven’t found.
From there, a credible AI security policy requires the following.
- Access control with MFA for any AI development environment, model registry, or admin console.
- Vendor security review before approving any new tool, covering data residency and incident notification terms.
- Logging of AI-assisted actions, especially where AI agents have write access to production. An unmonitored action can cause damage faster than a human can react.
- Defined escalation paths for when an AI system behaves outside expected parameters, so a response isn’t improvised mid-incident.
Some engineering organisations have already built tiered review gates for AI-generated code. The same logic extends to tool access and data handling.
5. Compliance Requirements: Mapping the Policy to Regulation
Quick answer:
AI compliance requirements vary by jurisdiction, but the EU AI Act, GDPR, and sector rules like DORA and FINMA guidance converge on the same expectations: documented risk classification, human oversight for high-risk use cases, and a demonstrable audit trail. A policy mapped to these requirements turns a legal obligation into an operational checklist.
For organisations operating across the EU, Switzerland, and the US, the regulatory map isn’t optional reading. It’s the backbone of the policy itself.
The EU AI Act requires risk-tiered classification and human oversight mechanisms for high-risk systems. A governance policy that skips this classification framework isn’t actually aligned with the law it’s meant to satisfy.
For financial institutions, DORA adds operational resilience requirements on top: AI systems must be tested, documented, and recoverable. Germany’s BaFin treats AI explicitly as an ICT system under DORA. That includes software purchased without anyone consciously deploying it.
For Swiss enterprises, 2024 FINMA AI Governance Guidance closely mirror the EU framework. Swiss banks and insurers serving EU clients face effectively the same AI compliance requirements as their EU-headquartered counterparts.
GDPR sits underneath all of this. Any AI system processing personal data needs a lawful basis. Document it at the point data enters the system, not after a complaint.
Different regulators phrase the question differently. They’re all asking the same thing: can you show your risk classification, who reviewed it, and what went wrong?
6. Where ISO/IEC 42001 Fits
Quick answer:
ISO/IEC 42001 is a voluntary international standard for AI management systems, published in 2023. It follows the same structure as ISO 27001, making it a natural extension for organisations that already run an information security management system. Certification is optional, but the structure – leadership commitment, risk assessment, continual improvement – is a useful blueprint regardless.
Most organisations don’t need a new certification to benefit from ISO/IEC 42001. Its real value is structural. It gives a governance policy a recognised shape, built around the same leadership and risk clauses as ISO 27001.
For US-facing organisations, NIST’s AI Risk Management Framework follows comparable logic without a certification path. Neither standard replaces the EU AI Act, DORA, or FINMA guidance. What they offer is a consistent architecture for mapping to all three at once.
7. From Document to Practice: Ownership, Review, and Enforcement
Quick answer:
A governance policy that isn’t reviewed, owned, and enforced is a document, not a control. Effective enforcement needs a named owner, a review cadence – typically every six months, given how fast AI tooling changes – and a tabletop exercise that tests the policy before an auditor does.
The policy document is the easy part. Most governance failures happen after publication, not before.
What enforcement actually requires:
- A named owner. Not a committee – one person accountable for the policy’s currency and for exception requests.
- A review cadence. AI tooling changes faster than most governance documents do. A policy reviewed annually is reviewing last year’s risk landscape.
- Training tied to role, not a one-time onboarding module everyone forgets by month two.
- A tabletop exercise. Pick a recent AI-related decision and reconstruct who approved it, what data was involved, and what the policy required. If you can’t, the policy isn’t working yet.
This is the same discipline that makes tiered review gates work in engineering delivery. The policy only holds if someone actually checks that it’s followed.
Conclusion
An AI governance policy isn’t a document you write once and file away. It’s the layer that turns “we trust our people” into something a regulator, a client, or a board can verify.
The organisations ahead of this problem treat the policy as infrastructure – owned, reviewed, and tested. Not paperwork produced for a single audit cycle.
IMT Solutions works with enterprise clients across Switzerland, the EU, and the US. We design AI governance frameworks built to hold up under regulatory scrutiny. Explore our case studies or contact our team to talk through where your policy currently stands.
Frequently Asked Questions
What is an AI governance policy?
An AI governance policy is a written document that defines how an organisation approves, uses, secures, and monitors AI systems. It covers tool approval, data handling rules, security requirements, and the compliance obligations the organisation must demonstrate to regulators.
What should an AI usage policy include?
An AI usage policy should tier approved tools by risk level. It should specify allowed data classifications per tier, and define the process for requesting a new tool. The goal is to make sanctioned AI use easier than unsanctioned use, not simply to ban tools outright.
How often should an AI governance policy be reviewed?
Most organisations should review the policy every six months, given how quickly new AI tools reach the market. A policy reviewed only once a year is governing a risk landscape that has already changed.
Does the EU AI Act require a written AI governance policy?
The EU AI Act doesn’t name a single required document. But it requires risk classification, human oversight mechanisms, and audit-ready documentation for high-risk AI systems. In practice, those obligations are hard to demonstrate without a written governance policy that defines and enforces them.
