Data subject rights (DSRs) are not optional check boxes. They are legally enforceable rights granted to individuals whose personal data is processed. Businesses must respect data subject rights throughout all stages of AI development, deployment, and ongoing system management. The GDPR grants individuals several rights over their personal data. Let us focus on four of these here:

1. Right to be informed: As with other data protection frameworks, transparency is key under the GDPR. This right takes the form of a duty to inform prior to the processing taking place. Businesses must include information on how they collect, use, store, and share data, the purpose of processing, the legal basis, data retention periods, and who may receive the data. Privacy notices are the typical repositories for this information. They must be concise, accessible, and written in plain language.
2. Right of access: Data subjects can request access to the exact personal data a business holds about them. Businesses must provide information about processing activities, data categories, and any third parties with whom they share the data.
3. Right to rectification: Data subjects can request organizations to correct incorrect or incomplete data without delay. Businesses must respond promptly and update the data across systems and third-party processors where necessary.
4. Right to object, right to be forgotten and right to revoke consent: It allows individuals to exercise control. The European Data Protection Board (EDPB)  published a case digest on right to object and erasure. Data subjects must be able to object to the use of their data and request its erasure when it is no longer necessary, when they withdraw consent, or for purposes like direct marketing.

Incorporating data minimization in AI Systems

One of the most effective ways businesses can respect data subject rights is by adhering to the data protection principle of data minimization. This GDPR principle requires businesses to collect and process only the minimum personal data necessary to achieve their specific purpose. Avoid over-collecting data, use anonymized or synthetic data for training, and regularly review AI outputs to remove unnecessary personal information.

Implement transparent data practices

Transparency is central to building trust and achieving legal compliance. Always define the purpose of processing, specifically the training of AI models. If businesses rely on legitimate interest, they must show that they gave data subjects the chance to object; otherwise, they invalidate their legal basis.

Clearly inform existing customers in advance when using their data to train AI models, and provide opt-out options before processing begins. Transparency is key. 

When there’s no direct relationship with the individual (such as when using publicly available data or from data brokers), the GDPR requires information to be provided within one month of its collection GDPR Articles 14.  

In 2023, the Italian DPA temporarily banned OpenAI’s ChatGPT, citing a lack of transparency around how it used personal data for training. The DPA later required the company to implement clear privacy notices and provide users with ways to exercise their rights.

Respect the right to access 

Can data owners request access to training data? 

This becomes complicated with large language models, but under the GDPR, individuals have the right to know if and how their data is being used.

How to exercise that right? 

Under the GDPR, individuals have the right to know if and how their personal data is used, including data processed by AI systems. While this is straightforward for users with an existing relationship (who can submit data subject access requests via account settings or customer support), it’s more complicated when there’s no direct connection.

In such cases, organizations must ensure proactive transparency by clearly informing people through privacy policies and AI transparency reports. Failure to uphold this right contributes to loss of trust and accountability in AI use and development.

Develop clear processes for data deletion and rectification 

Can data be corrected or deleted after it has been used to train an AI model? 

While difficult, companies must explore the use of data architectures that allow tracing of personal data contributions. The GDPR (Recital 26) considers even pseudonymous data, like randomly generated user IDs, as personal data since organizations can technically link it back to a person, directly or indirectly.

To reduce data subject risk while improving compliance, companies could implement the following measures:

• Data encryption: Businesses should ensure proper security implementation, especially when handling sensitive personal information.
• Anonymization and pseudonymization: Where possible, anonymize or pseudonymize data before using it in AI models. Anonymization and pseudonymization protect personal data by reducing breach risks and limiting the impact on individuals in case of a data exposure.
• Access control: Implement strict access controls and monitoring to ensure only authorized personnel can access personal data. This prevents unauthorized exposure of sensitive information.

By embedding these practices into AI development pipelines, organizations can take meaningful steps toward compliance, trust-building, and ethical AI deployment.

Ensure security and privacy by design

Organizations should build user trust and meet regulations by embedding privacy from the start, not treating it as an afterthought. This is the core of the privacy by design principle under the GDPR.

Key steps include:

• Promoting user choice and control: Provide clear opt-out options before processing data—whether in email campaigns, mobile app popups, or web trackers.). Empower users with privacy dashboards that let them view, manage, and delete their personal data at any time.
• Secure data handling: Businesses must encrypt personal data used in AI training while transmitting and at rest. Implement strict access control mechanisms to ensure that only authorized personnel can interact with sensitive data.

Embedding privacy and security into system architecture from the outset not only ensures compliance, trust-building, and ethical AI deployment.

Maintain ongoing communication and feedback loops

Transparency shouldn’t stop at data collection. When introducing AI processing, update your privacy notices to reflect new processing activities, as required by the GDPR. Use layered notices to highlight AI-specific practices like model training, profiling or automated decision-making. Importantly, inform users before processing, not after. True consent means giving people a real choice. Building feedback loops as user input is essential for improving fairness, spotting issues, and building trust in your AI systems.

Conclusion

As AI continues to shape modern business, respecting data subject rights is not just a legal obligation; it’s a foundation for responsible innovation. By embedding privacy by design, adopting transparent data practices, and enabling user control, organizations can align AI development with GDPR principles and foster long-term trust. Data protection isn’t a compliance checkbox, it’s a strategic imperative for ethical and sustainable AI.

Feel free to reach out to us for any clarification of AI compliance needs.

The post Respecting Data Subject Rights in AI: A Practical Guide for Businesses appeared first on TechGDPR.

Privacy by Design (PbD) is crucial here. We cannot shy away from saying it’s a good idea, but framing it as ‘critical’ is much closer to the mark. Dr. Ann Cavoukian’s developed framework is integral to embedding privacy in AI infrastructures. It is important to understand how AI developers can infuse PdD into reality alongside explaining the reasoning behind the importance of preserving user privacy.

Understanding PbD starts from the foundation of believing that privacy comes when the service is not looking for or pre-configured by users, but instead set as a default feature.

Understanding Privacy by Design: Principles at the Core

Privacy by Design is based upon the notion that privacy should be the natural default and not an optional feature one must find or switch on. Instead of responding to privacy violations, PbD has companies anticipate them and prevent them from occurring in the first place. Its seven design principles are not idealistic goals; they are pragmatic recommendations for integrating ethical data handling at every stage of the design process.

Picture Privacy by Design as building privacy into a cake rather than sprinkling privacy on top as sprinkles. PbD is an innovative approach to building privacy into systems in the first place.

Here are the seven main principles in more detail:

