Data Protection & Information Security Experts

AI Governance in Schools: Practical Guidance

How schools, academies, and multi-academy trusts can navigate the legal, technical, and ethical implications of artificial intelligence while protecting children, staff, and their fundamental rights and freedoms.

Artificial intelligence (AI) presents schools with an increasingly complex governance challenge. Its potential to reduce administrative burdens, support teaching, and improve accessibility is significant. However, so too are the implications for data protection, safeguarding, information security, educational development, and the rights of the children and adults whose information it processes.

For school and trust leaders, the question is no longer simply whether AI should be used. In many cases, it is already being used, either deliberately or through functionality embedded within existing software. The more important questions concern how these systems operate, what information they process, whether their use is justified, and how the organisation retains control over the outcomes they produce.

AI systems vary considerably in their design, capabilities, and underlying processes. Some generate text or images in response to prompts, whilst others analyse data, make predictions, recommend actions, or carry out sequences of tasks with limited human intervention. More specifically, an AI-enabled product may incorporate several interconnected models, algorithms, data sources, and external services, each introducing its own dependencies and potential risks. The apparent simplicity of the interface can therefore obscure the complexity of the system behind it. This matters particularly in education, where schools process substantial amounts of personal data about children, including information concerning their health, special educational needs and disabilities (SEND), family circumstances, behaviour, and safeguarding concerns. Such information can be highly sensitive, and its inappropriate disclosure or use may have consequences extending well beyond the immediate incident.

At the same time, children are developing the critical faculties they need to evaluate information, recognise uncertainty, and make independent judgements. Introducing AI into their educational environment raises questions not only about the protection of personal data, but also about the reliability of information, the potential for manipulation, and the extent to which children can understand and challenge the systems with which they interact. The answer is not to reject AI categorically, nor is it to assume that its benefits justify the risks simply because the technology is becoming more prevalent.

Responsible AI adoption requires schools to understand what they are introducing, establish whether its use is justified, assess the risks to the people affected, and retain meaningful accountability throughout its lifecycle.

This is where effective AI governance becomes essential: not as a standalone compliance exercise, but as an integral part of how schools make decisions, procure technology, and protect the people in their care.

1. AI governance begins with understanding the technology

One of the difficulties in governing AI is that the term itself is used to describe a broad range of technologies that do not operate in the same way. A generative AI system may produce text, images, or other content based on patterns learned during training. A predictive model may estimate the likelihood of an outcome based on particular inputs. An AI agent may use a model alongside tools, external data sources, and defined permissions to carry out a sequence of tasks. The risks associated with each depend on its design, the information available to it, the actions it can take, and the context in which it is deployed. It is therefore unhelpful to treat AI as a single, uniform category of software.

Consider the difference between asking an AI tool to generate a generic revision quiz and introducing a system that analyses attendance, attainment, and behavioural information to identify pupils considered at risk of disengagement. The first use may require little or no personal data, whereas the second may involve the combination of multiple datasets, inferences about individual children, and recommendations that influence how staff respond to them. Even if the system is intended to support professional judgement rather than replace it, its output may influence how a pupil is perceived, which interventions are prioritised, or whether a particular concern receives further attention. The distinction is important because AI does not need to make a final decision to have a material effect on an individual.

There is also a difference between understanding what a system is intended to do and understanding how it produces its outputs. A supplier may explain a product’s purpose without providing sufficient information about its limitations, the provenance of its data, the factors influencing its recommendations, or the circumstances in which it is likely to perform poorly. Some systems are inherently difficult to interpret, even for technically experienced users, whilst others may be easier to inspect but remain dependent on complex external models or services. An apparently transparent interface does not necessarily provide meaningful transparency into the underlying processing.

For schools, this creates a practical obligation to look beyond the product demonstration. What does the system actually do? What information does it use? What assumptions underpin its outputs? What can it access or change? How reliably has it been tested for the intended purpose? What happens when it is wrong? These questions should inform the decision to adopt AI, rather than being postponed until a problem arises.

2. The particular risks of processing children’s information

Schools already operate in a context where data protection requires careful judgement. The information they hold can reveal intimate details about a child’s circumstances, vulnerabilities, relationships, and experiences. This is particularly apparent where records include safeguarding concerns, mental health information, disability, SEND, family difficulties, or allegations of harm. Information of this nature may be necessary to support a child’s education and welfare, but its sensitivity makes the consequences of inappropriate access, disclosure, or interpretation especially serious.

The introduction of AI can create additional processing risks: information may be copied into an external service, used to generate new inferences, retained in prompts or logs, or made accessible through integrations that were not fully understood when the product was approved. Even where a supplier does not use customer information to train its model, other questions remain about retention, access, security, sub processors, and the purposes for which the information is processed.

A school might, for example, use an AI tool to summarise information relating to a pupil who has additional learning needs. The intention may be entirely legitimate, such as helping staff organise information or prepare for a meeting. However, if the source material includes sensitive information about the pupil’s health, family circumstances, or safeguarding history, the school must understand where that information goes, how the tool handles it, and whether the proposed processing is necessary and proportionate. The potential benefit does not remove the need for this assessment, nor is the risk confined to the disclosure of information. AI may generate inferences from existing records, combine information in ways that reveal previously unrecognised patterns, or produce summaries that omit important context. Those outputs may then influence subsequent decisions, creating consequences for the child even where no external disclosure has occurred. Accordingly, the accuracy and interpretation of information can be just as important as its confidentiality.

