Executive Summary: The Dual Compliance Imperative and Strategic Findings

Organisations that leverage advanced data processing, particularly those developing complex Artificial Intelligence (AI) systems, face a critical and often unrecognized strategic risk: the prolonged retention of training data. European Union (EU) law establishes conflicting imperatives regarding data lifecycle management, creating a fundamental compliance challenge. The General Data Protection Regulation (GDPR) mandates personal data erasure as soon as the data is no longer required for its established purpose, while the newly implemented EU AI Act demands lengthy archival of system documentation.

The Inescapable Regulatory Conflict: Delete Now vs. Document for a Decade

The core of the conflict lies in the tension between personal data protection and system accountability. The GDPR is clear: personal data must be erased once its specific processing purpose is fulfilled. This is enforced by the Storage Limitation Principle (Article 5(1)(e)). Retention beyond this defined necessity, even if the data might be useful for future research or system retraining, is deemed a direct violation unless a new, distinct, and lawful purpose is established.

Conversely, the EU AI Act introduces stringent requirements for system traceability, particularly for High-Risk AI Systems (HRAS). Providers of HRAS must maintain comprehensive technical documentation, quality management system records, and conformity declarations for up to 10 years after the system is placed on the market (Article 18, EU AI Act). This requirement applies to system records, ensuring long-term accountability, but does not override the fundamental protection afforded to individuals’ data under the GDPR.

The GDPR Foundation: The “Storage Limitation” Principle 

The entire framework of data retention under EU law rests on the GDPR’s Storage Limitation Principle (Article 5(1)(e)).This foundational rule dictates that personal data must be kept “for no longer than is necessary for the purposes for which the personal data are processed.” This is the core principle driving all retention decisions.

The GDPR does not set generic retention times, instead placing the full burden on the data controller to define, document, and justify a specific deletion timeline for every category of data. If personal data (which is defined broadly to include information beyond PII, like cookie IDs) is used to train a system, the retention clock starts ticking. Organisations leveraging advanced data processing face a critical strategic risk: retaining training data for too long. The GDPR is unambiguous; personal data must be erased once its specific processing purpose. Retention beyond that, even for potential future research, is a direct violation unless a new, distinct, and lawful purpose is established.

Defining the Critical Strategic Risk for GDPR non-compliance

The strategic risk is precisely defined by failing to establish, document, and legally justify a specific deletion timeline for every category of personal data used in the training process. The absence of generic retention times in the GDPR places the full burden of definition and justification squarely upon the data controller. 

This environment forces organizations to confront a critical trade-off: is the unproven, speculative future value of raw personal data worth the risk of fines and potential data breaches? The calculation strongly favors deletion. As, 

• Failing to define and document specific deletion timelines exposes organizations to GDPR violations.
• Retaining data for future retraining or academic purposes is legally indefensible once the initial training purpose is fulfilled.
• Financial penalties for non-compliance can exceed the cost of implementing compliant, minimal-data systems.

The EU AI Act Layer: Traceability and Documentation 

The EU AI Act introduces a layered approach to retention centered on system accountability rather than individual personal data. The rules are tied to the system’s risk profile, with High-Risk AI Systems (HRAS) (EU AI Act, Chapter 3) having the most stringent obligations.

Data Governance (Article 10) for HRAS requires that training, validation, and testing data sets be relevant, representative, and free of errors. While not a direct retention rule, this implicitly requires maintaining data sets for a period necessary for auditing and quality checks during the development phase.

The most critical requirement is Documentation Retention (Article 18): HRAS providers must keep key records (Technical Documentation, Quality Management System, etc.) for 10 years after the system is placed on the market. This 10-year rule applies to documentation and metadata, not the raw personal data itself, which must be deleted sooner under the GDPR. This 10-year period covers documentation, quality records, and conformity declarations. It is vital to understand that this does not override the GDPR’s Storage Limitation Principle (Article 5(1)(e)). 

Raw personal data used for training must still be deleted sooner. However, the requirement for Record-Keeping (Logging) (Article 12) means that systems must automatically record events and usage logs. While these logs should ideally be anonymised, their retention period must be “appropriate” extending the non-personal data record-keeping timeline. This mandates a long-term, non-personal data retention strategy that must be carefully integrated with the strict, short deletion cycles required by the GDPR for raw personal data.

