An AI usage policy for your company: where can code, data and customer information go?

Somebody on your team pasted a stack trace into an AI tool today. Somebody else pasted a SQL schema, and a third person pasted the full text of a customer complaint. If you cannot say which tool, under which account and on which contract terms, then your company's AI policy currently reads "everyone uses whatever is closest". This article is about turning that sentence into one page of rules that people can follow and that your tooling enforces.

One note before we start: what follows is engineering governance and should not be read as legal advice. Deciding the lawful basis, the mechanism for transfers abroad, processor agreements, whether an incident must be notified, and how the EU AI Act classifies your product belongs to your legal and compliance team. We give you the questions to bring them and the setup to build on the engineering side.

Our running example is a fictional travel booking company, Rota: forty engineers, mobile and backend teams, a product that takes payments.

"We have no policy" is a policy

On a Monday morning a backend developer at Rota is chasing a production error and pastes this into the chat tool that happens to be open under a personal account:

Can you help with this? Some users get a 500 after payment in prod.

2026-09-28T09:14:03Z ERROR PaymentController orderId=RT-48213
  user={"name":"Ayşe Yılmaz","email":"ayse.yilmaz@example.com","phone":"+90 532 000 00 00"}
  card=5400 00** **** 1234
  Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
  DB_URL=postgres://rota_app:S3cr3t!@prod-db.rota.internal:5432/booking

Nobody here is malicious or lazy: someone wants to finish quickly and nothing stops the paste or points to a better tool. In one paste, a customer's personal data, a valid session token and a database password went to a vendor the company has no contract with. This is shadow AI, and it is a pattern we see often in large teams. The Turkish data protection authority (KVKK) makes the same observation in its March 2026 document on generative AI tools in workplaces: the tools are frequently used on individual employees' preference, outside any defined corporate policy, which makes them hard to monitor at organisation level.

The reflex answer is a blanket ban, and it fails. A ban leaves usage where it was and moves it to personal phones and home laptops. You lose the logs and you lose the employee who would have told you when something went wrong. We recommend the opposite order: hand people a good approved tool first, then close off everything else.

People use the tool with the least friction. The policy's job is to make sure the tool with the least friction is also the approved one.

What separates tools is the contract

The same model treats your data differently depending on which door you came in through. These are the questions we ask about a tool, and we take the answers from the vendor's own data-usage documentation.

Are inputs used for training? With most vendors the line runs between consumer and commercial terms. Anthropic's data usage page says that on Free, Pro and Max accounts this is a user setting, and data is used for model training when the setting is on. On Team, Enterprise and API it is not used unless the customer opts in. Under Google's Gemini API terms, content sent on the unpaid quota is used to improve products and may be read by human reviewers, while paid usage is not (users in the EEA, Switzerland and the UK get the paid terms on the unpaid quota too). OpenAI's platform documentation states that API data is not used for training unless the customer explicitly opts in to share it. GitHub's model hosting page notes that individual subscribers' interaction data may be used to train models and that they can opt out. A personal account and a company account look like the same product and are different contracts.

How long is it kept? "Not used for training" does not mean "not stored". On the OpenAI API, abuse monitoring logs are kept for up to 30 days by default, and some endpoints (those that store conversations and threads) keep data until you delete it. Anthropic gives 30 days as the standard retention for commercial use, and up to two years for inputs and outputs flagged as usage policy violations. On a consumer account that allowed training, retention is five years. These numbers change, so put the link to the page in your policy and leave the number out.

Is zero data retention available, and is it available to you? Existing is not enough. At OpenAI, zero data retention and modified abuse monitoring require prior approval. At Anthropic, ZDR is not part of the standard Enterprise plan and is enabled per organisation for qualified accounts. When a sales call includes "we support ZDR", the question to ask is whether it is switched on for your account today.

Where is the data processed? Some vendors offer a choice of region, but regions often need extra approval or a contract amendment and do not cover every feature. Look at the layers in between as well: your IDE assistant may send the request to its own servers, which forward it to a model provider. GitHub's page lists that for Copilot the hosting party varies by model, each with its own retention commitment. Every link in that chain is a sub-processor from your point of view.

Who at the vendor can see it? Most contracts reserve human access for safety and abuse review. Feedback buttons are a separate channel: in Claude Code the /feedback command sends the conversation history including code, and that record is kept for five years.

What IDE assistants and coding agents send

