AI Governance for Small Teams: Simple Policies & Checklists

In small teams, “AI” can mean anything from a chatbot to an autocomplete feature. For governance, you need a working definition that is broad enough to catch real risk, but narrow enough that people can follow it. A practical definition: AI is any tool or feature that generates, classifies, ranks, or recommends content or decisions based on statistical patterns—especially when it is trained on large datasets or uses a model you did not create.

That includes: large language models (chatbots, meeting summarizers, coding assistants), image/video generators, automated scoring (lead scores, fraud flags), “smart” search, recommendation feeds, and vendor tools labeled “AI-powered.” It also includes workflow automation that uses AI to decide what to do next (e.g., auto-routing tickets based on message text).

• Counts as AI: generating text, rewriting copy, extracting entities, classifying emails, suggesting decisions, ranking candidates, summarizing private documents, running sentiment analysis, auto-writing code.
• Usually not AI (for this course): deterministic rules (if/then), simple templates, static reporting dashboards, spreadsheets with formulas, basic keyword search.

Common mistake: treating AI as “just another software tool.” Unlike normal software, AI outputs can be plausible but wrong, can reflect bias in training data, and can leak sensitive inputs through logs, prompts, connectors, or human copy/paste. Another mistake is focusing only on “model building.” Many teams do not train models; they use and buy AI. Governance must cover all three: use, buy, and build.

Milestone tie-in: once you adopt this definition, you can identify where AI shows up in everyday work. Ask: “Does this tool generate content, classify, or recommend?” If yes, it falls under your AI policy—no argument about labels required.

Teams often stall because the words feel heavy. Here is the simple split that keeps you moving.

Governance is the operating system: who decides, what rules exist, what steps happen before and after AI use, and how you document choices. Think “process and accountability.”

Ethics is the value lens: what your team believes is acceptable, fair, and respectful—especially when users or customers could be harmed. Think “should we do it, even if we can?”

Compliance is the external constraint: laws, regulations, contracts, and industry standards you must follow (privacy laws, security requirements, customer DPAs, procurement rules). Think “must do.”

• Governance turns ethics and compliance into day-to-day actions (checklists, approvals, logging, reviews).
• Ethics helps you set boundaries before you get pressured by deadlines (“we don’t use AI to decide hiring outcomes”).
• Compliance keeps you from breaking obligations, but it rarely tells you what is wise or safe in practice.

Milestone 1 (simple definition): a governance program for a small team can be as small as: a one-page policy, a one-page risk checklist, and a simple register of what AI tools you use. The goal is not to “be perfect.” The goal is to make decisions visible, consistent, and reviewable.

Engineering judgment shows up when you decide what level of formality fits the risk. A marketing team using AI for headline ideas needs a lighter process than a healthcare team summarizing patient notes. Governance is how you right-size the process without pretending all AI use is equal.

Most small teams touch AI in three ways: use (employees use tools), buy (you procure a vendor feature), and build (you integrate an API or ship an AI feature). Governance must follow the lifecycle, because risk shows up at different moments.

Use: People paste content into chatbots, connect tools to Google Drive, or ask an assistant to draft client responses. Risks here are often privacy and accidental disclosure. Practical control: define what data is allowed, require human review before sending outputs externally, and require approved accounts (not personal logins).

Buy: You add an “AI add-on” to a SaaS product. Risks here include vendor data handling, retention, training on your inputs, and unclear security posture. Practical control: an approval step before purchase or enablement, with a short vendor questionnaire (data use, retention, access controls, incident notification).

Build: You integrate an LLM API, ship a recommender, or automate decisions. Risks here include prompt injection, insecure connectors, logging sensitive prompts, and users over-trusting outputs. Practical control: threat modeling-lite, red teaming of common misuse cases, and release criteria (privacy review, safety tests, rollback plan).

• Where AI shows up in everyday work (Milestone 2): content creation, customer support, coding, analytics, recruiting, finance ops, knowledge management, and “smart” features inside existing tools.
• Approval steps: low-risk internal drafting may be “allowed by default,” while customer-facing automation requires explicit sign-off.

Common mistake: only reviewing AI at purchase time. Teams often start with “free trials” and personal accounts, and only later realize data has been shared or outputs were used in customer work. Your lifecycle approach should include a lightweight onboarding step: when someone starts using a new AI tool, it gets recorded and checked once.

You do not need a long risk taxonomy to start. For beginner governance, you can catch most issues with four failure modes: wrong, harmful, leaked, and unsafe. These map cleanly to the main risk types you’ll see: errors, bias, privacy, and security.

Wrong (errors): AI makes up facts, cites nonexistent sources, misreads a table, or writes buggy code. Outcome: customer misinformation, bad decisions, rework. Control: require human verification, cite sources, run tests, and keep AI outputs as drafts unless validated.

Harmful (bias and unfairness): AI produces discriminatory language, unfair rankings, or stereotypes; it may disadvantage certain user groups. Outcome: reputational harm, user harm, legal risk. Control: avoid high-stakes automation at first, review outputs for sensitive categories, and document “no-go” uses (e.g., hiring decisions without structured review).

Leaked (privacy and confidentiality): sensitive data is pasted into prompts, stored in logs, or shared through connectors. Outcome: breach, contract violation, loss of trust. Control: clear data handling rules, redaction, approved tools only, and least-privilege access for integrations.

Unsafe (security and misuse): prompt injection, jailbreaking, malicious outputs, or insecure agent actions (sending emails, executing code, calling tools). Outcome: account takeover, data exfiltration, operational disruption. Control: restrict tool permissions, separate environments, input/output filtering where appropriate, and “human-in-the-loop” for actions.

• Milestone 3: when you assess a use case, ask: could it be wrong, harmful, leaked, or unsafe? If any answer is “yes,” apply a stronger review step.

Common mistake: treating “bias” as the only ethics issue. In small teams, the most frequent incidents are mundane: someone pastes a customer list into a chatbot, or a confident but incorrect summary gets emailed. Your checklist should prioritize the failure modes you are most likely to experience next week.

Beginner governance is about reducing surprise. “Good enough” means: people know the rules, risky uses get a second set of eyes, and you can answer basic questions quickly (What tools do we use? What data do we allow? Who approved this?). You are aiming for lightweight consistency, not heavyweight committees.

Start by choosing your first governance goal (Milestone 4). Most small teams pick one of these:

• Reduce risk: prevent privacy leaks and insecure integrations; limit high-stakes automation; standardize safe prompting and data handling.
• Increase trust: improve output quality and reliability; ensure human review; make AI use transparent to customers when appropriate.

Then translate that goal into simple operating rules. Example “good enough” controls:

