The question is evident: how do businesses employ global AI systems and continue to comply with the GDPR cross-border data transfer principles? It is essential to understand the link between AI and personal data and its impact through the legal landscape governing cross-border transfers.

Understanding the AI and the GDPR Landscape

Artificial intelligence systems will typically need to use humongous amounts of data, of which may include personal data. This data is typically obtained from various jurisdictions and processed using cloud platforms, data centers, and development teams in various countries. The worldwide infrastructure complicates the fulfillment of the GDPR since it inhibits the transfer of personal data beyond the European Economic Area (EEA) and United Kingdom.

The GDPR is grounded in fundamental principles of lawfulness, fairness, transparency, limitation of purpose, and data minimization. It also requires accuracy, limitation of storage, integrity, confidentiality, and accountability. These principles should be adhered to by any AI system that involves personal data even when data is transported.

Cross-border data transfers happen when personal data is moved from the EEA to a third country. These are addressed by Chapter V of the GDPR, which dictates the legal frameworks organisations must obey. Since most AI systems are international data processing, virtually all of them are confronted with this regulatory challenge.

Focal Compliance Challenges in Cross-Border AI Projects

There are a few challenges that make it hard to regulate cross-border data in AI:

• Terabytes of information: AI systems read text, images, video, audio, and behavior data in volumes that older compliance procedures find difficult to keep up with. It’s no small challenge to collect, categorize, and safeguard these datasets across borders.
• Pseudonymization risks: So-called anonymized data can in fact facilitate re-identification, particularly when combined with additional datasets. It is important to understand the difference between pseudonymized and anonymized data. 
• Lack of transparency: Most AI systems, especially deep learning-based systems, are “black boxes.” This uninterpretability may hinder the ability of organizations to show compliance with the GDPR, especially purpose limitation and data minimization.
• Shifting rules: Regular updated guidance from national authorities and the European Data Protection Board (EDPB) on AI, transfers abroad, and the way the two interoperate. Just requirements mount with the arrival of legislation such as the EU AI Act.
• Third-party risk: Third-party data suppliers, cloud vendors, and outsourcing data processors are all more likely to be in the AI supply chain. Unless they are properly managed, they bring inherent third-party risk through non-compliance, data loss, or unauthorized transfers.

Legal Frameworks for GDPR-Compliant Cross-Border Transfers

The GDPR provides a range of legal frameworks for cross-border transfers of personal data beyond the EEA, depending on conditions and limitations.

• Adequacy decisions are among them. The European Commission will be in a position to determine that a non-EEA nation ensures “adequate” protection for personal data, and data can flow freely. These decisions have been granted to Japan and Switzerland, and the same has been granted to the United States under the new EU–U.S. Data Privacy Framework. Adequacy decisions are not absolute, however, and can be invalidated, as was the invalidation of Privacy Shield.
• For organizations in countries not issuing an adequacy decision, Standard Contractual Clauses (SCCs) are the most used. Contractual clauses maintain international data transferred from being reduced below EU levels. Organizations must perform Transfer Impact Assessments and introduce additional safeguards since the Schrems II judgment, in order to lawfully use SCCs.

• Binding Corporate Rules (BCRs) is a further possibility for multinationals. They are internal codes of conduct that have to be approved by a data protection authority and are legally enforceable against the corporate group. It is a scalable solution to implement for intragroup data transfers, but it may be time-consuming and costly to obtain the approval.
• The GDPR also has limited derogations for certain situations, including where the individual provides unambiguous consent or where a transfer must be conducted in order for a contract to be formed. Exceptions are few and not to be generalized or bulked.

Practical Steps to Remain Compliant

To effectively administer cross-border data transfers, follow these best practices:

• Map data flows: Determine where personal data comes from, is processed, and travels.
• Perform Data Protection Impact Assessments (DPIAs): DPIAs for riskier AI projects ensure assurance of risk identification in the areas of discrimination, bias, and data protection and transfer risk assessment.
• Improve data governance: Establish policies and roles that ensure accountability to operating, technical, and legal teams.This ensures consistency and accountability when dealing with personal data.
• Enforce security controls: There must also be organizational and technical controls. These include secure development of AI models, access controls, pseudonymization, and encryption. Security audits and penetration tests done on a regular basis can combat threats that can be used in performing cross-border transfers.
• Manage third parties: Secure good data processing terms and ensure all suppliers comply with the GDPR. Any AI supplier or cloud provider dealing with your personal data on your behalf must be subject to rigorous due diligence. This includes negotiating good DPAs and ensuring vendors apply GDPR-level controls.
• Train your staff: Make sure staff is educated about their part to play with regard to AI and international processing of data. A specific incident response plan also needs to be created to handle any AI system-related breaches.

Readiness and Regulation

Regulatory requirements are changing. The EU AI Act and industry-specific guidelines from the EDPB and others will keep transforming what looks like compliance with AI. Leading-edge businesses are already constructing governance structures in accordance with the GDPR and these new rules. Technologies such as data flow mapping automation, real-time risk management, and Transfer Impact Assessments run on a regular basis become typical. Legal, technical, and compliance staff need to interact so that AI ingenuity is converged into regulatory requirements.

Conclusion

Cross-border transmissions of AI data under the GDPR is not impossible, but difficult. With good understanding of the regulatory frameworks, operating on high-risk subjects, and adopting good mitigations, organizations can deploy effective AI technologies in immaculate compliance.

Creating AI responsibly involves creating it legally. Now is the time to audit your cross-border data transfer processes, enhance your governance structure, and embed compliance in all areas of your AI work.

The post GDPR Compliance for AI: Managing Cross-Border Data Transfers appeared first on TechGDPR.

The EU AI Act 

The EU AI Act is one of the first laws in the world designed to regulate AI, setting rules to ensure AI systems are safe, ethical, and respect human rights. It classifies AI systems into four risk categories — from minimal risk to high risk. The stricter the category, the more oversight and compliance are required. The AI Act also outlines use of AI that is prohibited within the EU. Chapter 2, Act 5 of the EU AI Act prohibits the following uses of AI: 

