Most small businesses that have a brand guide keep it as a PDF. It has a logo page, a colour page and one page about voice that says something like “warm, expert, never stuffy.” Then somebody opens ChatGPT, asks for a newsletter, and gets copy that sounds like a bank apologising for an outage. The guide existed. The AI never saw it, and “never stuffy” would not have helped anyway.
AI brand guidelines fix that gap. They are your existing brand rules rewritten as instructions a model can follow and a colleague can check: who you write for, what you are allowed to claim, which words you use, what you never say, and who signs off. This article is about that translation and about keeping it current once five people are using it. If you don’t have an approved identity yet, build that first; the brand voice and identity prompts guide covers the creation side.
Start with what you already approved
The worst way to write AI brand guidelines is to ask an AI to write them. You get a polished, plausible brand that is slightly different from yours, and from then on every output drifts toward the invented version. Collect the real material instead: the brand guide, the last few pieces of copy you were happy with, the website About page, any legal or regulatory limits on what you can say, and the corrections you keep making by hand. That last item is the most useful: if you have told three people to stop writing “solutions,” that is a rule, whatever the PDF says.
Throughout this article we’ll use an illustrative business: Larchwood Physio, a two-clinic physiotherapy practice invented for this example. Health is a useful case because the cost of an off-brand sentence is not just tone. A cheerful promise to “fix your back pain for good” is a claim the practice can’t support.
Why a brand PDF makes a poor instruction
Brand guides are written for designers who fill gaps with judgment. A model fills gaps with the most average version of whatever you asked for, and adjectives like “premium” give it nothing to hold, because every brand on earth uses them.
Two pieces of vendor guidance point in the same direction. Anthropic’s prompting best practices recommend explaining the reason behind an instruction, since the model can generalise from the explanation, and telling it what to do rather than only what to avoid. In brand terms: “Don’t be salesy” is weak. “Write like a clinician explaining a plan to a patient, because our patients distrust hype and our regulator restricts outcome claims” gives the model a picture and a reason. The same principle runs through the do vs don’t guide to instruction prompts, which is worth reading before you rewrite your voice section.
The test for every rule: could a stranger read a paragraph and say yes or no to it? If not, rewrite the rule until they could.
The AI-ready guidelines template
This template has eleven sections, some only two lines long. The middle column shows the kind of rule that sounds fine in a PDF and does nothing in a prompt; the right column shows the usable version, using Larchwood Physio as the illustrative example.
| Section | Weak version | Usable version (illustrative) |
|---|---|---|
| Scope | For all content | Use for patient emails, website copy, social posts and leaflets. Not for clinical notes or referral letters. |
| Audience | Health-conscious adults | Adults 35 to 70 with a specific injury or recurring pain, often sceptical after a previous treatment didn’t help. Many are reading on a phone during a break. |
| Positioning | Premium, patient-first care | Longer first appointments (60 minutes) and a written plan after every assessment. Mention one of these when relevant; never both in one sentence. |
| Voice | Warm, expert, never stuffy | Write like a physiotherapist talking to a patient across the desk. Plain words, short paragraphs, “you” and “we.” Explain one medical term per piece at most, in brackets. |
| Approved claims | Highlight our expertise | All physios are registered with the national regulator. Assessments include a written plan. Evening appointments Tuesday and Thursday. |
| Prohibited claims | Avoid overpromising | No cure, guarantee or “pain-free” promises. No recovery timelines. No comparisons with GPs or other clinics. No patient stories without written consent on file. |
| Terminology | Use consistent language | Say “physio,” “appointment,” “plan.” Avoid “solutions,” “journey,” “wellness experience,” “clients.” |
| Format defaults | Keep it engaging | Emails under 150 words with one link. Social posts under 80 words, no hashtags beyond the clinic name, one emoji maximum. |
| Visual references | Clean, modern aesthetic | For image prompts: daylight, real clinic rooms, people over 35 in ordinary clothes. No stock-photo grins, no glowing anatomy graphics. |
| When information is missing | (usually absent) | If a price, date, name or clinical detail is not in the input, write [CHECK] instead of inventing it. |
| Owner and version | (usually absent) | Owner: practice manager. Version 1.3, reviewed 2026-10-01. Changes go through the owner only. |
The two sections that are usually missing do the most work. “When information is missing” stops the model from filling a blank with a confident fake price. “Owner and version” stops the guidelines from quietly forking into six slightly different copies on six laptops.
Here is the same structure as a blank block you can paste into a document or a project’s instructions field:
BRAND INSTRUCTIONS: [Business name], version [x.x], reviewed [date], owner [name] Use these for: [content types]. Do not use for: [exclusions]. Audience: [who, what they already believe, where they read] Positioning: [the one or two facts that make us different, and when to mention them] Voice: [describe how a specific person at the business talks, with reasons] Approved claims (use only these, word for word where possible): - [claim] Never claim or imply: - [prohibited claim] because [reason] Words we use / words we avoid: - Use: [list] Avoid: [list] Format defaults: [length, structure, links, emoji, hashtags per channel] Visual references (image or layout prompts only): [description] If a fact, price, date or name is not in my input, write [CHECK] instead of guessing. If these instructions conflict with a request, follow this order: prohibited claims, then the request's channel and format, then voice. Say which rule you followed.
One off-brand output, annotated
Rules are easier to judge against a real failure. Below, a team member at the illustrative Larchwood Physio asked a general assistant, with no brand instructions loaded, for a short email announcing new evening appointments. The output is a sample written for this article to show typical drift, not a captured result from any specific tool.
Request: “Write a short email telling patients we now have evening appointments on Tuesdays and Thursdays.”
Output before (sample): “Exciting news! 🎉 Your wellness journey just got easier. We’re thrilled to announce evening appointments, so you can finally say goodbye to back pain without missing work. Our expert team offers cutting-edge solutions tailored to you. Book now and feel like yourself again in just a few sessions!”
| Phrase | Rule broken | Why it matters |
|---|---|---|
| “wellness journey,” “solutions” | Terminology | On the avoid list; reads like a spa, not a clinic |
| “say goodbye to back pain” | Prohibited claims | An outcome promise the practice can’t support |
| “in just a few sessions” | Prohibited claims | A recovery timeline, and an invented one |
| “cutting-edge” | Approved claims | Not on the approved list; nothing backs it |
| “Exciting news! 🎉” | Voice | Nobody announces opening hours across a desk like this |
| No times given | Missing information | The model should have flagged [CHECK] instead of skipping the detail |
The fix was loading the template, and a longer list of banned words would have caught only two of those six problems. The lines doing most of the work are the voice reason (“our patients have often tried treatment before and distrust hype”) and the missing-information rule. With the full template loaded, the corrected version reads like this (also a sample):
Output after (sample): “From 4 November you can book physio appointments on Tuesday and Thursday evenings, [CHECK: times] at both clinics. If daytime appointments have been hard to fit around work, this should help. Evening slots are the same 60-minute appointments as during the day, with a written plan after your assessment. Book online or reply to this email and we’ll find a time.”
Notice the [CHECK]. The request never mentioned hours, and an honest placeholder is better than a believable invented “6 to 9 pm.” Someone still reviews it, now with a list to check against.
When instructions pull in different directions
Conflicts come in two kinds. The first is inside the guidelines: “keep emails under 150 words” against a request for a detailed explanation of a new service. The second is between layers of instructions. In ChatGPT, for example, OpenAI’s help article on projects says project instructions apply only inside that project and override your global custom instructions. Useful, but a colleague working outside the project gets their personal settings instead, which might say “be enthusiastic.”
Handle the first kind by writing the precedence into the guidelines, as the last line of the template does. Prohibited claims beat everything, because they protect the business. Channel format beats voice preference, because a 900-word Instagram caption is wrong however charming it is. Asking the model to name the rule it followed sounds fussy, but it makes conflicts visible to the reviewer. Handle the second kind with a team habit: brand work happens inside the shared project or assistant, and nowhere else.
Where to keep the guidelines so everyone uses one version
Pasting the rules into every chat works for about a week. After that, store the instructions where the tool applies them automatically. In ChatGPT that is a project’s instructions. In Claude, project instructions apply to every chat in the project, and you can add your brand PDF and approved examples to project knowledge. In Gemini, a Gem can hold the instructions and supporting files, and Gems can be shared with colleagues; Workspace admins can turn Gem sharing on or off. Sharing options differ by plan and change often, so check your own plan’s current documentation before you design the team setup around one of them.
Whatever the tool, keep the master copy outside it, in a document with a version number at the top, and treat the project or Gem as a deployed copy. If your team already runs a shared AI prompt library, the brand instructions belong in it as one record with an owner and a review date, and every content prompt in the library can point to it instead of repeating it.
The template works for a restaurant brand built with AI as well as a clinic; only the prohibited claims and terminology change, and those deserve the most thought.
Keeping the guidelines alive
Brand instructions decay in a predictable way. A new service launches and nobody adds its approved description, so the model improvises one. A team member fixes the same phrase in every draft for a month and never tells the owner. Six months later the guidelines are technically in place and practically ignored.
Three habits prevent most of this. First, every correction a reviewer makes twice becomes a proposed rule, sent to the owner, not added locally. Second, the owner keeps a short changelog at the bottom of the master document (“v1.3: added evening appointments to approved claims; removed ‘clients’ from allowed terms”), and updates the deployed copies the same day. Third, keep two or three standard test requests, such as the evening-appointments email, and rerun them after every change and whenever your AI tool announces a model update. If the output drifts, you find out from a test, not from a patient.
None of this needs new software, just one owner and rules a stranger could check. If you want more practical systems like this, Direktorium covers AI for small-business work in plain terms, and if you’d rather have the brand instructions built and set up for your team, BBDirector can do it for you.