1. Proactive not reactive; preventive not remedial: Anticipate risks before they arise. Don’t wait for a breach to act.
2. Privacy as the default setting: Individuals shouldn’t have to request privacy. It should be automatic.
3. Privacy embedded into design: Build systems that make it impossible to forget privacy because it’s built in, not added later.
4. Full functionality by being positive-sum, not zero-sum: Achieve both privacy and innovation; one shouldn’t come at the expense of the other.
5. End-to-end security and lifecycle protection: Protect data from the moment it’s collected until it’s deleted.
6. Visibility and transparency: Systems must be open to inspection, review, and explanation.
7. Respect for user privacy: Keep the user at the center with simple controls and clear, honest communication.

The Unique Privacy Challenges in AI

AI is different from typical software. Its reliance on enormous collections of data and capacity to infer sensitive material from ostensibly harmless points of data make it highly invasive. Voice, text, image, or behavior-trained models can identify not only user tendencies but mood, political orientation, or state of health as well.

This poses a sequence of privacy threats:

• Over collection: AI is starved for data, and therefore developers overcollect.
• Inferred data: Models have the ability to make truly excellent predictions, often more than what users have expressed in so many words.
• Opacity: Most AI models are “black boxes,” where even the developers aren’t necessarily sure how the decisions are being made.

Ignoring privacy can result in:

• Fines and lawsuits under legislations such as the GDPR, the EU AI Act and the CCPA.
• Loss of customer and user trust.
• PR disasters that bury your brand.

Good privacy is not only good business, but good ethics as well.

Best Practices for Integrating PbD in AI Development

In order to design Privacy by Design properly for AI systems, developers need to be strategic as well as practical. Below are crucial steps to follow:

1. Begin with Privacy Impact Assessments (PIAs): Before creating anything, perform a PIA to discover privacy threats and analyze how your AI system processes information. This way, threats are identified and addressed upfront, instead of once it is deployed. Begin your AI project by questioning: 

• What information is required? 
• What are the threats? 
• How are users safeguarded? 

2. Adopt data minimization and purpose limitation: Collect data only if it’s needed to accomplish a precise, well-defined purpose. This minimizes risk and simplifies handling of privacy obligations. Refrain from the temptation to “collect now, decide later.”
3. Take advantage of privacy-enhancing technologies: Differential privacy adds noise to statistics, preventing data tracing back to individuals. Federated learning learns models on user devices, reducing central data aggregation. These technologies maintain utility while keeping user identities secure.
4. Encourage transparency and explainability: Transparency does not solely involve open-sourcing code but more importantly explaining in simple terms how the system functions, what information is used, and what the model is deciding. Interpretation of models and tools such as model cards can assist.
5. Ensure secure access and data encryption: Both in transit and at rest, data should be encrypted. Controls on access must be strong, restricting access to data by role and need. Regular audits should be performed to ensure compliance.
6. Build ethical oversight: Develop cross-disciplinary review boards consisting of technologists, legal specialists, ethicists, and community members. Such bodies can review projects for privacy, fairness, and unintended effects.
7. Design for user empowerment: Provide users with the ability to see, control, and remove their information. Provide privacy controls that are understandable and accessible. Opt-in is the norm, not sneaky default options or unclear text.

Lessons from the real world

Let’s see who’s doing it right and who didn’t:

• Apple has been a leader in on-device computing and differential privacy. Their health features, for instance, store personal data locally and anonymized.
• Google applies federated learning in its Gboard keyboard to allow for predictive text without ever transmitting what users are typing.
• But Clearview AI and Cambridge Analytica are cautionary tales. They were firms that did not respect user privacy and lost lawsuits, penalties, and long-term public distrust.
  • Clearview AI scraped billions of images without permission and was met with worldwide outrage.
  • Cambridge Analytica harvested Facebook data for political campaigns and sparked worldwide alarm about AI and privacy.

The Trade-Offs and Challenges Ahead

With the best of intentions, it’s hard to implement PbD for AI. There are compromises:

• Data minimization vs. performance: Data about people can restrict how much data you process, which can have an impact on model performance because lower numbers of data points can result in lower-performing models.
• Anonymity vs. fairness: Reducing bias relies on demographic information, which introduces new privacy issues. To be fair, there is often a requirement for data on race or gender, which is sensitive.
• Technical expertise: Federated learning or differential privacy is required to utilize these, which calls for expert know-how as well as computational resources.

These are challenges that are worthwhile overcoming. With privacy as a competitive advantage and a legal requirement, businesses embracing PbD will be far ahead of their competitors for long-term achievement.

What’s coming next?

Regulations are solidifying. The EU AI Act and other initiatives are establishing new norms. Meanwhile, technologies such as homomorphic encryption (so computation can be performed on encrypted information) and synthetic data (which simulates real data without revealing real users) are opening up new paths for privacy-led innovation. These technologies will help AI developers to prioritize how to create systems that safeguard people.

As AI reshapes society, privacy must not be treated as an afterthought. It’s a design choice that reflects an organization’s values, foresight, and respect for its users. Integrating Privacy by Design isn’t just about avoiding penalties; it’s about building systems that are ethical, resilient, and worthy of trust. If you’re building AI, you’re shaping the future. Make it one where people feel safe and respected. By using Privacy by Design, you’re not just avoiding trouble; you’re building trust, improving outcomes, and showing users you’ve got their back.

Every line of code and every product decision is an opportunity to do better. Start now. Make privacy the foundation, not the fix.

The post How to build trustworthy AI from the ground up with Privacy by Design? 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.

GDPR compliance as a market differentiator 

Companies serious about GDPR compliance understand its role in maintaining their market position. Those who are proactive are quicker at placing themselves on a purchaser’s list of adequate suppliers. When processing data from people in Europe, the GDPR applies. It forces an organization to implement measures and maintain records of compliance. Even if an organization is not currently processing that data, building in regulatory compliance early supports future collaborations and partnerships with larger organizations and ensures the trust of product users.

Regardless of whether a software developer operates in a B2C, B2B or B2B2C context is irrelevant. The processing of personal data anywhere on that chain of services needs to comply with GDPR requirements. Thus achieving and maintaining compliance allows an organisation to be a supplier that implementing clients consider. For instance, a software developer for a small start up is able to integrate fundamental privacy by design and default principles in their design. This includes practices such as implementing end-to-end security, hashing, and other cryptographic measures.

Transparency makes the product more competitive if it is to be implemented through partnerships or sold as a SaaS. Procurement negotiations might still bring up specific questions and feature requests to be added to the agreements your organization signs as a vendor. By prioritizing compliance, any solution developed is more likely to remain on the list of suppliers worth considering especially if the negotiation deals with business in the EU. Implementing privacy preserving design features allows an organization the competitive edge of transparency.

Major fines