• Using manipulative techniques to distort behavior and impair informed decision-making, causing significant harm;
• Exploiting vulnerabilities related to age, disability, or socio-economic status to distort behavior, causing significant harm;
• Inferring sensitive attributes (e.g., race, political opinions, sexual orientation) through biometric categorization, except for lawful purposes;
• Social scoring that leads to detrimental treatment based on social behavior or personal traits;
• Assessing criminal risk solely based on profiling or personality traits, unless supporting human assessments based on objective facts;
• Compiling facial recognition databases by scraping images from the internet or CCTV footage;
• Inferring emotions in workplaces or educational institutions, except for medical or safety reasons; and
• ‘Real-time’ remote biometric identification in public spaces for law enforcement, with exceptions for serious cases like missing persons or imminent threats.

There are also special considerations and requirements for the development or use of high risk AI systems, which are classified as such in Chapter 3 of the EU AI Act which could result in the necessity of a risk management system. Risk management systems are frameworks for identifying, mitigating, and managing AI-related risks, especially regarding discrimination and data breaches.

Lastly, the providers of General Purpose AI systems (GPAI) are subject to special requirements under Chapter 5. 

Important Principles for Ethical AI Policies to Address

When developing ethical AI, it is important to emphasize fairness, accountability and transparency. It is not just important in the development of AI systems but the use of AI systems. In essence, ethical AI is about ensuring that as AI technology advances, it does so in a way that respects human dignity, promotes fairness, and fosters trust, ultimately contributing to the well-being of individuals and society as a whole. 

Fairness

The primary objective of a fairness policy is to eliminate algorithmic bias and ensure that AI decision-making processes treat all individuals equitably. An AI policy should include comprehensive protocols such as fairness assessments, regular bias audits, and data diversity requirements during the training phases of AI systems. By mandating AI fairness testing before deployment and continuously monitoring systems for potential biases, organizations can proactively address and mitigate any unfair treatment. For instance, consider the case of Amazon’s AI recruitment tool, which was found to exhibit bias in hiring practices against women; this highlighted the necessity of implementing bias mitigation policies in AI-driven recruitment processes to ensure equitable outcomes.

Accountability

Establishing clear lines of responsibility for AI decision-making is crucial to ensuring human oversight and accountability. An AI policy should address the issue of accountability by defining specific roles and responsibilities within the organization for the oversight of AI systems. This includes establishing audit trails to track decisions and requiring regular reviews of AI outputs to ensure accountability. As Data Officers, TechGDPR can help in the development of these policies. Since the role of Data Officer involves data governance, we can help ensure oversight for your organization to maintain control over AI systems and understand their impact on decision-making processes.

Transparency

Transparency in AI systems is essential for building trust among users and complying with regulatory demands. The principle of transparency is also mentioned in Art.12 GDPR. An AI policy should be transparent and include protocols that mandate the use of explainable AI models, thorough documentation of decision-making processes, and clear disclosures in privacy notices regarding AI-driven data usage. A good AI policy should require organizations to provide stakeholders with comprehensible explanations for AI-driven decisions, ensuring that the operations of AI systems are understandable to both users and regulators. Organizations that adopt explainable AI frameworks such as the OECD Transparency and Explainability Principle, for example, can better maintain transparency and meet regulatory requirements, fostering trust and accountability in their AI applications.

The Role of Data Officers in Ethical AI Policy Creation

Data Officer is a new service provided by TechGDPR in which we can help with AI compliance as well as serving as a Data Protection officer, a role which can be mandated by the GDPR. Instead of having multiple people filling these roles, a Data Officer can understand how to navigate everything for your peace of mind. It is not a traditional role for privacy or AI compliance but this innovative role can alleviate stress for how to navigate multiple regulations including the AI Act as it is so new. 

Conclusion

In conclusion, as AI continues to permeate various industries, ensuring its ethical use is paramount. The EU AI Act lays out new legal requirements for AI systems and multiple frameworks including the OECD emphasizing the need for fairness, accountability, and transparency which can be done through the creation of AI policies. Organizations must not only comply with these regulations but also proactively adopt ethical AI practices to build trust and mitigate risks.

TechGDPR’s Data Officer service offers a comprehensive solution, integrating AI compliance with data protection and privacy governance. By crafting and implementing tailored AI policies, a Data Officer can ensure that your organization’s AI systems are not only legally compliant but also ethically sound, fostering a responsible approach to AI development and usage. As the landscape of AI regulation evolves, partnering with a Data Officer will be crucial in navigating these complexities and maintaining your organization’s commitment to ethical AI.

The post Ethical AI: How Data Officers Craft Policies for Fairness, Accountability, and Transparency appeared first on TechGDPR.

The Privacy Tech Directory serves two purposes: 

1. it empowers users to enhance their privacy and
2. provides a list of tools that can help to maintain compliance with relevant data protection laws. 

It offers a large selection of tools categorized meticulously to address different aspects of privacy and security.

It should be noted that the directory is not an exhaustive list but rather an initial stepping point to figure out what services and/or products are available to help with your specific privacy or security concern.

Here’s a detailed look at the categories available:

Features of the Privacy Tech Directory 

The tools are divided into the following categories: 

• Consent Management Platforms: Manage user consent and ensure compliance with the GDPR and other regulations.
• Access Control: Implement secure access controls to protect sensitive information.
• Analytics: Use privacy-focused analytics tools to gather insights without compromising user data.
• File Management: Secure file storage and sharing solutions to protect data integrity.
• Privacy Alternatives: Discover privacy-respecting alternatives to mainstream services.
• AI: Leverage AI tools designed with privacy in mind.
• Forms: Create and manage forms that prioritize user data protection.
• Fonts: Use fonts that respect user privacy.
• Encryption: Employ encryption tools to secure data in transit and at rest.
• Bookmarking: Find privacy-focused bookmarking tools.
• Advertising: Access advertising tools that prioritize user privacy.
• Compliance/Risk Management: Simplify compliance and risk management processes.
• DPO-as-a-Service: Utilize data protection officer services for expert guidance.

The diversity of tools underscores multiple ways technology intersects with privacy, and seeks to highlight the necessity of preserving privacy on various fronts.

The Creation and Evolution of the Privacy Tech Directory 

The Privacy Tech Directory was crafted through independent research and the innovative use of generative AI. Should any inaccuracies be found in the tool descriptions, users are encouraged to contact TechGDPR at privacydirectory@techgdpr.com to correct the information. The directory aggregates information from various sources, including Privacy Guides, Web3 Privacy on GitHub, and the IAPP privacy vendor directory, alongside independent research efforts.

