← All insights ←

Switzerland's AI Code: The structure is in place, some tools are still missing

By · Published: 4 November 2026

AI GovernanceRegulationBoard of DirectorsRisk Management
Switzerland's AI Code: The structure is in place, some tools are still missing

On 28 October 2026, the Swiss Federal Council took note of the state of work on implementing the Council of Europe’s AI Convention. Part of this work is a ‘Guide to an AI Code’ published by DETEC and OFCOM. It is aimed at associations and companies that want to adopt voluntary rules for their use of artificial intelligence.

The path was set out in February 2025. Alongside changes to the law, the Federal Council relies on legally non-binding measures such as self-commitments and sector solutions. The guide belongs to this second track.

For boards of directors, a simple question arises: is this document enough to build effective AI governance in the company? My answer: it is enough to start with. It becomes effective only with tools that the document itself does not provide.

What is well done

The structure is well thought out and easy to understand. The guide organises a code into ten manageable articles, from purpose and scope to maintaining the code. For each article there are text modules at three levels of detail, freely combinable and written in the ‘we’ form. An association can start with a few sentences, while a company with high risks can set tighter guardrails at the same time.

The proposed drafting process is also realistic. It calls for backing at leadership level, a mixed team and a connection to existing structures. For the risk analysis, the document points to the NIST AI Risk Management Framework and its Playbook. It also states that responsibility for a decision always remains with a person.

The benchmark the government sets itself

The guide describes AI governance as a chain: principles, instructions derived from them, and processes built on top. It calls this whole chain ‘indispensable for effective AI governance’, yet limits the code to principles.

This is a deliberate and openly declared choice. But anyone who implements only the code in its simplicity does not yet have effective governance by the government’s own benchmark. They have one link of the chain.

The same shows at the high level of detail. There it says that something is ‘documented’, ‘checked’ or ‘assessed in a traceable way’. How, by whom and against which criteria remains open.

One word carries the whole weight

The strict modules usually apply only under one condition: the application must be ‘significant’ or have ‘significant effects’. This is the case for human dignity and autonomy (Art. 5 a), for accountability (Art. 5 c), for reliability and security (Art. 5 g) and for dealing with affected persons (Art. 7). For fairness, the wording is ‘relevant effects’ (Art. 5 e).

What exactly counts as ‘significant’ is something a general guide can hardly settle. Each organisation has to define it for itself. The guide, however, does not say so. Art. 4 does recommend a glossary for the key terms; that ‘significant’ belongs there is not mentioned, and criteria for orientation are missing. As a result, each organisation silently decides whether its strict rules apply at all. Without a criterion, a translation of product texts and a chatbot that analyses customer data can fall under the same module.

In my view, two further weaknesses concern the levels of detail. The guiding questions for the medium and the high level are almost identical; at their core they differ only in the word ‘minimum’. The level of detail is chosen per article of the code. In practice, a choice per application would be more useful: not every AI in the company needs the same oversight.

What is missing in practice

Five gaps stand out when I test the modules against a concrete company.

  • AI register: The guide names an inventory analysis as a step in the drafting process. No text module requires a continuously maintained register of AI applications. Without a register, however, effective monitoring and reporting are hardly possible.
  • Criteria for approval: Personal data and confidential information may only be processed in ‘approved’ AI systems (Art. 5 f). The criteria for approving a system are not stated.
  • Suppliers and exit: External suppliers must not break the chain of responsibility (Art. 5 c, Art. 6), and dependencies have to be checked (Art. 5 g). How to assess a supplier, and how to get away from one again, remains open.
  • Shadow AI: Private accounts with public chat services do not appear in the text. Yet this is exactly where data leaves the company without anyone having decided on it.
  • Framework and individual case: Art. 6 calls for clear roles. But it does not separate the framework, which is set by those overseeing AI, from the individual use case, which executive management decides on. For a board of directors, this separation is the core of overall management and overall supervision (Art. 716a of the Swiss Code of Obligations).

The code deliberately does not list legal requirements in detail. That explains some of these gaps, but it does not close them.

