Building GDPR compliant AI features in your SaaS

The sprint that turns into a compliance project

The model works. The recommendations look good, the accuracy is fine, and someone says "let's ship it next sprint". Then someone else asks: "Have we done the DPIA?" Silence. "Do our customer contracts cover AI processing?" More silence. And a two week sprint turns into a two month compliance project, because nobody thought about data protection until the feature was built.

I've been through this cycle more times than I'd like to admit, building GrowCentric.ai and AI features for clients on Ruby on Rails. The good news is that data protection for AI features is less frightening than it sounds. Most of the pain comes from not knowing what is required and when. It rests on three pillars: the processing contract, data protection by design, and the data protection impact assessment. Build them into the workflow and they speed you up, because you stop retrofitting compliance onto finished features.

This is the walkthrough I wish I'd had. The law first, then the code.

Which law, for whom

An Irish SaaS business is governed by the GDPR, which applies directly, and by the Data Protection Act 2018, which set up the Data Protection Commission (DPC) as the supervisory authority.¹ The same regulation reaches businesses outside the EU that offer goods or services to people here or monitor their behaviour here, so a competitor from outside the EU selling into Ireland works to the same text as you do.² One regulation for the whole EU market keeps this article simple: every article number below is the GDPR's.

For the wider picture, cloud models, staff pasting data into chatbots and the EU AI Act, start with AI in business: the options, the dangers and how to get it right.

Pillar 1: a processing contract that actually covers AI

Article 28 requires a binding contract between a controller and any processor handling personal data on its behalf.³ In most B2B SaaS your customer is the controller and you are the processor. When the product gains AI features, the existing contract rarely describes what is now happening.

A traditional data processing agreement says the processor will handle personal data "only on documented instructions from the controller" to provide the service. That fits a product that stores data and shows it back. AI does more: it analyses, extracts patterns, predicts and sometimes trains.

I learned this the hard way when building GrowCentric.ai. When a client connects their campaign data, the system analyses conversion patterns, audience behaviour and budget effectiveness. That is processing well beyond "store it and show it back".

What the contract has to contain

Article 28(3) lists eight things the contract must require of the processor: acting only on documented instructions, confidentiality of staff, security, the rules for engaging sub processors, help with people's rights requests, help with security, breach notification and impact assessments, deletion or return of the data at the end, and making available the information needed to show compliance, including audits.³

For AI features, several of these need sharper wording:

Scope and purpose. Not "providing the Service". Name the activities: inference (applying a trained model to customer data), analysis (extracting patterns for reporting), feature extraction (deriving inputs from personal data) and, if it happens, model training. They carry different risks, and the instructions should cover each.

Sub processors. AI features bring in sub processors customers do not expect: a hosted model provider, a GPU host, a separate inference service. Under Article 28(2) a processor needs the controller's prior written authorisation, specific or general, and under a general authorisation must tell the controller about intended changes so it can object.³ List every link in the AI chain, with its purpose and what data it sees.

Training. This is the clause most AI SaaS products get wrong. State whether customer data trains anything, what kind of training (a per customer model or a shared one), how customers are kept apart, and whether a customer can opt out. In GrowCentric.ai's case the commitment is that client campaign data is used for that client's optimisation only, and no client's data trains models used for other clients. The architecture behind it is in GDPR and AI: when the right to be forgotten reaches the model.

Where it runs. AI workloads sometimes run somewhere other than the main application. If the Rails app is hosted in Dublin but the model is served from the United States, that is an international transfer, with its own conditions in Chapter V.⁴ Say where training happens, where inference happens and where the model files are stored.

Automated decisions. If the feature takes decisions about people, say who reviews them and how a person can challenge one. Article 22 sets the rules, and I come to them under pillar 2.

Worked example: an AI processing schedule

I keep the AI part of the contract as a machine readable schedule, attached as an annex. Here it is for an invented business, Merchants Mail, an email marketing SaaS in Galway at merchantsmail.example:

module DPACompliance
  class AIProcessingSchedule
    # Annex to the processing contract: one entry per AI processing activity
    def self.for_merchants_mail
      {
        processing_activities: [
          {
            name: "Send time optimisation",
            purpose: "Recommending the send time for each campaign segment",
            data_categories: ["open and click events", "send timestamps", "segment ids"],
            personal_data_involved: true,
            aggregation: "Segment level, minimum 100 recipients per segment",
            automated_decision: false,
            sub_processors: ["Irish cloud host (hosting and inference)"],
            location: "Ireland only",
            retention: "Raw events 12 months, segment statistics kept",
            training_use: "Per customer model on aggregated segments only"
          },
          {
            name: "Subject line suggestions",
            purpose: "Drafting subject line options for the customer to choose from",
            data_categories: ["campaign text written by the customer"],
            personal_data_involved: false,
            automated_decision: false,
            sub_processors: ["Hosted language model provider (EU region)"],
            location: "EU",
            retention: "Not retained by the provider under its API terms",
            training_use: "None. Recipient data is never sent to the model"
          }
        ],
        model_training_policy: "Customer data is aggregated before training. " \
                               "Models are per customer and never shared across accounts.",
        human_oversight: "Every suggestion is reviewed by the customer before a send.",
        data_subject_rights: "Requests are passed to the customer within two working days " \
                             "and completed within the one month deadline."
      }
    end
  end
end

The same structure feeds the record of processing activities that Article 30 requires,⁵ and the impact assessment under pillar 3. One source, three uses.

Telling customers about sub processor changes

Under a general authorisation, the customer must get the chance to object before a new sub processor starts. The law sets no fixed notice period, so the contract should. This example uses 30 days:

class SubProcessorRegistry
  NOTICE_PERIOD = 30.days # the contract's notice period, not a statutory one

  def self.notify_controllers_of_change(product:, change:)
    Controller.where(product: product, active: true).find_each do |controller|
      SubProcessorChangeNotification.create!(
        controller: controller,
        change_type: change[:type], # :addition, :removal, :modification
        sub_processor_name: change[:name],
        purpose: change[:purpose],
        data_access_scope: change[:data_scope],
        location: change[:location],
        effective_date: NOTICE_PERIOD.from_now,
        objection_deadline: NOTICE_PERIOD.from_now,
        notified_at: Time.current
      )
      SubProcessorNotificationMailer.change_notification(controller, change).deliver_later
    end
  end
end

Pillar 2: data protection by design, in code

Article 25 requires data protection by design and by default: appropriate technical and organisational measures, built in when the processing is designed, and by default only the personal data necessary for each purpose.⁶ That sounds abstract. In practice it comes down to seven decisions made before the AI code is written.

It is not abstract to regulators either. In December 2024 the DPC, the regulator on your own doorstep, fined Meta €251 million over a 2018 breach. €130 million of that was for breaching Article 25(1) by failing to build the data protection principles into the design of its systems, and €110 million for breaching Article 25(2) on processing only the data necessary by default.⁷ Article 25 sits in the fine band of up to €10 million or 2% of worldwide turnover, whichever is higher.⁸

Decision 1: purpose limitation at the model level

Every model gets a documented purpose, and the code holds it to that purpose. A recommendation engine should not be quietly reusable as a profiling tool.

module PrivacyByDesign
  class PurposeBoundModel
    PERMITTED_PURPOSES = {
      car_recommendation: {
        permitted_inputs: %i[category_preferences price_range region session_signals],
        prohibited_inputs: %i[name email phone address financial_data],
        output_type: :ranked_listing_ids
      },
      send_time_optimisation: {
        permitted_inputs: %i[segment_id historical_open_rates day_of_week time_bucket],
        prohibited_inputs: %i[individual_email name browsing_history],
        output_type: :recommended_send_time
      },
      campaign_budget_allocation: {
        permitted_inputs: %i[channel_metrics historical_roas budget_constraints seasonal_index],
        prohibited_inputs: %i[individual_user_data personal_demographics],
        output_type: :budget_recommendation
      }
    }.freeze

    def initialize(purpose:)
      @purpose = purpose
      @config = PERMITTED_PURPOSES.fetch(purpose)
    end

    def validate_inputs(input_data)
      keys = input_data.keys.map(&:to_sym)
      violations = keys & @config[:prohibited_inputs]
      raise PrivacyViolationError, "#{violations} prohibited for #{@purpose}" if violations.any?

      unexpected = keys - @config[:permitted_inputs]
      Rails.logger.warn("Unexpected inputs #{unexpected} for #{@purpose}") if unexpected.any?
      true
    end
  end
end

If someone passes an email address to the recommendation engine by accident, it fails before any processing happens.

Decision 2: data minimisation in feature engineering