The directory attempts to highlight open source and free tools. There is a landing page to navigate all of the tools with the following options presented.

This database is located on our Privacy Tech Directory landing page. It allows for users to search the database directly by Name, Format, Category or even words that appear in Short Description such as for example: “GDPR.”

For each tool described in the directory, we strive to include the: 

• Name
• Short description (AI generated)
• Format category (Is this tool for developers (low level code)? Is it a working software or application?)
• Long descriptions (AI generated)
• URL / Github
• Languages supported
• Whether the tool is free or not, if the tool is not free, the cost is included if it could be discerned from the website
• Open Source (if applicable)
  • Link Github/open source (if applicable)

If you have new tools to add or wish to feature or remove a tool from the Privacy Tech Directory, please reach out to TechGDPR at privacydirectory@techgdpr.com.

Conclusion

The Privacy Tech Directory by TechGDPR is a resource for anyone interested in data protection and privacy compliance. The directory is a curated collection of tools to enhance security, streamline compliance, and maintain transparency. 

For any requests and issue reporting, contact TechGDPR at privacydirectory@techgdpr.com.

The post Introducing the Privacy Tech Directory: A Tool for Data Protection and Compliance appeared first on TechGDPR.

Crucial to AI Act is that organisations using high-risk AI systems must conduct a comprehensive Fundamental Rights Impact Assessment (FRIA). This assessment proactively identifies and mitigates potential harms to individuals. Notably, the FRIA shares similarities with the Data Protection Impact Assessment (DPIA) mandated under the GDPR. This underscores the intersection of data protection and fundamental rights in the context of AI systems.

What is a Fundamental Rights Impact Assessment (FRIA)?

While the EU AI Act does not expressly define the FRIA, it explains what the objective of the assessment is. The Act also states what the assessment must contain. Recital 96 of the AI Act states that “The aim of the fundamental rights impact assessment is for the deployer to identify the specific risks to the rights of individuals or groups of individuals…”. Moreso, the FRIA helps to “identify measures [to take] in the case of a materialisation of those risks”. Orgnaisations must conduct the FRIA “prior to deploying the high-risk AI system”. They are also required to update it “when ... any of the relevant factors have changed”.

In other words, a FRIA is an evaluation of the risks high risk AI systems present in relation to individuals’ rights. It is also the determination of remediation strategies to manage and mitigate the risks in case they occur.

What should a Fundamental Rights Impact Assessment contain?

According to Article 27(1) of the EU AI Act, the Fundamental Rights Impact Assessment should contain the following information:

Interestingly, Article 27(4) of the EU AI Act states that if organisations meet “any of the obligations laid down in this Article […] through the data protection impact assessment conducted pursuant to Article 35 of [the GDPR]…, the fundamental rights impact assessment referred to in paragraph 1 of this Article shall complement that data protection impact assessment”. Essentially, the fundamental rights impact assessment should complement the data protection impact assessment.

Intersection between Fundamental Rights Impact Assessment and Data Protection Impact Assessment

Article 35 of the GDPR states that a DPIA evaluates the impact of processing operations on the protection of personal data. This is especially where the processing operations make use of new technologies and is likely to result in a high risk to the rights and freedoms of natural persons. Based on this, it appears that the FRIA and DPIA relate to the impact, rights and protection of personal data for high risk AI systems and high risk processing operations respectively.

The table below offers a quick overview of the minimum information requirement for the FRIA and DPIA:

FRIA and DPIA in practice

The minimum requirements for FRIA and DPIA differ. Although in practice, both assessments often include additional information, making them quite similar. For example, Article 35 of the GDPR does not mandate the inclusion of data subject categories in the DPIA. However, organisations logically include such details to identify risks to individuals’ rights and freedoms. Similarly, the EU AI Act does not explicitly require the purpose and proportionality of processes in the FRIA. Yet organisations naturally include them when describing the processes and the necessity of the AI system.

What are the differences?

The major difference between the Fundamental Rights Impact Assessment and the Data Protection Impact Assessment is their focus point. The FRIA focuses on how the AI system directly impacts the rights of individuals. The DPIA focuses on how the processing operation impacts the protection of personal data and the rights of individuals.

The table below provides an overview of the major differences between the FRIA and the DPIA:

Summary

The major takeaway is that the Fundamental Rights and Data Protection Impact Assessment play a complementary role. At least, this is the intent of the EU AI Act according to Article 27(4). Therefore, organisations deploying high risk AI systems processing personal data, will have to conduct both assessments. If your organisation is a provider of high risk AI systems, there is no requirement to conduct the FRIA. However, providers must make information available to deployers of the AI system to make the conduct of the FRIA possible. This is because a substantial part of the assessment relies on the information presented by AI providers.

Given that the EU AI Act is new, organisations may struggle with identifying their role in the AI value chain. Orgnaisations may also struggle to comply with requirements based on that role. At TechGDPR, we assess your processing operations, the information provided by AI providers as well as the envisaged implementation of the AI system to help determine what requirements apply under the EU AI Act. We can help you correctly classify the AI system(s) your organization plans to manufacture or deploy, ensuring early detection of any outright prohibitions. This will prevent your organisation from wasting valuable resources on systems not allowed within the EU.

The post Difference between Fundamental Rights Impact Assessment & Data Protection Impact Assessment appeared first on TechGDPR.

Data localization is the practice of storing and processing data within a set geographical space. This is different than data residency which is often used interchangeably with data localization; however, it is slightly different. Data residency refers to the actual location of the servers and other infrastructure used to store and process the data. While data localization includes the concept of data residency, it also incorporates the idea of data sovereignty. Data sovereignty refers to the rights of the legal authority or any entity to exercise control over data within its borders. Data localization is the combination of both data sovereignty and data residency. 

The EU’s General Data Protection Regulation (GDPR) prioritizes strong data protection practices and indirectly favors the storage of personal data within the EU. However, data localization is not a strict legal requirement therein. 

What is required to transfer data outside of the EEA?

The GDPR does specify the need for “appropriate safeguards” for transferring data outside the EU. Articles 44 to 50 of the GDPR detail the requirements for storing and transferring data outside of the EEA, including adequacy decisions, standard contractual clauses, certifications and binding corporate rules as well as when processing activities are exempt from these requirements. 