The AI code is a self-commitment of the organisation and stays at the level of principles, just as the guide intends. But for each tool it needs one sentence that points to the implementation. The tools themselves belong in policies and processes; they can be adapted without changing the code.

Overview of the five tools: classification, AI register, data classification for AI use, supplier assessment and approval sheet, each with the corresponding sentence in the code, the article and the addressees.
Figure 1: The five tools, their sentence in the code and their addressees. Author’s own illustration.

For employees in their daily work, the data classification for AI use matters most. The other tools address the functions that decide on the use of AI.

1. Classification: defining ‘significant’ yourself

My proposal assigns each application to one of three risk classes based on five characteristics. The table describes the application as planned; which controls it needs follows from the class. The highest risk counts: if an application falls into class 3 on a single characteristic, it belongs in class 3. Each organisation adapts the characteristics to its business.

The class states how concrete the rules for the application have to be. This follows the logic of the AI code: with each level of detail, the requirements become more concrete and stricter. At low risk, the general principle is enough. At high risk, the tight guardrails of the high level of detail are needed.

Classification table with five characteristics (technology, data, affected persons, consequences of errors, autonomy) and three risk classes, from low risk with a general principle to high risk with tight guardrails.
Figure 2: Classification: five characteristics assign each application to one of three risk classes. Author’s own illustration.

The guiding rule: the simplest technology that fulfils the purpose is usually the best. Art. 5 h at the high level of detail says the same; the table makes it usable.

2. AI register

One line per application: name, purpose, responsible person, supplier, path of the data, class from the classification, status, date of the next review. The register is the basis for Art. 6 (roles), Art. 8 (monitoring) and the reporting to the board of directors.

3. Data classification for AI use

The rows are data classes. The columns are operating models, that is, the way the AI is embedded in the organisation, from a private account to a locally operated model. The table answers what ‘approved’ means under Art. 5 f and belongs in the AI acceptable use policy for all employees. A proposal as a starting point:

Matrix of data classification for AI use: five data classes from public to sensitive personal data against four operating models from private account to local model, with the levels allowed, with conditions and prohibited.
Figure 3: The more sensitive the data, the narrower the permitted path. Author’s own illustration.

‘With conditions’ means: a data processing agreement, a check of cross-border disclosure, additional technical and organisational measures (TOMs), and depending on the risk a data protection impact assessment and an approval. The assessment depends on the specific contract. Without defined data classes, the table has no effect.

4. Supplier assessment

Eight questions before any contract with an AI supplier:

  1. Where is the data processed and stored?
  2. Is our data used for training?
  3. How long is it stored, and who has access?
  4. Which law applies, including for authorities abroad?
  5. Is there a data processing agreement, or only general terms and conditions?
  6. Who is responsible for operation and security?
  7. How dependent do we become, and how do we get out again?
  8. Who is liable for errors or data leakage, and what does the contract exclude?

5. Approval sheet

Five questions before an application of class 2 or 3 is put to use:

  1. Which problem are we solving?
  2. Which data flows along which path?
  3. Who checks the results, and who can intervene?
  4. Is an exit from the supplier possible?
  5. How will we know after six months whether use and costs have proven themselves?

The header of the sheet is at the same time the line in the register. Register, assessment and approval are created in one step.

An addition to Art. 6

A text module for the code itself that is missing from the guide: ‘Those overseeing AI set the framework: risk appetite, permitted areas of use and guardrails. Executive management decides on individual applications within this framework. Whatever exceeds the framework is decided by those overseeing AI.’

Conclusion

The AI code is a usable structure and a good starting point for an organisation’s own code. The guide gives associations and companies a common outline and a language that can be adapted. Its effect depends on the organisation defining what is ‘significant’ and providing tools for it.

A board of directors does not have to wait for further steps by the government. It can start today with two resolutions: require a register of AI applications, and put an AI acceptable use policy with clear data classes into force. Each fits on one page. The code is written afterwards, with the modules from the guide.

Transparency note

Generative AI was used in a supporting role for research and editorial preparation of this article. The conceptual design, the selection and weighting of the content, the professional assessment, the final version of the text as well as the responsibility for all statements and conclusions lie with me.

Sources