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

A UK SaaS business is governed by the UK GDPR and the Data Protection Act 2018. The regulator is now the Information Commission (still the ICO on its website), since the office of the Information Commissioner was abolished by the Data (Use and Access) Act 2025.¹ When you offer the product to people in the EU, or monitor their behaviour there, the EU GDPR applies to that processing too.² The two texts still share their article numbers and most of their words, so I cite the UK GDPR first and note where the EU text differs, as it does on automated decisions.

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 the UK 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. The rules differ between the UK and the EU, 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, Ashdown Mail, an email marketing SaaS in Brighton at ashdownmail.example:

module DPACompliance
  class AIProcessingSchedule
    # Annex to the processing contract: one entry per AI processing activity
    def self.for_ashdown_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: ["UK cloud host (hosting and inference)"],
            location: "UK 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 Irish Data Protection Commission 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.⁷ In the UK, Article 25 sits in the fine band of up to £8.7 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 a UK product there is a second rule in front of it: storing or reading anything on a visitor's device to track them needs consent under the Privacy and Electronic Communications Regulations, unless an exception applies,¹³ and the ICO's guidance says tailoring content to someone's known or inferred interests is not covered by the exceptions.¹⁴ 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 Ashdown 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, and here the UK and the EU now differ.

In the UK, the Data (Use and Access) Act 2025 replaced Article 22 with Articles 22A to 22D. A decision is "based solely on automated processing" if there is no meaningful human involvement, and "significant" if it has a legal or similarly significant effect on the person.¹⁵ For such decisions the controller must have safeguards that give the person information about the decision and let them make representations, obtain human intervention and contest it.¹⁶ Solely automated significant decisions based on special category data are only allowed with explicit consent or in narrow legal cases, and none can rest on the new basis of a "recognised legitimate interest".¹⁷

In the EU, Article 22 still gives a person the right not to be subject to a decision based solely on automated processing, including profiling, that produces legal or similarly significant effects, with three exceptions: contract, law or explicit consent.²

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 ICO is blunt: "In the vast majority of cases, the use of AI will involve a type of processing likely to result in a high risk to individuals' rights and freedoms, and will therefore trigger the legal requirement for you to undertake a DPIA."¹⁹ Its general guidance lists the nine criteria from the European guidelines 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. The ICO's own list requires a DPIA for innovative technology, which names AI and machine learning, in combination with any one of those other criteria.²⁰

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,
                   # UK rule: innovative technology plus any one other criterion
                   dpia_required: triggered.include?(:innovative_technology) && 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, innovative technology among them, so under the ICO's list 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. In the UK the ceiling is £8.7 million or 2% of worldwide annual turnover, whichever is higher.⁸

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

Here $F$ is the fixed amount, £8.7 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.

Ashdown 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 pounds. The higher of £60,000 and £8.7 million is £8.7 million, so for any business with a turnover under $8{,}700{,}000 \div 0.02 = 435{,}000{,}000$ pounds, the fixed figure is the ceiling. Nobody expects a Brighton 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 (Use and Access) Act 2025, section 118, abolition of the office of Information Commissioner, legislation.gov.uk, https://www.legislation.gov.uk/ukpga/2025/18/section/118

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

3. UK GDPR, Article 28, processor, legislation.gov.uk, https://www.legislation.gov.uk/eur/2016/679/article/28

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. UK GDPR, Article 30, records of processing activities, legislation.gov.uk, https://www.legislation.gov.uk/eur/2016/679/article/30

6. UK GDPR, Article 25, data protection by design and by default, legislation.gov.uk, https://www.legislation.gov.uk/eur/2016/679/article/25

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. UK GDPR, Article 83(4), general conditions for imposing administrative fines, legislation.gov.uk, https://www.legislation.gov.uk/eur/2016/679/article/83

9. UK GDPR, Article 5, principles, points (c) and (e), legislation.gov.uk, https://www.legislation.gov.uk/eur/2016/679/article/5

10. UK GDPR, Article 4, definitions, point 5 (pseudonymisation), legislation.gov.uk, https://www.legislation.gov.uk/eur/2016/679/article/4

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. UK GDPR, Article 6, lawfulness of processing, legislation.gov.uk, https://www.legislation.gov.uk/eur/2016/679/article/6

13. The Privacy and Electronic Communications (EC Directive) Regulations 2003, regulation 6, legislation.gov.uk, https://www.legislation.gov.uk/uksi/2003/2426/regulation/6

14. Information Commissioner's Office, Guidance on the use of storage and access technologies: What are the exceptions?, accessed November 2026, https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guidance-on-the-use-of-storage-and-access-technologies/what-are-the-exceptions/

15. UK GDPR, Article 22A, automated processing and significant decisions, legislation.gov.uk, https://www.legislation.gov.uk/eur/2016/679/article/22A

16. UK GDPR, Article 22C, safeguards for automated decision making, legislation.gov.uk, https://www.legislation.gov.uk/eur/2016/679/article/22C

17. UK GDPR, Article 22B, restrictions on automated decision making, legislation.gov.uk, https://www.legislation.gov.uk/eur/2016/679/article/22B

18. UK GDPR, Article 35, data protection impact assessment, legislation.gov.uk, https://www.legislation.gov.uk/eur/2016/679/article/35

19. Information Commissioner's Office, Guidance on AI and data protection: What are the accountability and governance implications of AI?, accessed November 2026, https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/what-are-the-accountability-and-governance-implications-of-ai/

20. Information Commissioner's Office, When do we need to do a DPIA?, accessed November 2026, https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/when-do-we-need-to-do-a-dpia/

21. 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