Standard contractual clauses as described in GDPR Art.46 are legally binding data protection clauses approved by the European Commission. Binding corporate rules (BCRs) as described in GDPR Art.47 internal rules adopted by multinational companies or groups of enterprises for transfers within a group. BCRs serve to ensure all members maintain appropriate levels of GDPR compliance regardless of their locations. If a company decides to rely on BCRs as a transfer mechanism, all its EU-based entities must adhere to the binding corporate rules when transferring data outside the Union. There are also certification mechanisms for transfers; however, these alone are not sufficient for data transfers outside of the EEA. 

An adequacy decision states that a country outside of the EEA provides adequate data protection measures. If an adequacy decision is in place, then no additional data protection safeguards are required. There are currently adequacy decisions with the following countries: Andorra, Argentina, Canada (commercial organizations), Faroe Islands, Guernsey, Israel, Isle of Man, Japan, Jersey, New Zealand, Republic of Korea, Switzerland , the United Kingdom under the GDPR and the LED, the United States (commercial organizations participating in the EU-US Data Privacy Framework) and Uruguay. 

Addressing the US

Many tech companies and third party service providers are located in the U.S. The Schrems II case, in July 2020 invalidated the U.S. Privacy shield, which allowed for U.S.-EU data transfers. This was due to concerns related to data sovereignty. Essentially, the personal data of EU data subjects that was located in the U.S. could be processed and subject to U.S. surveillance, meaning that US laws did not actually provide adequate privacy protection in accordance with the GDPR for EU data subjects. This case made data localization within Europe more common to avoid transfers to the U.S. when possible. 

The GDPR does not mandate data localization, but it outlines strict rules and requirements for processing data outside of the EEA. Storing and processing data of EU data subjects within the EU helps to make compliance with the GDPR easier; however, compliance is not just data localization, data security and minimization are also crucial to consider. 

Understanding Data Practices 

In recent years there has been a growing trend of organizations using third party services such as content distribution networks (CDNs) and cloud storage services. CDNs have become increasingly popular, serving a majority of web traffic, including traffic from major sites like Facebook, Netflix, and Amazon. Server location means where the servers physically are. Large service providers such as Amazon, Google or Cloudflare allow for companies to choose the location of the servers holding the information. While Amazon might be a US entity, information stored in an Amazon server located in Germany for example is subject to German legal requirements on data sovereignty.

In 2021, a report was published revealing that within the calendar year 44% of organizations experienced a data breach, and the majority of these data breaches were due to not properly assessing the risks of third party vendors. Many organizations see the use of third parties as a security risk, but not a high security risk leading to insecure and poor data management practices. It is important to utilize strong security practices such as always sending personal information using TLS and encryption as opposed to directly over HTTP. While location of the third parties utilized is important, arguably it is not as important as the data management practices or security practices implemented by said third parties.

The Global Landscape of Data Privacy and Data Localization

Some countries have stronger data localization laws. In 2017, there were 67 data localization laws; however, by 2021 that number had grown to 144. There is a growing trend towards regulating data localization. The most notable data localization laws effect: China, Brazil, Russia, and India. 

• China has the personal information protection law (PIPL) which has various localization requirements in regards to personal information. It requires companies to store and process data within China’s borders.
• Russia enforces the Federal Law on Personal Data No.152-ФЗ, dated 27 July 2006 (PDL), and updated it in March 2023 to include strict data localization requirements, mandating the maintenance of data within Russia.
• India’s Digital Personal Data Protection (DPDP) Act, 2023, authorizes the Central Government to impose localization restrictions on certain data categories and potentially require storing specific types of personal data within the country.

There are other countries that require data localization, and when processing information about data subjects located in specific countries it is important to be aware of any data localization requirements. Specific industries such as healthcare have regulations that deal with data residency requirements, such as UAE Health Data Law. 

Conclusion

While data localization can facilitate compliance and potentially simplify certain regulatory aspects, based on the GDPR: the ultimate focus must remain on implementing strong, consistent data protection practices. The GDPR prioritizes securing data through comprehensive safeguards, regardless of physical location, and emphasizes mechanisms such as standard contractual clauses, binding corporate rules, and adequacy decisions to ensure protection across borders. There is an increase in a trend towards data localization as more regulations are requiring data residency, and this article does not take into account other possible local regulations. Furthermore, the evolution of global data privacy laws suggests a continuous shift towards balancing data sovereignty with international data flows, underscoring the importance of robust security practices over mere geographic constraints.

Therefore, when asking, “Does server location really matter under GDPR?”; the answer lies in balancing data security and compliance measures, regardless of geographical constraints. TechGDPR can help to better understand how to navigate data privacy regulations and ensure a high level of compliance. 

The post Does Server Location Really Matter Under GDPR? Understanding Data Localization in the Context of Data Protection Compliance appeared first on TechGDPR.

The Economic Impact of AI

BITKOM, Germany’s digital association, conducted a survey revealing a significant finding: approximately half of all companies surveyed in the EU have already abandoned new, innovative projects. This is due to ambiguities in the interpretation of the GDPR. Fear of potential penalties and legal ramifications could further discourage companies from investing in new AI technologies.

The new AI act, which is still on the legislative agenda of the EU, will largely determine the competitiveness of the AI industry. The act holds the power to shape the EU’s AI industry for the next decade. However, the unprecedented challenge for the EU’s fast-paced tech industry is that of the different member state laws and regulations that prevent innovation. Privacy concerns of EU citizens are also another important topic that directly threatens AI innovation. The EU’s new AI Act envisions an AI regulatory sandbox to establish a sustainable competitive environment for AI technologies while safeguarding citizens’ fundamental rights.

High-risk AI system is also defined in Article 6(1) as: “The AI system is intended to be used as a safety component of a product, or is itself a product, covered by Union harmonization legislation” or “the product whose safety component is the AI system, or the AI system itself as a product, is required to undergo a third-party AI conformity assessment with a view to the placing on the market or putting into service of that product pursuant to Union harmonization legislation.“

AI regulatory sandboxes make it easier for innovators to conduct experiments with high-risk AI systems and test their products with fewer legal procedures. AI regulatory sandboxes also offer legal flexibility, but not absolute immunity.

