What UK AI Dev Partners Won't Tell You About GDPR Liability

Published by CodeNicely, the product studio founded by Meghal Agrawal and Ujjwal Agrawal in 2017

For: A seed-to-Series-A UK SaaS founder who has shortlisted two or three offshore AI dev studios and is about to sign, but has not yet checked whether any of them will sign a UK GDPR Article 28 Data Processing Agreement — because no vendor mentioned it during the pitch

Before you sign with any offshore AI development partner, ask one question: will you sign a UK GDPR Article 28 Data Processing Agreement, with an IDTA or SCCs plus UK Addendum, before your engineers touch our staging environment? If the answer is a shrug, a “we’ll sort that later,” or a generic NDA passed off as a DPA, walk. The liability for that gap sits with you as the controller, not with them — and the ICO has started fining processors too, which means your vendor’s risk appetite is now a direct input into your own.

This is a buyer’s guide for a UK SaaS founder who has shortlisted two or three offshore AI studios on price, portfolio and chemistry, and is about to sign. It covers the criteria that actually decide a UK engagement — GDPR posture, IP ownership, time-zone overlap, regulatory fluency, delivery proof, and what the local price band actually buys — and the exact questions to ask before you countersign.

The non-obvious thing nobody mentioned in the pitch

Under UK GDPR Article 28, the moment an offshore engineer accesses a database containing personal data of UK users — even a staging copy, even for a debugging session, even for ten minutes — a processing relationship exists. You are the controller. They are the processor. And if there is no signed, Article 28-compliant contract in place at that moment, you have breached UK GDPR before a line of production code ships.

The ICO’s Article 28 guidance is explicit: a processor must act only on documented instructions, bind staff to confidentiality, implement Article 32 security measures, and flow those same obligations down to any sub-processor. A standard offshore services MSA with an NDA bolted on does not satisfy any of this. Neither does a one-line clause that says “Supplier shall comply with applicable data protection law.”

Why do offshore vendors stay quiet about this? Because historically the enforcement risk sat with the controller alone. That changed in March 2025, when the ICO issued its first-ever monetary penalty against a data processor — a £3.07 million fine against Advanced Computer Software Group, reduced from a provisional £6.09 million. But even now, under Article 82, controllers can be held jointly and severally liable for the full failures of their processors. So the vendor’s silence is rational: raising it slows the sale, and the worst-case scenario still lands harder on you than on them.

What the UK regulator can actually do

The headline number: the ICO can fine a controller up to £17.5 million or 4% of annual worldwide turnover, whichever is higher, for serious UK GDPR breaches. For a Series A SaaS doing £3m ARR, the 4% calculation is small; the £17.5m statutory ceiling is not. ICO practice has been to scale down heavily where there is no evidence of actual harm — the Advanced fine was halved on that basis — but the starting quantum is calculated against the statutory maximum, not a token amount.

The trend direction matters more than any single number. According to URM Consulting’s 2025 analysis, UK GDPR fines in 2025 totalled roughly £20.68 million, versus £1.025 million for PECR. UK GDPR as a share of total ICO fines rose from one-seventeenth in 2023 to one-sixth in 2024. The regulator is escalating, not relaxing, and the Data (Use and Access) Act 2025 has not softened the Article 28 regime.

The second thing nobody mentioned: the transfer mechanism

An Article 28 DPA alone is not enough if your processor is outside the UK. The UK recognises adequacy for the EEA and a handful of other jurisdictions. India, Ukraine, the Philippines, Vietnam, most of Southeast Asia, and most Latin American hubs do not have UK adequacy. Every engineer access from those jurisdictions to a database containing UK user records is a “restricted transfer” under UK GDPR, and requires either the ICO’s International Data Transfer Agreement (IDTA) or the EU SCCs plus the UK Addendum, backed by a Transfer Risk Assessment.

Article 28(3)(a) requires the processor contract itself to cover any instruction to transfer personal data to a third country. The DPA and the transfer mechanism are legally interlocked, not two optional add-ons you can paper over post-launch. Both must be in place before the first access event.

The criteria that actually decide a UK engagement

1. GDPR posture — the only criterion that can sink you after launch

Why it matters: everything else on this list is a cost or a schedule problem. This one is an existential problem.

Exact questions to ask, in order:

• “Can you share your standard UK GDPR Article 28 DPA template before we sign the MSA?” If they do not have a template, they have not done this before.
• “Which transfer mechanism do you use for UK personal data — IDTA, or SCCs with the UK Addendum?” A vague answer means no answer.
• “Who is your named sub-processor list, and what is your notification period before you add one?” Article 28 requires both.
• “Will your engineers access production or staging data containing real UK user records? If yes, how are those access events logged and reviewable by us?”
• “Can you produce an ISO 27001 or SOC 2 Type II report, or a documented ISMS equivalent?”
• “Do you carry professional indemnity and cyber liability insurance that covers UK GDPR fines passed through under Article 82?”

