# How to Write an AI Ethics Committee Decision Note

Canonical URL: https://xpertdpo.com/how-to-write-ai-ethics-committee-decision-note/

Content type: Article

Published: 2026-06-25T22:44:59+01:00

Updated: 2026-06-26T09:18:30+01:00

Author: Philipa Jane Farley, Head of Legal and Operations

Summary: Practical CPD guidance on writing an AI ethics committee decision note, including evidence reviewed, evidence missing, safeguards, conditions and approve/pause/reject outcomes.

## Article

*This article supports **Deep Dive B: AI Ethics Committee Simulation**, the extra deep-dive hours attached to our [CPD Event B: Full-Day AI, Technical Privacy & Emerging Technology Training](https://xpertacademy.com/cpd-event-b-ai-technical/) programme on [XpertAcademy](https://xpertacademy.com/). Event B provides the seven-hour CPD programme; the Deep Dive material is there for organisations and learners who want to go one level deeper through practical exercises, real-world evidence packs and an AI ethics committee simulation. Completion and certification are tied to the relevant XpertAcademy learning activity, rather than to reading this article on its own.*

 An AI ethics committee decision note should be short enough to read and strong enough to stand up later.

 It is not a transcript. It is not a policy essay. It is not a place to hide uncertainty in polished language. It should show what the committee reviewed, what it decided, what evidence was missing, what safeguards are required, who owns the conditions and when the system must come back for review.

 The decision note matters because AI governance decisions are often revisited after something has changed: a complaint, an incident, a model update, a DSAR, a supplier change, a fairness concern, a press question, a board review or a regulator enquiry. When that happens, the organisation needs a record that explains the decision made at the time.

 For Deep Dive B, the decision note is the practical output of the simulation. The system is an AI-enabled triage tool in a regulated or essential-service environment. It uses online form information, previous interaction history, internal case notes and operational status data to assign a priority score and recommend the next action for staff. The organisation says the tool supports staff decisions rather than replaces them.

 The committee's task is to decide whether to approve, approve with conditions, pause or reject/redesign.

### The decision note should answer one question

 The note should answer:

> On the evidence available, what decision did the committee make about this AI-enabled system, and under what conditions?

 Everything else supports that question.

 A useful decision note usually includes:

- system name and version;
- purpose and decision requested;
- affected people and workflow;
- benefits expected;
- evidence reviewed;
- evidence missing;
- key risks;
- safeguards already in place;
- conditions required;
- decision outcome;
- residual risk owner;
- review date and re-review triggers.

 The note should be specific. "The committee discussed privacy and fairness" is not enough. It should say which privacy and fairness issues mattered.

### Decision outcomes

 The committee should use clear decision categories.

 Approve means the evidence is good enough for the defined scope and the residual risk is accepted by the right owner. It should not mean permanent approval for every future use.

 Approve with conditions means the system may proceed only if the listed conditions are met. The note should say whether conditions must be met before go-live, during pilot, before expansion or by a review date.

 Pause means the committee cannot approve on the current evidence. The project may return when specified evidence or design work is complete.

 Reject/redesign means the proposed design is not acceptable in its current form. That should be used where the issue is not merely missing paperwork, but a substantive problem with purpose, data use, fairness, oversight, security, supplier control or governance.

 The committee should avoid softer labels such as "endorsed in principle" unless the organisation has a defined meaning for them. Soft labels create hard confusion later.

### A practical decision note structure

 The following structure is designed for a one to three page note, with the evidence pack held separately.

 | Section | What to write |
| --- | --- |
| 1. System and decision requested | Name the tool, owner, stage, scope and the decision being sought. |
| 2. Purpose and affected people | Explain the business purpose, affected workflow and categories of people affected. |
| 3. Expected benefits | Record the practical benefits claimed and how they will be measured. |
| 4. Evidence reviewed | List the evidence pack items and versions reviewed by the committee. |
| 5. Evidence missing or weak | State material gaps plainly and say whether they block approval or become conditions. |
| 6. Risk assessment summary | Summarise privacy, fairness, transparency, human oversight, supplier, cloud, security and governance risks. |
| 7. Safeguards and controls | Record controls already in place and controls still required. |
| 8. Decision | State approve, approve with conditions, pause or reject/redesign. |
| 9. Conditions and owners | List each condition with owner, evidence required, due date and consequence. |
| 10. Review and triggers | Set review date and event-triggered re-review criteria. |

 The structure is deliberately plain. The value is in the judgement, not the template.

### Worked example: conditional approval for a triage pilot

 The committee is asked to approve a three-month pilot of the triage tool for standard service requests. The pilot excludes complaints, safeguarding, emergency support, children, vulnerable-person escalation and hardship cases. Staff will see a priority recommendation and next-action suggestion, but they must make the final triage decision.

 The evidence reviewed includes a data map, DPIA draft, supplier DPA, subprocessor list, security assessment, staff workflow, transparency wording, bias testing summary, human oversight design and monitoring plan.

 The evidence is not perfect. The DPIA is strong on data flows but light on case-note quality. Bias testing covers broad priority accuracy, but does not yet analyse missed urgent cases by language, access need or prior complaint history. Supplier evidence covers hosting and security, but support access needs tightening. The staff override workflow exists, but the committee wants stronger guidance on when to disagree with the score.

 The committee decides to approve a limited pilot with conditions.

 A good decision note would not simply say "approved with conditions". It would record the conditions clearly:

 | Condition | Owner | Evidence required | Due date | Consequence |
| --- | --- | --- | --- | --- |
| Exclude complaints, safeguarding, children, vulnerable-person escalation and hardship cases from pilot scope. | Product owner | Updated configuration and staff guidance. | Before pilot starts | No pilot start until complete. |
| Review historical case-note fields for relevance, excessive data and unfair proxy risk. | DPO and operations owner | Case-note field review and minimisation decision. | Before pilot starts | Committee chair to confirm closure. |
| Expand bias and fairness monitoring to include missed urgent cases by language, access need and complaint marker where lawful and feasible. | Analytics lead | Monitoring plan and first-month report format. | Before pilot starts | Pilot may start, but first-month review cannot be waived. |
| Strengthen staff guidance on override and escalation. | Operations owner | Final training pack and override reason codes. | Before staff training | No staff access until training complete. |
| Restrict supplier support access to named support roles with logged access and approval for content-level inspection. | Procurement and security | Supplier support access procedure and contract note. | Before pilot starts | No live personal data until complete. |
| Review pilot after one month and three months. | Senior accountable owner | Review pack covering outcomes, overrides, complaints, incidents and monitoring. | Month 1 and Month 3 | Expansion blocked until review complete. |

 This is a usable decision. It says what can proceed, what cannot proceed, and what evidence will close the gaps.

### Writing about evidence reviewed

 The decision note should list evidence precisely. It should not say "the DPIA was reviewed" if the committee reviewed a draft.

 Use versioned descriptions where possible:

- DPIA draft v0.4 dated 18 June 2026;
- data map v0.3 dated 17 June 2026;
- supplier DPA dated 12 June 2026;
- security assessment summary dated 19 June 2026;
- bias testing summary dated 20 June 2026;
- staff workflow and override process dated 21 June 2026;
- public transparency wording draft dated 21 June 2026;
- monitoring and review plan dated 22 June 2026.

 This may look fussy. It is not. If the supplier changes the architecture later, or the DPIA is updated after a condition closes, version control will matter.

### Writing about evidence missing

 Missing evidence should be stated without drama and without smoothing it away.

 Instead of "further work is ongoing", write: "The committee did not receive sufficient evidence on whether historical case-note text contains irrelevant or unfair staff comments. Approval is conditional on a case-note field review and minimisation decision before pilot start."

 Instead of "supplier access to data was discussed", write: "The supplier evidence pack did not clearly explain when support staff can view customer-level content. Live use is conditional on a support access procedure covering approval, logging, role restriction and incident escalation."

 Clear gaps are kinder to the organisation than vague comfort. They let people close the issue.

### Writing about risks and safeguards

 The risk summary should cover the areas the Deep Dive simulation asks learners to practise:

- purpose and necessity;
- affected people;
- benefits;
- privacy risks;
- fairness risks;
- transparency risks;
- human oversight risks;
- supplier, cloud and security risks;
- governance risks;
- evidence reviewed;
- evidence missing;
- safeguards;
- decision and conditions.

 The note should not overclaim legal certainty. If the committee has not determined whether a particular AI law classification applies, say that classification requires separate confirmation. If the committee is relying on a DPIA still under review, say so. If the tool is described as advisory, record what makes the human review meaningful in practice.

### Records and retention

 The decision note should be stored with the evidence pack, not scattered across inboxes.

 The record should include the final note, evidence index, meeting agenda, attendees, conflicts of interest, decision authority, conditions tracker, residual risk acceptance, review schedule and later closure evidence. If conditions are closed after the meeting, closure evidence should be added to the same file or linked record.

 Retention should follow the organisation's governance, legal and records policies. For a system that may affect people over time, the organisation should keep enough evidence to explain the approval during operation and after decommissioning. The committee should avoid deleting the rationale while the system or its effects remain relevant.

### Common decision note weaknesses

 The most common weakness is writing the note as if approval was inevitable. A real decision note should show that the committee could have said no.

 Other common problems include:

- no named senior accountable owner;
- benefits recorded but affected people ignored;
- conditions without owners or due dates;
- supplier claims repeated without evidence;
- human oversight described but not tested against real workflow;
- fairness risks mentioned without monitoring;
- no explanation of what would trigger re-review;
- no record of dissent or unresolved concern;
- no link to the DPIA, supplier evidence or security review.

 These problems are fixable. The cure is plain writing and accountable ownership.

### How this supports the simulation

 In Deep Dive B Section 4, participants produce a practical decision note. The learning is not to produce a beautiful document. It is to make a defensible governance decision under imperfect evidence.

 In the simulation, participants should be able to say: this is the purpose, these are the affected people, this is the benefit, these are the privacy, fairness, transparency, oversight, supplier, cloud, security and governance risks, this is what we reviewed, this is what is missing, these are the safeguards, this is the decision and these are the conditions.

 That is what a decision note is for. It turns committee discussion into organisational memory.

 *This article is intended to support the extra learning covered in **Deep Dive B: AI Ethics Committee Simulation**. The seven-hour CPD programme is covered through Event B on XpertAcademy, with the Deep Dive hours available for organisations and learners who want more applied depth. You can return to CPD Event B and the Deep Dive B materials here: [CPD Event B: Full-Day AI, Technical Privacy & Emerging Technology Training](https://xpertacademy.com/cpd-event-b-ai-technical/).*

### Sources

- Information Commissioner's Office, Guidance on AI and data protection: [https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/)
- Information Commissioner's Office, Governance and accountability in AI: [https://ico.org.uk/for-organisations/advice-and-services/audits/data-protection-audit-framework/toolkits/artificial-intelligence/governance-and-accountability-in-ai/](https://ico.org.uk/for-organisations/advice-and-services/audits/data-protection-audit-framework/toolkits/artificial-intelligence/governance-and-accountability-in-ai/)
- Information Commissioner's Office, Explaining decisions made with AI – what goes into an explanation: [https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/explaining-decisions-made-with-artificial-intelligence/part-1-the-basics-of-explaining-ai/what-goes-into-an-explanation/](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/explaining-decisions-made-with-artificial-intelligence/part-1-the-basics-of-explaining-ai/what-goes-into-an-explanation/)
- European Data Protection Board, Opinion 28/2024 on certain data protection aspects related to the processing of personal data in the context of AI models: [https://www.edpb.europa.eu/documents/opinion-of-the-board-art-64/opinion-282024-on-certain-data-protection-aspects-related-to_en](https://www.edpb.europa.eu/documents/opinion-of-the-board-art-64/opinion-282024-on-certain-data-protection-aspects-related-to_en)
- European Commission, Guidelines for providers and deployers of AI high-risk systems: [https://digital-strategy.ec.europa.eu/en/policies/guidelines-ai-high-risk-systems](https://digital-strategy.ec.europa.eu/en/policies/guidelines-ai-high-risk-systems)
- Data Protection Commission, AI, Large Language Models and Data Protection: [https://dataprotection.ie/en/dpc-guidance/blogs/AI-LLMs-and-Data-Protection](https://dataprotection.ie/en/dpc-guidance/blogs/AI-LLMs-and-Data-Protection)

 Publication verification notes:

- Re-check the ICO AI pages before publication because the pages checked on 2026-06-25 carried a live UK legal update banner.
- Re-check the European Commission high-risk guidance page before publication because the page checked on 2026-06-25 described the guidelines as draft and not legally binding.
- Confirm the Deep Dive B public route and CPD wording before loading. Do not link to Moodle management pages in the article body.

## General Information Only

This article is provided for general information and does not constitute legal, regulatory, or professional advice. Data protection obligations depend on the specific facts, context, and jurisdiction involved. You should not rely on this content as a substitute for advice tailored to your organisation.

If you would like support with a specific issue, please contact us: https://xpertdpo.com/contact/