This is one reason why schools should be particularly cautious about introducing AI into safeguarding, SEND assessment, behavioural monitoring, or other contexts involving vulnerable children. The relevant question is not merely whether the system can perform the task, but whether it can do so reliably, fairly, and with safeguards appropriate to the potential consequences of error. The UK GDPR requires organisations to implement appropriate technical and organisational measures to protect personal data and safeguard individuals’ rights. The ICO’s guidance on data protection by design and by default reinforces the need to integrate these considerations into processing activities from the outset and throughout their lifecycle. In practice, this means privacy and security cannot be left to a final approval stage; they must influence the selection, configuration, and use of the technology itself.

3. Security, data breaches, and processing visibility

Data breaches and information-security concerns should not be treated as abstract risks, particularly in an educational environment where information about children may be involved. AI does not necessarily introduce a security vulnerability simply by being AI-enabled. However, it may change how information is accessed, transferred, processed, and retained. It can also introduce new interactions between users, models, external services, and other systems, increasing the importance of understanding the full processing environment.

A member of staff who enters information into an online AI service may not know whether the prompt is retained, whether the provider can access it, which sub processors are involved, or whether the service’s terms permit additional uses of the information. Similarly, an AI feature introduced through an existing supplier may alter the way information is processed without the school having fully considered the implications of that change. This creates a problem of visibility and, ultimately, an organisation cannot effectively govern processing that it does not know is taking place.

The issue becomes more significant where AI systems can access connected services, retrieve documents, execute actions, or interact with other applications. In these circumstances, security assessment needs to consider not only the model itself, but also the permissions granted to it, the data it can reach, and the actions it is authorised to perform. For example, an AI assistant that can only generate text presents a different operational risk from an agent that can search internal records, access staff mailboxes, or modify information in another system. The latter requires careful consideration of access permissions, authentication, logging, oversight, and the consequences of an erroneous or malicious instruction. Technical controls must reflect these differences and may include role-based access restrictions, multi-factor authentication, logging, restrictions on external connections, secure configuration, appropriate retention settings, and tested incident-response arrangements.

The National Cyber Security Centre’s guidance and the Department for Education’s cyber-security standards for schools and colleges provide useful foundations. For AI systems, these should be considered alongside product-specific risks, including the possibility of malicious instructions being embedded in material that a model processes. A supplier’s general assurance that its product is secure is not, by itself, sufficient evidence that it is suitable for the school’s intended use. The school needs to understand the controls available, establish which are enabled, identify any limitations, and determine whether the residual risk is acceptable.

4. Children, AI, and the reliability of information

Data protection is only one part of the wider governance challenge. As AI becomes more accessible, schools must also consider how children interact with systems that can generate convincing but inaccurate information, present uncertain claims with apparent confidence, or respond in ways that encourage users to accept their outputs without scrutiny. Generative AI can produce useful explanations, alternative perspectives, and accessible learning materials. However, fluency should not be confused with reliability: a response can be coherent, persuasive, and factually incorrect at the same time.

For children who are still developing their ability to evaluate sources, distinguish evidence from speculation, and recognise manipulation, this presents a particular concern. The problem extends beyond conventional misinformation. AI can generate fabricated quotations, synthetic images, misleading narratives, and apparently authoritative explanations that are difficult for an inexperienced user to verify. It may also reproduce or amplify existing biases. Malinformation adds another dimension. Unlike misinformation, which generally involves false or inaccurate information, malinformation concerns information used to cause harm, including information that may be factually true but is disclosed or deployed in a harmful context. AI may make it easier to package, amplify, or target such information, although the precise risks depend on the application and circumstances. Schools should therefore consider not only what an AI system can generate, but also how its outputs may be interpreted, shared, and relied upon by children.

There is also a legitimate question about the effect of habitual AI use on independent thinking. AI can support learning when it encourages pupils to explore ideas, test their understanding, and engage critically with information. Conversely, if pupils routinely rely on generated answers without working through the underlying reasoning, there is a risk that the technology may displace some of the cognitive effort that education is intended to develop. The extent of this risk will depend on the age of the pupil, the educational purpose, the design of the tool, and the way its use is supervised. It would be premature to assume that all AI use undermines independent thinking. Equally, schools should not dismiss the question simply because the technology offers convenience. The Department for Education’s generative AI product safety standards, updated in January 2026, explicitly address potential cognitive deskilling, emotional and social development, mental health, and manipulation. These considerations are therefore recognised within the government’s approach to assessing the safety of AI products intended for educational settings.

For schools, the implications are practical. Learner-facing systems should be assessed for age suitability, content moderation, the handling of disclosures, the potential for emotional dependency, and the extent to which they encourage rather than undermine independent learning. Children should also be supported to understand that AI-generated information requires evaluation, that AI systems do not possess the same understanding or accountability as a human professional, and that an apparently confident answer is not necessarily a reliable one. This is not an argument against introducing AI into education; rather, it is an argument for considering educational suitability alongside technical capability.

5. Why AI governance is a leadership responsibility

AI governance should not be delegated exclusively to IT teams or treated as a matter for the DPO to resolve in isolation. Its implications extend across teaching and learning, safeguarding, equality, cyber security, procurement, employment, intellectual property, and organisational accountability. Decisions about AI can influence how information is interpreted, how resources are allocated, and how children and staff are treated.

