Suppose a US software company uses customer conversations to answer support requests, then proposes training a model on the same records. Some conversations describe a person's health; Swiss customers use the service alongside customers in the EU. A GDPR legal-basis entry for the service does not resolve that change of purpose. Under Art. 6 DSG, Switzerland's federal data-protection statute makes purpose and compatibility central to the analysis.1Bundesgesetz über den Datenschutz (Datenschutzgesetz, DSG) vom 25. September 2020 (SR 235.1), version of 7 July 2025, Art. 6 and Art. 30 to Art. 31 (private processing and justification). The difference affects both the training dataset and the service built from it.
1. Why Does a GDPR Legal Basis Not Settle the Swiss Position?
The GDPR starts with a positive condition of lawfulness. Art. 6(1) GDPR requires at least one of its listed bases for personal-data processing. Art. 9 GDPR adds a prohibition and specified exceptions for special categories, including health and genetic data; legitimate interests alone do not remove that additional restriction.2Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation) [2016] OJ L119/1 (GDPR), Art. 6 and Art. 9 (lawfulness and special-category conditions). A European AI training assessment therefore cannot stop after identifying a plausible commercial interest.
For private companies, Swiss law asks a differently structured question. Art. 30 DSG prohibits unlawful interference with personality rights. Its examples include processing contrary to the principles of Art. 6 DSG or security requirements of Art. 8 DSG, processing against an express declaration of the person's wishes, and disclosure of sensitive personal data to third parties. Art. 31(1) DSG makes an interference unlawful unless justified by consent, an overriding private or public interest, or law. The statute does not require a private controller to allocate one of six GDPR-style bases to every processing operation.
That distinction is confined to the private-sector regime. Art. 34 DSG requires a statutory basis for processing by federal bodies, subject to its specified qualifications and exceptions. Art. 2 DSG distinguishes those bodies from private persons. A company supplying a public institution cannot assume that the customer's authority follows the company's private-sector analysis, or that every public customer is governed by the federal statute.
The practical difference appears when support records become training material. Art. 6(3) DSG requires collection for a specified purpose recognizable to the person and subsequent processing compatible with that purpose. Art. 6(2), Art. 6(4) and Art. 6(5) DSG add proportionality, deletion or anonymization when data are no longer needed, and appropriate accuracy measures. A contract permitting service delivery does not itself explain why identifiable conversations must improve a model for other customers. Calling that activity product development leaves the purpose, necessity and personality interference to be assessed.
A public source does not remove that inquiry. Art. 30(3) DSG normally finds no personality interference where the person made the data generally accessible and did not expressly prohibit processing. That formulation concerns the data subject's conduct and wishes, not merely the technical accessibility of a page. A training collection assembled from public websites may contain records published by someone else, or data whose reuse the person expressly opposed. The commercial fact that a dataset can be acquired without authentication does not establish the statutory conditions for every record in it.
For private companies, a Swiss justification addresses interference with personality rights. A GDPR legal basis and a Swiss justification may draw on similar facts, but they answer different statutory questions at each stage of AI processing.
Consent also requires care. Art. 6(6) DSG governs consent where it is required: it must be voluntary, informed and directed to specified processing. Art. 6(7) DSG requires express consent for sensitive-data processing and high-risk profiling by private persons. Read together, these provisions prescribe consent's quality and form where relied upon; they do not make consent the only justification for every health-data operation. Art. 31(2)(e) DSG identifies non-personal purposes, including research, as a setting where an overriding interest may arise, with conditions concerning anonymization, sensitive-data disclosure and non-identifiable results. An AI research label does not establish those conditions.3DSG (n 1), Art. 6, Art. 30, Art. 31 and Art. 34 (scope of consent and justification).
The research provision also makes the intended output material. Art. 31(2)(e) DSG requires anonymization as soon as the purpose permits. If that is impossible or disproportionate, appropriate measures must prevent identifiability. If particularly sensitive personal data are disclosed to third parties under that research provision, the people concerned must not be identifiable; only if that is impossible must the controller ensure those third parties process the data solely for non-personal purposes. Published results must not identify the people concerned. A developer's research description cannot establish these restrictions where its actual purpose remains evaluation of particular individuals.
The EDÖB, the federal data-protection authority, confirmed on 9 November 2023 that the DSG applies directly to AI-supported personal-data processing. Existing duties therefore operate during development as well as use.4Eidgenössischer Datenschutz- und Öffentlichkeitsbeauftragter (EDÖB), ‘Geltendes Datenschutzgesetz ist auf KI direkt anwendbar’ (9 November 2023), direct application of the DSG. The separate analysis of Switzerland's AI regulatory approach addresses the policy framework.
2. When Do Information and Human-Review Duties Attach?
Training data and model behavior present different identification questions. Art. 5(a) DSG concerns information relating to an identified or identifiable natural person. Removing names from a source table does not, by itself, establish that all information in a model has ceased to relate to identifiable people. On the EU side, the EDPB addresses this issue in Opinion 28/2024, adopted on 17 December 2024. It calls for a case-specific assessment of whether extracting personal data from a model, or obtaining such data through queries, is insignificantly likely using reasonably likely means. A vendor's assertion of anonymity is insufficient.5European Data Protection Board (EDPB), Opinion 28/2024 on certain data protection aspects related to the processing of personal data in the context of AI models (adopted 17 December 2024), paras. 35 to 48 and 134 to 135.
The same opinion distinguishes development from deployment. Its legitimate-interest analysis examines the interest, necessity and balancing of competing rights. Merely mentioning training in a privacy policy does not establish that people reasonably expect it. Where a model retains personal data, unlawful development may affect later processing, assessed in the circumstances of the case. That concern can follow a model to a different deploying controller. These are EU conclusions, not a substitute for Art. 30 and Art. 31 DSG, but they undermine the commercial assumption that buying a finished model settles the provenance question.
Demonstrable anonymization changes the EDPB's downstream analysis without excusing the earlier processing. The authority's powers over unlawful development remain, while subsequent operation involving no personal data falls outside the GDPR. If a customer then supplies fresh personal data during deployment, that processing remains covered. An anonymous model and a service that processes no personal data are therefore different propositions. The distinction matters when a vendor describes the model's status as if it settled the customer's use of it.
Swiss information duties likewise do not depend on a direct customer relationship. Art. 19 DSG requires appropriate information when data are collected, including indirectly. The controller identifies itself, the purpose and any recipients or recipient categories; indirect collection adds the categories of data processed. Foreign disclosure brings additional country and safeguard information. For indirect collection, the outside limit is one month after receipt, or earlier disclosure if that occurs first. Art. 20 DSG contains exceptions and restrictions, including impossibility or disproportionate effort for indirect collection. A large dataset alone does not establish the exception.
Deployment adds a distinction between profiling and deciding. Art. 5(f) DSG defines profiling through automated evaluation of personal aspects. Art. 5(g) DSG adds high risk where linked data permit assessment of essential aspects of personality, with the required risk to personality or fundamental rights. Neither definition turns every AI tool into high-risk profiling. Art. 21 DSG addresses a further question: a decision based exclusively on automated processing with legal consequences or a considerable effect on the person. It requires information and, on request, an opportunity to state a position and review by a natural person.6DSG (n 1), Art. 5 and Art. 19 to Art. 21 (information, profiling and automated decisions).
Art. 21(3) DSG removes those information and review duties where a directly related contractual decision grants the person's request, or the person expressly consented to automated decision-making. Art. 22 GDPR instead establishes a prohibition in principle, with exceptions for contract necessity, authorizing law or express consent and associated safeguards. A contract's existence is not its necessity, and granting a request is not the same test.7GDPR (n 2), Art. 22 (qualified prohibition and safeguards).
The consequence of express consent illustrates the difference. Under Art. 21(3)(b) DSG, consent to the automated decision removes the information and review duties of Art. 21(1) and (2) DSG. Under Art. 22(2)(c) and Art. 22(3) GDPR, explicit consent can permit an otherwise covered decision, but the minimum safeguards still include human intervention, an opportunity to express a view and contesting the decision. The Swiss exception also leaves the underlying processing requirements in place. The same consent interface therefore cannot be understood through the same legal explanation in both markets.
In SCHUFA, the Court of Justice held that a credit agency's automated score itself falls within Art. 22 GDPR where the receiving third party draws strongly on it for its contractual decision. Describing the score as preparatory did not resolve its determining role.8Case C-634/21 SCHUFA Holding (Scoring), EU:C:2023:957, judgment of 7 December 2023, paras. 40 to 64 and 73 (determining downstream use of a credit score). The holding does not make every recommendation an automated decision, and it does not decide Art. 21 DSG.
3. What Changes Before the Model Reaches Production?
A service's legal role can change when its use of data changes. Art. 5(j) DSG identifies the controller by decisions about purpose and means; Art. 5(k) DSG identifies a processor acting on that controller's behalf. Art. 9 DSG permits outsourcing only within processing the controller could itself carry out and where no statutory or contractual secrecy duty prohibits it. A vendor answering its customer's prompts and the same vendor retaining those prompts for its own model may therefore present different role questions. The processor label in a service agreement does not determine both activities.
Art. 7 DSG requires compliant technical and organizational design from the planning stage. Its defaults must limit processing to the minimum necessary for the purpose, unless the person determines otherwise. Art. 8 DSG separately requires risk-appropriate security from controllers and processors. These duties matter to choices such as retaining identifiable prompt histories or making them available for general training. A justification for processing does not supply the missing design decision or make an unnecessarily broad default proportionate.
For the controller, Art. 22 DSG requires a prior data-protection impact assessment where processing may create high risk to personality or fundamental rights. New technology matters alongside nature, extent, circumstances and purpose. Large-scale sensitive-data processing is an express example. The trigger is therefore a risk assessment of the proposed activity, rather than the word AI. The statute also contains qualified exceptions for private controllers, including legally required processing and specified certification or code-of-conduct arrangements. Art. 69 DSG preserves narrow transitional relief for processing begun before the statute's commencement only where its purpose stays unchanged and no new data are collected.
Where high risk remains despite planned measures, Art. 23 DSG requires prior consultation of the EDÖB. A private controller can instead consult its data-protection advisor under Art. 10 DSG, but that route requires the advisor's independence, freedom from incompatible duties and expertise, as well as publication of the advisor's contact details and communication of them to the EDÖB. The Swiss advisor is a distinct role from the Swiss data-protection representative. Merely appointing a representative does not establish this consultation alternative.9DSG (n 1), Art. 7 to Art. 10, Art. 22 to Art. 23 and Art. 69 (design, impact assessment and consultation). Under Art. 35 and Art. 36 GDPR, seeking advice from a designated data-protection officer does not replace required consultation of the supervisory authority.
The European overlay can reach a Swiss deployment. Art. 2(1)(a) of the EU AI Act covers providers placing systems or general-purpose models on the Union market regardless of location. Art. 2(1)(c) AI Act also reaches third-country providers and deployers where a system's output is used in the Union. Scope exclusions remain relevant, including the distinct scientific-research and pre-market development exclusions in Art. 2(6) and Art. 2(8) AI Act; the latter preserves applicable Union law and excludes real-world testing from its exclusion.10Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act) [2024] OJ L2024/1689 (AI Act), Art. 2 (territorial scope and exclusions).
The July 2026 amendment also prevents an absolute separation between the AI Act and data law. Art. 2(7) AI Act preserves the latter subject to Art. 4a and Art. 59 AI Act. New Art. 4a AI Act exceptionally permits strictly necessary sensitive-data processing for specified bias detection and correction, with cumulative safeguards. Its qualified reach includes certain providers and deployers beyond high-risk-system providers. The extension concerns biases likely to affect health or safety, negatively affect fundamental rights or lead to discrimination prohibited by Union law; it creates no new obligation to perform that work. Art. 4a(1) and (2) AI Act require more than an asserted fairness benefit. Other data, including synthetic or anonymized data, must not effectively achieve the objective. Reuse, access and security restrictions accompany deletion and recordkeeping requirements, and the sensitive data cannot be transmitted, transferred or otherwise accessed by other parties. That restriction matters to a cloud arrangement in which several organizations could access the bias-testing dataset. The exception is neither general training permission nor a Swiss justification.11Regulation (EU) 2026/1744 of the European Parliament and of the Council of 8 July 2026 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 as regards the simplification of the implementation of harmonised rules on artificial intelligence (Digital Omnibus on AI) [2026] OJ L2026/1744, Art. 1 and Art. 4 Regulation (EU) 2026/1744 (sensitive-data bias provision and commencement).
4. What Survives US Hosting and Incident Response?
Sending training records to a US recipient raises a transfer question in addition to the processing question. Art. 16 DSG permits foreign disclosure where the Federal Council has found adequate protection, or through the specified safeguards where no such decision exists. Art. 17 DSG supplies particular exceptions. A justified training purpose does not itself establish one of those transfer routes; a transfer route does not establish that training respects the original purpose or avoids unlawful personality interference.
The Swiss-US Data Privacy Framework became legally effective for the Swiss adequacy listing on 15 September 2024. Annex 1 of the DSV limits the US entry to personal data processed by organizations certified under the Swiss-US framework. The original ordinance amendment of 14 August 2024 specifies the commencement date.12Verordnung über den Datenschutz (Datenschutzverordnung, DSV) vom 31. August 2022 (SR 235.11), version of 1 December 2025, Art. 8 and Annex 1 item 44 (Swiss-US certified organizations). This is not a finding that every US recipient offers adequate protection. An EU-US certification alone does not answer whether the organization falls within the Swiss entry.
For an AI service, that boundary matters beyond the location of its headquarters. A disclosed dataset may serve inference, customer-specific adaptation or general model development. The recipient and the actual processing remain material to the adequacy route. A statement that data remain in the United States says nothing by itself about Swiss certification, while a valid Swiss transfer route says nothing by itself about whether the recipient may change the purpose. The health-data analysis for US software vendors addresses the additional context of health services and Swiss customers.
An incident then exposes another difference hidden by a common European procedure. Art. 24(1) DSG requires the controller to notify the EDÖB as quickly as possible when a security breach is likely to result in high risk to personality or fundamental rights. Art. 33 GDPR requires notification without undue delay and, where feasible, within 72 hours of awareness, unless the breach is unlikely to create a risk to individuals' rights and freedoms. The Swiss threshold is high risk; its text supplies no 72-hour allowance. A policy that treats the EU period as a Swiss deadline confuses both the clock and the threshold.
The processor's Swiss duty is separate. Art. 24(3) DSG requires notification to the controller as quickly as possible, without reproducing the controller's high-risk threshold. For affected individuals, Art. 24(4) DSG requires information where necessary for their protection or where the EDÖB requires it, subject to qualified exceptions. Art. 34 GDPR uses likely high risk and notification without undue delay, again with exceptions.13DSG (n 1), Art. 24; GDPR (n 2), Art. 33 to Art. 34 (different breach-notification thresholds and timing). One incident can therefore require different notification conclusions within the same group.
Sanctions also resist a single corporate fine model. Art. 60 to Art. 63 DSG specify intentional offenses, including certain information, care and secrecy breaches and disobedience of a duly warned order, with fines up to CHF 250,000. They do not criminalize every shortcoming in an AI program or make every officer liable merely by title. Responsibility concerns the particular offense and responsible person. Art. 64 DSG permits a business fine instead where a fine no greater than CHF 50,000 is in prospect and identifying liable individuals would require disproportionate investigative measures.14DSG (n 1), Art. 60 to Art. 64 (specified intentional offenses and the business-fine exception). For example, Art. 61(c) DSG concerns failure to observe the minimum security requirements issued under Art. 8(3) DSG. It is not an offense framed as any failure to complete an AI design exercise. Art. 63 DSG requires intentional disobedience of an order issued with the specified penalty warning. Management needs to distinguish a substantive duty from a specified criminal offense and an order backed by a penalty warning. Contractual allocation of a vendor's tasks cannot make those statutory distinctions disappear.
5. Strategic Considerations for US Teams Training AI in Switzerland
A unified privacy program can carry common facts across markets: which records enter a model, why they are retained, who determines their use, and what a deployment does to a person. Its weakness appears when a shared label is treated as a shared legal conclusion. Does the service agreement concern only answering a customer's question, or also improving a model for strangers? Has the vendor remained a processor for the activity under examination, or begun deciding an additional purpose? The value of the common record lies in making those differences visible.
The model itself does not end the inquiry. If a provider claims anonymity, what evidence supports that claim in the deployed setting, including access and queries? If personal data remain, a model acquisition also raises the provenance and subsequent-processing issues discussed in the EDPB's opinion. If deployment materially determines a person's treatment, describing the output as advice does not establish that the automated-decision rules are irrelevant. These questions affect what a purchaser is acquiring and which uses a customer can credibly promise.
The Swiss analysis can also change without any new AI-specific statute. New records, a changed training purpose or a different deployment can alter the facts against which existing principles, information duties and impact-assessment rules operate. A US transfer certification resolves a particular cross-border condition; it cannot answer those lifecycle questions. Nor does a completed European AI assessment decide the private-sector justification under Swiss law.
The commercial consequence is a limit on standardization by conclusion. A group may use the same model and service in Switzerland and the EU, while the legal grounds for using it, the conditions for human review and the decisions about reporting an incident remain distinct. A program that preserves those distinctions can explain what the same system is permitted to do in each market. A single entry marked GDPR compliant cannot supply that explanation.