21 April 2026 , Blackgate
Client-facing AI use needs clarity your team can follow under deadline - not a 40-page policy nobody reads. Governance here means: who may use which tool for which class of work, what data is forbidden in prompts or training uploads, and where a human must review before the client ever sees a deliverable or a line of code ships.
Practical AI adoption for marketing teams for culture and pilots; agentic workflows - approvals and logging for automation specifics.
Acceptable use - written in one page
The goal of this section is not to forbid tools; it is to make obvious choices on a Friday afternoon. If a junior has to “ask legal” to send a paragraph to a model, the policy is too vague. If a senior can upload a customer export without friction, the policy is too weak.
- Allow: summarising public docs, drafting from approved client briefs, internal brainstorming without raw PII in third-party UIs.
- Require review: anything client-facing, facts (numbers, law, product claims), code to production, images of people.
- Block or gate: pasting customer lists, credentials, unredacted contracts, or unapproved subprocessor flows into tools your DPA does not cover.
Publish the page where people search (wiki, Notion, intranet) and onboard every contractor.
Data boundaries: tenants, projects, and retention
- Project-based access in tools that support it - separate workspaces for Client A and B, not one shared “agency” project with a mixed retrieval pool if that crosses a line for your lawyers.
- Minimum necessary in prompts: synthetic or truncated examples for dev; anonymise in writing feedback where possible.
- Retention - delete or export client-related threads when the engagement ends if contracts say so; config in vendor admin beats a policy nobody touches.
Subprocessors and transfer
Your MSSA and SCCs should list AI vendors you rely on, or amend with legal when you adopt a new class of processing. Client DPAs may need annexes for jurisdiction and subprocessor notification - treat as change control, not a Friday afternoon checkbox.
IP: who owns model outputs when trained on client materials? State the default in your SOW: usually client owns their data, you own process and reusable non-confidential method unless agreed otherwise; clarify for co-developed playbooks.
Review steps
- Two-person or checklist review for first-time high-risk use per client; downgrade once quality is proven on a stratified sample.
- Log the version of prompts/assistants and date for repro when something goes wrong - light RACI is enough.
For search-specific risks when content is automated or AI-expanded, keep technical SEO priorities and real quality bar first - over-automation is a long-term trust problem, not only a ranking tweak.
Confidentiality in practice: treat SOW/NDA terms as controlling what may enter any model; get legal on retention and IP of outputs when the engagement ends.
Frequently asked questions
Is ChatGPT for client work “allowed”?
Only under a config and DPA your legal accepts - default consumer terms are often inadequate for B2B with regulatory data.
What about “private” enterprise ChatGPT or Azure OpenAI?
Better for enclave-style use; you still need data flow and retention mapped in your RPA pack.
Who signs off the policy?
Leadership + legal + a practising team lead; revisit quarterly as tools ship features.
Do clients need to know we use AI?
Transparency in SOWs and credits where material; hiding generative work that affects quality or facts is a reputation risk.
Start in one day?
Block the worst data types in prompts, add one review gate for outbound deliverables, and log the tool list you actually use - iterate from there.