Organisations using AI
Self-reported organisational AI adoption in 2025, as summarised by the 2026 AI Index; the 2025 edition reported 78% for 2024. Survey data, not a Swiss census or a productivity measure.
A policy must serve both governance review and everyday work. Consider the regulator, board and audit audiences, then test whether a project manager, analyst, assistant or professional adviser can use the same rules to decide what is permitted.
A useful AI policy is not a wall of prohibitions. It is an operating tool. It tells people which uses are encouraged, which are restricted, which are prohibited, and what to do when a use case does not fit neatly into the categories.
Bankins and colleagues’ systematic review of AI in organisations identifies individual, team and organisational factors shaping work with AI. It supports looking at the setting in which a policy is used, not just its wording. The five sections below are Ada Studio’s design choices: test them with the team rather than treating them as a guarantee of compliance or adoption.
Translate risk into everyday decisions
A policy should translate concerns about hallucinations, data leakage, copyright, bias, applicable law and reputation into concrete decisions. Awareness of those concerns does not demonstrate that a person can apply the rules.
Can I summarise a client call? Can I paste a contract clause? Can I use an AI meeting assistant? Can I ask a model to rewrite a board memo? Can I use a public tool if I remove names? Can I use the output in a deliverable if I reviewed it?
If the policy does not answer these questions, teams will make their own rules. That is how governance becomes informal, inconsistent, and hard to defend.
The hidden failure mode
An unused or impractical policy can create false confidence. Test both its content and its application; neither permissive nor restrictive wording alone establishes effective control.
Five sections to consider
1. A simple use-case map
The policy should start with the work people actually do. Group uses into practical categories:
- drafting and productivity support, assessed according to the data and context, including grammar, formatting, brainstorming and public-information summaries;
- internal knowledge work, such as drafting, analysis, meeting notes, and decision support;
- client, patient, employee, or customer-facing work;
- high-impact decisions, such as hiring, credit, health, legal, education, safety, or access to services;
- prohibited or paused uses.
This structure is easier to apply than a purely legal taxonomy. Legal classification still matters, but teams need a front door they understand.
2. Data rules people can remember
A usable policy should distinguish between public, internal, confidential, personal, sensitive, and regulated data. It should explain what may be entered into which type of tool.
The rule should be concrete. For example: public AI tools may be used for non-confidential drafting and brainstorming, but not for personal data, including client, patient, employee and sensitive personal data, or for trade secrets or unpublished financial data, unless an approved enterprise configuration and review path exists.
3. A review standard
AI-assisted work should have a human review rule. The rule cannot simply say "review output". It should explain what review means:
- verify factual claims;
- check citations and references;
- compare output against source documents;
- test assumptions;
- identify missing context;
- document material AI contribution where needed;
- escalate when the output affects rights, obligations, safety, money, health, or reputation.
4. An approval path for new tools
People should know where to go before connecting a new AI tool to organisational data. The path should cover vendor review, data processing, security, model training terms, retention, access controls, human oversight, and business owner accountability.
5. Examples, not just rules
Use scenarios to test whether people can distinguish allowed use, conditional use, prohibited use and cases requiring review.
Data rule
Weak version: Do not share confidential data
Usable version: Public tools: no personal data (including client, patient, employee and sensitive data) and no confidential or unpublished business data. Approved enterprise tools: use only within listed workflows.
Human review
Weak version: Users must check outputs
Usable version: Verify facts, sources, calculations, assumptions, and suitability before relying on output or sharing externally.
Tool approval
Weak version: Ask IT if unsure
Usable version: Submit tool name, use case, data types, users, vendor terms, and owner before pilot.
Legal anchors (CH/EU)
- Sensitive data: base the policy’s sensitive category on the legal lists. Under FADP Article 5(c), sensitive personal data are data on religious, philosophical, political or trade union views or activities; health, the intimate sphere or racial or ethnic origin; genetic data; biometric data that uniquely identifies a natural person; administrative and criminal proceedings or sanctions; and social assistance measures. Where the GDPR applies, use the special categories in GDPR Article 9(1); personal data relating to criminal convictions and offences are separately restricted by GDPR Article 10.
- External AI services: when a provider processes personal data on your behalf, FADP Article 9 requires a contract or legal basis, allows only processing you could lawfully do yourself, excludes assignment where a statutory or contractual duty of confidentiality prohibits it, and requires you to satisfy yourself that the provider can guarantee data security; the provider may assign processing to a third party only with your prior approval. GDPR Article 28 sets comparable processor requirements. Disclosure of personal data abroad must meet FADP Articles 16 and 17.
- High-risk processing: FADP Article 22 requires a data protection impact assessment beforehand where processing is likely to result in a high risk to the data subject’s personality or fundamental rights. Whether the risk is high depends on the nature, extent, circumstances and purpose of the processing, in particular when new technologies are used; a high risk exists notably in the case of large-scale processing of sensitive personal data. Article 22(4) and (5) set out exemptions.
- Automated decisions: if a decision is based exclusively on automated processing and has a legal consequence for, or a considerable adverse effect on, the person concerned, FADP Article 21 requires the controller to inform that person; on request, the person may express their point of view and ask for the decision to be reviewed by a natural person, subject to the exceptions in Article 21(3). Where the GDPR applies, GDPR Article 22 gives a right not to be subject to a decision based solely on automated processing that produces legal effects or similarly significantly affects the person, subject to exceptions with safeguards.
- EU AI Act: where the AI Act applies, including to providers and deployers outside the EU whose AI system output is used in the EU (Article 2(1)(c)), Article 4, as replaced by Regulation (EU) 2026/1744 with effect from 27 July 2026, requires providers and deployers to take measures to support the development of AI literacy of their staff and other persons operating or using AI systems on their behalf; it does not require them to guarantee any specific level of AI literacy of any individual. The Article 5 prohibitions have applied since 2 February 2025, with two further prohibitions from 2 December 2026. Deployers of high-risk systems, which can include certain systems for recruitment, work-related decisions or the creditworthiness of natural persons under Annex III, must assign human oversight to natural persons with the necessary competence, training, authority and support (Article 26(2)). Under Article 113 this applies from 2 December 2027 for Annex III systems; other dates and transitional rules apply to product-related systems and to systems already placed on the market (Articles 111 and 113).
- Swiss AI rules: the Federal Chancellery states that Switzerland does not yet have any overarching AI-specific legislation. On 12 February 2025 the Federal Council announced that Switzerland intends to ratify the Council of Europe Framework Convention on AI, which Switzerland signed on 27 March 2025. A consultation draft for the required legislation, in particular on transparency, data protection, non-discrimination and supervision, is due by the end of 2026.
FADP links point to the English translation, which has no legal force; the German, French and Italian texts are authoritative.
The governance test
A good AI policy should pass three tests:
- Can a non-specialist understand it? If not, it will not shape behaviour.
- Can a manager enforce it? If not, it is only a statement of intent.
- Can the organisation show evidence? If not, it will be difficult to defend later.
NIST’s AI RMF organises risk work through Govern, Map, Measure and Manage, with governance spanning the other functions. ISO/IEC 42001 provides a management-system perspective. Neither validates this article’s policy layout.
A policy is not the end of AI governance. It is the interface between governance and daily work.
What to do next
One illustrative starting point is a one-page working policy tested on three real workflows. Adjust the length and sample to the variety and risk of the work. Record ambiguous cases, revise the rules and expand testing before relying on the result.