• Two-tier usage: Tier 1 (low risk, internal drafting) is allowed with basic rules; Tier 2 (customer-facing, sensitive data, automated actions) requires approval.
• Human review requirement: any external-facing content generated by AI must be reviewed and owned by a named person.
• Data boundary: no secrets, no personal data, no customer confidential info in unapproved tools; use redaction or approved enterprise accounts.
• Tool onboarding: new tools get a quick check for data retention, training-on-inputs, access controls, and export/deletion options.

Common mistakes: writing a policy that is too abstract (“use AI responsibly”) or too strict to follow (forcing legal review for every prompt). A policy that people ignore is worse than a small policy people actually use. Good governance fits your workflow: a checkbox in a ticket, a template in procurement, a short review step before launch.

Your starter kit has three parts: a policy (rules), a checklist (risk spotting), and a register (inventory). This is enough to run a lightweight review and incident process without technical skills.

1) One-page AI Use Policy (what people may do). Include: approved tools/accounts; data you must not share (credentials, customer PII, health/financial data, confidential contracts); rules for prompt sharing (no pasting sensitive prompts into public forums); requirements for human review; and when disclosure is needed (e.g., customer-facing AI assistance).

2) One-page Risk Checklist (what to check before using/buying/building). Keep it tied to the four failure modes:

• Wrong: How will outputs be verified? What is the fallback if AI is unavailable?
• Harmful: Does this affect people’s opportunities, prices, access, or treatment? Any protected/sensitive attributes involved?
• Leaked: What data enters the tool? Is it stored, logged, or used for training? Who can access it?
• Unsafe: Does the AI take actions (send, delete, purchase, execute)? What permissions does it have?

3) Simple AI Register (what exists). A spreadsheet is fine: tool name, owner, purpose, tier (1 or 2), data types used, approval date, renewal date, and notes on vendor terms.

Now write your “why now” statement (Milestone 5). Keep it short enough to read in a team meeting: “We’re adopting AI across writing, support, and engineering. To protect customer trust and move fast without surprises, we’re standardizing which tools we use, what data we share, and when we require review. This lets us benefit from AI while reducing privacy, security, and quality risks.”

Finally, define basic roles and a lightweight incident path: one person owns the policy, one person approves Tier 2 uses, and anyone can report issues in a shared channel. When an incident happens (wrong/harmful/leaked/unsafe), your process is: stop the use, capture what happened, notify the owner, decide containment, and update the policy/checklist so it is less likely next time. That feedback loop is governance in action.

An AI inventory is a living list of the AI-enabled tools, features, and integrations your team uses to create outputs or make decisions. It matters because it is the foundation for every later governance activity: policy, approvals, training, incident response, and audits. If you’re a small team, it also reduces cognitive load—people stop debating “do we use AI?” and start discussing specific tools and workflows.

For Milestone 1 (create your first AI tool list), start with a single table. Keep it small enough that you’ll maintain it. A good inventory includes both “obvious AI” (chatbots, image generators, model APIs) and “embedded AI” (CRM lead scoring, email triage, document summarization inside apps). Include any tool where a model influences content, recommendations, ranking, classification, or automation.

• Minimum fields: Tool name, where it’s used (team/workflow), purpose, owner, internal/external, free/paid, data in, data out, users, vendor, and a risk label.
• Rule of thumb: if the tool can see customer data, employee data, proprietary code, or business plans, it belongs in the inventory—even if it’s “just for drafting.”

Engineering judgment comes in when deciding the boundary: don’t inventory every minor feature toggle, but do inventory anything that changes decisions, creates user-facing text, or stores prompts/inputs. A common mistake is starting too big and quitting. Start with your top 10 tools and expand as you find “shadow AI.”

End this section by saving the inventory somewhere shared (not a personal note) and naming it clearly (e.g., “Team AI Inventory”). That simple act turns it into a governance artifact your team can reference during reviews and onboarding.

Shadow AI is any AI tool used without the team realizing it, documenting it, or setting expectations for data handling. It’s common in small teams because individuals optimize for speed: they sign up for a free assistant, paste in a customer email thread, generate a proposal, and move on. The risk is not that people are “doing something wrong”; it’s that no one has assessed the data exposure, output quality, or vendor terms.

To find shadow AI, use a low-friction discovery process. Ask “what do you use to draft, summarize, code, design, research, or transcribe?” rather than “are you using AI?” People often don’t label their behavior as AI use. Run a 20-minute inventory workshop and collect tools live. Then follow up asynchronously with a short form that asks for the tool name and what it’s used for.

• Where to look: browser extensions, meeting transcription add-ons, marketing/design generators, code copilots, automation tools (Zapier/Make-style flows), and built-in “smart” features in SaaS platforms.
• Signals: sudden jumps in content volume, unusually consistent writing style, faster PR turnaround, auto-generated summaries in notes, or “AI” settings toggled on in common apps.

Use judgment when responding. Don’t start with enforcement; start with visibility. Tell the team the objective is safe enablement: “We want to keep the tools that help, and make sure we don’t leak sensitive data.” This framing increases honesty and reduces the incentive to hide usage.

Once you discover a shadow tool, immediately apply Milestone 2: assign an owner and write a one-line purpose. Ownership prevents the tool from remaining “everyone’s responsibility,” which is functionally nobody’s.

After you have a list, add two simple categories that unlock better decisions: internal vs. external and free vs. paid. These are not about accounting; they’re proxies for control and risk. Internal tools (your own models, self-hosted services, or tightly managed enterprise deployments) typically allow stronger access controls and clearer data handling. External tools (public web apps, third-party APIs, consumer assistants) often have more variability in retention, training usage, and support.

Free vs. paid matters because paid plans often include enterprise controls: admin logs, SSO, contractual terms, and explicit data processing commitments. Free plans may be great for experimentation but are frequently the worst place to put any sensitive input. A common mistake is assuming “everyone uses it, so it must be fine.” Popularity is not a privacy policy.

• Practical workflow: add two columns to the inventory: “Deployment: internal/external” and “Plan: free/paid/enterprise.” If unsure, mark “unknown” and treat it as higher risk until clarified.
• Milestone tie-in: mapping each tool to a purpose and owner becomes easier when you can say, “This external free tool is used for drafting outbound emails.” That statement naturally raises the next question: “What data is being pasted into it?”

Engineering judgment: some external paid tools may be lower risk than an internal proof-of-concept with no access controls. Categories are not a verdict; they’re a way to prioritize which tools need more facts collected next.

Once categorized, you can set lightweight defaults (later chapters will formalize them), such as: “External free tools are allowed only for non-sensitive content,” and “External paid tools require an owner and a risk label before use.”