A school may have a legitimate reason to explore an AI-enabled product, but that does not establish that every proposed use is appropriate. Leaders need to understand the problem the technology is intended to solve, the evidence supporting its use, the alternatives available, and the consequences if the system fails. For multi-academy trusts, the challenge may be more complex, as different schools may have different needs, existing systems, and pupil populations. A trust-wide approach can establish consistent minimum standards, approved procurement arrangements, and clear accountability, whilst still allowing individual applications to be assessed in their own context. Effective governance should involve senior leaders, governors or trustees, the DPO, the Designated Safeguarding Lead, IT and cyber-security leads, relevant curriculum staff, and procurement or contract owners.

The DPO should be involved early enough to influence the decision, rather than simply being asked to review the documentation once the organisation has already committed to a product. However, the DPO should not be expected to assume responsibility for the school’s educational judgement or to approve every technology decision. The role is to advise on data protection obligations, monitor compliance, and provide independent advice and challenge, whilst the controller remains accountable for its processing. That distinction is crucial: a school cannot transfer its legal responsibilities to a software provider, nor can it rely on the DPO’s involvement as a substitute for informed decision-making by those responsible for the organisation.

6. Applying the UK GDPR to AI in schools

Where AI processes personal data, the UK GDPR and Data Protection Act 2018 apply, as amended by the Data (Use and Access) Act 2025 (DUAA). As of October 2026, the relevant DUAA provisions affecting data protection law have come into force. The DUAA has changed aspects of the framework, including the rules governing certain solely automated decisions. However, it has not removed the fundamental obligations to process personal data lawfully, fairly, and transparently, limit its use to appropriate purposes, maintain accuracy, and implement suitable security measures.

The legal analysis of an AI system must reflect the school’s actual use of that system. A supplier’s assertion that its product is GDPR-compliant does not establish that the school’s particular processing is lawful or appropriate.

Lawfulness, fairness, and transparency

Schools must identify an appropriate lawful basis under Article 6 of the UK GDPR. Where special-category data is involved, an additional condition under Article 9 is required, alongside any applicable requirements under the Data Protection Act 2018. The appropriate basis depends on the nature, context, and purpose of the processing. Consent is not automatically the most suitable choice, particularly where the relationship between the school and the individual may make it difficult to demonstrate that consent is freely given, for example, where there is an imbalance of power.

The school must also consider fairness. AI-generated inferences may be inaccurate, reflect bias, or disadvantage particular groups. This is particularly important where a system is used to assess behaviour, predict outcomes, or recommend interventions affecting pupils. Where relevant, schools must also consider their obligations under the Equality Act 2010, including the Public Sector Equality Duty where applicable.

Transparency must be meaningful. A privacy notice that is technically complete but incomprehensible to the intended audience does not, in practical terms, help people understand what is happening to their information. For children, information should be presented in an age-appropriate and accessible way. Depending on the use, it may also be necessary to explain whether AI generates recommendations, how staff review its outputs, and how concerns can be raised.

Purpose limitation and data minimisation

Personal data should be used for specified, explicit, and legitimate purposes. It should not be entered into an AI system merely because doing so might produce a more personalised or detailed response. A useful principle is to avoid introducing personal information where the task can be completed effectively without it. For example, a teacher seeking help with the structure of a parent communication could use an approved tool to generate a neutral template and then add the pupil-specific information within the school’s secure environment.

Where personal data is genuinely necessary, the school should consider whether the processing is proportionate and whether a less intrusive alternative would achieve the same purpose. Removing a person’s name or other direct identifiers does not, in itself, render the information anonymous. An individual may remain identifiable through other information contained within the dataset or by linking it with information available elsewhere. The distinction is important: pseudonymisation reduces the extent to which data can be attributed to an identifiable individual without the use of additional information, but pseudonymised data remains personal data where the individual is identifiable, directly or indirectly. The ICO’s guidance on pseudonymisation explains this distinction in further detail.

Anonymisation, by contrast, requires that individuals are no longer identifiable, taking account of the means reasonably likely to be used to identify them. This requires consideration of the information retained, the possibility of linking datasets, and the wider context in which the information may be accessed or used. Schools should therefore avoid assuming that data is anonymous simply because names have been removed. Where information is intended to be used in an AI system on the basis that it is anonymous, the effectiveness of the anonymisation should be assessed before the information is disclosed or processed. The ICO’s guidance on effective anonymisation provides further detail on assessing identifiability.

Schools should also consider the personal data generated or inferred by AI systems, rather than focusing solely on the information initially provided. For example, an AI system may infer that a child is vulnerable, disengaged, or likely to exhibit particular behaviours based on patterns in attendance, attainment, or other records. Such inferences may be inaccurate, lack sufficient context, or reflect biases within the data or model. Nevertheless, they may influence how a child is perceived, the support they receive, or decisions made about them. Where these inferences relate to an identifiable individual, they may themselves constitute personal data and must be subject to appropriate scrutiny, including consideration of their accuracy, fairness, and potential consequences.

Accuracy and professional judgement

AI-generated content must be checked against reliable evidence before it is relied upon in a consequential context. The appropriate level of verification will depend on the potential harm: a generic classroom exercise is different from a safeguarding record, formal pupil report, or recommendation concerning a child’s support needs. Staff should verify facts, preserve relevant context, and distinguish between established information and AI-generated suggestions or inferences. A fluent summary can still be misleading if it omits a qualification or changes the meaning of the source material, and responsibility for checking an output cannot simply be transferred to the technology.

