A policy that lists tools goes stale every time a new assistant, browser extension or meeting transcriber appears. A policy that classifies data still applies to tools nobody has heard of yet. Its rule is simple: before content leaves your machine, know its class and check that the destination is approved for that class.
Most organisations already have a data classification scheme for documents. Reuse it rather than inventing a parallel one for AI, and add the categories engineering needs: source code, credentials, and code owned by someone else.
Data classes and where each may go
A worked mapping, to adapt rather than copy:
| Class | Examples | Approved hosted tool under enterprise terms | Tool inside your own boundary | Nowhere |
|---|
| Public | Open-source code, published docs | Yes | Yes | |
| Internal | Most first-party source, internal designs, non-sensitive logs | Yes | Yes | |
| Confidential | Core algorithms, security code, unreleased product plans | Only where the repository tier allows it | Yes | |
| Restricted | Customer personal data, production data, regulated records | | Only if privacy has approved that use | Default |
| Credentials | Keys, tokens, connection strings, certificates | | | Always |
| Third-party owned | Client code in a services engagement, partner code under NDA | Only if the contract permits it | Only if the contract permits it | Default until confirmed |
Two details make this work. The tier attaches to a repository, not to the company, so one estate can hold all three cases. And "source code" is rarely only code: fixtures hold real customer records, configuration holds credentials, and comments name customers. Engineering has to audit a repository before tiering it as internal.
Approval is a joint decision. Security and procurement collect the facts; legal interprets them. The questions to answer before any tool is approved:
- What the provider retains, for how long, and whether you can have it deleted.
- Whether your prompts or code are used to train or improve any model, and whether that is off by default or by contract.
- Where processing happens, and which sub-processors are involved.
- What breach notification the contract promises.
- What the terms say about ownership of output and any indemnity against claims that output infringes someone else's rights.
- Whether accounts sit under single sign-on with admin controls and audit logs.
Free and consumer tiers frequently carry different terms from enterprise agreements. Engineers need to know which tier they are approved on, and the policy needs someone who rechecks terms when the vendor changes them. Cross-border processing raises its own questions, set out in adding an AI provider in another country.
Intellectual property in both directions
What goes in can be someone else's. In a services firm or a captive centre working on a parent company's code, the client or parent contract governs what may be shared, and silence is not permission. The default for third-party code is "not permitted until confirmed".
What comes back has its own uncertainty. Whether generated output can be owned, and who bears the risk when it closely reproduces licensed code, are unsettled questions whose answers vary by jurisdiction. You do not resolve them in an engineering policy. You name legal as the owner, and you put engineering controls in place while the questions stay open: licence scanning on first-party code, extra care in software you distribute, and attention to long, distinctive generated blocks.
Exceptions, with an owner and an expiry
Someone will need to send restricted data to a tool for a legitimate reason, such as a support investigation. Give exceptions a short form: what data, which tool, why, who approved it, and when it expires. An exception without an expiry becomes the policy. A quarterly list of open exceptions is often the most useful page security reads.
Enforcement that assumes people will paste
Training explains the policy. Controls enforce it.
- Approved tools only through single sign-on, so usage sits under the enterprise terms.
- Network or browser controls on unapproved AI services, where your environment allows them.
- Secret scanning before commit and in CI, plus data-loss controls where you already run them.
- Agents that can read repositories, browse or run commands treated as a separate class, with limited permissions and no production credentials.
- An incident route for a pasted secret that makes reporting quick and blameless. The response is rotation within hours, not a disciplinary meeting.
If reporting a mistake is punished, people stop reporting, and you lose the signal the policy depends on.
A blanket ban is the leakiest policy
The adequate answer lists what is forbidden. The strong answer notices what a ban does. Engineers who find the tools useful keep using them on personal accounts and phones, under consumer terms you have not reviewed, with no logging and no way to rotate what leaked. The ban looks safe on paper and pushes data to the least controlled place available. An AI usage policy that offers an approved route for most work, and saves the hard "never" for credentials and restricted data, reduces exposure. Interviewers listen for that reasoning, because it shows the candidate thinks about behaviour rather than wording. The individual habits that should sit underneath the policy are in how you use AI tools and when you refuse to trust them.
Who signs it, and what varies by country
Security, legal, the privacy or data-protection officer and engineering leadership should all sign. Data-protection law differs by jurisdiction: the GDPR in the EU and its UK equivalent, India's Digital Personal Data Protection Act, and sector regulators in finance and health all shape what "restricted" must mean in your data classification. A global organisation usually sets one baseline and lets local legal teams tighten it. In some countries, monitoring how employees use tools can also require consultation with employee representatives. None of these calls is engineering's alone; your role is to make sure they are made before rollout, as part of the plan in rolling out AI coding assistants.
Classify the data, approve destinations per class, and make the safe route the easy one; an AI usage policy that only forbids pushes the data somewhere you cannot see.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).