Milestone 4 is where governance becomes real: capture key facts about data in and data out. Every AI tool is a data pipeline. If you don’t document the touchpoints, you can’t enforce privacy rules, you can’t respond to incidents, and you can’t explain decisions to stakeholders.

Start by listing the input types people provide: customer tickets, call transcripts, contract text, internal strategy docs, source code, employee information, analytics exports, or “just a prompt.” Then list outputs: draft emails, code suggestions, summaries, classifications (e.g., sentiment), recommendations, or images. Record where outputs go next—into a customer reply, a public blog post, a sales deck, a product feature, or a support macro.

• Key questions to capture in the inventory: Does the tool receive personal data? Does it receive confidential business data? Are prompts stored? Are outputs stored? Are outputs reviewed by a human before external use?
• Common failure mode: teams document the tool but not the workflow. The risk usually sits in the handoff: AI-generated text shipped to customers without review, or code suggestions merged without tests.

Use engineering judgment to set “default safe handling.” For example, if the tool touches regulated or contractual data (health, financial, student records, or sensitive customer data), treat the tool as higher risk until you confirm retention and access controls. If the tool’s output is used to make decisions (prioritizing leads, flagging fraud, ranking applicants), note that explicitly—decision support should be governed differently than brainstorming.

Write the data touchpoints in plain language so non-technical teammates can follow them. The point is not to model your architecture; the point is to prevent accidental oversharing and to ensure outputs are used appropriately.

Even small teams can capture vendor facts that dramatically improve safety. You don’t need a full legal review to record the basics: who provides the tool, where it runs, and who can access it. This is often the difference between a manageable issue and an emergency when something breaks or data is exposed.

For each external tool, record the vendor name, the product name, and the access method (web app, API, plugin, embedded feature). Note the hosting model if you know it (vendor cloud, your cloud, on-prem). If you don’t know, write “unknown” and assign the owner to find out. This is not busywork: hosting affects data residency, logging, and your ability to restrict access.

• Access notes to capture: Who has accounts today? Is access via personal emails or company SSO? Is there an admin console? Can you revoke access quickly if someone leaves?
• Contract/process notes: Paid or free plan, renewal date (if any), and a link to the vendor’s terms/data policy or DPA if you have one.

Common mistakes include relying on one person’s personal account for a team workflow, or assuming “it’s just a website” so access doesn’t matter. In practice, a single account can become a single point of failure and a compliance risk. Another mistake is not recording where to go when something happens. Your inventory should include “support path”: who to contact internally (the owner) and where vendor support lives.

These vendor notes also help you make purchase decisions later. When you can compare tools side-by-side on access control, data handling, and hosting, you stop choosing tools purely on feature demos.

Milestone 3 is to classify tools by risk level (low/medium/high) so you can focus effort where it matters. The label is not about fear; it’s a prioritization mechanism. A small team cannot do deep reviews for every tool, so you need a quick, repeatable approach that produces consistent outcomes.

Use a simple rule set based on two dimensions: data sensitivity and impact of mistakes. Data sensitivity asks what the tool can see (public vs. confidential vs. personal/regulated). Impact asks what happens if the tool is wrong (minor inconvenience vs. customer harm vs. legal/financial harm). Combine them into a label:

• Low risk: no sensitive inputs; outputs used internally; mistakes are easily caught and low impact (e.g., brainstorming slogans with no proprietary info).
• Medium risk: some confidential inputs or outputs used externally with human review; mistakes could cause customer confusion or reputational damage (e.g., drafting customer emails from sanitized summaries).
• High risk: personal/regulated data, proprietary source code, security-sensitive content, or outputs used for decisions or shipped with minimal review (e.g., lead scoring that drives outreach, AI-generated support replies sent automatically, tools that process IDs or health info).

Engineering judgment: if a tool is “unknown” on key facts (retention, access, training usage), temporarily label it one level higher until clarified. This prevents uncertainty from silently becoming risk. Also note that “internal tool” does not automatically mean low risk; an internal model that can access your customer database and auto-take actions may be the highest risk system you have.

Finally, implement Milestone 5: set a monthly update habit. Put a 15-minute recurring calendar event where the team owner reviews new tools, removes retired ones, and re-checks high-risk entries. The inventory stays useful only if it reflects reality. Treat it like any other operational register: lightweight, consistent, and always ready when you need it.

Section 3.1: Policy basics: purpose, scope, and who it applies to

Start your policy with three sentences: purpose, scope, and who must follow it. This sounds obvious, but many teams skip it—and then argue later about whether the policy “counts” for contractors, interns, or a specific tool. Write it so nobody has to guess.

Purpose should be operational: “Help the team use AI to work faster while protecting privacy, client trust, and our brand.” Avoid vague goals like “be ethical,” because they do not tell someone what to do at 4:30 p.m. when a deadline hits.

Scope should define what counts as “AI” for your team: chat assistants, code assistants, image generators, transcription tools, automated scoring tools, and any feature labeled “AI” in a SaaS product. Include both free and paid tools, browser extensions, and “built-in AI” features in docs, CRM, support, and marketing platforms.

Applies to should be explicit: employees, contractors, and anyone acting on behalf of the team. If your team works with agencies, include them too. Then define the policy format milestone: keep it one page with headings that match decisions people make: Allowed / Limited / Not Allowed, plus Data Rules and Output Rules. This structure is easier to follow than a narrative document and reduces “policy drift” as tools change.

Common mistake: writing a policy that reads like a threat. A practical policy assumes people want to do the right thing and gives them a safe path. Reserve enforcement language for the end; start with clarity and usability.

Section 3.2: Allowed uses (safe examples) for common roles

People follow policies when they see themselves in the examples. Create an “Allowed uses” section that lists safe, everyday tasks by role. This is your acceleration zone: tasks where AI help is low-risk because the inputs are non-sensitive and the outputs are reviewed naturally as part of work.

Use concrete examples rather than categories like “brainstorming.” For instance:

• Customer support: draft a response template from a non-sensitive summary; propose troubleshooting steps using public documentation; rewrite for tone.
• Marketing: create headline variations; outline a blog post from public product features; generate social captions; translate copy that will be reviewed before publishing.
• Sales: draft a follow-up email using approved talk tracks; summarize a call transcript only if the transcript is stored in an approved tool and the customer has been informed when required.
• Engineering: generate unit test ideas; explain an error message; propose refactors; draft documentation; suggest code snippets that are then reviewed and tested.
• Operations/HR: draft job descriptions; rewrite policies for clarity; create onboarding checklists from internal non-sensitive process notes.

Also define “Limited uses” (allowed with extra steps). Examples: using AI to help with contract language, customer-facing medical/financial guidance, or any content that could be interpreted as official advice. Limited uses are not forbidden—they just require human review rules (see Section 3.5) and sometimes approval (for example, from a team lead).

