The EU AI Act now applies: four questions for a Swiss company
Published · updated
On 2 August 2026, most of the European Union’s Artificial Intelligence Act, usually called the EU AI Act, became applicable. The transparency rules now apply, and the EU institutions and national authorities have begun enforcing the provisions already in force. The date matters. It does not turn every use of ChatGPT by a Swiss company into a high-risk system.
A company in Switzerland can fall outside the Act for one use and inside it for another. A tool that drafts internal notes for a team in Lausanne raises a different question from a recruitment service sold in Lyon or a score produced in Geneva and used by a Paris office. The model name does not decide the answer. The company’s role, the route into the EU and the purpose of the output do.
I am an engineer, not a lawyer. I use the following four questions as a technical and operational screening before production. A lawyer should confirm the legal scope where the answer affects people, market access or a regulated activity.
1. Is the company a provider or a deployer?
The consolidated text of the Act calls a machine-based system an AI system when it can operate with some autonomy and infer from its inputs how to produce a prediction, content, a recommendation or a decision. A fixed spreadsheet formula is not automatically an AI system. A model that ranks applications, an assistant that writes an answer and an agent that chooses which tool to call can be.
A model is the component that generates content or makes a prediction. The system is the complete business setup around it: the model, instructions, data, interface, user accounts and controls. In this article, an AI agent means a system that can choose and call software tools to complete a sequence of steps. Its permissions matter as much as the quality of its answers.
The Act then assigns different responsibilities to two roles:
- Provider: the organisation develops an AI system, has one developed, and places it on the market or puts it into service under its own name. A company can therefore be the provider of a branded service even when a contractor wrote the code and an external model produces the text.
- Deployer: the organisation uses an AI system under its authority for a professional purpose. A company that licenses a supplier’s assistant for its employees is normally a deployer. The employees are not separate deployers while they act under the company’s instructions and control.
That distinction changes who must design the system, prepare its documentation and give information to the people using it. A purchase contract cannot answer the question by itself. The company must record whose name appears on the service, who chose its purpose, who can change it and who controls its use. A major modification or a new purpose can also change the role, so the note needs review when the system changes.
2. Does the Act reach this use from Switzerland?
Switzerland is outside the EU, but the Act has territorial links that reach beyond an EU address. Three routes matter most to a Swiss company:
- The EU market: a provider places an AI system on the EU market or puts a system into service there. The provider can be established in Switzerland.
- An EU deployer: the organisation using the system is established or located in the EU. A Swiss group therefore examines each entity and each deployment, rather than relying on the address of its head office.
- Output used in the EU: a provider or deployer in a country outside the EU can enter scope when the system’s output is used in the EU. A score produced by a Swiss team and used by a French office is the plain business example.
An internal drafting assistant used only by a Geneva team has no obvious EU connection on those facts. A Swiss software company offering a customer-facing AI service in France has one. Borderline cases need legal analysis; the phrase “available online” is not a substitute for tracing where the service is offered, who operates it, where its output is used and whom it affects.
The first scope record can fit on one page. It names the legal entities, the countries where the system is offered and operated, the people affected and the place where the output changes a business process. If one of those facts changes, the scope conclusion needs a new review.
3. What does the system do to a person?
The AI Act classifies a use by the harm it can cause, not by the prestige or size of the model. Four categories provide the useful first pass.
- Prohibited practices: examples include social scoring, harmful manipulation and emotion recognition in a workplace outside the narrow exceptions. The relevant bans have applied since 2 February 2025. A company stops the proposed use and obtains legal advice; a control added after deployment does not make a prohibited purpose acceptable.
- Transparency duties: these can concern a service that speaks directly with a customer, a synthetic video that could be mistaken for a real one or AI-written public-interest information. Article 50 transparency duties have applied since 2 August 2026. The responsible party depends on the use and on whether the company is provider or deployer.
- High-risk systems: examples include software used to rank candidates for a job, manage workers or decide access to education and certain essential services. These uses appear in Annex III, the list of sensitive purposes attached to the Act. Their specific high-risk requirements now apply from 2 December 2027 following the AI Omnibus, the July 2026 amendment that changed several deadlines and rules. Existing employment, data-protection and discrimination rules still apply before that date.
- Minimal or no risk: a spam filter or an internal text helper that makes no consequential decision about a person will usually start here. The AI Act adds no special obligations for most uses in this category. Other law, the supplier contract, confidentiality and ordinary security controls still matter.
Several terms in these categories need a plain meaning. Emotion recognition means inferring a person’s emotions or intentions from biometric data such as a face or a voice. A deepfake is a generated or manipulated image, audio recording or video that could falsely appear authentic. A high-risk recruitment system is not merely a tool that helps write a vacancy; it is a system intended to select people or evaluate candidates in a way that can affect access to work.
For a system that communicates directly with people, the provider must design the interaction so that a person knows from the start that an AI system is replying, unless that fact is obvious. A company using a supplier’s chatbot should verify the notice in the real interface rather than assume the supplier added it. Deployers have separate disclosure duties for emotion recognition, biometric categorisation, deepfakes and some AI-generated text published to inform the public. Biometric categorisation means sorting people by physical or behavioural traits measured by a technical system.
The postponed high-risk deadline should not postpone the inventory. A recruitment system needs time to identify its provider, document its intended purpose, examine the data used to evaluate people, test unequal errors and define genuine human oversight. Starting that work in December 2027 leaves no time to correct the design.
The Act also requires providers and deployers in scope to support the AI literacy of their staff. AI literacy means a practical grasp of how a system works and where it fails. Staff also need to understand the context of use and which people may be affected. The obligation has applied since 2 February 2025, and supervision began in August 2026. The amended rule prescribes no single “sufficient” level. Role-specific instructions and worked examples show what staff were taught. An attendance record shows who received that instruction.
4. Which evidence exists before production?
The following production file is my operational starting point. The AI Act does not impose this exact file on every AI system. Its purpose is to put the facts, tests and decisions in one place before an incident, a supplier review or a request from an affected person exposes the gaps.
-
A named owner and a bounded purpose: one manager writes the task the system may perform, the people who use it and the decisions it may not make. The boundary lets the company detect an unapproved extension before it becomes ordinary practice. A named owner cannot make an unlawful purpose lawful.
-
The role, territorial route and risk category: the file states whether the company acts as provider or deployer, which EU connection was tested and why the use falls into a category. This gives a lawyer or auditor a factual conclusion to challenge. The conclusion expires when the market, purpose or affected population changes.
-
The data and supplier path: the company records which information enters the system, where processing occurs, whether a supplier may retain it or use it for training, and which further providers receive it. That map exposes an undeclared transfer or reuse before confidential data leaves. It remains accurate only while someone reviews contract and product changes.
-
Acceptance tests and known failures: a representative set of real cases measures useful answers, wrong answers, refusals and differences between groups where fairness matters. The result gives management a release threshold and shows reviewers which cases need escalation. Passing a fixed set never guarantees the next output.
-
A real human decision point: the procedure names the person who reviews an output, the information available to that person, the time allowed and the authority to reject it. A signature added after an automatic decision is a rubber stamp, not oversight. Workload and automation bias, the tendency to trust a machine’s output too readily, can still weaken a well-designed review. The company therefore measures overrides and exceptions.
-
Permissions and proportionate logs: each person and program receives only the data and actions required for the task, while the log records tool calls, approvals, failures and changes. Limited access reduces the consequences of an error; the log helps reconstruct it. Logs can create a second store of personal or confidential data, so their content and retention also need a limit. See identity and access for the underlying account design.
-
A rehearsed shutdown procedure: the team can disable the system, revoke its credentials, continue the work manually, report an incident and export the records needed to change supplier. A rehearsal proves that those actions work before an emergency. The procedure reduces the duration and cost of a failure; it does not prevent every bad output.
Four ordinary uses need four different answers
The intended purpose changes the analysis even when all four systems call the same underlying model.
-
An internal drafting assistant: an employee uses an approved tool to prepare an email and reads the text before sending it. This will usually be a minimal-risk use under the AI Act. Swiss data protection and confidentiality may still apply, as may the supplier’s use of prompts. The company defines which data may enter, tests the account settings and makes the sender responsible for the final message.
-
A public support assistant: the direct conversation creates a transparency question. Personalised answers also raise questions about access and personal data. The interface clearly tells the customer that AI is replying, offers a route to a person and prevents one customer from retrieving another customer’s information. A secure AI assistant has to carry those decisions into the interface.
-
A CV-ranking system: recruitment is an Annex III high-risk purpose when the Act applies. The special high-risk rules begin on 2 December 2027, while current employment and data-protection duties remain. The company identifies the criteria, measures unequal errors, gives the reviewer the original application and records real overrides. A human who sees only the model’s score cannot independently review it.
-
An invoice agent: using AI does not by itself make the automation high- risk, and its permissions can still create financial loss. The agent receives read access to invoices and permission to prepare an entry, not authority to release a payment. The log connects the source with the proposed entry and approval. The same boundary is built into a business agent.
These are starting points, not legal conclusions that remain valid in every context. A change from “draft” to “send”, from “recommend” to “decide”, or from an internal user to a customer can change the obligations without changing the model.
Swiss law already applies to personal data
Switzerland does not yet have one general law devoted specifically to AI. The Federal Chancellery says that a draft for consultation is due by the end of 2026. The absence of that general law does not create a legal waiting room.
The Federal Act on Data Protection, or FADP, already applies when an AI system processes personal data, meaning information relating to an identified or identifiable person. The Federal Data Protection and Information Commissioner states that anyone who builds, supplies or uses such processing must explain its purpose. The same explanation covers how the processing works and where its data comes from. A person communicating with a language model must also be able to understand that a machine is replying and whether the entered data will be reused to improve the service or for another purpose.
An automated individual decision is a decision made without human intervention that has a legal effect on a person or affects that person significantly. Under Article 21 FADP, the controller, meaning the organisation that decides why and how the personal data is processed, must inform the person. Subject to the statutory exceptions, it must also allow that person to state a view and ask for review by a human being. A hiring rejection, a credit decision or access to an important service can therefore raise a Swiss duty even when the EU AI Act does not reach the use.
The FADP also requires a data protection impact assessment when planned processing is likely to create a high risk to the personality or fundamental rights of the people concerned. In Swiss data-protection law, personality includes a person’s private sphere and control over personal information. The impact assessment describes the processing, evaluates those risks and records the measures used to reduce them. It is a specific legal instrument, not another name for the broader production file above.
The EU and Swiss reviews therefore run side by side. One determines whether the AI Act reaches the system and which of its duties apply. The other examines the personal data and the decisions already governed in Switzerland. Employment law, professional secrecy and sector rules may add a third review.
PERINGER turns the review into a working system
During data and AI work, I turn the four questions into an inventory, a data-flow map, tests on real cases, named approval points and an operating procedure. The legal interpretation remains with the company and its counsel. My part is to make the chosen limits observable in the architecture and testable before the service goes live.
For an assistant, the user can open each source and every search applies the right permissions. The project also declares retention and tests the hand-off to a person. For an agent, each tool has a limit and consequential actions wait for approval. An action log and a stop procedure complete the operating record. The project is ready for production when the company can demonstrate those properties on its own cases, not when a supplier presentation describes them.
Primary sources and review date
- European Commission: AI Act framework and application timeline
- European Commission: AI Omnibus changes and extended deadlines
- EUR-Lex: consolidated Regulation (EU) 2024/1689 as at 27 July 2026
- European Commission: Article 50 transparency questions and answers
- European Commission: AI literacy questions and answers
- Swiss Federal Chancellery: regulation of AI
- Federal Data Protection and Information Commissioner: AI and data protection
I reviewed the legal timetable and the cited official guidance on 25 August 2026. Deadlines, guidance and the Swiss legislative project can change; a production decision should verify the current texts again.