# AI Acceptable Use Policy: What to Include, Who Signs It Off and How to Make It Stick

> What belongs in an AI acceptable use policy and who signs it off? Use our section outline, use-case matrix and seven-step plan to draft yours this week.

Source: https://digitalbridge.com.tr/en/blog/company-ai-acceptable-use-policy.html
Publisher: Digital Bridge Teknoloji (https://digitalbridge.com.tr)
Topic: Artificial Intelligence
Published: 2026-10-09 · Updated: 2026-10-22

An AI acceptable use policy is an internal document that sets out which AI tools staff may use, for which tasks, with which data and on whose approval. A good one is more than a list of bans: it defines scope, owners, use-case approval, output accountability, training and a review cycle, and takes effect once signed off.

## What happens when there is no policy

In most organisations AI arrived as a habit rather than a decision. Marketing drafts copy with it, sales summarises proposals, developers accept code suggestions and HR writes job adverts. Each team has its own tool and rules. What these uses look like when they are set up properly is covered in [AI in B2B marketing](https://digitalbridge.com.tr/en/blog/ai-in-b2b-marketing.html) and [AI proposal writing](https://digitalbridge.com.tr/en/blog/ai-proposal-writing.html).

The trouble is that nobody owns this patchwork. An employee who asks which tools are approved, who is accountable for a contract clause drafted by AI, or who reviews a new tool will not get a clear answer. When something goes wrong, there is no written rule to enforce.

We covered the data side, meaning what should never be pasted into ChatGPT-style tools, in our piece on [ChatGPT and company data security](https://digitalbridge.com.tr/en/blog/chatgpt-company-data-security.html). This article covers the document that carries those rules: its sections, owner, approval and rollout.

## The cost of running AI without a policy

Türkiye's Personal Data Protection Authority (KVKK, which enforces Law No. 6698, the country's GDPR-style data protection law) described the situation in a March 2026 notice (our translation):

> In particular, the fact that these tools are not always used within a clearly defined corporate strategy, policy or guidance framework, and that their use is in most cases shaped by employees' individual preferences to make their daily work easier, can make it difficult to monitor and manage generative AI tools at organisational level. ([KVKK notice "Use of Generative AI Tools in Workplaces", 5 March 2026](https://www.kvkk.gov.tr/Icerik/8674/is-yerlerinde-uretken-yapay-zeka-araclarinin-kullanimi))

The policy gap shows up in breach data too. In [IBM's Cost of a Data Breach Report 2025](https://newsroom.ibm.com/2025-07-30-ibm-report-13-of-organizations-reported-breaches-of-ai-models-or-applications,-97-of-which-reported-lacking-proper-ai-access-controls), 63% of breached organisations either had no AI governance policy or were still developing one. A policy should not be something rushed out after an incident.

Uncertainty also holds back the firms that have not started. In the [OECD's 2025 D4SME survey](https://www.oecd.org/content/dam/oecd/en/networks/oecd-digital-for-smes-global-initiative/D4SME-2025-Policy-Highlights.pdf), 67% of responding SMEs not using generative AI were unsure how to use it or what the risks were. A clear policy tells that hesitant majority which tool, task and limits apply.

Incidents are rising as well: the [Stanford AI Index 2026](https://hai.stanford.edu/assets/files/ai_index_report_2026.pdf) reports that AI incidents recorded in the AI Incident Database grew from 233 in 2024 to 362 in 2025. Banning tools one by one cannot keep up; you need a document that sets principles and process.

## What an AI acceptable use policy should contain

Every section should answer a real question. The outline below suits most small and mid-sized companies and can also sit as an annex to your information security policy.

| Section | Question it answers | Common mistake |
|---|---|---|
| Purpose and scope | Who and which tools are covered? Contractors and interns too? | Saying "ChatGPT" and forgetting AI built into email, office suites and CRM |
| Definitions | What counts as generative AI, an agent, an approved tool, sensitive data? | Rules built on undefined terms, open to interpretation |
| Roles and responsibilities | Who owns, approves and enforces the policy? | Leaving it all to IT |
| Approved tools and use cases | Which tool may be used for which task? | A tool list with no distinction between tasks |
| Data rules | Which data class may go into which tool? | Vague wording not tied to a data classification |
| Output accountability and transparency | Who checks output, and when is AI use disclosed to clients? | Leaving room for "the AI wrote it" as an excuse |
| Prohibited uses | Where is AI never used? | Ignoring automated decisions about employees |
| New tools and exceptions | How does someone request a tool that is not listed? | No request route, which pushes people to shadow use |
| Incident reporting | What happens when the wrong data is entered, and who is told? | Punitive wording that makes people hide mistakes |
| Training and review | Who is trained, when, and how often is the policy revisited? | Writing it once and forgetting it |

The data rules section should rest on your data classification; how to set classes and owners is covered in our [data governance framework](https://digitalbridge.com.tr/en/blog/data-governance-framework.html) guide. For use cases involving personal data, point the policy at a separate legal assessment covering lawful basis and cross-border transfer, as described in [AI and KVKK personal data](https://digitalbridge.com.tr/en/blog/ai-and-kvkk-personal-data.html).

## Approve use cases, not just tools: green, amber and red

The same tool can be harmless for one task and a serious risk for another. Tie each approval to a combination of tool, use case and data class, and sort use cases into three colours:

| Colour | Example use case | Condition |
|---|---|---|
| Green: allowed | Drafting from public information, general research, proofreading | Approved tool and a company account |
| Amber: conditional | Client-facing correspondence, summaries of internal documents, code suggestions, translation | Approved tool, human review, sources checked |
| Red: prohibited or specially approved | Hiring and performance decisions, credit or pricing decisions, health data, final contract wording | Only with a separate risk assessment and management sign-off |

Why amber cases need a human check is shown with examples in our article on [reducing AI hallucinations](https://digitalbridge.com.tr/en/blog/reducing-ai-hallucinations.html). Decisions about staff deserve particular care on the red list; the limits on processing employee data are set out in [employee personal data under KVKK](https://digitalbridge.com.tr/en/blog/employee-personal-data-kvkk.html).

Cases where AI does more than produce text, such as agents that act inside business systems, need their own clause. State which permissions an agent may hold, at which steps a person must approve its actions, and how its activity is logged; the checklist in our guide to [AI agents for business](https://digitalbridge.com.tr/en/blog/ai-agents-for-business.html) can be lifted straight into the policy. Safeguards against instructions hidden in the documents or emails an agent reads are covered in [prompt injection security](https://digitalbridge.com.tr/en/blog/prompt-injection-security.html).

## Seven steps to write the policy and put it into force

1. **Map current use.** Run a short survey with no disciplinary consequences to learn which team uses which tool for what. The policy should govern real use, not an imagined one.
2. **Name an owner and a small board.** Give the policy one owner, supported by IT or security, legal or the data protection lead, and a business unit representative.
3. **Build the use-case matrix.** Classify every use from the survey as green, amber or red and link approved tools to the matrix. Assess AI vendors with the questions in our [third-party vendor security assessment](https://digitalbridge.com.tr/en/blog/third-party-vendor-security-assessment.html) guide.
4. **Open a request and exception route.** Create a one-page request form for new tools or use cases and commit to a reasonable response time. Without a route, people will use tools without asking.
5. **Map technical controls to rules.** Back the policy with mandatory company accounts, web filtering and data loss prevention rules; we explain how rules and controls line up in our guide to [data loss prevention (DLP)](https://digitalbridge.com.tr/en/blog/data-loss-prevention-dlp.html).
6. **Train and collect acknowledgement.** Deliver short training built around real scenarios and record that staff have read the policy; linking it to your [security awareness training programme](https://digitalbridge.com.tr/en/blog/security-awareness-training-program.html) keeps the effort manageable. How training fits with roles and job descriptions is covered in [human–AI collaboration at work](https://digitalbridge.com.tr/en/blog/human-ai-collaboration-at-work.html).
7. **Measure and update.** Review at least once a year using requests, exceptions and reported incidents, and immediately when a new tool or a regulatory change arrives.

A note for companies that offer AI systems in the EU market or whose AI output is used in the EU: under the [European Commission's AI Act timeline](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai), the AI literacy obligation has applied since 2 February 2025. Step six's training records help here; when the act reaches Turkish companies is covered in our guide to [the EU AI Act for Turkish companies](https://digitalbridge.com.tr/en/blog/eu-ai-act-for-turkish-companies.html).

## Keeping the policy alive: a safe alternative and ongoing oversight

A policy only holds when it offers an alternative to what it forbids. "Do not paste client documents into external tools" has to come with "use this company assistant instead". The architecture of a permission-aware assistant that works on your own documents is explained in [RAG for enterprise LLMs](https://digitalbridge.com.tr/en/blog/rag-enterprise-llm.html).

To keep the policy working, track three indicators: pending requests, exceptions granted for red use cases and incident reports. Zero reports is more likely to signal that people are reluctant to speak up than that nothing happened. Write the incident section so that good-faith reporting is never punished.

If you have not yet decided where AI should start in your organisation, work on the policy alongside an [AI roadmap for your business](https://digitalbridge.com.tr/en/blog/ai-in-business-where-to-start.html). The priority use cases you choose there will shape the policy matrix; if you run an [ISO 27001 management system](https://digitalbridge.com.tr/en/blog/iso-27001-guide-for-smes.html), the controls fit within it.

## How we approach this at Digital Bridge

We write policies from how a company actually works:

- **Discovery and needs analysis.** Through our [cyber security consultancy](https://digitalbridge.com.tr/en/consultancy/cyber-security.html) we interview teams, map tools, account types and data flows, and draft the use-case matrix and policy together with you.
- **Data protection and classification.** With [data protection compliance](https://digitalbridge.com.tr/en/consultancy/data-protection-compliance.html) support we align personal data use cases with privacy notices, the data inventory and transfer assessments, and our [data governance and quality](https://digitalbridge.com.tr/en/data-analytics/data-governance-quality.html) work pins down data classes and owners.
- **Pilot and a safe alternative.** We pick one amber use case and pilot it with a small team. For sensitive documents we build an [enterprise LLM assistant](https://digitalbridge.com.tr/en/technology-hardware/enterprise-llm-assistant.html) that respects permissions and cites its sources, running entirely on your own servers where required.
- **Integration.** We connect approved use cases to your ERP, CRM or intranet through [AI integration](https://digitalbridge.com.tr/en/technology-hardware/ai-integration.html), so staff reach the approved channel without hunting for a separate tool.

For ready-made tools, our own [Smart360 product family](https://digitalbridge.com.tr/en/smart360.html) enforces the policy's "who, with which data, how much" question inside the product. In [SmartMail business email](https://digitalbridge.com.tr/en/smart360/smartmail.html) and SmartFiles, AI is a separate permission granted person by person; usage is counted against the organisation's monthly allowance shown in the panel, and in SmartFiles an administrator can switch the feature off entirely. SmartMail's audit log records actions taken by AI separately, as "System".

## Next step

Do two things this week: send your teams a short survey asking which AI tools they use for which tasks, and place the answers in the green, amber and red table above. That table is your first draft. To refine it and choose a pilot use case, [get in touch with us](https://digitalbridge.com.tr/en/contact.html). More articles on the subject are collected in our [Artificial Intelligence hub](https://digitalbridge.com.tr/en/blog/topic/yapay-zeka.html).

## Frequently Asked Questions

### How long should an AI acceptable use policy be?

Two to five pages is enough for most companies. What matters is that each section answers a question: scope, roles, approved tools and use cases, data rules, output accountability, prohibitions, the request process, incident reporting and review. Keeping the detailed tool list and use-case matrix as annexes lets you update them without re-approving the whole policy.

### Should we write a separate AI policy or update our information security policy?

Either works. If your information security policy is current and well known, adding AI as a dedicated section is enough. If use is widespread, teams rely on different tools and business units make their own choices, a standalone policy is more visible. In both cases, link it to your data classification and your existing incident reporting process.

### Who should approve the AI policy?

The policy needs a named owner and sign-off from senior management. The owner is usually the information security or IT lead, but the approval group should also include legal or the data protection lead and at least one business unit representative. A policy written by IT alone tends to miss real business needs and is quickly worked around.

### What should happen when an employee breaches the policy?

Start with the nature of the breach. An honest mistake, such as pasting an internal document into the wrong tool and reporting it, should be handled with training and correction; otherwise people will hide incidents. Deliberate or repeated breaches belong in your existing disciplinary procedure. Spell out this distinction in the incident reporting section.

### Is an AI acceptable use policy a legal requirement?

The obligations behind it are binding more than the document itself. Türkiye's data protection law expects controllers to take the necessary technical and administrative measures to keep personal data secure, and the authority's 2026 notice flagged unmanaged workplace AI use. Companies that offer AI systems in the EU or whose AI output is used there may also fall under the AI Act's AI literacy obligation. A written policy is one of the most practical ways to show the measures taken for these duties; it does not replace a legal assessment of how they apply to your company.

### How often should the policy be reviewed?

Review it at least once a year. In between, update it when a new tool is approved, when a provider changes its terms, when relevant regulation changes or after an incident. Holding the approved tool list and use-case matrix in annexes means these updates can be made without taking the main text back through approval.