The Shop AI Use Policy SOP

Purpose

This SOP is the standing rule for every use of an AI tool by anyone in the shop: what data may never go into one, who may use which tool for what, which outputs need a named person's sign-off before they leave, and how a breach of the rule is recorded and contained. It guarantees that a customer's card number, lockbox code or medical detail never ends up in a third party's chat history, and that when something does go wrong the shop finds out the same day and has a record. Without it, the most careless person sets the shop's actual policy, and the first exposure is discovered by the customer.

Scope

Covers every AI tool used for shop business on any device (chat assistants, AI features in the field software, AI phone answering, writing and image tools), used by owners, office staff, technicians and contractors working under the shop's name.

Does not cover how to check output (owned by The Verify-Before-You-Send Rule for AI Output; this SOP only says which outputs need sign-off), line-by-line message review (The AI-Drafted Customer Message Review SOP), changing an AI feature's configuration (The Automation Change Control SOP), or phone-agent call review (The Weekly AI Call Review SOP).

Roles and responsibilities

Role Owns Hands off to
Owner The policy itself, the approved-tool list, the final call on any breach Office manager, for day-to-day upkeep
Office manager Keeping the approved-tool list and the AI incident log current, quarterly review Owner, with the review findings and any open incident
Any user (office or field) Classifying data before it goes in, stripping identifiers, checking output, reporting their own slip the same day Approver, for any output in a sign-off category; office manager, for any incident
Approver Signing off outputs in the categories in step 6 User, who sends only after sign-off

Procedure

  1. Use only a tool on the approved list, under the account type listed. The list names each tool, the account type, whether its setting to stop training on your input is confirmed on, and which roles may use it for which tasks. Acceptance: the tool and account you are about to use appear on the list with today's role permission. What wrong looks like: a personal account on a free tier, a browser extension somebody installed, a tool a vendor added to software without anyone deciding to use it. Stop rule: if the tool is not on the list, do not use it for shop data; ask the office manager to assess it, which takes a day, not a week. Hazard: none physical, this is a desk decision.

  2. Classify everything you are about to paste before you paste it. Three classes. RED never goes in under any account: payment card numbers, bank account and routing numbers, government ID numbers, passwords, and every access code (gate, lockbox, garage keypad, alarm disarm), plus any customer health, disability or medical detail (an oxygen concentrator in the home, a medication fridge, a dementia note on the account) and any employee medical or disciplinary detail. AMBER goes in only after step 3: customer names, street addresses, phone numbers, email addresses, and photos showing a house number or a face. GREEN goes in as-is: generic trade questions, your own published marketing copy, a tech note that names no customer. Acceptance: you can name the class of every block of text in the paste. What wrong looks like: pasting a whole email thread because "the codes are buried at the bottom." Stop rule: any RED item present means you delete it from the paste first, or you do not use the tool for this task. Hazard: none physical; the exposure here is to the customer's property and privacy, which is why RED is absolute.

  3. Strip AMBER identifiers and replace them with placeholders. Write CUSTOMER, ADDRESS, PHONE, TECH in place of the real values; the model writes the draft around the placeholders and you fill them back in from the job record, which also forces the rung-2 check the verify rule requires. Acceptance: a read-through of the final paste shows no real name, number or street address. What wrong looks like: the customer's name survives in the email signature line or in a forwarded header. Stop rule: if you find a RED item at this stage that slipped past step 2 and it is already submitted, stop using the conversation and go straight to step 8. Hazard: none physical.

  4. Keep to the task categories your role allows. Office staff may draft and edit customer messages, summarize documents the shop owns, draft job postings and internal SOP drafts. Technicians may use AI to reword notes and to look up general background, but not to decide a repair, a wiring method or a safety call on site; see related: The Tech Followed an AI Wiring Answer. Nobody uses AI to compute a price, decide a warranty claim, or make a hiring or disciplinary decision. Acceptance: the task matches a category your role holds on the list. What wrong looks like: a coordinator asking the tool what to charge for a sewer camera inspection. Stop rule: out-of-category task means you stop and take it to the person who owns that decision. Hazard: for a technician on site, the hazard is acting on an unverified procedure near energy, gas or height; the control is that AI output never substitutes for the manufacturer instructions, the code or the lead tech, and live work waits until one of those confirms it.

  5. Check the output against the verification standard before anything else happens to it. Apply the ladder in The Verify-Before-You-Send Rule for AI Output: every specific gets checked at its rung. Acceptance: every number, name, date, citation and promise in the output has either been confirmed against a source or deleted. What wrong looks like: fixing the tone and sending, with a part number nobody looked up. Stop rule: any rung-3 item you cannot confirm comes out of the message. Hazard: none physical at the desk; where the output is an instruction a customer or tech will act on near gas, water and electricity, or a ladder, it moves to step 6 regardless of who wrote it.

  6. Get sign-off for the four categories that need a second person. (a) Anything that commits the shop: a price, a timeline, warranty or refund terms. (b) Any safety instruction to a customer or a crew member. (c) Anything public: a review response, a social post, a service page. (d) Anything about an employee. The approver is the owner or the person the owner has named for that category. Acceptance: the approver's initials and the time are recorded on the job or in the message log before it is sent. What wrong looks like: "I'll send it and tell them after." Stop rule: no approver reachable means it waits; a safety question from a customer that cannot wait goes to a tech by phone, not to an AI draft. Hazard: a delayed safety reply is itself a risk, so a customer who reports a gas smell, burning smell or water near electrical is told to leave and call the utility or 911, from outside, by a person, immediately.

  7. Mark the record where AI touched it. On the job, invoice or message log add a short note: "AI-drafted, checked by [name]." Acceptance: any customer-facing text drafted with AI carries the note. What wrong looks like: a dispute six months later where nobody can say who wrote the sentence in question. Stop rule: none, this is a record step; if it was missed, add it when noticed. Hazard: none physical.

  8. If the rule was broken, report it the same day and contain it. Tell the office manager within the working day: what went in, which tool and account, when. Containment, in order: delete the conversation if the tool allows; change any exposed access code with the customer that day (a lockbox or keypad code costs minutes to change and is the only fix that actually works); flag any exposed card number to your payment processor for advice. Acceptance: an incident log entry with time found, time contained and actions taken. What wrong looks like: quietly deleting the chat and saying nothing. Stop rule: if the exposed data was card data, a government ID number or medical information, the owner talks to the shop's attorney or insurer before telling the customer anything beyond "we are looking into it," because what the shop must disclose is a legal question. Hazard: none physical.

  9. Review the approved list and the incident log every quarter. The office manager re-checks each tool's data settings (vendors change them without notice) and reads the incident log for repeats. Acceptance: the list carries a review date within the last 92 days. What wrong looks like: a list last touched the month it was written. Stop rule: a tool whose training setting can no longer be confirmed comes off the list until it can. Hazard: none physical.