Engineering judgment tip: If a task already has a strong review loop (PR review, editorial review, manager sign-off), it’s easier to allow AI assistance safely. If a task is often shipped “as-is” (quick replies, one-off analyses), treat it as higher risk and add guardrails.

Section 3.3: Prohibited uses (red lines) and why they exist

Your prohibited list should be short, memorable, and defensible. The goal is not to ban AI; it’s to draw clear red lines where AI use creates unacceptable harm, legal exposure, or trust damage. People are more likely to comply when you explain why a red line exists.

• No fully automated high-stakes decisions: Do not use AI to make final decisions about hiring, firing, promotions, credit/loans, insurance, pricing discrimination, eligibility, or account termination. Reason: these decisions can materially harm people and require accountable human judgment and documentation.
• No deception: Do not impersonate a human, fabricate endorsements, or create fake reviews/testimonials. Reason: trust and consumer protection.
• No disallowed content generation: Prohibit harassment, sexual content involving minors, instructions for wrongdoing, or any content that violates law or platform rules. Reason: obvious safety and legal exposure.
• No training or fine-tuning on restricted data without approval: Prohibit uploading customer datasets, internal logs, or proprietary content into external training pipelines unless explicitly approved. Reason: you may lose control of confidentiality and usage rights.
• No bypassing controls: Prohibit “shadow AI” workarounds such as using personal accounts/tools when a request was denied for risk reasons. Reason: this defeats governance and increases incident likelihood.

Common mistake: creating red lines that are too abstract, like “no unethical use.” Replace abstraction with behaviors people can recognize. Another mistake is over-banning (e.g., “no AI in customer support”), which pushes usage underground. If you can’t tolerate a use case, explain what safe alternative looks like (e.g., “use AI to draft internal notes, but a human writes the final message”).

Finally, add a one-sentence escalation rule: if someone is unsure whether an activity is prohibited, they must treat it as prohibited until reviewed by the designated owner (defined in the policy header).

Section 3.4: Data rules: personal data, secrets, client info, prompts

Data handling rules are the most important part of a small-team AI policy because they prevent the most common real-world incident: pasting sensitive information into a tool that stores it, reuses it, or exposes it via logs and support access. Write rules that answer one question: “What can I paste into an AI system?”

Use a simple three-tier model that fits on a page:

• Public: safe to share (published website text, public docs). Allowed in most tools.
• Internal: company-only but not highly sensitive (process notes, internal FAQs). Allowed only in approved tools/accounts.
• Sensitive/Restricted: personal data (PII), client confidential info, credentials, API keys, security details, unreleased financials, legal matters, health data. Never paste into general-purpose AI tools unless explicitly approved and contractually protected.

Be explicit about examples of personal data: names with contact details, addresses, government IDs, payment data, and any dataset that could identify an individual. Include “secrets” like passwords, tokens, private keys, and internal URLs that grant access. Small teams often forget that prompts are data: the prompt itself can contain restricted details, and prompts may be stored by vendors or copied into tickets and docs.

Add two practical rules people can execute:

