An Internal AI Policy That Fits on One Page

Most internal AI policies fail on their length, not their content. A fourteen-page document sent out once and never opened again protects nobody — it only records that somebody addressed the topic. A policy works when an employee sitting in front of a client document on a Tuesday morning knows within ten seconds whether they may upload it.

In workshops I almost always put the same question to the room: who knows whether there is a rule about this here? Usually two people raise a hand, and in roughly half the cases they contradict each other. That is the real state of affairs in many Swiss SMEs — not an absence of rules, but a rule that exists and has reached nobody.

This article is not about what the law requires. That is already covered in AI and data protection in Switzerland and, for the European part, in the EU AI Act for SMEs. This is about the document itself: what goes on it, how it is written, why the good ones are short — and what belongs in the appendix only two people read.

Why the long ones go unread

A thorough policy grows from an understandable impulse: not wanting to forget anything. The result is a text that covers every conceivable case and therefore answers none of them quickly. It becomes protection for the author instead of orientation for the reader.

A second mechanism compounds it. The longer a document, the more abstract its wording, because abstraction is what allows completeness. "Company data is to be handled with care" covers everything and decides nothing. The employee in front of the client document is exactly as well informed afterwards as before — except that now they carry the decision alone, because a rule does exist.

And there is a third, less comfortable mechanism. Long policies are almost always written outside the business, by someone who knows the legal position and not the work. They are therefore reliably correct and reliably unusable: they speak of "processing sensitive personal data" where in-house it means "the sick notes", and of "approved systems" where the question is whether Marina may paste the quote into ChatGPT. Between the document and the work sits a translation nobody performs.

A good policy is therefore not a legal text but a decision aid. Every sentence has to answer a question somebody actually has.

What happens while there is no rule

It is not that nothing happens without a policy. It just happens unobserved.

Large international surveys over the past two years converge on an order of magnitude of four in five AI users bringing their own, unapproved tools to work. The striking part is not the height but the direction: the rate is if anything higher at small and mid-sized companies than at large ones. Anyone assuming this is a big-company problem, with their thousands of endpoints, has it exactly backwards. A corporation has an IT department that can see installed software. A thirty-person company has a browser and nobody looking into it.

Two further findings from the same body of work explain why this stays invisible for so long. First, a substantial share of users openly say they would rather not admit to using AI for important tasks, out of concern it makes them look replaceable or less competent. Second, security vendors that measure actual traffic on company networks report that even at businesses with a properly configured commercial account, roughly a third of usage still runs through personal logins. Those are not representative population figures but measurements inside those vendors' own customer base — but the order of magnitude matches what I see in workshops whenever the question about personal accounts is asked once without managers in the room.

From that follows perhaps the most important insight for the whole document: you are not writing a policy to introduce AI use. You are writing it to make existing use visible and safe. That changes the tone. A text that pretends to be deciding something prospective is read by people who have been doing it for a year — and loses its credibility in the first paragraph.

The six blocks that belong on the page

1. Which tools are allowed. By name, with account type. "ChatGPT on the business account" is a rule; "AI tools" is not. Also name what is explicitly not allowed where it is common in-house — translation services, transcription tools and note-taking assistants in video calls are in use at almost every company and appear in almost no policy. Add one sentence on how to propose a new tool. Otherwise shadow IT arises not from bad faith but from not knowing what else to do: someone with no procedure for "am I allowed to?" simply tries it.

2. Which data may go into which tool. The heart of the matter, and the only block that needs some structure. Three tiers are almost always enough:

• Open: anything already published or publishable — marketing copy, public figures, general questions. May go anywhere.
• Internal: quotes, cost calculations, minutes, code. Only into tools with a commercial contract and no training on content.
• Sensitive: personal data of clients and staff, health and recruitment data, contracts with confidentiality clauses. Only after explicit approval, and specifically by a named person.

The value of those three lines lies not in the classification but in the fact that they are filled with your own examples. "Quotes" is understandable; "internal business documents" is not. Write two documents that are genuinely on your desks behind each tier, by name: "the weekly plan", "the quote to the municipality", "the sick notes". That is the difference between a classification and a rule.

3. Where a human has to check. Not everywhere — nobody would keep to that, and a review duty that applies everywhere applies nowhere. Name the places where a mistake gets expensive or embarrassing: everything that leaves the building, everything with numbers, everything legal, everything with a client name in it. Normal care applies to the rest. And phrase the check as an action, not an attitude — "compare against the source", not "critically appraise".

4. How you handle it towards clients. This question comes up in every workshop and is almost never settled. Does a client need to know a draft was produced with AI? Decide it, in one sentence, in both directions: what you disclose and what you treat as an ordinary tool. A team that does not know this becomes evasive in a client conversation — and the client notices.