Tech giants, Facebook, Google and Amazon, regularly face severe fines for non compliance. These fines are essentially caused by deliberate ambiguity in their data processing and the fulfillment of their transparency requirements. Worse, they disregard their data controller obligations and get fined for a combination of hidden processing practices and implemented dark patterns. In May 2023, Meta, was hit with a 1.3 billion euro fine for lack of GDPR compliance. This is the largest fine to date. Amazon was fined for 746 million in 2021 for lack of user consent collection when advertising. When companies get fined, several factors come into play. This could potentially include their willingness to cooperate and implement corrective actions. However, a constant factor includes lack of transparency, misleading patterns and a lack of legitimization of processing.

However, most businesses are small-to-medium-sized enterprises (SMEs). This term is technically defined by the European Commission as a company with less than 250 employees. For an SME, GDPR compliance is harder to achieve due to proportionally reduced resources or access to expertise. Therefore, if an SME is able to achieve compliance, they recover the competitive advantage over larger players lost on operational costs. Tech giants are consistently pressured to maintain compliance due to their increased visibility. Therefore, compliance, when managed efficiently, is a defining competitive advantage for smaller companies.

GDPR compliance as a political or social issue 

When tech-savvy individuals go online, they tend to protect their own privacy by using strong passwords. Some examples of this includes increasingly using MFA where available or using pseudonyms and single use email addresses where possible. With the help of a few high profile breaches and updates to app marketplace practices and communication strategies, the average user has become more aware of the online privacy risks. Software developers tend to implement best security practices in their own use of software and apps. As a result, they are particularly best suited to understand the need for security. They are also specifically instructed to implement strong security practices and privacy design patterns such as content security policies for websites. As creators of technology, software developers have an ethical responsibility to protect the privacy of individuals and empower them to use their software or services more privately. 

Through implementing best design practices such as the minimization of cookies, the forced use of MFA, the encryption of user data, a privacy by default approach to design, designers create privacy-preserving environments. While the expectation might be that less tech-savvy individuals are likely to show relative indifference about their own privacy, one study entitled Caring is not enough: the importance of Internet skills for online privacy protection, argues that even if people do care they also need to be educated on how to protect their own privacy. It is not uncommon to feel helpless protecting one’s own data or safely using the internet. Typically, a lot of the burden for security falls, wrongfully, on the individual.

Should the average user be expected to know how to make use of encryption to feel safe online? 

For many, cookie banners are annoying interfaces, easily brushed away by clicking the “Accept all” button. Configuring a cookie banner to not set non-essential cookies by default, makes the organization compliant on that requirement. It also provides users with a choice. Amongst other principles, privacy by default also requires the developer to ensure the most private settings are set by default. Software designers, familiar with ePrivacy requirements, are able to notify the marketing team that silent opt-ins is illegal in the EU. This allows the organization to engage in discussions as to whether to design for compliance or to accept the risk. In accepting the risk, an organisation increasing user distrust for the benefit of tracking, profiling and advertising KPIs.

As digitization continues, there is a pervasive use of selling user data or mishandling personal information in the tech field. This trend occurs without much regard to the significance of this action. This has become regretfully normalized even though it is against the GDPR. This is likely due partially to many companies solely operating within the US. At the moment, the US does not have a federal governing law similar to the GDPR. Regardless, this precedent is pervasive.

People should have the right to use and access the internet and software related tools/services without being seen as a commodity. Through the use of tracking elements and abuse of consumer metrics, individuals are becoming commodified and sold as such. This should not be the case where individuals can be so easily manipulated and tracked through their actions online. When software developers prioritize GDPR compliance, they are able to help prevent the commodification of individuals by their company. 

GDPR compliance in software development as an intellectual challenge

It is easy to do things in a non secure manner. It would be easier to access one’s phone to text people if one didn’t have a password, but most individuals likely have a password on their phone to protect from strangers accessing the content on their device. Therefore, the easiest solution is not always the best solution. This stems from the common dilemma of convenience versus privacy that one is confronted with daily. Instead of seeing this as an issue, one should frame it a challenge. If one views compliance as an intellectual challenge of how to protect others, the issue becomes more intriguing and fun to solve. An issue bears the connotation of an obligation or nuisance. 

Individuals are motivated to do things either intrinsically or extrinsically. When a supervisor informs a developer that they must make the system compliant with the GDPR, that would be the definition of an extrinsic motivator as it is external; however, intrinsic motivation is a powerful and compelling motivator. Due to intrinsic motivation, this is part of the reason as to why computer games are fun to learn.

An intellectual challenge has a better and more enthralling connotation. This idea has been theorized since the 1950s and academics have postulated through research that intrinsic motivation is correlated with how challenging the activity is. Considering those who have a background in computer science are confronted with technical issues and problems to solve all the time, compliance is best viewed as an intellectual challenge to avoid the easiest solution but create the most secure solution. 

Concluding thoughts 

Compliance is the law. As a software developer, one will likely need to work to implement or maintain compliance with the GDPR. It is easy to see it as a tedious endeavor handed down to a higher up, who might not necessarily understand the ramifications of the technical assignment they are bestowing. Instead, one should view the GDPR through an intrinsically motivated lens as an intellectual challenge to protect the rights of individuals. There are other reasons as to why as a software developer one should care about the GDPR. This includes but is not limited to securing contracts and helping others with less knowledge of proper internet privacy practices.

The joy of the internet and technology should be able to benefit and be enjoyed by all individuals. Any individual regardless of their technical background and without the fear of loss of rights. The question should not be: “does one engage with technology and in doing so give up their right to privacy?” but rather the burden should fall less on the technically ignorant users and be built into technology inherently. 

If you are interested in taking your GDPR knowledge to the next level, dive into TechGDPR’s specialized training for developers. This course is designed to equip you with the skills and understanding needed to navigate GDPR compliance within your projects. It will help you ensure your software is up to standard and gain a competitive edge. Discover more and enroll today at GDPR for Developers – Online Course.

The post Why should software developers care about GDPR compliance? appeared first on TechGDPR.

Taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing, the controller shall, both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organisational measures, such as pseudonymisation, which are designed to implement data-protection principles, such as data minimisation, in an effective manner and to integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects.

Essentially, data controllers need to consider data protection throughout the core of their organisational activities. As such, those who work to create technologies involved in data processing must consider the implications of their software in the context of the GDPR. While Data Protection by Design and Data Protection by Default are separate concepts, they are complementary. Implementing Data Protection by Design makes achieving Data Protection by Default much easier, with the reverse being true as well.

Building privacy into the heart of data processing operations and systems is part of Privacy by Design, while ensuring that the data subject’s rights are protected as a matter of standard operations is part of Privacy by Default. These concepts have been in existence since long before the GDPR came into fruition, but under the GDPR became important requirements. 

Achieving Privacy by Design and Privacy by Default is not a simple process when one’s main focus is developing and delivering products. As such, familiarity is of the essence. 