Security and accountability

Schools should understand how information is processed, where it is stored, who can access it, whether sub processors are involved, and how long prompts, outputs, and logs are retained. Where a supplier acts as a processor, the contract must include the required Article 28 terms. Moreover, the parties’ roles must be determined by their actual activities, rather than simply by the labels used in a contract. The school should also maintain appropriate evidence of its decisions, including its lawful-basis assessment, risk assessments, supplier due diligence, relevant records of processing, privacy information, training, and monitoring arrangements. The objective is not to generate documentation for its own sake; it is to demonstrate that the organisation understands its processing and has implemented appropriate safeguards.

7. When should a school complete an AI DPIA?

A Data Protection Impact Assessment (DPIA) should be a central part of assessing any proposed use of AI that involves personal data within a school environment. Under Article 35 of the UK GDPR, a DPIA must be completed before processing begins where the proposed activity is likely to result in a high risk to the rights and freedoms of individuals. Although not every application of AI will automatically meet this legal threshold, the ICO recognises that, in the vast majority of cases, the use of AI is likely to involve high-risk processing. In an educational setting, the need for careful assessment is particularly compelling, given the vulnerability of children, the sensitivity of the information schools hold, and the potential consequences of inaccurate outputs, profiling, or inappropriate disclosure.

A DPIA should therefore be the starting point when considering an AI system that processes personal data. Where a school concludes that a DPIA is not legally required, it should be able to demonstrate how it reached that conclusion, taking account of the nature, scope, context, and purposes of the proposed processing, as well as the risks to the individuals affected. This is particularly important where AI involves children’s data, special-category information, safeguarding records, systematic monitoring, profiling, the combination of datasets, biometric technologies, or decisions that may significantly affect an individual’s education or welfare.

The assessment must go beyond identifying risks in general terms; it should examine whether the proposed processing is necessary and proportionate, whether a less intrusive alternative could achieve the same purpose, what harm could arise from inaccurate or biased outputs, and whether the proposed technical and organisational measures are sufficient to mitigate the risks. Where the supplier cannot provide enough information about the system’s functionality, limitations, data-processing arrangements, or safeguards, that uncertainty must form part of the assessment, as a school cannot meaningfully evaluate risks it does not adequately understand.

The DPIA should inform the decision to adopt the technology, rather than simply document a decision already made. Where a high residual risk cannot be sufficiently mitigated, the controller must consult the ICO before beginning the processing.

For schools, the question should not simply be whether a DPIA is technically required. It should be whether the organisation has sufficiently understood and assessed the risks to justify proceeding.

8. Automated decision-making and meaningful human oversight

The DUAA 2025 amended the UK GDPR provisions governing solely automated decision-making, introducing Articles 22A–22D. The amended framework permits certain significant decisions based solely on automated processing, subject to the applicable legal conditions and safeguards. It would be incorrect to suggest that all such decisions are prohibited, or that the involvement of a human reviewer automatically resolves every concern. Schools must assess the precise nature of the decision, the processing involved, and the relevant statutory requirements. This is particularly important where AI is used to influence decisions about admissions, attendance interventions, behaviour, educational pathways, safeguarding, or access to support. The relevant provisions can be found in section 80 of the Data (Use and Access) Act 2025.

A system may be presented as advisory, yet its recommendations can still influence professional judgement. If staff routinely accept its outputs without independent consideration, the practical effect may be more significant than the product description suggests. Meaningful human involvement requires more than a person clicking an approval button: the reviewer must understand the system’s limitations, consider relevant information beyond the automated output, be able to challenge the recommendation, and have the authority to reach a different conclusion. Where the applicable rules on solely automated significant decisions are engaged, the required safeguards must be implemented. These include relevant rights to information, human intervention, representation, and challenge, with additional restrictions where special-category data is involved.

Children merit particular consideration because they may have limited ability to understand how an automated inference has been reached or how to challenge its consequences. AI can support professional judgement; however, it should not quietly replace it.

9. Safeguarding, educational suitability, and children’s rights

AI governance must be considered alongside safeguarding and online safety, rather than treated as a separate compliance function. Keeping Children Safe in Education 2026, in force from the 1st of September 2026, provides the relevant statutory safeguarding guidance for schools and colleges in England. It reinforces the importance of a child-centred approach and the need for staff to understand their safeguarding responsibilities. The Department for Education’s generative AI product safety standards, updated in January 2026, provide a useful benchmark when assessing tools intended for educational settings. They address privacy, security, filtering, monitoring, cognitive development, emotional and social development, mental health, and manipulation.

For learner-facing AI systems, schools should consider whether the product is suitable for the intended age group, whether harmful content is effectively moderated, how safeguarding disclosures are identified and escalated, and whether the system encourages inappropriate reliance or emotional dependency. They should also consider whether children with SEND or other vulnerabilities may be affected differently, and whether the product has been tested with users whose needs reflect the school’s own pupil population. The supplier’s claims should be supported by evidence, as a product designed for education is not necessarily suitable for every educational setting or every child.

Data protection must also be understood in its proper context. For example, it does not prevent necessary and proportionate information sharing to protect a child. Equally, a safeguarding purpose does not automatically justify every form of monitoring, profiling, or data collection. The school must consider the circumstances, the information needed, the intended use, and the safeguards required. Decisions and their rationale should be recorded where appropriate.

