What belongs in an AI policy?

Three things: which tools may be used with which data classes (public, internal, especially sensitive), who in the company is responsible for each tool, and a way for employees to report a doubtful case. Four ground rules for daily use come on top. To start with, one page is enough for that.

How long does it take to set up AI governance?

Budget an afternoon for the first draft of the policy, once the data classes and approved tools are settled. What takes real effort afterwards is reviewing the provider contracts. Delays almost always arise because the document is meant to cover a bit more at every meeting.

Who decides whether an AI tool gets approved?

The person who wants to use it and is accountable for it. Legal, data protection and security advise and lay out the risks. Without a named responsible person, a tool should not go into productive use.

Do we need to train employees in using AI?

Anyone falling under the EU AI Act, the EU's AI law, has had to take steps on the AI literacy of their employees since 2 February 2025. The AI Omnibus, an EU amending package, replaced Article 4 in July 2026 and softened the duty. What is required are measures that support AI literacy. Nobody is required to guarantee a particular level. For Swiss companies with no EU connection, training remains a matter of work quality.

AI governance: one page is enough to start

Q: Does my company need AI ethics principles?

Not to start with. Much of what ethics principles would contain is already binding through the revised Federal Act on Data Protection (revFADP), copyright law and your existing contracts. What goes beyond that is a deliberate self-commitment. A dedicated set of values pays off once the policy is in place and you have some initial experience.

An AI policy, the internal rule for how to use AI tools, that takes three months to finish protects no one today. Shadow AI, the use of unapproved tools, grows for exactly as long as the document sits in draft.

What belongs in AI governance?

AI governance defines how employees may use AI tools at work, and it only helps once it is in force. One page with three parts is enough: a policy stating which tool is allowed with which data, a responsible person per tool, and a point of contact for doubtful cases before use.

In brief

Budget an afternoon for the first draft of the policy. Reviewing the provider contracts, meaning what the provider may do with the data entered, takes the weeks after that.
Purchased line-of-business software also contains AI features that nobody ever approved. Each one belongs in the tool table, described further below as the core of the policy, with a line of its own.
If nobody wants to enter their name in the table as the responsible person for a tool, the company apparently does not need it. That, too, is a useful outcome.
Without a date on the policy, you cannot show in a dispute which version applied. Put one on it.

One client had made AI governance a top-management priority: its own focus group, fixed meetings, high priority. Every meeting added a chapter that nobody had missed before. Months later, nothing exists that an employee could read, and the employees have long since been working with personal accounts. Shadow AI, the use of unapproved tools, grows for as long as the document sits in draft. An unfinished page that is in force today protects better than a complete one arriving in three months.

This article is the fourth part of our Law & Regulation series, and the most practical one: the obligations from the other parts turn into one page that applies in daily operations.

What belongs on the one page

The core is a table. It answers the question an employee actually has: am I allowed to enter this here?

Before that, you need three data classes, no more. Public is anything that could also sit on your website. Internal is the normal case: quotes, minutes, source code with no customer link. Especially sensitive covers health, HR and client-mandate data, plus anything subject to a duty of confidentiality. Anyone who sets up four or five levels creates boundary questions that nobody answers in daily practice.

The table has three columns: the tool, the approved data classes and the owner, the responsible person.

Tool	Approved data	Owner
Chat tool, business tier	public, internal	Name
Translation service, signed in	public, internal	Name
Coding assistant	public, internal	Name
Line-of-business app with AI feature	per contract	Name

Add four rules, and daily use needs nothing more:

Use approved tools only, company account only, only with the data approved for it.
Check results for accuracy, because responsibility for your own work stays with you.
Disclose where third parties need to know that AI was involved.
Report what goes wrong, even where it could be quietly fixed. Whoever quietly fixes a case makes sure the next person makes the same mistake.

How to staff the owner role

The column on the far right says who answers when there is a question. This person knows the contract, sets the approved data classes and keeps them updated when the provider changes something.

The owner rarely sits in IT. They sit wherever the benefit accrues: the translation service with marketing, the coding assistant in development, the AI feature in the ERP with whoever already manages the ERP. Whoever gets the benefit should propose it and be accountable for it. Legal, data protection and security advise and lay out the risks. The body that issues the policy also signs off the approval.

This role also makes clear who the acting person is if things go wrong. Why that matters is explained in our revFADP guide: the criminal provisions of the data protection act reach the acting person inside the company. The data-protection obligations themselves stay with the company.

When someone asks

A policy cannot anticipate every future use case. The five questions on which a project can stall, together with the reasoning behind them, are set out in the regulatory map.

For the policy, what matters is what follows a yes to one of these questions. Three details are enough: who the question goes to (the point of contact), by when it gets answered, and where the decision is recorded. Without these details, employees keep deciding for themselves, but with a guilty conscience.

The response time is the part most likely to be forgotten. Anyone waiting weeks for approval reaches for a personal account in the meantime. Set a deadline your point of contact can keep even in a busy week, and name a deputy.

What you can leave out

Statements of principle on responsible AI use are well-intentioned but can be left out at the start. Much of what is in them is binding anyway through the revFADP, copyright law and your existing contracts. What goes beyond that is a deliberate self-commitment. A dedicated set of values pays off once the policy is in place.

Much the same applies to training. Anyone falling under the EU AI Act has had to take steps on the AI literacy of their employees since 2 February 2025. The AI Omnibus replaced Article 4 in July 2026 and softened the duty. The measures to take are ones that support the development of AI literacy, and nobody has to guarantee a particular level. For a Swiss company with no EU connection, training is therefore a question of work quality.

How to get started

Four steps lead to the first draft:

01

Write down the data classes

The three levels from above, each with one example from your own business. This is the basis for the "Approved data" column.
02

List the tools

Whatever is already in use today, including the AI features in purchased software. One owner per line.
03

Put the page into force

With a date, the issuing body and a point of contact. Empty rows are allowed: whatever is not in the table is not approved.
04

Update it after a year

Contracts, reported incidents, tools added since.

The legal grounding behind this one page is set out in the other parts of the series: the regulatory map, the revFADP guide, and the article on professional secrecy.