What to think about before using Artificial Intelligence

What do we mean by AI?

1. The DPJL 2018 does not define AI and your legal obligations do not depend on whether you call your system AI or not. In simple terms, AI refers to computer systems that can learn from data and perform tasks that usually require human thinking, such as recognising patterns or making predictions.

2. A common type of AI is “machine learning,” where a computer uses a large amount of data to build a model that can classify information or predict outcomes. Most modern uses of AI (like image recognition, speech processing, or assessing credit risk) rely on machine learning.

3. Even if you do not call what you are doing AI or machine learning, the same data protection principles will usually apply if you are using data to build models and make decisions or predictions about people.

You may already be using AI without knowing it

4. Many organisations are already processing personal data through AI without realising it. AI is now built into many everyday tools and is often switched on by default. Before asking whether to use AI, check what is already running in your existing systems and software.

5. Common examples of Embedded AI that may already be active in your organisation include:

• Microsoft 365 Copilot: analyses emails, documents, and meeting recordings; can summarise and generate content based on data in your tenancy.
• Google Workspace AI features: similar summarisation and drafting tools across Gmail, Docs, and Meet.
• CRM and accounting software: many platforms (e.g. Xero, Salesforce, HubSpot) now include AI features that analyse customer or financial data.
• HR and recruitment platforms: applicant tracking systems increasingly use AI to rank or score candidates.
• Customer service chatbots: may be processing personal data in unstructured conversations.
• Security and monitoring software: some endpoint security or network monitoring tools use AI to detect anomalous behaviour.

6. Sole traders and small organisations are just as subject to data protection law as large ones. The obligations are the same; the scale of effort required is proportionate to the risk. The following examples illustrate common AI use cases in smaller organisations.

Example - Sole trader: AI already switched on

Sarah runs a small HR consultancy from home and uses Microsoft 365 for emails, documents, and client calls. Her Microsoft 365 package includes a feature called Copilot, which her IT provider switched on automatically. Copilot has been helping in the background by summarising emails and meeting notes, some of which include personal information about job candidates and employees.

Sarah did not make a conscious decision to start using AI. But now that she knows, there are a few straightforward things she can do to make sure she is working responsibly:

• Check Microsoft's terms to understand how they handle data processed by Copilot.
• Update her privacy notice to let clients and candidates know that AI tools may be involved in handling their information.
• Think about whether a DPIA is needed, given that some of the data relates to employment matters.
• Decide what works for her, for example whether to keep Copilot switched on for everything or limit it to lower-risk tasks.

The good news is that she is not in trouble. She just needs to take a few steps to get on top of it, the same way she would if she had started using any new tool that handles client data. (We have template DPIAs and Privacy Notices).

Example - Small retailer: AI-powered customer analytics

A small Jersey retailer uses an e-commerce platform that includes AI-powered customer analytics. The platform analyses purchasing behaviour and browsing patterns to suggest which customers to target with promotions and to predict which customers are at risk of churning. The retailer may not have thought this as 'using AI', but:

• The platform is processing personal data about identifiable customers using AI.
• The retailer needs a lawful condition to use personal information in this manner. Legitimate interests is likely the most appropriate basis, but a balancing assessment must be carried out and documented.
• The privacy notice must mention that customers’ data is used for AI-driven analytics and marketing.
• If the platform sends automated targeted marketing based on AI predictions, customers have the right to object (Art.36 DPJL 2018 — right to object to direct marketing).
• The retailer should check where customer data is stored and processed — many e-commerce platforms are US-based, which engages the [cross-border transfer] cross-border transfer requirements in Arts.66-67 DPJL 2018.

Your staff may be using AI without you knowing about it