The feature pipeline is where most privacy problems in AI systems begin. Someone pulls in every column that might be useful and the model now processes data it does not need. Article 5 says personal data must be adequate, relevant and limited to what is necessary for the purpose.⁹ So every feature is registered with its reason, and what was discarded is logged:

module PrivacyByDesign
  class MinimisedFeatureExtractor
    FEATURE_REGISTRY = {
      car_recommendation: {
        category_affinity: { extraction: :category_view_counts,
                             minimisation: "Category level only, no single listing tracking" },
        price_band:        { extraction: :price_range_histogram,
                             minimisation: "Five bands, no exact values" },
        region:            { extraction: :region_code,
                             minimisation: "Region level only, no precise location" }
      }
    }.freeze

    def extract_features(purpose:, raw_data:)
      registry = FEATURE_REGISTRY.fetch(purpose)
      features = registry.to_h { |name, cfg| [name, send(cfg[:extraction], raw_data)] }

      FeatureExtractionAudit.create!(
        purpose: purpose,
        features_extracted: features.keys,
        raw_fields_discarded: raw_data.keys - features.keys,
        extracted_at: Time.current
      )
      features
    end
  end
end

Decision 3: pseudonymisation by default

Pseudonymisation means processing personal data so that it can no longer be attributed to a person without additional information, kept separately and protected by technical and organisational measures.¹⁰ The EDPB published draft guidelines on it, Guidelines 01/2025, for consultation in January 2025.¹¹ Two points matter for builders. The key lives apart from the data. And pseudonymised data is still personal data, because the key exists. It reduces risk. It does not take you out of the law.

module PrivacyByDesign
  class Pseudonymiser
    def pseudonymise_for_training(records, purpose:)
      mapping_id = SecureRandom.uuid
      pseudonymised = records.map do |record|
        record.except(:user_id, :email, :name, :ip_address)
              .merge(pseudo_id: pseudonym(record[:user_id], mapping_id))
      end

      PseudonymMapping.create!(mapping_id: mapping_id, purpose: purpose,
                               expires_at: 90.days.from_now, access_level: "dpo_only",
                               record_count: records.size)
      { data: pseudonymised, mapping_id: mapping_id }
    end

    private

    # HMAC pseudonym: stable within one mapping, different across mappings
    def pseudonym(user_id, mapping_id)
      OpenSSL::HMAC.hexdigest("SHA256", KeyManagement.retrieve("pseudo_#{mapping_id}"), user_id.to_s)
    end
  end
end

Decision 4: pipelines that know the legal basis

Every processing purpose needs a lawful basis under Article 6.¹² For personalised features in an Irish product there is a second rule in front of it: storing or reading anything on a visitor's device needs consent under regulation 5(3) of the ePrivacy Regulations 2011, unless one of the two narrow exemptions in regulation 5(5) applies,¹³ and the DPC's guidance is clear that a cookie which recognises a visitor over time to remember their preferences needs consent, however helpful the feature, while advertising cookies are never strictly necessary.¹⁴ I set that out for recommendations in building custom AI recommendations in Solidus. So the pipeline checks the basis for each purpose before every step, not only at collection:

module PrivacyByDesign
  class LegalBasisAwarePipeline
    # The legal basis for each purpose is decided once, in the impact assessment,
    # and enforced here
    PURPOSES = {
      essential_service:      { basis: :contract,             consent_required: false },
      service_analytics:      { basis: :legitimate_interests, consent_required: false },
      personal_recommendations: { basis: :consent,            consent_required: true },
      model_training_contribution: { basis: :consent,         consent_required: true }
    }.freeze

    def process_for(user:, purpose:, data:)
      config = PURPOSES.fetch(purpose)
      consent = ConsentRecord.current_for(user: user, purpose: purpose)
      return nil if config[:consent_required] && !consent&.granted?

      ProcessingRecord.create!(user_id: user.id, purpose: purpose, legal_basis: config[:basis],
                               consent_id: consent&.id, data_categories: data.keys,
                               processed_at: Time.current)
      yield data
    end
  end
end

For an email platform like Merchants Mail this matters at scale: whether a recipient's engagement feeds the AI analytics depends on what each recipient agreed to, and the check runs every time.

Decision 5: retention that actually deletes

Personal data may be kept no longer than the purpose needs.⁹ If the policy says 90 days, something has to delete it on day 91.