10. Supplier due diligence: looking beyond the product demonstration

Procurement is one of the most effective opportunities to address AI risk before the technology becomes embedded in school processes. Before approving a product, schools should establish its intended purpose, educational suitability, data-processing arrangements, security measures, and limitations. The following questions provide a starting point.

Purpose and suitability

• What problem is the product intended to solve, and what evidence supports its claimed benefit?
• Which age groups and educational settings is it designed for?
• What personal data does it collect, generate, or infer?
• What are its known limitations, failure modes, and inappropriate uses?

Data protection and security

• Is school information used to train or improve models, and can this be disabled?
• What are the supplier’s actual roles under data protection law?
• Where is information stored, accessed, and processed?
• Which subprocessors are involved, and how are changes communicated?
• Are restricted international transfers taking place, and what safeguards apply?
• How long are prompts, outputs, and logs retained?
• How does the supplier support individual-rights requests?
• What technical and organisational security measures are in place?
• What audit logs, access controls, and incident-reporting arrangements are available?

Governance and termination of contract

• Where the supplier acts as a processor, does the contract contain the required Article 28 terms?
• How are changes to models, functionality, purposes, or terms notified?
• What filtering, moderation, and safeguarding controls are available?
• How has the system been tested for accuracy, bias, and accessibility?
• Can the school obtain evidence supporting the supplier’s claims?
• How will the supplier support the school following a personal data breach?
• Can the school suspend use, retrieve its information, and exit safely if the risk changes?

The level of scrutiny should be proportionate to the proposed use. For example, a tool that generates generic teaching resources does not necessarily require the same assessment as an AI agent that can access sensitive pupil records or influence significant decisions. The important point is that procurement should not be driven solely by functionality, price, or convenience. The school must be satisfied that the product is suitable for its intended purpose and that its risks can be managed effectively.

11. Integrating AI governance into existing processes

A common weakness in compliance is to treat governance as a separate activity that sits alongside the organisation’s actual operations. The result can be a collection of policies, assessments, and approval forms that exist on paper but have limited influence over everyday decisions. AI governance should instead be integrated into the systems and processes through which schools already manage risk, procure technology, assess suppliers, train staff, and review operational performance.

A practical framework should include the following stages:

• Discovery: Establish which AI tools and embedded features are in use.
• Purpose: Define the intended benefit and consider whether AI is necessary.
• Classification: Identify the nature of the processing, the people affected, and the likelihood and severity of harm.
• Assessment: Evaluate data protection, safeguarding, equality, security, educational, and contractual risks.
• Approval: Establish ownership, permitted uses, restrictions, and appropriate safeguards.
• Monitoring: Review effectiveness, incidents, complaints, supplier changes, and emerging risks.
• Retirement: Stop using systems that are ineffective, unnecessary, or no longer sufficiently safe.

These stages should inform existing governance arrangements rather than create an unnecessarily complex parallel system. Staff also need practical guidance: they should know which tools are approved, what information may be entered, how outputs should be checked, and who to contact before introducing a new application. The objective is to make responsible use easier to achieve, whilst ensuring that significant risks receive the scrutiny they require.

12. The role of the outsourced DPO

The role of an outsourced DPO is not to prevent every proposed use of AI, nor to provide blanket approval for technology that the organisation wishes to adopt. Rather, it is to understand the organisation’s circumstances, identify its legal obligations, assess the risks, and provide advice that is both technically informed and practically workable. That requires a logical, proportionate approach. The appropriate safeguards will depend on the intended purpose, the information involved, the people affected, the organisation’s operational requirements, and the consequences if something goes wrong.

A solution that is appropriate for one school may not be appropriate for another. Similarly, a control that is necessary for a high-risk application may be disproportionate for a routine task involving no personal data. Ultimately, effective advice should reflect those differences. It should also recognise that compliance cannot be achieved through documentation alone; policies and assessments must be reflected in the way systems are configured, suppliers are managed, staff are trained, and decisions are made. The DPO should provide constructive challenge where assumptions are weak, safeguards are insufficient, or the proposed use cannot be justified. Where risks can be managed appropriately, the DPO should help the organisation understand how to proceed responsibly.

This is the distinction between treating data protection as a tick-box exercise and integrating it into the organisation’s decision-making. The purpose is not simply to demonstrate that an assessment has been completed; it is to ensure that the assessment has improved the decision.

What should schools and trusts do now?

Schools do not need to resolve every question about AI before taking sensible action. They do, however, need to establish a clear understanding of their current position and prioritise the uses that present the greatest potential risks. Five actions provide a practical starting point:

• Identify AI tools and features already in use, including those embedded within existing supplier products.
• Establish clear restrictions on entering personal, sensitive, or confidential information into unapproved services.
• Agree ownership, approval arrangements, and the involvement of relevant professional leads.
• Prioritise high-risk applications involving children’s data, SEND, safeguarding, monitoring, profiling, or significant decisions.
• Integrate AI governance into existing procurement, data protection, cyber-security, safeguarding, and staff-training processes.

These actions should form the beginning of an ongoing programme of governance, rather than a one-off compliance exercise. AI systems, supplier arrangements, and organisational practices will continue to evolve, and the controls that are appropriate today may need to be revisited as the technology or its use changes. Ultimately, the question is not whether a school can use AI; it is whether the school can explain why it is using a particular system, demonstrate that the risks have been properly assessed, and show that appropriate safeguards remain effective.

