There is no shortage of guidance on AI and GDPR. The ICO has published extensively on it. Legal commentary fills the inbox. Everyone agrees that processing personal data through an AI platform is a novel activity, that a DPIA is almost certainly required, and that the controller-processor relationship needs to be carefully documented.

What is much harder to find is practical guidance for the person who actually has to approve the deployment, the DPO who needs to make a defensible, informed decision about whether a specific vendor, a specific platform, and a specific implementation plan is lawful and safe.

This is not that GDPR explainer. These are the eight questions that, in practice, determine whether a university AI platform deployment is approvable - and where the gaps most commonly appear.

1. Where is the data actually processed - and can the vendor prove it?

UK-only data processing is not a marketing claim. It is a technical and contractual commitment that needs to be specified, auditable, and breach-notifiable. Ask the vendor to state explicitly: which availability zones process your data, whether development and support activities involve personnel outside the UK, and what happens if future architecture requires international transfer.

The answer you are looking for is a contractual commitment to UK-only processing, named availability zones (London and Manchester are the standard UK pair), a change-notification obligation if that ever needs to vary, and an agreed mechanism - IDTA or SCCs with ICO Addendum, already drafted for that eventuality. A vendor who cannot name their availability zones or who hedges on support access is not giving you the assurance you need.

2. Is your institution's data being used to train AI models?

This sounds obvious but the answer is less straightforward than vendors sometimes imply. The question is not whether the vendor's general terms prohibit training use - it is whether those terms cover every tier of service your users will access, and whether the prohibition extends to any sub-processors or underlying model providers.

Enterprise and education tiers of major AI platforms typically carry explicit no-training commitments. Consumer tiers often do not. If any of your users could access the platform through a free or personal-tier account - which is why domain claim matters - those interactions may not carry the same protection. The contractual commitment you need is comprehensive, specific to your tenancy, and flows through to every sub-processor the vendor uses.

3. What does the Data Processing Agreement actually cover?

A DPA aligned to UK GDPR Article 28 must include: processing only on documented instructions; confidentiality obligations binding on all personnel with access; appropriate technical and organisational measures; sub-processor authorisation with advance notification of changes; assistance with data subject rights requests within regulatory timeframes; assistance with DPIAs and prior consultation; deletion or return of all data at contract end; and full cooperation with your audit and information requests.

In practice, the most commonly missing items are: the advance notification period for sub-processor changes (30 days is standard; some vendors try to reduce this), the specific commitment on deletion timelines at contract end, and the scope of audit rights. Read the DPA before relying on a vendor's summary of it.

4. Can the vendor support your DPIA - or are they expecting you to produce it from scratch?

Processing personal data through a generative AI platform will, in the vast majority of cases, trigger the requirement for a DPIA under UK GDPR Article 35. A vendor who says "we can support your DPIA" and then provides a generic privacy notice is not actually providing DPIA support.

What genuine DPIA support looks like: comprehensive data flow diagrams specific to your deployment; Article 30 records of processing activities that you can directly incorporate; a security control specification you can assess against; a risk assessment methodology aligned to ICO guidance; and documentation of data usage limitations that can be referenced as a risk mitigation. It should be maintained by a qualified DPO on the vendor side and updated quarterly to reflect platform changes. If the vendor cannot demonstrate this on request, the DPIA burden falls entirely on you - which is possible, but should be priced into your resourcing.

5. How does the platform handle data subject rights and how long does it actually take?

The right of access, the right to erasure, and the right to data portability are not edge cases in a university AI deployment. With tens of thousands of students and staff, you will receive data subject requests. The question is whether the platform is architected to fulfil them efficiently or whether each one is a manual support ticket.

Access requests should be fulfillable through an export function within a reasonable timeframe - two hours is achievable with well-designed tooling. Erasure requests should produce an audit trail confirming deletion, not a support email asking you to wait. Portability should produce a structured format, JSON or CSV - that a data subject can actually use. Ask the vendor to demonstrate each of these during evaluation, not just confirm they exist in the documentation.

6. Are safeguarding controls operational at student launch or configured afterwards?

If your student population includes under-18 learners - which it does if you run foundation programmes, some access courses, or certain partnership arrangements - KCSIE 2025 compliance is not optional. The question is not whether the vendor supports safeguarding controls. It is whether those controls are operational at the moment a student first accesses the platform.

Content filtering, deepfake detection, and age-appropriate access restrictions that are configured after the student launch window expose you to a period of non-compliance. The implementation plan should sequence safeguarding configuration as a Phase 3 task - before the pilot, before the staff launch, and well before student access. Ask to see where in the implementation timeline these controls are activated and what the vendor's testing protocol is before they go live.

7. Does the platform meet WCAG 2.2 Level AA - including the criteria added in October 2024?

UK public sector accessibility regulations now reference WCAG 2.2. The standard was updated in October 2024 with new Level AA success criteria that were not present in WCAG 2.1: Focus Not Obscured (2.4.11), Target Size Minimum (2.5.8), and Accessible Authentication (3.3.8) are the most operationally significant for an AI chat interface.

A vendor who claims WCAG 2.2 compliance but cannot produce a VPAT (Voluntary Product Accessibility Template) validated against the 2.5 Rev or later, with screen reader testing documented for JAWS, NVDA, and VoiceOver, is not providing evidence of compliance - they are providing a marketing statement. This matters particularly for your disabled students and staff, and for your institution's legal obligations under the Public Sector Bodies Accessibility Regulations.

8. What is the vendor's commitment to regulatory change - and is it contractual?

UK GDPR guidance, KCSIE requirements, and AI governance frameworks were all evolving at the point of writing this. The Data (Use and Access) Act 2025 changed the landscape for automated decision-making. ICO AI guidance is under review. The regulatory environment for AI in education will not be static.

A DPA and DPIA that are accurate at contract signature may contain gaps within 12 months. The question is whether the vendor has a contractual commitment to track regulatory changes, notify you of implications for your deployment, and update relevant documentation accordingly. A quarterly compliance review cycle, contractually mandated, is the minimum that gives you defensible ongoing assurance rather than a point-in-time snapshot.

The Approval Decision

None of these questions is unanswerable by a well-prepared enterprise vendor. The purpose of asking them is not to create barriers - it is to distinguish between vendors who have genuinely built compliance into their platform architecture and those who have produced documentation to satisfy a procurement checklist.

A DPO who can answer all eight questions affirmatively, with evidence, is in a position to make a defensible approval decision for an institution-wide deployment. A DPO who discovers gaps after go-live is in a much more difficult position.

Ask the questions before contract award. The evidence should already exist - if the vendor is asking you to wait while they produce it, that is itself an answer.

VE3's PromptX platform is designed to support DPO approval from the outset - with a fully executed Article 28 DPA, DPIA support documentation maintained quarterly, UK-only processing, and contractual compliance review commitments. If you are evaluating a university AI deployment, we are happy to answer all eight of these questions with evidence. To discuss more, contact VE3 Global.