What a board should see before approving an AI deployment

Most boards are now being asked to approve AI projects, often on the strength of a supplier demo and a business case. The question that matters is simpler than it sounds: if this goes wrong in six months, what will we wish we had seen before we said yes?

Here is a short list of what a board can reasonably expect to see before approving an AI deployment in the UK. None of it needs a technical background to read. All of it should exist before go-live, not after.

1. A plain statement of what the system decides

Not what the product does in general, but what it will decide or influence in your organisation, about whom, and what happens to a person as a result. "Triages incoming tenant repair requests and sets the priority" is useful. "Improves efficiency in repairs" is not.

This matters because the legal position changes with the decision. Since 5 February 2026, the Data (Use and Access) Act 2025 has set new UK GDPR rules for significant decisions made solely by automated means, meaning decisions with a legal or similarly significant effect on someone and no meaningful human involvement. If the answer to "what does it decide?" is vague, nobody can say whether those rules apply.

2. A named owner, and someone who can switch it off

One named person accountable for the deployment and its outcomes, and a clear answer to who has the authority to pause or suspend it if it starts going wrong. These are often different people. Both should be written down.

The ICO's guidance on AI is direct about where accountability sits: "You cannot delegate these issues to data scientists or engineering teams." Senior management is expected to understand and address the risks.

3. A DPIA, or a recorded decision that one isn't needed

If the system uses personal data, a Data Protection Impact Assessment is likely to be needed. Article 35 of the UK GDPR requires one before processing starts where the processing is likely to result in a high risk to people, and the ICO lists innovative technology, including AI, among the triggers. Its AI guidance goes further, saying that "in the vast majority of cases" the use of AI will involve high-risk processing.

If the team concluded a DPIA isn't needed, the board should see how they reached that view. The ICO expects that reasoning to be documented too.

4. Where a human reviews, and whether that review is real

Many deployments are described as "human in the loop". The board should see exactly where the person sits, what they look at, and whether they can change the outcome. A reviewer who sees a score and clicks approve on every case is not the same as one who checks the inputs and can overrule the system.

This links straight back to point 1. If the decision is significant and the human involvement isn't meaningful, the new automated decision-making safeguards apply: people must be told about the decision, be able to make representations, get human intervention and contest it.

5. Evidence it works on your data, not just the supplier's

Results from a pilot or test on your own cases, including where it got things wrong and what kind of wrong. A supplier's headline accuracy figure tells a board very little about how the system will behave with your customers, your tenants or your pupils.

6. Go-live conditions and a review date

What has to be true before it goes live, what would cause it to be paused, and when it will next be reviewed. A deployment approved without a review date tends to never be reviewed.

7. A record the board could show someone else

The final test is whether the board could hand this pack to a regulator, an insurer or an auditor and have it make sense without the project team in the room. The ICO asks organisations to document AI governance processes and outcomes "to an auditable standard". If the evidence only exists in people's heads or in a supplier's slide deck, it isn't evidence yet.

Putting it together

None of these seven items is exotic. They are the same questions a careful board would ask about any significant change. The difference with AI is that the answers are easy to assume and hard to reconstruct later, so it pays to have them written down before the switch is flipped.

AQE was built to produce exactly this record. It works through these areas as structured questions, applies fixed rules, and returns a verdict with the gaps that need closing before go-live. The same answers always give the same result, so the board can see why the verdict is what it is.

Sources

• Data (Use and Access) Act 2025, section 80 (legislation.gov.uk)
• The Data (Use and Access) Act 2025 (Commencement No. 6) Regulations 2026, SI 2026/82
• ICO: When do we need to do a DPIA?
• ICO: What are the accountability and governance implications of AI?

This article explains the rules in general terms. It is not legal advice. Where guidance is marked as draft, check the regulator's site for the final version.