CozyHR
Menu
Products
Docs
Resources
Compliance
Company
Support
Blog
HR PoliciesAI in HRHR TechEmployee Data Privacy

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...

CozyHR editorial team 30 July 2026 28 min read
CozyHR Blog
AI Acceptable Use Policy at Work: Employer Guide

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 classExamplesPublic/free AIApproved enterprise AIRestricted tier (DPA, logged)
PublicPublished copy, public pricing, job advertsPermittedPermittedPermitted
InternalProcess notes, agendas, draft plansNoPermittedPermitted
Confidential – businessRoadmap, financial models, board materialNoWith approval for the stated usePermitted
Personal dataEmployee and candidate details, payroll dataNoOnly if purpose-approved and minimisedWith DPA and purpose limitation
Sensitive personal dataHealth, biometric, financial, disciplinary recordsNoNoOnly with documented approval and extra controls
Client-restrictedData covered by contractual processing limitsNoOnly after checking the contractOnly where the contract allows
Regulated / sectoralData under sector-specific supervisionNoNoOnly under a documented assessment
SecretsAPI keys, passwords, tokens, security configsNeverNeverNever

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 levelTypical outputsRequired reviewDocumentation
LowBrainstorming, outlines, rephrasing your own textSkim for obvious errorsNone
ModerateTeam documents, routine customer email, marketing copy, job descriptionsFull read and factual check by the authorAuthor on record as owner
ElevatedProposals, published content, financial analysis, production codeVerify every claim, figure and citation; peer reviewNote AI assistance in the internal record
HighAnything affecting employment, pay or access; legal and tax positionsIndependent human decision-maker reviewing underlying evidence, not the AI summaryDocumented 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.

SituationDisclose?Practice
AI rephrased your own writingNoTreat as an editing tool
AI drafted an internal document you edited and verifiedUsually noDisclose if colleagues will rely on it as research
AI produced research or analysis others will act onYes, internallyNote the tool and what you verified
AI-generated images, audio or video in published materialYesVisible label per your brand standard
Client deliverable with substantial AI assistanceCheck the contract, then discloseSome contracts require prior written consent
AI use in candidate or employee evaluationYesInclude in the candidate or employee notice
Synthetic voice or likeness of a real personAlways, with written consentNever simulate a colleague or customer
Performance feedback drafted with AI helpYes if asked; manager remains the authorManager 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.

TierDefinitionWho may use itData permittedApproval
1 – ApprovedContracted enterprise tools, inputs excluded from training, admin controls and loggingAll staffPer the data matrixNone needed
2 – Approved with conditionsCleared for specific teams, purposes or data typesNamed teams or rolesAs stated in the approval recordManager confirms scope
3 – Requires reviewUnassessed, or assessed and pending conditionsNobody yetNoneFull intake request
4 – ProhibitedRejected, or categorically excluded (unmanaged extensions, no usable DPA)NobodyNoneWritten 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

  1. Request. Tool, vendor, business problem, expected users, data classes involved, and the alternative the requester would otherwise use.
  2. Triage within two working days. Check whether an approved tool already covers the need. Many requests end here, satisfied.
  3. Security and privacy review for anything above internal data: terms, data handling, access controls.
  4. Legal check. Does a client contract restrict this? Is an acceptable DPA available? Where is data processed?
  5. Decide. Approve, approve with conditions, or decline with a reason and an alternative. Unexplained declines drive workarounds faster than anything else.
  6. Catalogue and enable. Add the entry, provision through single sign-on, name an owner, set a review date.
  7. 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 casePrimary risksRequired controlsOwner
Resume screeningBias, opacity, adverse candidate effectHuman decision-maker, documented criteria, outcome review, candidate noticeTalent lead
Interview summarisationMisattribution, recording consent, sensitive disclosuresConsent, human verification, restricted access, defined retentionTalent lead
Performance review draftingGeneric or unfair content, manager abdicationManager authors every statement; evidence-based inputs; no model scoringHR business partner
Attrition predictionSelf-fulfilling outcomes, proxy discriminationAggregate use only; no individual adverse actionPeople analytics
Employee monitoringPrivacy intrusion, morale, legal exposureDefault avoid; if used, transparency and proportionalityHR + Legal
Disciplinary mattersFairness, natural justice, record integrityFormatting help only; never evidence analysis or recommended outcomesHR + Legal
Legal, tax and financial outputsConfident inaccuracy, calculation errors, reliance riskQualified human review; every figure reproduced and source-linkedFinance / Legal
Code generationLicence contamination, insecure patterns, phantom dependenciesStandard review, dependency verification, security scanningEngineering lead
Customer-facing contentBrand and factual risk, third-party IPHuman review before publication, IP check on generated mediaMarketing lead
Client-restricted dataContract breach, subprocessor violationContract check first; written client consent where requiredAccount 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

  1. A named human makes the decision and can explain it in their own words.
  2. Criteria are documented and were set before the tool was applied.
  3. Outcomes are reviewed periodically for unexplained disparity.
  4. Candidates or employees have clear notice.
  5. There is a route to question the outcome or request human review.
  6. Records are retained: inputs, criteria, tool version, output, decision, rationale.
  7. 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.

