An AI governance framework your company can operate

What belongs in an AI governance framework?

A company's framework connects policy to everyday decisions across the AI lifecycle: selecting a tool, approving data access, testing a use case, releasing it, monitoring it, and retiring it. It applies to purchased AI tools as well as systems your team builds. The controls should reflect the use's impact on people, the sensitivity of its data, and the actions it can take.

Separate three decisions: whether the vendor is acceptable, whether a particular workflow is acceptable, and whether the people using it are prepared. Approval of a tool does not automatically approve every use of that tool.

This guide provides operational guidance, not legal advice. Ask qualified legal and privacy advisers to determine the laws, sector requirements, and contractual obligations that apply to your organisation and each use case.

Choose public frameworks for the job they do

These references serve different purposes. Use their official sources to check scope and current requirements. The implementation suggestions below are Symph's practical guidance, not a claim of certification or compliance.

Set up governance in seven operating steps

Start with an existing management or risk forum if it can make the decisions. Name the people responsible and record the evidence for each approval. Add specialist review where the use case requires it.

1. 01

   Inventory the tools and uses

   Ask each department which AI tools, assistants, and embedded features it uses. Record the business purpose, owner, vendor, users, data sources, permissions, outputs, and any actions the system can take. Include experiments and employee-selected tools, not only procurement's list.

2. 02

   Assign decision rights

   Make a business owner accountable for the outcome. Give IT responsibility for access and technical controls; involve security and privacy owners for their reviews, and legal advisers for applicable obligations. Specify who may approve a pilot, accept residual risk, release it, and suspend it. Employees need one clear route for submitting a new use.

3. 03

   Set policy and triage rules

   Publish approved tools, allowed data, prohibited uses, and review requirements. Triage by potential harm, sensitive data, external exposure, autonomy, and reversibility. A private drafting aid and a system recommending employment decisions need different scrutiny. Define which uses must wait for specialist review and which are prohibited.

4. 04

   Review data and suppliers

   Confirm permission to use each source and test that users see only information they are authorised to access. Review vendor retention, model-training use of inputs, subprocessors, incident terms, and exit arrangements. Record unresolved questions; an enterprise label alone does not answer them.

5. 05

   Evaluate before release

   Test representative tasks and foreseeable failures, including unsupported answers, data leakage, prompt injection, and inappropriate actions. Include affected groups where relevant. Set acceptance criteria before testing, document limitations, and assign a human reviewer who has enough information and authority to reject the output. Keep a fallback and rollback procedure.

6. 06

   Monitor and handle incidents

   Track output errors, employee reports, access issues, and changes in how people use the system. Give users a reporting channel. Define who can restrict access, preserve relevant evidence without exposing more sensitive data, investigate, communicate with affected people, and restore service. Record corrective actions and any external reporting decisions with the right advisers.

7. 07

   Review changes and retire uses

   Reassess when the model, vendor terms, data source, permissions, workflow, or intended audience changes, and after a significant incident. Schedule periodic reviews appropriate to the risk. When a use ends, remove access and integrations, handle retained data under your policy, and record why it was retired.

A minimum use-case approval record

Keep one record per use case. A spreadsheet can work at the start if ownership, access, and version history are clear. Include these fields:

• Use-case name, purpose, business owner, sponsor, and review date.
• Vendor, model or product version, users, connected systems, and permitted actions.
• Data sources, classification, permission evidence, retention, and access boundaries.
• People affected, expected benefit, potential harms, risk rating, and reasons for it.
• Required controls, human review, evaluation criteria, test evidence, and known limitations.
• Approval decision, approver, conditions, residual risks, and next review triggers.
• Monitoring owner, incident contact, suspension authority, and fallback or retirement plan.

Example: an internal policy assistant can answer from approved policy documents but must not change employee records. The policy owner reviews source accuracy; IT tests permissions; employees receive a route for reporting a wrong answer. Expanding the assistant to recommend disciplinary action requires a fresh use-case review.

Keep governance working in Sustain

In Symph's AI transformation approach, Sustain covers adoption tracking, governance, and refresher sessions as models evolve. Discuss how that phase fits your existing operating reviews: who owns the AI inventory, which uses need reassessment, and what employees need to learn when tools change.

Bring one current AI use and its approval record to the conversation. We can discuss the gaps between the written policy and how employees use the tool.

Read Symph's AI transformation approach or discuss governance for your team.

Frequently asked questions