5. Who decides in case of doubt. A name, not a function. "If in doubt, ask Marina" works; "contact the responsible office" ends the thought. This person is the most important part of the policy, because they catch the cases nobody thought of while writing. Give them two things: a response-time promise, so questions do not disappear, and the authority to actually grant an exception. A contact point that has to escalate every request stops being asked after the third time.

6. What to do after a mistake. One sentence, without a threat. Someone who has accidentally uploaded the wrong thing should be able to report it without facing consequences worse than the mistake. Otherwise you will not hear about it, and that is the only case where it genuinely becomes dangerous. Include what happens next: delete the conversation, inform the contact person, and where third-party personal data is involved, check whether a notification is required. Three lines, so nobody improvises in the moment.

The six ways data tiers fail

Splitting data into three tiers is quick work. What is interesting is where the split tears in practice — and that turns out to be remarkably uniform across industries and company sizes.

Client data lands in the same drawer as your own secrets. Most schemes distinguish open, internal and confidential — and then throw your own strategy and the client's material into the same tier. That is too coarse. For your own data you decide how much risk you want to carry. For client data you have often already answered that contractually, in a confidentiality clause you signed before the tool existed. Client data therefore belongs one tier above your own internals, not on the same one.

"Anonymised" gets believed instead of tested. Removing the name is not enough when role, project, date and amount remain. In a company with twelve clients, "the conversion of a commercial building in Wädenswil, construction starting in spring, around 1,200 square metres" is not an anonymised case but a name by a detour. The usable rule of thumb: if you show the text to a colleague from another department and they guess who it is about, it is not anonymised.

Metadata gets forgotten. The body text is redacted; the filename stays "Quote_Muster_AG_final.docx", the spreadsheet carries hidden columns along with it, the PDF holds the author and revision history in its document properties. Anyone uploading a file rather than an excerpt always uploads more than they read.

Persistent configurations are not seen as data stores. The custom assistant, the custom GPT, the saved instruction in the profile: whatever was entered there sits permanently with the provider and is sent along with every conversation. People who carefully weigh what they type into a single chat will cheerfully store client lists and pricing models in the configuration, because it feels like a setting rather than an input. The policy has to treat the configuration explicitly like an input.

Classification is thought of as static. A draft starts as an internal text and becomes sensitive the moment the real client name and the real numbers are in it. Without a named switching point, the document keeps the tier it had when it was first opened. Write the trigger down: "as soon as real names or real numbers are in it".

Classification is treated as a purely internal matter. It is also a legal one. Putting personal data into a tool that processes it abroad is a cross-border disclosure, not merely a question of internal handling. A scheme that ignores this looks tidy inside the building and does not hold outside it.

The seventh failure is not in the scheme but in the process: the classification exists, but nobody was ever shown two examples from their own working day. Then everyone classifies whichever way is more convenient in the moment — and systematically downwards.

Why the account type matters more than the provider

The question that comes up most often in workshops is: do they train on our data? The answer is unsatisfyingly precise, because it depends on the contract, not the provider.

As of September 2026 the same pattern holds across the large providers, with differences in the defaults:

Two things about this matter more than they look.

First, the step is between personal and commercial, not between free and paid. A paid personal subscription feels like the professional option and remains contractually a consumer relationship — without a data processing agreement, without the evidence you would have to produce for a client. This is the most expensive misunderstanding in the whole area, because it is made by people who are trying.

Second, the defaults differ between providers, including in the personal accounts. With some, using conversations to improve the model is on out of the box and has to be switched off individually; with others it is off out of the box. That is exactly why the policy should contain no general sentence about "AI providers" but a tool list with account types — and the appendix should carry the date on which those settings were last checked. These defaults change; every statement about them has an expiry date, including this one.

The legal underpinning, as short as it can be

Four points are enough for the appendix. The detail is in the revDSG article; here only what shapes the policy.

The provider is a processor. As soon as personal data goes into a tool — and a client name in a quote is already personal data — the provider is processing data on your behalf. You may outsource that, but only within what you would be permitted to do yourself, and only where no confidentiality obligation stands in the way. In practice this is demonstrated through a written agreement. A business account without a signed agreement is, strictly speaking, already a gap.

Disclosure abroad needs a basis. The EEA and the United Kingdom are treated as adequate. For the United States, a framework has been in place since 15 September 2024 under which certified US companies may receive data without additional safeguards — the relevant route for most large AI providers. Where neither applies, you need standard contractual clauses or one of the statutory exceptions. A free account gives you none of this evidence.

The record of processing activities is in principle dispensable below 250 employees — except where sensitive personal data is processed on a large scale or high-risk profiling takes place. Both are judgement calls, not numbers. Anyone working with health, recruitment or proceedings data is better off keeping it.

Sensitive data covers more than most people assume. Health data, data on the intimate sphere, religious, philosophical, political and trade-union views, ethnic origin, genetic and biometric data, data on administrative and criminal proceedings and on social assistance measures. In an ordinary SME this applies more often than expected: sick notes, accident reports, an ongoing employment dispute, a candidate's file.

