Responsible AI implementation controls are the named, testable controls a board requires before AI enters a regulated workflow: a scoped use case, clear data boundary, technical access limits, evidence for outputs, human approval, audit logging, incident handling and assigned supplier ownership.
The board question is not "do we have an AI policy?" The practical question is narrower: before this system touches a customer record, board paper, invoice, inspection note or case file, what prevents the model from acting outside its remit, and what evidence would prove that control worked?
Key takeaways
- A regulated AI workflow should start with a permitted use case and a prohibited-use list, not a general licence to automate.
- Data access should be bounded before deployment: read-only where the AI only needs to inspect records, least privilege where it needs tools, and no unapproved personal data reuse.
- Outputs need evidence controls: source citations, confidence thresholds, reason codes and a human route when the answer is uncertain or consequential.
- Human approval is a control only when it is placed at the right point in the workflow, given enough context, and written to an audit trail.
- Supplier assurance should allocate control ownership between the board, executive owner, data custodian, system operator and provider before go-live.
Who this applies to
This applies to boards and executive teams approving AI inside regulated, evidential or customer-affecting workflows. Typical examples include complaint triage, governance packs, property inspections, safeguarding referrals, professional reports, lending analysis, invoice posting and procurement screening.
It is less relevant to low-risk drafting, private note summarisation or internal brainstorming where the output is not relied on for a decision and no sensitive data is used. Even there, acceptable-use rules still matter. The heavier control set belongs where an AI output could affect a person, create a compliance record, commit money, alter operational data or shape advice that a professional signs.
The UK position remains principles-led rather than a single horizontal AI Act. The government's response to its pro-innovation AI regulation consultation sets cross-sector principles for regulators, while existing regimes such as UK GDPR, sector rules, cyber security and professional duties still apply. That is why a board needs controls that can be evidenced under several frameworks at once.
What the board must decide before use
A board paper seeking approval for a regulated AI workflow should ask for decisions, not reassurance. The minimum decision set is:
- Permitted purpose: the exact workflow, user group, business objective and boundary of use.
- No-go conditions: the decisions the AI must not make, the data it must not use, and the outputs that require human review.
- Data boundary: which systems, records and personal data categories are in scope, with a DPIA where processing is likely to result in high risk.
- Technical authority: whether the AI has read-only access, tool access, write access, external connectivity or supplier-hosted processing.
- Approval point: where a named human accepts, modifies, rejects or escalates the AI output.
- Evidence pack: the records the organisation can produce after the event: sources, prompts, model version, confidence, decision, approver, time, incident route and supplier control owner.
That decision set is deliberately operational. It converts board appetite into a design brief that engineers, suppliers, data protection officers and risk teams can test.
Responsible AI implementation controls before go-live
The controls below are the minimum set we expect before a regulated workflow moves from pilot to use. Some will be enforced in policy, but the load-bearing controls should sit in the system, access model and audit trail.
| Control | Evidence the board should require | Owner |
|---|---|---|
| Scoped use case | Approved workflow description, user roles, prohibited uses, trigger events and go-live criteria | Executive sponsor |
| Data boundary | Data map, lawful basis assessment, retention rule, DPIA decision, personal data exclusions and supplier processing locations | Data protection lead and data custodian |
| Access limit | Read-only database role where the AI only inspects data, least-privilege tool permissions, environment separation and access review log | System operator |
| Source citations | Output must cite approved source records, policy sections or retrieved documents, with unsupported answers blocked or labelled for review | Product owner |
| Confidence threshold | Pre-set threshold, evaluation results, reason codes below threshold and escalation rule for uncertain outputs | Model owner |
| Human approval | Named accept, modify, reject or escalate action before the workflow affects a person, record, payment or professional report | Accountable process owner |
| Audit trail | Append-only record of prompt, retrieved sources, model/version, output, confidence, decision, approver and timestamp | Risk or compliance owner |
| Incident route | AI-specific incident category, vulnerability disclosure route, rollback plan, affected-person communication route and test record | Security lead |
| Supplier and control ownership | Contract schedule showing which controls sit with the supplier, which sit with the organisation, and what assurance evidence is due | Commercial owner |
Read-only access is not always the right answer. A workflow that drafts a response may need no system access at all. A workflow that analyses operational data may only need to read. A workflow that creates a case note may need write access after human approval. The control decision is to give the AI the lowest authority that still lets the approved workflow function, then evidence that boundary in code and contract.
Source citations serve the same purpose for reasoning. They do not make a model truthful. They make the evidential chain inspectable. If a claim cannot be tied to an approved source, the system should either withhold it, route it to review or mark it as unsupported. We describe one narrow technical pattern in our article on an AI anti-hallucination substring check.
Confidence thresholds also need discipline. A score is not a control unless the board knows what happens below the threshold. In regulated use, the answer should usually be no action, manual review or a reason-coded escalation, not a quieter automated decision. See our worked example on confidence floors and reason codes.
The audit trail is the spine of the evidence pack. A spreadsheet noting that "human review applies" is weak evidence. An append-only record showing what the model produced, what the person decided, and when they decided it is materially stronger. The same principle sits behind the append-only AI decision ledger.
Framework mapping
The control set maps cleanly onto the main frameworks a UK board is likely to encounter.
| Framework or source | What it asks for | How the control set answers |
|---|---|---|
| NIST AI Risk Management Framework | Govern, Map, Measure and Manage functions for AI risk across the lifecycle | Use-case scoping and ownership support Govern and Map; confidence testing and source checks support Measure; incident route and monitoring support Manage |
| GOV.UK AI Playbook | Lawful, secure and responsible use, meaningful human control and assurance | Human approval, access limits, testing evidence and the audit trail turn those principles into workflow controls |
| ICO AI and data protection guidance and ICO DPIA guidance | Accountability, transparency, accuracy, fairness, security, data minimisation and DPIAs for likely high-risk processing | Data boundary, source evidence, confidence thresholds, human review and retained decision records support the data protection file |
| UK AI Cyber Security Code of Practice and its implementation guide | Security by design, human responsibility, asset tracking, supply-chain security, testing, monitoring and incident management | Access limits, supplier ownership, prompt and model records, incident routes and monitoring evidence satisfy the security file |
| ISO/IEC 42001 | An AI management system for organisations providing or using AI-based products or services | Control owners, documented evidence, risk treatment, lifecycle monitoring and improvement records provide the management-system material |
| UK government AI regulation response | A regulator-led framework based on cross-sector AI principles | The board can show how safety, transparency, fairness, accountability and contestability are implemented in the workflow, not only stated in policy |
This mapping matters because boards often receive fragmented assurance: a cyber review from one team, a DPIA from another, a supplier questionnaire from procurement and a model note from technology. The board should require one control register that shows how each evidence item supports the same approved workflow.
Common mistakes
The most common mistake is approving a tool rather than a workflow. "Use Copilot for casework" is too broad. "Use an AI assistant to summarise complaint correspondence for officer review, with no write access and no automated outcome recommendation" is governable.
The second mistake is treating human review as a label. Human oversight works only when the reviewer has authority, time, context and a visible decision action. If the person sees a polished answer with no sources, no confidence warning and no easy reject route, the control has already failed.
The third is allowing supplier assurance to stop at the model. A regulated workflow depends on retrieval, hosting, access controls, logs, prompts, integrations and support arrangements. Supplier ownership should be written against each control, including who handles a security issue, who notifies affected users and who can pause the system.
The fourth is recording too little at the point of decision. Retrospective governance is expensive because the evidence has already disappeared. The audit trail should be generated as the system runs, not rebuilt during an incident review.
The final mistake is using a generic policy to approve a specific risk. A policy can state principles, but it cannot prove that a production assistant had read-only access, cited the right source, stayed below a confidence threshold or routed a decision to a named person. Those facts need system evidence.
Next step
For a board that wants assurance before deployment, start with the workflow and work backwards. Identify the decision, the data, the action the AI is allowed to take, the person who remains accountable and the evidence the organisation can produce after use.
If you already have pilots in flight, use the AI governance diagnostic to test whether each one has a control owner, data boundary, human approval point and audit trail. If you need the operating model behind those controls, our services cover governance design, delivery assurance and implementation support. For how we evidence these controls in the systems we build, see our Trust page and the article on read-only AI database access.
Sources: NIST AI Risk Management Framework · GOV.UK AI Playbook · ICO guidance on AI and data protection · ICO DPIA guidance · UK AI Cyber Security Code of Practice · Implementation guide for the AI Cyber Security Code of Practice · ISO/IEC 42001 · UK government AI regulation response
