D3 · Governance and Risk

This domain carries 18% of the mock — roughly 9 of 50 items. It tests whether you can build governance that enables safe adoption rather than governance that merely performs caution. Leaders who get this wrong either block everything (and drive shadow AI) or wave everything through (and inherit an incident). The material: a governance operating model with clear ownership and decision rights, a risk taxonomy you can apply to any use case, data-handling and residency rules, vendor and model risk, and the concrete enterprise controls available in ChatGPT Business and Enterprise. This connects directly to the credential landscape and to adoption: governance that is all friction is the surest way to kill adoption.

What you need to know

Governance is an operating model, not a document. It names who owns AI risk, who decides what, which policies apply, where use cases are reviewed, and how exceptions are granted. A usable risk taxonomy spans accuracy, privacy, security, IP, regulatory, reputational and workforce risk — each with a different owner and control. Data handling turns on classification and residency: what data may enter a tool, where it is processed, and whether it trains a model. The enterprise editions of ChatGPT ship real controls — SSO, SCIM, EKM, RBAC, compliance logs, data residency in ten regions, and no training on business data by default — that let a leader say “yes, safely” instead of “no”. The recurring judgement is telling enabling governance from governance theatre.

Learning objectives

By the end of this page you should be able to:

1. Design an AI governance operating model with ownership, decision rights, policy, review boards and exception paths.
2. Apply a seven-category risk taxonomy to classify and control any AI use case.
3. Decide data-handling and residency rules from data classification, not habit.
4. Assess vendor and model risk, including data-training and residency posture.
5. Map enterprise controls in ChatGPT Business/Enterprise to specific governance requirements.
6. Distinguish governance that enables safe adoption from governance that is theatre.

3.1 The governance operating model

Governance fails when nobody can say who decides. A working model answers five questions explicitly.

              AI GOVERNANCE OPERATING MODEL
  ┌──────────────────────────────────────────────────┐
  │  Executive sponsor  (owns AI risk)                │
  └───────────────┬──────────────────────────────────┘
                  │
      ┌───────────┴───────────┐
      ▼                       ▼
  Policy & standards     AI review board
  (acceptable use,       (cross-functional:
   data classes,          risk, legal, security,
   human review)          data, a business voice)
      │                       │
      ▼                       ▼
  Tiered decision rights  Exception path
  low → team              (time-boxed, conditioned,
  medium → function+risk   logged, reviewed)
  high → review board

The tiering is the load-bearing idea: most decisions never reach the board. A governance model that routes every request to a committee is theatre — it produces delay, not safety.

3.2 The risk taxonomy

You cannot control a risk you cannot name. Seven categories cover almost every AI use case, and each has a distinct owner and control.

The leadership point: these risks do not share an owner, so a single “AI risk lead” cannot carry them all. Governance assigns each category to the function that already owns that risk class.

3.3 Data handling and residency

Almost every AI incident traces to data — the wrong data entering a tool, or leaving a jurisdiction it should not. Two decisions govern this: classification (what may enter) and residency (where it is processed and stored).

  Data class            May it enter an AI tool?
  ─────────────────────────────────────────────
  Public                Yes
  Internal              Yes, in a governed workspace
  Confidential          Only in a governed workspace with
                        no-training terms + access control
  Regulated / PII       Only with a DPIA/legal sign-off,
                        residency confirmed, minimised
  Secret / restricted   No, unless explicitly cleared

The default that changes the whole risk conversation: in ChatGPT Business and Enterprise, business data is not used to train OpenAI’s models by default. That single fact is often the difference between “no” and “yes, in the governed workspace” for confidential data.

3.4 Vendor and model risk

Choosing a provider is a governance decision, not just a procurement one. Assess vendors on the controls that matter to your risk taxonomy.

Model risk adds a second layer: models change, deprecate and behave differently. A governed programme pins which models are approved for which risk tier and reviews changes — not every new model is automatically fit for a regulated workflow.

3.5 Enterprise controls in ChatGPT Business/Enterprise

A leader must know which control answers which requirement, because “we can’t use AI, it’s not secure” is usually false — the controls exist, they simply have to be turned on.

