Walk around almost any office in Lahore, Karachi or Islamabad and you will find people using AI tools to write emails, summarise documents, fix spreadsheets and draft proposals. Very few of those companies have told staff what is allowed. That gap is where problems start: a confidential client contract pasted into a free chatbot, a proposal with invented figures sent to a customer, or code copied into a product without anyone checking it.
Banning AI rarely works. People simply use it on their phones. A short, practical policy works much better.
What a good AI policy is for
- Protecting confidential data from being shared with outside services.
- Protecting accuracy, because AI output can be fluent and wrong.
- Protecting clients, especially where contracts restrict how their information is handled.
- Enabling productivity, by making clear what is encouraged, not only what is forbidden.
If a policy only lists prohibitions, staff will read it once and ignore it. If it tells them how to use AI safely, it becomes useful.
The sections your policy needs
1. Approved tools
List the specific AI tools employees may use for work, and under which accounts. Business or enterprise versions of major tools usually offer data terms that free consumer versions do not, such as not using your inputs for training. If the company pays for a tool, say so and ask staff to use that account rather than personal ones.
2. Data classification
This is the most important section. Keep it simple with three levels:
- Green: allowed. Public information, general writing help, rephrasing your own non confidential text, learning.
- Amber: allowed only in approved business tools. Internal documents, anonymised data, non sensitive project details.
- Red: never. Customer personal data such as CNIC numbers and phone numbers, passwords and API keys, financial records, health information, anything a client contract marks confidential, unreleased source code unless the tool is approved for it.
3. Human review
State plainly that the person who uses AI output is responsible for it. Figures, legal statements, technical claims and anything sent to customers must be checked by a human before use. AI can invent references, prices and facts with complete confidence.
4. Client work and disclosure
Some clients prohibit AI use on their projects or require disclosure. Tell staff to check before using AI on client deliverables, and set a default rule for when disclosure is needed.
5. Code and intellectual property
For software teams: AI generated code must go through the same review and testing as human written code, secrets must never be pasted into prompts, and licence concerns should be flagged. We cover team practice in AI coding assistants in a software team.
6. Automated decisions
If AI is used to screen job applicants, approve credit or make decisions about people, require human review and document the process. See AI in recruitment screening for why this matters.
7. Reporting mistakes
Make it easy and blame free to report “I pasted something I should not have”. Fast reporting limits damage. Fear produces silence.
8. Ownership and review
Name who owns the policy and commit to reviewing it every six months. AI tools change quickly and a year old policy will be out of date.
A starter template you can adapt
- Staff may use the following AI tools for work using company accounts: [list].
- Never enter customer personal data, passwords, API keys, financial records or client confidential material into any AI tool unless the tool is listed as approved for that data.
- You are responsible for anything you produce with AI help. Check facts, figures and technical statements before sharing.
- Do not use AI on client deliverables where the client contract restricts it. Ask your manager if unsure.
- AI generated code must be reviewed and tested like any other code.
- AI must not make final decisions about hiring, credit or customer disputes without human review.
- Report any accidental sharing of sensitive data to [name] immediately. Reporting will not be punished.
- This policy is owned by [name] and reviewed every six months.
Rolling it out
- Explain, do not just email. A fifteen minute session with real examples of green, amber and red data does more than a PDF.
- Provide the approved tools. If you forbid free tools but provide nothing better, people will quietly keep using the free ones.
- Share good uses. Collect prompts and workflows that save time and publish them internally.
Real scenarios your policy should cover
Policies become clearer when tested against situations employees actually face. Here are common scenarios with how a sensible policy handles them.
| Scenario | Allowed? | Policy guidance |
|---|---|---|
| Rewriting your own email to sound more professional | Yes | Green data, any approved tool |
| Summarising a public industry report | Yes | Green data, verify key figures against the source |
| Pasting a client’s contract to find risky clauses | Only in approved business tools | Check client restrictions first, never in free consumer tools |
| Uploading a spreadsheet of customer names and phone numbers for analysis | No, unless approved for personal data | Remove personal identifiers or use approved internal tools |
| Using AI to draft a proposal with pricing | Yes, with review | Prices and commitments must be checked by an approver |
| Asking AI to shortlist job applicants | Only as assistance | Human decision required, criteria documented, bias checked |
| Pasting production database credentials to debug an issue | Never | Red data, rotate credentials immediately if it happens |
| Generating images for social media | Yes, with review | No misleading depictions of real customers, products or results |
Including a table like this in the policy itself helps staff far more than abstract rules.
Choosing approved tools
When deciding which AI tools to approve and pay for, evaluate them on practical criteria rather than popularity alone:
- Data terms: whether inputs are used for training, how long data is retained, and where it is processed.
- Account controls: central administration, single sign on, removing users when they leave.
- Security features: two factor authentication, audit logs, admin visibility.
- Usefulness for your work: test with real tasks from different departments.
- Language support: quality in Urdu and Roman Urdu if staff work with local customers. See AI for Urdu and Roman Urdu.
- Cost per user and whether usage limits fit your team’s needs.
- Integration with tools you already use, such as email, documents and CRM.
Handling an incident
Even with a good policy, mistakes happen. Having a simple incident process means the response is calm and fast.
- Report immediately to the named policy owner, without fear of punishment for honest mistakes.
- Identify what was shared: type of data, how much, which tool and account.
- Contain: delete conversations where the tool allows, rotate any exposed passwords or keys, restrict access if needed.
- Assess impact: whether customer or client data was involved and whether contractual or legal obligations apply.
- Notify affected parties where required, with advice from legal counsel for serious cases.
- Learn: update the policy, training or tool settings so the same mistake is less likely.
Training that actually changes behaviour
A policy document alone rarely changes habits. Short, practical training works better:
- A 20 minute session per department with examples from their own work.
- A one page quick reference pinned in the office chat group or intranet.
- Onboarding for new hires in their first week.
- Short refreshers when new tools are approved or rules change.
- Champions in each team who share good workflows and answer questions.
Measuring whether the policy works
Track a few indicators: how many staff use approved tools, reported incidents and near misses, questions raised to the policy owner, time saved in key workflows, and quality issues traced to unchecked AI output. Rising adoption of approved tools combined with few serious incidents suggests the policy balances safety and productivity well. A policy that nobody follows, or that causes staff to hide AI use, needs revision.
Special considerations for software companies
Software houses and IT teams have extra risks: client source code, credentials in configuration files, and contractual confidentiality. Add rules on which coding assistants are approved for client repositories, how to prevent secrets from being shared, and how AI generated code is reviewed. See AI coding assistants in software teams and software contract checklist.
Frequently asked questions
Is this a legal document?
It is an internal policy. For regulated industries or specific contract obligations, have it reviewed by a lawyer.
Should we block AI websites on office networks?
Blocking pushes use onto personal phones where you have no visibility. Providing approved tools and training is usually more effective.
What about AI features inside tools we already use?
Office suites, CRMs and design tools increasingly include AI. Treat these like any other AI tool: check the data terms and classify accordingly.
Should interns and contractors follow the same policy?
Yes. Anyone with access to company or client data should receive the policy and training before using AI tools for work.
What if an employee uses AI on a personal phone for work?
The same data rules apply regardless of device. Provide approved tools so staff have a convenient, safe alternative.
The bottom line
A one or two page AI policy, focused on data classification and human responsibility, protects your company far better than a ban. Pair it with approved tools and short training, and review it twice a year.
If you want to go further and build AI into your workflows safely, our AI solutions team can help, starting with our AI data readiness checklist.