What are the most important considerations involved with these concepts, and how may data processors implement them? 

What is Privacy by Design? 

The concept of Privacy by Design was created by Ann Cavoukian in the 1990s and presented in her 2009 “Privacy by Design: The Definitive Workshop.” As Cavoukian stated, the concept of privacy by design encompasses more than just technology. Rather, Privacy by Design dictates that privacy is taken into account throughout the design process and operations of broader organisations and systems. There are seven foundational principles which constitute the basis of Privacy by Design:

1. Measures are proactive rather than reactive. They anticipate risks and try to prevent them from occurring, rather than allowing for invasions of privacy and minimising them after the fact. These measures are woven into the culture of an organisation. 
2.  Privacy is protected by default. Personal data is protected without requiring the data subject to act. In practice, the most intrusive privacy features of an app, such as geolocation tracking when that is not called for by the user, are turned off when the product is first installed or better yet, every time the app is launched.
3. Privacy is embedded into the design of systems and organisations. It is not an afterthought, but an essential part of a system’s functionality.  Designing for privacy can be quite costly so planning for it rather than redesigning to accommodate it, is a wise cost management strategy.
4. Privacy is not implemented to the detriment of other interests, but rather to accommodate all legitimate interests with full functionality. 
5. Privacy is extended throughout the lifecycle of all the data collected.  
6. Data processing activities are visible and transparent. The business practices and technologies involved are clear to both users and providers.  
7. Measures for privacy are user-centric: the interests of data subjects are at the forefront of operations. 

Cavoukian stresses that ensuring privacy does not come at the cost of other critical interests, but rather ought to complement other organisational goals. 

But how does a team implement these foundational principles into their technological design?

Methods of Implementing and Measuring Data Protection by Design for Technology Developers

The European Data Protection Board adopted guidelines for Data Protection by Design and by Default on 20 October 2020. These guidelines clarify how to implement the requirements of Article 25 in organisations that process personal data. 

Certain concepts, such as pseudonymisation, noise addition, substitution, K-anonymity, L-Diversity, T-closeness, and differential privacy, can help increase the privacy of an individual data subject, or give key information about the privacy of a data set. As a result, individuals working to achieve Privacy by Design should think about these methods as tools they can use, though not as absolute methods in and of themselves. 

• Pseudonymisation replaces direct identifiers, such as names, with codes or numbers, which allows data to be linked to an individual without the individual themself being identified. This data is still within the scope of the GDPR. Truly anonymous data is not considered personal data, and thus its processing does not fall under the scope of the GDPR. However, anonymous data, that is, data which cannot be linked back to a data subject, is different from pseudo-anonymous data in that pseudo-anonymous data has the potential to be re-linked to a data subject, even if in a difficult or indirect way. Thus, pseudo-anonymous data is still subject to the requirements of the GDPR. 
• Noise addition is often used in conjunction with other anonymisation techniques. In this technique, attributes which are both confidential and quantitative are added to or multiplied by a randomised number. The addition of noise still allows for the singling out of an individual’s data, even if the individual themself is not identifiable. It also allows for the records of one individual to be linked, even if the records are less reliable. This linkage can potentially link an individual to an artificially added piece of information. 
• Substitution functions as another method of pseudonymisation. This is where a piece of data is substituted with a different value. Like the addition of noise, substitution ought to be used in conjunction with other data protection measure in order to ensure the data subjects’ rights are protected. 

Means of measuring the privacy of data 

• K-anonymity, a type of aggregation, is a concept that is based around combining datasets with similar attributes such that the identifying information about an individual is obscured. This helps to determine the degree of anonymity of a data set. Essentially, individual information is lumped in with a larger group, thereby hiding the identity of the individual. For example, an individual age could be replaced with an age range, which is called generalisation. By replacing specificity with generality, identifying information is harder to obtain. Suppression is another method of achieving better k-anonymity. This is where a certain category of data is removed from the data set entirely. This is best-suited in cases where the data in that category would be irrelevant in regards to the purpose of the data processing. It is important to note, however, that k-anonymity itself does not guarantee that sensitive data will be protected. 
• L-diversity is an extension of k-anonymity. It provides a way of measuring the diversity of sensitive values in a dataset. Essentially, l-diversity requires each of the values of sensitive attributes within each group to be well-represented. In doing so, l-diversity helps to guarantee that a data set will be better protected against re-identification attacks. This is a helpful consideration in cases where it is possible for attributes in k-anonymised data sets to be linked back to an individual.
• T-closeness expands on l-diversity and is a strategy of anonymisation by generalisation. T-closeness creates equivalent classes which are similar to the initial distribution of attributes in a data set and is beneficial in situations where a data set must be kept as close as possible to its original form. Like k-anonymity and l-diversity, t-closeness helps to ensure that an individual cannot be singled out in a database. Additionally, these three methods still allow for linkability. What l-diversity and t-closeness do which k-anonymity cannot, is provide the guarantee that inference attacks against the data set will not have 100% confidence. 
• Differential privacy aims to ensure the privacy rights of an individual data subject are protected by ensuring the information someone obtains from the output of data analysis is the same with or without the presence of the data of an individual. This allows for data processing without an individual’s information being singled out or the individual being identified. Differential privacy provides privacy through a specific type of randomisation. The data controller adds noise to the data set, with differential privacy revealing how much noise to add. 

Privacy Design Strategies

Researchers have identified eight privacy design strategies, divided into two groups: data-oriented strategies and process-oriented strategies. Data-oriented strategies include: minimise, hide, separate, and abstract. These strategies focus on how to process data in a privacy-friendly manner. Process-oriented strategies include: inform, control, enforce, and demonstrate. These strategies focus on how an organisation can responsibly manage personal data. Article 5 of the GDPR identifies the basic principles to follow when processing personal data: lawfulness, fairness and transparency, purpose limitation, data minimisation, accuracy, storage limitation, integrity and confidentiality. These principles help guide the strategies, which can be exemplified by the concepts and methods of pseudonymisation, noise addition, substitution, k-anonymity, l-diversity, t-closeness, and differential privacy. These methods and processes of measuring privacy should stand as part of larger efforts to work to implement data protection into the fabric of data processing operations. 

How can technology developers learn more about Privacy by Design and Default?

Data Protection by Design and Data Protection by Default are fundamental concepts to adhere to under the GDPR. Teams which keep these concepts in mind at every level of their organisations will keep the rights of data subjects at the forefront of their operations, and thus go further in working towards GDPR compliance. Technology developers have a special role in making sure that their products have the capacity to be used in a GDPR compliant manner, and thus should have extensive familiarity with these concepts. Those interested in learning more about GDPR compliance, from the perspective of what a technology developer should consider, can participate in TechGDPR’s Privacy & GDPR Compliance Course for Developers. This course delves into what individuals working in technology development need to know about data protection so they can better understand their own duties and responsibilities under the requirements of the GDPR. 

