One teammate drops an AI-generated image straight into a client deck. Another treats the same tool as internal reference only, and double-checks everything before it goes near a deliverable. Without a written AI usage guideline, copyright, security, and quality end up handled by whoever happens to be at the keyboard — until two of those judgment calls collide.
1. What Every Guideline Actually Needs to Cover
A usable guideline rests on three pillars, and a tool list alone isn’t one of them. Naming the platforms your team is allowed to use means nothing unless each entry is paired with its license terms and exactly how far its commercial-use rights extend. The single most important thing to get right first is what should never be fed into an AI tool in the first place.
An officially approved tool list, with commercial-use scope spelled out per platform
A hard line on what data must never be entered into an AI tool
A review step every AI output has to clear before it touches real work
2. Copyright Rules and Protecting Client Data
Setting a Copyright and License Standard
The copyright standard your team needs to check before using AI-generated images or text in a commercial project is the item guidelines reference most often. License terms differ by tool, and the fine print on referencing existing images varies just as much — write down the specific standard your team has agreed on, rather than leaving it to individual interpretation each time.
Principles for Protecting Client Data
Uploading a client’s unreleased product photos, contracts, or internal materials straight into a public AI tool is how security incidents start. The whole team needs to share one non-negotiable principle: pre-launch product images, client-identifying information, and anything with contract terms attached never go into a public AI tool’s input field. This is also worth weighing whenever your team discusses folding AI tools deeper into the design system itself.
💡 Pro tip — Writing the document isn’t what makes it stick. Build guideline literacy into new-hire onboarding, and name someone whose job is to update the document whenever a new tool or feature shows up. Guidelines that bend for genuinely new situations, rather than getting rigidly enforced against every edge case, are the ones people actually follow.
3. Building a Quality Review Process for AI Output
AI-generated images and mockups look impressively finished at first glance, and the failures aren’t limited to the obvious tells — six-fingered hands, garbled text. Subtly off product proportions, material patterns that would never survive real production, color combinations that clash with brand guidelines: these are the errors a trained eye catches, and everyone else misses. When that kind of output goes straight into client material or a live product without review, the problem usually surfaces after it’s too late to fix quietly.
Concept & exploration stage
Internal brainstorming and direction exploration only need a quick self-check before moving on.
Delivery & public stage
Client handoffs and anything touching a live service need a cross-review by at least two people.
Assigning a reviewer per project stage ahead of time, rather than picking one on the fly each time, keeps the workflow from stalling. Three items belong on every review checklist without exception: consistency with brand guidelines, copyright risk, and factual accuracy.
4. Making the Guideline Part of Team Culture
The design principles Dieter Rams wrote decades ago are still cited today not simply because the document itself was well written. It’s because those principles got applied over and over inside real product development, and later designers inherited them as a habit rather than a memo. The same is true of an AI usage guideline — publish it once and walk away, and it’s often forgotten within a few weeks.
The most common mistake is leaving the guideline out of onboarding entirely. New hires start working without even knowing the rules exist, and the same confusion repeats itself with every new hire after that. Building guideline literacy explicitly into onboarding, and asking one clarifying question about it during the first project review, does more for adoption than any amount of re-announcing the document.
💡 Pro tip — Keep a running log of every guideline revision on its own, separate from the document itself. When teammates can see the context behind “why this part changed,” they buy into the rule far more readily than when a rule simply appears.
Closing thoughts
Does the tool list spell out commercial-use scope per platform?
Have you clearly named what must never be entered into an AI tool?
Does new-hire onboarding include guideline literacy?
Is there an approval process for handling exceptions?
The safest way to keep a guideline current is to update it against each service’s own official terms of use, the way OpenAI publishes its usage policies. An AI usage guideline isn’t a document you write once and close the book on — it’s a living set of rules that has to be revisited every time the tools themselves change. If your team doesn’t have one yet, start with just two things: the approved tool list and the short list of what never gets entered into an AI tool.
Design Daily Life · Notes on design, daily