AI Governance for IT Teams: RACI, Approvals, and Change Control

If Microsoft 365 Copilot, AI agents, or external genAI tools are already in your environment, governance is no longer optional. This guide gives IT teams a clear, lightweight governance model that improves speed and reduces risk.

Published: February 17, 2026 Reading time: 14 to 18 minutes Best for: IT managers, security leaders, and operations owners

What you will build: an AI RACI, an approvals workflow, and a change control path that fits your existing ITSM.

What you will reduce: data leakage risk, shadow AI, and production changes without owners.

What you will improve: Copilot adoption, auditability, and faster safe releases.

This article is educational and not legal advice. If you operate in a regulated environment, validate AI policy and data handling with privacy and legal counsel.

What AI governance means for IT teams (in plain language)

AI governance is the operating system for deciding who can deploy AI, what data it can touch, how changes get approved, and how you prove it later. In practical IT terms, it is a set of artifacts and workflows that keep AI adoption fast, controlled, and auditable.

A useful governance program borrows from proven frameworks. NIST organizes AI risk management into four functions (govern, map, measure, manage) and treats governance as cross cutting across the lifecycle.¹ ISO/IEC 42001 defines an AI management system standard that formalizes policy, objectives, and continual improvement for responsible AI use.²

The minimum viable AI governance stack

Start with these seven components. You can implement all of them without creating bureaucracy.

1. AI policy and acceptable use: what is allowed, what is not, and how to handle sensitive data.
2. AI inventory: a living register of AI tools, agents, plugins, connectors, datasets, and automations.
3. RACI: role clarity for decisions, approvals, testing, and ongoing operations.
4. Approval workflow: an intake form plus a predictable path for low, medium, and high risk AI changes.
5. Change control: a safe release process, aligned to ITIL change enablement concepts like risk assessment, authorization, and scheduling.³
6. Technical guardrails: identity controls, data classification, and monitoring.
7. Operating cadence: weekly and monthly governance reviews, with clear owners and metrics.

Step 1: Build an AI inventory that IT can actually maintain

Most governance fails because nobody can answer a simple question: What AI is in production today? Your inventory should be short, searchable, and owned. Keep it in the same place you already track systems, like your CMDB, a service catalog, or a controlled SharePoint list.

Inventory fields to capture (copy and use)

• Name: tool, model, agent, plugin, connector, automation.
• Business purpose: what outcome it supports and who benefits.
• Data touched: sources, destinations, and whether it can access Microsoft Graph content.
• Access model: which identities can use it, and whether it is scoped by least privilege.
• Risk tier: low, medium, high (see next section).
• Owner: business owner and technical owner.
• Controls: labels, DLP, logging, retention, approvals required.
• Change path: standard change, CAB review, or emergency process.
• Review cadence: quarterly, semi annual, or annually.

Step 2: Define risk tiers that drive approvals (not debate)

Risk tiers prevent endless meetings. They tell you which changes can move fast and which require formal approval. Use the table below as a starter, then tune it to your environment.

If you handle sensitive data, build incident response into your AI governance from day one. Your IR plan should define owners, escalation paths, evidence handling, and communications before a data exposure event occurs.⁴ MSP Corp also provides a practical, Canada focused guide: Incident Response Plan Template (for SMBs).

Step 3: Create an AI RACI that removes ambiguity

RACI works because it forces a single accountable owner per decision. Keep the matrix small and readable. If everyone is accountable, nobody is accountable.

ISACA notes that a RACI matrix is a core tool used in governance toolkits (including COBIT) to clarify responsibility and accountability across enterprise roles.⁵

RACI: onboarding a new AI capability (tool, agent, or connector)

RACI: prompt library and usage standards

Prompting standards are governance, not training fluff. They reduce accidental data disclosure and improve repeatability.

Step 4: Build an approvals workflow that matches reality

Approvals fail when they are vague. Your workflow should answer: what gets approved, by whom, in what order, and what evidence is required. Use the risk tiers to route requests automatically.

Approval workflow (copy and adapt)

1. Intake: requestor submits an AI change request (new tool, new connector, expanded access, new agent, or new dataset).
2. Triage: IT service owner assigns a preliminary risk tier and confirms the business owner.
3. Assessment: security and data stakeholders confirm data scope, controls, and monitoring plan.
4. Approval: approvals recorded in a ticket, including conditions for release.
5. Pilot: limited rollout with logging, success metrics, and user enablement.
6. Go live: change record closed with evidence and rollback plan.
7. Review: 30 day review, then quarterly or semi annual reviews.

AI change request form (fields that prevent rework)

• Use case: what task it improves and what “done” looks like.
• Who uses it: roles, groups, and licenses.
• Data accessed: SharePoint sites, Teams channels, mailboxes, line of business systems.
• External sharing: any data leaving your tenant, including connectors or third party agents.
• Controls requested: labels, DLP rules, conditional access, retention, restricted sites.
• Logging plan: where audit data will be reviewed and by whom.
• Roll back: how to disable the feature and unwind permissions quickly.
• Impact: downtime, user disruption, and communications plan.

