The Swiss federal data protection commissioner and privatim have published joint non-binding guidance that expects AI processing of patient-monitoring data to stay in the patient's room where possible and treats reuse of that data for AI training as hard to justify

Two publishers, one leaflet, and what it does not cover

The first page explains why two bodies signed it. Depending on which law applies in a given case, personal data processing by a care institution falls under the supervision of the federal commissioner (EDOEB) or of the cantonal data protection authorities. For that reason, the text says, EDOEB and privatim decided to publish the leaflet jointly, to sensitise controllers to the data protection challenges of surveillance sensors. privatim is the conference of the Swiss data protection commissioners. We do not read joint publication as evidence that each cantonal authority separately adopted the text, because the document does not say that and we did not check with any canton.

It is non-binding on its face. A Merkblatt explains law; it does not make it. Every obligation the leaflet describes rests on the federal DSG for private institutions or on cantonal law for public ones (III.1), and section III.1 is explicit that the principles are essentially the same in both, apart from the question of legal basis. Which side of that line an institution sits on is not a matter of corporate form. Footnote 1 says the classification depends on the institution's mandate: a private clinic carrying out orthopaedic procedures on behalf of a canton counts as a public institution for that activity, and one and the same institution can be public for activities that derive from a cantonal mandate and private for the rest. The leaflet also fixes its own scope: it covers surveillance of the persons receiving care only, and states that general surveillance of the institution, cameras in corridors, at entrances and in waiting rooms, is not addressed.

One framing point from the introduction shapes everything after it. The leaflet calls this kind of surveillance a high-intensity measure because it reaches into the private and even intimate sphere of people who are often in a vulnerable position, and adds that for long-term residents it can amount to surveillance of the person's own home.

The taxonomy the AI section is built on

Chapter II sets out four kinds of optical surveillance and then works from the last of them. Analogue direct: a carer sits in the room. Digital direct: a camera streams live video to a monitor. Digital indirect: a camera feeds a computing unit in the same room, which converts the image into a pictogram of the person's position (lying, on the floor, sitting, standing, restless). Indirect situational: the same architecture, but staff receive nothing unless a pre-configured situation such as a fall is detected, and no data leaves the room while nothing happens.

That last model is the leaflet's worked example and the basis for the rest of the text. Steps one to four, the person, the sensor, the raw data and the computing unit, all sit inside the room. The leaflet uses it to illustrate data minimisation: to detect a fall you do not need to see the recording, so staff receive only the alarm or the pictogram, and only in predefined situations.

Chapter II.2 extends this to infrared and radar. Those sensors produce no photographic image but can capture other things a camera misses, body temperature in one case, heart and breathing rate in the other. Because the system has to be tied to a room or a bed so that staff know where to go, and rooms and beds are assigned to named people, the leaflet says the raw data from radar and infrared is not anonymised in the proper sense but pseudonymised. Resolution matters too: under the same conditions a 0.5 megapixel camera captures less than a 10 megapixel one, and the leaflet says this holds for every technology in scope.

Section III.7: the model runs in the room, and cloud needs a case

The AI section opens by conceding the upside. In indirect monitoring, AI pre-processing can reduce the volume of data transmitted out of the room and the amount of information staff actually see. Then it turns to the problems, and the first is location. The verbatim passage, from the second paragraph of III.7 on PDF p. 12: "Der erste Aspekt betrifft den Ort der Datenbearbeitung: Die Bearbeitung der Daten durch die KI muss so weit wie möglich lokal erfolgen, und zwar im Zimmer der betreuten Person. Der Einsatz von Cloud-Lösungen ist heikel: Er birgt nämlich spezifische Risiken im Zusammenhang mit der Zugänglichkeit der Daten (insbesondere für den Cloud-Anbieter)."

Our translation: "The first aspect concerns the place of data processing: the processing of the data by the AI must take place locally as far as possible, namely in the room of the person receiving care. The use of cloud solutions is delicate: it carries specific risks relating to the accessibility of the data (in particular for the cloud provider)." The must here is the leaflet's own word, not ours, and it sits inside a non-binding document.