The disclosure question, answered once and properly

Because it comes up in every workshop, here is the short version. There is no general legal duty in Switzerland to tell a client that a quote or an email was drafted with AI assistance and then reviewed and owned by a human. The European transparency rules in force since August 2026 explicitly carve out content that has undergone human editorial review — and that carve-out describes the normal way an SME works.

One situation is clearly regulated: anyone running an AI-driven chat on their own website must make it recognisable that the other side is a machine, unless that is obvious anyway. Beyond that, professional-body rules in individual sectors may add obligations, and those are worth asking your own association about rather than taking from an article.

The question still belongs in the policy — not as a legal duty but as an agreed form of words. The practical damage does not come from non-disclosure; it comes from a team that does not know what it is allowed to say in a client conversation and therefore dodges.

What does not belong on the one page

The temptation to fit everything in is strong. These things are important but belong in the appendix for the people responsible: the list of contracts and data processing agreements with dates, the question of server locations, the risk-class assessment, the records of the annual review, the list of people trained, the checked defaults per tool, and the rejected tools with a one-line reason.

The last point is usually forgotten and turns out to be remarkably useful: once it is documented why a tool was not approved, the same discussion does not have to be had again every four months.

The appendix may be as long as it needs to be. Two people read it, not forty.

The sentence that makes any policy worthless

It reads, in substance: "The use of AI tools is prohibited in principle; exceptions must be applied for case by case."

A ban like that does not end use. It relocates it. As soon as a tool visibly shortens the working day, it moves to the personal account and the personal phone, where no commercial contract applies, no setting against training on content has been made, and nobody can see what is being uploaded. A manageable risk inside the building becomes an invisible one outside it.

The effect is well evidenced, not through individual cases but through the order of magnitude: companies that formally permit nothing barely differ from companies that permit something in how much AI use actually happens — they differ in where it happens. A ban therefore does not change the amount of risk but its visibility, and in the wrong direction.

None of which means bans are never right. In an HR function or a medical practice, "nothing here" can be the correct rule, and it is then also enforceable, because it is narrow and can be explained. But as a general stance for a whole company it produces the opposite of what it intends.

The policy is one half; the convenient path is the other

The same finding produces the part that is missing from nearly every policy. As long as the permitted tool is more awkward than the forbidden one, the rule loses. Not because people are disobedient, but because they want to get something finished on a Tuesday morning.

Concretely: the business account has to be set up before the policy goes out, not available on request. It has to run in the same browser people work in, ideally through the existing company sign-in. There must be no expense claim involved. And the approval route for a new tool needs a time promise — a week is fine, "we'll look into it" is not.

I have yet to see a company where shadow use fell because the rule got stricter. I have seen several where it fell because the permitted route got faster than the personal one.

How to get it into the business

Do not send it out. Discuss it — twenty minutes, with three real examples from your own building that make the data tiers concrete. That is the part that turns delivery into acknowledgement.

The three examples should not be the easy ones. Take the case where the classification is genuinely disputed within the team — usually a quote with real numbers or a candidate's file. If that case is argued and settled in the room, the people present have understood the rule. If only the uncontroversial marketing text gets worked through, they have listened.

The natural place for this is the foundations part of a training session: everyone is in the room, the topic is open anyway, and the questions come by themselves. That is why for us the policy is not a separate consulting product but an output of the workshop — the team writes the three data tiers using its own documents, and by the evening there is one page nobody has to translate.

The attendance list is enough as evidence. Nobody prescribes a particular form; the European obligation to ensure sufficient AI literacy among your own staff asks for appropriate measures, not a record. That is precisely why the list is useful: it is the cheapest proof that something was done, should the question ever be asked.

How you know it is working

Not because nobody asks any more. Because the questions change.

A policy that has landed produces three observable things. First, the words for the three data tiers turn up in ordinary conversation without anyone opening the document — "that's internal, that's fine" is the sentence you are waiting for. Second, questions reach the named person, and they are questions about cases you did not consider while writing; that is not a defect in the policy but the policy working. Third, at some point somebody reports a mistake before you notice it. The third is the most telling, because it only happens when the sentence about handling mistakes is believed.

If it stays quiet, that is not a good sign. It usually means the decisions are still being made individually and invisibly — exactly as before, except that now there is a document lying next to them.

Conclusion

An AI policy is not a protective document but a working tool. It is good when it makes a decision faster, and bad when it describes an attitude. One page, six blocks, three data tiers with your own examples, one name, one date — plus an appendix for two people and a business account that is more convenient than the personal one. Twenty minutes once a year to check whether all of it still holds.

If you would rather not set this up alone: in our AI training the policy is produced in the workshop itself, together with the team that will have to follow it. Which training format is right for that is covered in the format comparison.