• Redact before you paste: replace identifiers with placeholders (e.g., “Customer A,” “Order #123”).
• Use approved work accounts only: no personal accounts for work prompts, because retention and access controls are unknown.

Engineering judgment tip: if a tool offers “do not train on my data” but still stores prompts for abuse monitoring, treat it as retained unless you have confirmed retention terms. If you don’t have vendor clarity, default to using only Public data.

Section 3.5: Output rules: accuracy checks, citations, and labeling AI help

Most AI failures that reach customers are output failures: incorrect claims, made-up citations, unsafe advice, or confident nonsense. Your policy should treat AI output as a draft, not a source of truth. This is where you implement Milestone 4: human review rules for high-impact outputs.

Create a two-level review rule:

• Standard outputs (low impact): a human must read before sending/publishing; check for obvious errors; ensure tone and confidentiality are appropriate.
• High-impact outputs: require a second reviewer or designated approver. High-impact includes legal/financial/medical guidance, public statements, security instructions, HR decisions, and anything that could materially affect a customer or employee.

Add concrete checking steps that do not require technical skills:

• Accuracy: verify key facts against primary sources (your docs, the contract, system-of-record data). Do not “fact-check” by asking another model.
• Citations: if the output references laws, studies, or numbers, require a link or source. If you cannot find a source quickly, remove the claim or rewrite it as an assumption.
• Labeling: define when to disclose AI assistance. For example: external content that appears authoritative (reports, research summaries) should state “Drafted with AI assistance and reviewed by [role].” Internal notes may not require labeling but should be attributable to a human owner.

Common mistake: equating “review” with a quick skim. Your policy should define what reviewers are responsible for: factual correctness of key claims, compliance with data rules, and appropriateness for the audience. Make ownership explicit: every AI-assisted artifact has a human accountable for it.

Practical outcome: this turns AI into a speed tool without letting it become an unchecked decision-maker or an unverified publisher.

Section 3.6: Exceptions and enforcement: what happens when rules are broken

Even a simple policy needs an exceptions path; otherwise, people will route around it. Define a lightweight request-and-approval process for cases that fall outside “Allowed” usage but may still be reasonable. Keep it fast: a short form in your ticketing tool or a template message in chat.

An exceptions request should capture: tool name, use case, what data will be used, who reviews outputs, and how results will be stored. Approvals should be role-based, not committee-based. For small teams, a common model is: team lead approves business need; security/privacy owner (or the most relevant person) approves data handling; legal approves contract terms when buying.

Enforcement should be predictable and proportionate. Spell out what happens when rules are broken:

• Unintentional minor violation: stop the activity, document what happened, share a short learning note, and update the policy if it was unclear.
• Significant or repeated violation: access may be restricted; manager review; mandatory retraining.
• Intentional or deceptive misuse: formal disciplinary action, up to termination, depending on severity.

Also define an incident reporting path that does not punish honesty: “If you think sensitive data was pasted into a tool, report it within 24 hours to X.” Include what to report (tool, time, what data, whether it was shared externally). The faster you know, the more you can do (revoke tokens, rotate credentials, contact vendors).

Milestone 5 is publishing and communication. Don’t just upload the policy to a drive. Announce it, explain the intent in plain language, and pin the one-page version where work happens (wiki homepage, onboarding checklist, shared channel). Revisit monthly for the first quarter: your goal is not perfection, it is a stable habit that keeps AI usage visible, safe, and useful.

Section 4.1: Role design from first principles (accountability vs. blame)

Start with a principle: governance roles exist to create clarity, not to create blame. If people think a role is a liability, they will avoid it, rush reviews, or keep AI usage unofficial. Your goal is “single-threaded accountability” (someone owns the outcome) paired with “shared responsibility” (others can challenge decisions without being punished for slowing things down).

For small teams, three roles are enough for most AI activities:

• Owner: the person proposing or running the AI use case. They write the intake, keep documentation current, and monitor real-world performance. Ownership is not “they caused the problem”; it means they’re the coordinator and point-of-contact.
• Reviewer: the person who checks the proposal for obvious issues (privacy, security, quality, user impact). Their job is to ask “what could go wrong?” and confirm mitigations exist.
• Approver: the person who accepts the remaining risk and authorizes use. This is often a manager, product lead, or operations lead. Approvers should not rewrite the design; they decide whether the plan is acceptable.

Common mistake: assigning the same person to all three roles. If you do that, you’ve created paperwork, not governance. If your team is too small to fully separate roles, keep one separation: the approver should be different from the owner for anything external-facing or data-sensitive.

Practical outcome: every AI tool and use case has a named owner, a lightweight peer review, and a clear “yes” decision by someone with authority to accept risk. That’s accountability without scapegoating.

Section 4.2: RACI-style clarity without the jargon (who decides what)

You don’t need governance jargon, but you do need decision clarity: who proposes, who checks, who decides, and who needs to be informed. Write it in plain language so it survives staff changes and busy weeks.

Use a simple table (even in a shared doc) that maps common AI decisions to your three roles:

• New AI use case (same tool, new workflow): Owner drafts intake; Reviewer checks; Approver signs off if not low-risk.
• New AI tool (new vendor or model): Owner drafts intake + vendor notes; Reviewer checks privacy/security basics; Approver signs off and confirms procurement path.
• Prompt/data handling rules: Owner proposes how prompts will be shared and what data can be used; Reviewer checks privacy and confidentiality; Approver confirms alignment with company policy.
• Production rollout: Owner defines success metrics and monitoring; Reviewer confirms test plan; Approver confirms go-live.
• Incident response (bad output, leak, customer complaint): Owner leads triage and documentation; Reviewer helps analyze causes; Approver decides on customer communication and whether to pause the system.

Two-step maximum is a design constraint, not a suggestion. If everything needs three approvals, people will route around the process. A workable default is: (1) peer review by the reviewer, then (2) approval by a manager/lead. If it’s clearly low risk (e.g., internal brainstorming with no sensitive data), you can define “owner-only” usage that still requires an intake entry and a decision log entry.

Practical outcome: you remove “decision fog.” People know exactly what they can do today, what needs review, and who can make the call when time is tight.

Section 4.3: The intake form: what questions to ask before using AI

An intake step is the heartbeat of a small-team review loop. It’s a short form (one page) that forces the owner to think clearly before an experiment becomes a dependency. Keep it fast: 10–15 questions, mostly checkboxes, with a few short text fields.

Your intake form should cover five areas:

• Purpose and scope: What problem are we solving? Who uses it (internal staff, customers, public)? What outputs will be created (emails, code, decisions, images)?
• Data and privacy: What data goes in? Any personal data, customer data, internal confidential info, or regulated data? Will prompts be stored/shared? Where will outputs be stored?
• Model/tool behavior: Is the tool generative? Does it cite sources? Can it browse the web? Can it take actions (send emails, change records)?
• Human-in-the-loop: Who reviews outputs before use? What must always be verified (facts, quotes, pricing, legal claims)?
• Risk and monitoring: What could go wrong? What’s the fallback if the tool is unavailable? How will you detect bad outputs or drift?

Engineering judgment matters here: you are not trying to predict every failure mode; you are trying to identify the “big rocks” early. A common mistake is treating the intake as a compliance exercise and writing vague answers (“we will be careful”). Replace vagueness with concrete controls: “No customer PII in prompts,” “All outbound content must be reviewed by a human,” “Outputs stored in ticketing system with labels.”

Practical outcome: you can onboard new AI tools or new use cases without chaos, and you create a consistent record that makes later audits, incident reviews, and team handoffs straightforward.

Section 4.4: Review gates: when a manager or privacy check is needed

Not every AI use needs the same scrutiny. The trick is to define a short “high-risk” trigger list that automatically adds an extra review gate. This keeps the normal path fast while ensuring you slow down for the situations most likely to cause harm.

Define your default workflow as two steps max: Reviewer check → Approver decision. Then add triggers that require a manager or privacy check (or both). Example high-risk triggers:

• Personal data in prompts, training, or outputs (customers, employees, applicants).
• External-facing output that could be perceived as official company communication (marketing, support, press, legal).
• Automated decisions or recommendations affecting people (eligibility, pricing, prioritization, moderation).
• Access to internal systems (tools that can read/write to CRM, email, databases, code repos).
• Regulated or sensitive domains (health, finance, children, employment, safety-critical operations).
• Data retention uncertainty (you don’t know if prompts are stored, used for training, or accessible to others).

When a trigger fires, the process changes in a predictable way. For example: the reviewer must confirm data handling and a privacy-safe configuration, and the approver must explicitly accept the risk in the decision log. If your organization has a privacy or security point-person, route triggered items to them as a time-boxed consult, not an open-ended review.

Common mistake: making the trigger list too long or too subjective (“anything risky”). Keep it short and binary. People should be able to answer in under a minute whether escalation is required.

Practical outcome: you preserve speed for low-risk work while reliably catching the few scenarios that create reputational, legal, or customer harm.

Section 4.5: Procurement basics: evaluating vendors in plain terms

Small teams often adopt AI through a credit card and a browser tab. That’s convenient, but procurement is where many governance risks hide: data retention, unclear ownership, weak security controls, and surprise pricing. You don’t need a complex vendor program; you need a short, repeatable vendor check.

Evaluate AI vendors with plain questions tied to real operational needs:

• Data use: Do they store prompts and outputs? Do they use them to train models? Can you opt out? What is the retention period?
• Access control: Can you enforce SSO, MFA, and role-based access? Can you remove users quickly?
• Security posture: Do they provide basic assurances (e.g., SOC 2 or equivalent)? How do they handle breaches?
• Compliance fit: Any data residency needs? Support for DPA (data processing addendum)? Subprocessors list available?
• Reliability and support: SLA, downtime history, support response time, export options.
• Cost and lock-in: Pricing model, usage caps, overage behavior, and how you can leave (export your data, delete your data).

Engineering judgment: match diligence to impact. A tool used for internal brainstorming with no sensitive data can be approved with minimal vendor checks. A tool that touches customer records or generates regulated communications needs stronger assurances and a clear contract path.

Common mistake: approving a vendor because it “has enterprise customers.” That’s not evidence your use case is safe. Your governance loop should require that the owner documents the vendor’s data practices and that the approver confirms the risk is acceptable.

Practical outcome: fewer surprises—no accidental data sharing, fewer emergency migrations, and clearer costs as AI usage grows.

Section 4.6: Keeping decisions consistent with a decision log

The final piece of a small-team review loop is consistency over time. People forget why choices were made, and new team members re-litigate old decisions. A simple decision log prevents this. It’s not bureaucracy; it’s memory.

Your decision log can be a spreadsheet or a page in your team wiki. Each entry should be short and searchable:

• Date and use case/tool name
• Owner / Reviewer / Approver
• Decision: approved, approved with conditions, or rejected
• Conditions: e.g., “No PII,” “Human review required,” “Do not store prompts,” “Only allowed for internal drafts”
• High-risk triggers that applied (if any)
• Links: intake form, vendor notes, configs, monitoring plan
• Review date: when to re-check (monthly or quarterly)

Schedule periodic check-ins—monthly for fast-changing usage, quarterly for stable environments. The check-in agenda is simple: confirm the tool is still being used as approved, review any incidents or near-misses, update conditions, and confirm the owner is still the right person.

Common mistake: logging only approvals. Log rejections and “approved with conditions” decisions too, because they teach the team what good looks like. Another mistake is forgetting to update the log when a pilot becomes production—make “status change” a reason to add a new entry or update the existing one.

Practical outcome: you can answer, quickly and confidently, “Why are we using this AI tool, under what rules, and who signed off?” That’s the backbone of governance that remains lightweight even as your team evolves.

Section 5.1: Why checklists work (human limits and repeatable steps)

Checklists work because people are inconsistent under time pressure. In AI work, inconsistency shows up as “I thought it was fine” decisions: someone pastes sensitive data once, skips source checking once, or shares outputs that sound authoritative but are wrong. None of these are rare edge cases—they’re normal human shortcuts. A checklist is a way to design around those limits without requiring everyone to become an expert.

For small teams, the checklist also acts as a shared contract. It clarifies what “good enough” looks like and reduces debates that burn time. If the checklist says “no customer identifiers in prompts,” the discussion becomes about whether the content contains identifiers, not whether privacy matters. That shift is crucial: governance becomes operational, not philosophical.

To make a checklist usable, keep each line item: (1) observable (“Does the prompt contain X?”), (2) actionable (“Remove or mask X; use a synthetic example”), and (3) assigned (“Author checks; reviewer verifies”). Avoid vague items like “be ethical” or “ensure accuracy.” Replace them with concrete gates such as “verify two key claims against a primary source.”

Common mistakes include making a checklist too long (people stop using it), too abstract (people interpret it differently), or detached from workflow (it lives in a doc nobody opens). Place the checklist where work happens: a template in your ticketing system, a pull request checklist, or a “ready to share” note in your doc. Treat the completed checklist as a lightweight record of engineering judgment: what you checked, what you fixed, and what you accepted with rationale.

Section 5.2: Privacy-by-default: what not to paste into AI tools

Milestone 1 is a privacy checklist for prompts and data sharing. The core rule is simple: assume anything you paste into an AI tool could be stored, reviewed for safety, or leaked via logs. Even when vendors promise strong controls, privacy-by-default keeps you safe across tools, accounts, and future changes.

Start by defining “restricted data” for your team in plain language. Typical categories include: customer personal data (names, emails, phone numbers, addresses), government IDs, payment details, authentication secrets, internal financials, unreleased product plans, legal matters, health information, and any dataset you promised to keep confidential. Then encode “what not to paste” as a prompt checklist that runs before you hit Enter.

• No identifiers: Remove direct identifiers (name, email) and indirect identifiers (unique job title plus location) that could re-identify a person.
• No secrets: Never paste API keys, passwords, private tokens, SSH keys, or admin URLs.
• No raw customer text by default: Support tickets, chat logs, and call transcripts often contain hidden personal details. Use redaction or summaries first.
• Use the minimum: Provide only the fields needed for the task; prefer synthetic examples.
• Document consent and purpose: If you must use real data, record why, which tool/account, and whether policy allows it.

Make the checklist practical with “safe alternatives.” Examples: mask values (“[EMAIL]”), aggregate counts instead of rows, paraphrase a message rather than pasting it, or create a minimal repro sample that contains no real customer data. A common mistake is forgetting attachments and screenshots—teams redact text but upload a spreadsheet or paste a screenshot with visible names. Your checklist should explicitly cover files, images, and links.

Outcome: by the end of this milestone you should have a one-page “Prompt Privacy Rules” sheet that anyone can apply in 30 seconds and a default behavior of using synthetic or redacted inputs.

Section 5.3: Quality controls: sampling, second eyes, and source checking

Milestone 2 is a quality checklist aimed at accuracy and hallucinations. The practical reality is that AI can produce fluent output that is wrong in subtle ways. Your goal is not perfection; it is to reduce predictable failures with a small set of repeatable controls.

Start by classifying the output type, because the right checks differ. For internal brainstorming, you may accept higher error rates. For customer-facing instructions, legal claims, medical guidance, pricing, or technical configuration steps, you need stronger controls. Your checklist should explicitly ask: “What is the impact if this is wrong?” That single question drives the level of review.

• Sampling: For bulk generation (many emails, many summaries), review a sample. Define a minimum (e.g., 10 items or 5%, whichever is larger) and expand the sample if you find issues.
• Second eyes: Require a second person to read any high-impact output before sending or publishing. The reviewer’s job is to spot confident errors, missing constraints, and unclear language.
• Source checking: For factual claims, require citations to primary sources (your docs, official vendor docs, contracts). If the model can’t provide a source, treat the claim as unverified.
• Boundaries: Confirm the output stays within your policy (no prohibited advice, no guarantees, no sensitive data).
• Regenerate with constraints: If quality is off, adjust the prompt: specify audience, format, assumptions, and “if unsure, ask questions.”

Common mistakes include trusting the first draft, checking only grammar (not correctness), and failing to test edge cases. Add a simple “challenge pass”: ask the model to list uncertainties, or to produce counterexamples, or to provide a step-by-step rationale you can verify. The practical outcome is a workflow where AI speeds up drafting, but humans own correctness—especially at customer touchpoints.

Section 5.4: Harm and bias: spotting risky language and unequal impact

Milestone 3 is a fairness checklist to catch harmful or biased outputs early. Bias in small-team AI use often appears in subtle forms: stereotyped descriptions, unequal tone in customer communication, exclusionary language in job posts, or “policy” text that discourages certain groups. You do not need a research lab to reduce these risks—you need a few consistent review habits.

First, define where harm can occur in your context. If you generate marketing copy, you risk stereotypes and exclusion. If you summarize tickets, you risk misrepresenting customers or using disrespectful labels. If you draft hiring materials, you risk discouraging protected groups. Your checklist should include a quick “who is affected?” prompt: name the user groups and stakeholders impacted by the output.

• Check for loaded descriptors: Remove language that assigns moral judgment, intelligence, or intent to people (“lazy,” “crazy,” “illegal” used casually).
• Equality of service: If the output guides decisions (priority, eligibility, escalation), verify it does not introduce different rules for different groups.
• Neutral tone: Confirm the content is respectful and professional, especially in summaries of complaints or disputes.
• Representation test: For examples and personas, vary names, regions, and situations to avoid one “default” identity.
• Harmful advice gate: Flag outputs that could facilitate wrongdoing (harassment, discrimination, self-harm) or that give medical/legal/financial directives beyond your allowed scope.

A common mistake is treating fairness as only “no slurs.” The more frequent risk is unequal impact from seemingly neutral wording (for example, “must have native English” when it’s not required). Another mistake is assuming the model is “objective.” Your practical outcome is a lightweight review step where you scan for risk patterns and adjust wording, examples, or decision logic before content reaches users.

Section 5.5: Security basics: accounts, permissions, and data retention

Milestone 4 is a security checklist focused on access and account risks. Many AI incidents in small teams are not sophisticated attacks; they are ordinary security lapses: shared logins, personal accounts used for work, overbroad permissions, and unclear retention rules. Because AI tools often handle sensitive context (documents, conversations, code), account hygiene matters.

Start with identity and access management. Your checklist should require: named accounts (no shared passwords), strong authentication (MFA), and role-based access (only the people who need it). If your AI tool integrates with Google Drive, Slack, GitHub, or your CRM, treat that integration like any other system connection: it can expose more than you expect.

• Accounts: Work accounts only; MFA enabled; disable accounts promptly when people leave.
• Permissions: Least privilege for teams, projects, and connectors; review permissions quarterly or after org changes.
• Retention: Know whether prompts/outputs are stored, for how long, and who can access logs. Prefer settings that limit retention where possible.
• Approved tools list: If a tool is not approved, define a simple approval path (who reviews, what they check).
• Export/sharing controls: Prevent accidental public links, uncontrolled downloads, or copy/paste into untrusted channels.

Common mistakes include assuming “enterprise” equals safe, forgetting that browser extensions can read content, and ignoring model settings that allow training on your data. Your practical outcome is a minimum security baseline: controlled accounts, explicit retention expectations, and a habit of reviewing what the tool can access before connecting it to internal systems.

Section 5.6: Release readiness: when it’s safe to ship or share outputs

Milestone 5 combines privacy, quality, fairness, and security into one “go/no-go” checklist for launches. This is the moment where checklists become a decision tool. Instead of arguing abstractly, you decide: are we ready to publish this content, ship this feature, or share these outputs with customers?

Your combined checklist should be short enough to run at the end of a project or before a major share-out. It should also define who can say “go.” For small teams, a practical model is: the author completes the checklist, and a designated reviewer (team lead, product owner, or rotating “AI steward”) signs off for customer-facing or high-impact releases.

• Privacy gate: No restricted data in prompts, attachments, examples, logs, or screenshots; any exceptions documented and approved.
• Quality gate: High-impact claims verified against sources; sampling completed for bulk outputs; second-eyes review done where required.
• Fairness gate: Language reviewed for harmful framing; examples and criteria checked for unequal impact; escalation path used for edge cases.
• Security gate: Correct accounts and permissions; connectors reviewed; retention settings confirmed; sharing controls set.
• Incident readiness: You know what to do if something goes wrong: how to pull content back, who to notify, and how to record the incident.

Make “no-go” meaningful by pairing it with fast fixes. If privacy fails, redact and rerun. If quality fails, narrow the scope, add citations, or require human-authored final wording. If fairness fails, adjust tone and examples and re-review. If security fails, fix access before shipping. The practical outcome is a repeatable launch habit: you catch problems early, you can show what you checked, and you can ship with confidence without adding heavy process.

Section 6.1: Incident basics: examples (leak, harmful output, bad decision)

Milestone 1 is to define what counts as an AI incident for your team. If you don’t define it, people will guess—and they’ll usually under-report because they’re unsure, embarrassed, or too busy. Your definition should be broad enough to capture meaningful risk, but narrow enough that it doesn’t label every typo as an emergency.

A practical definition: an AI incident is any event where an AI tool, AI-generated output, or AI-enabled decision (a) exposes restricted data, (b) creates harm or credible risk to people, customers, or the business, or (c) leads to a materially wrong decision that wouldn’t likely have happened without the AI.

• Leak (privacy/data): A teammate pastes customer notes (names, emails, medical/financial details, or internal IDs) into a public chatbot; a vendor tool stores prompts by default; a screenshot of a model response reveals confidential roadmap details.
• Harmful output: AI generates biased hiring advice, unsafe medical guidance, discriminatory language, or content that violates your brand standards; the model produces instructions for wrongdoing; a support bot responds rudely or inaccurately in a way that escalates a customer issue.
• Bad decision: A “summary” omits a key contract clause; an AI analysis misclassifies tickets so the wrong customers get refunds; a code assistant suggests insecure code that ships; an internal risk score becomes the basis for denying service without review.

Common mistake: only counting incidents once there is external damage. For small teams, near-misses are gold. A near-miss (caught before sending, publishing, or deploying) should be reported at a lower severity because it reveals a gap in your workflow.

Make the definition operational by including “report triggers” in plain language: “If you used AI with customer data,” “If an AI output would embarrass us if posted online,” or “If AI influenced a decision about a person.” This creates a shared reflex and reduces hesitation.

Section 6.2: Triage steps: stop, assess impact, notify, document

Milestone 2 is a simple report-and-respond process. You want four steps that fit on one screen and work regardless of whether the incident involves marketing copy or production code. A good triage process is consistent, quick, and calm: stop, assess impact, notify, document.

1) Stop: Pause the activity that could spread harm. Don’t keep prompting “until it looks right.” Don’t ship the change “just this once.” If it’s customer-facing, disable the feature, pause the campaign, revert the commit, or switch to manual review. Stopping is not an admission of failure; it is a safety control.