Governance is also a support model decision. If your team needs always on coverage for Copilot adoption, identity incidents, or endpoint changes, read What’s Included in 24/7 IT Support (and What Isn’t) so your expectations, SLAs, and escalation paths are realistic.

Step 5: Treat AI changes as real changes (ITIL aligned change control)

AI changes can impact data exposure, user permissions, and compliance. That makes them change enablement candidates, not informal tweaks. ITIL describes change enablement as maximizing successful changes by ensuring risks are assessed, changes are authorized, and schedules are managed.³

Classify AI changes using three lanes

• Standard AI change: pre-approved, low risk changes with documented steps (example: adding users to an approved Copilot pilot group).
• Normal AI change: requires review and authorization (example: expanding an agent’s access to a new SharePoint site collection).
• Emergency AI change: time sensitive changes to reduce harm (example: disabling a connector after suspected data exposure).

What evidence should a change record include?

• Scope of access before and after (groups, sites, datasets).
• Risk tier and the control set applied.
• Testing evidence (pilot results and known limitations).
• Approval trace (who approved and when).
• Rollback steps that a second person can follow.

Step 6: Use Microsoft 365 controls to enforce governance (Copilot included)

For Microsoft 365 Copilot, governance is only as strong as your existing identity and data permissions. Microsoft states that Copilot only surfaces organizational data a user already has at least view permissions to, so overshared content becomes an AI exposure problem.⁶

Four controls that deliver the fastest risk reduction

1. Permission hygiene: fix overshared SharePoint sites, public Teams, and broad link sharing.
2. Sensitivity labels: Purview sensitivity labels are recognized by Microsoft 365 Copilot and Copilot agents, and can enforce usage rights when encryption is applied.⁷
3. Auditing: Purview audit logs capture Copilot and AI application interactions and admin activities for traceability.⁸
4. DLP and retention: baseline DLP policies, plus retention and eDiscovery readiness for investigations.

Copilot governance reality check

• Tenant boundary matters: Microsoft states prompts, responses, and data accessed through Microsoft Graph are not used to train foundation models for Microsoft 365 Copilot.⁶
• Extensibility increases risk: agents and connectors can introduce new data flows. Treat every new connector like a high visibility change request.

For a practical implementation order, start with the Microsoft 365 Copilot Readiness Checklist (Data, Security, Licensing), then align ongoing operations to the Microsoft 365 Administration Checklist: Weekly, Monthly, Quarterly Tasks.

Operating cadence: keep governance alive (without meetings that drag)

Governance fails when it becomes a one time document. Give it a rhythm.

Weekly (15 to 30 minutes)

• Review new AI requests, assign risk tiers, and confirm owners.
• Review audit signals for unusual usage or new high risk access patterns.
• Confirm upcoming changes and user communications.

Monthly (45 to 60 minutes)

• Review Copilot adoption and top use cases by department.
• Review DLP and label coverage gaps, then assign fixes.
• Review support tickets and update prompt packs and user guidance.

Quarterly (90 minutes)

• Review high risk AI inventory items and revalidate access scope.
• Run a tabletop on an AI related incident scenario.
• Update policy, controls, and change templates based on lessons learned.

Common AI governance failure modes (and how to avoid them)

• No single accountable owner: fix it with RACI and make the business owner accountable for value and risk acceptance.
• Permissions are a mess: Copilot will not fix oversharing. Your governance must include a permission cleanup backlog.
• Approvals do not match risk: use tiers to reduce friction for low risk changes and increase rigor for high risk ones.
• Support is under-scoped: evaluate whether it is time for a different support model or partner. See When to Switch MSPs: 12 Red Flags and a Transition Checklist.

A 90 day rollout plan you can execute

Days 1 to 15: establish control

• Publish acceptable use and the “never include” data list.
• Stand up the AI inventory with owners and risk tiers.
• Turn on auditing and confirm who reviews it weekly.⁸

Days 16 to 45: enforce guardrails

• Permission cleanup for overshared content.
• Deploy sensitivity labels for critical data and validate Copilot behavior with labeled items.⁷
• Build standard AI changes and pre-approvals for low risk actions.

Days 46 to 90: scale safely

• Expand Copilot to more teams using the approval workflow and change windows.
• Formalize quarterly governance reviews and a lightweight CAB for high risk items.
• Run an AI incident tabletop and update your IR plan. Use MSP Corp’s template if helpful: Incident Response Plan Template (for SMBs).

FAQ

Sources

1. NIST. Artificial Intelligence Risk Management Framework (AI RMF 1.0). PDF.
2. ISO. ISO/IEC 42001:2023 Information technology – Artificial intelligence – Management system. ISO overview.
3. AXELOS. ITIL 4 Practitioner: Change Enablement. AXELOS page.
4. NIST. SP 800-61 Rev. 3, Incident Response Guidelines. CSRC.
5. ISACA. COBIT tool kit enhancements. ISACA.
6. Microsoft Learn. Data, Privacy, and Security for Microsoft 365 Copilot. Microsoft Learn.
7. Microsoft Learn. Learn about sensitivity labels. Microsoft Learn.
8. Microsoft Learn. Audit logs for Copilot and AI applications. Microsoft Learn.