Writing a company AI usage policy

A company AI usage policy tells staff which AI tools they may use, what information they may put into them, which kinds of output a person must check before use, and who to ask when unsure. A useful policy fits on two or three pages, names the approved tools and data categories in plain words, and is reviewed every few months as tools and laws change.

This guide offers a structure to adapt. It is not legal advice; have your counsel review the final text.

Why you need one now

Your staff are already using AI tools. An accountant pastes a client's ledger into a public chat assistant to find a mismatch. A sales executive uploads a customer's purchase order to draft a reply. An HR executive asks a tool to summarise a disciplinary note. Each of these may be useful, and each may also send confidential or personal data to a service your company has no agreement with.

Banning AI outright rarely works; people use it on their phones. A clear policy gives them a safe way to use it and makes the risky uses plain.

Consider a chartered accountancy firm in Vadodara with about seventy staff. Client financials, PAN details and GST data move through the office every day. The partners want staff to use AI for drafting and research, and they need to be sure no client's books end up in a public tool.

What to include

Purpose and scope

Two or three sentences. The policy covers every AI tool used for work, on company or personal devices, including assistants built into email, documents and phones.

Approved tools

List the tools staff may use, with the account type. For example: the company's enterprise account of a named assistant, and agents built on your own platform. Say plainly that personal or free accounts of public tools are for public information only. Name an owner who approves new tools and keep the list in one place.

Data categories

This is the heart of the policy. Use three or four categories with examples staff recognise:

• Public. Published price lists, your website, public laws and circulars. Any approved tool.
• Internal. Internal process notes, meeting agendas, non-confidential drafts. Approved company tools only.
• Confidential. Client financials, contracts, pricing, source code, board papers. Only tools and agents the company has set up for that data, with access controls.
• Personal and sensitive. Employee records, customer KYC, health information, Aadhaar numbers, bank details. Only in systems approved for that purpose, and never in general chat tools.

For the CA firm, a client's trial balance is confidential and its directors' PAN and Aadhaar details are personal. Neither goes into a general assistant.

Checking output

State which outputs a person must check before use. A practical rule: anything sent outside the company, anything that changes a record, and anything relied on for a legal, financial, tax or HR decision is checked by a responsible person. AI output can be fluent and wrong, and the person who sends it is accountable for it.

Disclosure

Say when staff should tell a client or colleague that AI helped. Many firms require disclosure where a client contract asks for it, and leave internal drafts to judgement.

Agents that act

If your company uses agents that do more than draft, such as updating records or sending messages, the policy should say who may build or change them, which actions need approval and how their logs are reviewed. Where a person must approve gives a method for deciding those points, and prompt injection and safe tools covers the risk of agents reading outside text.

Personal data and the DPDP Act

Personal data put into an AI tool is processed under the DPDP Act, 2023 and the DPDP Rules, 2025, like any other processing. The policy should require that personal data is used in AI tools only for a stated purpose, only in approved systems, and only as much as the task needs. Agents and the DPDP Act explains where personal data turns up in prompts and logs.

Client confidentiality and intellectual property

Remind staff of existing confidentiality duties to clients and of any client contract terms on third party tools. Note that output may resemble existing material, and that code or text intended for products should be reviewed before use.

Reporting a mistake

Tell staff exactly what to do if they put the wrong data into a tool: who to tell, how quickly, and that early reporting is expected and will be treated fairly. A fast report gives you the chance to delete data or contact the provider.

Writing it so people follow it

• Use examples from your own work. "Do not paste a client's ledger into a personal chat account" is clearer than "do not share confidential information".
• Keep it short. Two or three pages. Put tool lists and examples in an appendix that can change without a full policy revision.
• Give a safe route. If staff need AI for confidential work, provide an approved tool for it. Without one, they will use whatever is at hand.
• Train in one short session. Walk through the data categories with real examples from each department.

Who owns it

Name an owner, often the head of IT or risk, with legal and HR involved. Set a review date, every three to six months at first. Keep a short register of approved tools and agents, with what data each may handle.

Where a person approves

• New tools are approved by the policy owner before use with internal data or above.
• Agents that act on records are approved by the process owner and IT before going live, with their actions and approval points written down.
• Exceptions to the policy are approved in writing by the owner.

AksharAI supports this kind of policy with workspace roles, data permissions, action boundaries and full logs, described under deployment and governance and on the security page.

Limits to plan for

• A policy does not stop copy and paste. It sets expectations. Technical controls, such as approved tools and blocked uploads on company devices, do the rest.
• Tools change monthly. New features, such as assistants built into office suites, can bring new data flows overnight. Review the tool list often.
• Categories need judgement. Staff will meet cases the examples do not cover. Make it easy to ask.
• Personal devices are hard to govern. Be realistic about what you can enforce, and focus on giving people a better approved option.