ActivityResponsibleAccountableConsultedInformed
Policy draftingHR / People OpsFounder or COOLegal, IT, function leadsAll staff
Data classification matrixIT / SecurityIT leadLegal, HR, FinanceManagers
Tool selection and contractingIT / ProcurementCOO or CFOLegal, requesting teamsAll staff
Vendor and privacy reviewLegal / SecurityLegal ownerIT, data protection contactRequesters
Training design and deliveryL&D / HRHR leadFunction leads, ITAll staff
Acknowledgement trackingHR OpsHR leadManagers
Catalogue upkeepITIT leadFunction ownersAll staff
Incident responseSecuritySecurity ownerHR, Legal, commsLeadership
Quarterly reviewPolicy ownerFounder or COOAll aboveAll 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.

RoleHighest-value usesWatch-outs
RecruitersJob descriptions, outreach, structured questions, note summarisationCandidate personal data, recording consent, screening bias
HR and People OpsPolicy drafting, FAQs, comms, survey analysisEmployee personal data, health and disciplinary information
ManagersFeedback structuring, meeting summaries, planningPerformance claims without evidence
SalesProposal drafts, research, call summariesClient-restricted data, contract terms, overstated commitments
MarketingContent drafts, campaign variants, repurposingThird-party IP, brand accuracy, disclosure on generated media
FinanceAnalysis structuring, variance narrativesUnverified numbers, confidential financials
EngineeringCode assistance, tests, documentation, debuggingSecrets in prompts, licence risk, phantom dependencies
SupportResponse drafting, knowledge articles, ticket summariesWrong advice at scale, customer personal data
LeadershipResearch, drafting, scenario thinkingBoard-confidential material; same rules, applied visibly

What "verify before you ship" means in practice

  1. Read the whole output. Fluency masks error.
  2. Recompute every number independently.
  3. Open every source. If it does not say what was claimed, remove it.
  4. Ask what is missing. Models rarely flag the consideration they omitted.
  5. Rewrite in your own voice. This catches anything you cannot defend.
  6. 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 fieldPurpose
Incident ID, date, reporter and routeTraceability, and shows which channels work
Tool and tierIdentifies catalogue gaps
Data classes and individuals affectedDrives obligation and notification decisions
Description and containment actionsEvidence of response
Notification required and completedCompliance record
Root causePolicy, training, tool or deliberate breach
Corrective action, owner and closure dateCloses 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.

CadenceActivityOwner
ContinuousTool requests triaged; catalogue updatedIT / policy owner
MonthlyIncident review, shadow AI signals, adoption checkSecurity + HR
QuarterlyPolicy review, risk register refresh, tool re-approvalsPolicy owner + Legal
Half-yearlyOutcome review for HR-related AI uses; training refreshHR + function owners
AnnuallyFull training cycle and re-acknowledgement; contract reviewHR + Legal
Event-drivenVendor change, new client restriction, incident with policy root causePolicy 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:

  1. You know roughly what AI tools are in use today.
  2. Data classes are mapped to tool tiers in a one-page matrix.
  3. At least one contracted Tier 1 tool is available to everyone who needs it.
  4. A published catalogue exists, with a named intake owner and a stated turnaround.
  5. Human accountability, review standards and disclosure rules are written down.
  6. High-risk use cases are listed with owners and controls.
  7. HR uses meet all seven items on the people-decisions checklist.
  8. Client contract restrictions have been checked for major accounts.
  9. Counsel has reviewed the policy for your jurisdiction and sector.
  10. Role-based training is built, scheduled and tracked.
  11. The incident route is published and has been tested once.
  12. 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.