In a chat window you can see what you are sending. In an IDE assistant you cannot. Code completion sends the code around the cursor and snippets from open tabs as context. Agents go further: every file they read, the output of every command they run, and every response from every connected MCP server becomes part of the conversation and goes to the model. If the agent runs env, your environment variables are in the prompt. If it runs cat .env.production, so is your production password. There is a local trail too: Claude Code stores session transcripts in plaintext under ~/.claude/projects/ for 30 days by default.

Do not trust file exclusion features blindly either. GitHub's documentation says plainly that content exclusion is not supported in Copilot CLI or in agent mode in IDEs. Look for the equivalent sentence in your own tool's docs.

Browser extensions and meeting assistants

Engineering teams usually skip these two. An AI extension with permission to read page content can read your admin panel, your customer support console and your internal wiki whenever they are open. A meeting assistant moves an audio recording, a transcript and an attendee list to a third party, and on a customer call that includes the other side's data. Put both through the approved-tools process and manage browser extensions with an allowlist through MDM.

A data classification you can apply in ten seconds

Nobody opens a twenty-page classification standard while writing a prompt. Four classes are enough, each with a single test question.

We sort tools into four tiers as well:

T0  Personal/consumer account, free quota, unapproved extension
T1  Approved business account: SSO, training off by contract, processor agreement signed
T2  T1 plus tightened terms: zero or short retention, pinned region, access through the internal gateway
T3  A model running on your own infrastructure or in your own cloud account, or on device

The verdict in that table: we open source code to T1, because a team that hides its code from AI soon becomes a team working in T0. Secrets have no tier they may go to, your own self-hosted model included. A secret lives in the secret manager, and there is no legitimate reason for it to enter a prompt.

Rules for code

Secrets never. Not in a prompt, not in a file the agent can read, not in the environment of the shell the agent runs in. A secret that entered a prompt counts as leaked and gets rotated.

Accountability sits with whoever commits. "The AI wrote it" is not accepted as an explanation. We treat AI output like the work of a colleague who just joined: fast, often useful, always read. The author of the code is the person who read it line by line and ran it.

Disclosure in the PR. It tells the reviewer where to look harder. Our template section:

## AI usage
- [ ] No AI tool was used in this PR
- [ ] Used: (tool name, which files or parts)
- [ ] I read the generated code line by line and ran the tests on my machine
- [ ] If a new dependency was added, I checked that the package exists and checked its licence
- [ ] Nothing above the confidential class went into prompts

The fourth item is there for a reason. Models inventing package names that do not exist is a known failure mode, and someone registering that name later is a supply chain attack.

Licence and provenance. Generated code can repeat long stretches of licensed code from training data. Our rule: for blocks you did not write that run past twenty or thirty lines and look suspiciously polished, search for their origin, and if your tool offers a setting that filters or attributes suggestions matching public code, turn it on. The copyright status of generated code and the vendor's indemnity commitment are clauses for your legal team to read.

Review does not loosen. The human review requirement applies unchanged to code written with AI, and AI review is added in front of human review without replacing it. We describe how we set that up in our article on AI code review.

Agents run with least privilege. An agent should not be a process that inherited the developer's full authority. No agent runs in a shell that holds production credentials, or in a terminal with an active cloud CLI session. It cannot write outside the working directory, cannot reach network hosts outside an allowlist, and git push and deploy commands need a human. Remote agents get access to the one repository they work on, with a short-lived, narrowly scoped token. We show how to enforce this at tool level below.

Customer data and personal data

The first rule here is an engineering rule before it is a legal one: data you never send to the model cannot leak from it. The KVKK principle in Article 4 of being "relevant, limited and proportionate to the purposes" and data minimisation in Article 5 of the GDPR say the same thing. To fix a bug you do not need the customer's name, you need the shape of the failure.

There are three questions to take to your legal team. The first is the lawful basis: sending customer data to an AI tool is a new processing activity, which needs a basis under KVKK Article 5 or GDPR Article 6 and a matching line in your privacy notice. The second is transfers abroad: most model providers process data outside Türkiye. Article 9 of the KVKK, as amended in 2024, looks for an adequacy decision or, failing that, one of the appropriate safeguards, and when a standard contract is used it must be notified to the Authority within five business days of signing. The GDPR counterpart is Chapter V (adequacy decisions, standard contractual clauses). The third is the processor relationship: if the vendor processes data on your behalf, GDPR Article 28 requires a written contract, and KVKK Article 12 makes you jointly responsible with the processor for security measures. A consumer account comes with none of these agreements, which is why T0 is closed to personal data. If you operate in Türkiye, read KVKK's generative AI guide together with your legal team.