module PrivacyByDesign
  class RetentionEnforcer
    # The example's retention policy. The periods are business decisions,
    # recorded in the impact assessment, not periods set by the law.
    RETENTION_POLICIES = {
      raw_interaction_data: 90.days,
      email_engagement_events: 12.months,
      search_query_logs: 30.days,
      training_features: 6.months,
      pseudonym_mappings: 90.days,
      consent_records: 6.years, # kept to prove consent was given
      audit_logs: 3.years
    }.freeze

    def enforce!
      RETENTION_POLICIES.each do |data_type, retention|
        purged = data_class_for(data_type).where("created_at < ?", retention.ago).delete_all
        Rails.logger.info("Retention: purged #{purged} #{data_type} older than #{retention.inspect}")
      end
    end
  end
end

I run this as a daily Sidekiq job across every product. It sounds obvious, and most teams forget it.

Decisions 6 and 7: rights respecting inference and transparent logging

These connect to the audit logging and tiered autonomy patterns in the EU AI Act for SaaS builders and the agentic AI post: every AI decision is logged with its inputs, output and model version, and a person can review and override it.

That logging is what the automated decision rules need.

Article 22 gives a person the right not to be subject to a decision based solely on automated processing, including profiling, that produces legal effects concerning them or similarly significantly affects them. There are three exceptions: the decision is necessary for a contract, authorised by law, or based on explicit consent.² Where it rests on a contract or on consent, the controller must put safeguards in place, at least the right to obtain human intervention, to express a point of view and to contest the decision.¹⁵ Decisions of this kind may not be based on special category data unless the person gave explicit consent or there is a substantial public interest in law, with suitable safeguards in place.¹⁵

Most SaaS AI features never meet that bar. A send time suggestion or a product carousel has no significant effect on anyone. Credit limits, job applications, insurance prices and account closures do. Know which side each feature is on, and write it down.

Pillar 3: impact assessments that do not sit in a drawer

Article 35 requires a data protection impact assessment before processing that is likely to result in a high risk to people's rights and freedoms, "in particular using new technologies".¹⁶

For AI, the DPC's guidance points the same way: building an AI product with personal data "may require performing a data protection impact assessment", especially where the technology is new to you, where you combine datasets, or where children or vulnerable people are involved, and it adds that it may be best practice to do one anyway.¹⁷ The European guidelines the DPC applies list nine criteria that indicate likely high risk: evaluation or scoring, automated decisions with legal or similar effect, systematic monitoring, sensitive data, large scale processing, matching or combining datasets, vulnerable people, innovative technology, and preventing people from exercising a right or using a service. In most cases, processing that meets two of them needs a DPIA. On top of that, the DPC's own list makes a DPIA mandatory, where a documented screening points to high risk, for processing such as profiling individuals on a large scale, systematically monitoring or tracking people's behaviour, and combining datasets for profiling or behavioural analysis.¹⁸

The mistake most developers make is treating the DPIA as a one off document written by someone in legal and forgotten. A useful one is a technical artefact that lives next to the code and changes when the processing changes.

class DPIAGenerator
  CRITERIA = %i[evaluation_or_scoring automated_decisions systematic_monitoring
                sensitive_data large_scale matching_datasets vulnerable_people
                innovative_technology preventing_rights].freeze

  def generate(ai_feature:)
    triggered = CRITERIA.select { |c| ai_feature.meets?(c) }
    {
      metadata: { feature: ai_feature.name, version: ai_feature.version,
                  assessed_at: Time.current, review_due: 6.months.from_now },
      description: { processing: ai_feature.processing_description,
                     data_categories: ai_feature.data_categories,
                     data_subjects: ai_feature.data_subject_categories,
                     purpose: ai_feature.stated_purpose },
      necessity_and_proportionality: { legal_basis: ai_feature.legal_basis,
                                       minimisation: ai_feature.minimisation_evidence,
                                       retention: ai_feature.retention_policy,
                                       rights: ai_feature.rights_mechanisms,
                                       automated_decision_safeguards: ai_feature.adm_safeguards },
      screening: { criteria_triggered: triggered,
                   # The European guidelines the DPC applies: two criteria in most cases
                   dpia_required: triggered.size >= 2 },
      risks: ai_feature.risks,
      mitigations: ai_feature.mitigation_measures,
      consultation: { dpo_opinion: nil, prior_consultation_required: false }
    }
  end
end

Worked example: screening GrowCentric.ai's audience segmentation

This is the assessment for GrowCentric.ai's audience segmentation feature.