The next sentence of the non-binding leaflet sets the test for going to the cloud anyway. In our translation: it would therefore have to be demonstrated that on-premise solutions are not an option (complexity, cost, etc.) and that the principles of proportionality, security and privacy by design remain guaranteed. Two things follow from the wording. Complexity and cost are listed as admissible reasons, so the bar is not technical impossibility. And there is no cloud ban: the leaflet asks for a demonstrated case and continued compliance with three named principles. Section III.8 adds that an institution using a service provider's tool or a cloud solution remains fully responsible for the processing, that the provider may process data only as the institution itself may, and that processing abroad can add risk where the processor sits under a legal order without an adequate level of protection.

Training reuse: proportionality first, consent last, and consent with strings

The second half of III.7 addresses a second question, whether monitoring data can be reused to train AI systems. The leaflet lists the added risks: transfer of data outside the actual care context, re-identification, storage and security. It then states that training the models is not directly aimed at the concrete needs of the person in their current situation. Even if the reuse is announced transparently, the non-binding text says, it remains problematic under proportionality insofar as the processing is neither suitable nor necessary for the person's care, and that would make the processing impermissible as long as no justification can be invoked.

The closing lines of III.7 are the ones that matter most in this non-binding text, so here they are in full. In our translation: given the context and the intensity of the processing, it is likely to be difficult to justify this reuse by an overriding interest. That would leave the consent of the person receiving care, with all the limitations mentioned above to be taken into account (see chapter III.2). The phrase we have rendered as "likely to be difficult" is "dürfte es jedoch schwierig sein", which is a hedge, not a prohibition.

The limitations in III.2, again the leaflet's non-binding reading of law already in force, are substantial and they travel with that sentence. For public institutions (footnote 1: classified by mandate, see above), the leaflet states that consent cannot replace the legal basis the legality principle requires, and that public institutions have to fulfil their care mandate regardless of any consent to data processing. For private institutions under the DSG, III.2 says consent has to be voluntary and that the situation can become delicate: the person is often in a vulnerable position, may feel pressure from the institution housing them, and relying on consent is therefore not always appropriate. Persons lacking capacity cannot consent at all, and the leaflet says consent by a representative is a priori unlikely to be available given the intimate character of the processing, unless the measure is a medical intervention. III.2 concludes that neither opt-in nor opt-out is sufficient on its own to justify surveillance, and that an institution has to be able to show an overriding interest, which in care can be the interest of the person being monitored. Read together, III.7 does not say training reuse is consent-only. It says justifying reuse by an overriding interest is likely to be difficult, that consent is what remains, and that consent is hemmed in.

Footnote 6 draws one line the other way. Where algorithms and AI have been trained on raw data obtained abroad, the leaflet says this falls within the manufacturers' responsibility, since the lawfulness of processing under foreign law is hard for Swiss controllers to assess.

The checklist around the model: purpose, defaults, DSFA, documentation

On the leaflet's reading of the purpose principle, which is non-binding guidance on law already in force, III.3 asks the institution to define the purpose before any system is installed, and rules out purely logistical or organisational aims such as checking whether a bed is made or a meal finished. The leaflet also says a purpose has to be pursued for a concrete reason: systematic surveillance introduced without regard to the individual situation of each person is, in its words, not permissible, and the outcome may not be a deterioration in care quality, for instance because staff spend less time in the room. For public institutions the leaflet adds that purposes are limited to what their legal basis covers.

III.4 turns proportionality into settings, and everything in this paragraph is the leaflet's non-binding reading of that principle, not a rule of its own. It says to prefer the indirect solutions from chapter II. Where a product carries functions beyond the use case (zoom, audio, raw-data quality) and a simpler product cannot be chosen, the leaflet says to configure the system so that those additional functions are deactivated by default. It regards retention beyond the duration of technical processing as, as a rule, not justified in care monitoring, and says practicality alone does not justify it. It says monitoring may not be applied systematically to everyone, that each measure is to be justified individually and reassessed regularly, that network exposure is to be limited or avoided, and that access is to be restricted to a defined circle. Its worked example: a room fall detector has to be switchable off from inside the room, in particular when staff or relatives are present, because on the leaflet's view its operation in the presence of others is not justified by its purpose.