Looking across all types of AI failures, the most frequent problem is privacy risks. High-risk AI systems have the potential to inflict greater harm upon the fundamental rights of citizens.

Figure: Floridi, L. et al. (2022) ‘Capai – A procedure for conducting conformity assessment of AI systems in line with the EU Artificial Intelligence Act’. (1)

The Role of the EU in AI Regulation

To effectively address the legal implications arising from AI failures, special attention needs to be given to the rules that shape the direction of the regulatory sandbox. These rules include: processing data for public interest, monitoring performance, risk mitigation, secure data environment, data transmission restriction, data subject impact reduction, technical documentation, record-keeping, and transparency for experimenters. These rules, designed to protect the privacy of data subjects, are in line with the General Data Protection Regulation (EU) 2016/679 (GDPR).

Article 54(1)(c) of the AI Act requires effective monitoring mechanisms to identify risks to data subjects’ fundamental rights in sandbox experimentation. If any issue arises that infringes upon the privacy of data subjects, the risks must be mitigated, and, if necessary, the processing halted altogether. Organization must maintain records of decisions and efforts carried out to halt data processing to demonstrate compliance. Each high-risk AI experimentation differs by nature, so a case-by-case examination is necessary. The balancing test between the participants’ interests in privacy and the experimenter’s interests may not practically be determined beforehand or for each experiment. The recommended best practice, also a GDPR Article 25 privacy-by-design requirement, is thus to involve privacy experts in designing the experiments.

Regulatory Sandbox for AI

AI regulatory sandboxes defined in the Article 53(1) of the new AI Act as: “a controlled environment that facilitates the development, testing and validation of innovative AI systems for a limited time before their placement on the market or putting into service pursuant to a specific plan.”

For the experiments being conducted, participants in the AI regulatory sandbox remain liable, and as stated in Article 53(2) of the AI Act, “Member States shall ensure that national data protection authorities and other national authorities are associated with the operation of the AI regulatory sandbox.” Additionally, the corrective powers of the competent supervisory authorities in relation to the data subject rights shall remain unaffected.

The AI Act also introduces practices, such as implementing quality management systems, maintaining technical documentation, and establishing post-market documentation plans, specifically designed for high-risk AI systems. However, the overarching goal is to ensure that these practices harmoniously implement privacy concerns to protect the fundamental rights. As stated in the ICO’s “Regulatory Sandbox Final Report,” practices such as using synthetic data for innovation can also help to reduce the risk to privacy. However, this information is still generated from real data and must be carefully analyzed.

The use of personal data for high-risk AI systems is challenging, but necessary in some cases, such as public health and safety. AI regulatory sandboxes facilitate this possibility, particularly when it serves the public interest in these matters. Nevertheless, supervisory authorities have the authority to halt the experiments if they deem it necessary. The new guidelines from the data protection supervisory authorities and the future cooperation of the European Artificial Intelligence Board are expected to reveal how the AI industry will be shaped within the EU’s Single Data Market policy.

(1) Floridi, L. et al. (2022) ‘Capai – A procedure for conducting conformity assessment of AI systems in line with the EU Artificial Intelligence Act’, SSRN Electronic Journal, p. 57

The post Strategic Compliance in the EU: Balancing Competition, GDPR and AI Regulation appeared first on TechGDPR.

Due to their age and general level of maturity and education, children are considered to be vulnerable and granted special rights in the eyes of the majority of jurisdictions. This is internationally recognised through, for example, the United Nations’ Convention on the Rights of the Child. This vulnerability is considered across different areas of legislation, including data protection, leading to specific provisions being included in the GDPR, such as Art. 8, laying the conditions for information society services to process children’s data.

Art. 8 GDPR’s requirements and the age of digital consent

Art. 8 of the GDPR is the only article that regulates the processing of children’s personal data specifically. It provides that the processing of personal data of children is lawful when the child is at least 16 years old (age of digital consent), or, if below that age, only where consent has been given by the holder of parental responsibility for said child. The GDPR also allows for the individual member state to independently legislate on whether the age limit can be lower than 16, so long as it is no lower than 13. Countries such as Germany and the Netherlands have opted to stick to the standard already established by the GDPR, while others, including Belgium and the UK prior to its departure from the EU, have lowered the threshold to the lowest possible age of 13. Notably, the UK’s current data protection provision still maintains that the age of digital consent is 13.

With this provision, the inevitable consequence is to first and foremost ensure that the age of a data subject is appropriately verified, in order to assess whether these rules apply and take the appropriate steps. However, recent cases and studies have shown that it is inherently difficult to gain consent of a parent or guardian, as there are no appropriate mechanisms in place to ensure that children are being truthful about their age.

Growing concerns about the processing of children’s data

One of the main issues that information society services face in regards to the processing of children’s data, is that these services are not aware that many of the users are actually under the age of digital consent. So far, the majority of these platforms have been relying on relatively lax forms of self declaration, meaning that the platforms offer services on the legal assumption that the user is responsible for declaring their age truthfully, which leads to users easily lying about their age to gain access to platforms where no extra assurance is required. 

UK’s Ofcom research has shown that for platforms such as TikTok and Facebook, which only required users to indicate their date of birth, the vast majority simply indicated a date of birth that would indicate that the user is older than they actually are. The main issue with this is that this may set up young users to be exposed to content that is not safe for their age, and also expose them to unlawful collection of their personal data from these platforms. 

It is therefore unsurprising that Meta and TikTok have been the two biggest companies being fined for violations in regards to misuse of children’s data by the Irish and UK’s data protection authorities respectively. In fact, the UK’s ICO noted that TikTok had been aware of the presence of under 13s in the platform but it had not taken the right steps to remove them. 

It becomes clear that the development and implementation of more stringent age assurance techniques is necessary to ensure that personal data of children is only processed in accordance with GDPR standards. Whilst the EU is yet to come up with specific guidelines in regards to this matter, the UK has published the Children’s Code, to be applied to online services likely to be accessed by children as a code of practice.

Age assurance mechanisms

