Lab 04 · Write the Team AI-Usage Policy

Rafael Mendes is VP of Engineering at Kernwork Consulting, a fictional 140-person software services firm. Two of his largest clients have contractually incompatible positions: Client A (a bank) prohibits any public AI tool from touching their code or data; Client B (a retailer) permits enterprise-tier tools with a no-training clause. Meanwhile his engineers are already using AI daily — some on approved tools, some not, most with no idea where the lines are. There is no policy. Rafael's view, and the correct one: an unwritten policy is a policy of "whatever each engineer guesses," and the first guess that goes wrong lands in a client's legal department. You will write the policy, then attack it.

You will need

• A chat AIfree ChatGPT, Claude, or Gemini, as drafting partner and red-team adversary.
• A doc for the policy and the violation-scenario test log.
• Timeabout 90 minutes.
• No real dataall client terms and scenarios below are synthetic. Never paste real contract language into an unapproved tool.

The inputs

CLIENT CONTRACT EXCERPTS (synthetic)
Client A (Meridian Bank): "Supplier shall not process, transmit, or
  expose Client Code or Client Data to any third-party AI or machine
  learning service, whether or not such service claims non-retention.
  Violation is a material breach."
Client B (Corville Retail): "AI-assisted development is permitted
  using enterprise-tier tools under a signed DPA with training on
  customer content disabled. Supplier maintains a register of tools
  used on the engagement."

CURRENT TOOL REALITY (from an informal survey Rafael ran)
- 61 engineers use a personal-account chatbot at least weekly
- 34 use an AI IDE plugin; 9 of those on Client A code
- 3 teams run agentic coding tools; one has repo write access
- Nobody could name which tools are approved. There is no list.

SEEDED VIOLATION SCENARIOS (you will test your policy against these)
S1: An engineer pastes a production database connection string into
    a personal chatbot account while debugging a config issue.
S2: An engineer on the Meridian (Client A) team uses an AI IDE
    plugin for autocomplete on Meridian repository code.
S3: A team's coding agent, configured with repo write access,
    auto-merges its own PR to main on a Corville service.
S4: An engineer pastes a Meridian stack trace into the enterprise-
    tier chatbot. The trace includes function names, file paths,
    and three lines of surrounding Meridian source code.
S5: An engineer uses the approved enterprise chatbot — but signed
    in on a personal free account, because SSO was "being slow,"
    to summarize Corville sprint requirements.
S6: An engineer has the approved AI notetaker join a Meridian
    architecture call. The vendor's default settings retain audio
    for model improvement. Nobody changed the defaults.

Steps

1. 1.

   Map the obligations before writing rules — ten minutes, no AI. From the two contract excerpts, write down what each client actually binds Kernwork to. Note the asymmetry: Client A's clause covers any third-party AI service regardless of retention claims; Client B's permission is conditional (enterprise tier + DPA + no-training + tool register). Every policy rule you write must trace to an obligation, a risk, or a stated company value — rules without a traceable "why" get ignored.

2. 2.

   Draft the data classification. Prompt: "Draft a four-tier data classification for a software services firm: Public, Internal, Client-Confidential, Restricted. For each tier: definition, examples an engineer would recognize (source code, stack traces, credentials, meeting audio, sprint docs), and which AI tool categories may touch it." Edit the output: make sure stack traces and meeting recordings are explicitly classified — engineers reliably treat both as harmless.

3. 3.

   Build the approved-tool matrix. Rows: tool categories (enterprise chatbot, AI IDE plugin, agentic coding tool, AI notetaker, personal-account anything). Columns: general internal work, Client B engagements, Client A engagements. Each cell: allowed / allowed-with-conditions / prohibited, with the condition named (SSO-enforced account, no-training config verified, register entry, human merge gate). The Client A column should be mostly red — that is the contract, not caution.

4. 4.

   Write the client-code boundary rules. The rules that prevent cross-contamination: client code stays in client-designated repos and tools; no client material in personal accounts ever; engagement-specific tool registers; and the one engineers forget — derived artifacts (stack traces, logs, error messages, screenshots, call audio) inherit the classification of their source.

5. 5.

   Define review gates and the agent rule. AI-assisted code follows the normal review path with AI-origin noted. Agentic tools get their own clause: no agent merges its own work; write access requires a named human owner, an audit trail, and a rollback path. Keep it to five lines — gates that read like an appendix get skipped.

6. 6.

   Design the exception process. A policy without an exception path becomes a policy people route around silently. Specify: who can request (anyone), who decides (named role, not committee), SLA (48 hours), what gets logged, and the default posture (time-boxed yes with conditions beats slow no). Include one worked example.

7. 7.

   Red-team against all six scenarios. For each of S1–S6, write a test-log entry: What happened? Which policy clause applies? Is it a violation, and of what severity? What is the response — and does the policy actually say all of that, or did you just infer it? Where the policy is silent or ambiguous, amend it and note the amendment. This log is a graded artifact; S4–S6 are where drafts fail.

8. 8.

   Add the response ladder and communicate. A severity ladder (self-report vs discovered; first vs repeat; negligent vs willful) with proportionate responses — the goal is surfacing mistakes fast, so self-reporting must be visibly cheaper than being caught. Close with the one-page rollout note to all engineers: what changed, the three rules that matter most, where to ask.

Verify your work

A complete lab has all of the following:

• •
  A four-tier data classification in which stack traces, logs, screenshots, and meeting audio explicitly inherit their source's classification.
• •
  An approved-tool matrix with a per-client column, conditions named per cell, and personal accounts prohibited for anything above Public.
• •
  An agent clause: no self-merge, named human owner, audit trail, rollback path.
• •
  An exception process with a named decider, 48-hour SLA, and logging.
• •
  A six-row violation test log where every ruling cites a specific clause — and at least one amendment made because a scenario exposed silence or ambiguity.
• •
  A severity ladder where self-reporting is explicitly cheaper than discovery.