Redaction before the prompt

Have a single point that every model call touching customer data passes through, and redact there:

data class Redacted(val text: String, val counts: Map<String, Int>)

// Order matters: long, distinctive patterns first
private val rules = listOf(
    "IBAN" to Regex("""\bTR\d{2}(?:\s?\d{4}){5}\s?\d{2}\b"""),
    "CARD" to Regex("""(?<!\d)(?:\d[ -]?){13,19}(?!\d)"""),
    "JWT" to Regex("""\beyJ[\w-]+\.[\w-]+\.[\w-]+"""),
    "EMAIL" to Regex("""[\w.+-]+@[\w-]+(?:\.[\w-]+)+"""),
    "PHONE" to Regex("""(?<!\d)(?:\+90|0)?\s?5\d{2}\s?\d{3}\s?\d{2}\s?\d{2}(?!\d)"""),
    "NATIONAL_ID" to Regex("""(?<!\d)[1-9]\d{10}(?!\d)"""),
)

fun redact(input: String): Redacted {
    val counts = mutableMapOf<String, Int>()
    val text = rules.fold(input) { acc, (label, regex) ->
        regex.replace(acc) {
            counts.merge(label, 1, Int::plus)
            "[$label]"
        }
    }
    return Redacted(text, counts)
}

The patterns here are for Turkish IBANs, mobile numbers and national ID numbers. Swap in the formats of your own market. This code catches identifiers with a known format. It does not catch names, addresses or health information buried in free text. That makes redaction the second line of defence, and the first is not sending the field at all: give the model the three fields of the customer object that matter and leave the rest behind. If you are building an assistant that works with customer data inside your product, we cover the access control side in our article on an internal knowledge assistant with RAG.

Logging prompts without logging the prompt

For audit you need to know who used which tool, when, and with which data class. If you store the prompt itself in plaintext you have created a second copy of your most sensitive data in a place that is protected less carefully. This is the record we keep:

data class PromptAudit(
    val requestId: String,
    val userId: String,              // SSO identity, never a customer identifier
    val tool: String,                // "gateway/chat", "ide-assistant"
    val model: String,
    val dataClass: String,           // "internal", "confidential", "restricted-redacted"
    val promptChars: Int,
    val promptSha256: String,        // digest of the redacted text, to spot repeats
    val redactions: Map<String, Int>, // {"EMAIL": 2, "PHONE": 1}
    val timestamp: Instant,
)

The redactions field doubles as an early warning: if one team's prompts have dozens of card numbers redacted every day, that team is working with the wrong data and you found out without a breach. If debugging needs the full text, keep the redacted version in a separate store with short retention and restricted access.

AI features inside your own product

Using tools and shipping AI in your product are separate topics, and the policy should cover both. We write three rules. Users know when they are talking to an AI system, and generated content is labelled as such. Outputs with consequences for the user (a refund refusal, a price difference, an account restriction) pass through a human, or at the very least the user is given a route to appeal to one. Model output is treated as untrusted input: it does not become a SQL query, a shell command or a payment operation without validation.

If you have users in the EU you also need to look at the EU AI Act. The regulation is risk-based: practices with unacceptable risk are banned, high-risk systems carry strict obligations, certain systems carry transparency obligations, and the large remainder has no specific requirements. According to the European Commission's page, the timeline is as follows: the Act entered into force on 1 August 2024, the prohibitions and AI literacy obligations have applied since 2 February 2025, obligations for general-purpose AI models since 2 August 2025, and the transparency rules in Article 50 since 2 August 2026. Obligations for high-risk systems were postponed by the AI Omnibus regulation that entered into force on 27 July 2026: 2 December 2027 for certain high-risk areas and 2 August 2028 for systems integrated into products. A customer support chatbot most likely falls under transparency, and a system that screens job applicants or assesses credit may be high-risk. Your legal team does the classification, and engineering's job is to describe to them in full what the product does.

The approved-tools list and how a new tool gets on it

Keep the list short, and have each line name the tool, the plan, the highest permitted data class and an owner. One approved option each for chat, IDE assistant, coding agent and meeting notes is enough for most teams. This is the intake form we use for a new tool request:

Tool and plan:
Requested by / future owner:
What work, with which data class:

1. Is there a business plan with SSO? Can accounts be closed at offboarding?
2. Are inputs used for training? What is the default, what does the contract say? (link)
3. What is the retention period? Is zero retention enabled on our plan?
4. In which country is data processed? Who are the sub-processors? (link)
5. Can we sign a processor agreement and a transfer mechanism?
6. What does the tool access on the machine: files, terminal, browser, clipboard, microphone?
7. Admin controls: audit log, feature switches, file exclusion?
8. Can feedback and telemetry channels be turned off?
9. Exit: can we delete our data and get confirmation that it was deleted?

Decision: approve / reject / conditional   Class ceiling:   Review date:

The real value of the form is speed. If a request sits unanswered for more than two weeks, the team will not wait and will start using the tool in T0. We suggest a group of three (security, legal and one engineering representative) and a ten-business-day response time.

Technical enforcement, so the policy is not just a PDF

SSO-managed business accounts. Approved tools are entered with the company identity only. That way the contract terms apply to everyone, a leaver's access closes, and the audit log has a name in it.

Secret scanning, two layers. A pre-commit hook on the developer machine and push protection on the server. The pre-commit configuration for Gitleaks:

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.24.2   # take the current version from the project's releases page
    hooks:
      - id: gitleaks

A local hook can be skipped, so the server side is mandatory. GitHub's push protection blocks pushes containing secrets before they reach the repository. It can be bypassed, but each bypass requires a reason, creates an alert and lands in the audit log. GitLab and Bitbucket have equivalent features.