Amongst 15 other standards that the Code implements, there is the need to ensure that the product and its features are age-appropriate based on the ages of the individual users. To be able to do so, the code requires that the age of users is established with the appropriate level of certainty, based on the risk level of the processing and taking into account the best interest of the child. Therefore, it is also crucial under the code, to carry out a Data Protection Impact Assessment (DPIA) prior to the processing of children’s data, to evaluate said risk level.

The code suggests some additional age assurance mechanisms that information society services may put in place, and the UK’s children’s rights foundation 5Rights has identified additional ones and its possible use cases, advantages and risks. Some of these include: 

• Hard Identifiers, such as sharing one’s ID or Passport or other identifying information. Those are considered to provide a high level of assurance, but raise concerns in regards to data minimisation and might otherwise lead to a disproportionate loss of privacy. Organizations are generally advised to implement appropriate storage limitation periods for those, limited to what is needed to verify an individual’s age once, making it tricky to demonstrate having checked that information, for compliance. Youtube and Onlyfans are examples of ISS that makes use of this mechanism to give access to age-restricted content.
• Biometric data relies on the use of artificial intelligence to scan for age-identifiers on a person’s face, natural language processing or behavioral patterns. It is more commonly used through facial recognition. However, it presents a high degree of risk due to the use of special categories of data, risk of discrimination by biased artificial intelligence and the effective profiling that takes place. Whilst it does provide a high level of assurance, it also requires a very stringent mechanism in place in order to ensure data is processed safely. GoBubble is a social network site made for children in schools that has been using this kind of age assurance technology, by requesting users to send a selfie upon sign up. Meta is also currently in the process of testing this method of age assurance, by working with Yoti, one of the leading age assurance technology developers.

• Capacity testing allows services to estimate a user’s age through an assessment of their capacity. For example, through a puzzle, language test or a task that might give an indication of their age or age range. Whilst this is a safe and engaging option for children, and does not require the collection of personal data, it might not be as efficient at determining the specific age of a user. The Chinese app developer BabyBus uses this type of methodology in its app, by providing a test where users are asked to recognise traditional Chinese characters for numbers.

More examples and use cases of age assurance mechanisms are provided in the 5Rights report. 

Therefore, although it may be difficult to strike a balance between appropriately verifying users’ age prior to sign up, and avoiding over-intrusive measures to do so, it is apparent that solely relying on the user being truthful about their age is no longer sufficient for the majority of platforms, especially when processing vast amounts of personal data, sensitive data or use personal data for targeted advertising. With the growing number of very young children accessing the internet, it is important to ensure that they are protected, their fundamental rights respected, and relevant data protection provisions are fulfilled. In recent years, large steps have been made in the development of alternative secure identity and age verification technologies. The tools are therefore available for organizations to ensure that their GDPR requirements are also met in this respect. 

TechGDPR is a consultancy based in Berlin offering GDPR compliance assessments, DPO-as-a-service retainers and hourly consulting. TechGDPR consultants help assess the vendors you wish to purchase your solutions from, navigate the complexity of international data transfers as well as guide you through the most compliant roll-out of the solutions you have purchased. TechGDPR routinely trains product development, HR, marketing, sales and procurement teams in understanding data protection requirements.  It offers an online training course for software developers, system engineers and product owners.

The post Processing children’s data and implementing age assurance mechanisms appeared first on TechGDPR.

There is no precise definition under the GDPR of what constitutes a legitimate interest and this precisely opens the room for a controller to argue that certain business activities, for instance, sending direct marketing messages to a group of people are based on controller’s legitimate interest. 

Ultimately, all companies have different interests in processing personal data for different purposes. But are all these interests legitimate? 

The GDPR offers a few sections where certain characteristics can be extracted, reducing its scope and outlining this lawful basis. 

On one hand, the GDPR explicitly says that personal data can be processed for the controller’s legitimate purposes or third party purposes (Article 6.1.f). In other words, a company can have the intention of processing personal data for their own interest but if third parties need to receive personal data, this also constitutes a legitimate interest. 

Additionally, commercial interests are also part of the list. For example, if a company has a commercial interest to store the personal data of website visitors, this is possible in principle. 

Nevertheless, the processing of such personal data must be necessary. The latter means that it can’t be up to the controller’s discretion to process this data and it must be the only way to achieve those purposes. Thus, if it’s possible to do it in another way, then it’s not recommendable to rely on this legal basis. 

Taking the previous example, the company should determine that they do need to store website visitor data in order to better understand the customers and/or to know what is the customer’s interest using the company’s services so that it will be possible to improve the services and search external adequate suppliers if needed. 

But not everything ends here.

If such interest affects individuals’ fundamental rights and freedoms, it won’t be possible to carry out the processing, even if it is necessary. 

Hence, if a company informs on the privacy policy that they will collect website visitor’s data for improving the service but then those individuals start receiving weekly newsletters with products they are not interested in, it is not possible to do it under the GDPR. 

Purpose, Necessity and the Balancing Test: relying on legitimate interests as a lawful basis. 

As previously shown, three elements need to be considered whenever a company selects legitimate interest as their legal basis.

First, consider whether the activity at hand pursues a legitimate interest and none other. For instance, if a company stores employee bank account data for payment purposes, this is inextricably linked to the employment contract, therefore the legal basis of this processing activity is to allow the company to perform a contract, which means no legitimate interest is involved here. 

Secondly, the processing of the activity has to be necessary to achieve this legitimate interest. 

Finally, such interest must be balanced with individuals interest, rights, and freedoms. Moreover, if individuals are affected – particularly children- by that processing or would not likely expect that processing to happen, companies should avoid processing their personal data or find another lawful basis. An important factor that could trigger this last step is what the privacy notice disclosed to individuals. If companies include clear information about the processing, individuals are more likely to expect that processing.
We encourage companies to keep a record of the legitimate interests assessment (LIA) to demonstrate compliance if required. 

Use-cases: can companies rely on legitimate interest for direct marketing or web analytics?

There is no clear cut yes-or-no answer to these questions. 

Apart from the mandatory 3-step approach, it is important to keep in mind that the relationship with the individuals plays a very important role in determining the possibility to use this legal basis. Should the company have a previous client relationship, the individual could expect the processing of personal data. In other cases, a full Legitimate Interest Assessment (LIA) will lead to the applicability of the legitimate interest will be determined on a case-by-case basis. 