III.5 on technology choice contains the hardest line in the document, and it is worth saying before quoting it that this is the leaflet's interpretation of the data security principle in the DSG and the cantonal laws, in a non-binding leaflet, not a freestanding enforceable rule. The section is framed at its start around indirect (situational) digital monitoring, the two-step architecture from chapter II in which raw data is captured only to produce cleaned data, and the raw-data rule belongs to that architecture. On that interpretation, and for that architecture, concrete measures have to exclude access to the raw data, including during maintenance and software updates, with an exception only for technical access by direct physical connection to the sensor to check its function. On our reading the leaflet does not extend this to every form of monitoring: footnote 5 (p. 10) says that optical cameras with real-time transmission may, in certain circumstances, be justified in an intensive care unit where they meet a clearly identified clinical need and the layout makes it impossible for staff to keep the various patients in view, and III.4 reserves special requirements in intensive and acute care from its statement that high-resolution image transmission is not needed for incident alarms. The controller, the leaflet says, has to be able to demonstrate this at any time, on the basis of sufficiently detailed manufacturer descriptions and, where needed, its own documented checks. Otherwise, in the leaflet's words, use of the sensors is to be regarded as impermissible whatever the technology, and the leaflet says a gap here cannot be cured by consent or by overriding private or public interest. Whether a supervisory authority or a court would apply that reading in a given case is not something the leaflet can settle. The same section tells project leads not to rely on marketing materials but to obtain the technical information from the supplier, to assess systemic and specific risks for each alternative, and to verify data protection conformity before purchase, at introduction and on an ongoing basis.

III.9 deals with the impact assessment and splits by sector, with the footnote 1 caveat above on which sector an activity falls in. Under Art. 22 para. 1 DSG, which is in force, private institutions subject to the DSG are required to carry out a DSFA when the processing may entail a high risk to the personality or fundamental rights of the person concerned, and the leaflet says large-scale processing of sensitive personal data can indicate such a risk. For public institutions the duty follows the applicable cantonal provisions, and the leaflet says these differ: some cantons require a DSFA for every newly planned processing, others only where high risk is expected, in line with the federal approach. Art. 23 para. 1 DSG provides for prior consultation of the EDOEB where a high risk remains despite the measures taken; cantonal laws provide their own prior checks with slightly varying conditions. Chapter IV, again as non-binding guidance, says controllers are in every case to make, from the start of the project, a written comparison of alternatives with a data protection risk assessment, kept up during the project and reviewed regularly after go-live, together with technical and organisational measures (encryption, access control, logging). Chapter V is a seven-point checklist that runs from needs assessment through staff training and concrete implementation to a concept for control and reassessment.

What we did not verify

What we opened: the full Merkblatt PDF as served from the federal news file service, extracted to text and read end to end, including the front-page scope statement, chapters I to V, footnotes 1 to 6 and the 16.09.2026 date on p. 15. On 18 September 2026 we downloaded the PDF again from the primary URL (HTTP 200, application/pdf, 489,976 bytes) and confirmed it is byte-identical to the copy we read. We also opened the federal press release of 16 September 2026 (served to us from the EDOEB host at the same path after www.admin.ch refused the fetch) and saved a copy: it carries the date line Bern, 16.09.2026, a title naming EDOEB and privatim as joint publishers, a link to this same PDF, and a link describing privatim as the conference of the Swiss data protection commissioners; the release does not mention artificial intelligence, so nothing in this article rests on it.

What we did not open: the text of the DSG articles the leaflet cites; any cantonal data protection law; any privatim resolution or cantonal adoption decision; French or Italian versions of the leaflet, if any exist; and any product documentation for the monitoring systems the leaflet describes in general terms. Our translations of the German are our own and are labelled as such.

What we refuse to claim: we do not say Switzerland has adopted a new AI law, a cloud ban or an in-room-only rule, because the leaflet is non-binding and describes existing law. We do not say every cantonal data protection authority individually adopted the text, because the publishers named are EDOEB and privatim. We do not say training reuse is lawful with consent or unlawful without it, because III.7 makes consent the remaining route and then imports every limitation in III.2. We do not say every Swiss facility faces the same DSFA trigger, because III.9 says cantonal tests vary. We do not name any vendor, product, penalty, enforcement action, cost or clinical outcome, because the leaflet contains none. Outside the marked III.7 quotation and our translation of it, we do not use the word must in our own voice; the Art. 22 para. 1 DSG duty is stated as "are required to" because that article is in force.

Informational analysis for working professionals, not legal advice. Confirm how any rule applies to your situation with qualified counsel.

Related briefings

• Switzerland: Federal Council mandates FDJP to draft an AI consultation
• Sweden: IMY decision on AI driver-camera surveillance at Securitas
• Europe AI regulation tracker
• AI healthcare compliance tracker
• AI Regulation News hub