An AI acceptable-use policy tells a team which AI tools may be used, for what work, with which data and under whose review. It is not a blanket ban and it is not a promise that an AI system is accurate. A useful policy converts risk into daily decisions: an employee can tell whether a task is allowed, what information must stay out, what must be checked, and how to report a mistake.
This guide owns the policy-template intent within GPTWala’s AI adoption roadmap for manufacturers and retailers. It is an operational starting point, not legal advice. Adapt it to contracts, sector rules, employment practices and the current commencement position of India’s data-protection framework.
- Start with scope, purpose and named owners
- Create an approved-tool and account rule
- Set a clear input-data rule
- Separate allowed, review-required and prohibited uses
- Define human review by consequence
- Address prompt injection, integrations and incidents
- Protect ownership, records and intellectual property
- Roll out the policy through examples and reinforcement
- Frequently asked questions
- Sources and further reading
Start with scope, purpose and named owners
Write the policy for people who will use it during real work. State that it covers employees, contractors, interns and external partners using AI for company tasks, whether the tool is free or paid. Include text, image, audio, code, analytics, translation, automation and agent-like systems. Define the policy owner, the approving manager and the contact for security or privacy incidents.
NIST’s AI Risk Management Framework organises work around Govern, Map, Measure and Manage. A small business does not need a large committee, but it does need accountable decisions. The owner should maintain an AI-tool register, classify use cases, approve exceptions and schedule reviews. Functional managers remain responsible for the quality and consequences of work produced by their teams.
| Policy item | Minimum decision | Owner |
|---|---|---|
| Purpose | Enable useful AI work without bypassing duties | Business owner |
| Scope | People, tools, data and work channels covered | Policy owner |
| Exceptions | Who may approve and for how long | Named approver |
| Review | When the policy and tool list are checked | Policy owner |
Create an approved-tool and account rule
Employees should use only tools listed in a simple register. For each tool, record the business purpose, plan or account type, administrator, sign-in method, data settings, permitted teams, renewal date and exit method. A familiar brand name does not answer whether prompts are retained, used for improvement, visible to administrators or sent to another processor.
Free accounts and browser extensions
Do not treat a free account as automatically suitable for company work. The employee should request approval before connecting a mailbox, drive, customer platform or browser extension. The review should consider permissions, data handling, support, export and deletion. Where available, use company-managed accounts, multi-factor authentication and restricted integrations. Link the chosen tool to a defined workflow in the marketing automation guide, rather than allowing unowned experiments to become production systems.
| Tool status | Team action | Example control |
|---|---|---|
| Approved | Use only for listed purposes | Managed account and documented settings |
| Pilot | Use with test or low-risk data | Named owner and end date |
| Restricted | Use only with specialist approval | Contract or technical safeguard |
| Not approved | Do not use for company work | Report accidental use promptly |
Set a clear input-data rule
The fastest policy test is: would the employee be comfortable sending this information to an unapproved outside party? If not, it does not belong in a public or unreviewed AI tool. Prohibit passwords, authentication tokens, payment data, government identifiers, private employee information, confidential contracts, unreleased financials, customer lists, health information, protected technical files and any data a contract forbids sharing.
Even apparently harmless text may reveal identity when combined with order details, locations or complaints. Prefer synthetic examples, redacted records and the minimum fields needed for the task. The DPDP Act and notified Rules should be read for the business’s actual obligations and timeline; do not turn this policy into unsupported legal claims.
| Data class | Default AI rule | Safer method |
|---|---|---|
| Public approved material | Allowed for approved purpose | Link the public source |
| Internal routine information | Use only in approved company tool | Minimise and remove names |
| Confidential business information | Restricted unless specifically approved | Use controlled environment or summary |
| Personal or regulated data | Do not enter by default | Use authorised process with qualified review |
Separate allowed, review-required and prohibited uses
Use three practical tiers. Allowed uses may include brainstorming non-confidential ideas, improving grammar, summarising approved public material or creating a first draft from verified facts. Review-required uses include customer communication, product claims, code, pricing analysis, translations, decisions about people and public images. Prohibited uses include impersonation, deceptive reviews, discrimination, bypassing access controls, fabricating evidence, unlawful surveillance, hiding AI use when disclosure is required, or making a consequential decision without authorised human judgement.
A task may move between tiers when its context changes. Drafting a generic checklist is different from using the same tool to score employees. The NIST Generative AI Profile highlights risks such as confabulation, privacy, information security and harmful bias. Policy language should therefore follow the use case, not merely the product name.
Product and marketing truth
Require staff to follow GPTWala’s fact-safe AI product-description workflow. AI must not invent materials, dimensions, certifications, performance, prices, stock, delivery promises, customers or testimonials.
Define human review by consequence
“Human in the loop” is too vague. Name what the reviewer checks and what evidence they need. The author should verify factual statements against an approved source, check calculations independently, inspect images for product accuracy, test code safely and ensure the output fits the intended audience. The reviewer should have authority to reject the work and enough subject knowledge to recognise errors.
| Output | Required reviewer | Evidence before release |
|---|---|---|
| Internal brainstorm | Task owner | No confidential input and clear draft label |
| Customer message | Sales or service owner | Order record, policy and tone check |
| Product content | Product-data owner | Approved specification and current commercial facts |
| Code or automation | Technical owner | Test result, access review and rollback |
| People-related recommendation | Authorised manager and specialist | Lawful process and independent evidence |
Record review inside the normal system of work, such as a content approval, ticket, CRM activity or controlled file. Do not create a separate bureaucracy where an existing approval trail is sufficient.
Address prompt injection, integrations and incidents
AI tools can be influenced by text inside websites, documents, emails and connected data. OWASP describes prompt injection and sensitive information disclosure among important risks for large-language-model applications. Employees should treat external content as untrusted, avoid granting broad permissions, verify actions before execution and never allow an assistant to send, delete, purchase or publish merely because a message instructs it to.
Require immediate reporting when protected information is entered, an account is compromised, an output is sent to the wrong person, a tool performs an unexpected action or a harmful public claim is published. The report should state the tool, account, time, data type, action and known recipients without copying the sensitive data again. Follow the existing incident plan. CERT-In’s current blueprint also stresses governance, exposure reduction, supply-chain security, response and workforce readiness.
Protect ownership, records and intellectual property
Specify that company work remains subject to contracts, confidentiality, records rules and intellectual-property review regardless of the tool used. An AI response may resemble third-party material or carry unclear usage rights. Staff should not request imitation of a living creator, paste licensed material outside its permitted use, or claim exclusive ownership without review.
Keep the source brief, material approvals, important prompts, output version and reviewer where the record matters to a customer, audit or production process. Do not retain every casual experiment. Use a proportionate retention rule tied to the underlying business record. Approved public content should enter the same content marketing system as human-written material, including fact checks, source links and version ownership.
Roll out the policy through examples and reinforcement
Introduce the policy in a short live session using tasks the team recognises. Ask people to classify examples, redact a risky prompt, review a flawed answer and report a simulated incident. Give managers a one-page decision route and publish the approved-tool register where it is easy to find.
| Rollout step | Evidence of adoption | Correction if weak |
|---|---|---|
| Brief managers | Managers can explain the tiers | Use role-specific examples |
| Train the team | Staff complete scenario exercise | Repeat unsafe-data practice |
| Enable requests | Tool and exception path is visible | Remove informal approval channels |
| Review after launch | Incidents and questions are logged | Clarify recurring ambiguous rules |
Measure useful adoption, not only policy signatures. Watch for repeated questions, unapproved tools, preventable fact errors, delayed approvals and high-risk use cases. Connect approved tools to the AI-ready website and data architecture so governance supports real delivery.
Frequently asked questions
What is an AI acceptable-use policy?
It is a practical rule set defining approved AI tools, permitted purposes, restricted data, required review, prohibited conduct, incident reporting and ownership.
What should an AI use policy include?
Include scope, owners, an approved-tool register, data classes, use tiers, human-review rules, security controls, records, incident response, training and review cadence.
What data should employees never enter into an AI tool?
By default, keep out passwords, payment data, protected identifiers, confidential contracts, customer lists, private staff data and any information that law or contract restricts.
Can employees use free AI tools for work?
Only if the business has reviewed and approved the specific tool, account type, settings, permissions, purpose and data involved. Free access is not evidence of business suitability.
Who should approve AI-generated work?
The reviewer should match the consequence: a product-data owner for specifications, a sales owner for customer messages, and a technical owner for code or automation.
How often should a small business review its AI policy?
Review it on a fixed cadence and whenever a tool, integration, law, contract, incident or material use case changes. High-risk tools need more frequent review.
Sources and further reading
- NIST AI Risk Management Framework
- NIST Generative AI Profile
- MeitY Digital Personal Data Protection Rules, 2025
- OWASP Top 10 for Large Language Model Applications
- CERT-In blueprint for reducing AI-assisted cyber exposure
Operational guidance is general information, not legal, security or professional advice. Verify current requirements and obtain qualified advice for your circumstances.