The post Privacy by Design for Technology Development Teams appeared first on TechGDPR.

Reaching a high level of compliance takes time. As with most endeavours that rely on change management (e.g. setting up a quality management system or an information security management system), staff training plays a crucial role in aligning operations with business goals. Documenting evidence of GDPR training goes a long way in objectively displaying the journey achieved to date.

Data Protection by Design and GDPR Training

The GDPR dictates that a company must weave privacy into the very fabric of a processing operations through the principles of Data Protection by Design and Data Protection by Default, outlined in Article 25 of the GDPR. As such, the individuals responsible for building the technology involved in data collection and processing must pay special heed to the fundamental principles of privacy. Finally, while software designers might not be the first line of defence in terms of achieving GDPR compliance, one could indeed see them as the last line of defence in this regard, and as such ought to be able to recognize the challenges and complexities involved in achieving GDPR compliance.

Thus, encouraging tech developers as well as software engineers and coders to engage in GDPR training achieves two goals for companies looking to enact strong GDPR compliance measures. It both enables designers to include legal requirements in the handling of data and documents company efforts in delivering compliant solutions as a vendor (data processor) or as an implementer (data controller). As Recital 78 of the GDPR states, 

When developing, designing, selecting and using applications, services and products that are based on the processing of personal data or process personal data to fulfil their task, producers of the products, services and applications should be encouraged to take into account the right to data protection when developing and designing such products, services and applications and, with due regard to the state of the art, to make sure that controllers and processors are able to fulfil their data protection obligations.

GDPR and Technology Neutrality

Though there are debates as to whether or not the GDPR prevents the development of advanced technology, the GDPR was not created with the intention of stifling technological innovation. An important feature of the GDPR is that it is technologically neutral, meaning that it does not discriminate between two different technologies with the same functionality or between existing and new technologies. Though its technological neutrality makes the GDPR a much more effective and widely applicable piece of legislation, it also makes it quite a bit more difficult for developers to implement.

Rather than regulating technology itself, legislation regulates only the effects of technology use and the conditions surrounding the actual processing. In essence, the GDPR does not offer specific guidelines for compliance for those developing technology. The GDPR was created to apply to technological developments taking place after its coming into force, so it is up to those developing technology to make sure that their work supports GDPR compliance. 

What challenges do developers of data processing technology face in GDPR Compliance?

New technology brings unique challenges under the GDPR. This is the case with IoT, blockchain, cloud computing, and artificial intelligence. Certain aspects of each of these might, at first glance, appear to be inherently incompatible with GDPR compliance. Since it is always best not to ignore the law, the development of new technology must take data protection into special consideration. GDPR training thus becomes a market differentiator for these organisations. Awareness of the available data subject rights, as well as the obligations of the data controller and data processor, is necessary to prevent incompatibilities between legislation and feature developments.

GDPR compliance is a complicated, though necessary, endeavour. Given that organisations are required to adhere to the principles of Privacy by Design and Privacy by Default along with the core data protection principles, developers need to consider data protection at every phase of the design and development process. In order to develop products that have the potential to be used in a GDPR-compliant way, employees need to comprehend the rights of data subjects and the obligations of the data controller and the data processor which the GDPR outlines.

Without an adequate knowledge of GDPR requirements, it is impossible for individuals or teams to implement the necessary measures to ensure an adequate protection of data subject rights. Awareness of the challenges behind GDPR compliance and the possible conflicts between data protections and certain technologies, achieved through GDPR training, is a fundamental first step towards solving these issues and creating products and organisations that thoroughly protect the rights of data subjects. 

While compliance and GDPR training for employees are no simple tasks for an organisation to undertake, especially fast-developing fields of technology, there are many resources available to help staff understand and best implement GDPR-appropriate measures in their respective roles. One of the most convenient ways for companies to train their technical staff on the GDPR is through the use of an online course. 

TechGDPR has created a unique GDPR training online course specifically for individuals working in technical roles, such as software developers, software engineers, devops, software architects, and more. This course will help clarify the GDPR requirements for technology developers and give them the tools they need to achieve GDPR compliance within their organisations and products.  Though the GDPR does not outline specifications for training requirements in this regard, the extensive requirements of the Regulation and the principles of Data Protection by Design and Data Protection by Default mean that creators of data processing technology help methodically consider which requirements apply and navigate them autonomously. 

The post Why is GDPR training important for technology teams? appeared first on TechGDPR.

Why do GDPR assessments on AI matter?

If you are a company, regardless of size, that already implements, or wishes to introduce, AI tools or apps into the workplace that interacts with humans without carrying out an in-depth assessment that evaluates risks, acquiring both foreseen and unforeseen penalties, then your company may face penalties. Foreseen risks are fairly obvious risks the company did not take necessary and obligatory steps to prevent them from becoming heightened security threats. Unforeseen risks result from a company not carrying out a Data Protection Impact Assessment (DPIA), or not assessing the technology in-detail through human oversight/intervention on the individual level; thus allowing some form of negligence to creep in. This would result in several GDPR violations such as impacting the rights and freedoms for data subjects (Article 12-22), which would otherwise have been averted by privacy by design. It is nearly impossible to assess and predict all risks; however,the objective is more that of displaying user-centricity rather than runaway enthusiasm for the capabilities of the technology thus enabling trustworthy AI with the users. 

Risk assessments by product designers that objectively surface risks for the data subjects are particularly challenging -a reality legislators did not ignore. To that effect, the need to assess technology from the perspective of the data subject (as embodied in Art.35.9’s requirement to solicit the views of the individuals whose data will be subjected to the technology) illustrates the intention to provide for a feedback loop in product design, the same way designs are tested on consumers in market research for example.

GDPR Fines related to Artificial Intelligence 

In May 2021, the Spanish data protection Authority (AEPD) imposed two fines totaling  €1.5 million against EDP ENERGÍA, SAU under articles 6, 13 and 25. One of the key elements in the fines was how DPA based their decisions on the infringement of Articles 6 and 22 were instrumental to the infringement of Article 13. Recall the HR example mentioned above, imagine your HR department not vetting apps or tools being introduced through candidate applications that do use AI capabilities Did your department inadvertently discriminate against potential candidates, thus eradicating a central purpose of HR -that of promoting and sustaining diversity in the workplace. In 2018, Reuters reported that Amazon’s new recruiting engine excluded women from the candidate pool. As a result, the system learned to disqualify anyone who attended a women’s college or who listed women’s organizations on their resume. Amazon has since scrapped and implemented a more “water-down” recruitment system, however, AI in Human Resources is expected to grow. Ultimately, and more concerning, the company has violated anti-discrimination laws which in turn, exposes the company to penalties. Under the GDPR, these penalties range from a simple order to alert the processing to being barred from processing data and or being fined. 