2) Assess impact: Do a fast, bounded assessment (15–30 minutes). Ask: What data was involved? Who could be affected (customers, employees, partners)? How many items (one email vs. 10,000 records)? Is it ongoing? What’s the likelihood of real-world harm? If you lack certainty, assume a higher risk until proven otherwise.

3) Notify: Define a short notification chain. For small teams, one “AI owner” (or operations lead) plus one privacy/security point of contact is usually enough. If the incident touches regulated data, employment decisions, or public statements, include legal/compliance or a designated executive sponsor. Make it explicit when to notify an external party (e.g., vendor support, customers) and who approves that message.

4) Document: Capture the minimum facts while they are fresh: tool name/version, where the output appeared, who saw it, what inputs were used (or a safe summary), timestamps, and actions taken. Documentation is not for blame; it’s for learning and defensibility.

Common mistake: triage becomes a debate about whether it is “really an incident.” Avoid this by letting anyone report and by classifying severity later. If it feels like it might matter, it should be logged. Your process should reward early reporting with quick support, not extra work.

Section 6.3: Corrective actions: fix the prompt, process, tool, or access

After triage, Milestone 3 begins: you turn an incident into a fix. Corrective actions should target the true failure mode, not just the visible symptom. In small teams, most AI incidents come from one of four places: the prompt, the process, the tool, or access.