If the vendor cannot answer four of these six on the first call, assume the DPA will become a six-week negotiation after you have already signed the MSA — which is the worst time to negotiate it, because your leverage is gone.

2. IP ownership and governing law

Why it matters: you are commissioning a work product that will underpin the valuation of your company. If the contract is governed by the laws of the vendor’s home jurisdiction and IP vests on final payment only, a payment dispute becomes an IP dispute in a court you cannot easily reach.

Questions to ask:

• “Does the contract vest all foreground IP in us on creation, or on payment?” On creation is cleaner.
• “What is the governing law and jurisdiction?” England and Wales is the strong default for a UK founder.
• “Will you warrant that no open-source component is used under a copyleft licence without written approval?”
• “Will you warrant that no training data, model weights, or generated code from third-party AI tools infringes third-party IP?” This is new territory and most 2022-vintage contract templates do not cover it.

Get full IP assignment and no vendor lock-in in writing. If the vendor pushes back on either, that tells you how they will behave in year two.

3. Time-zone overlap and how it reshapes your working day

Why it matters: the pitch deck will show “4-5 hours of overlap.” What that means in practice depends on where the overlap sits.

India (IST, UTC+5:30) gives you a working-day overlap from roughly 09:30 to 13:30 UK time in summer, 10:30 to 14:30 in winter. Eastern Europe gives you most of the UK day. Latin America gives you the UK afternoon only. For a product team doing daily standups, demo cycles and incident response, four hours of morning overlap with a Bengaluru team is usually enough; two hours of late-afternoon overlap with a São Paulo team is not.

Questions to ask:

• “What hours are your engineers contractually required to be online for us?”
• “What is your on-call rotation and response SLA for a production incident at 02:00 UK time?”
• “Who is the single named point of contact in our time zone, and what happens when they go on leave?”

4. Regulatory fluency beyond GDPR

Why it matters: depending on your sector, GDPR is the floor, not the ceiling. FCA for fintech, MHRA and NHS DSPT for health, PCI-DSS for payments, the EU AI Act for anything you sell into the EU. A vendor whose portfolio is all consumer apps for US clients will learn these on your budget.

Questions to ask:

• “Show me two reference projects in our regulated sector, with the compliance frameworks you handled.”
• “Have you ever supported a client through an ICO investigation, FCA audit, or NHS DSPT submission?”
• “How do you handle Data Protection Impact Assessments for AI features — do you draft them, or do we?”

5. Delivery proof at your stage

Why it matters: a studio that has shipped three MVPs and a studio that has scaled a product from 10k to 1M users are different companies. Pattern-match the portfolio to your stage.

For seed-to-Series-A SaaS, you want evidence of: a working MVP shipped in a defined window, product iteration based on real user feedback, and at least one engagement that survived the transition from MVP to scaling product. Case studies worth probing include those in regulated or data-heavy domains — for instance CodeNicely’s work on Gimbooks (YC-backed accounting SaaS), Cashpo (KYC and AI credit scoring), and Healthpotli (e-pharmacy with AI drug interaction checks) — because each involved personal or financial data under a regulatory regime.

Questions to ask:

• “Of your last five engagements, how many went from MVP to a second phase with the same client?”
• “Can I speak to a founder client whose project did not go well?” An honest answer here is worth more than three glowing references.
• “Which engineers who worked on the reference case study will work on mine?” Studios routinely show their A-team in the pitch and staff with juniors on delivery.

6. What the price band actually buys

Blended day rates for offshore AI development partners typically sit well below London in-house or UK agency rates — which is why the pitch lands. What drives the real total cost is not the day rate; it is five things:

• Scope clarity. A tight PRD with wireframes shortens delivery materially. An ambiguous brief doubles it.
• Integrations. Each third-party API — Stripe, HubSpot, a core banking provider, an EHR — adds its own discovery, auth, error-handling and testing cycle.
• Data migration. Zero legacy data is cheap. Migrating a messy Postgres from a previous build is not.
• Compliance overhead. A DPIA, an IDTA, a Transfer Risk Assessment and ISO-aligned controls add real engineering and legal hours. Vendors who quote without this line item are quoting incomplete work.
• Model and infra costs. If you are shipping anything LLM-powered, inference cost at scale often dwarfs the build cost by month six.

