Team Workflows & Governance

When one designer uses AI, quality rests on their personal judgement. When ten do, quality rests on whatever each of them happens to know - which is a recipe for drift. One person has a brilliant spec-drafting prompt; another uses a clumsy one and ships weaker work; a third pastes a confidential client brief into a free tool without thinking. None of this is malice. It is the natural entropy of a shared capability with no shared practice.

Governance is simply the act of making the good practice explicit and shared. The aim is not control for its own sake - it is to raise the floor (everyone works to the same safe standard) while keeping the ceiling high (your best people can still push). Get the balance wrong towards heaviness and people route around the rules; get it wrong towards looseness and you get the drift above. The sweet spot for most design studios is a handful of shared assets and a one-page policy, reviewed as the field changes.

Think of it the way you already think about drawing standards, file naming, or your specification templates. Nobody finds those oppressive; they are the quiet infrastructure that lets a team produce consistent work. AI governance is the same idea extended to a new capability.

The test of good governance is that people reach for it rather than around it. If your prompt library is faster than reinventing a prompt, people use it; if your policy answers a real question in plain language, people follow it. Governance that fails is invariably governance that got in the way - a twelve-page policy nobody read, an approval queue that made the AI slower than doing it by hand. So write for adoption: make the good, safe path also the easy path. That single principle does more for real-world compliance than any amount of enforcement.

The single highest-leverage governance asset is a shared prompt library: the prompts and templates your team has tested and trusts, in one place everyone can reach. When someone finds a prompt that reliably drafts a good FF&E schedule or summarises a code section well, it should not live in their head or their private chat history - it should become a shared, named, reusable asset.

A useful library entry is more than the prompt text. It records what task it is for, the exact prompt or template, what inputs to feed it, an example of good output, and - the part most people skip - how to check the result before it counts. That checking note is what keeps the library safe as it spreads: it travels with the prompt, so a junior using it inherits the senior's scepticism.

Library entry: "First-pass FF&E schedule"
  Use for : turning a room list into a draft schedule to edit
  Prompt  : [tested template with placeholders]
  Inputs  : room list, budget band, style notes
  Checks  : verify every product is real; prices are estimates;
            confirm quantities against the plan before issuing
  Owner   : R.M.   Last reviewed: 2026-07

As the library grows, the best prompts often graduate into custom assistants - a custom GPT or a Claude Project preloaded with your standards, tone and templates, so the whole team gets the good prompt built in (we covered building these in Module 8). Keep the library owned and dated: assign someone to prune stale entries and re-test as tools change. A library nobody curates rots into a museum of prompts that no longer work.

Every practice using AI needs a short, plain-language AI-use policy - one page, not a legal treatise. It answers the questions people actually have: which tools are approved, what you may and may not put into them, when AI output must be disclosed to a client, and who is accountable for checking it. The best policies are written for designers, not by lawyers at designers, and are revised as the field moves.

The most important section is data rules, because this is where real harm happens fastest. Anything you paste into a public AI tool may leave your control - and with consumer tiers, may be used to train future models. So the rule of thumb is blunt: never paste client-confidential information, personal data, or unpublished designs into a consumer AI tool. For sensitive work, use enterprise tiers that contractually exclude your inputs from training, or tools that run privately. Where privacy law applies - the GDPR in Europe, India's data-protection regime, and others - client personal data carries legal obligations that a careless paste can breach. When in doubt, anonymise: strip names, addresses and identifying details before the prompt, and add them back afterwards yourself.

Disclosure belongs in the policy too. Decide, as a practice, when you tell a client AI was involved - and be honest. The professional stance is that AI is a tool you used and checked, exactly as you would a plugin or a consultant's draft; hiding it erodes the trust that disclosure protects.

The hardest governance question is also the simplest to state: who is responsible for the AI output? The answer must always be a named human, never "the AI" and never "nobody in particular." Professional responsibility does not transfer to a tool. If an AI-drafted specification goes to site with an error, the practice that issued it is accountable - full stop. Governance makes sure that accountability lands somewhere deliberate rather than by accident.

A clean way to think about it is a small responsibility map that scales the checking to the stakes (the principle from Lesson 0.1). Low-stakes, divergent output - a moodboard, an idea list - can be checked by whoever uses it. Medium-stakes drafts - a proposal, a schedule - get a peer or senior review before they leave the studio. High-stakes, convergent output - anything going to a statutory authority, a contractor, or into a contract - gets sign-off from the responsible professional, who owns it as if they had written every word, because in the eyes of the client and the law, they did.

Make this explicit and it stops being scary. Everyone knows which bucket their task is in, who signs off, and that using AI never dilutes the sign-off. The checker's role is not a formality - it is the human closing the loop, and it is what lets a practice scale AI use without scaling its risk. Bring your careful, sceptical people into these checking roles; their judgement is the governance.

Pulled together, team-scale AI rests on four light pillars. A shared prompt library spreads the good workflows and carries the checks with them. A one-page AI-use policy sets the ground rules everyone knows. Data rules protect client confidentiality and stay on the right side of privacy law. And a responsibility map ensures every output has a named human who checks it, with scrutiny scaled to the stakes.

None of this needs a big budget or a dedicated department. A solo designer can hold all four in a single document; a mid-size firm might give one person the part-time role of curating the library and updating the policy. What matters is that the practice's quality and responsibility live in shared, maintained assets rather than in individual habits that vary and fade.

The payoff compounds. A well-kept prompt library makes every new hire productive faster. A clear policy means confidential data does not walk out the door. A responsibility map means the work is always defensible. Governance done lightly is not bureaucracy - it is what turns a group of people each using AI into a practice that uses AI well, consistently, and safely, as it grows.

And it should evolve. Revisit the four pillars on a set rhythm - a couple of times a year is plenty - because the tools, the risks and the law all move. New approved tools get added; retired ones removed; the data rules tightened or relaxed as enterprise options and regulations change; the library pruned and re-tested. Treat governance as a living document owned by a named person, not a stone tablet written once and forgotten. A practice whose AI rules quietly keep pace with the field is one that can keep saying yes to new capability without ever losing its grip on quality or responsibility.