Innovation should not be pursued without scrutiny. Equally, risk should not be used as a reason to reject every opportunity for improvement. The challenge is to distinguish between uses that offer a genuine benefit and those that introduce unnecessary complexity, unacceptable risk, or consequences that the organisation cannot adequately control.

How we can help

We support schools, academies, multi-academy trusts, independent schools, and colleges in developing practical, proportionate approaches to data protection and AI governance.

Our support includes:

• AI audits, inventories, and governance registers.
• AI governance frameworks, policies, and acceptable-use procedures.
• Data Protection Impact Assessments and risk assessments.
• Supplier due diligence, procurement advice, and contract reviews.
• Reviews of privacy notices, records of processing, and data-sharing arrangements.
• Staff, governor, and trustee training.
• Ongoing outsourced DPO advice and support.

Our approach is grounded in understanding the organisation, its circumstances, and the risks it needs to manage. We work to make data protection an integral part of operational processes and decision-making, rather than a separate exercise undertaken simply to demonstrate compliance.

Whether your school or trust is already using AI or considering a new system, we can help you assess the implications, identify appropriate safeguards, and make informed decisions about how to proceed.

The objective is not to adopt AI at any cost, or to avoid it at every opportunity. It is to ensure that innovation remains justified, proportionate, and accountable.

Contact Us to Discuss AI Governance and Data Protection Support for Your School or Trust

Who Needs to Maintain a Record of Processing Activities for GDPR?

Under Article 30 of the UK GDPR, organisations acting as data controllers or processors generally need to maintain records of their processing activities (RoPA). It applies to organisations of different sizes, but if you have fewer than 250 employees, then you may be exempt.  

TL;DR:

• Both data controllers and data processors must maintain a RoPA.
• Organisations with fewer than 250 employees are exempt from maintaining a RoPA, unless they regularly process data that poses a risk to the rights of the data subjects or includes special category data.
• A RoPA can still be good practice even if you are exempt, as it demonstrates a commitment to data protection. 

Who Must Maintain a Record of Processing Activities?

Both data controllers and data processors have RoPA obligations under Article 30; however, the records they maintain differ. 

Data Controllers 

Data controllers are organisations that decide why and how personal data is processed, e.g. a retailer or employer. Their records document their processing purposes, categories of data subjects and personal data, recipients, retention periods and security measures. 

Data Processors

Data processors are organisations that process data on behalf of a controller, e.g. payroll software or an email marketing agency. Their records cover the categories of processing carried out for each controller, as well as other Article 30 requirements. 

Organisational size or industry does not dictate whether you need to maintain a RoPA; instead, your data processing activity does.

Do Small Businesses Need a RoPA?

Yes. Small businesses often need to maintain a Record of Processing Activities, as size alone does  not automatically grant an exemption. Some may be exempt in limited circumstances, but having fewer than 250 employees doesn’t necessarily remove the requirement for a RoPA. 

If your processing activities fall under any of these conditions, you are required to maintain a RoPA:

• Your processing activities are likely to pose a high risk to data subjects’ rights and freedoms
• Your processing activities are not occasional 
• You process personal data relating to criminal convictions and offences
• You process special categories of personal data, including:
  • Racial or ethnic origin
  • Health condition
  • Trade union membership
  • Religious beliefs
  • Sexual orientation
  • Political opinions
  • Biometrics
  • Genetics

Should You Keep a RoPA Even if You’re Exempt?

Maintaining a RoPA can be good practice, even if your organisation qualifies for an exemption. There are several benefits, including:

• Understanding what personal data your organisation holds and why.
• Identifying data flows, retention requirements and potential risks.
• Supporting wider GDPR accountability and data protection compliance.

It can also make it easier to respond to data subject access requests and demonstrate compliance when required.

Get Help With Your RoPA

If you’re unsure about your obligations to maintain a RoPA, then get in touch. At Data Protection People, we offer ongoing data protection guidance, specialist outsourced support and training on maintaining records so we can tailor support where you need it most.

FAQs

Do charities and schools need a RoPA?

Charities and schools need a RoPA if they meet the requirements. This could be processing data such as employee records, donor information, pupil data and safeguarding information.

Do micro-organisations need a RoPA?

Micro-organisations are not automatically exempt because of their size. The exemption for organisations with fewer than 250 employees depends on whether processing is occasional, poses a risk to individuals or involves special category or criminal offence data. 

Can you be both a data controller and processor?

Yes, an organisation can act as a controller for some processing activities and a processor for others. For example, a business may control how it uses its employees’ information while processing customer data on behalf of another business. 

How to Create and Maintain an Effective RoPA

RoPA stands for Record of Processing Activities. It is a document that a business or organisation maintains to record how it collects, uses, stores and shares personal data. It is a legal requirement under UK GDPR.  

How To Get Started With Creating a RoPA

To start creating an effective RoPA, you must assess your resources. Are you able to use a tool or will you be using a spreadsheet? Who will manage the RoPA and how?

Your RoPA should be fit for your business, easy to maintain and understand. Ideally, it shouldn’t be granular, but not too in-depth; otherwise, you may end up with thousands of entries that are impossible to maintain correctly or efficiently. 

You should also have stakeholder buy-in from your organisation’s leadership to establish a top-down security culture. 

What Are the Core Elements Required in a RoPA?

The core elements required in a RoPA depend on whether your organisation is a data controller or a data processor.