Agent permissions live in the repository. In Claude Code this is the settings file committed to the project. Other agents have their own permission files, and the principle is the same:

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(secrets/**)",
      "Bash(git push *)",
      "Bash(curl *)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "allowUnsandboxedCommands": false,
    "filesystem": {
      "denyRead": ["~/.ssh", "~/.aws", "~/.kube"]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

According to the documentation, Read deny rules cover the built-in file tools and recognised commands such as cat, and do not cover a Python script that opens files by itself. The sandbox, which is enforced by the operating system, stops that. The sandbox in turn wraps shell commands only, and MCP servers run outside it. If you put these settings into centrally deployed managed settings, developers cannot loosen them on their own machines.

An instruction file that tells the agent the rules. The shared format many tools read is AGENTS.md (Claude Code reads CLAUDE.md; confirm the file name in your tool's documentation):

# AGENTS.md

## Data rules
- Do not read .env*, secrets/ or *.pem files, and do not print their contents.
- Do not connect to the production database, production APIs or dumps containing customer data.
  For tests use only the synthetic data under fixtures/.
- If you see an email, phone number, card number or token in a log or error output,
  do not repeat it verbatim. Write [REDACTED] and warn the user.

## Execution rules
- Do not run git push, deploy, migration or package publishing commands. Propose the command, a human runs it.
- Before adding a new dependency, stop and ask, with your reasoning.
- Do not touch files outside the task description. If you think it is needed, say so first.

This file is a request and enforces nothing. The model can forget the instruction or be talked out of it by a prompt injection. Wherever a rule has to hold, the permission and sandbox layer above must stand behind it.

Egress control and an internal gateway. There are two options on the network side. The cheap one is to block the consumer endpoints of unapproved AI services on corporate devices at proxy or DNS level, and show the approved tool on the block page. The sturdier one is to route model access through a single internal gateway: developers and services never see the vendor API key, the gateway takes identity from SSO, applies redaction, writes the PromptAudit record and decides in one place which model may receive which data class. For a team of forty we would start with blocking and build the gateway on the day you start calling models from inside your product.

Audit logs. Pull the logs your business plans provide into your SIEM and look at them once a quarter: who uses which tool, which approved tool nobody uses (a sign that people are using something else), how many secret pushes were blocked.

When something restricted went into the wrong tool

It will happen. This section of the policy exists so that when it does, the person writes it up within five minutes instead of hiding it.

1. Report. Post in #security: what, to which tool, under which account, when.
   No sanction for the person who reports. There is one for concealing.
2. If it is a secret, rotate it now. Deleting the chat does not take the secret back.
3. Delete the conversation in the tool and note the vendor's deletion and retention period.
   On a business account, have the admin open a deletion request.
4. If personal data is involved, tell the data protection officer and legal.
   They decide whether this is a breach that must be notified.
5. Keep a record: which data, how many people, which class, actions taken.
6. Fix the cause: was a tool missing, was a log printing too much, was a block absent?

Speed matters in step four. GDPR Article 33 asks for notification to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of the breach. KVKK Article 12 says "within the shortest time", which the Board interpreted as 72 hours in its decision 2019/10. The clock starts when you learn about it, so an engineer who mentions on Monday what happened on Friday evening has used up your legal team's time. Deleting in the UI does not mean immediate deletion on the server: the vendor's retention period keeps running.

For step six, back to the Rota example: the underlying fault lay in the log line that printed personal data and the Authorization header in plaintext, more than in the person who pasted it. Cleaning up your logs is the cheapest clause in your AI policy.

A one-page policy template

AI USAGE POLICY   v1.0   Owner: (name)   Next review: (date)

1. SCOPE
   All AI tools used for company work: chat, IDE assistants, coding agents,
   browser extensions, meeting assistants, and the AI features in our products.

2. APPROVED TOOLS
   Current list: (link). A tool not on the list may not be used with company data.
   Approved tools are entered with the company SSO account only. A personal account is T0.

3. DATA CLASSES AND TOOL TIERS
   Public: any tool.  Internal: T1 and above.  Confidential (code, architecture): T1 and above, tools approved for code.
   Restricted / personal data: T2-T3 only, redacted, for a defined purpose.
   Restricted / payment and health: T3 only, with compliance sign-off.
   Secrets and credentials: no tool.

4. CODE
   Whoever commits owns the code. AI usage is disclosed in the PR.
   Human review is mandatory. A new dependency's existence and licence are verified.

5. AGENTS
   Least privilege. No production credentials. Sandbox on. Push, deploy and migration need a human.

6. PERSONAL DATA
   First do not send, then redact. A new purpose of use does not start without legal approval.
   Prompt logs hold no personal data.

7. AI IN OUR PRODUCTS
   Users know they are interacting with AI. Consequential outputs pass through a human.
   A new AI feature goes through legal and security review before release.

8. NEW TOOLS AND EXCEPTIONS
   Intake form: (link). Response time: 10 business days.
   Exceptions are written, time-boxed (90 days at most) and have a named owner.

9. INCIDENTS
   If data went to the wrong tool, post in #security immediately. No sanction for reporting.

10. REVIEW
    Quarterly, and whenever a vendor term, a regulation or an incident triggers it.

Rollout: training, exceptions, review cadence

A four-week plan works for most teams. Week one is inventory: use an anonymous survey and proxy logs to learn which tools are in use today. The survey has to be anonymous, otherwise you will only hear about approved tools. In week two, buy the approved tools, hand out licences and publish the policy. The order matters: a rule without an alternative gets ignored. In week three, run a forty-five minute training session, and in place of slides use realistic cases like the log example above for a "which class is this, which tool may it go to" exercise. In week four, switch on the technical enforcement: push protection, the block list, agent settings files. We describe more broadly how we place AI tools into the development process in our article on AI transformation of the SDLC.

There will be exceptions, and there should be. A policy with no exceptions is a policy that runs on hidden ones. Give each exception an owner, a justification and an end date, and keep the records in the same place as the approved-tools list. When the same exception is requested for the third time, it is time to change the policy.

Review quarterly. Vendor terms in this field change several times a year, and an email saying "we have updated our terms" can change the tier of a tool on your approved list. Make sure vendors' terms-change notices go to a distribution list that includes the policy owner, and not to one person's inbox.

Checklist

• An anonymous survey and network logs established which AI tools the team uses today and under which accounts.
• There is at least one approved business tool each for chat, IDE assistant and coding agent, entered through SSO.
• For every approved tool, training use, retention period, processing region and sub-processors were read from the vendor's own documentation and the links are on the list.
• The four data classes and the tool tier table are published, and the team practised with real examples.
• Secret scanning is on both at pre-commit and on the server, and bypasses are monitored.
• Agent permission and sandbox settings live in the repository or in managed settings, and no agent runs in an environment holding production credentials.
• Repositories contain an agent instruction file with the data and execution rules.
• Model calls that touch customer data pass through a single point, with redaction and the audit record there.
• Logs do not print personal data or tokens.
• Legal approved the lawful basis, the mechanism for transfers abroad and the processor agreements.
• In-product AI features are disclosed to users, consequential outputs have a human in the loop, and the AI Act classification is done.
• The incident steps are written down, the reporting channel is known, and the sentence "no sanction for reporting" is in the policy.
• The policy has an owner and a quarterly review date in the calendar.