What it does: analyses campaign data to find behavioural clusters for audience targeting, grouping users by engagement, purchase signals and browsing behaviour, and recommends which segments a client should target.

Criteria met: evaluation or scoring (it profiles audience segments), innovative technology (machine learning segmentation) and large scale processing (campaign data across many people). Three criteria, one more than the two that usually call for a DPIA, and profiling on a large scale is on the DPC's own list, so a DPIA is required.

Risks: discriminatory targeting if segments correlate with protected characteristics, opaque profiling because people do not know they have been segmented, and leakage if a segment reveals something sensitive about the people in it.

Mitigations: segments are built from aggregated data only, with a minimum of 50 users per cohort. Protected characteristics are excluded from feature extraction. Segment definitions are transparent and auditable. Clients can review and override any segment before use. Provenance tracking records what data informed each segment.

Residual risk: low, because no individual's personal data enters the segmentation pipeline. The feature works on statistical patterns, not personal profiles.

That is a useful DPIA. Not a 50 page legal document. A technical assessment that maps to decisions in the code.

Worked example: what the fine ceiling means for a small SaaS

The Article 25 and Article 35 duties sit in the lower fine band. The ceiling is €10 million or 2% of worldwide annual turnover, whichever is higher.⁸

$$\text{cap} = \max(F,\; p \times T)$$

Here $F$ is the fixed amount, €10 million, $p$ the percentage written as a decimal, 0.02, $T$ the worldwide annual turnover for the preceding financial year, and $\max$ takes the larger of the two. Percentages as decimals are in Foundations: percentages.

