The governance team was given three months to produce the company's AI policy. They spent two months reviewing other companies' documents. They spent two weeks writing. They spent one week in review cycles.
The result was twelve pages of principles that looked like every other company's twelve pages of principles. The general counsel said it was fine. The head of responsible AI said it committed the company to nothing. They were both right. The team had drafted a document when they should have been designing a governance system.
The most important drafting insight is the distinction between a policy document and a governance system. A policy document states values and commitments. A governance system specifies who does what, when, with what authority, and with what consequences. Effective AI governance policy drafts a governance system — not just a values statement.
This means the key questions during drafting are not "what do we believe about AI?" but rather: Who is responsible for each governance function? What specific actions are required and when? What constitutes compliance vs. non-compliance? What happens when governance requirements are not met? How will compliance be monitored and verified?
Scope definition: Precisely which AI systems and use cases does this policy cover? Scope should be defined positively (what is included) and tested by asking whether each major AI use case in the organization is covered. Exclusions should be explicit and justified — not discovered by implication.
Risk classification criteria: How will AI systems be classified by risk level? What criteria determine tier assignment? Who makes the classification decision? What governance requirements apply to each tier? Classification criteria should be specific enough that two people applying them independently would reach the same result.
Pre-deployment requirements: What must happen before an AI system is deployed? Testing requirements, documentation requirements, review requirements — who conducts each, what constitutes satisfactory completion, who has authority to approve or reject.
Ongoing monitoring obligations: What monitoring occurs after deployment? What metrics are tracked? What thresholds trigger review? Who is responsible for monitoring and what is the escalation path?
Incident management: What constitutes an AI governance incident? What is the response process? Who is notified, by whom, within what timeframe? What remediation is required?
Accountability assignment: For each governance function, who is specifically responsible? Accountability assignment should be by role, not by name — governance survives personnel changes.
A governance-grade policy passes the two-reader test: two people reading the policy independently should reach the same conclusions about (1) whether a specific AI system is in scope, (2) what governance requirements apply to it, and (3) whether a specific governance action has been taken correctly. If reasonable readers would reach different conclusions, the policy needs more specificity.
When policy includes principles — as most do — those principles should be written to constrain behavior rather than express aspiration. The test: can someone use this principle to argue that a specific action is prohibited or required? A principle that cannot be used to prohibit any specific action is not a governance principle — it is a values statement. Both have legitimate roles, but they should not be confused.
Techniques for binding principles: Use active voice and specific actors. Specify what "compliance" means operationally. Connect each principle to at least one specific process or requirement. Identify who evaluates adherence and how.
The most effective policy drafting starts by identifying the failure modes the policy is designed to prevent — specific scenarios where AI causes harm, governance fails, or accountability disappears. Draft requirements that specifically address those failure modes. This produces governance with teeth rather than aspiration with polish.
Choose an organization type: a mid-sized hospital system using AI for patient triage, scheduling, and diagnostics; a regional bank using AI for credit decisions and fraud detection; or a media company using AI for content recommendation and ad targeting.
Draft the scope section of an AI governance policy for that organization. Your scope must: (1) State explicitly what AI systems are covered. (2) Apply the two-reader test — would two people agree on whether a specific AI system is in scope? (3) Include explicit justified exclusions if any. (4) Cover at least three distinct AI use cases the organization actually uses.
The policy team was proud of their draft. It had taken months. It was comprehensive. It addressed every concern raised in the review process.
The red team spent four hours on it. They found seven scenarios where the policy either did not apply, did not provide clear guidance, or provided guidance that produced perverse outcomes. None of the scenarios were exotic — they were all situations the organization would encounter in the next eighteen months.
The team revised. The red team found three more. They revised again. The policy that emerged from stress testing was unrecognizable from — and far more effective than — the original draft.
Policy drafters have a systematic bias: they draft for the scenarios they are thinking about, not the scenarios that will actually arise. Stress testing — systematically applying a draft policy to adversarial, edge, and failure scenarios — identifies gaps before they matter. The goal is not to find that the policy fails (some failure in stress testing is expected and useful) but to identify which failures are acceptable and which need to be addressed before deployment.
Scenario injection: Apply the policy to a set of specific, concrete scenarios — including edge cases, adversarial actors, and high-stakes situations. For each scenario: Does the policy apply? What does it require? Is that the right outcome? If the policy does not produce the right outcome, why — is it a scope gap, specificity gap, or accountability gap?
Adversarial reading: Read the policy as someone who wants to comply with the letter but not the spirit. Find every ambiguity that could be exploited. Find every commitment that could be satisfied nominally without achieving its purpose. These are the gaps most likely to be exploited — intentionally or by motivated reasoning — in practice.
Failure mode injection: Start with a list of AI governance failures (from modules 5 and 6: Amazon's hiring algorithm, IBM Watson Health, bias in credit scoring) and ask whether your policy would have prevented each failure. If not, why not — and should it?
Stakeholder stress testing: Apply the policy from the perspective of each affected stakeholder. Does it give an affected individual any recourse? Does it give a frontline employee clear guidance? Does it give a regulator anything verifiable? Each perspective reveals different gaps.
Effective stress testing requires genuine adversarial intent — the tester is trying to find failures, not validate the policy. This is psychologically difficult for the drafting team, who are invested in the policy's quality. Bringing in people outside the drafting process — or explicitly assigning a "red team" role — produces more rigorous stress testing than self-review.
Stress test results fall into three categories: Gaps that must be addressed — policy failures that would produce significant harm or liability if they occurred in practice. Gaps that are acceptable — policy failures in low-probability or low-stakes scenarios, or scenarios where the cost of addressing the gap exceeds the benefit. Gaps that are deferred — policy failures that would be better addressed through a different instrument (a separate procedure, training, a different policy) rather than the current document. Distinguishing these categories is as important as finding the gaps.
A common response to stress testing is to try to fix every gap — producing a policy so detailed it cannot be understood or implemented. Good policy design accepts that no policy is complete and focuses on addressing the most significant gaps while keeping the policy implementable. Perfect is the enemy of deployable.
Take a real corporate AI policy (from your M7 work, or choose a new one) and stress test it using at least two methods: scenario injection and adversarial reading.
For scenario injection: Present three concrete scenarios — one routine, one edge case, one adversarial — and apply the policy to each. For adversarial reading: Identify three specific ambiguities in the policy that a nominal complier could exploit. For each finding: categorize it (must-fix, acceptable, or better-handled-elsewhere) and explain why.
The draft went to seven stakeholders. Six responded with minor edits and general approval. One — the head of the customer service team whose AI system would be most directly affected — sent back two pages of concerns about implementation feasibility.
The policy team had a choice. They could make the minor edits and override the implementation concerns, citing the review deadline. Or they could delay the final policy, work through the implementation concerns, and produce something that could actually be deployed.
They chose the deadline. The policy was finalized. The customer service AI system was exempted from compliance for eighteen months pending "implementation review." The deadline had been met. The governance had not been achieved.
Policy review processes serve two functions that are often in tension: quality improvement (finding substantive problems with the draft) and buy-in generation (building support for the policy among stakeholders who will need to implement it). A review process optimized only for buy-in — one that collects signatures without substantive engagement — produces policies that look approved but cannot be implemented.
Review process design decisions that matter: Who reviews: People who will implement the policy should review it — they know where requirements will break down in practice. External experts can identify technical gaps. Legal reviews for compliance, but should not be the primary substantive reviewer. Affected communities (customers, employees) are rarely included in corporate policy review and often have the most important perspective.
What reviewers are asked: Reviewers asked "do you approve?" produce approvals. Reviewers asked "describe a scenario where this policy would fail" produce substantive engagement. Review questions should be designed to surface specific problems, not generate general approval.
How feedback is handled: Review processes that do not have a defined mechanism for adjudicating conflicting feedback produce either paralysis or domination by the most senior voice. Before review begins, define who has authority to make final decisions on contested points.
Policy iteration — the process of revising drafts in response to review feedback — has its own failure modes. Over-iteration: Incorporating every piece of feedback without prioritization produces a policy that satisfies every reviewer but serves no coherent governance purpose. Under-iteration: Making only cosmetic changes in response to substantive criticism produces a policy with the appearance of revision but not its substance. Scope creep iteration: Gradually expanding the policy's scope in response to stakeholder requests until it becomes unimplementable.
Effective iteration requires maintaining a clear statement of the policy's purpose and priority governance failures — and evaluating each proposed change against that purpose. Does this change better serve the governance purpose? Or does it serve a stakeholder's interest at the cost of governance coherence?
One of the most valuable — and most often skipped — review steps is an implementation feasibility review: asking the teams who will actually implement the policy whether it can be implemented with available resources, within realistic timelines, using existing systems. A policy that cannot be implemented is not a governance achievement. It is a governance liability — creating obligations the organization has committed to but cannot meet.
Design a stakeholder review process for an AI governance policy at a specific organization (use one from your earlier labs or choose a new one).
Specify: (1) Who reviews — list each reviewer role and explain what perspective they bring. (2) What each reviewer is asked — write the specific review questions you would send each stakeholder type. (3) How feedback is adjudicated — who has final authority on contested points. (4) What triggers iteration vs. finalization. Then identify the three most likely ways your review process would fail to surface real problems.
The policy launched with a company-wide email from the CEO. It was posted on the intranet. It was referenced in three external publications. The responsible AI team celebrated.
Eighteen months later, two of the governance bodies described in the policy had merged with other committees and lost their AI-specific mandate. One of the monitoring processes had been deprioritized due to resource constraints. The policy had not been updated. It described a governance system that no longer existed.
The policy had been published. The governance had not been maintained.
Publishing an AI governance policy is not the end of a governance project — it is the beginning of a governance commitment. Published policies create obligations that persist: internal compliance obligations, potential regulatory obligations, and reputational commitments that can be held against the organization if not met. Understanding what publishing means shapes how policies should be drafted and what governance infrastructure must be in place before publication.
What external publication commits the organization to: Regulators may treat published policies as evidence of organizational commitments in enforcement proceedings. Journalists and civil society organizations may use published policies as benchmarks against which to evaluate organizational behavior. In litigation, published policies may establish a standard of care the organization committed to. None of this is hypothetical — all three have occurred in AI governance contexts.
Governance systems erode without active maintenance. The mechanisms that make governance persist are as important as the governance design itself:
Policy ownership: A named role (not a named individual) with explicit responsibility for policy maintenance — reviewing, updating, and reporting on policy compliance. Without a designated owner, policies drift.
Scheduled review cycles: AI governance policies should have defined review triggers: a scheduled annual or biennial review, plus event-triggered reviews (significant AI capability changes, regulatory changes, major governance failures, organizational restructuring). Reviews without triggers do not happen.
Compliance reporting: Regular reporting on policy compliance — to the board, to senior leadership, or to a governance committee — creates accountability for maintaining governance. Without reporting, non-compliance is invisible.
Governance funding protection: Responsible AI teams and governance processes are among the first to be cut in budget pressures. Governance that survives only in good times is not effective governance. Minimum governance functions should have protected funding or be embedded in functions (legal, compliance, risk) that are harder to cut.
Internal accountability mechanisms — reporting, ownership, review cycles — are necessary but insufficient. External accountability — accountability to parties outside the organization — provides a check on internal governance that self-assessment cannot. External accountability mechanisms include: Third-party audits (as covered in module 6). Regulatory reporting where required. Civil society engagement — organizations that publish policies should be prepared to engage with civil society organizations that review and critique them. Affected individual channels — mechanisms for people affected by AI decisions to raise concerns and receive responses. The strongest external accountability mechanism is one that gives affected people real recourse — not just a complaint form that goes unanswered.
You have now studied the full arc of AI governance: from understanding why governance exists (M1), through the major regulatory frameworks (M2–M4), to corporate governance structures and their failures (M5–M6), to reading and critiquing real policies (M7), to drafting and stress-testing your own (M8). The through-line: governance is not a document. It is a system of accountability — with authority, specificity, persistence, and consequences — that constrains AI deployment and creates recourse when things go wrong. Every tool in this course is a tool for building, evaluating, or improving that system.
This is the capstone lab for the AI Governance course. You will draft, stress-test, and defend a complete section of an AI governance policy.
Step 1 — Draft: Write the accountability assignment section of an AI governance policy for a specific organization. Specify: named roles (not individuals), specific responsibilities, authority levels, escalation paths, and consequence mechanisms for non-compliance.
Step 2 — Stress-test: Apply adversarial reading to your own draft. Find three ways someone could satisfy your accountability requirements nominally without achieving their purpose.
Step 3 — Defend: Explain your three most important design choices and why you made them instead of alternatives you considered.
Drafting & Stress-Testing AI Governance Policy — 15 questions · 80% to pass