Generative AI Policy

A sales team may use a chatbot to outline a proposal, while a payroll employee may be tempted to paste salary records into the same tool, and those are different risks. A useful policy lets people distinguish approved assistance from prohibited disclosure.

NIST's Generative AI Profile gives organisations a risk-management framework rather than a universal one-page policy, and the UK Information Commissioner's Office explains data-protection considerations for AI; its UK legal guidance is an example of jurisdiction-specific requirements, not a global rule for every business. Start with a list of permitted tools and account types, because personal accounts and company-controlled versions may have different terms and settings.

Name permitted tasks, such as brainstorming or summarising non-confidential material, and the uses that need extra review. Classify information before staff enter it into a tool, since public marketing text and confidential customer records must not be treated alike, and remember that a vendor promise about privacy does not replace review of its contract, retention settings, subprocessors and available controls.

Personal data needs attention to applicable law and company obligations, and the exact legal requirements depend on where the business operates and whose information it handles. Explain whether staff may upload customer, employee, financial, legal or unpublished product information, specify who can turn on integrations that connect tools to drives, email or customer systems, and define retention and deletion expectations where settings and contracts permit.

Require human review of material outputs, because fluent text may contain invented citations, inaccurate figures or claims unsupported by source records. For code, check security, licensing, tests and maintainability; for images and copy, review intellectual-property, consent, brand and contractual restrictions before external use.

Say when AI assistance must be disclosed to a customer, manager or reviewer, and keep accountability with the person and team that approve the final work, since a tool is not an authorised signer or a substitute for professional judgment. Set approval paths for high-stakes uses, such as employment decisions, medical content, financial advice or legal communications, and describe how staff verify factual claims: check original documents, current figures and named sources instead of citing a chatbot answer.

Set limits for automated publication or messages, because drafting assistance and sending unreviewed content are different permissions, and cover meetings and recordings so staff know when transcription or summarisation tools are allowed and when consent or notice may be required. Record incidents through the existing security and privacy process, because a mistaken upload should be reported promptly, not hidden because the employee fears blame.

Train staff on real examples, since a policy that no one understands tends to drive unapproved use underground. Assign an owner to approve tools and revise the policy because models, products and contractual terms change, and review logs or samples only where lawful and proportionate, explaining monitoring clearly rather than assuming employees expect it.

A blanket ban can be appropriate for a narrow sensitive workflow but may fail as a substitute for workable rules across the company, so measure adoption and incidents, not just signatures. For a small firm, a short table of approved tools, banned data, review duties and an escalation contact may be more usable than a long manual, while a larger organisation may need team-specific annexes with one common data and approval standard; when a use is unclear, pause the sensitive input or external release and ask the designated owner.