AI Governance

The policy layer. Written before the rollout, because the alternative is a policy written after an incident, and those policies are always worse.

When to use

• Before AI reaches a GTM team at any scale
• Somebody discovers reps pasting customer data into a consumer chatbot
• Legal, security, or a works council asks what the policy is
• Adoption is being blocked by fear rather than by capability
• Procurement or a customer security review asks about AI use

Inputs

• Needs from user: which tools people are already using (ask without consequence, or you get a false answer), what customer data exists, contractual and regulatory obligations, and whether any staff are represented
• Reads: workspace/agents/context/guardrails.md

Workflow

1. Survey the shadow AI first, and make it safe to answer

People are already using AI. A policy written as though they are not is a policy about an imaginary company.

Ask what tools are in use, for what, with what data, and state explicitly that the answer carries no consequence. An amnesty gets you the truth. A compliance-framed question gets you silence and the behavior continues unobserved.

The findings are usually: a consumer chatbot with customer names in it, a meeting recorder nobody approved, an unvetted writing tool with a browser extension, and one person running something genuinely useful that should be sanctioned and shared.

2. Draw the data boundary as three tiers

The most-used part of the policy, so it has to be readable by somebody who will not read the rest.

GREEN   – free to use with any approved tool
  Public information, your own marketing copy, published pricing,
  anonymized aggregate patterns, publicly posted job listings

YELLOW  – approved tools only, and only ones with a data agreement
  Account names, business context, deal notes with no personal detail,
  internal metrics that are not confidential

RED     – never enters any model, no exceptions
  Customer PII, credentials, unreleased financials, contract terms,
  employee personal data, anything under a specific confidentiality
  obligation, anything covered by a customer's own AI restriction

Name the tools, not the categories. "Approved tools" gets interpreted generously. A list of four named tools does not.

Check customer contracts for AI restrictions before finalizing the tiers. Enterprise agreements increasingly forbid processing the customer's data with third-party models, and one such clause governs the whole tier for that account.

3. Set the disclosure rules

Three separate questions, and teams conflate them.

The middle row is the one that matters most and the one most likely to be crossed by an eager growth experiment.

4. Address the fear directly, because it drives adoption more than capability does

The unspoken question in every GTM AI rollout is whether this eliminates the job. Ignoring it does not make it stop determining behavior. People do not enthusiastically adopt a tool they believe is measuring them for replacement.

Say something specific and falsifiable:

What changes:              <the tasks that go away>
What does not change:      <the judgment that stays with the person>
How performance is judged: <explicitly, and whether AI use is a factor>
Headcount intent:          <state it plainly, and do not lie>

Do not promise no impact if that is not the plan. A rollout built on a promise the team later watches break destroys trust in every subsequent one. Stating an uncomfortable truth costs less than a discovered evasion.

5. Sanction what is already working

The shadow AI survey usually finds one person doing something genuinely good. Sanctioning and sharing it is the highest-return governance move available, because it converts the policy from a restriction into a distribution channel.

A policy that only prohibits gets routed around. One that also promotes gets read.

6. Set the approval path for new tools

Requester → data tier the tool would touch → security and data agreement
review → named approver → added to the tool list with its tier

The path must be fast enough to use. An approval process taking three weeks produces shadow AI, which is the thing the policy exists to prevent. Two days is a reasonable target for anything touching only green data.

7. Handle representation and regulation where they apply

Where staff are represented, changes to how work is monitored or evaluated may require consultation before deployment rather than notification after. Where AI systems make or materially inform decisions about people, obligations around transparency, human oversight, and record-keeping may attach.

This skill does not give legal advice. It names the trigger conditions so they reach counsel before deployment rather than after:

• An AI system that scores, ranks, or filters people
• Monitoring that materially changes how performance is evaluated
• Automated decisions affecting customers with limited human review
• Processing personal data of individuals in a jurisdiction with specific AI rules

8. Write it to one page

A governance document nobody reads governs nothing. One page, the data tiers as a visible table, the tool list, the disclosure rules, the approval path, and a named owner. Everything else is an appendix.

Output

• Writes: workspace/agents/ai-policy.md
• Prints: the shadow AI findings, the three data tiers with named tools, the disclosure rules, the fear-and-headcount statement, the approval path with its target turnaround, and the escalation triggers for counsel

Rules & quality bar

• Survey shadow AI with an explicit amnesty. A compliance-framed question returns a false answer
• Name tools, not categories. "Approved tools" is read generously
• Check customer contracts for AI restrictions before setting the tiers
• Autonomous agents acting as people are always disclosed. This is the line
• Address headcount plainly, and never promise what is not the plan
• Sanction what is already working. A policy that only prohibits gets routed around
• The approval path must be fast enough to use. Slow approval manufactures shadow AI
• One page. An unread policy governs nothing
• This skill names legal trigger conditions, it does not give legal advice

Related skills

• Pairs with: agent-guardrails for the technical enforcement of the same boundaries
• Runs before: agent-rollout
• See also: docs/build-surface.md