If You’re a Data Controller:

Element	Description
Contact details	The name and contact details of your organisation, your joint controller, representative and Data Protection Officer.
Purposes of processing	A clear description of the reason why you are collecting and processing the personal data.
Categories of data subjects	The groups of people whose data you collect, e.g. employees, customers and suppliers.
Categories of personal data	The types of data being processed, e.g. names, financial data and health records.
Categories of recipients	Anyone who receives or will receive the data, including third-party processors, partners or other authorities
International data transfers	Details of any data transferred outside the EU/EEA, including the name of the country or international organisation, and the documentation of security safeguards.
Retention periods	The time limits for erasing the different categories of data.
Technical and organisational security measures	A general description of the security safeguards in place to protect the data.

If You’re a Data Processor:

Data processors are required to maintain records on behalf of all data processed for the controller, including:

Element	Description
Contact details	The name and contact information of the processor, each controller you work for and your DPO, if applicable.
Categories of processing	The types of processing operations carried out on behalf of each controller.
International data transfers	Details of data transfers outside the EU/EEA.
Technical and organisational security measures	A general description of your security safeguards.

How Must RoPAs Be Formatted?

There is no specific format mandated for RoPAs. However, Article 30 of the GDPR states that a RoPA must be in writing. This can be in paper or electronic form, though most organisations will benefit from an electronic RoPA as it is easier to maintain. 

If you’re using a spreadsheet, use tabs, standardised dropdowns and granular rows to keep things clear, consistent and clean.

How Often Should RoPAs Be Reviewed?

RoPAs should be reviewed at least annually, as well as whenever there is a change in how your organisation processes data. The information should be kept up to date, ready to present to regulatory authorities at any given moment. 

Need Support With Your RoPA?

At Data Protection People, we can support you in a number of ways. Whether you’re looking for RoPA training for your in-house team, general GDPR support or you’re in need of a DPO, we’re here to make RoPAs simple and easy. Get in touch with the team today.   

China’s Approach to AI Liability: Can Fault-Based Liability Keep Pace with AI?

China’s Supreme People’s Court (SPC) issued guidance on handling disputes involving artificial intelligence on 7 September 2026. The guidance provides a framework for applying existing laws to AI-related disputes, particularly where AI systems have caused harm. It addresses personality rights, the processing of personal data, intellectual property, consumer protection and AI-generated content.

Applying Existing Laws to AI

In my view, the most significant aspect of this guidance is not the specific liability rules themselves, but the use of judicial guidance to address AI-related disputes while China has not yet enacted a dedicated AI law.

AI technology is developing at a pace that often exceeds the speed of legislative processes. A comprehensive AI law may require frequent amendments as new technologies, risks and use cases emerge. Guidance that helps courts apply existing legal principles can provide greater flexibility while still promoting consistency in decision-making.

This does not mean judicial guidance replaces future AI legislation. Rather, it provides courts with a framework for applying the laws already in place.

The SPC’s approach appears to recognise that AI governance remains an evolving area. Rather than attempting to create rules for every possible future scenario, the guidance focuses on how existing legal concepts, such as fault and foreseeability, should be applied in an AI context. This allows courts to adapt their analysis as technology develops without requiring lawmakers to constantly revise legislation.

Fault-Based Liability and Its Exceptions

Another notable feature is the guidance’s clarification that fault-based liability applies to AI-related harms where existing law does not expressly provide for no-fault liability or presumed-fault liability. It is therefore a general approach, rather than a rule that applies to every AI-related claim.

When assessing fault, courts should consider factors including the specific application of the AI system, its degree of autonomy, technological and informational transparency, potential risks and their scope, preventative measures, and the relevant parties’ ability to foresee and control harm.

In my view, this reflects a balanced approach. It seeks to hold organisations accountable where appropriate while avoiding excessive liability that could discourage innovation.

Can Fault-Based Liability Keep Pace With AI?

However, the practical application of fault-based liability may present challenges. One of these is the increasing complexity of modern AI systems. Some AI technologies, particularly those designed to adapt through ongoing interactions and feedback, may evolve in ways that are not entirely predictable.

While developers are expected to identify foreseeable risks and implement appropriate safeguards, there may be circumstances where harmful outcomes arise despite reasonable testing and governance measures.

The guidance itself identifies technological transparency, the ability to foresee harm and the capacity to control risks as relevant factors when assessing fault. However, where an AI system produces an unexpected outcome based on patterns learned from large volumes of data, establishing whether a developer, provider or user acted negligently may become significantly more difficult.

In such cases, courts may need to assess not only what harm occurred, but also whether the organisation took reasonable steps to identify and manage risks beforehand.

The distinction between an unforeseeable AI outcome and a failure to implement appropriate controls may become one of the most important issues in future AI litigation.

Why Governance and Evidence Matter

The guidance also highlights the importance of evidence. For example, in certain copyright disputes, developers defending an infringement claim may be required to provide information about training data sources, training records and how the model operates.

More broadly, organisations should consider maintaining appropriate records relating to training data, model development, testing processes, risk assessments and complaint handling. These records may become important evidence of the measures taken to prevent harm and comply with applicable legal obligations.

This is a practical governance consideration, rather than a blanket record-keeping requirement imposed by the guidance for every AI system.

An Evolving Approach to AI Liability

Overall, China’s approach offers an interesting example of using judicial guidance alongside existing legislation to address AI-related disputes. It provides a framework that can develop through judicial practice while promoting greater consistency for courts and organisations.