Merchants Mail has a turnover of €3 million (the example's figure):

$$0.02 \times 3{,}000{,}000 = 60{,}000$$

Here $0.02$ is the 2% and $3{,}000{,}000$ the turnover in euros. The higher of €60,000 and €10 million is €10 million, so for any business with a turnover under $10{,}000{,}000 \div 0.02 = 500{,}000{,}000$ euros, the fixed figure is the ceiling. Nobody expects a Galway email platform to be fined millions for a missing DPIA. The ceiling simply shows how seriously the law takes the duty, and the regulator weighs every case on its facts.

Keep it alive

A DPIA is a living document. I keep them in version control alongside the features they assess, and the code raises a review when the processing changes:

class DPIALifecycleManager
  def check_for_review_triggers(ai_feature:)
    dpia = DPIA.current_for(feature: ai_feature)
    triggers = []
    triggers << "Scheduled review due" if dpia.review_due <= Date.current
    triggers << "New data category" if added_data_category?(ai_feature, dpia)
    triggers << "New sub processor" if added_sub_processor?(ai_feature, dpia)
    triggers << "Scale increase" if scale_increased?(ai_feature, dpia)
    triggers << "New automated decision" if added_automated_decision?(ai_feature, dpia)
    triggers << "Model architecture change" if model_changed?(ai_feature, dpia)

    if triggers.any?
      DPIAReviewRequest.create!(dpia: dpia, triggers: triggers, requested_at: Time.current)
      DPIAReviewNotifier.notify(dpia: dpia, triggers: triggers)
    end
    triggers
  end
end

How the three pillars fit together

They are not separate workstreams. They are layers of one architecture.

Read it from the top: the contract says what is allowed, the code enforces it, the assessment checks it. Any change to the processing loops back to the contract and the assessment before it ships.

They connect to the rest of the law too. The right to be forgotten article covers the erasure handler. The EU AI Act article covers the transparency duties that have applied since 2 August 2026 and the high risk rules that now start on 2 December 2027, and a deployer's fundamental rights impact assessment under that Act can cross reference its DPIA instead of repeating it.¹⁹ The Cyber Resilience Act article covers the security of the infrastructure underneath.

The same patterns apply whatever the product: campaign optimisation in GrowCentric.ai, engagement analytics on an email platform, search ranking on a local listings site, car recommendations and pricing on Solidus. Different features, the same architecture.

The ten point checklist

Before shipping any AI feature:

1. Contract updated? Does the customer agreement cover this specific AI processing?
2. Sub processors listed? Is every AI infrastructure provider documented, and were customers given the chance to object?
3. Purpose documented? Is the model held to one stated purpose in code?
4. Data minimised? Does the model get only the data it needs?
5. Pseudonymised? Are identifiers replaced before data reaches the model, with the key kept apart?
6. Legal basis checked? Does the pipeline respect each person's consent where consent is the basis?
7. Retention enforced? Will the data be deleted when the period ends?
8. Audit trail active? Is every AI decision logged with inputs, outputs and model version?
9. DPIA done? Have you screened against the criteria, assessed the risks and recorded the mitigations?
10. Human oversight in place? Can a person review and override every AI decision, and can the people affected by a significant one contest it?

Ten yeses and you are in good shape. Not finished, because data protection is never finished, but well ahead of most AI SaaS products.

The bottom line

Data protection for AI features comes down to three documents and seven decisions. The documents are the processing contract, the design record and the impact assessment. The decisions are purpose limitation, minimisation, pseudonymisation, a checked legal basis, retention, rights respecting inference and transparent logging.

None of it needs a law degree. It needs an engineering mindset applied to legal requirements. Write the compliance into the code, not into a document in a drawer. Build the patterns once and they work everywhere: every product, every feature, every market.

Footnotes

1. Data Protection Act 2018, sections 10 and 11, establishment of the Data Protection Commission as supervisory authority, Irish Statute Book, 2018, https://www.irishstatutebook.ie/eli/2018/act/7/enacted/en/print

2. Regulation (EU) 2016/679 (General Data Protection Regulation), Articles 3 and 22(1) and (2), EUR-Lex, https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679

3. Regulation (EU) 2016/679 (General Data Protection Regulation), Article 28, processor, EUR-Lex, https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679

4. Regulation (EU) 2016/679 (General Data Protection Regulation), Chapter V, transfers of personal data to third countries, EUR-Lex, https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679

5. Regulation (EU) 2016/679 (General Data Protection Regulation), Article 30, records of processing activities, EUR-Lex, https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679

6. Regulation (EU) 2016/679 (General Data Protection Regulation), Article 25, data protection by design and by default, EUR-Lex, https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679

7. Data Protection Commission, Irish Data Protection Commission fines Meta €251 Million, 17 December 2024, https://www.dataprotection.ie/en/news-media/press-releases/irish-data-protection-commission-fines-meta-eu251-million

8. Regulation (EU) 2016/679 (General Data Protection Regulation), Article 83(4), general conditions for imposing administrative fines, EUR-Lex, https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679

9. Regulation (EU) 2016/679 (General Data Protection Regulation), Article 5(1), principles, points (c) and (e), EUR-Lex, https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679

10. Regulation (EU) 2016/679 (General Data Protection Regulation), Article 4, definitions, point 5 (pseudonymisation), EUR-Lex, https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679

11. European Data Protection Board, Guidelines 01/2025 on Pseudonymisation, public consultation 17 January to 14 March 2025, https://www.edpb.europa.eu/our-work-tools/documents/public-consultations/2025/guidelines-012025-pseudonymisation_en

12. Regulation (EU) 2016/679 (General Data Protection Regulation), Article 6, lawfulness of processing, EUR-Lex, https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679

13. European Communities (Electronic Communications Networks and Services) (Privacy and Electronic Communications) Regulations 2011, S.I. No. 336 of 2011, regulations 5(3) and 5(5), Irish Statute Book, 2011, https://www.irishstatutebook.ie/eli/2011/si/336/made/en/print

14. Data Protection Commission, Guidance note: Cookies and other tracking technologies, April 2020, https://www.dataprotection.ie/sites/default/files/uploads/2020-04/Guidance%20note%20on%20cookies%20and%20other%20tracking%20technologies.pdf

15. Regulation (EU) 2016/679 (General Data Protection Regulation), Article 22(3) and (4), safeguards and special category data in automated decisions, EUR-Lex, https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679

16. Regulation (EU) 2016/679 (General Data Protection Regulation), Article 35, data protection impact assessment, EUR-Lex, https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679

17. Data Protection Commission, AI, Large Language Models and Data Protection, 18 July 2024, https://www.dataprotection.ie/en/dpc-guidance/blogs/AI-LLMs-and-Data-Protection

18. Data Protection Commission, List of Types of Data Processing Operations which require a Data Protection Impact Assessment, November 2018, https://www.dataprotection.ie/sites/default/files/uploads/2018-11/Data-Protection-Impact-Assessment.pdf

19. Regulation (EU) 2026/1744 (Digital Omnibus on AI), Article 1, point 13, amending Article 27(4) of Regulation (EU) 2024/1689, Official Journal of the European Union, 24 July 2026, EUR-Lex, https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202601744