Assign responsibility before deployment.

1. Record the actual uses of AI.

Start with an inventory of tools and workflows, including AI features embedded in ordinary software. Record the purpose, users, information involved and actions the system can take. A public-facing assistant and an internal drafting tool need different controls because their audiences, failure consequences and review opportunities differ.

Assign a business owner who can decide whether the use remains appropriate and a technical owner who can maintain its controls. Include the people responsible for data protection, security and procurement where relevant. Ownership should survive staff changes. A policy that says “users remain responsible” is incomplete if those users cannot inspect sources, correct errors or stop an automated action.

2. Distinguish guidance from obligations.

The NIST AI Risk Management Framework organises risk work around Govern, Map, Measure and Manage. It provides a vocabulary for considering context and consequences; it is not a guarantee that a particular system is safe. Use it to structure questions, then document the controls chosen for the actual application.

ISO/IEC 42001 specifies requirements for an AI management system. It concerns organisational processes rather than endorsing a model’s answers. Referring to the standard does not mean an organisation holds certification. Decide whether a formal management system is appropriate for the organisation’s responsibilities and procurement requirements.

For UK personal-data processing, use the ICO’s AI guidance alongside applicable law. The EU AI Act may also require assessment when a use falls within its territorial and substantive scope. Do not treat every international framework as automatically binding, or assume that UK location alone settles obligations. Obtain qualified advice for specific legal questions.

3. Control access and information flows.

Document what enters the system, where it is processed and what is retained. Review provider terms covering subprocessors, training use, deletion and international transfers. Apply role-based access and separate development data from production records. A tool’s general security description does not answer whether a particular workflow is authorised to process particular information.

A data protection impact assessment, or DPIA, is required where processing is likely to result in a high risk to individuals under the applicable rules. Consider necessity, proportionality and safeguards before deployment. Do not collect extra personal information merely because a model can use it. Keep privacy notices and internal instructions aligned with the actual processing.

4. Give reviewers a real decision.

Human review is meaningful only when the reviewer has enough context, time and authority to disagree. Show the input, supporting sources and proposed action. Provide a route to correct the result or decline it. Avoid interfaces that encourage a quick approval while concealing uncertainty or making rejection unnecessarily difficult.

Assess failure consequences as well as average behaviour. Check for unsupported claims, inappropriate disclosure and uneven performance across relevant input types. Where a system affects employment, access to services or other consequential decisions, seek specialist assessment and legal advice. General-purpose text generation should not quietly become an unexamined decision-maker.

Write staff guidance that names permitted tasks, prohibited data and escalation contacts. Explain that confident language is not proof and that external text can contain malicious instructions. Training should reflect the tools staff actually use, including how to report an incident without forwarding sensitive content more widely.

5. Treat changes as operating decisions.

Model providers, prompts, connectors and source collections can change independently. Keep a record of the configuration used for evaluation and repeat relevant checks after a material change. Define who may approve releases, how a previous configuration can be restored and when access should be suspended. Preserve enough evidence to explain incidents without retaining unnecessary personal data.

Our governance service can cover a use inventory, responsibility assignments, control documentation and review procedures. It does not replace legal advice or promise certification. Start with the AI uses already present, their data categories and the people accountable for them. Governance is easier to apply when it describes real work rather than an unrestricted aspiration to use AI everywhere.