10.2 Governance Principles for AI Use
Key Takeaways
- AB-731's official skill is Establish governance principles for AI use — an operating model with policies, allowed uses, data classes, human review, incident response, measurement, and named owners, not a recitation of the six values (those are the next standards section).
- CAF Responsible AI Policies tells organizations to start from proven frameworks such as Microsoft's responsible AI principles or the National Institute of Standards and Technology (NIST) AI Risk Management Framework, then map RAI requirements to existing data, security, and risk policies.
- CAF asks for a quarterly review of AI policies against evolving references such as the EU AI Act and ISO/IEC 42001 rather than a one-time poster.
- CAF tells leaders to embed RAI checkpoints at design reviews, testing, and prelaunch, and to require formal sign-off for high-risk AI that interacts with customers or makes consequential decisions.
- Incident-response protocols must name who can take an AI agent offline, how affected users are notified, and which remediation steps follow — and CAF says to practice those procedures in tabletop exercises before a real incident.
Governance is an operating model, not a poster
Microsoft's AB-731 official skill here is Establish governance principles for AI use. Do not treat that bullet as "recite fairness, reliability, safety, privacy, security, inclusiveness, transparency, and accountability." Those named standards are a separate skill, taught in section 10.4. This section is what a transformation leader actually stands up: written rules, intake, owners, gates, and measurement so Copilot, agents, and Foundry Tools do not become an exception to how the company already governs data and risk.
Microsoft Learn's Design a system for AI governance unit is direct: principles only work when they become repeatable decisions, controls, and accountability across the AI lifecycle. CAF's Responsible AI Policies article says the same in operational language: create practical standards that integrate into existing workflows rather than a parallel bureaucracy that teams route around.
Start from a recognized framework, then map to what you already own
CAF's first move is Adopt industry frameworks as your baseline. Microsoft's responsible AI principles and NIST's AI Risk Management Framework (AI RMF) are the examples CAF names. Using a proven framework accelerates drafting and gives credibility with stakeholders who already recognize those names. You still rewrite the framework into your allowed uses, data classes, and review gates. You do not paste a Microsoft blog into the employee handbook and call the skill done.
CAF's second move is Align AI policies with corporate governance. Map RAI requirements to existing policies for data governance, security, and risk management so AI is not an exception to normal oversight. Teams who already follow records, access, and incident processes then extend those habits to prompts, indexes, and agents. CAF adds a calendar: review policies against emerging regulations such as the EU AI Act and ISO/IEC 42001 quarterly as the landscape evolves.
CAF AI strategy places this work in a fixed sequence: use-case identification and technology choice, then a responsible AI strategy whose standards stay constant even when one workload is Copilot and another is Foundry, then data strategy. AB-731's wording is to map AI strategy to Microsoft's responsible AI policies. The local artifact is still your policy pack.
The artifacts a leader can put on a one-page operating model
Use this list as the minimum pack. If a row is blank, you do not yet have governance principles — you have a slogan.
- Policies. Purpose of AI in the company; which frameworks you adopted; how RAI maps to security, privacy, records, and HR rules; who may grant exceptions.
- Allowed uses and prohibited uses. Productivity drafting versus automated decisions about people; consumer chatbots for labeled data; training on personal data; agents that send mail or move money without a human.
- Data classes. Which labels, systems of record, and personally identifiable information (PII) may enter which tools; retention of prompts and logs; vendor and subprocessors.
- Human review. When a human must approve before an output is sent, posted, or acted on; who that human is by process, not by whoever is online.
- Incident response. Who can halt an agent, how users are notified, how you preserve logs, who speaks externally.
- Measurement. Inventory completeness, review cycle time, incident counts, fairness and safety checks, user-reported harm, adoption on approved tools versus shadow tools.
- Owners. A named executive sponsor, a policy owner, a security owner, a privacy owner, and a business owner for each production system.
Who owns what (RACI-style, in business language)
CAF's Govern AI guidance tells you to document policies that match identified risks and risk tolerance. Use a Responsible, Accountable, Consulted, Informed (RACI) view so the operating model is not "everyone owns RAI," which means no one does.
| Artifact | Accountable (typical) | Responsible (typical) | Consulted |
|---|---|---|---|
| Allowed-use and prohibited-use list | Executive sponsor / AI council | Business process owner | Legal, security, privacy, HR |
| Data-class rules for prompts, indexes, and logs | Privacy + security leadership | Data/records + platform IT | Legal, business owner |
| Human-review gates for consequential actions | Business owner of the process | Operations or HR/finance supervisor | Legal, RAI reviewer |
| Incident halt and notification | Executive on-call / CISO path | Security operations + business owner | Legal, communications |
| Measurement and inventory | AI council or governance lead | Platform / CoE operations | Finance (cost), audit |
| Vendor and model onboarding | Procurement + security | IT / platform | Legal, privacy, business |
Names will differ by company size. The exam skill is that ownership is written down. CAF's cloud-governance RACI teaching is the same habit: policy without an accountable role is guidance-only, and Microsoft's agent-maturity guidance calls "guidance-only instead of enforceable" a universal anti-pattern.
Put the rules in the workflow, not in a wiki nobody opens
CAF: Institutionalize governance in workflows. Embed RAI checkpoints at design reviews, testing, and prelaunch approvals. Require formal sign-off from the governance team for high-risk AI that interacts directly with customers or makes consequential decisions. Add automated scanning where it actually helps — biased training data, inappropriate generation, privacy violations — so you are not relying only on heroic manual reviews.
CAF Govern AI's policy table is the practical expansion of "governance principles":
- Selecting and onboarding models — criteria, sandbox, then catalog; avoid duplicate unvetted models.
- Third-party tools and data — vet privacy, security, and ethics; separate sensitive from public data; define quality (a "golden dataset" for testing).
- Maintaining and monitoring — retraining frequency by risk; watch performance degradation.
- Regulatory compliance — regional law, residency, language, and feature restrictions.
- User conduct — misuse scenarios, restricted functions, terms of use.
- Integration and replacement — data-sharing and security at interfaces; how you retire the old process and train staff.
Learn's Apply systems for AI governance unit adds three actions that belong on the same operating model: make training resources available (handbook or session), create a centralized AI inventory, and develop or buy tools that monitor drift and raise a flag. If you buy Copilot or Foundry rather than building in-house, the same unit says to vet vendor RAI evidence, require documentation on data use and evaluation, and put your requirements in procurement and contracts.
Incident response is a governance principle, not a hope
CAF's auditing section is the paragraph to memorize for the exam: schedule regular audits of deployed AI; watch model drift, emergent biases, and changing risk as systems learn from new data; establish incident protocols that define escalation paths, shutdown authorities, and communication procedures; document who can take an AI agent offline, how to notify affected users, and what remediation follows; practice in tabletop exercises before a real incident.
Transparency is part of the same operating model: document risk assessments and approval rationales; identify AI as AI to users; give people a way to report concerns or challenge decisions. That is governance. It is not yet the full walkthrough of each Microsoft standard — that is section 10.4.
Scenario. An operations vice president wants a warehouse agent that can email carriers when inventory is short. Finance wants it this quarter. Governance principles say: allowed use (notify, do not bind the company to a rate), data class (no customer payment card data in the prompt), human review (supervisor approves the first release of a new carrier template), incident response (fulfillment director plus security can halt send), measurement (wrong-address rate and user flags), owner (VP Operations accountable, IT responsible for the connector). That is a leader operating model. A slide titled "We believe in fairness" is not.
You are standing up governance principles for AI use before a Copilot and Foundry wave. Which set of artifacts matches the AB-731 skill rather than restating Microsoft's named values?
CAF guidance on responsible AI policies says to review policies against which pair of evolving external references on a quarterly cadence?
A security director and a finance controller disagree about who can shut down a customer-facing agent after a harmful output. What should the governance operating model specify?