Note the split: SSO, SCIM, EKM, RBAC and the ten-region residency and default no-training posture are enterprise-grade capabilities; a leader mapping a requirement to a plan should confirm the specific edition rather than assume every control is in every tier.

3.6 Governance that enables vs governance that is theatre

The most examined leadership judgement in this domain is the difference between control that reduces risk and ritual that only signals caution.

Theatre feels safe and is dangerous: it delays value and increases risk, because a blocked workforce moves to ungoverned personal tools. Enabling governance channels demand into the governed workspace where the controls actually apply.

Decision framework

The G-U-A-R-D use-case review

Route each proposed use case through five checks. It replaces “does the committee like it?” with a repeatable test that most cases pass without a committee at all.

Low-tier cases clear G-U-A-R-D in minutes at the team level; only high-tier cases reach the review board.

Common mistakes

Scenario challenge

Scenario. You chair the AI review board at a European bank. Adoption is stalling: staff complain that every AI request — even summarising a public regulator circular — must wait for the monthly board, and three teams have quietly started using personal ChatGPT accounts on their phones to get work done. Meanwhile the head of wealth management wants to pilot an assistant that reads client portfolio data (regulated, EU-resident) to draft review notes, and legal is nervous about “AI training on client data”. The CISO asks you to fix both the bottleneck and the shadow-AI problem.

Expert reasoning trace.

1. Diagnose the bottleneck as theatre. Sending a public-circular summary to a monthly board is pure ritual: it adds delay and, worse, it causes the shadow-AI risk by making the governed path unusable. The fix is tiered decision rights — public and internal-class, low-stakes use cases decided at team level under a clear policy, with only high-risk cases reaching the board.

2. Address shadow AI by making the governed path faster than the ungoverned one. Personal-account use is the real incident risk: no logging, no residency control, no no-training guarantee. I provide a governed ChatGPT Business/Enterprise workspace with SSO and SCIM (so access follows employment) and communicate that it is both allowed and faster than waiting for the board. Enabling governance channels the demand back inside the controls.

3. Apply G-U-A-R-D to the wealth-management pilot. Grade: privacy + regulatory + reputational, high tier. Use-of-data: regulated client PII, so residency must be EU (ChatGPT Enterprise’s EU region) and the no-training-on-business-data default must be confirmed in writing — which directly answers legal’s fear. Accountable human: an adviser reviews and owns every drafted note. Rights: RBAC limits the assistant to the advisers who own those clients. Document: logged via the Compliance API, with a review date.

4. Answer legal precisely, not vaguely. “AI trains on our client data” is false for the governed workspace by default; I cite the no-training default and EU residency rather than debating in the abstract. The pilot proceeds as a high-tier, conditioned exception — human review, EU residency, RBAC, logging — not a blanket yes and not a reflexive no.

5. Close the loop. The board’s new job is high-risk cases and policy, not rubber-stamping trivia. Adoption recovers because the governed path is now the fast path.

Board-ready outcome: tiered decision rights end the bottleneck; a governed workspace with SSO/SCIM/logging pulls shadow AI back inside the controls; the wealth pilot proceeds under EU residency, default no-training, RBAC and human review as a documented high-tier exception; legal’s concern is answered with the specific control, not a slogan.

Assessment traps

Practice questions

Each item states how many responses to select. Commit before revealing.

Key takeaways

• Governance is an operating model — ownership, tiered decision rights, policy, a review board and an exception path — not a document.
• Use a seven-category risk taxonomy (accuracy, privacy, security, IP, regulatory, reputational, workforce), each assigned to its natural owner.
• Data handling turns on classification and residency; ChatGPT Enterprise offers residency in ten regions and does not train on business data by default.
• Assess vendor and model risk on training posture, residency, access controls, logging and certifications; pin approved models per risk tier.
• Know the enterprise controls — SSO, SCIM, EKM, RBAC, compliance logs, residency — and map each to the requirement it meets.
• Enabling governance decides most cases fast and channels demand into the governed workspace; theatre blocks everything and breeds shadow AI.
• Run G-U-A-R-D on each use case: grade risk, check use-of-data, name the accountable human, scope rights, document and revisit.