Boris Arendt

Leon Neumann

Jakob Riediger

In contrast to the GDPR, the processing of personal data is generally permitted under the FADP. However, this principle is severely restricted, since according to Art. 30 FADP, processing must not constitute an unlawful violation of personality.

A violation of personality rights occurs if the principles of data protection law according to Art. 6 FADP are not observed in the processing, whereby these principles are similar to the principles of GDPR. The violation is unlawful if no exceptional circumstances apply, such as the existence of consent or an overriding interest. As a result, processing operations that are lawful under the GDPR should also be lawful under the new GDPR. 


Basic principles 

Just as the GDPR knows "special categories" of personal data, Art. 5 lit. c FDAP also enshrines  “sensitive" personal data. It should be noted that the definitions are not identical. Thus, in deviation from the GDPR, data on social assistance measures and data on administrative and criminal prosecutions or sanctions are also subject to sensitive data. 

Sensitive data

Locally, the FADP applies to data protection matters that (only) have an effect in Switzerland, i.e. also if they are initiated abroad (Art. 3 (1) FADP). Accordingly, for example, EU companies that process data of Swiss citizens must also comply with the FADP. 

The FADP applies to the processing of data of natural persons. While the old FADP also covered the processing of data of legal persons, an alignment with the GDPR is apparent in this respect. 


Scope of application

Another new aspect is that there are now information obligations towards data subjects from the time the data is collected. In contrast to the previous version of the FADP, these obligations apply regardless of whether the data is sensitive personal data or whether the processor is a federal body. Which information exactly is covered by the information obligations is not conclusively regulated, in contrast to the GDPR. Rather, it is based on the open concept of "necessity". However, Art. 19 FADP contains some minimum information, although this is less extensive than that of the GDPR.

Extension of the information requirements for controllers (Art. 19 FADP)

A fundamental innovation in the FADP is the introduction of a inventory of processing activities. For the first time in Switzerland, it is now necessary to list all data processing activities in an inventory. At the same time, the previous obligation of the owner of data collections to register his collections with the Federal Data Protection and Information Commissioner (FDPIC) no longer applies. The inventory is intended to provide a continuously updated overview of all data processing activities of the respective company. The information that must be included in the directory as a minimum is listed in Art. 12 (2) FADP. However, companies that have fewer than 250 employees and whose data processing activities pose only a low risk to the rights of the data subjects are exempt from the obligation to maintain the directory.

Inventory of processing activities (Art. 12 FADP)

The requirements for processing (on behalf), which is equivalent to processing pursuant to Art. 28 GDPR, are still lower under the FDAP than under the GDPR: A contract for processing is not mandatory, but the controller must ensure in advance that the processor is able to guar-antee data security and that the data is only processed in the form permitted by the controller. Similar to the GDPR, sub-processors may now only be used with the approval of the controller.

Data processing by processors (Art. 9 FADP)

If a data processing operation may involve a high risk to the personality or fundamental rights of data subjects, a data protection impact assessment must be carried out. 
Accordingly, the risks of the processing must be determined and assessed and, if necessary, risk-minimizing countermeasures must be specified, implemented and documented. If the assessment shows that a residual risk remains despite risk-minimizing measures, the FDPIC must be consulted.


Data protection impact assessment and consultation procedure (Art. 22, 23 FADP)

If a decision is based exclusively on automated processing and if this has legal implications for the data subject, the data subject shall be informed of this by the controller. In addition, the person may request that the decision be reviewed by a natural person. 

Consent for the processing of personal data is still not required for profiling, unless a high risk is assigned to the type of profiling. 


Automated decision making and profiling

The data subject rights of the FADP are the same as those of the GDPR. Therefore, there is a right to information, correction and deletion, rights of objection as well as a right to data disclosure and transfer. The scope of information will possibly be greater than that enshrined in the GDPR, in that data subjects should receive the information required under the GDPR to assert their rights and to ensure transparent data processing. What information may be necessary to establish transparency is nevertheless not explicitly regulated.

Data subject rights

Data security breaches must be reported to the FDPIC as soon as possible. Under certain circumstances, there is also a duty to inform the data subject. To ensure this, controllers must establish functioning processes within the company. If a data protection incident appears possible, there are duties to investigate, inform and mitigate damages. In contrast to the GDPR, however, no strict (72-hour) deadline applies. Rather, the law speaks of notification "as soon as possible". Also in contrast to the GDPR, notification is only required in the event of an identified high risk to the personality or fundamental rights of the data subject.

Obligation to report breaches of data security (Art. 24 FADP)

Similar to the GDPR, the principles of "privacy by design" and "privacy by default" are enshrined in law for the first time. Accordingly, data processing must be designed in such a way that data protection principles are observed, and default settings must be made that limit data processing to the extent necessary to fulfill the purpose of the data processing.

In addition, controllers and processors must implement suitable technical and organizational measures for the purpose of data security, whereby the measures are specified in Art. 3 FADP and are aligned overall with the GDPR.


Privacy by design / default and data security

Foreign companies that have customers in Switzerland or monitor Swiss users must appoint a representative in Switzerland if they carry out extensive and regular operations with a high risk for the data subjects. How far this obligation will extend remains to be seen in the wake of the open wording of Art. 14 FDAP. However, based on the character of an exception, a restrictive interpretation seems preferable, so that the appointment of a representative will only be necessary in exceptional cases. 

Appointment of a representative in Switzerland (Art. 14 FADP)

