Your AI Governance Framework

Governance sounds like something only big companies need. In practice, it's just written answers to questions you're already answering every day in your head: Which tool can I use for this? Can this data go in? Who checks it? What do we do when it goes wrong?

Writing them down once — briefly — means you stop re-deciding, your team makes consistent choices, and when something does go wrong you already know what to do.

This lesson produces three documents: a personal AI charter, a team policy, and an incident response protocol. The templates are in the resources below.

---

1. Your personal AI charter — one page

MY AI CHARTER                               Reviewed: [date]

1. WHAT I USE AI FOR
   [e.g. first drafts, summarising my notes, data cleaning with
   code, brainstorming, automations for my own admin]

2. MY RED LINES — what I never do with AI
   [e.g. make final decisions about people; submit work as
   unassisted where disclosure is expected; put client data into
   personal accounts; clone anyone's voice or likeness]

3. APPROVED TOOLS AND DATA
   | Tool / plan | Allowed data | Not allowed |

4. HOW I VERIFY
   [e.g. numbers checked against source; citations opened; client-
   facing text read in full before sending; code-based calculations]

5. HOW I DISCLOSE
   [context → what I say]

6. HOW I PROTECT DATA
   [anonymisation rules; settings; what I delete]

Draft it with your assistant from your notes on the previous lessons, then cut ruthlessly. If it's longer than a page, you won't follow it.

2. The team AI policy

For a team or small organisation, add five elements:

1. Approved tools — a short list, with the plan type (e.g. "ChatGPT Business workspace — yes; personal accounts for work data — no").
2. Data classification — which data classes may go into which tools:

Data class	Examples	Approved AI tools
Public	Published website copy, public reports	Any approved tool
Internal	Internal docs, non-sensitive plans	Business/enterprise tools only
Confidential	Client data, financials, contracts	Named enterprise tools with DPA, anonymised where possible
Restricted	Health, identity numbers, credentials	Not permitted in AI tools

1. Human review requirements — which outputs need sign-off, and by whom (e.g. anything client-facing, published, legal, financial, or about individuals).
2. Documentation — prompts for recurring tasks kept in the shared library; AI use noted on client deliverables where required.
3. Escalation — who to tell when AI produces something harmful, or data goes somewhere it shouldn't.

Name an owner. A policy nobody owns decays within a quarter.

3. The review cadence

When	What	Time
Weekly	Quick look at AI usage and anything that nearly went wrong	15 min
Monthly	Review incidents and near-misses; update prompts and checks	30 min
Quarterly	Full review: tools, plans, data rules, new regulations, the charter itself	1–2 h

AI tools, their terms and the law change every few months. A policy dated more than a quarter ago should be treated as possibly wrong.

4. Incident response

When AI produces a bad output — a wrong figure sent to a client, confidential data pasted into the wrong tool, an automation messaging the wrong people:

1. Contain — stop the spread. Unsend, unpublish, pause the automation, revoke access.
2. Assess — what went wrong, who's affected, how serious is it? Is personal data involved? (Under the DPDP Rules, personal data breaches must be reported to the Data Protection Board and affected people — check the current requirements with legal.)
3. Communicate — tell those affected honestly and promptly, and escalate internally.
4. Document — what happened, why, and the timeline.
5. Learn — fix the root cause: the prompt, the check, the permission, the policy. Share the lesson with the team.

INCIDENT LOG
Date/time:
What happened:
Tool / workflow:
Data involved:        (none / internal / confidential / personal)
Who was affected:
Contained how, when:
Root cause:
Fix:
Policy or prompt updated:  yes / no  — link:
Owner:

A minor incident should take under fifteen minutes to log. Near-misses are worth logging too — they're free lessons.

5. An AI review board, even for two people

Formal committees aren't necessary. For a small team:

• One AI lead who owns the policy and the tool list.
• A 15-minute weekly check-in as part of an existing meeting.
• A shared log of incidents, near-misses and good prompts.

6. Documentation that earns its keep

• Prompt library with versions, owners and "what to check".
• Output review log for high-stakes outputs.
• Learning notes: what worked, what failed, what changed.

---

⚠️ Common mistakes

• Governance overkill. A 50-page policy nobody reads protects no one.
• One-time creation. Governance must be a living document, reviewed quarterly.
• No owner. Someone must be accountable.
• Only logging disasters. Near-misses are where the cheap lessons are.
• Banning everything. People route around bans with personal accounts — which is worse. Approve safe tools instead.

---

What's next: with guardrails in place, the next module looks ahead — how to keep up as AI keeps changing, without drowning in it.