AI Acceptable Use Policy at Work: Employer Guide
A calm, practical guide to writing an AI acceptable use policy: data classification matrices, tool tiering and approval, high-risk use cases in HR, an original policy skeleton a...
Somewhere in your company right now, someone is pasting a client email thread into a chatbot to draft a reply. A recruiter is summarising an interview. A developer is asking an assistant to explain legacy code. None of them filed a request. This is why an AI acceptable use policy has moved from a governance nicety to a basic operating requirement.
The instinct for many founders and HR leaders is a blanket ban. It rarely works. Generative AI now lives in the browser, the office suite, the CRM and the code editor. A ban does not remove AI from your workflows; it removes your visibility into it. Work migrates to personal accounts with the loosest possible data settings, and you end up with all of the risk, none of the gain, and a workforce that has learned not to tell you things.
The better approach is unglamorous. Define what good looks like, publish an approved-tool list people can find, classify your data so employees know what they may paste where, and make the compliant route faster than the workaround. This guide walks HR leaders, founders and ops teams through building that policy, with an original model template, decision matrices, a rollout plan and an incident process.
Why an AI Acceptable Use Policy Beats a Ban
The shadow AI problem
Shadow AI is shadow IT, only faster. Shadow IT took years to accumulate because someone had to buy software. Shadow AI takes ninety seconds and a personal email address. Free tiers, browser extensions and AI features quietly switched on inside SaaS you already pay for all bypass procurement entirely.
The consequences compound quietly:
- Unmanaged data egress with no deletion path. Confidential documents, salary data and customer records leave through accounts you cannot audit. If a client asks what happened to their data, "someone pasted it into a personal chatbot" is not an answer you can act on.
- Inconsistent quality. One team verifies carefully; another ships confident-sounding fabrication into a customer proposal.
- Contractual exposure. Many contracts restrict subprocessors, data location and automated processing. Employees cannot honour clauses they have never seen.
- A culture of concealment. Someone who used a prohibited tool and then spotted a leak has every incentive to stay quiet.
A ban also has a capability cost: teams that learn AI well compress research, drafting and first-pass analysis dramatically. So the through-line for everything below is one test. Does this control make the compliant option faster and clearer than the workaround? If not, it will be routed around, and you will have shadow AI plus paperwork.
Scoping Your AI Acceptable Use Policy
A workplace AI policy template usually fails at scoping. It gets written for full-time employees using one chatbot, then reality arrives with contractors, agencies and embedded copilots.
Who it covers
Include everyone who touches company data or produces work in the company's name: employees, interns, contractors, agency personnel, and vendors bound through contract rather than policy. Include founders and executives explicitly — senior exemption is a common failure point. Personal devices and accounts used for work belong in scope, because that is where shadow AI lives.
What counts as an AI tool
Employees interpret "AI tool" narrowly unless you define it broadly. Name each category in the definitions clause: standalone chatbots, AI features embedded in software you already license, specialist vertical tools for transcription or resume parsing, agentic tools that take actions on your behalf, browser extensions, self-hosted models, and consumer AI on personal devices.
Two categories are consistently underestimated. Browser extensions get broad page-level access and should be prohibited by default unless centrally deployed. Meeting recorders capture candid discussion, third-party voices and sometimes personal data, and a participant can introduce one without your knowledge — say plainly whether they are permitted, who may enable them, and what notice participants get.
Foundational Principle 1: Data Classification
The highest-value component of any AI acceptable use policy is a data classification scheme mapped to tool tiers. Employees do not need to understand model architecture. They need to know: given this information, which tool may I put it into?
| Data class | Examples | Public/free AI | Approved enterprise AI | Restricted tier (DPA, logged) |
|---|---|---|---|---|
| Public | Published copy, public pricing, job adverts | Permitted | Permitted | Permitted |
| Internal | Process notes, agendas, draft plans | No | Permitted | Permitted |
| Confidential – business | Roadmap, financial models, board material | No | With approval for the stated use | Permitted |
| Personal data | Employee and candidate details, payroll data | No | Only if purpose-approved and minimised | With DPA and purpose limitation |
| Sensitive personal data | Health, biometric, financial, disciplinary records | No | No | Only with documented approval and extra controls |
| Client-restricted | Data covered by contractual processing limits | No | Only after checking the contract | Only where the contract allows |
| Regulated / sectoral | Data under sector-specific supervision | No | No | Only under a documented assessment |
| Secrets | API keys, passwords, tokens, security configs | Never | Never | Never |
Three things make the matrix work. Minimise before you prompt — strip names and identifiers first. Explain the why once: inputs to consumer tools may be retained or used to improve models, and your obligations include purpose limitation and deletion. Put it where the work happens — a one-pager pinned in your chat tool gets consulted; a PDF in a shared drive does not.
The regulatory backdrop, in general terms
India's data protection framework, like comparable regimes elsewhere, creates obligations that shape AI use without mentioning AI: process personal data for specified purposes, collect no more than needed, rely on consent or another valid basis, keep data secure, respond to individual requests, and report certain breaches. Sectoral regulators add expectations around localisation and third-party risk, and global AI governance frameworks are converging on themes rather than identical rules — transparency, human oversight, risk assessment, documentation. Design controls that satisfy those principles, then have counsel confirm the specifics.
Foundational Principle 2: Human Accountability
The second principle is short to state and hard to embed: the person who submits, sends or publishes AI-assisted work owns it completely. "The model said so" is not a defence — nobody accepts "the intern drafted it" as an excuse for an inaccurate deliverable either. Review obligations should scale with consequence, not with how impressive the output looks.
| Risk level | Typical outputs | Required review | Documentation |
|---|---|---|---|
| Low | Brainstorming, outlines, rephrasing your own text | Skim for obvious errors | None |
| Moderate | Team documents, routine customer email, marketing copy, job descriptions | Full read and factual check by the author | Author on record as owner |
| Elevated | Proposals, published content, financial analysis, production code | Verify every claim, figure and citation; peer review | Note AI assistance in the internal record |
| High | Anything affecting employment, pay or access; legal and tax positions | Independent human decision-maker reviewing underlying evidence, not the AI summary | Documented rationale, reviewer identity, retained record |
Three habits prevent most failures. Never trust a citation you have not opened. Never trust a number you cannot reproduce. And treat generated code exactly like human-written code, with extra attention to suggested dependencies.
Foundational Principle 3: AI Disclosure Rules
Disclosure confuses people because the sensible answer varies by context. Nobody expects a notice because you used spellcheck; everybody expects to know if a "personalised" note was generated at scale. The workable rule: disclose when a reasonable person would change how they weigh the output if they knew AI produced it.
| Situation | Disclose? | Practice |
|---|---|---|
| AI rephrased your own writing | No | Treat as an editing tool |
| AI drafted an internal document you edited and verified | Usually no | Disclose if colleagues will rely on it as research |
| AI produced research or analysis others will act on | Yes, internally | Note the tool and what you verified |
| AI-generated images, audio or video in published material | Yes | Visible label per your brand standard |
| Client deliverable with substantial AI assistance | Check the contract, then disclose | Some contracts require prior written consent |
| AI use in candidate or employee evaluation | Yes | Include in the candidate or employee notice |
| Synthetic voice or likeness of a real person | Always, with written consent | Never simulate a colleague or customer |
| Performance feedback drafted with AI help | Yes if asked; manager remains the author | Manager must defend every line unaided |
Two rules sit alongside this. Never present AI output as another person's words. And be honest with candidates and employees: if AI is part of screening or assessment, say so. Silence erodes trust far more than the AI use itself.
Tool Governance and the AI Tool Approval Process
Employees need to know, without asking anyone, whether a tool is allowed. That requires a published catalogue and a tiering model.
| Tier | Definition | Who may use it | Data permitted | Approval |
|---|---|---|---|---|
| 1 – Approved | Contracted enterprise tools, inputs excluded from training, admin controls and logging | All staff | Per the data matrix | None needed |
| 2 – Approved with conditions | Cleared for specific teams, purposes or data types | Named teams or roles | As stated in the approval record | Manager confirms scope |
| 3 – Requires review | Unassessed, or assessed and pending conditions | Nobody yet | None | Full intake request |
| 4 – Prohibited | Rejected, or categorically excluded (unmanaged extensions, no usable DPA) | Nobody | None | Written executive and legal sign-off |
Publish the catalogue where people already look, listing for each tool what it is good for, what data class it accepts, who owns it, and how to get access. A catalogue three months behind reality is a shadow AI generator.
The intake and review process
- Request. Tool, vendor, business problem, expected users, data classes involved, and the alternative the requester would otherwise use.
- Triage within two working days. Check whether an approved tool already covers the need. Many requests end here, satisfied.
- Security and privacy review for anything above internal data: terms, data handling, access controls.
- Legal check. Does a client contract restrict this? Is an acceptable DPA available? Where is data processed?
- Decide. Approve, approve with conditions, or decline with a reason and an alternative. Unexplained declines drive workarounds faster than anything else.
- Catalogue and enable. Add the entry, provision through single sign-on, name an owner, set a review date.
- Offboard cleanly when a tool is retired: revoke access, export what you need, request deletion, and tell users what to use instead. Removing a tool without naming a replacement pushes the work into personal accounts.
Vendor diligence questions
- Are our inputs used to train the vendor's models, and can that be excluded contractually rather than by a settings toggle?
- What is the retention period for prompts, outputs and logs, and can we delete and export our data after termination?
- Where is data processed and stored, and which subprocessors are involved?
- Does the tool support single sign-on, role-based access and audit logs, and is an acceptable DPA available?
- For agentic tools: what actions can it take, under whose credentials, logged where?
High-Risk Use Cases That Need Extra Controls
Most AI use is low-stakes and needs nothing beyond the general rules. A minority carries enough consequence to justify specific controls. A short use-case risk register makes this concrete and gives you something to review quarterly.
| Use case | Primary risks | Required controls | Owner |
|---|---|---|---|
| Resume screening | Bias, opacity, adverse candidate effect | Human decision-maker, documented criteria, outcome review, candidate notice | Talent lead |
| Interview summarisation | Misattribution, recording consent, sensitive disclosures | Consent, human verification, restricted access, defined retention | Talent lead |
| Performance review drafting | Generic or unfair content, manager abdication | Manager authors every statement; evidence-based inputs; no model scoring | HR business partner |
| Attrition prediction | Self-fulfilling outcomes, proxy discrimination | Aggregate use only; no individual adverse action | People analytics |
| Employee monitoring | Privacy intrusion, morale, legal exposure | Default avoid; if used, transparency and proportionality | HR + Legal |
| Disciplinary matters | Fairness, natural justice, record integrity | Formatting help only; never evidence analysis or recommended outcomes | HR + Legal |
| Legal, tax and financial outputs | Confident inaccuracy, calculation errors, reliance risk | Qualified human review; every figure reproduced and source-linked | Finance / Legal |
| Code generation | Licence contamination, insecure patterns, phantom dependencies | Standard review, dependency verification, security scanning | Engineering lead |
| Customer-facing content | Brand and factual risk, third-party IP | Human review before publication, IP check on generated media | Marketing lead |
| Client-restricted data | Contract breach, subprocessor violation | Contract check first; written client consent where required | Account owner + Legal |
AI in Performance Management and Hiring
AI in HR deserves separate treatment: the stakes are personal and the data is sensitive. What follows is good practice, not a claim about what any specific law requires.
Resume screening
Used carelessly, AI screening reproduces whatever patterns sit in the data it was tuned on, at scale. Used carefully, it reduces the inconsistency of human first-pass review.
- Define the criteria yourself, in writing, before the tool runs. Do not let a model infer "good candidate" from your hiring history, which encodes that history's biases.
- Use AI to surface and organise, not to reject; keep a named human accountable for every rejection from shortlisting onward.
- Review outcomes periodically for unexplained skew across gender, age, location or institution type.
- Tell candidates in the privacy notice that AI-assisted tools are used, with a route to request human review, and retain the criteria, tool version, outputs and rationale.
Interview summarisation
The most useful AI application in recruitment, and the one most likely to create a quiet consent problem. Get advance notice and consent from every participant including the candidate. Treat the summary as a draft the interviewer verifies against their own notes, restrict access to the panel, and set a retention period you honour. Never let a summary replace the structured scorecard.
Performance review drafting
The risk is not that AI writes badly. It is that AI writes fluently about things the manager has not observed.
- The manager supplies the evidence — examples, results, feedback — and AI helps with structure. Never the reverse.
- No ratings, scores or rankings generated or recommended by a model.
- The manager must defend every sentence in conversation, without notes.
- Never paste health information, disciplinary history or grievance details into any AI tool.
Attrition prediction
Predictive people analytics sits at the outer edge of what most SMBs should attempt. If you do it: use it for systemic insight, not individual labelling; never take adverse action based on a prediction; watch for proxies such as location or education standing in for protected characteristics; and be transparent that the analysis exists.
Control checklist for AI in people decisions
- A named human makes the decision and can explain it in their own words.
- Criteria are documented and were set before the tool was applied.
- Outcomes are reviewed periodically for unexplained disparity.
- Candidates or employees have clear notice.
- There is a route to question the outcome or request human review.
- Records are retained: inputs, criteria, tool version, output, decision, rationale.
- Data is minimised, purpose-limited and covered by a vendor agreement.
If you cannot tick all seven, the tool is not ready for that use yet.
IP, Confidentiality and Client Obligations
Training on your data. The most important setting in any AI deployment is whether your inputs feed model improvement. Consumer tiers often default to yes; enterprise tiers often default to no. Get it in the contract, not a screenshot of a settings page.
Confidentiality flows through. If an NDA restricts disclosure to third parties, pasting protected information into a third-party AI service is, on a plain reading, a disclosure to a third party. The same logic applies to client contracts with subprocessor lists, sectoral outsourcing rules and open-source licences.
Ownership and third-party risk. Ownership of purely machine-generated material is unsettled in many jurisdictions; most organisations treat AI-assisted employee work as belonging to the company under the standard IP assignment, with counsel confirming the wording. Generated content can also resemble existing protected material, so run similarity checks on visuals before publication and check generated code for licence-encumbered snippets.
An Original Workplace AI Policy Template
What follows is an original model skeleton written for this guide. It is a starting point, not a finished policy, and not legal advice. Adapt it to your size, sector and jurisdiction, and have counsel review it before adoption.
1. Purpose and scope
This policy governs the use of artificial intelligence tools at [Company]. It applies to employees, interns, contractors and agency personnel using [Company] data, systems or devices, including on personal accounts; where it conflicts with a client contract or stricter internal standard, the stricter requirement applies.
2. Definitions
"AI tool" means any software that generates, summarises, classifies, predicts, recommends or acts using machine learning or generative models, including embedded AI features, browser extensions, transcription tools and agentic assistants. "Approved tool" means a tool listed in the [Company] AI Tool Catalogue, at the tier and for the purposes stated there.
3. Approved tools
Use only tools listed in the AI Tool Catalogue, within the data limits stated for each. Unlisted tools must not be used with [Company] or client information; submit the AI Tool Request form for a response within [X] working days. Personal AI accounts must not be used for [Company] work.
4. Data handling
Before entering information into an AI tool, identify its classification and check the AI Data Permitted-Use Matrix. Never enter credentials, security configurations, sensitive personal data or contractually restricted client data. Minimise first, and ask [role] if you are unsure of a classification.
5. Human accountability
You are fully responsible for any work you produce, submit or publish, whether or not AI assisted you. AI output is a draft, reviewed in proportion to its consequences, and you must verify every claim, figure and calculation you rely on. Attributing an error to an AI tool does not reduce your responsibility.
6. Disclosure
Disclose AI involvement whenever a reasonable person would weigh the output differently knowing it was AI-generated: research colleagues will rely on, generated media in published material, client deliverables where the contract requires notice, and AI use in evaluation. Never present AI output as another person's words, or create a synthetic likeness without written consent.
7. Intellectual property and confidentiality
Your confidentiality obligations apply in full to AI tools, and entering confidential or third-party information into an unapproved tool may constitute unauthorised disclosure. All work you create with AI assistance during your engagement belongs to [Company] under your existing agreement. Take reasonable care that AI-generated material does not infringe third-party rights.
8. Client and contractual obligations
Some clients restrict how their data may be processed, where it is stored and which third parties may be involved. Before using any AI tool with client data, confirm with the account owner or Legal that no restriction applies, and obtain written consent where required. If uncertain, do not proceed.
9. Prohibited uses
You must not use AI tools to process data in breach of the Permitted-Use Matrix; decide any individual's employment, pay or access without human review; generate discriminatory, harassing, deceptive or unlawful content; impersonate any person or organisation; circumvent security or licensing controls; or monitor colleagues without authorisation. The standard is that AI use must be lawful, honest and consistent with our values.
10. AI in hiring and people decisions
AI tools may support recruitment and performance processes but must never be the decision-maker; a named human must make and explain every decision affecting a candidate or employee. Candidates and employees will receive clear notice where AI-assisted tools are used in evaluation, with a route to request human review. Tools in scope will be reviewed periodically for unexplained disparity.
11. Security
Access approved AI tools only through [Company]-provisioned accounts and single sign-on, and do not install AI extensions, plug-ins or desktop agents without IT approval. Agentic tools that act on systems or data require explicit authorisation, scoped credentials and activity logging. Treat AI outputs containing links or code as untrusted content.
12. Incident reporting
Report suspected AI-related incidents to [security contact] as soon as you become aware of them, and no later than [X] hours. Reportable incidents include restricted data entered into an unapproved tool, inaccurate AI content published externally, unauthorised access to an AI account, and potential exposure of personal or client data. Prompt, good-faith reporting will not itself result in disciplinary action; concealing an incident may.
13. Training
All personnel must complete AI acceptable use training during onboarding and refresher training at least annually or when this policy changes materially. Teams in higher-risk areas — recruitment, people operations, finance, legal, engineering and customer communications — must complete role-specific training first. Completion is tracked and forms part of our compliance record.
14. Enforcement
Most breaches will be handled through guidance, coaching and correction. Serious or deliberate breaches — knowingly exposing client or personal data, concealing an incident, or using AI to deceive — may be treated as misconduct under the disciplinary procedure. Managers are responsible for ensuring their teams understand this policy.
15. Review
This policy will be reviewed at least quarterly by [owner], with input from IT, Legal, HR and function leads, and updated as tools, risks and obligations change. Tool approvals expire and must be renewed on the schedule in the catalogue. Material changes will be communicated and re-acknowledgement requested.
16. Acknowledgement
I confirm that I have read and understood the [Company] AI Acceptable Use Policy, that I will use AI tools only as permitted by it, and that I will report incidents promptly. I understand that this policy forms part of my obligations to [Company].
Rolling Out the Policy: A 30-60-90 Plan
Days 1–30: find out what is actually happening. Run a short, amnesty-framed survey asking what AI tools people already use and why — frame it well or you will get useless answers. Pull technical signals: SSO logs, expense claims, extension inventories. Identify the top five to ten real use cases, draft the data matrix, and contract one or two Tier 1 tools.
Days 31–60: publish, train, enable. Finalise the policy with counsel review, publish the catalogue and the one-page matrix, and provision approved tools broadly — availability is your primary defence against shadow AI. Run role-based training rather than one generic all-hands, and brief managers before launch so they can answer questions rather than deflect them.
Days 61–90: embed and iterate. Run the intake process on real requests and publish turnaround times. Build the risk register with function owners, set up the incident register, and test the reporting route with a tabletop exercise. Add acknowledgement and training to onboarding, and report adoption and incidents to leadership.
| Activity | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
| Policy drafting | HR / People Ops | Founder or COO | Legal, IT, function leads | All staff |
| Data classification matrix | IT / Security | IT lead | Legal, HR, Finance | Managers |
| Tool selection and contracting | IT / Procurement | COO or CFO | Legal, requesting teams | All staff |
| Vendor and privacy review | Legal / Security | Legal owner | IT, data protection contact | Requesters |
| Training design and delivery | L&D / HR | HR lead | Function leads, IT | All staff |
| Acknowledgement tracking | HR Ops | HR lead | — | Managers |
| Catalogue upkeep | IT | IT lead | Function owners | All staff |
| Incident response | Security | Security owner | HR, Legal, comms | Leadership |
| Quarterly review | Policy owner | Founder or COO | All above | All staff |
AI Training for Employees That Actually Works
A single compliance module explaining what not to do produces employees who are cautious and unskilled. You want employees who are skilled and appropriately cautious, which means teaching capability alongside constraint.
| Role | Highest-value uses | Watch-outs |
|---|---|---|
| Recruiters | Job descriptions, outreach, structured questions, note summarisation | Candidate personal data, recording consent, screening bias |
| HR and People Ops | Policy drafting, FAQs, comms, survey analysis | Employee personal data, health and disciplinary information |
| Managers | Feedback structuring, meeting summaries, planning | Performance claims without evidence |
| Sales | Proposal drafts, research, call summaries | Client-restricted data, contract terms, overstated commitments |
| Marketing | Content drafts, campaign variants, repurposing | Third-party IP, brand accuracy, disclosure on generated media |
| Finance | Analysis structuring, variance narratives | Unverified numbers, confidential financials |
| Engineering | Code assistance, tests, documentation, debugging | Secrets in prompts, licence risk, phantom dependencies |
| Support | Response drafting, knowledge articles, ticket summaries | Wrong advice at scale, customer personal data |
| Leadership | Research, drafting, scenario thinking | Board-confidential material; same rules, applied visibly |
What "verify before you ship" means in practice
- Read the whole output. Fluency masks error.
- Recompute every number independently.
- Open every source. If it does not say what was claimed, remove it.
- Ask what is missing. Models rarely flag the consideration they omitted.
- Rewrite in your own voice. This catches anything you cannot defend.
- Apply the newspaper test: would you be comfortable if this output, and the fact AI produced it, were visible to your client or the person it concerns?
Name two or three internal champions per function and give them protected time. They answer questions faster than any formal process, surface real use cases for tool selection, and model good practice visibly.
AI Incidents: Reporting, Triage and Learning
Define an incident broadly — restricted data entered into an unapproved tool, inaccurate AI content sent externally, unauthorised access to an AI account, an agentic tool taking an unintended action, a vendor breach notification — and say plainly that reporting is expected and safe.
The response sequence: report through a genuinely easy route; triage to establish what data, whose, which tool and how long; contain by revoking access, requesting deletion and rotating credentials; assess obligations with Legal for client, individual or regulatory notification; remediate the underlying gap; and learn by recording the incident and sharing the anonymised lesson.
| Register field | Purpose |
|---|---|
| Incident ID, date, reporter and route | Traceability, and shows which channels work |
| Tool and tier | Identifies catalogue gaps |
| Data classes and individuals affected | Drives obligation and notification decisions |
| Description and containment actions | Evidence of response |
| Notification required and completed | Compliance record |
| Root cause | Policy, training, tool or deliberate breach |
| Corrective action, owner and closure date | Closes the loop |
Most entries in a healthy register will be small and caused by ambiguity rather than bad intent. A register with no entries usually means people are not reporting.
Enforcement That Is Proportionate
Punitive-only enforcement produces silence, and silence is more dangerous than most underlying incidents. Calibrate to intent and consequence.
- Genuine mistake, promptly reported, limited impact. Coaching, and a check on whether the policy or catalogue caused the confusion.
- Repeated carelessness. A documented conversation with the manager, targeted retraining, closer review of output for a period.
- Deliberate breach without serious harm. Formal warning, consistent with comparable policy breaches.
- Serious deliberate breach. Knowingly exposing client or personal data, using AI to deceive, or concealing an incident — handled as misconduct with full due process.
Say explicitly that good-faith reporting will not itself attract discipline, then honour that the first time someone tests it. And if many people breach the same rule, the rule is the problem — investigate the policy before the people.
Keeping Responsible AI at Work Alive
AI tooling changes faster than any software category most companies have handled. A policy on an annual cycle will be materially out of date within two quarters.
| Cadence | Activity | Owner |
|---|---|---|
| Continuous | Tool requests triaged; catalogue updated | IT / policy owner |
| Monthly | Incident review, shadow AI signals, adoption check | Security + HR |
| Quarterly | Policy review, risk register refresh, tool re-approvals | Policy owner + Legal |
| Half-yearly | Outcome review for HR-related AI uses; training refresh | HR + function owners |
| Annually | Full training cycle and re-acknowledgement; contract review | HR + Legal |
| Event-driven | Vendor change, new client restriction, incident with policy root cause | Policy owner |
Two habits help. Sunset clauses: every tool approval carries an expiry date, so the catalogue self-cleans. Versioning: number your policy versions, keep a changelog, and re-collect acknowledgement when changes are material.
Common Mistakes and a Readiness Checklist
- Writing the policy before understanding actual usage. You will regulate imaginary problems and miss real ones.
- Approving tools nobody wanted. If the approved tool does not do the job, people find one that does.
- Slow, opaque approval. A four-week queue with no status visibility is a shadow AI engine.
- Legal language nobody reads. If a new joiner cannot summarise your rules in two sentences, the policy has failed.
- Exempting leadership. Visible senior compliance outweighs any amount of written emphasis.
- Ignoring embedded AI, and having no named owner. Features switched on inside existing SaaS are the largest unexamined surface, and a policy owned by "leadership" is owned by nobody.
Work through this checklist before calling the programme live:
- You know roughly what AI tools are in use today.
- Data classes are mapped to tool tiers in a one-page matrix.
- At least one contracted Tier 1 tool is available to everyone who needs it.
- A published catalogue exists, with a named intake owner and a stated turnaround.
- Human accountability, review standards and disclosure rules are written down.
- High-risk use cases are listed with owners and controls.
- HR uses meet all seven items on the people-decisions checklist.
- Client contract restrictions have been checked for major accounts.
- Counsel has reviewed the policy for your jurisdiction and sector.
- Role-based training is built, scheduled and tracked.
- The incident route is published and has been tested once.
- A quarterly review sits in the calendar with a named owner.
Disclaimer
This article and the model clauses within it are general guidance and a drafting starting point. They are not legal advice and do not account for your jurisdiction, sector, client contracts or specific tools. Data protection, employment and sectoral requirements differ across markets and continue to evolve, as do wider AI governance expectations. Have qualified counsel review any policy before you adopt, publish or enforce it.
Frequently Asked Questions
Do small companies really need a formal AI acceptable use policy?
Yes, though proportionate. A twenty-person startup does not need a governance committee, but it does need three things written down: which tools are approved, what data must never go into them, and who owns the output. Two pages is enough. Do it early — retrofitting discipline onto a team that spent a year pasting client data into personal accounts is far harder.
What is shadow AI, and how do we measure it?
Shadow AI is any use of AI tools outside your approved, visible set — personal accounts, free tiers, extensions and AI features quietly enabled inside existing software. Find it by combining an amnesty-framed anonymous survey with technical signals such as SSO logs and expense reimbursements. The survey usually reveals more, provided people believe there will be no consequences.
Can employees use free AI tools for work?
For genuinely public information, often yes. For anything internal, confidential or personal, generally no. The issue is terms rather than quality: free tiers may retain inputs longer, may use them for model improvement, and typically come with no data processing agreement, admin visibility or deletion commitment. The fix is one contracted enterprise tool available to everyone.
How do we use AI in hiring without creating risk?
Keep the human decision-maker visibly in charge, document criteria before applying any tool, give candidates clear notice and a route to request human review, check outcomes periodically for unexplained disparity, and retain records of criteria, outputs and rationale. Use AI to organise and surface rather than to reject, and confirm jurisdiction-specific requirements with counsel.
What do we do when someone pastes confidential data into an unapproved tool?
Treat it as an incident, not a scandal. Establish what data, whose, which tool and how long ago, then contain it: change account settings, request deletion, revoke access, rotate exposed credentials. Assess with Legal whether notification is required, then examine the root cause — usually a missing tool or absent training rather than misconduct — and fix that. Respond to good-faith reports with coaching, or you will not get the next one.
Should employees disclose AI use in everyday work?
Not for everything. Requiring disclosure for routine rephrasing makes the rule feel bureaucratic and trains people to ignore it. Apply the reasonable-person test: disclose when knowing AI was involved would change how someone weighs the output. That covers AI-generated research others will act on, generated media in published material, client deliverables where the contract requires it, and AI involvement in evaluation.
How often should we update the policy?
Review quarterly, with an annual deep review covering training refresh and re-acknowledgement. Also trigger reviews on specific events: a vendor changing its data terms, a new client contract with AI restrictions, an incident whose root cause was a policy gap, or new regulatory guidance. Build expiry dates into tool approvals so the catalogue refreshes itself.
Conclusion
An AI acceptable use policy is not really a document about artificial intelligence. It is a document about data, judgement and accountability — three things your organisation already has views on. AI simply changes the speed and the surface area.
The organisations handling this well do not have the longest policies. They made the safe path the easy path: a classification matrix people can hold in their heads, one good tool available to everyone from day one, honest disclosure rules, a named human accountable for every consequential output, and a reporting culture where mistakes surface early enough to fix cheaply.
Once the policy is written, the work is distribution, acknowledgement and evidence — which is where an HRMS earns its place. CozyHR helps you publish the policy to every employee and contractor, collect timestamped acknowledgements, track AI training completion, and keep version history so you can show which version each person accepted and when. If you are rolling out an AI policy this quarter, explore CozyHR and see how much of the administration you can hand to the system.