Therefore, the disadvantages of not putting in the ground work to ethically evaluate tools that may or may not have AI capabilities likely incurs high costs, lack of trust among your employees and company reputation at stake for further partnerships. 

Why ethical assessments are essential for GDPR compliance

To be, or not to be ethical?

One may not always know how to scope ethical questions in today’s world of big data, data collection, AI and ML capabilities; i.e. what is intrinsically right or wrong in regards to collecting large amounts of data, or health data concerning children for example? Today, many private or public organizations -including governments- understand the stakes of considering ethics and its importance in data collection and utilization. The GDPR further embeds ethics into law within the EEA. The GDPR safeguards the rights and freedoms of data subjects by keeping organisations in line with data protection, privacy and ethics. This is notable for instance in the requirements of GDPR Art.5.1.a, lawfulness, fairness and transparency and Art. 5.1.b. purpose limitation providing for a heightened requirement to communicate and to align the processing to what is expected by the subject, what is necessary to the processing. The principle of privacy by design mentioned previously is however introduced by the GDPR in Article 22 and Recital 71. 

The European Commission introduced a proposal for an EU regulatory Framework on artificial intelligence (AI) in April 2021. The Framework will be a complement to the GDPR’s regulation of AI in Articles Art. 13 , 15-22, 25, and 25 and intends to focus on specific utilisation of AI systems and associated risks. Waiting for it to be published and come into force is however not the recommended approach. Investing years into product development only to find out that the product will need to be overhauled to satisfy data protection requirements prior to its release will prove dramatic. Tell-tale signs of this happening occur when co-innovation partners start pulling out of discussions. Here at TechGDPR and in preliminary discussions we have, albeit rarely, come in contact with products that are ethically questionable or intrinsically at odds with data protection. With a sharp eye for the current and future trends in regulation, we help innovators understand where their products require consolidation.

As a proactive start, consider the available assessment checklists created by supervisory authorities to guide private and public organizations, to ethically assess tools and their AI features. 

Can AI comply with privacy by design requirements?

AI technology and machine learning requires large amounts of data to even function or bring out a workable algorithm. A strong proposition of the technology is its use of data lakes in innovating ways. From the outset this is at odds with data protection law that requires any processing to have a stated purpose before it is performed.

One can argue there is not an explicit law nor regulation enacted that fully clarifies  how companies can assess a tool’s ethical footprint. Be that as it may, the duty remains for companies to ensure Privacy by Design under the GDPR. Checklists and assessment methodologies abound, created to guide organizations to assess tools and their AI capabilities. 

We recommend product teams to start early and take a proactive role by engaging their DPO, data protection, legal, IT and information security teams.

The post Artificial Intelligence and Privacy by Design appeared first on TechGDPR.

In my opinion, however, this needs to be seen with more nuance, and as lawyers like to say, it all depends on the specific circumstances; blockchain is not always strictly immutable, the right to be forgotten is not absolute, and the definition of personal data is still not 100% clear. If you look past the headlines and dive into the details, you will see this situation is not that black and white.

1. Blockchain is not always strictly immutable

Already in the very first paper on blockchain, “Bitcoin: A Peer-to-Peer Electronic Cash System” by Satoshi Nakamoto, there was the notion of pruning: “Once the latest transaction in a coin is buried under enough blocks, the spent transactions before it can be discarded to save disk space.” Meaning even in the first-generation protocol of Bitcoin, there is a technical method to delete certain data from the chain. So far, this has not been implemented, but there is a methodology to achieve this without breaking the system. Obviously in this particular way, a node operator could still choose to maintain all data that ever comes across, so in practice this may not with with Bitcoin unless additional safeguards to guarantee this are being put in place.

With later-generation protocols, such as with EOSIO, there is more sophisticated governance in place. By designating certain block producers who could, based on a constitution, agree to remove certain data, or mutually agree to block access to certain data for the outside. Even though this may limit transparency and centralizes some of the decision making, this may still be a feasible solution for certain use cases. For example Europechain aims at setting up networks with only EU/EEA block producers that are all under a Data Protection Agreement (DPA), specifically to offer a GDPR compliant way in which blockchain can be used while keeping most of the advantages of using blockchain in place.

Immutability can for certain purposes be very valuable, but for Personal Data it may not be ideal.

2. The right to be forgotten is not absolute

The right to be forgotten if often cited as the holy grail of protection your personal data, but it can not always be applied. According to Article 17, it can for example be used under the following circumstances:

• Personal data is no longer needed for the purpose, for example, if it was processed for the provision of a contract (Article 6.1(b)), but the contract has been cancelled or has expired.
• It was processed under consent (Article 6.1(a)), and the consent has been withdrawn.
• It has been processed under legitimate interest, but the legitimate interest has been challenged and no overriding interests prevail.
• The processing was unlawful in the first place.

The right to be forgotten does for example not apply if the processing is (still) necessary for the performance of a contract, for scientific or historical reasons in the public interest, to comply with a legal obligation, or if the legitimate interest continues to overrule the interest of the data subject.

If a controller has made personal data public, and publishing on a public blockchain should be seen as making public, they are required to inform others who are processing the data that is should be deleted. It’s an interesting question how that should work in a distributed environment with public actors, but this is not impossible.

3. The definition of personal data is still not 100% clear

In blockchain environments clearly readably personal data should not be used. In particular within public permissionless blockchains there is no good reason to do so. Most projects resort to storing hashes of information or transactions on-chain to prove certain things off-chain. Depending on the circumstances, such hashes could be considered pseudonymous or anonymous. Pseudonymous data is still in-scope of the GDPR, and should therefor adhere to it, anonymous data is out of scope. What exactly is to be considered pseudonymised following a specific approach, and therefor in scope of the GDPR, was previously (before the GDPR) explained in Opinion 2014/05 of the Working Party 29 (WP216). However, this has not been formally adopted by the EDPB. This makes it a lot harder to establish if, for example hashed information is pseudonymous or anonymous from the perspective of the GDPR.

Is the right to be forgotten in blockchain really a problem?

Well yes. Very often, there are certainly potential problems with storing pseudonimysed personal data in a blockchain, however one should be looking at the particular circumstances: which source-data is pseudonimised, encrypted or hashed, where is it stored, and can it be related to other on-chain events, what happens if you delete the source-data, and how strong is the entropy?

To find solutions for this challenge, it is important to consider both the technical (immutability) and the legal (how absolute is the right to erasure?) aspects, and the overall situation. It will stand or fall with the small details, and because the GDPR is a new regulation and blockchain a new technology, it will always be a risky undertaking to deploy this ‘in the wild’.