Transfers abroad ("Cross-Border Disclosure of Personal Data") are possible if the Federal Council has determined that the recipient country has an adequate level of protection. If this is not the case, standard data protection clauses or own contractual clauses previously approved by the FDPIC, specific guarantees or Binding Corporate Rules can be used. SCCs are available [here](https://www.edoeb.admin.ch/edoeb/de/home/deredoeb/infothek/infothek-ds.html).

Data transfers abroad (Art. 16-18 FDAP)

The sanctions are not linked to the responsible company as in the GDPR, but to the responsible natural person. Fines of up to CHF 250,000 can be imposed. 

Sanctions

Finally, there is the possibility (not the obligation) to appoint a data protection advisor whose role is similar to that of the data protection officer within the meaning of the GDPR. The appointment facilitates high-risk data processing: instead of the FDPIC, the data protection advisor can be consulted and appropriate measures to compensate for the high risks can be requested with him/her.

Data Protection Advisor

In summary, Switzerland's new data protection law enshrines largely parallel, in some places more lenient requirements for the handling of personal data compared to the GDPR. In principle, it can therefore be assumed that companies that comply with the GDPR will also be able to meet the requirements of the FDPA. Nevertheless, it is necessary to address the special features of the GDPR in some places and to review any need for implementation in this regard. 

Summary

New Swiss Data Protection Act: Changes under the new FADP

neues Schweizer Datenschutzgesetz dsg

Steffen Groß


###### Introduction of Executive Order 14086 - Emphasis on the Principle of Proportionality


In the Schrems II decision, criticism focused in particular on the far-reaching access powers of U.S. intelligence agencies to personal data of non-U.S. citizens under Sec. 702 FISA. This regulation enabled mass surveillance of foreign citizens, which was judged disproportionate by the ECJ. In order to ensure the principle of proportionality pursuant to Art. 52 CFR, the access rights of the U.S. intelligence services will henceforth be more restricted and limited to a necessary level by the "[Executive Order on Enhancing Safeguards for United States Signals Intelligence Activities](https://www.whitehouse.gov/briefing-room/presidential-actions/2022/10/07/executive-order-on-enhancing-safeguards-for-united-states-signals-intelligence-activities/)" ("EO-14086") of October 7, 2022.

###### Reorganization of the legal protection mechanism

Another major criticism of the former Privacy Shield was the ombudsman mechanism. The ECJ ruled that it did not offer sufficient legal protection. In particular, it criticized the lack of independence and the inability to issue binding regulations against intelligence services. In response, a special data protection court, the Data Protection Review Court, was established. This court is intended to give EU citizens the opportunity to take action against potential data protection violations. However, since it is subordinate to the U.S. Department of Justice, there are concerns about its actual independence and whether it meets the requirements under Art. 47 CFR.


Core changes to U.S. surveillance law

Already during the development phase of the amended U.S. surveillance law, critical voices were raised from various corners. With the adoption of the new adequacy decision, data privacy activist Max Schrems in particular came forward and voiced his concerns. [His comment sums it up](https://noyb.eu/de/european-commission-gives-eu-us-data-transfers-third-round-cjeu): 
> "People often define insanity as doing the same thing over and over again, but expecting a different result. Just like with the 'Privacy Shield,' the current agreement is not based on real change, but merely on short-term political considerations."


A major point of criticism by many experts and data protectionists lies in the fact that Sec. 702 FISA, which enables mass surveillance, has remained unchanged in its core structure. The data protection organization NOYB, for example, assumes that the problems associated with Sec. 702 FISA will continue to exist even after EO-14086 is implemented. A key factor here is the different interpretation and application of the principle of "proportionality" in the U.S. compared to the EU.

Against this background, it seems likely that the ECJ will re-examine the regulations in the near future.

Criticism of the innovations: Renewed rejection by ECJ to be feared?

As a result of the revised legal framework, the transfer of personal data to the U.S. is now considered secure, provided it is directed to an appropriately certified company.

This means maintaining the principle of self-certification. Companies wishing to participate in the Framework must commit to complying with a defined set of data privacy principles and standards. These criteria have been defined by the US Department of Commerce.

The obligations include, among other things, that the companies submit to the investigative and enforcement powers of both the Federal Trade Commission (FTC) and the U.S. Department of Transportation (DoT). It is also required to implement a privacy policy that conforms to the principles set forth in Annex 1 of the Adequacy Decision. The Department of Commerce regularly monitors compliance with these provisions (compliance monitoring). In the event of repeated violations, there is a risk not only of civil sanctions, but also of exclusion from the Privacy Framework.


Maintenance of the self-certification principle

Companies that were already certified under the Privacy Shield do not need to recertify themselves to participate in the DPF.

According to a [notice from the International Trade Administration](https://www.dataprivacyframework.gov/s/article/FAQs-EU-U-S-Data-Privacy-Framework-EU-U-S-DPF-dpf) (ITA), these companies' participation in the DPF will automatically continue. However, they must update their privacy policies to comply with the DPF's amended principles by October 10, 2023.

These companies must renew their certification annually in accordance with DPF regulations, as of their current recertification date. Companies that were certified under the Privacy Shield but do not wish to participate in the DPF must formally opt out in accordance with the ITA withdrawal procedure. 

It is important to note that failure to complete the annual recertification process does not terminate the Company's participation or obligations. Even after completing the formal withdrawal process, the Company must continue to comply with the applicable Privacy Shield/DPF Principles with respect to personal data received under these programs.

Companies not already certified under the Privacy Shield can begin the DPF self-certification process as of July 17, 2023, as indicated on the official DPF website ([http://www.dataprivacyframework.gov/](http://www.dataprivacyframework.gov/)). It should be noted that companies must comply with the DPF requirements before submitting their self-certification.

Does the Privacy Shield certification also apply to the new Data Privacy Framework?

Despite the prevailing criticism, the newly adopted Privacy Framework lets many companies breathe a sigh of relief for the time being. Because when data is transferred to a certified company, this can now happen WITHOUT the use of special third-party SCCs, without TIA and without additional measures. This means that extensive audits are no longer necessary for the time being.
In view of the profound criticism, however, we recommend that existing SCCs be retained and not dissolved. A renewed legal review of the adequacy decision by the ECJ seems to be only a matter of time, and its outcome remains uncertain. It is important to note that SCCs and TIAs remain required for data transfers to U.S. companies that are not certified, as well as for transfers to other third countries.

How to deal with the new adequacy decision?


###### Scenario 1: data transfer between two EU companies

**Question:**
Are SCCs and a TIA required in this context?

**Answer:**
No - for data transfers within the EU, Articles 44 et seq. GDPR are not applicable. Therefore, there is no need for SCCs or a TIA. A classic order processing agreement pursuant to Art. 28 (3) GDPR is sufficient - even if the data transfer is to a European subsidiary of a US group.

**Justification:**
The GDPR applies in all EU Member States, ensuring a uniformly high level of data protection throughout the EU. Companies located in the EU are therefore obliged to comply with the GDPR. Therefore, SCCs and a TIA are not necessary in this context.

###### Scenario 2: data transfer from an EU company to a certified US company

**Question:**
Are SCCs and a TIA required in this context?

**Answer:**
While the use of SCCs is not mandatory, we still recommend their use. A TIA, on the other hand, is not required.

**Justification:**
According to the EU Commission's adequacy decision, an adequate level of data protection now applies to certified companies in the USA, making a TIA unnecessary. However, as the validity of this decision will be reviewed by the ECJ in the near future, there is some legal uncertainty. We therefore advise continuing to integrate SCCs in the order processing contract as a safeguard.

###### Scenario 3: Data transfer from an EU company to a non-certified US company

**Question:**
Are SCCs and a TIA required in this context?

**Answer:**
Yes, both SCCs and a TIA are mandatory in this case.
Substantiation: The adequacy decision only facilitates data transfers to certified companies in the USA. For non-certified companies, the previous handling of data transfers remains unchanged.

###### Scenario 4: Existing order processing contract with a US company

An order processing agreement including SCCs has already been signed and a TIA has already been carried out.

**Question:**
Do additional steps need to be taken to ensure the legality of the data transfer?

**Answer:**
No, the data transfer on the basis of the existing contract is still legally compliant. No further steps are required.

**Justification:**
The data transfer is still based on the legal basis of Art. 28 GDPR. Through the integration of SCCs and the implementation of a TIA, the requirements of Art. 44 et seq. GDPR are complied with. In view of potential uncertainties regarding the future existence of the adequacy decision, it would be advisable not to make any hasty decisions regarding the discarding of these measures.


Practical application examples for companies

Data transfers to the USA under the EU-US Data Privacy Framework

Data transfers to the USA with EU-US. Data Privacy Framework

The development of an AI model requires the training of the model with large amounts of data. Due to the volume of data required for training, it often cannot be ruled out that the training data may include personal data.

Insofar as this involves data of persons located in the European Union, the provisions of the GDPR must therefore be taken into account in the context of the training of AI models. By classifying the training as processing according to Art. 4 No. 2 DSGVO, a legal basis according to Art. 6 DSGVO is required.

AI Training = processing activity

The provisions of the GDPR do not apply to anonymized data. These data no longer have any personal reference and can therefore be processed without having to observe the restrictions of the GDPR. Anonymization of data (e.g., of inventory data in the run-up to the training) could consequently eliminate data protection concerns.

In implementation, however, anonymization often fails due to practical considerations. On the one hand, it involves a considerable technical effort that cannot be afforded by most of the responsible companies.

On the other hand, the anonymization of training data results in a significant loss of quality, which indirectly leads to a loss of accuracy of the AI model. Furthermore, depending on the application scenario of an AI model, it is not always possible to rely exclusively on anonymous data. [1] An example of this is the development of facial recognition software that is to be trained on "real" faces to be useful as an AI model for this particular application.


Anonymization of training data as a solution?

To be able to use a sufficient and qualitative amount of data, the training of AI models often relies on inventory data of the company, such as customer data. These were regularly collected not for the development of an AI, but for the respective business purposes of the company (e.g., delivery of goods or provision of services).

If this data is now to be used for a different purpose - namely the development of an AI - the requirements of the change of purpose according to Art. 6 (4) must be observed. First, data controllers must inform the data subjects about the further processing that will then take place, Art. 13 (3), Art. 14 (4) GDPR.

In addition, the five criteria mentioned for a change of purpose in Article 6 (4) of the GDPR must be considered. This is checked as part of a so-called "compatibility test"[2], unless this is already dispensable (see below):


Prerequisites for change of purpose

In certain constellations, the performance of a compatibility test pursuant to Art. 6 (4) DSGVO may be dispensable. According to Art. 5 (1) (b) of the GDPR, this is the case for "further processing for archiving purposes in the public interest, for scientific or historical research purposes, or for statistical purposes". Thus, at the first level, a consideration of the purpose to be pursued by the AI model to be trained is required.

On the one hand, statistical purposes come into consideration here. Specifically, these may be relevant if the model to be trained "is deemed anonymous within the meaning of the GDPR due to appropriate (...) measures and is not used for measures or decisions regarding individual natural persons." [3]

Statistical purposes consequently come into consideration when processes are "generally improved, anomalies or system impairments are detected, or new data is generated, such as with chatbots," by means of AI.[4]


Dispensability of a compatibility test

Article 6 (4) (e) of the GDPR requires "the existence of appropriate safeguards, which may include encryption or pseudonymization" in the context of the compatibility test. 

This makes it clear that the implementation of privacy-enhancing technologies ("PET measures") is a central component of the successful implementation of a compatibility test. This allows the controller to justify the data protection compliance, especially vis-à-vis supervisory authorities.

In addition, early implementation of PET measures is required to avoid "infecting" the AI model. [7]

PET measures that may be considered include, but are not limited to:

- Anonymization or pseudonymization of training data

- Use of synthetic training data

- "Federated Learning" methods[8]

Implementation of Privacy Enhancing Technologies

The performance of a compatibility test always requires a case-by-case examination. The following factors in particular must be taken into account:

###### Purpose context

The link between the original and new processing purposes: the closer the link, the more likely the compatibility.

###### Type of personal data

Sensitive data or data requiring special protection could have higher compatibility requirements.

###### Consequences for those affected

The possible consequences of further processing for the data subjects: Negative effects on the privacy of the data subjects may affect the compatibility of the purposes.

###### Protective measures

The existence of appropriate safeguards: The implementation of safeguards (PET measures) such as pseudonymization or anonymization can support the compatibility of the processing purposes.

Carrying out the compability test

Companies that want to train an AI model must comply with data protection regulations. 

If the training is carried out with existing data, a compatibility test must be carried out. To be successful here, the company must implement data protection-friendly measures (privacy-enhancing technologies).

In addition to the requirements of the GDPR, companies will also have to comply with the provisions of the AI Regulation in the future. In particular, Article 10 of the AI Regulation sets out requirements for the quality of training data.

Outlook and conclusion

[1] Cf. Leicht/Sorge, Einsatz von KI-Systemen im Unternehmen: Datenschutzrechtliche Voraussetzungen und technische Lösungsansätze, in: Roth/Corsten, Handbuch Digitalisierung (forthcoming), including a reference to the exemplary presentation of this problem in the use of differential privacy: Bagdasarayan, et. al, Differential privacy has disparate impact on model accuracy, Advances in Neural Information Processing Systems 32 (2019): 15479-15488.

[2] Buchner/Petri, in: Kühling/Buchner DSGVO, 3rd ed. 2020, Art. 6, para. 186.

[3] Kaulartz, Rechtshandbuch Artificial Intelligence and Machine Learning, 1st edition p. 476.

[4] Kaulartz, Rechtshandbuch Artificial Intelligence and Machine Learning, 1st edition 2020, p. 476.

[5] Stefan Brink, former data protection commissioner of Baden-Württemberg, ChatGPT ban: This is what Italy demands from OpenAI - Overview! | SÜDKURIER (suedkurier.de). 

[6] Leffer/Leicht, Data Protection Challenges in the Use of Training Data for AI Systems, *34_p_28_IRIS22_Leffer+ES.indd (uni-saarland.de).

[7] Cf. Kaulartz, Legal Handbook Artificial Intelligence and Machine Learning, p. 476.

[8] [https://www.bigdata-insider.de/wie-entwickelt-man-dsgvo-konforme-Modelle-kuenstlicher-intelligenz-a-aefe48c90aa8e08bc579a3f3f43b183d/](https://www.bigdata-insider.de/wie-entwickelt-man-dsgvo-konforme-Modelle-kuenstlicher-intelligenz-a-aefe48c90aa8e08bc579a3f3f43b183d/); [https://www.cmshs-bloggt.de/tmc/machine-learning-datenschutz-compliance-bei-ki-am-beispiel-federated-learning/](https://www.cmshs-bloggt.de/tmc/machine-learning-datenschutz-compliance-bei-ki-am-beispiel-federated-learning/).

Sources

Privacy-compliant training of AI models

Datenschutzkonformes Training von KI-Modellen

Artificial intelligence is increasingly finding its way into our everyday lives. Its use can optimize decision-making processes and work procedures in many areas of life and enables approaches to solutions that would have been almost inconceivable before. However, the rapid technical development and the steadily increasing use of AI are also revealing more and more risks, which can be relevant to fundamental rights, associated with the use of artificial intelligence.

These become particularly apparent when AI is used in the context of facial recognition, surveillance, and health technologies. In recent weeks, however, debates and media reports have focused primarily on the chatbot "ChatGPT" developed by California-based OpenAI.

These examples give an idea of the overall societal consequences that artificial intelligence can have if it is used by large numbers of the population. The more AI gains authority and influence, the greater the risk that it will be instrumentalized for harmful purposes, such as influence public opinion and democratic discourse. This is not the only reason why it is necessary to regulate the use of artificial intelligence.

This is also the opinion of Sam Altmann, one of the founders of OpenAI:

> "we definitely need more regulation on ai"
> (Twitter, 13.03.2023)

Introduction

The EU Commission became aware of the risks of AI several years ago, and in 2018 developed a strategy to regulate and at the same time promote the development of artificial intelligence. Specifically, a proposal for the Artificial Intelligence Act ("AI Act") was submitted in spring 2021. The aim of the draft, in addition to promoting the development of AI, is to ensure adequate protection of fundamental rights by creating a legal framework and to create a basis of trust when dealing with artificial intelligence.

In response to the AI hype triggered by ChatGPT and the associated risks, amendments to the Commission proposal were introduced by the parliamentary committees of the European Parliament on May 11, 2023. This was preceded, among other things, by negotiations on stricter requirements for generative general-purpose AI, so that fundamental rights, including freedom of expression, must be taken into account in its development. In addition, further obligations and transparency requirements for providers of so-called foundation models such as ChatGPT were included. In addition, general principles such as technical security, transparency and data governance are to apply to all AI systems, but without developing new requirements. Rather, the principles are to be included in future technical standards and guidance documents.

In addition to the AI Regulation, a Commission proposal for a directive on AI liability has been on the table since fall 2022, which is intended to make it easier for injured parties of AI systems to file lawsuits. 

Efforts are also underway in the U.S. to create specific regulations for artificial intelligence. For example, proposals for an "AI Risk Management Framework" and an "AI Bill of Rights" were presented in 2022. In contrast to the European approach, however, these merely serve as non-binding guidelines and thus rely in principle on the voluntary implementation of the specifications by the addressees.


Current status of regulatory development

The AI Act follows a risk-based approach, according to which AI systems are divided into four different risk groups based on their field of application and purpose. Accordingly, there are AI systems with unacceptable, high, limited and minimal risk. On the one hand, the regulation addresses providers of AI systems, if they place the system on the market or put it into operation in the EU, and on the other hand, their users, unless the use is solely for private purposes.

As the legislator assumes, the majority of all AI systems pose a minimal risk. For such systems, which include spam filters, for example, the regulation does not contain any specific requirements.

In contrast, AI systems with unacceptable risk are prohibited under Art. 5 AI Regulation. These include only a few groups of cases, such as the social scoring system (based on the Chinese model) or - with a few exceptions - biometric real-time remote identification systems in public spaces for law enforcement purposes.

###### Transparency requirements

The regulation imposes certain transparency requirements on certain AI systems with particular risks of manipulation - regardless of whether the system is classified as high-risk. These now also include so-called generative foundation models such as GPT, which is why ChatGPT or Replika are likely to fall into this group. To meet the requirements, it is necessary to make it transparent to the users of such a system that they are interacting with an AI, unless this is obvious from the circumstances. In addition, there will be a registration requirement in an EU database for providers of such models. Whether this will adequately address the risks associated with chatbots remains to be seen. However, the transparency obligations can at least ensure that the risk of so-called "deep fakes" is reduced.

###### High-risk systems

The core of the regulation is the governance of high-risk systems. This group includes, on the one hand, AI systems that are used as security components in products and, on the other hand, AI-based applications with particular relevance to fundamental rights, such as those in the area of human resources management, in education and training, or in critical infrastructure. High-risk systems, as well as their operators and users, are subject to specific requirements that must be met when using the system in the EU. Some of these requirements are outlined below.

###### Risk management system

First, the AI system must be accompanied by a documented risk management system that reduces the risk of the AI system to an acceptable level through concrete, state-of-the-art measures. The risk management system is designed as an iterative process and must be updated regularly, whereby the actual and potential risks of the AI system must be continuously identified and weighed. “Appropriate" measures must then be taken to counter the risks identified in this way.

In addition, there are individual documentation and information obligations. Article 13 I AI Act (draft) stipulates, for example, that systems must be designed and developed in such a way that their operation is sufficiently transparent to enable users to interpret and use the results appropriately, without, however, specifying concrete measures by which this objective can be achieved.


###### Working with the data sets/data protection

Of particular relevance from a data protection perspective is Art. 10 AI Act (draft), which sets requirements for handling the datasets with which the AI is trained. If a high-risk system is trained with data, training, validation and test data sets must be used that must meet certain quality requirements. The datasets are subject to certain management practices according to Art. 10 II AI Act (draft), for example with regard to the collection, evaluation and preparation of data or with regard to any data deficiencies. In addition, according to Art. 10 III 1 AI Act (draft), the data sets must be relevant, representative, error-free and complete. In practice, however, it will be difficult to determine when a dataset is free of errors, as objective quality standards are still lacking.

Article 10 V AI Act (draft) contains a legal basis for the processing of special categories of personal data within the meaning of Article 9 I GDPR, if the processing is strictly necessary for the identification and correction of bias and appropriate safeguards are taken for the fundamental rights and freedoms of the data subjects. A further condition is that the purpose pursued would be significantly impaired by prior anonymization. 

At this point, the provision makes use of the general clause from Art. 9 II lit. g GDPR, since the prevention of bias ("distortions") is likely to be considered a public interest, whereby the question arises as to its relevance. However, it remains open when the processing of personal data under Article 10 V AI Act (draft) is strictly necessary and when the purpose would be "significantly impaired" by anonymizing the data.

###### Post-Market-Monitoring

Furthermore, according to Art. 61 AI Act (draft), the provider is obliged to carry out "post-market monitoring", which serves to collect user data actively and systematically. The data collected in this way is then to be merged in the system with user data from other sources, enabling the provider to continuously monitor user compliance with the regulation. In the event of serious incidents and malfunctions of the system, there is a reporting obligation pursuant to Art. 62 AI Act (draft). According to Art. 61 III AI Act (draft), the post-market monitoring must be based on a plan, which is part of the technical documentation according to Annex IV No. 8 AI Act.

###### Sanctions

Violations of the Regulation are to be sanctioned by the Member States with fines in accordance with Art. 71 AI Act (draft). The highest penalties are to be expected for violations of Art. 5 AI Act (systems with unacceptable risk) or Art. 10 AI Act (handling of data), namely in the amount of up to EUR 30 million or 6% of the worldwide annual turnover if the violator is a company.












Artificial Intelligence Act (AI Act)

The AI Liability Directive applies to non-contractual, fault-based, civil damages claims relating to harm caused by AI systems.

One of the key provisions of the Directive is the right to demand a court order to for disclosure of information as potential evidence in the event of damage caused by high-risk systems in accordance with Art. 3 AI liability directive. 

The disclosure obligation is limited to a necessary and proportionate extent, whereby the protection of business secrets must be observed. In addition, Art. 4 of the AI Liability Directive contains a rebuttable presumption of causality between fault and the result produced by an AI system or the lack thereof.

Overall, the directive thus takes into account the "black box" problem, i.e. the fact that the decision-making process of an AI cannot regularly be traced and that injured parties therefore have difficulty in proving the facts they have to present in court.

Directive for AI Liability

The AI Regulation will not be the sole piece of legislation dealing with artificial intelligence. Since AI-based applications often process personal data, the AI Regulation is also flanked by the provisions of the GDPR in such cases. Here, the principles of data processing, such as data minimization, purpose limitation and transparency, are primarily relevant. In addition, the AI's recourse to certain data may result in violations of any copyrights or personal rights. In addition, labor and IT law, as well as the protection of trade secrets, must be observed by the operators and users of AI, so that there is a wide range of regulations that put a stop to the excessive use of artificial intelligence.

Further regulations

With the vote for the AI Act, the parliamentary committees of the EU Parliament on 11.05.2023 have paved the way for adoption in plenary in mid-June. After that, the final phase of the legislative process will begin and negotiations with the EU Council and the Commission (trilogy) will be initiated.

When implementing the regulation, further problems may arise. For example, the requirements placed on high-risk systems must be reconciled with data protection principles. Futhermore, the obligation to log processes during the operation of an AI system under Article 12 of the AI Act conflicts with the principle of data minimization, which is why it will be challenging to implement the requirement in a way that complies with data protection law. 

Overall, the Regulation imposes a not inconsiderable burden on providers, users and operators of AI systems. In order to make it easier for them to comply with the regulations, the "European Committee on Artificial Intelligence" described in Art. 56 of the AI Act could be of help, which is to develop opinions, recommendations and guidelines. 

Outlook

Current developments in AI regulation

In connection with this, today, May 4, 2023, the European Court of Justice issued a judgment on the right to non-material damages under Article 82 of the GDPR.

*Breach of the GDPR does not automatically lead to a claim for damages:*

The ECJ ruled that a breach of the GDPR alone does not give rise to a claim for damages by data subjects. Rather, proof of concrete damage is required.

Accordingly, for a claim for damages
1) a breach of the GDPR  
2) **AND** proof of damage causally caused by the breach is required.

*No de minimis limit for damages:*

The ECJ ruled that no de minimis limit applies to a claim for damages. Some national courts had ruled that the damage had to exceed a certain materiality threshold to give rise to a claim for damages. The ECJ has hereby countered this.


ECJ ruling:

The ECJ's case law provides a clearer definition of the right to damages under data protection law. However, many legal questions have not yet been clarified. 

For companies, there is a non-negligible risk of being exposed to mass lawsuits by consumers and consumer protection associations in the event of data privacy violations. 

Data protection supervision, which has been dysfunctional to a large extent to date, could also be overtaken by the fact that those affected now pursue data protection violations independently or via legal tech platforms because of financial incentives.

The developments about immaterial damages are therefore not a legal glass bead game but will have very concrete economic effects on companies. 

Companies in the consumer sector should address these risks, which can result from data privacy violations, at an early stage.


Relevance and evaluation:

Mere infringement of the GDPR does not result in a claim for damages

The use of emotion recognition AI software is prohibited in law enforcement, border control, workplace, and education. The ban on biometric identification software has also been expanded.

The possibility of using AI for purposes of preventive policing ("predictive policing") is also to be restricted. The AI regulation bans "purposeful" manipulation, which was maintained despite debates over proving intentionality. 

Ban on emotion recognition, biometric identification and predictive policing

The AI Act's high-risk classification will only apply to AI models that pose a significant risk of harm to health, safety, or fundamental rights. This includes AI used to manage critical infrastructure with a severe environmental risk. The severity, intensity, probability of occurrence, and duration of effects will be taken into account to determine if the risk is significant.

High-risk AI classification criteria defined

The European Parliament has included additional safeguards to detect negative biases while processing sensitive data such as sexual orientation or religious beliefs for high-risk AI models. Processing such data must happen in a controlled environment and the bias must not be detectable by processing synthetic, anonymized, pseudonymized or encrypted data. The sensitive data cannot be transmitted to other parties and must be deleted following the bias assessment, and the providers must document why the data processing took place.

Safeguards for detecting biases in processing sensitive data for high-risk AI models

The members of the European Parliament proposed general principles that would apply to all AI models, including human agency and oversight, technical robustness and safety, privacy and data governance, transparency, social and environmental well-being, diversity, non-discrimination, and fairness. 

High-risk AI systems will also have to keep records of their environmental impact and comply with European environmental standards. These principles are not meant to create new obligations but will be incorporated into technical standards and guidance documents.



Source: [https://www.euractiv.com/section/artificial-intelligence/news/meps-seal-the-deal-on-artificial-intelligence-act/]((https://www.euractiv.com/section/artificial-intelligence/news/meps-seal-the-deal-on-artificial-intelligence-act/))


General principles for all AI models

Preliminary agreement on European “Artificial Intelligence Act” reached

Before we can address the question of whether ChatGPT is "GDPR-compliant", we must first define the parameters of the assessment.

![Overview ChatGPT GDPR-compliance](https://a.storyblok.com/f/183108/2460x1770/75d0968ec3/chatgpt-gdpr-compliance-en-simpliant-insights.jpg "When assessing the GDPR-compliance of XY, it is important to first define the assessment object. This can be an (1) organization, (2) a product, (3) the usage of this product.")

This is important because not only companies (OpenAI LLC) and the products of companies (development of ChatGPT and creation of the Large Language Model ("LLM")), but also the use of these very products by third parties (use of ChatGPT by companies) can be data protection compliant or non-compliant.

The following article examines the **third option**, i.e. the question of how the service can be used in a privacy-compliant manner (privacy compliance regarding the use of ChatGPT).

To answer the question of whether and how the service can be used in a GDPR-compliant manner, a distinction must be made between different usage scenarios. For this purpose, we have formed several short use cases.

What are we looking at when assessing GDPR-compliance?

###### Use case:
A user wants to enrich or organize his personal contact list, which has been maintained in a spreadsheet, by using ChatGPT.

###### Question:
Does using ChatGPT for personal purposes while entering personal data in a prompt violate the GDPR?

###### Answer:
No, such use does not violate the GDPR, as the latter does not apply to data processing for purely personal purposes.

###### Justification:
**Personal use - GDPR not applicable**

To the extent that processing (including personal data) is carried out exclusively for personal or household activities, this is outside the scope of the GDPR (Art. 2(2)(c) GDPR). According to Recital 18 of the GDPR, personal or household activities are at hand "when processing is carried out without (any) relation to a professional or economic activity." Typically, private purposes include processing data for own leisure time activities, entertainment, and hobbies.

**Business or mixed personal-business use - GDPR applicable**

In contrast, processing activities would be considered non-personal if they are performed in the context of economic activity, regardless of whether there is monetary compensation. This includes advertising measures, the exchange of data for services, but also preparatory activities, e.g. the creation of a first draft of a text to be used in a professional context.

In the case of mixed personal and business use, the GDPR is still applicable, even if personal use predominates since the exceptions to the scope of application of the GDPR are generally to be interpreted narrowly.

Use of ChatGPT for (exclusively) personal purposes (Case study 1)

###### Use case:
The company X-Inc. would like to use ChatGPT to edit its customer lists, including address data. The customer data is to be entered via input ("prompt") into the web interface.

###### Question:
Does this mean that Company X-Inc. is in breach of the GDPR?

###### Answer:
Yes - Company X-Inc. is in breach of the GDPR as it transfers personal data to a third-party recipient (OpenAI LLC) without a legal basis.

###### Justification:
As economic purposes are pursued with the use of the service, the processing occurs for business use. Since the personal data (customer data) is forwarded to a third-party recipient, this constitutes a processing of personal data within the scope of the GDPR.

The transfer requires a legal basis. In most cases, companies will not have obtained consent from customers to transfer data to OpenAI. Therefore, consent will, in most cases, not be a viable legal basis.

Justifying legitimate interest is also likely to be difficult, as the risks for data subjects regarding data processing by OpenAI are often difficult to assess. However, exceptions could arise if, for example, protective measures such as pseudonymization are taken and risks for data subjects can be excluded with sufficient certainty.

Since consent or legitimate interest is only likely to exist in special cases, only processing on behalf (Art. 28 GDPR) could be considered as a legitimization of the transfer. 

However, a data processing agreement is not provided by OpenAI for this use.

Regarding data protection, OpenAI states in its Terms of Use (as of 03/14/2023):
> "5. confidentiality, security and data protection
(c) (...) If you use the OpenAI API for the processing of "personal data" as defined in the GDPR (...), please fill out this [form](https://ironcladapp.com/public-launch/63ffefa2bed6885f4536d0fe) to request the execution of our data processing addendum."

The linked form leads to a subpage labeled "[Sales] Data Processing Addendum External", where one can electronically enter into a data processing agreement pursuant to Art. 28 GDPR with OpenAI LLC (this refers to the EU Standard Contractual Clauses).

However, the interesting information is located in the text description under the heading:
> "Note that this agreement is only applicable to our business service offerings (APIs for text completion, images, embeddings, moderations, etc.) and NOT our consumer services (ChatGPT, DALL-E Labs)."

OpenAI LLC makes the statement here that the provided data processing agreement should only apply to their "Business Service Offerings" (i.e. the API users), but this explicitly does not include ChatGPT (web interface).

Consequently, OpenAI does not provide a data processing agreement for the use of the ChatGPT web console. This is only provided for API-using business customers.

Although OpenAI does not prohibit the business use of the service in its TOS, it nevertheless sees ChatGPT - at least implicitly - as a consumer service, as can be derived from the description of the "[Sales] Data Processing Addendum External".

In the absence of a data processing agreement for the use of the web interface, a data transfer based on Art. 28 GDPR cannot be considered.

Accordingly, companies will generally not be permitted under the GDPR to transmit personal data to OpenAI through prompts in the web interface of ChatGPT.

Business use of ChatGPT Web interface (Case study 2)

###### Use case:
A company wants to make its customer support more effective. It creates an own customer chat interface on the website that accesses both the customer's order history in an internal database and the ChatGPT API (“API”) to generate suitable answers for customer queries. For this purpose, the customer data is transferred to OpenAI via the API.

###### Question:
Is the described integration of the API and the transfer of customer data to ChatGPT permissible under the GDPR?

###### Answer:
Yes, the transfer of customer data can be based on Art. 28 GDPR in conjunction with concluded data processing agreement. However, since a data transfer to the USA takes place, a so-called Transfer Impact Assessment must also be carried out. If the result of this assessment is positive, the customer data may be transferred to OpenAI.

###### Justification:
In contrast to the users of the web interface, API users can conclude a data processing agreement with OpenAI. Provided it is effective, data can therefore be transferred to OpenAI on this basis even without the consent or legitimate interest.

However, it must be considered that processing on behalf requires data to be processed exclusively on the instructions of and for the purposes of the controller.

According to the Terms of Use, it can be assumed that the data is processed exclusively for purpose of the controller, which would speak for processing on behalf:
> "3. content (c)
c) Use of Content to Improve the Services. We do not use content that you provide to or receive from our API ("API Content") to develop or improve our Services. We may use content from services other than our API ("Non-API Content") to develop and improve our Services."

Supplemental requirement - Transfer Impact Assessment (data transfer to the U.S.):

However, in addition to the conclusion of the data processing agreement, the company must carry out a so-called Transfer Impact Assessment ("TIA").

A TIA is used to assess risks posed by the transfer of data to a third country, which is not deemed to have an adequate level of data protection (i.e. the USA). Only if the result of this risk assessment is positive, i.e., it can be justified that there are no substantial data protection risks for data subjects, the data transfer permissible under data protection law.

Business use of the ChatGPT API (Case study 3)

###### No entry of personal data in the web interface
In the absence of a data processing agreement, no transfer of personal data may take place using the ChatGPT web interface for business purposes.

Such use may exceptionally be legitimized if there is consent by the data subject (Art. 6 para. 1 a) GDPR) or if there is a legitimate interest pursuant to (Art. 6 para. 1 f) GDPR).

Insofar as companies use the web interface, they should ensure that no personal data (e.g. customer data or employee data) is transmitted to OpenAI via a prompt. 

###### No entry of trade secrets (Trade Secrets Act)
It should also be prohibited that data subject to the Trade Secrets Act is entered into ChatGPT's web console, regardless of whether such data is personally identifiable.

This applies to technical data and software code, as well as to all data that has an economic value and must be handled confidentially. As far as this is not prevented, a scenario like [Samsung's recently reported incident is looming](https://www.financialexpress.com/life/technology-samsungs-trade-secrets-have-reportedly-leaked-because-employees-shared-a-bit-too-much-info-with-chatgpt-3038108/).

######  "ChatGPT Acceptable Use Policy"
Insofar as the use of the service is permitted, the company bears responsibility for data protection compliance concerning ChatGPT.

Therefore, companies should generally prohibit the entry of personal data. This can be done, for example, through an "Acceptable Use Policy".

If a company does not take internal precautions to prevent personal data from being entered in violation of data protection laws, the data protection violation is generally attributed to the company and can lead to fines and claims for damages by data subjects.

You will find a free sample of an acceptable use policy below that you can adapt to your organization’s requirements and use freely.

######  Further measures required for API integration
If the processing of personal data is to take place via API integration, the following additional measures must be taken:
-	Conclusion of OpenAI’s data processing agreement (Art. 28 GDPR)
-	Conducting a transfer impact assessment (Art. 44 ff. GDPR and requirements of the ECJ in the "Schrems II ruling")
-	Information about data processing by ChatGPT vis-à-vis data subjects in the company’s own privacy policy (a mere reference to ChatGPT's privacy policy is not sufficient (Art. 13, 14 GDPR)
-	Carrying out a data protection impact assessment as far as necessary (Art. 35 GDPR)
-	Documentation in the records of processing activities (Art. 30 GDPR)

Results and recommendations

A closer look at the issue shows that the use of ChatGPT's web interface to process personal data will regularly be non-compliant under data protection law.

Companies should therefore take precautions to prevent such use of the service to avoid the risk of violating data protection law. It is therefore recommended to prohibit the entry of personal data in the inputs (prompts) unless the customer has expressly consented to this.

In contrast, the use of the API faces fewer data protection hurdles. However, some measures must also be taken to ensure data protection-compliant processing.

Given of the importance of the issue, a harmonized approach at the European level would be welcomed. In any case, it would be difficult to justify why the service would not be permitted in Italy but would be available in Germany, for example. After all, the starting point for data protection is the same for all member states - the GDPR, which is to be interpreted uniformly within the European Union.

Against the backdrop of the data protection pitfalls highlighted, Politico magazine aptly writes: "[ChatGPT is entering a world of regulatory pain in Europe](https://www.politico.eu/article/chatgpt-world-regulatory-pain-eu-privacy-data-protection-gdpr/)".

Despite the regulatory uncertainties, companies should not rush to abandon the use of the service. After all, companies that have introduced AI report significant cost reductions and revenue increases. "[Companies that have adopted AI continue to pull ahead](https://aiindex.stanford.edu/wp-content/uploads/2023/04/HAI_AI-Index-Report_2023.pdf)".

If the use of ChatGPT makes sense in your respective business, the data protection risks can usually be reduced to a minimum by designing the integration with data protection requirements in mind.

Conclusion

Is ChatGPT GDPR-compliant?

Not a day goes by without exciting news about OpenAI or other AI players being published, but also new problems and challenges becoming known. For example, OpenAI had to report its first data privacy incident when the chat history, email addresses and contact information of other users [were disclosed](https://futurism.com/the-byte/chatgpt-bug-chat-histories-email-phone).

At the end of March, the Italian data protection authority [banned](https://www.gpdp.it/web/guest/home/docweb/-/docweb-display/docweb/9870847) ChatGPT operation in Italy temporarily for, among other things, lacking a legal basis for processing personal data for training the AI algorithm and failing to integrate an effective age verification system to protect children under 13.

Publicly, the regulator highlights in its press release that OpenAI could face a fine of up to 20 million euros or 4% of its annual global revenue if it does not follow the requirements of the order. OpenAI has been given 20 days to respond to the authorities order, and an initial dialogue between the regulator and OpenAI [has already taken place](https://www.garanteprivacy.it/home/docweb/-/docweb-display/docweb/9872832#english). In the meantime, the Canadian regulator has also [announced](https://www.priv.gc.ca/en/opc-news/news-and-announcements/2023/an_230404/) that it will initiate investigations against OpenAI. It should therefore only be a matter of time before other supervisory authorities follow suit.

Current developments 

The current reactions and administrative measures are mainly directed toward ChatGTP of OpenAI. The chatbot is offered in a free version as well as via a paid subscription. The addressee of the supervisory measures is therefore the company providing the tool (OpenAI).

However, ChatGPT is also offered via the OpenAI API platform. Through this API platform, companies can integrate ChatGPT into their own services. A very common scenario is the integration of ChatGPT into customer support, but also apps like Snapchat, Quizlet, and Shopify have already [integrated](https://openai.com/blog/introducing-chatgpt-and-whisper-apis) ChatGPT via the API. Just recently, Helvetia Insurance from Switzerland integrated ChatGPT into their customer chatbot. In the [instructions for use](https://www.helvetia.com/ch/web/de/privatkunden/kontakt/services/chatbot-clara/frag-clara.html), the chatbot is presented as an experiment via which questions about insurance and retirement planning can be answered. Customers are then asked not to enter personal topics into the chatbot console.

We are currently receiving more and more inquiries about how OpenAI products can be integrated into our customers' products and services via the API in a legally compliant manner.

Use of ChatGPT via the OpenAI API platform

If companies integrate ChatGPT into their products and services via the API, they generally also become data controllers in terms of data protection law. OpenAI (more precisely OpenAI, L.L.C., 3180 18th St, San Francisco, CA 94110) becomes in these cases a service provider and processor acting on the instructions of the company using the API.

As a controller, each company using the API must be able to demonstrate for each (data) processing step that the processing in question is data protection compliant. While the Italian supervisory authority still addressed OpenAI directly in its order, in the future any company using the API could also become the addressee of supervisory measures. It is thus adviseable to properly implement the applicable data protection requirements when integrating ChatGPT into own services and products.

Who is the controller?

The controller (the company using the API) must be able to demonstrate the legal basis for the data processing when using the chatbot. This should still be quite unproblematic with regard to the pure provision of services (e.g., customer support) since the responsible party can regularly invoke a necessity for the protection of a legitimate interest (Art. 6 (1) f) DSGVO) or for the performance of a contract (Art. 6 (1) b) DSGVO). 

It becomes more problematic when it comes to the use of the inputs (prompts) for training the AI algorithm, as this processing for OpenAI purposes is no longer covered by the data processing agreement between the controller and OpenAI. It is conceivable that the controller obtains consent from the user, which also covers further processing by OpenAI. However, it is more advisable to exclude the further processing of the input by OpenAI so that the partly sensitive content is not further processed for the AI algorithm.

###### API-Content vs. Non-API-Content

OpenAI differentiates between "Non-API Content" and "API Content". According to the [terms of use](https://openai.com/policies/terms-of-use), content input from users received via the ChatGPT-API (API Content) will not be used for OpenAI's own purposes (e.g. for further development and service improvement) unless the user or customer explicitly requests this. 
Only the Non-API Content is used by default for the training of the AI algorithm, whereby users are offered an opt-out option here. Opt-out can be done via a [web form](https://docs.google.com/forms/d/e/1FAIpQLScrnC-_A7JFs4LbIuzevQ_78hVERlNqqCPCt3d8XqnKOfdRdQ/viewform) that is linked to the user account.

From a contractual point of view, it therefore looks as if the responsible party using the API is on the safe side for the time being. The [privacy policy](https://openai.com/policies/privacy-policy) of OpenAI, however, contains additional purposes, such as the analysis and improvement of services, the performance of research, and the development of new programs and services. In this respect, it remains unclear whether any processing for OpenAI purposes remains excluded or only processing for training the algorithm. At this point, a clarification would be desirable that no customer data or user input is processed for own purposes.

###### Transparency for users

The controller must make data processing transparent to its users when using OpenAI services. This is regularly done through data protection notices or privacy policies as an expression of the transparency obligation of Art. 13 and Art. 14 of the GDPR. However, it is not sufficient for the controller to simply refer to the OpenAI privacy policy. Rather, it must provide independent information about how and for what purposes the data of the users is processed by the controller and its processors, how long it is stored, and when it is deleted again.  It is also necessary to make it transparent to users how they can exercise their data protection rights, and it must be defined between the controller and OpenAI how compliance with data protection rights can be ensured with service providers such as OpenAI.

###### Contractual requirements

When using OpenAI services via the OpenAI API platform, an order processing relationship is established between the data controller as the client and OpenAI as the processor. For these purposes, OpenAI provides a [Data Processing Agreement (DPA as of 05.04.2023)](https://openai.com/policies/data-processing-addendum), which can be concluded via an electronic signing process. However, it must be checked in detail whether the respective use is actually a data processing on behalf.

This is because constellations are also conceivable in which the parties are to be regarded as joint controllers under Art. 26 GDPR (e.g., if training data of the customer is processed together with OpenAI for both parties for their joint purposes). OpenAI currently does not (yet) provide a template for a contract pursuant to Art. 26 GDPR.

If the data is processed via the API in third countries (e.g. in the USA), standard contractual clauses (SCC) must also be concluded. OpenAI has integrated the SCCs into its DPA because, according to them, the data processing takes place in the USA. As long as there is no adequacy decision by the EU Commission on the EU-U.S. Data Privacy Framework (more on this in these [Insights](https://simpliant.eu/insights/data-processing-by-us-cloud-providers-in-europe-is-possible-under-data-protection-law)), the controller must also conduct a so-called Transfer Impact Assessment (TIA)and,  if necessary, must conclude an agreement on supplementary measures for the protection of the data.

###### Data Protection Impact Assessment (DPIA) and data security

If the data processing during the use of the ChatGPT-API is associated with high risks for the data subjects, a data protection impact assessment (DPIA) must be carried out according to Article 35 GDPR.

The joint body of the German Data Protection Supervisory Authorities (DSK) has published a so-called [positive list ](https://datenschutzkonferenz-online.de/media/ah/20181017_ah_DSK_DSFA_Muss-Liste_Version_1.1_Deutsch.pdf)of processing activities for which a DPIA is mandatory. Particularly relevant here are item 11 of the list (customer support using artificial intelligence) or also item 13 (telephone call evaluation using algorithms). In this context, it is of decisive importance for which purposes the service is to be used. For example, if the ChatBot is to be integrated into the customer support of a health insurance company (as in the example of Helvetia Insurance, see above), health data can be processed quite quickly and it would have to be analyzed in the context of the DPIA how the risk of disclosure of sensitive information and health data is effectively handled or excluded.

The DPIA pursues the goal of identifying and assessing the risks for the data subjects in a structured manner and determining how these risks can be handled with technical and organizational measures and reduced to an acceptable level. At this point at the latest, an in-depth analysis of a security concept for OpenAI is likely to become necessary. According to OpenAI's DPA, however, this is only made available on request. The freely available information on the website is probably not sufficient in itself to make a reliable assessment of whether the measures can effectively counter the assessed risks.



What should be considered when using the API?

On 28 April 2023, the ban on ChatGPT in Italy [was lifted by the Italian supervisory authority](https://www.garanteprivacy.it/home/docweb/-/docweb-display/docweb/9881490#english) after OpenAI made the service as a whole more transparent, introduced age verification for local users and facilitated the implementation of data subjects' rights. 

In particular, OpenAI [simplified the process](https://openai.com/blog/new-ways-to-manage-your-data-in-chatgpt) for opting out of the use of non-API content for its own training purposes. Instead of the previous opt-out via web form, the storage of one's own "chat history" can now be turned off by mouse click in the settings. A conversation conducted under this setting will then be kept by OpenAI for 30 days and only checked to monitor possible misuse. 

In addition, OpenAI has announced the release of "ChatGPT Business" in the coming months. ChatGPT Business will follow the "[API data usage policies](https://openai.com/policies/api-data-usage-policies)", whereby end-user data will not be used to train OpenAI's models by default. 

Lastly, OpenAI enshrined a new "export option" in the settings. This makes it possible to export ChatGPT data and thus understand what information OpenAI stores. In return, the user receives a file with their conversations and all other relevant data by email.

Update from 16.05.2023

The latest developments around AI providers are likely to be just the beginning of a longer consolidation phase between AI providers and regulators. Even if the focus is currently on OpenAI, the areas of tension are also transferable to other providers such as Google's Bard and others. 

The current dynamics therefore require careful observation of the developments so that new requirements on the part of the supervisory authorities or the legislature can be responded to in good time.

Even though the news are currently dominated by reports of bans, regulatory measures, and risks, it can be said that an integration of AI services into one's own offerings and services – at least from a data protection perspective – can be designed in a GDPR-compliant way.

When your company considers to implement ChatGPT in their service offerings, it is advisable to consider privacy compliance aspects in the earliest planning phase (privacy-by-design), and that the minimum legal requirements, such as the lawfulness and transparency of data processing, the conclusion of the necessary data protection agreements, the performance of data protection impact assessments, and the review and specification of technical and organizational measures, are addressed.

Data Protection aspects when using the ChatGPT-API

Data Protection Requirements when using ChatGPT-API

In practice, the server infrastructure required to operate the software (hosting) is very often provided by American companies that act as subcontractors to the platform provider. The leading international companies all come from the USA (e.g. Amazon Web Services, Google Cloud Platform, Microsoft Azure) and usually offer their services via subsidiaries in Europe. So far, I am not aware of any European hosting providers that could compete with the major American hosting providers in terms of price or technology.

European companies using the said U.S. hosting providers are often confronted with the question vis-à-vis customers and authorities as to whether their services can be used in a GDPR-compliant manner. 

This is because it is sometimes assumed that such use is always accompanied by a third-country transfer of personal data (to the US). As a reminder, according to the so-called Schrems II ruling of the European Court of Justice ("ECJ"), a transfer of personal data is only possible under strict conditions that take into account any access rights by U.S. intelligence agencies, which are considered to be incompatible with European data protection law by the ECJ.

In fact, even the transfer of data to the European entity (e.g., "Amazon Web Services EMEA SARL, Avenue John F. Kennedy 38, 1855 Luxembourg") of a U.S. parent company (e.g., "Amazon.com, Inc., 410 Terry Ave N, Seattle 98109, WA, USA"), was considered to be a data transfer to the United States by some authorities.

This is because the U.S. parent company that controls the European entity could (or would have to) oblige the European entity to hand over data under applicable U.S. laws. Such potential access alone was already considered a transfer to the US.

This in turn would mean that the strict requirements for third country transfers under the GDPR would apply. According to the ruling of the ECJ (Schrems II) and the implementation guidelines of the European Data Protection Board, a transfer impact assessment would have to be carried out in addition to the conclusion of standard contractual clauses (often with the result that a transfer would have been impermissible under data protection law). 

As a result, this often meant that an avoidable data transfer to the USA could only be carried out with difficulty in compliance with data protection law. The uncertain legal situation caused considerable uncertainty among potential customers, some of whom assumed that a data transfer to a large U.S. tech company was always illegal under data protection law. 

The result of this strict interpretation often led to the de facto compulsion to resort to a European hosting provider in order to act in a data protection-compliant manner. As a consequence, however, this put EU companies at a competitive disadvantage vis-à-vis their international competitors.


Previous view: Theoretical access = Data transfer

However, European companies can now breathe a sigh of relief. **If data is transferred to an EU subsidiary (be it "Google Ireland", "Amazon Luxembourg", or "Microsoft Ireland"), this alone does not constitute a third country transfer to the USA.** The quintessence of the legal opinion is that a purely hypothetical access does not constitute a "transfer by disclosure" according to the wording of Art. 44 et seq. GDPR.

This is the view of the Conference of Independent Data Protection Authorities of Germany "DSK" (Datenschutzkonferenz) in its decision of January 31, 2023 (available [here](https://www.datenschutzkonferenz-online.de/media/dskb/20230206_DSK_Beschluss_Extraterritoriale_Zugriffe.pdf)) and also of the Procurement Chamber of the Federal Cartel Office (available [here](https://www.bundeskartellamt.de/SharedDocs/Entscheidung/DE/Entscheidungen/Vergaberecht/2023/VK2-114-22.pdf?__blob=publicationFile&v=2)). [But note: Both the Procurement Chamber and the Data Protection Conference are not courts, so their decisions do not have the force of law].

Both the DSK and the Federal Cartel Office are now of the opinion that control by an American parent company alone does not lead to a third country transfer pursuant to Art. 44 et seq. GDPR. This means that no transfer impact assessment has to be carried out and the data transfer is regularly to be classified as purely intra-European and thus "secure".

European companies that use such subcontractors can now confidently refer to the decision of the Data Protection Conference and the Procurement Chamber of the German Federal Cartel Office.

Current view: Hypothetical access = no third country transfer

For the sake of completeness, it should be mentioned that in the opinion of the Data Protection Conference, however, the possibility of access by public authorities must be taken into account in the context of the general reliability check pursuant to Article 28 (1) of the GDPR. 

In this context, the abstract risk of possible access must be assessed and (among other things) the extraterritorial applicability of third-country law, the risk of instructions from third-country parent companies, and suitable technical and organizational measures to prevent access must also be taken into account. As long as the EU Commission has not yet issued an adequacy decision, companies must place particularly high demands on the diligence of the reliability check.

However, the current opinion (Opinion 5/2023) of the European Data Protection Board (EDPB) has brought an adequacy decision by the European Commission on the EU-U.S. Data Privacy Framework closer again. The EDPB had generally expressed positive views on the EU Commission's draft adequacy decision, but at the same time expressed concerns and asked for clarification on several points. If the adequacy decision would be issued, companies would be allowed to transfer personal data to the U.S. without any special restrictions, as the level of data protection in the U.S. would thus correspond to that of the EU. 

It should also be noted that when data is transferred to EU subsidiaries, there may also be a third country transfer if the subsidiary in turn uses subcontractors from third countries (in some cases, however, this can be ruled out if only "regional services" limited to EMEA are used). A precise legal examination of the respective processing situation is therefore advisable.

We also recommend checking whether the Data Processing Agreement (DPA) concluded with the hosting provider is up to date. Here, it is important to ensure that the DPA also refers to the correct service.

In most cases, this can be verified by a simple Google search ("Microsoft current Data Processing Agreement") and should otherwise be requested from the hosting service provider. Typically, this is done via the data protection email address, for example, which can usually be found in the data protection statements. 

The Data Processing Agreement should be independently reviewed for effectiveness and accuracy of fit and - at least in connection with other parts of the contract - include an EU company as a contractual partner. Several providers make the most recent DPAs available for download via their admin console.

What to watch out for

Data processing by US cloud providers in Europe is possible under data protection law

Natascha Gaden

ChatGPT is a so-called chatbot. A chatbot is a text-based application that allows people to chat with technical systems via a technical interface (API). This is of particular relevance for companies and a significant factor for increased efficiency and quality.

What makes ChatGPT special is that it works on the basis of artificial intelligence, i.e. it uses machine learning to independently generate answers to user questions. This takes it to a whole new level of usability compared to, for example, rule-based chatbots.

What is ChatGPT and what explains the hype about it?

Since personal data can be processed in the context of the use of chatbots, the requirements of the General Data Protection Regulation (GDPR) must be observed.

The obligation to ensure that personal data is processed in compliance with the GDPR primarily applies to the controller. The controller in terms of the GDPR is the natural or legal person who decides on the purposes and means of processing. Specifically, this means that a company has the authority to decide why and how ChatGPT is used for its interests.

###### Purpose limitation
Regarding the principle of purpose limitation, it is problematic that ChatGPT usually wants to use the personal data not only for the purpose determined by the controller, but also for other purposes of its own, such as for artificial intelligence training.

This is currently a difficult challenge for the controller when entering a data processing agreement, as the data may only be processed for its own purposes in accordance with its instructions. 

If the data is also to be processed for other purposes, a suitable legal basis must legitimize this processing.

###### Separation of data
In this context, technical and organizational measures should be used to prevent data from different sources from being merged. This risk could theoretically exist if a controller’s customer uses ChatGPT and receives information from another customer as a result of his request.

###### Storage limitation
OpenAI states in its FAQ that it is not able to delete certain prompts (input to retrieve information) from the use of ChatGPT. Especially if these prompts contain personal data, this circumstance is not GDPR-compliant. The deletion of personal data is not only a right of the data subject, but also a principle of the GDPR to delete personal data as soon as the purpose of the data processing has been achieved. Therefore, if there is no guarantee that the data processed by ChatGPT is no longer related to a person, it should be used with caution.

###### Privacy Impact Assessment
Since AI-based chatbots such as ChatGPT are considererd to be a new technology, their use is likely to make a privacy impact assessment necessary pursuant to Art. 35 GDPR. 

In addition, the federal and state supervisory authorities have already defined certain areas of application in a so-called positive list for which a privacy impact assessment is mandatory. This concerns, for example, the use of AI in the context of customer support. 

How a privacy impact assessment is to be carried out is not regulated in the GDPR. However, there are guidelines and online tools from German and European data protection bodies that the controller can use.

###### For processors
If companies use ChatGPT as a processor and thus process personal data for their customers, the above-mentioned problem areas are equally relevant. The processor is bound by instructions from the controller and ultimately obligated to support him in complying with the GDPR.

Data protection issues in the use of ChatGPT

The planned AI Act will regulate the marketing and use of artificial intelligence within Europe. Aside from the opportunities offered by the use of artificial intelligence, the new EU law will address the associated risks. It is therefore to be expected that, when the AI Act comes into force, providers and users of AI systems such as ChatGPT, among others, will be subject to more specific obligations regarding the above-mentioned aspects.

If you have any questions around data protection and the integration of ChatGPT or similar applications, please feel free to contact us.

(This post was not created with the use of ChatGPT 😉)


Impact of the upcoming AI Act on the use of ChatGPT

GDPR and ChatGPT

Steven Bressner

When using your service, your customers will entrust personal data of their employees and/or their customers ("data") to you that, generally (we will talk about exception in Part 3) you must only process according to instructions of the controller and under a data processing agreement (DPA).

A bit simplified, your customers primary interest vis-à-vis your organization is to make sure that there is a DPA in place that meets legal requirements and that you have "adequate" security measures in place to make sure their data is sufficiently safe with you. Most companies will (rightly) want to make their own picture in this regard.

Saying that you are GDPR compliant and/or putting a fancy fantasy badge on your landing page may be really cute for marketing, but in essence it means absolutely nothing to most of your potential customers. It bears no significance whatsoever, in particular, if you sell to enterprise or larger organizations. There are certifications (similar to ISO 27001) that are vouched for by independent accreditation bodies, which would provide more clout, however, certifications for GDPR are mostly still in the process of being developed. Bottom line, you probably won't have them (now) and neither will your subprocessors. 

The sooner you understand that in many cases your customers will want more substantial answers, and the sooner you can provide meaningful documentation, the faster you'll close that deal.

Understand why Leads are asking Questions and forget "GDPR Compliant" Tags

Legally speaking DPAs are pretty "stupid" contracts (this does not apply for the important description of processing carried out under it). Quite literally everything that is supposed to be stipulated in them is spelled out by Art. 28 GDPR. Therefore, any minute spent on negotiating DPAs is wasted time in our view. 

Based on our experience there is a very effective fix, being the use of EU Standard Contractual Clauses (EU SCCs). EU SCCs are a template contract that has been approved by the European Commission. There is a prohibition to modify the core text (there is a bit wiggle room regarding the annexes). Therefore, none of your customers should have anything to nag about regarding the contract. 

Important: do not confuse EU-SCCs with SCCs for third country transfers. They are two different things.

You can download the template here:

[https://commission.europa.eu/publications/standard-contractual-clauses-controllers-and-processors-eueea_en](https://commission.europa.eu/publications/standard-contractual-clauses-controllers-and-processors-eueea_en)


Simplify your DPA

If you do not want to use the EU SCCs or your customer wants to use their own DPA then give your sales team some useful information to be independent, rather than having to run to legal with every comment in the DPA.

The starting point of the FAQ should contain a list of legal requirements of Art 28. In our opinion, for the sake of simplicity and speed you should kick everything out of a DPA that is not required by law. In particular this refers to provisions for liability and damages or jurisdiction (both can perfectly well be dealt with in ToS or other commercial agreements).

In addition, focus on providing information where it really matters. Based on our experience there are two areas that are frequently (and most fervently) subject of debate and negotiations.

###### Addition or Replacement of Subprocessors

Art. 28 mentions two options when adding or replacing subprocessors: a prior specific authorization or a general written authorization. The latter must include a prior notification and the right to object to the addition or replacement. Now, it is absolutely critical to understand that both options equally put your customer in the position to effectively object to adding or replacing, while the option to require prior authorization can wreak havoc on your operations. You would basically need to get prior approval from every customer before you can make any infrastructure switches, and only one customer that does not get back to you can block the entire process. Even if you customer says that it's their standard procedure to demand prior authorization, give them push back. If you explain the above to them, in a very high percentage they understand. 

###### Audit Rights

Art. 28 requires the processor to provide all information necessary to demonstrate compliance with [Art. 28] and allow for and contribute to audits, including inspections. Because these things have the potential to eat up a lot of time and resources, a lot of processors will try to limit or exclude them. Sure, if a significant number of your customers starts wanting to do on-site inspections this can jam up your operations. However (and unfortunately for you), you are legally required to contribute to and allow them. If you try to limit or exclude them, in many cases this will lead to pushback from your leads and DPA negotiations and it is legally more than doubtful that such limitations or exclusions would stand in front of a court. If you boil it down you have the choice of creating more negotiations thus prolonging your sales cycle (which also uses resources) or biting the bullet and answer questionnaires or participate in on-site audits. IMHO, I would rather opt for the latter. On-site audits for cloud-heavy operating companies are quite rare in our experience (I mean what is there really to see?) and resources for questionnaires can be preserved with better security documentation.

The next parts of this series will deal with international data transfers, separating between being a processor and a controller, and security documentation, known as "technical and organizational measures" or "TOM". Make sure to add relevant information regarding all of those topics to your sales FAQ. 


Stay tuned for Part 2 


Set up a strong FAQ for your Sales Team

Empowering Sales to deal with GDPR Questions

Before we get started with the nitty gritty, we need to sort out some GDPR basics: figuring out who is a controller and a processor. Spoiler alert: it's quite tricky.

Controllers are organizations that (quote GDPR) "determine the purposes and means of the processing". In simpler words, they decide which data gets used for what reason. The determine the "how" and the "if" of data processing if you will.

Processors only handle data on behalf of and subject to controllers' instructions (as per the data protection agreement "DPA"). 

That said a B2B SaaS provider will usually assume the role of a processor as the customer decides how to use your tool to process their (customer) data. 

In reality, these definitions are not always that easy to apply. If you offer a standard application you pretty much determine a lot of the "how"... For that reason, the "if" part generally holds more weight when figuring out the respective roles. To make matters a bit more complicated the role of a processor needs to be assessed per processing activity (def: processing personal data for a specific business purpose). In many cases I have encountered B2B-SaaS providers will be both a controller and processor regarding their product.

In our experience it really helps to think in terms of outsourced business processes When making that determination. If a customer outsources a business process to your platform, in all likelihood you will be considered a processor for all data that is associated with this process. In turn, such data will usually be the center of focus when it comes to integrations.


Controllers vs. processors

Let's start by taking a look at the most common scenario. Your company is a processor for a controller, and you offer an integration to another service ("integrated service"). For example, you offer a fintech tool and you can integrate with the API of several banks to sync financial data to your SaaS Platform.

At the end of the day the solution is to understand that the integrated service is just a different processor for the same controller (namely the customer of your platform). This means that the same controller has two respective processors. Both services are based on independent service contracts and a respectively two DPAs in place. And that's it: no additional contracts or safeguards are needed to provide the integration in conformity with GDPR to your customers.

The "usual" scenario

Yes and no. 

From a data protection point of view, no additional contracts are required. However, it would make sense to have your DPA reflect the instruction of the controller to send and/or receive data via an integration. Note that your DPA may also refer to your terms of service, which could address this point.

From a commercial and cybersecurity standpoint, however, it definitely makes sense to have an agreement in place with the integrated service in terms of IP rights and security documentation regarding the APIs that are used.

![B2B SaaS Integrations & GDPR](https://a.storyblok.com/f/183108/2460x1686/f844776923/b2b-saas-integrations-en-simpliant-insights.jpg "The integrated service is just a different processor for the same controller with independent contracts in place that issue instructions to share data.")


Do additional contracts need to be in place?

From my experience, I can think of only one scenario that might deviate a bit from the above: the integration does not occur directly between two processors that are contractually bound by the same controller. Rather, another third-party service is used to facilitate the integration (think of Zapier, Make "the tool formerly known as Integromat"). For our purposes, let's call it an "integration provider".
 
In that scenario the main difference is that the controller does not have a direct contractual relationship and no DPA with the integration provider. This means, that no instructions could be issued accordingly. In order to ensure this, the only viable solution is to add to integration provider as a subprocessor to the DPA of that processor that has a contractual relationship (and DPA) with the integration provider and that initiates data transfers via the latter. In practice, this could apply to both processors (you or the integrated service) respectively. 

If I haven't lost you by now, and you think I've missed something or still have open questions, please feel free to reach out! 