That being said, future cases may test the limits of fault-based liability where AI systems behave in ways that are difficult to predict or explain.

As AI technology becomes increasingly sophisticated, courts may need to further develop principles around foreseeability, accountability and the standard of care expected from developers and deployers of AI systems.

Source: Supreme People’s Court guidance on AI-related disputes, published 7 September 2026 (Chinese-language original).

S2 Ep38: AI Systems and DPIAs

S2 Ep38: AI Systems and DPIAs

Can AI help you write a Data Protection Impact Assessment? And how do you assess the privacy risks of the AI system itself?

In S2 Ep38 of Data Protection Made Easy, Caine Glancy and Catarina Santos (Cate) explore both sides of the conversation: carrying out DPIAs for AI projects and using AI to help prepare an assessment.

What We Discuss

• Understanding how an AI system uses personal data, including its inputs, outputs and who can access them.
• Asking practical questions about suppliers, retention and where information goes.
• Using AI to organise information, suggest questions and identify gaps in a DPIA.
• Why project-specific information and human review remain important.
• Setting clear boundaries for how staff use AI tools.

Join Cate and Caine for a practical discussion about making informed decisions, checking assumptions and keeping people involved in the assessment process.

Watch or Listen to the Episode

Watch the Full Episode on YouTube

Listen to the Full Episode on Spotify

Join Our Community

Our free Friday sessions bring people together to discuss data protection topics, share practical advice and ask questions.

Explore Upcoming Sessions

Need Support With Your DPIA?

Our DPIA service helps you identify and assess privacy risks in new projects, systems or processes. We work with your team to document the assessment and recommend practical measures to reduce risks and support informed decisions.

Contact Data Protection People

S2 Ep37: Sector Spotlight Ep1: Caught Between the FCA and UK GDPR – What DPOs Need to Know

Sector Spotlight Ep1: Caught Between the FCA and UK GDPR – What DPOs Need to Know

Financial services businesses face overlapping responsibilities. How do they bring financial regulation and data protection together in practice?

In the first episode of Sector Spotlight, DPP’s Mark Farrell joins Phillip Garlick, CEO of Product Partnerships Limited (PPL), to discuss the relationship between FCA requirements and UK GDPR.

Created as part of the partnership between Data Protection People and PPL, this episode brings together perspectives on data protection, retail finance and the practical realities of running a regulated business.

Explore the Conversation

Our promotional clips explore financial promotions, whether good compliance can support business growth, the cost of compliance in the financial sector, and AI’s promise and peril in data protection.

Watch or listen to the full episode to hear the wider conversation with Mark and Phillip.

Meet Phillip Garlick

Phillip is the CEO of Product Partnerships Limited, which delivers retail financial solutions and compliance support to consumer-facing businesses. PPL helps these firms offer finance to their customers and manage the regulatory responsibilities that come with it.

He has over 30 years’ experience in regulated, consumer-facing sectors, with a strong focus on governance, risk management and sustainable growth.

Phillip is a practising Chartered Director and Fellow of the Institute of Directors. He holds an Advanced Certificate in Governance & Risk from the International Compliance Association and an MBA from Leeds University.

About Sector Spotlight

Sector Spotlight is a separate series within Data Protection Made Easy, exploring data protection through conversations focused on particular sectors. This is episode 1 of the series, rather than an episode in our regular Season 2 numbering.

Watch or Listen to the Episode

Watch the Full Episode on YouTube

Listen to the Full Episode on Spotify

Need Data Protection Support?

If your organisation needs help navigating its data protection responsibilities, speak to our team about the support available.

Contact Data Protection People

S2 Ep36: GDPR Radio – Data Protection News of the Week

S2 Ep36: GDPR Radio – Data Protection News of the Week

Cate and Caine are back together on GDPR Radio, and Cate marks the occasion with a little singing before the conversation gets underway.

In S2 Ep36 of Data Protection Made Easy, Caine Glancy and Catarina Santos catch up on data protection news and share practical perspectives on what it means for organisations.

Expect a friendly discussion, familiar faces and plenty of conversation about the world of data protection.

Watch or Listen to the Episode

Watch the Full Episode on YouTube

Listen to the Full Episode on Spotify

Join Our Community

Our free Friday sessions bring people together to discuss data protection topics, share practical advice and ask questions.

Explore Upcoming Sessions

Need Data Protection Support?

If your organisation needs help with a data protection question or challenge, speak to our team about the support available.

Contact Data Protection People

S2 Ep35: AI Redaction Tools: The Mistakes Most SAR Systems Miss

S2 Ep35: AI Redaction Tools: The Mistakes Most SAR Systems Miss

AI redaction tools promise to make handling subject access requests easier. But what might they miss?

In S2 Ep35 of Data Protection Made Easy, Amber Sivill and Katerina Douni discuss AI redaction tools and the challenges organisations face when using them to support SAR responses.

Join them for a practical conversation about technology, redaction and the importance of checking information before it is shared.

Watch or Listen to the Episode

Watch the Full Episode on YouTube

Listen to the Full Episode on Spotify

Join Our Community

Our free Friday sessions bring people together to discuss data protection topics, share practical advice and ask questions.

Explore Upcoming Sessions

Need Support With Subject Access Requests?

If your organisation needs help managing subject access requests or reviewing its redaction process, speak to our team about the support available.

Contact Data Protection People