Ultimately, the information companies provide to the individuals is key for preventing possible claims. The privacy notice is the best place to provide as it, at the very least allows individuals to exercise the right for their data to not be subject to further processing.

In short, in this article, we discovered that if an appropriate assessment is implemented before processing any personal data based on legitimate interest, it is in effect broader in scope than other legal grounds. The legitimate-interest legal base can be flexible, but it requires both a documented internal assessment of the three stages within the company and external communication to those individuals involved. 

The post How to use legitimate interest under the GDPR? appeared first on TechGDPR.

GDPR and POPIA are fairly similar overall, albeit with some differences in terminology, organisation of the respective articles, and greater specificity on the part of GDPR.

Key Definitions in GDPR and POPIA

A key difference between the Information Regulator (POPIA) and the Supervisory Authority (GDPR)

Responsible parties under POPIA must obtain authorisation from the Regulator in order to:

• process:
  • unique identifiers of data subjects for a purpose other than the one specifically intended at collection and with the aim of linking the identifiers with those processed by other responsible parties
  • information on criminal behaviour or on unlawful/objectionable conduct on behalf of third parties
  • information for the purpose of credit reporting
• transfer special personal information or the personal information of children to a third party in a foreign country that does not provide an adequate level of protection for the processing of personal information.
• The above provisions may be applied by the Regulator to other types of information processing by law or regulation if such processing carries a particular risk for the legitimate interests of the data subject.

In comparison, the GDPR’s Supervisory Authority only monitors GDPR compliance

What are the Conditions (principles) for processing personal information in GDPR and POPIA?

For both the GDPR and POPIA, accountability is the central principle for processing personal information. Under accountability, both regulations specify that the controller/responsible party demonstrate compliance with the following conditions (principles):

How does the scope of application of POPIA compare with that of the GDPR?

POPIA and GDPR apply when the responsible party is:

• Domiciled (established) in the Republic/EU
• Not domiciled in the Republic, but makes use of automated or non-automated means in the Republic with the exception of forwarding personal information.

This scope is comparable to the EU’s pre-GDPR Directive-1995. However, the GDPR also applies when the data processed belongs to EU citizens, regardless of the headquarters of the controller/processor, and when EU member state law applies due to international agreements.

What are the exceptions to the prohibition on processing special personal information under POPIA and GDPR?

Under both POPIA and GDPR, responsible parties/controllers may process special personal information if processing is:

• Carried out with the consent of a data subject
• Necessary for the establishment, exercise or defence of a right or obligation in law
• Necessary in order to comply with an obligation of international public law
• Forhistorical, statistical or research purposes to the extent that
  • the purpose serves a public interest and the processing is necessary for the purpose concerned
  • it appears to be impossible or would involve a disproportionate effort to ask for consent
  • sufficient guarantees are provided for to ensure that the processing does not adversely affect the individual privacy of the data subject to a disproportionate extent
  • Information has deliberately been made public by the data subject
  • Regulator has granted an authorisation upon application by the responsible party on the basis of public interest and established safeguards
•  

How does POPIA’s justification of processing compare with the GDPR’s legal bases

Under POPIA and GDPR, processing is justified when:

• Consent is obtained by the data subject or a competent person when the data subject is a child
• processing is:
  • necessary to carry out actions for the conclusion or performance of a contract to which the data subject is party
  • complies with an obligation imposed by law on the responsible party
  • necessary for the proper performance of a public law duty by a public body
  • protects a legitimate interest of the data subject. This might be interpreted to cover the data subject’s vital interest, a term the GDPR uses, but this is unclear.
  • necessary for pursuing the legitimate interests of the responsible party to whom the information is supplied. POPIA additionally covers the legitimate interests of third bodies here.

Rights of data subjects

How does POPIA compare with GDPR in the following circumstances?

Processing for the purpose of direct marketing

In POPIA and GDPR, the processing of personal information of a data subject for the purpose of direct marketing by means of any form of electronic communication, including automatic calling machines, facsimile machines, SMSs or e-mail is prohibited. Exceptions to this prohibition are when the data subject has consented to the processing or is a customer of the responsible party subject to subjection. In other words, the responsible party has obtained the contact details of the data subject in the context of the sale of a product/service and they are marketing similar products/services.

Additionally, it is essential that the data subject be given a reasonable opportunity to object, free of charge and in a manner free of unnecessary formality, to direct marketing related use of their electronic details. Direct marketing communication must accordingly contain the details and identity of the sender in addition to an address or other contact information to which the recipient may request that such communications cease.

Transfers outside of Republic under POPIA

The responsible party must not transfer personal information to a third party in a foreign country aside from the following exceptions.

Additional Remarks

• The Regulator may exempt any responsible party from compliance with POPIA for the purpose of satisfying public interest or for the benefit of the data subject.
• Automated decision making is not based on the data subject’s consent but rather on a contract or law/code of conduct. Moreover, POPIA safeguards for automated decision making are narrower than in the GDPR. While POPIA provides only a possibility to make representations, GDPR provides a trio of rights related to automated decision making: obtain human intervention, express the point of view, and appeal the decision.
• Responsible parties under POPIA are able to process personal data in the event that the processing is deemed to be in the data subject’s legitimate interest. However, the phrasing of this concept is ambiguous. Consequently, it will likely become a source of abuse. For instance, a clear line of defence for businesses is to argue that they have actually evaluated the data subject’s interest. Similarly, customary assessments of interests done by marketing departments are reflected in cookie banners like this one.

In the long run, as a cultural shift towards more privacy takes place, friction will increase between individuals who want more privacy and organisations who want more data. Accordingly, regulations like POPIA and the GDPR are essential for working through this friction.

This article is for information purposes only, and does not constitute or replace legal advice. Seek professional support for any specific questions you may have.

The post A Comparison of POPIA and GDPR in Key Areas appeared first on TechGDPR.

What are HIPAA and the GDPR?

HIPAA refers to the Health Insurance Portability and Accountability Act of 1996. HIPAA was enacted to specifically deal with how medical data are shared and processed. Unlike HIPAA the GDPR regulates any information which can lead to the identification of a living person whether it is health-related or not. The GDPR denotes health data as special categories of personal data, commonly referred to as sensitive data. This means that non-consensual processing of health-related data is strictly prohibited unless the processing purposes are related to medical diagnosing, preventative or occupational medicine, provision and management of health or social care or treatment, in accordance with a contract with a medical professional or based on Union or Member State law. 