The only way in which this challenge can be approached, is through Privacy by Design: ensuring all privacy controls are implemented right from the start, and making sure products, protocols and their apps and UX are designed in a privacy friendly way. Launching an immutable system with privacy weaknesses that are not fully thought through, and documented, is quite clearly a violation against Article 25 of the GDPR on Data Protection by Design and by Default.

The post GDPR’s Right to be Forgotten in Blockchain: it’s not black and white. appeared first on TechGDPR.

Cold calling individuals is like throwing a rock in a pond with the hope of catching a fish. Obviously, the success rate is high enough to justify manning the phone with a single person all the way up to outsourcing a floor’s worth of call center advisers. But how can you continue making cold calls when you have purchased personal data?

With lots being said about the GDPR signalling death of sales and marketing as we know it, it’s hard to make sense of how much room remains for your organisation to call up an unsuspecting prospect in a compliant way. While you can’t avoid raising suspicion as to where the data subject’s number originated from, there is a wide spectrum of practices ranging from downright non-compliance data collection to the fully-fulfilled duty to inform. Though it is limiting to approach the Regulation with a single use case it remains the best way to avoid opening the floodgates to exceptions. For the purposes of this post, I’ll cite the following example:

Can personal data be sold and bought under the GDPR?

Inheriting personal data sets from a third party with no proper documentation (e.g.: legal basis for initial collection, records of the duty to inform being fulfilled by the initial controller, recorded consent or readily available consent matrix) is a liability for both the personal data broker and the purchaser. At the very least, records of processing activities should establish a trace of the transaction since personal data sold to a third party is a data transfer to a recipient. Additionally, your organisation will need to prove that subjects were informed this transfer would take place or that you informed them within a month of purchasing their personal data that your organisation now processes it. More on this further on. 

Failing to document what information was communicated and what legal base apply violates both the data protection principles of lawfulness and transparency and that of purpose limitation, exposing you to the heaviest of fines: 4% of annual turnover. If your organisation had purchased personal data from a third party source, don’t hide that information. Should your staff turn down a data subject request to know what the origin of that data is, make sure the staff has been trained to recognize the request as a genuine data subject request. Article 14.2.f) makes it compulsory for organisations to inform data subjects if requested as to the source of the data that was not collected from them directly.

The worst scenario on your call-center floor is for an agent to downplay that request and respond that the subject’s phone number was communicated by their line manager. You may need to review your processes, knowledge base and staff training as to how to handle data subject requests. You would be surprised how many people use built-in or third party app call recorders on their phones

While you can sell and purchase personal data, you have to be very clear about it. Unlike the CCPA, the GDPR does not make it a requirement to disclose that the data will be sold, instead it makes it a requirement to disclose who will be receiving it.

In that respect, the CCPA more explicitly acknowledges the commercial uses of personal data. It makes it a requirement to disclose such uses, to provide subjects to opt their data out of the sale. To that respect, it allows for slightly more traceability in the data supply chain than the GDPR does. Keep in mind that small print at the end of a 10-page privacy policy will not impress authorities. Requirements of concision and clarity can be found in Article 12.1.

Can our organisation cold call data subjects?

Yes, it can.

Central to data protection is your duty to inform. Fulfilling it puts your organisation in line with GDPR’s principle of lawfulness, fairness and transparency (GDPR Art.5.1).

It is likely that the applicable legal basis for processing personal data in your case is legitimate interest. Yet having determined an applicable legal base is not compliant unless the purpose and the legal base are formally communicated to the data subject.

Can data subjects refuse to be the target of your direct marketing?

Yes, under Article 21.1 of the GDPR, an individual has the Right to Object. While, typically this right designed to put the burden of proof on the controller that its processing of personal data is done in the controller’s legitimate interest, the data subject also has the right to outright object to the use of data for direct marketing. This means that your company will have to mark the personal contact data to prevent it from being used for that purpose. This is one of the only technical and organisational measures explicited in the GDPR. Apply it if the data is nonetheless required to serve other purposes such as the performance of a contract. Should the data serve no other purpose, the best practice principles of data minimization and purpose limitation dictate the complete deletion of the personal data.

As hinted above, do not expect the data subject to officially formulate a deletion or objection request via your data protection officer. Treat their request on the phone as officially as you can. Which naturally increases expectation on staff compliance training.

Must I perform my duty to inform during the call?

Where the CCPA does not makes it compulsory for organisations to disclose having transferred or sold their data unless the subject requests to know, the GDPR makes it a requirement to inform proactively about the transfer of personal data to a third party or recipient.

While a strict reading of the GDPR might lead you to believe that you should read your complete privacy policy on the phone, in reality the situation is not that extreme but needs to be broken down at little.

If, prior to the call, you have collected the contact information from the data subject, you will have already informed them, and collected consent (if such is your legal basis), on the purpose of processing. On the call itself, you might be inclined to remind the data subject of the legal base on which you are currently operating but there is no GDPR provision making this a requirement other than building trust and plain courtesy.

If you have not collected data from the data subject but amassed their contact details from a different source, or third party, then, you should inform data subjects of your full identity and contact details, what data you have collected, under what legal base(s) you have done so, what retention period governs that data processing and what rights the data subjects can exercise. GDPR. Art.14.3a) sets the duty to inform time frame to within a reasonable period after obtaining the personal data and no more than one month.

Should you place a call to the data subject before having informed them of the above, you should understandably be prepared to read this information out to them and facilitate the exercise of their data subject rights (GDPR Art.12).

A full list of elements your communication should include is available in Articles 12 to 14.

What if the data subject actually consents to their data being used when on call?

Technically, you could record the call to document consent but consent for that form of data collection -audio recording- would first be needed. Recording a call is nothing short of collecting biometric and personal data and, in many cases, transferring that data to servers or cloud services across the Atlantic. If your cloud provider is not listed under the EU-US / Swiss-US Privacy Shield and no other legal instrument allows for that transfer, the call recording would fail the compliance test on many levels.

A best practice often witnessed involves sending an opt-in email immediately after the call which recaps the essence of your phone conversation, what you agreed to share, the data the subject consented to disclosing and which were the purposes stated. You might want to consider including the date at which the conversation took place in the body of the text, i.e.: not relying on the email client’s automated time stamp.

Yes, your organisation can sell or purchase persona data and place cold calls.

The GDPR only prohibits both forms of personal data processing unless they are done unlawfully.
Unlawful data processing in the case of direct unsolicited marketing by phone is characterized by depriving data subjects of their rights, violating data protection principles of fairness, transparency and accountability, failing to inform them upon acquisition or collection of their data, depriving them of information when you first come in contact with a subject’s personal data and not supporting them in the exercise of their rights. If you have these items under control, you’re good to proceed with a fair degree of confidence in your compliance.

