The Safety Inspection

Eight lessons of stations, and we've been carrying a question the whole way — parked in Lesson 1, dodged in Lesson 4, waved at in Lesson 5. Time to face it in full: you are running AI automation on work data, and your employer has opinions about that. Maybe written ones. Maybe strong ones. Maybe ones nobody's checked since before agents existed.

Here's why this lesson exists, in one honest sentence: the single fastest way to get AI tools banned at a company is one person doing something careless with them — and the single best protection for your automations is being the person who visibly did it right. This is the inspection that keeps your kitchen open.

What you'll plate today

A written safety policy for your kitchen — enforced by the kitchen itself — plus the script for the IT/manager conversation, and an honest look at what happens when the answer is no.

Ingredients

• Your prep-station kitchen, all stations running
• Your company's AI/data policy, if one exists (search the intranet for "AI policy", "acceptable use", "data classification" — actually look; guessing is what we're here to end)
• About 30 minutes

Cook

1. Understand what your kitchen actually does with data

You can't defend what you can't describe. Make the kitchen explain itself:

Audit this kitchen like a data inspector. For every station —
butler, sous-chef, line cook, meetings, board, grind, plater —
answer three questions in a table, AUDIT.md:

1. What data does it touch, and where does that data live?
2. What leaves my machine? (Be precise: what the AI processes
   counts as leaving — say so per station.)
3. What does it NEVER touch, by rule?

No softening. This table is for showing to someone whose job is
to be suspicious.

Read AUDIT.md slowly. The middle column is the honest one — the same truth you learned in Cook Your Own Data: what the agent reads, the AI provider processes. Your exports, your masking, your skip-HR rules were never paranoia; they were this table looking good in advance.

2. Write the house law

From AUDIT.md and our habits since Lesson 1, write SAFETY.md —
this kitchen's law:

- NEVER ENTERS: other people's private data (mail, HR, reviews),
  customer personal data, credentials, anything marked confidential,
  [add your company's specific categories].
- MASK FIRST: names→roles, accounts, amounts when the analysis
  doesn't need them.
- MY MACHINE ONLY: no work data in anything deployed or shared.
- MY NAME, MY SEND: nothing leaves under my name untasted.

Then enforce it: add a CLAUDE.md rule to check new data against
SAFETY.md and refuse-with-explanation when it fails.

That last step matters more than the document. Policies people have to remember, fail. Policies the kitchen enforces on itself, hold — you built the same idea as a door code in Dinner Service; this is the data version.

3. The conversation — script included

If your company has a policy: read it against AUDIT.md and note honestly where you stand. If it doesn't — or it's ChatGPT-era vague — you have the better move: ask first, visibly. Here's the script, and its tone is the whole trick:

"I've been using AI tooling to automate some of my own work — file organization, drafting my reports, my own meeting notes. Everything runs on my machine against my own files; here's a one-page audit of exactly what touches what. I'd like to keep going — is there anything here you'd want me to do differently?"

Notice what the script does: it leads with the audit (you're the prepared one in the room), scopes to your own work product, and hands them the easy yes. Most ITs, handed this, say some version of "this is fine, thanks for asking" — and now your kitchen has a license instead of a secret.

4. When the answer is no — the honest part

Sometimes the answer is no: regulated industry, subscription-tier rules about training data, a blanket policy written in fear. This course's honest position: a no at work doesn't close your kitchen — it moves it. Everything you've built runs identically on your personal life (Lesson 4 said so from the start), your side projects, your Dinner Service graduation app. And workplace policies are living documents — the person who asked professionally in July is the first one consulted when the policy modernizes in January. Not yet ≠ never.

Save point "the inspection". Log: kitchen audited, law written,
conversation [had / scheduled / not needed because policy covers it].

When it burns

• You genuinely can't find any policy — that's information too: it means you're early, which is exactly when asking-first is cheapest and most appreciated. Use the script.
• The policy allows "approved tools" and yours isn't listed — the ask becomes specific: "what's the path to getting a tool reviewed?" You have the audit ready. That's usually 90% of the review.
• A colleague says "just don't tell them" — that's the careless person from this lesson's first paragraph, mid-origin-story. Your automations survive on being defensible; don't trade that for convenience.
• Your masking feels like it's degrading the analysis — sometimes true, always tunable: "which masked fields, if unmasked, would actually change the result? Let's discuss only those" — often the answer is none, and when it isn't, that's a category for the IT conversation, not a rule to quietly bend.
• This lesson made you nervous about lessons 2–8 — good; now resolve it, don't carry it: run the audit, and fix anything that surprises you today. The kitchen that's inspectable is the kitchen that relaxes.

Order up

□ AUDIT.md: every station's data, in suspicious-reader language
□ SAFETY.md written — and enforced by the kitchen itself
□ The conversation had (or consciously scheduled, or covered)
□ You know what a "no" moves — and what it doesn't close
□ CHORES.md: eighth DONE

Next up — Lesson 10: The Colleague's Order. The graduation: one chore automated for someone else — chosen, cooked, handed over with a receipt. The moment your kitchen starts feeding the room, the founder's story of this whole site starts happening to you.

Stuck on a step? Question box below.