Fix the prompt: If the model produced unsafe or misleading content, improve instructions and constraints. Add “do not” rules (e.g., “Do not infer medical conditions”), force citations to internal sources, or require a structured output with checks (“List assumptions,” “Flag uncertainty,” “Ask clarifying questions before advising”). Keep a prompt snippet library so people don’t re-invent risky prompts.

Fix the process: If the incident occurred because AI output was treated as final, add a human review step at the right point. Examples: require a second-person check for outbound customer messages generated by AI; add a checklist item: “Verify with source doc”; label drafts clearly (“AI-assisted draft—needs review”). The best process fix is the smallest change that reliably prevents repetition.

Fix the tool: Sometimes the right fix is switching configurations or vendors: disable prompt logging, tighten retention, restrict plugins, turn off web browsing, or use an enterprise plan with better privacy controls. If hallucinations are unacceptable, use retrieval from approved documents, or constrain use to summarization instead of decision-making.

Fix access: Many incidents are permission problems. Remove access for high-risk tools, separate accounts, use SSO, set role-based permissions, and limit who can connect integrations to customer data. If contractors use AI, explicitly cover them in the policy and onboarding.

Close the loop with a brief “what changed” note and a date to re-check. Common mistake: writing a long postmortem that no one reads. Prefer a short incident note plus one concrete control improvement. Governance succeeds when fixes are observable in day-to-day behavior.