The legal layer at step 8. In the United States there is no single federal breach rule for a small service business; every state has its own data breach notification law, and they differ on what data triggers notice, how fast, and whom you tell. California's covers medical and health information; others are narrower. Card data is governed mainly by your merchant agreement and the card industry's security standard, which is contractual, not statute. This is not legal advice: at the step 8 fork, walk in with the incident log entry, the exact data exposed and the tool's data-retention terms.

The record this produces

  • Approved-tool list: tool, account type, training setting, permitted roles and tasks, last review date. Kept by the office manager; read by every user.
  • Job or message note: "AI-drafted, checked by [name]", plus approver initials and time. On the job record; read in disputes.
  • AI incident log: time found, reporter, tool and account, data class exposed, containment actions with times, customer contacted or not, owner decision. Kept by the office manager; read by the owner, any attorney or insurer, and at quarterly review.

Worked pass

Tuesday, 3:10 pm. Office coordinator Dana needs to reply to a customer who wants to move a garage door spring replacement and asks whether the tech can let himself in.

  • Step 1: Business-account chat assistant, training setting confirmed off at the review 41 days ago, coordinator role permitted for message drafts. Pass.
  • Step 2: The thread holds names, address, phone (AMBER) and, near the bottom, "keypad is 4417 if nobody's home" (RED). Dana pastes the whole thread before finishing the read. Step 2 fails: a RED item went in.
  • Step 3: On the read-through Dana sees the keypad code in the submitted prompt. Stop rule applies: stop using the conversation, go to step 8. No draft is used.
  • Step 8: Dana tells the office manager at 3:16 pm, six minutes after the paste. Conversation deleted at 3:18 pm. Office manager calls the customer at 3:25 pm: "we accidentally pasted your keypad code into a writing tool; we have deleted it, but we'd like you to change the code today as a precaution." Customer changes it at 3:40 pm and confirms by text. Data class was an access code, not card, ID or medical, so the owner fork does not trigger; the owner is informed at end of day and agrees. Incident log entry complete: found 3:16 pm, contained 3:40 pm, 30 minutes from paste to code change.
  • Restart at step 2: New paste of only the customer's two questions, no code. GREEN after step 3 placeholders: CUSTOMER, ADDRESS, TECH.
  • Step 5: Draft offers "Thursday 1 to 3 pm." Board shows Thursday 8 to 10 am open, not 1 to 3. Corrected from the board.
  • Step 6: The draft says the tech can let himself in. Entry without the customer present is a commitment, category (a). Office manager approves at 3:52 pm with the condition that the customer re-confirms the new code by phone, not text.
  • Step 7: Job note: "AI-drafted, checked by Dana, approved OM 3:52 pm." Sent 3:55 pm.

The containment that actually worked was the code change, not the deletion, and nothing sent carried an unchecked specific.

References

  • See related: The Verify-Before-You-Send Rule for AI Output
  • See related: What Not to Paste Into an AI Tool
  • See related: The Customer Privacy Promise When You Use AI
  • See related: The AI-Drafted Customer Message Review SOP
  • Your state attorney general's published guidance on your state's data breach notification law