The GDPR defines health data as personal data related to the physical or mental health of a natural person, including the provision of health care services, which reveal information about his/her health status (GDPR Art.4). HIPAA denotes protected health information as any data uncovering an agent’s identity in respect to his or her past, future or present physical or mental condition, provision of and payment for the health treatment and services. Both definitions are similar, yet HIPAA also designates financial information of the recipient of the treatment as health data. The GDPR applies to all organizations operating in the EU or offering goods or services to individuals located in the EU territorially no matter of the citizenship. HIPAA, on the other hand, applies to special covered entities within the US, those include healthcare providers, health care clearinghouses and health plan providers.

The key differences between HIPAA and GDPR relevant to MedTech 

The principal difference between the regulations is obviously their scope. As previously stated, the GDPR relates to all organizations processing all types of data relating to a person. Furthermore, the GDPR applies to a much broader range of entities. Even if the company is located in the US (or anywhere in the world) and processes data of subjects located in the EU, it must comply with the GDPR. Contrastingly HIPAA only applies to covered entities located in the US. 

The right to be forgotten is another aspect specific only to the GDPR. It stipulates that under certain conditions, such as the revoking of previously granted consent or when the data is no longer necessary, the data subject may exercise a right to request a free of charge erasure of his or her personal data. If a company relies on third-party cloud storage services, it should ensure that it is able to locate and erase the data when required. The GDPR is also stricter on data breaches, it only grants 72 hours to report a data breach while HIPAA allows for up to 60 days to report a data breach if more than 500 individuals. If less than 500 people are affected, the data breach may be reported by the final day of reporting each year. 

The GDPR also introduced the notion of privacy by design and by default. The concept postulates that when developing new services related to MedTech, or any other sector, involving processing personal data, the company must always consider privacy. HIPAA makes no mention of such a framework for launching new services is present in HIPAA. 

Both regulations are compulsory and impose fines for non-compliance. HIPAA fines are mostly around $25.000 per violation, although in the worst case circumstances a company may be fined of up to $1.5 million per year. GDPR opens the door to potentially much larger maximum fines of up to 4% of the annual worldwide turnover. 

Do HIPAA and GDPR overlap?

There are some similarities and overlap between HIPAA and the GDPR which is good news for companies required to comply with both regulations. Firstly, both include obligations relating to individuals or entities handling data on behalf of covered entities who control the processing of data. Under HIPAA, those are distinguished as business associates and are required to sign a business associate agreement (BAA), this is similar to the data processors under the GDPR.

Secondly, HIPAA, as is the case with the GDPR, requires companies to ensure safeguards are in place to protect the data collected and stored from unauthorised access and disclosure. Article 32 of the GDPR specifically deals with the obligation of minimising risks of a security breach. Appropriate measures include pseudonymisation and encryption of data, maintenance of ‘ongoing confidentiality, integrity, availability and resilience of processing systems and services’ as well as ‘ability to restore availability and access to data in the event of an accident’. The same article prescribes regularly testing, assessing and evaluating the effectiveness of security measures in place. Furthermore, the entity subject of the GDPR shall ensure all personnel processing data on their behalf adheres to the code of conduct prescribed by the legislation and does not process data except on their instructions.

Parallel obligations of the covered entities can be found under HIPAA’s Security Rule. HIPAA also postulates confidentiality, integrity, and availability of protected health information in electronic form (ePHI). Likewise, covered entities must ensure potential security threats, or unlawful uses or disclosures of ePHI, are considered and addressed. HIPAA also obliges the covered entities to ‘ensure compliance of the workforce’. 

Both regulations call for minimisation of data collection and minimisation of data disclosure. Data should be disclosed for research purposes, judicial proceedings, public health interest and if required by law in both legislations.

HIPAA and the GDPR grant data subjects analogous rights. In particular, with a few exceptions, such as access to psychotherapy notes, both regulations grant the data subject the right to access and review a copy of the processed data. Moreover, if the information is inaccurate or incomplete, the data subject has a right to request an amendment of the information.

HIPAA and the GDPR grant data subjects a right to be informed of how and for what purpose their personal data is used and processed, this includes information regarding the recipients or categories of recipient to whom the personal data have been or will be disclosed. The privacy notice must include information on individual rights with respect to their personal information and how those rights may be exercised, and the covered entities obligations as well as the purpose of data usage and processing. Interestingly, both GDPR and HIPAA require the privacy notice to be written in clear and plain language.  

HIPAA and GDPR application

Two global trends may be identified with regards to MedTech and data processing. On one hand, there is an evident explosion of consumer health data. Technological advancement has stimulated vast growths in consumer-generated health data. Those can be put to work through data analytics to extract powerful insights. Secondly, as life expectancy increases and larger sections of the population account for senior citizens, the market boom for healthcare is explained by a demand to further digitise and employ analytics to identify the most cost and health effective treatments and insurance plans. 

Beyond the similarities and differences outlined earlier, there is a fair amount of divergence in how the two frameworks are implemented. Consider an app developer seeking to re-use healthcare data to extract insights. Under the GDPR, this app developer handles a special category of data and this handling is subject to strict safeguards. However, in the US, the same app developer will not be is not a subject HIPAA and the GDPR -provided they do not process personal data from an EU data subject. That is because HIPAA postulates that only covered entities of healthcare providers and insurers or their business associates are subject to the legislation. In other words, medical data that is collected and processed in a hospital will be subject to HIPAA and considered PHI.

If an individual voluntarily provides his or her health information to a mobile app, which is not connected to healthcare activities of a covered entity (i.e. not a business associate of any covered entity), most likely this falls outside of HIPAAs’ jurisdiction but the app developer remains subject to additional state or federal law. An example of such laws is the FTC Act that generally regulates commercial use of personal data or the Children Online Privacy Protection Act with regards to the use of children’s data. Ultimately, this has an effect on how consent should be extracted to process the data, as well as on the appropriate security and organisational protection measures, regardless of HIPAA. 

This article is for information purposes only, and does not constitute or replace legal advice. Seek professional support for any specific questions you may have.

The post HIPAA, the GDPR and MedTech appeared first on TechGDPR.