Section 6.4: The governance folder: what to store and where

Milestone 3 also includes templates, because documentation should be easy. Create a single “governance folder” in the tool your team already uses (Google Drive, Notion, Confluence, SharePoint). Keep it boring, searchable, and shared with the right people. The point is not perfect recordkeeping; it is having the right artifacts when someone asks, “Why did we choose this tool?” or “What did we do after that incident?”

Minimum contents:

• AI Tool Register (template): Tool name, owner, purpose, data types used, risk level, link to vendor terms, retention settings, and approval date. Keep it to one page per tool.
• Decision Log (template): Key governance decisions: what was approved/rejected, who approved, what risks were considered, and what mitigations were required. This prevents “policy drift” as people join and leave.
• Incident Notes (template): Date/time, reporter, description, category (leak/harmful output/bad decision), severity, immediate containment, affected parties, and corrective action. Include a field for “near-miss” so people feel safe reporting early.

Where to store sensitive details: be careful not to create a new data leak through documentation. Store raw prompts or outputs only if necessary, and redact personal data. Often, a summarized description (“customer email with name removed”) is enough. Restrict incident notes to a small group if they contain security or HR-sensitive information.

Common mistake: scattering documents across email threads and chat messages. Your governance folder should be the single source of truth. Link to it from your AI use policy and pin it in your team chat so reporting feels like a normal workflow, not a special event.

Section 6.5: Training and adoption: making rules easy to follow

Milestone 4 is to run a mini training and publish FAQs. Small teams don’t need a certification program; they need shared expectations and quick answers in the moment of use. Plan a 30–45 minute session that covers: what AI is allowed for, what data is restricted, how to use the risk checklist, and how to report incidents without fear.

Make the training practical. Bring three real examples from your work: a customer email draft, a meeting summary, and a data analysis task. Show what “good” looks like (sanitized inputs, clear prompt constraints, human review). Then show what “not allowed” looks like (pasting raw customer records into a public tool, using AI to make final HR decisions, or publishing AI content without review).

Your FAQ should remove friction. Include questions like: “Can I paste customer text if I remove names?”, “Can I use AI for code?”, “What if I already pasted something sensitive?”, “Which tools are approved?”, and “Who do I message if I’m unsure?” Put the FAQ in the same place people work, not in a hidden policy document.

Adoption depends on social design. Assign a visible point person (often the AI owner) who answers questions quickly and treats reports as helpful. Praise near-miss reporting. If people feel punished for raising issues, they will stop reporting—and you will only learn about incidents when customers do.

Common mistake: training focuses on abstract ethics instead of daily decisions. Teach rules as defaults: what to do every time (sanitize, label drafts, verify against sources) and what to do never (share secrets, bypass review, automate high-stakes decisions without oversight).

Section 6.6: Metrics that matter: fewer surprises, faster review, better trust

Milestone 5 is a 30-day rollout plan with success measures. Metrics should reinforce the behaviors you want: early reporting, fast containment, and steady improvement. Avoid vanity metrics like “number of AI prompts written.” Instead, measure governance outcomes: fewer surprises, faster review, better trust.

A practical 30-day plan:

• Days 1–7 (Set foundations): Publish the incident definition and triage steps; create the governance folder; add the three templates; name an AI owner and backup; list approved tools (even if it’s just “these two are approved; everything else needs review”).
• Days 8–14 (Pilot workflows): Pick one or two AI use cases (e.g., meeting summaries and customer email drafts). Require the risk checklist and labeling. Start the tool register entries for anything used in the pilot.
• Days 15–21 (Training + FAQs): Run the mini training; publish the FAQ; add a simple “report an incident” link or form; run one tabletop exercise: walk through a hypothetical leak and practice stop/assess/notify/document.
• Days 22–30 (Review + adjust): Review the first month of logs: what slowed people down, what confused them, what tools lack owners. Update prompts, checklists, and approvals. Announce one improvement publicly so the team sees governance producing value.

Suggested metrics for a small team: median time from report to containment; number of near-misses reported (higher at first is good); percentage of AI tools with an owner and register entry; review turnaround time for new tools; and the count of customer-facing AI outputs that passed required review.

Common mistake: aiming for zero incidents. A mature governance program often sees more incident reports early because people finally have a safe way to flag problems. Success looks like faster response, fewer repeated failures, and increasing confidence from stakeholders who can see that AI use is intentional and controlled.