Illustrative only: a two-integration AI MVP with no data migration, a clear PRD, one LLM feature behind a feature flag, and standard UK GDPR DPA + IDTA paperwork is a different shape of engagement from a three-integration regulated-sector build with legacy migration and a bespoke DPIA. The first might be a 10-14 week engagement with a small pod; the second easily twice that. Those are shapes, not quotes.

The two or three specifics that would turn any shape into a real quote: your integration list, whether real UK personal data touches dev or staging, and your target launch window. A scoping conversation is the only way to get past the range.

What to put in the contract, specifically

Before you sign, your MSA + DPA stack should contain, at minimum:

1. An Article 28-compliant DPA naming you as controller and the vendor as processor, with the six mandatory provisions in the ICO guidance.
2. An IDTA, or the EU SCCs with the UK Addendum, attached as a schedule — not promised for later.
3. A Transfer Risk Assessment signed off by the vendor, documenting the laws of the jurisdiction their engineers work from and the supplementary measures taken (encryption, pseudonymisation, access logging).
4. A named sub-processor list and a prior-notification clause (30 days is standard) for additions.
5. Audit rights — at minimum a right to receive a current ISO 27001 certificate or SOC 2 Type II report, at best a right to commission an independent audit.
6. Breach notification within 24 hours of the processor becoming aware — shorter than the ICO’s 72-hour window to you, so you have time to meet your own obligation.
7. IP assignment on creation, English law, English courts.
8. Professional indemnity and cyber liability insurance at a level that is credible against your worst-case exposure.

None of this is unusual. Any serious vendor — including studios that regularly work with UK clients, such as the teams building out software and AI products for UK founders from offshore delivery centres — will have templates for all eight. If yours does not, that is your answer.

One caveat: this post is not legal advice. The specifics of your DPA, your transfer mechanism, and your DPIA should be reviewed by a solicitor familiar with UK data protection law. The point of this guide is to make sure you ask the questions early enough that the lawyer’s review is cheap, not a crisis.

The decision test

Line your two or three shortlisted vendors up against a simple grid. For each: do they have a UK GDPR Article 28 DPA template? Will they sign an IDTA? Can they name their sub-processors? Will they warrant IP ownership on creation under English law? Can they point to a comparable regulated-sector build? Can they staff a UK-morning overlap?

Any “no” or “we’ll figure that out later” in column one is disqualifying. Any pattern of vagueness across the other columns tells you how the next 18 months will feel. The AI build itself is the easy part; the governance scaffolding around it is what separates the vendor who ships you a product from the vendor who ships you a liability.

Frequently Asked Questions

Do I really need a DPA if my offshore developer only accesses a staging environment?

Yes, if the staging environment contains real personal data of UK users — which it usually does, because teams copy production data for realistic testing. The moment that access happens, a controller-processor relationship exists under UK GDPR, and Article 28 requires a signed contract to be in place. The fix is either a signed DPA before access, or synthetic/anonymised data in staging with a documented policy that no production data is ever copied down.

What is the difference between an NDA and a DPA, and why does my vendor keep sending me the NDA?

An NDA protects confidential business information between two parties. A DPA is a specific contract required by UK GDPR Article 28 that governs how a processor handles personal data on behalf of a controller, with six mandatory provisions set out in ICO guidance. Vendors send the NDA because they have one on the shelf. If they do not have a DPA template on the shelf, they have not run a UK engagement with any rigour before.

If my vendor is in India, do I need an IDTA on top of the DPA?

Yes. India does not have a UK adequacy decision, so every access by India-based engineers to UK personal data is a restricted transfer. You need either the ICO’s IDTA or the EU SCCs with the UK Addendum, plus a Transfer Risk Assessment documenting the local laws and the supplementary technical measures — encryption in transit and at rest, pseudonymisation where feasible, access logging. The DPA and the transfer mechanism are separate documents that must both be in place.

How much does getting the compliance paperwork right add to an AI build?

The honest answer is that it is a function of three things: whether real UK personal data touches dev or staging, how many sub-processors sit in the chain, and whether a DPIA is required for the AI features (it often is, under the ICO’s guidance on AI and automated decision-making). The incremental legal spend is usually modest if addressed at contract stage; it becomes expensive only when a breach forces it to be sorted retrospectively. A scoping call with your prospective vendor and a data protection solicitor will size it properly.

Can my vendor be fined instead of me if something goes wrong?

Both of you can be fined. The ICO’s March 2025 action against Advanced Computer Software Group was the first-ever direct penalty against a processor, so the enforcement precedent now exists. But under Article 82, data subjects can claim against the controller for the full damage caused by the processor’s failures, and the controller then has to pursue the processor contractually for recovery. If your processor is a thinly capitalised offshore entity, that recovery may be theoretical.