Blending the GDPR and EU AI Act Requirements

The intersection of the GDPR and the EU AI Act necessitates a blended compliance strategy, particularly concerning purpose and identification. The GDPR’s Purpose Limitation principle (Article 5(1)(b)) demands that the purpose for processing, such as system training, be explicitly defined. This definition directly dictates the maximum legal retention period for personal data.

Implementing De-Identification in Your AI Data Retention Strategy under the GDPR and the EU AI Act

The best path for long-term data use is de-identification:

• Pseudonymisation only reduces identifiability; the data remains personal data under the GDPR and the Storage Limitation Principle still applies.
• Anonymisation is the only legal release valve. If the data is permanently and irreversibly stripped of identifiers; it is no longer considered personal data (GDPR Recital 26). Therefore, it can be retained indefinitely.

It’s critical to remember that while the raw personal data must be deleted, the trained system itself (the output) can be retained.

Reconciling the GDPR’s Right to Erasure with the EU AI Act Traceability

The most direct legal challenge is reconciling the GDPR’s Right to Erasure (Article 17) with the ongoing need for system traceability under the AI Act. If a system is trained on personal data, the controller must maintain the technical ability to honor an erasure request.

This is the Purpose Limitation Conflict: if the initial purpose (training) is complete, retaining the raw personal data is a violation of the GDPR. Developers must implement technical solutions like secure deletion protocols immediately after a system is finalised. Using robust, irreversible anonymisation is the only way to retain data sets without triggering the GDPR’s strict retention clock.

When facing overlapping regulations, the GDPR always acts as the primary constraint on personal data. Its Storage Limitation Principle sets the hard ceiling for raw personal data retention. This is regardless of the EU AI Act’s documentation rules.

The crucial legal distinction is that PII and other personal data used to create the system must be subject to rigorous deletion procedures the moment the training purpose ends. The technical documentation, metadata, and system logs (which should contain no personal data) are then subject to the EU AI Act’s extended 10-year retention rules. This hierarchy demands that the deletion process (the GDPR) must happen first, leaving only the audit trail (EU AI Act) behind.

Table: Comparison of differences 

The Financial & Operational Cost of AI Data

Compliance is not just a cost, but a powerful risk mitigator. Storing raw personal data beyond the necessary period is a direct violation of the GDPR’s Storage Limitation Principle. This exposes an organisation to fines of up to 4% of global annual turnover (GDPR Article 83).

Beyond the fines, excessive data retention creates massive operational liability. Longer storage times mean higher infrastructure costs and a larger surface area for security breaches. Every day the data is held, the probability of a costly Data Subject Request (DSR) increases, demanding expensive legal and technical personnel to fulfill. Compliant, timely deletion is ultimately the most financially responsible strategy.

Should you store raw personal data for training?

Organisations often retain raw data for perceived future utility, perhaps for retraining a system. The GDPR forces a hard strategic trade-off: is the speculative future value of that raw personal data worth the immediate, tangible risk of massive fines and data breaches?

The EU AI Act demands auditable records, but these should be built from fully anonymised data or non-personal data metadata. The cost calculation is simple: the threat of financial penalty for retaining personal data too is a much greater risk or potential cost than developing a compliant, data-minimal system. A mature data strategy prioritises de-identification and deletion over retention, significantly reducing the organisation’s regulatory and financial exposure.

Strategic Recommendations

The regulatory landscape governing AI development in the EU is defined by a critical tension:

1. the immediate obligation to protect individual privacy (GDPR) and
2. the extended obligation to ensure system safety and traceability (EU AI Act).

Compliant data management requires recognizing the GDPR’s Storage Limitation Principle as the absolute constraint on personal data retention. This is regardless of the EU AI Act’s documentation timelines. The solution is architectural separation, where raw personal data is subject to automated deletion, and the audit trail is constructed exclusively from non-personal, irreversibly anonymized assets.

TLDR;

• Under the GDPR, personal data must be deleted once its specific purpose is fulfilled. This limits how long raw training data can be stored.
• For AI developers, this means models cannot indefinitely rely on historical raw personal data. This can potentially impact retraining strategies and model evolution.

The post AI Data Retention Strategy under the GDPR and the EU AI Act: Reconciling the Regulatory Clock 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 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.

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.