If you need help with reviewing your data protection practices, your data flows, your compliance documentation and call center staff or management training, get in touch.

TechGDPR specialises in digitised environments and products including AI, machine-to-machine / IoT transactions and Blockchain applications. We offer consulting packages, hourly support, staff training and workshops.

The post Personal data and cold calling under the GDPR appeared first on TechGDPR.

Alongside the excitement, there are concerns. Among them, is how to address data privacy and the concern between data privacy and artificial intelligence is most pronounced in the General Data Protection Regulation (GDPR).

The GDPR is designed to protect the privacy of EU citizens and give them more control over their personal data. It aims to establish a new relationship between user and system – one where transparency and a standard of privacy are non-negotiable. Artificial Intelligence (AI) is a set of technologies or systems that allows computers to perform tasks involving a simulation of human intelligence including decision making or learning. In order to do so, the technology or system collects voluminous amounts of data (called Big Data) and namely personal data. AI (especially Machine Learning [ML] algorithms) and Big Data go hand in hand, which has led many to question whether it is possible to use AI while still protecting fundamental personal data protection rights as outlined in GDPR.

Applying the GDPR to machine learning and artificial intelligence

The GDPR–a sprawling piece of legislation–applies to artificial intelligence when it is under development with the help of personal data, and also when it is used to analyze or reach decisions about individuals. GDPR provisions that are squarely aimed at machine learning state “the data subject shall have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her.” (Article 22 and Recital 71). Also noteworthy are Articles 13 and 15 which state repeatedly that data subjects have a right to “meaningful information about the logic involved” and to “the significance and the envisaged consequences” of automated decision-making.

It is clear that the regulation expects the technologies like AI to be developed while taking into consideration the following principles:

• fairness,
• purpose limitation,
• data minimisation,
• transparency, and
• the right to information.

The principles mentioned above are supposedly some of the major challenges facing AI to adapt to the new world of GDPR. The problem is because most of the machine learning decision-making systems are “black boxes” rather than old-style rule-based expert systems, and therefore fail to comply with the GDPR requirements of transparency, accountability, and putting the data subject in control.

Solutions and Recommendations to make Artificial Intelligence GDPR-friendly

Some data sets used to train AI systems have been found to contain inherent biases, which results in decisions that unfairly discriminate against certain individuals or groups. To become GDPR compliant, the design, development and use of AI should ensure that there are no unlawful biases or discrimination. Companies should invest in technical research to identify, address and mitigate biases.

One way to address bias in trained machine learning models is to build transparent models. Organizations should improve AI systems transparency by investing in scientific research on explainable artificial intelligence. They should also make their practices more transparent ensuring individuals are informed appropriately when they are interacting with AI and provide adequate information on the purpose and effects of AI systems.

With respect to data minimisation, the developers should start from carrying out research on possible solutions that use less training data, anonymisation techniques and only solutions that explain how systems process data and how they reach their conclusions.

There is need for privacy-friendly development and use of AI. AI should be designed and developed responsibly by applying the principles of privacy by design and privacy by default.

Organizations should conduct data protection impact assessment at the beginning of an AI project and document the process. A report by the Norwegian Data Protection Authority, “Artificial intelligence and privacy” suggests that the impact assessment should include the following as a minimum:

• a systematic description of the process, its purpose, and which justified interest it protects;
• an assessment of whether the process is necessary and proportional, given its purpose;
• an assessment of the risk that processing involves for people’s rights, including the right to privacy; and
• the identification of the measures selected for managing risk.

Tools and methods for good data protection in Artificial Intelligence

In addition to impact assessment and the documentation of the process to meet the requirements of transparency and accountability, the Norwegian Data Protection Authority report mentioned above includes tools and methods for good data protection in AI. These methods reportedly have not been evaluated in practice, but assessed according to their possible potential. The methods are divided into three categories:

1. Methods for reducing the need for training data.
2. Methods that uphold data protection without reducing the basic dataset.
3. Methods designed to avoid the black box issue.

1. Methods that can help to reduce the need for training data include:

• Generative Adversarial Networks (GANs) have the potential to advance the power of neural networks and their ability to “think” in human ways. It might be an important step towards inventing a form of artificial intelligence that can mimic human behavior, make decisions and perform functions without having a lot of data.
• Federated Learning is a privacy-friendly and flexible approach to machine learning in which data are not collected. In a nutshell, the parts of the algorithms that touch the data are moved to the users’ computers. Users collaboratively help to train a model by using their locally available data to compute model improvements. Instead of sharing their data, users then send only these abstract improvements back to the server.
• Matrix Capsules are a new variant of neural networks, and require less data for learning than what is currently the norm for deep learning.

2. The field of cryptology offers some promising possibilities in the area of protecting privacy without reducing the data basis, including the following methods:

• Differential privacy is the leading technique in computer science to allow for accurate data analysis with formal privacy guarantees. The mechanism used by differential privacy to protect privacy is to add noise to data purposefully (i.e. deliberate errors) so that even if it were possible to recover data about an individual, there would be no way to know whether that information was meaningful or nonsensical. One useful feature of this approach is that even though errors are deliberately introduced into the data, the errors roughly cancel each other out when the data is aggregated.
• Homomorphic encryption can help to enforce GDPR compliance in AI solutions without necessarily constraining progress. It is a crypto system that allows computations to be performed on data whilst it is still encrypted, which means the confidentiality can be maintained without limiting the usage possibilities of the dataset.
• Transfer Learning enables one to train Deep Neural Networks with comparatively little data. It is the reuse of a pre-trained model on a new problem. In other words, in transfer learning, an attempt is made to transfer as much knowledge as possible from the previous task, the model was trained on, to the new task at hand.

3. Methods for avoiding the black box issue include:

• Explainable AI (XAI) plays an important role in achieving fairness, accountability and transparency in machine learning. It is based on the idea that all the automated decisions made should be explicable. In XAI, the artificial intelligence is programmed to describe its purpose, rationale and decision-making process in a way that can be understood by the average person.
• Local Interpretable Model-Agnostic Explanations (LIME) provides an explanation of a decision after it has been made, which means it isn’t a transparent model from start to finish. Its strength lies in the fact that it is model-agnostic which means it can be applied to any model in order to produce explanations for its predictions.

The GDPR requires that technologies like AI and machine learning take privacy concerns into consideration as they are developed. With the GDPR, the road ahead will be bumpy for machine learning, but not impassable. The adoption of the measures and the methods discussed above can help to ensure that AI processes are in line with the regulation. These could also go a long way to achieving accountable AI programs that can explain their actions and reassure users that AI is worthy of their trust.

The post How to develop Artificial Intelligence that is GDPR-friendly appeared first on TechGDPR.