7. Your employees may be using AI (such as ChatGPT, Claude or Co-Pilot for work tasks without your permission and this could mean personal data about your clients or colleagues is being shared with systems.

• Have you assessed what AI tools employees may be using on personal or unmanaged devices?
• Do you have an acceptable use policy covering AI tools?
• Does your policy specify which tools are approved and for what types of data?
• Have you told employees not to input personal data about clients, patients, or colleagues into unapproved AI tools?
• Do you have a process for employees to request approval for new AI tools?

8. If the answer to any of the above is no, you should take steps to address this. Start with the simplest actions first:

• Tell your staff clearly: even a short email or team message explaining that personal data must not be entered into AI tools that have not been approved is a meaningful first step.
• Write it down: add a short paragraph to your existing IT or data protection policy making clear which AI tools, if any, are approved for work use and what data can be used with them. You do not need a separate AI policy to begin with.
• Give people a route: make sure employees know who to ask if they want to use a new AI tool, so they come to you rather than simply going ahead.
• Think about what has already happened: if employees have been using unapproved tools, consider whether any personal data may have been shared and whether this needs to be assessed as a potential data breach.

9. The goal is not to stop people using helpful tools, but to make sure that when AI is used for work, you know about it and have checked that it is safe to do so.

What does AI have to do with data protection?

10. A common misconception is that once data has been processed by an AI, it is no longer personal data. This is not correct. You need to consider both what goes into an AI system and what comes out.

11. Personal data fed into an AI system remains personal data. If you input a customer’s name, medical history, financial details, or HR record into an AI tool, that data does not become anonymised simply because an algorithm has processed it. The DPJL 2018 continues to apply as do your responsibilities.

12. Outputs produced by an AI system about an identifiable individual are also personal data. A credit score, a risk rating, a candidate ranking, a performance assessment, or a health prediction generated by an AI is personal data if it relates to an identified or identifiable person. This means:

• Individuals can request access to AI-generated outputs about themselves.
• Inaccurate AI outputs about an individual can be the subject of a rectification request.
• You must be able to explain AI-generated outputs in response to rights requests.

Example - AI outout as personal data

A Jersey insurance company uses an AI model to calculate risk scores for individual policyholders. The score is generated automatically from anonymised-looking data inputs (postcode, vehicle type, claims history). The score relates to an identifiable individual and affects their premium.

The risk score is personal data. When a policyholder submits a subject access request, the company must be able to provide the score and a meaningful explanation of how it was calculated. The company cannot avoid this obligation by saying the AI is too complex to explain. Under the DPJL 2018, "because the AI worked it out" is not a sufficient answer. Individuals have a right to understand the reasoning behind automated decisions that affect them.

13. AI systems often rely on large amounts of personal data to work effectively, which brings them directly within the scope of data protection law. For example, AI may collect, analyse, and make predictions about individuals based on their behaviour, characteristics, or past activity. This raises issues around fairness, transparency, and accuracy, particularly where decisions are made or influenced by automated processing.

14. There is also a risk of bias if the data used to train the system is incomplete or unbalanced. This can lead to unfair outcomes – for example, a recruitment tool trained mostly on the CVs of previously successful candidates may learn to prefer certain characteristics that reflect historical patterns of discrimination rather than genuine job merit.

15. These risks require proactive assessment, governance, and ongoing oversight. Organisations should approach AI deployment with a lifecycle perspective, embedding data protection principles into design, procurement, operation, and review. Early assessment, clear accountability, and ongoing oversight are essential to ensure lawful, fair, and responsible use of AI.

16. Using an AI tool does not transfer your data protection responsibilities to the tool provider. Even if you are using a third-party product, you remain the data controller and are responsible for how it handles personal data.

A practical checklist – before you deploy AI

17. Before using any AI system that involves personal data, you should work through the questions below as a starting point.

We also have two fulsome checklists (one for general application and one tailored for HR professionals) which you can find in our related downloads section. Both explain “What to think about if you want to use an AI system”. These checklists are designed to help you think through the key issues step by step. You do not need to answer every question in detail but if you cannot answer a question at all, that is a sign you need to find out more before proceeding.

If you are deploying AI in a high-risk context (for example, making decisions about people's employment, finances, health, or benefits) you should seek specialist advice and contact us if you are unsure. You may also need to carry out a DPIA and formally consult with us.

Things to think about

What are the key data protection rules you need to follow?

Be clear about your purpose

18. Clearly define and document the purpose for which the AI system will be used. You should only use an AI system if it is necessary to achieve that purpose, and the amount of personal data used should be proportionate and no more than is needed.

Have a lawful basis

19. You need to identify a valid condition (a lawful basis) for processing personal data under Schedule 2 of the DPJL 2018 before you start. For ordinary personal data, you must satisfy at least one of the five conditions in Schedule 2 Part 1 of the DPJL 2018. If the AI processes special category data (such as health data, biometric data, or data revealing ethnic origin), you must instead identify a condition from Schedule 2 Part 2.

Be transparent

20. People have a right to know when AI is being used to process information about them. You must include information about AI use in your privacy notices, written in plain language (Art.12 DPJL 2018). If the AI makes or substantially influences decisions about individuals, you must explain the logic involved and the likely consequences.

Keep data accurate and to a minimum

21. Only use personal data that is necessary. Avoid feeding whole datasets into AI tools ‘just in case’. Ensure data is accurate and up to date because inaccurate training data can produce inaccurate and harmful outputs.

22. Be very cautious about inputting personal data into public-facing or third-party generative AI tools. Check the supplier's terms carefully. Unless you have specifically configured the tool to prevent it, your inputs may be used to train the AI model, which could constitute an unlawful transfer of personal data to a third party.

Automated decision-making

23. If your AI makes decisions about individuals automatically, and without a human genuinely reviewing each case, special rules under Art.38 DPJL 2018 apply. Individuals have the right to know, the right to ask for a human review, and the right to challenge the decision. A human ‘rubber-stamping’ an AI output without actually reviewing it does not count as meaningful human involvement.

Example - What meaningful human oversight looks like in recruitment

Going back to the recruitment AI example: the tool highlights the top-ranked applications, but an appropriately qualified or experienced recruiter then independently reviews each shortlisted CV before deciding who to interview. The recruiter has the authority to override the AI's ranking and does so in some cases. This is likely to constitute meaningful human involvement.

By contrast: a recruiter simply invites everyone ranked above a certain threshold for interview, without reviewing the individual CVs. The AI is effectively making the decision. This is likely to trigger the automated decision-making rules under Art.38 DPJL 2018, requiring the employer to inform candidates, provide a right to human review, and allow them to contest the outcome.

Carry out a DPIA

24. A DPIA (Data Protection Impact Assessment) is a structured way of checking whether your planned use of personal data is safe and lawful before you start. You should carry one out whenever using AI that could significantly affect individuals. If a DPIA identifies risks you cannot adequately mitigate, you must consult us before proceeding (Art.17 DPJL 2018). Use our DPIA template, available on our website, and submit it via our website.

25. You will almost certainly need one if any of the following apply:

• The AI makes or influences decisions about individuals, such as scoring job applicants, assessing credit, or determining benefits
• The AI processes sensitive information such as health data, biometric data, or information about ethnicity
• The AI monitors people, such as tracking employee activity or behaviour
• The AI processes information about children
• You are using a new or unfamiliar AI tool and you are not sure how it handles personal data

26. If you are a small organisation or sole trader, a DPIA does not have to be a lengthy document. The key question is: could this AI system affect people in a significant way? If the answer is yes, you need to think it through carefully and write down what you have considered and decided. If you are unsure whether you need a DPIA, the safest approach is to do one. It will help you identify problems early and before they affect the people whose data you are responsible for.

27. If after doing your DPIA you find risks you cannot fix or reduce, you must contact us before you go ahead. More information about DPIAs can be found here.

Look after the data — and have a plan if things go wrong

28. Implement appropriate security measures. If your AI system (or your supplier) suffers a data breach, you must report it us within 72 hours if it is likely to affect individuals' rights and freedoms (Art.20 DPJL 2018). Report breaches here. More information about breaches and how to handle them can be found here.

Choose your supplier carefully

29. If you use a third-party AI product, carry out due diligence. Make sure you understand: where your data will be stored and processed; whether the supplier uses it to train their AI models; what security measures they have; and what happens to your data if the contract ends. You must have a written data processing agreement in place if the supplier is acting as your data processor (Art.19 DPJL 2018). If data is processed outside Jersey, you must satisfy the international transfer requirements in Arts.66-67 DPJL 2018.

30. If you are using a third-party AI tool, ask the supplier directly whether they conduct bias testing, when it was last done, and what their findings were. If they cannot provide this, you should consider it as part of your supplier due diligence process.

31. We have a checklist to help you when you are considering using a third-party service provider or application. More information about what you need to do when appointing a processor can be found here, and information about processing personal data outside Jersey can be found here.

Keep reviewing

32. AI compliance is not a one-off exercise. AI systems can change over time, and so can the risks they pose. Review your DPIA, privacy notices, and supplier arrangements regularly. If you significantly update the AI system or change the data it processes, you should reassess from scratch.

Plan for the end

33. Think about what happens when you stop using the AI system whether because you switch suppliers, the product is discontinued, or you simply decide to stop. You should know:

• whether the supplier will delete your data or return it;
• whether your personal data may persist inside the supplier's AI model even after the contract ends; and
• what your data retention obligations are.

Build these questions into your supplier contracts and your DPIA from the outset and know the answers to these questions before you start using them.

Example - What happens to your data when the contract ends?

A Jersey estate agency signs up to a CRM platform with an AI feature that analyses client communication patterns to suggest follow-up actions. After two years, the agency decides to switch to a different platform. It cancels its subscription. The agency did not ask at the start whether the CRM supplier used customer data to train its AI model. It now discovers that clients' personal data (names, financial details, property preferences) may have been incorporated into the supplier's general model and cannot be deleted from it. The agency cannot satisfy potential erasure requests from clients. This is why data retention, model training restrictions, and exit provisions must be addressed in supplier contracts before signing, not after.

Responding to individual rights requests about AI

34. Individuals have the right to exercise data protection rights in relation to AI-processed data, just as they do for any other processing. In practice, AI systems can make it harder to respond to these requests. You should anticipate this and put systems in place before you deploy the AI, not after.

35. Practical steps to prepare:

• Document AI outputs contemporaneously. If an AI produces a score, recommendation, or decision about an individual, record it at the time - including what data was used as input and what the output was. Do not rely on being able to reconstruct this later.
• Ensure you can retrieve AI outputs about specific individuals. If your AI system does not allow you to search outputs by data subject, you may be unable to respond to subject access requests within the statutory timeframe.
• Prepare plain-language explanations of how your AI works. You do not need to disclose proprietary algorithms, but you must be able to explain the logic of AI-assisted decisions in terms that individuals can understand.
• Have a process for human review of AI decisions. Where an individual exercises their Art.38 right to human intervention, you must be able to deliver a genuine review not just a re-confirmation of the AI's output.
• Consider erasure requests carefully. Where personal data has been used to train an AI model, full erasure may not be technically possible. Document your position in advance and take reasonable steps where erasure is requested.

Registration

36. Data controllers and data processors established in Jersey are required to register with us under the Data Protection Authority (Jersey) Law 2018 (DPAJL 2018). If you are using AI systems that process personal data, this is a processing activity and you should be registered with us. Contact us or visit our website for guidance on registration requirements and exemptions.

What do we mean by AI?

1. The DPJL 2018 does not define “artificial intelligence,” and the applicability of data protection obligations does not depend on whether a system is labelled or characterised as AI. AI is best understood as an umbrella term covering computational systems designed to perform tasks that would ordinarily require human cognitive capabilities, including pattern recognition, reasoning, language processing, and decision-making.

2. AI systems can be classified in different ways. One common technical distinction is between rule-based (or symbolic) systems, which follow predefined rules, and data-driven systems, which learn patterns from data.

1. Rule-based systems operate according to predefined logic and do not learn from data.

2. Data-driven systems (particularly machine learning systems) use datasets to identify patterns and develop models capable of classification, prediction, or optimisation.

3. Machine learning itself encompasses approaches such as supervised learning (using labelled data), unsupervised learning (detecting patterns in unlabelled data), and reinforcement learning (improving performance through feedback).

4. More advanced machine learning techniques include deep learning using multi-layered neural networks.

3. A further important distinction, particularly in current deployments, is between predictive (or discriminative) AI and generative AI.

1. Predictive AI analyses existing data to identify patterns and make forecasts, classifications, recommendations or risk assessments e.g. fraud detection, credit scoring, or recruitment screening.

2. Generative AI systems are designed to create new content, such as text, images, audio, or code, based on patterns learned from training data. These systems, which often rely on large-scale foundation models, raise distinct considerations, including the potential to generate novel outputs that may reproduce, incorporate or infer personal data in less predictable ways.

4. AI can also be grouped by what it's capable of. Most AI you encounter today is "narrow" or "weak" AI i.e. systems built to do one specific thing, like recognise faces or recommend a playlist. More powerful forms, like "general" AI (which could handle any task a human can) or "superintelligent" AI (which would surpass human intelligence), are still largely concepts rather than everyday reality.

5. AI can also be described by how it processes information. The most basic type, reactive AI, simply responds to inputs with no memory of past interactions. A step up from that is limited-memory AI, which learns from historical data to make better decisions and this is what powers most modern AI tools. Beyond that, researchers talk about more advanced ideas like AI that understands human emotions ("theory of mind") or is even self-aware, but these remain theoretical for now.

How AI interacts with data protection?

6. The data protection regulatory framework is technology neutral. Where personal data is processed to train models, generate inferences, or inform decisions about individuals, data protection principles apply irrespective of how the system is referred to or characterised. The level of scrutiny required is informed by the nature, scale, and potential impact of the processing.

7. Different types of AI systems present varying degrees of complexity, opacity, and risk. For example, generative AI and deep learning models may be less interpretable and more difficult to constrain, raising enhanced issues around transparency, accuracy, and control over outputs. The iterative, data-intensive nature of machine learning means that data protection law is engaged at multiple stages of an AI system's lifecycle from the collection and curation of training data through to deployment, ongoing inference, and eventual decommissioning.

8. AI systems do not sit outside existing data protection frameworks – data protection encompasses AI systems or any use of personal information by any means. AI systems, they apply established principles and obligations in a context that may be more complex, iterative, and less transparent than conventional data processing. In particular, AI systems may involve the large-scale use of data, the generation of new information about individuals (such as predictions or inferences), and varying degrees of automation in decision-making.

9. You should therefore approach the use of AI by considering how core data protection requirements apply across the full lifecycle of the system. This includes, for example, how personal data is obtained and used, how outputs relating to individuals are generated and relied upon, and how risks to individuals are identified and managed. The specific implications will depend on the nature of the AI system, including its design, level of autonomy, and the extent to which it affects individuals.

10. The following sections set out more detailed guidance on how key data protection obligations (such as the data protection principles, lawful basis, transparency, individual rights, and impact assessments) apply in the context of AI systems.

Personal data: inputs, outputs and anonymisation

11. Controllers must consider whether personal data is present at every stage of an AI system's operation, not just at the point of initial data collection. Why?

12. Personal data fed into an AI system as input remains personal data subject to the DPJL 2018. Processing it requires a Schedule 2 condition and compliance with all data protection principles. The fact that the data is processed algorithmically does not alter its character or mean that falls outside the scope of data protection law.

13. Outputs generated by an AI system about an identifiable individual (including scores, predictions, risk ratings, classifications, recommendations, and profiles) constitute personal data in their own right. This has practical implications for controllers:

• AI-generated outputs are subject to subject access requests.
• Inaccurate outputs about individuals may be the subject of rectification requests.
• Where outputs are used to make significant decisions, they are within scope of Art.38 DPJL 2018 and protections for automated decision-making.
• Outputs must be retained and retrievable to enable compliance with individual rights.

14. Anonymisation of AI training data is technically challenging. A dataset that appears anonymised may be re-identifiable when combined with other data, or when processed by a sufficiently powerful model (is anonymisation reasonably likely). Controllers should not assume that removing names and obvious identifiers from training data achieves lawful anonymisation. Where anonymisation is relied upon to take data outside the scope of the DPJL 2018, it should be subjected to a rigorous technical assessment, including consideration of the risk of re-identification by the AI model itself.

The data protection principles (Art.8 DPJL 2018)

15. The data protection principles in Art.8 of the DPJL 2018 require that personal data is:

• Processed lawfully, fairly, and transparently (Art.8(1)(a))
• Collected for specified, explicit, and legitimate purposes and not processed incompatibly with those purposes - purpose limitation (Art.8(1)(b))
• Adequate, relevant, and limited to what is necessary - data minimisation (Art.8(1)(c))
• Accurate and kept up to date (Art.8(1)(d))
• Not kept longer than necessary (Art.8(1)(e))
• Processed securely using appropriate technical and organisational measures - integrity and confidentiality (Art.8(1)(f))

16. All these principles apply equally to AI systems. The fact that processing is performed by an algorithm rather than a human does not affect a controller's legal obligations.

Roles and responsibilities (controller/processor)

17. You should determine, at an early stage, whether you are acting as a controller, joint controller (Art.7 DPJL 2018), or processor in relation to any AI system. This assessment should reflect who determines the purposes and means of the processing, including decisions about model design, training data, and deployment. Where third-party AI tools or platforms are used, you should carry out appropriate due diligence and ensure that roles and responsibilities are clearly allocated in contractual arrangements. You should not assume that a supplier is a processor without assessing whether it exercises sufficient autonomy to be considered a controller in its own right.

Lawful conditions for processing (Art.9 and Schedule 2 DPJL 2018)

18. Art.9(1) of the DPJL 2018 provides that processing is only lawful if it meets at least one of the conditions specified in Schedule 2. The relevant Part of Schedule 2 depends on whether the data being processed is ‘ordinary’ personal data or more sensitive special category data.

19. Schedule 2 Part 1 of the DPJL 2018 sets out five conditions for processing ‘ordinary’ personal data. In the AI context, the most commonly relevant are:

• Consent (Schedule 2, Part 1, para.1): The individual has given consent. Consent must be freely given, specific, informed, and unambiguous (Art.11 DPJL 2018). It is rarely the most appropriate condition for AI used in employment or public service contexts given the inherent power imbalance. Individuals must be able to withdraw consent easily, and withdrawal of consent must be effective.

• Legitimate interests (Schedule 2, Part 1, para.5): Processing is necessary for the legitimate interests of the controller or a third party, except where those interests are overridden by the individual's interests or fundamental rights and freedoms. In the context of AI systems with significant effects on individuals, this balancing exercise may be more difficult to satisfy and should be documented carefully.

• Contract (Schedule 2, Part 1, para.2): Processing is necessary to perform a contract with the individual or to take pre-contractual steps at their request. May apply where AI is used to process insurance or mortgage applications.

20. Where an AI system processes special category data (including where such data may be inferred or generated by the system) you must identify a condition from Schedule 2 Part 2 of the DPJL 2018 instead. (You do not need to satisfy both Part 1 and Part 2; Part 2 conditions are self-contained and cover both the lawfulness of the processing and the additional justification for using sensitive data.)

21. The Schedule 2, Part 2 conditions most commonly applicable in the AI context include:

• Explicit consent of the data subject (Schedule 2, Part 2, para.6)
• Processing necessary in the employment and social fields (Schedule 2, Part 2, para.8) (e.g. HR AI tools including in a recruitment context).
• Processing necessary for the performance of a public function (Schedule 2, Part 2, para.13).
• Processing necessary for reasons of substantial public interest (Schedule 2, Part 2, para.14).

Example - Bias in recruitment AI

A company uses an AI tool trained on its own historical hiring data to screen CVs. Because past successful candidates were predominantly male, the system learns to favour male-coded attributes. As a result, female applicants are systematically disadvantaged - not because of an intentional decision, but because the bias is embedded in the training data.
This is likely to amount to unfair processing under the DPJL 2018 and may also raise issues under Jersey’s discrimination legislation.

• Carry out regular bias audits for AI tools.
• Test outputs across relevant demographic groups.
• Take remedial action promptly where disparities are identified.

You should assess whether special category data may be indirectly inferred from apparently non-sensitive data. For example, a model trained on postcode and purchasing data may effectively infer ethnicity. Where an AI system generates or infers special category data, an applicable Schedule 2, Part 2 condition should be identified for that aspect of the processing.

22. You should clearly define and document the purpose(s) for which the AI system is used and ensure that processing is necessary and proportionate. You must identify a valid lawful basis under the DPJL 2018 for each processing activity and ensure it applies across all stages of the AI lifecycle. You should assess fairness, including whether the use of AI is within individuals’ reasonable expectations and whether it may have unjustified adverse effects. Where personal data is reused for training or further development, you should assess compatibility with the original purpose.

AI in employment, HR and recruitment

23. AI is increasingly used in employment contexts - to screen job applications, monitor employee performance, schedule shifts, assess engagement, or predict which employees are likely to leave. This area carries particular risks because of the power imbalance between employer and employee, the use of employment-related data (which may include special category data), and the significant impact that AI-driven decisions can have on individuals’ livelihoods.

Example - AI in recruitment

A recruitment company uses an AI tool to help sort through job applications. When candidates submit their CVs, the system scans and analyses them to identify key information such as skills, qualifications, and work experience. It then compares this information against the job requirements and highlights the applications that appear to be the best match. This helps recruiters handle large volumes of applications more quickly by focusing their attention on the most relevant candidates.

However, this use of AI raises important data protection questions:

• The candidates need to be told that their data is being processed by an AI system.
• The employer needs a lawful basis for this processing.
• If the tool automatically filters out candidates without a human reviewing each decision, additional rules on automated decision-making apply (see below).
• The employer must check that the tool does not produce biased results - for example, inadvertently disadvantaging female applicants or those from certain ethnic backgrounds.
• A DPIA should be carried out before the tool is deployed.

Example - AI employee monitoring

A medium-sized financial services firm introduces an AI tool that monitors employee productivity across their entire workforce. The system tracks keystrokes, mouse activity, application usage, and time spent on tasks, and produces a daily 'productivity score' for each employee. Managers use this score to inform performance reviews (including performance improvement processes) and decisions about bonuses and promotions.

This raises serious data protection concerns:

• The productivity score is personal data about each employee (it relates to an identifiable individual and affects their employment).
• The processing is likely to involve special category data if the system picks up on health-related absences or patterns suggesting a disability.
• Employees cannot meaningfully consent in an employment context — there is too great a power imbalance. The employer would need to rely on a different Schedule 2 condition.
• A DPIA is mandatory given the scale and nature of the monitoring.
• The productivity score must be explainable to employees who request it.
• If the score automatically triggers decisions about pay or performance without human review, Art.38 DPJL 2018 applies.
• The employer must be transparent: employees must be told what is being monitored, how scores are calculated, and how they are used.

24. Controllers deploying AI in an HR/employment context should pay particular attention to:

• Lawful condition: consent will generally not be an appropriate Schedule 2 condition for AI processing of employee data, given the employment relationship's inherent power imbalance. Legitimate interests or, where applicable, a Schedule 2 Part 2 employment-related condition (para.8) is more likely to be appropriate, subject to a documented assessment.
• Transparency: employees must be informed (before monitoring begins) that AI tools are used, what data is collected, how it is processed, and how outputs are used in employment decisions. This information should be included in employment contracts, staff handbooks, and privacy notices. In a recruitment context, potential candidates need to be told at the point of application that AI is being used as part of the recruitment process and how those systems may impact on their application.
• Bias and discrimination: AI tools used in recruitment or performance assessment that are trained on historical data may reproduce or amplify existing discriminatory patterns. Regular testing and bias audits across protected characteristics are essential.
• Automated decisions: The use of AI systems that produce performance scores, productivity ratings, or candidate rankings that directly inform employment decisions without meaningful human review may engage Art.38 DPJL 2018.
• Special category data: Employee monitoring systems may collect or infer health data, disability-related information, or information about absences. Where such processing is carried out on a large scale, a DPIA will generally be required.

AI in education and with children

25. Children are considered a vulnerable group for the purposes of data protection law. AI systems that process children’s personal data, whether in schools, charities, online services, or other contexts, require a particularly high standard of care. The DPJL 2018 does not reduce obligations where children are involved; in many respects, the obligations are more stringent.

26. Key considerations when AI systems involve children include:

• Consent: children may lack the capacity to give meaningful, freely given, informed consent to AI processing. A child’s consent should not be relied upon as the lawful condition without careful consideration of whether it is valid. In many educational contexts, parental or guardian involvement will be required for younger children, although consent may still not be the most appropriate lawful condition.

• Transparency: information about AI processing must be presented in a way that children and their parents or guardians can actually understand.

• Special category data: educational AI systems frequently process data that either constitute, or may reveal, special category data, including information relating to learning difficulties, SEND requirements, mental health, or behaviour. An applicable Schedule 2, Part 2 condition is therefore required.

• Profiling: AI systems that builds profiles of children based on their behaviour, learning patterns, engagement or wellbeing raise heightened risks. A DPIA will almost certainly be required.

• Automated decisions: AI systems that make or substantially influence decisions about a child's educational pathway, support needs, safeguarding or behavioural management requires meaningful human oversight.

• Data minimisation and retention: only data that are necessary should be collected, and children’s personal data should not be retained for longer than necessary. Particular consideration should be given to whether profiles, behavioural assessments, or inferred outputs generated during a child’s education or involvement with support services should be deleted once no longer required.

Example - AI learning platform in a school

A Jersey school subscribes to an AI-powered learning platform. The platform monitors each pupil’s responses, time taken to complete tasks, and error patterns to generate a personalised learning plan. It also flags pupils who appear to be struggling to the class teacher.

The school is a data controller for this processing. Key obligations include:

• The platform processes children’s personal data, including data that may reveal learning difficulties or support needs, which may constitute special category data. An applicable Schedule 2, Part 2 condition is therefore required.
• A DPIA should be completed before the platform is deployed.
• Parents, guardians and pupils (where age-appropriate) must be informed in clear, plain language about what the AI system does, what data it collects, and how the outputs are used.
• The school must carry out due diligence on the platform provider including whether pupils’ data are used to train models, where data are stored, and what happens to the data when the service ends.
• Decisions relating to pupils’ educational needs and support should remain subject to professional judgment by teachers. AI outputs should support, rather than replace, human decision-making.
• The school should check whether the platform has any features that produce automated assessments, behavioural flags or recommendations that could affect a pupil’s educational record or opportunities without meaningful teacher review.

Example - Charity using AI with vulnerable young people

A Jersey youth charity introduces an AI chatbot on its website to provide initial support to young people seeking help. The chatbot asks questions about the young person's situation and directs them to relevant resources or escalates the matter to a human support worker.

This raises significant data protection considerations:

• The chatbot is likely to process special category data relating to children, including information about mental health, family circumstances, abuse, safeguarding concerns, or harmful situations. This is special category data. A Schedule 2 Part 2 condition (most likely substantial public interest or vital interests) must be identified.
• A DPIA should be completed before deployment.
• The chatbot must not mislead users into believing they are communicating with a human where the interaction is automated. Transparency regarding the use of AI is essential.
• Data collected through the chatbot must be securely stored and not used for any purpose other than providing support.
• The charity must have robust escalation procedures so that human intervention occurs promptly where safeguarding risks arise.
• Particular care should be taken in relation to retention periods, access controls, and the storage of chatbot conversations.

Data protection by design and by default

27. Art.15 of the DPJL 2018 requires you to embed data protection considerations into the design, development, and deployment of AI systems. You must implement appropriate technical and organisational measures from the outset. This includes:

• Selecting system architectures and design choices that minimise the processing of personal data.
• Implementing safeguards to reduce risks, including pseudonymisation, role-based access controls, and security measures proportionate to the sensitivity of the data.
• Ensuring that default settings are privacy-protective so that individuals are not required to take additional steps to protect their privacy.
• Being able to demonstrate that data protection has been considered systematically throughout the AI lifecycle.

Transparency and fair processing (Arts.10 and 12 DPJL 2018)

28. Art.10 of the DPJL 2018 requires personal data to be processed fairly and transparently. Art.12 requires controllers to provide individuals with clear, accessible, and intelligible information about the use of AI systems. In the AI context, privacy information should explain:

• That AI systems or automated processing are being used, and the purposes for which they are being used.
• The categories of personal data processed by the AI system.
• Whether the AI makes or substantially influences decisions about individuals.
• Where decisions are made solely by automated means, meaningful information about the logic involved, together with the significance and likely consequences of the processing for the individual.

29. Fairness requires that processing does not produce unjustified adverse effects on individuals. In the AI context, this means ensuring that explanations of AI-assisted decisions are meaningful and proportionate to the risks involved. Controllers should also maintain sufficient internal documentation to explain how the system operates, including its logic, limitations, intended purposes, and safeguards.

Data minimisation, purpose limitation, and accuracy

30. AI systems tend to require large volumes of data, but the data minimisation principle (Art.8(1)(c) DPJL 2018) requires that only data that is adequate, relevant, and necessary is processed. You must:

• Critically evaluate what personal data is actually required for the AI system to function.
• Assess the provenance, relevance, and quality of training, testing, and validation datasets.
• Avoid feeding entire datasets into AI tools indiscriminately (this is likely to breach data minimisation and purpose limitation requirements).
• Consider whether AI-generated outputs (scores, predictions, profiles) constitute personal data independently.
• Maintain processes to ensure ongoing accuracy (Art.8(1)(d) of the DPJL 2018), including mechanisms to correct or erase inaccurate data.

31. Purpose limitation (Art.13 of the DPJL 2018) is particularly important in the generative AI context. If your organisation uses a commercial generative AI tool, avoid inputting personal data into commercial generative AI tools unless you have confirmed that it may use inputs to retrain or improve its models. This may constitute processing for a new and incompatible purpose, or a disclosure of personal data to a third party requiring a fresh lawful basis under Schedule 2, and potentially a new transparency obligation under Art.12 of the DPJL 2018.

Fairness, bias and discrimination

32. You must assess and mitigate the risk that your AI system produces biased or discriminatory outcomes. AI systems trained on historical data may replicate and amplify existing patterns of inequality present in that data, even without discriminatory intent. You should:

• Test datasets and model outputs for bias, including indirect or proxy discrimination and disparate impacts on protected groups.
• Implement appropriate technical and organisational mitigation measures and monitor outcomes on an ongoing basis.
• Ensure that bias assessments and fairness considerations are documented and revisited whenever systems are updated or retrained.
• Retain human oversight of automated decisions, while remaining aware that human reviewers can themselves introduce bias.

Example - Bias in recruitment AI

A company uses an AI tool trained on its own historical hiring data to screen CVs. Because historically successful candidates were predominantly male, the model learns to favour attributes more commonly associated with male candidates in the training data. Female applicants are systematically disadvantaged, not because of any deliberate decision, but because the bias was built into the training data.

This is likely to constitute unfair processing under the DPJL 2018 and could give rise to discrimination under the Discrimination (Jersey) Law 2013. Controllers should conduct regular bias audits at least at each retraining cycle and at regular intervals during deployment of AI tools, test outputs across demographic groups, and take remedial action where disparities are identified.

Automated decision-making (Art.38 of the DPJL 2018)

33. Art.38 of the DPJL 2018 provides individuals with the right not to be subject to a decision based solely on automated processing (including profiling) that produces legal or similarly significant effects. This is one of the most important provisions in the context of AI deployment.

34. In the context of AI systems, Art.38 commonly engages where:

1. The decision is based solely on automated processing (no meaningful human involvement).
2. The processing includes profiling (evaluating aspects of personality, behaviour, performance, preferences, etc.).
3. The decision produces legal or similarly significant effects on the individual.

35. 'Similarly significant effects' is construed broadly. It covers, for example: automatic rejection of a credit or mortgage application; AI-driven shortlisting in recruitment without genuine human review; automated account suspension triggered by algorithmic fraud detection; and algorithmic determination of benefits eligibility.

36. Solely automated decisions with significant effects are only permitted where:

1. Necessary for entering into or performing a contract between you and the individual;
2. Authorised by law (which also lays down suitable measures to safeguard the data subject’s rights and freedoms and legitimate interests); or
3. The individual has given explicit consent.

Examples
Necessary for a contract: An online lender automatically approves or declines a loan application based on credit score and income.
Authorised by law: A tax authority is legally permitted to use automated systems to flag suspected fraud, provided the law guarantees a right to human review.
Explicit consent: A dating app explicitly asks users to consent to fully automated compatibility scoring that determines which profiles are shown or hidden, where this has a significant effect on their experience.

37. Where you rely on contract necessity or explicit consent (paragraphs 42(a) and 42(c) above), you must still inform the individual that solely automated decision-making is taking place, give them the ability to request human review, allow them to express their point of view, and ensure they can contest the decision and, where the authorising law does not provide otherwise, the same safeguards are recommended where reliance is placed on paragraph (b).

38. A human 'rubber-stamping' an AI output without genuinely reviewing it does not constitute meaningful human involvement. To be meaningful, human review must involve a person who has the authority to change the AI's output, actually reviews the underlying data (not just the AI's recommendation), and exercises genuine independent judgment.

Example - Meaningful oversight in credit and recruitment

A lender deploys an AI credit-scoring model that automatically approves or rejects applications. A human reviewer is technically in the loop but in practice follows the model's output in over 95% of cases and rarely examines the underlying data. This is unlikely to constitute meaningful human involvement and the Art.38 DPJL 2018 protections will apply.

Compare this with a recruitment scenario where an AI tool ranks CVs, but a recruiter independently reviews each shortlisted application and has authority to override the ranking and has a documented history of doing so. This is more likely to constitute genuine oversight, provided the recruiter is actually engaging with the individual merits of each application rather than treating the AI output as determinative.

The controller must ensure, and be able to demonstrate, that the process delivers genuine oversight, rather than nominal compliance.

Data Protection Impact Assessments (Art.16 of the DPJL 2018)

39. Art.16 DPJL 2018 requires controllers to conduct a DPIA before carrying out processing likely to result in a high risk to individuals' rights and freedoms. A DPIA is mandatory where the AI system involves:

• Systematic and extensive profiling based on automated processing producing significant decisions about individuals (Art.16(1)(a)).
• Large-scale processing of special category data (Art.16(1)(b)).
• Systematic monitoring of publicly accessible areas (Art.16(1)(c)).

40. Even where not strictly mandatory, a DPIA is strongly recommended whenever an AI system: is novel or uses technology whose privacy implications are not well understood; processes data about vulnerable individuals; could significantly affect individuals' life circumstances; or involves automated processing that individuals might not expect.

41. In addition to the standard requirements in Art.16(6) DPJL 2018, a DPIA for an AI system should address:

• A description of the AI system — type of model, training data (including personal data used), outputs produced, and how those outputs are used.
• The purposes of processing and the Schedule 2 condition relied upon.
• An assessment of the accuracy and reliability of the AI system's outputs and the limitations of those outputs.
• An assessment of the risk of bias, discrimination, or unfairness.
• Technical and organisational measures to mitigate risk — including human oversight mechanisms, bias testing, model monitoring, and data security.
• How individuals will be informed about the AI's use of their data.
• How individual rights (including Art.38 rights regarding automated decision-making) will be upheld and facilitated.

42. A DPIA for an AI system is not a one-off exercise. AI models can drift over time — their performance and outputs can change as conditions change. Treat your DPIA as a living document, reviewed whenever there is a material change to the AI system, the data it processes, or the context in which it is deployed including where the system is applied to new categories of individuals or decisions not originally anticipated. Records of DPIAs, including the risks identified and measures adopted, must be retained as part of your accountability documentation.

43. If your DPIA reveals high risks to individuals that you cannot adequately mitigate, Art.17 DPJL 2018 requires you to consult us before commencing processing. You should submit your DPIA via the secure portal on our website. We will provide written advice within eight weeks (or fourteen weeks in complex cases).

Individual rights (Part 6 of the DPJL 2018)

44. The individual rights in Part 6 of the DPJL 2018 apply in full to AI-related processing, including where personal data is processed as part of training, testing, deployment, or output generation. Key considerations include:

1. Right of access (Art.28 DPJL 2018): AI-generated outputs relating to an individual (such as a credit score, risk profile, or HR assessment) may themselves constitute personal data subject to the right of access. Ensure such outputs can be retrieved and disclosed in response to access requests. You must also be able to provide a meaningful explanation of any AI-assisted decision, and respond within statutory timeframes notwithstanding any technical complexity.

2. Right to rectification (Art.31 DPJL 2018): Where an AI system has produced inaccurate outputs about an individual that have been acted upon or relied upon as factual, those outputs should be corrected or deleted or, where correction is not possible, suppressed. Have mechanisms in place to handle rectification requests relating to AI-generated data.

3. Right to erasure (Art.32 DPJL 2018): Where personal data has been used to train an AI model, erasure requests create significant technical complexity. It may not be possible to delete a specific individual's contribution from a trained model without retraining it entirely. Document your approach, take reasonable technical steps, and where full erasure is technically infeasible consider proportionate mitigating measures such as data suppression or model retraining. You should also consider whether, pending full erasure or retraining, the affected data should be suppressed from active use.

4. Right to restriction (Art.33 DPJL 2018): Where an individual contests the accuracy of AI-generated data, or objects to processing pending determination of a legitimate interests assessment, you may be required to restrict processing of that data. Ensure your systems can implement and lift restrictions at the level of individual data records.

5. Right to object (Art.35 DPJL 2018): Where you rely on legitimate interests (Schedule 2 Part 1, para.5) or public functions as your condition for processing, individuals can object. You must stop the processing unless you can demonstrate compelling grounds that override the individual's interests, rights and freedoms.

6. Rights regarding automated decision-making (Art.38 DPJL 2018): Individuals have the right to obtain human intervention, express their point of view, and contest any solely automated decision that produces significant effects. Ensure your processes can deliver this in practice.

Security and resilience (Art.21 of the DPJL 2018)

45. Art.21 of the DPJL 2018 requires you to implement appropriate technical and organisational security measures to protect personal data including throughout the AI lifecycle. This includes:

• Access controls based on the principle of least privilege, encryption, and secure development practices ensuring that only those with a genuine operational need can access personal data processed by the AI system.
• AI-specific risks, including model inversion attacks (extracting training data from a model), membership inference (determining whether an individual's data was used in training), data leakage, and adversarial attacks (manipulating inputs to produce incorrect outputs).
• Regular testing, monitoring, and audit of AI systems, including monitoring for unauthorised use of AI tools on personal or unmanaged devices.
• Incident response procedures, including breach notification.

46. In the event of a data breach involving an AI system or supplier, you must notify us without undue delay and, where feasible, within 72 hours if the breach is likely to result in a risk to individuals' rights and freedoms (Art.20 DPJL 2018). Report here.

47. Where the breach occurs at the level of an AI supplier or processor, your processor contract should require the supplier to notify you without undue delay so that you can meet your own notification obligations. Where AI systems are supplied by third parties, you must ensure that appropriate data processing agreements are in place and that contractual obligations address security standards, breach notification, and audit rights.

Vendor management and processor contracts (Art.19 of the DPJL 2018)

48. When deploying AI built or operated by a third party, you must:

• Determine whether the third party is acting as a data processor (processing on your behalf and on your instructions) or as a separate data controller in its own right.
• If acting as your processor: enter into a written data processing agreement compliant with Art.19 DPJL 2018.
• If acting as a joint controller: document your respective responsibilities in a transparent arrangement (Art.7 DPJL 2018).

If the third-party processes personal data for its own purposes beyond your instructions (for example, using inputs to develop or improve its own models), it may be acting as an independent controller for that processing. You cannot legitimise that processing through a data processing agreement. You must assess whether it is permissible and, if not, avoid inputting personal data into that system.

49. When selecting an AI supplier, carry out due diligence. You must only appoint processors that provide sufficient guarantees of appropriate technical and organisational measures to protect personal data (Art.19(1) DPJL 2018). This includes:

• Reviewing the supplier's privacy documentation and terms of service.
• Understanding whether the supplier uses customer data to train or improve its AI models — and if so, on what legal basis and whether individuals have been informed.
• Understanding where data will be hosted and where technical support and backups take place. Data should ideally be hosted in Jersey, the EEA or an adequate jurisdiction; hosting elsewhere will trigger the cross-border transfer requirements addressed in paragraph 3 below.
• Assessing security measures and incident response procedures.
• Address liability, audit rights, and restrictions on secondary data use in the contract.
• Ensure the contract addresses what happens to your data on termination, including return, deletion, and confirmation of destruction. Negotiate restrictions on unilateral amendments to contractual terms, or at minimum ensure you receive adequate notice and have the right to exit if material changes are made. Consider what would happen to personal data held by the supplier in the event of insolvency, acquisition, or unexpected service termination. Contracts should address data return or deletion in these scenarios, not only planned termination.
• Ensure your data processing agreement requires the supplier to obtain your prior written authorisation before engaging sub-processors, and to impose equivalent data protection obligations on any sub-processors by contract. You should understand who the key sub-processors are and where they are located, particularly where cloud infrastructure providers are involved, including satisfying yourself that the organisation is compliant with their own local data protection requirements.

50. Data transferred outside Jersey must comply with the cross-border transfer requirements in Arts.66-67 of the DPJL 2018. If a supplier is based in a jurisdiction without an adequacy decision in respect of Jersey, you will need to ensure an appropriate transfer mechanism is in place (e.g. standard contractual clauses). Note that standard contractual clauses approved under UK GDPR or EU GDPR may require adaptation for use in the Jersey context. See our guidance note on international transfers here.

Retention, decommissioning and supplier exit

51. Controllers must address what happens to personal data when an AI system is retired, replaced, or when a supplier contract is terminated. This includes:

• Ensuring that personal data is deleted or returned by the supplier on termination of the contract, and that you receive written confirmation of deletion where return is not possible, in accordance with Art.19 DPJL 2018 and any contractual terms.
• Understanding whether personal data used to train the AI model persists in the model after the contract ends, and whether it can be removed. Where removal is not technically feasible, document the residual risk and any mitigating measures taken, and consider whether the model can continue to be used in a way that does not cause harm to affected individuals. Address this in the supplier contract and DPIA before deployment.
• Establishing data retention schedules for AI-generated outputs. Scores, predictions, and profiles generated about individuals must not be kept for longer than necessary. Retention periods for AI-generated outputs should be documented in your retention schedule and reviewed whenever the AI system or its purpose changes or at regular intervals in any event.
• Planning for model retirement: when an AI system is decommissioned, ensure that personal data held within the model or associated datasets is properly deleted or anonymised, and that deletion is verified and documented as part of the decommissioning process.

52. Where a supplier contract is terminated or an AI system is decommissioned, you should require written confirmation from the supplier that all personal data (including any copies held in backup systems, logs, or associated datasets) has been permanently deleted or, where deletion is not technically feasible, that appropriate measures have been taken to render the data inaccessible and to prevent its further use. Confirmation should be provided within a defined timeframe, specified in the contract, and retained as part of your accountability documentation.

Accountability and governance (Arts.6 and 14 of the DPJL 2018)

53. Art.6 of the DPJL 2018 sets out the general duties of controllers, including the requirement to demonstrate compliance. Art.14 requires controllers to maintain records of processing activities. In the AI context, this means:

• Maintaining records of processing (Art.14 of the DPJL 2018) that accurately describe AI-driven processing, including the logic and purpose of each AI system and the categories of personal data processed and individuals affected.
• Documenting your Schedule 2 condition assessment, legitimate interests assessment (where applicable), and DPIA for each significant AI deployment.
• Establishing clear internal accountability for AI-related decisions and compliance, including designated senior-level ownership and clear escalation paths for AI-related compliance issues.
• Integrating AI governance into existing data protection, risk management, and procurement frameworks, so that compliance obligations are addressed before deployment rather than retrospectively.
• Ensuring staff using or overseeing AI systems receive appropriate training, including on the risks of bias, individual rights obligations, and the limits of AI-generated outputs.
• Where a Data Protection Officer (DPO) is appointed (Art.24 of the DPJL 2018), ensuring they are consulted on significant AI deployments at an early stage, before procurement or deployment decisions are finalised.
• Establishing a programme of periodic audit and review of AI systems in use, to assess continued compliance, identify emerging risks, and verify that governance measures remain effective.
• Maintaining up-to-date internal policies governing the use of AI, and ensuring those policies are communicated to and followed by relevant staff.

Lifecycle management and ongoing monitoring

54. AI compliance is not a one-off exercise. You should:

• Monitor AI system performance, outputs, compliance with data protection obligations, and impacts on individuals on an ongoing basis.
• Implement processes for detecting model drift including where external conditions change in ways that affect the reliability or fairness of outputs.
• Reassess conditions for processing, DPIAs, and technical controls where models are retrained, repurposed, or significantly modified.
• Monitor guidance and regulatory developments from the JOIC and consider how emerging AI regulation (including developments in relation to the EU AI Act and its potential relevance to Jersey-connected processing) may affect the classification and governance of your AI systems.
• Ensure that exit and decommissioning plans are established and reviewed as part of ongoing governance, rather than addressed only at the point of system retirement.

55. Taken together, you should treat the use of AI as a form of high-risk, evolving data processing that requires proactive, documented, and demonstrable compliance across all relevant aspects of data protection law.

How to carry out a bias audit

56. A bias audit is a structured review of whether an AI system produces systematically different (and unjustified) outcomes for different groups of people. This guidance note refers to bias audits in several places and this section sets out how to carry one out in practice.

• Step 1: Define the relevant groups. Identify which protected characteristics are relevant to your context (e.g. sex, race/ethnicity, age, disability). In Jersey, the Discrimination (Jersey) Law 2013 covers: race, sex, pregnancy/maternity, sexual orientation, gender reassignment, religion/belief, and age. You do not need to process protected characteristic data directly, the audit looks at outputs across groups.

• Step 2: Gather your output data. Collect a sample of AI-generated outputs (e.g. candidate scores, credit decisions, risk ratings) alongside whatever demographic or proxy data is available. If you do not hold demographic data, use proxy variables cautiously (e.g. name-based gender inference has well-known limitations)

• Step 3: Test for disparate impact. Compare acceptance/rejection rates, average scores, or outcome distributions across groups.

• Step 4: Investigate root causes. If disparities are found, investigate whether they are explained by legitimate, job-relevant factors, or whether they reflect historical bias in training data, proxy discrimination (e.g. postcode as a proxy for ethnicity), or system design choices.

• Step 5: Document and act. Record your findings, the methodology used, and any remedial steps taken. If disparities cannot be justified, adjust the model, the training data, or the decision process. Do not simply note the disparity and continue.

• Step 6: Repeat. Bias audits should be conducted at least at each retraining cycle and whenever the system is applied to a new population or purpose. For systems that can impact on individuals in significant ways (e.g. recruitment, credit, benefits), conduct audits at least annually even without retraining.

Further resources

57. This guidance should be read alongside other JOIC guidance on data protection by design and default, DPIAs, individual rights, cross-border transfers, and data controller/processor duties. The following international resources may also provide useful background, though they relate to other legal frameworks and are not directly binding in Jersey:

• EDPB - Opinion 28/2024 on AI models and GDPR compliance
• EDPB - Guidelines on automated individual decision-making and profiling

58. We will update this guidance as the regulatory landscape evolves. If you have questions about your specific circumstances, please contact us.