AI coding assistant policy: code classes, vendor terms, licences of generated code, AI Act

What an AI coding assistant policy has to settle

An AI coding assistant policy tells developers which code they may give to which tool, under which account, and how generated code is checked before it ships. It settles four questions: the classes of code and the tools each class may reach, what each vendor's terms say about training and retention, the copyright and licences of generated code, and the company's duties under the EU AI Act. A coding model on your own server removes the vendor questions on training and retention and leaves the licence review in place.

This guide is for CTOs, heads of development, legal counsel and data-protection officers who write or update such a policy, and for the IT team that enforces it. Our article on shadow AI and an AI usage policy covers chatbots and other AI tools across the whole company; this page covers what is specific to code: repositories, secrets, customer code, agents that run commands, and the licences of what a model writes. It is general information as of October 2026, not legal advice; your legal counsel confirms how it applies to your contracts and products, and your data-protection officer confirms the rules for personal data.

Which code may go to which tool

A policy works when developers can apply it without asking. Classify code by who owns it and what it contains, then decide per tool and account type. The table is an example; the decisions are yours.

An example policy; "business plan" means a company contract with the vendor, such as Copilot Business or Claude Team. The rows on customer code and personal data need your legal counsel and data-protection officer.

Secrets need their own rule because agents read whole directories. An agent asked to fix a build may open an .env file or a deployment script and send it to the model with the rest of the context. Keep secrets out of repositories, configure each tool's ignore or deny lists where it has them, and treat a key that reached any external service as compromised and rotate it. Customer code is the second trap. Whether a customer's code may go to a cloud provider is a question of the contract that came with it, which our article on trade secrets, NDAs and AI tools works through.

A coding agent runs commands with the developer's rights, and text in a repository, an issue or a web page can carry instructions the agent follows. The policy should say where agents may run, for example only in development containers without production credentials, and which commands need approval. Our article on prompt injection and LLM security describes the attack.

Copilot, Claude Code and Cursor terms on training and retention

Terms change, and the account type decides more than the vendor. We read the vendors' current pages on 30 October 2026.

GitHub blog "Updates to GitHub Copilot interaction data usage policy" (25 March 2026); Claude Code documentation "Data usage"; Cursor "Data Use" page (last updated 3 September 2026); all read on 30 October 2026. Quotes and details in the text.

GitHub Copilot. GitHub's announcement of 25 March 2026 says that from 24 April interaction data from Copilot Free, Pro and Pro+ will be used to train and improve its models unless the user opts out. That data includes inputs, outputs, code snippets, the code around the cursor, file names and repository structure. GitHub adds that "Copilot does process code from private repositories when you are actively using Copilot", and that the data may be shared with companies in GitHub's corporate family but not with third-party AI model providers. "Copilot Business and Copilot Enterprise users are not affected by this update." So company code belongs on company accounts: a personal plan puts it under these terms.

Claude Code. Anthropic's documentation states that under commercial terms (Team and Enterprise plans, the API and third-party platforms) "Anthropic does not train generative models using code or prompts sent to Claude Code under commercial terms, unless the customer has chosen to provide their data to us for model improvement". Zero data retention is available to qualified Claude for Enterprise accounts, enabled per organisation. Consumer accounts follow the user's setting: training and 5 years' retention when it is on, 30 days when it is off. The client also keeps session transcripts in plaintext under ~/.claude/projects/ for 30 days by default, so laptops become part of the retention question. A report sent with the /feedback command includes the conversation and its code and is kept for 5 years; DISABLE_FEEDBACK_COMMAND=1 switches the command off.

Cursor. Cursor's data-use page says: "Even if you use your API key, your requests will still go through our backend!" With Privacy Mode on, "Customer Data will not be used for training by Cursor", and Cursor "maintains zero data retention (ZDR) agreements with all providers". With it off, Cursor may use and store codebase data, prompts, editor actions and code snippets. Our article on Cursor with a local model covers a self-hosted model behind Cursor.

Copilot CLI has a documented offline mode with a model you host, in which "No GitHub authentication is attempted" and telemetry is fully disabled, as our comparison of self-hosted Copilot alternatives sets out; our guide to Claude Code with a local model describes the same route for Claude Code.

We set up Cline or Kilo Code against a model on your own server; ask us which setup fits the tools your developers already use.

Copyright and licences of AI-generated code

EU law protects software through Directive 2009/24/EC. Article 1 protects computer programs "by copyright, as literary works", and Article 1(3) states: "A computer program shall be protected if it is original in the sense that it is the author's own intellectual creation." Article 2(1) names as author the natural person or persons who created the program or, where national law permits, the legal person it designates as rightholder, and under Article 2(3) the employer exclusively is entitled to exercise all economic rights in a program an employee creates in the execution of their duties or following the employer's instructions, unless a contract provides otherwise. It does not address code generated with AI. How far a developer's prompts, choices and edits make the result their own intellectual creation is a question for your legal counsel, and national law and courts may differ.

The policy can work without settling that question: the developer who commits code is responsible for it, whoever or whatever drafted it, and it goes through the same review and tests as any other change. A trailer in the commit message that marks AI-assisted commits takes seconds to add and helps if a question comes up later.

The licence question is more practical. A suggestion can match code from a public repository, and that code may come under an open-source licence with conditions, for example on distribution, which your legal counsel assesses. GitHub's code referencing addresses this in its cloud: when a suggestion matches public code, Copilot shows the licence type and the URL of the matching file, and organisations can set suggestions matching public code to "Block". A self-hosted open model has no such filter. Its licence does not help either: Qwen3-Coder and gpt-oss come under Apache 2.0, which provides the work on an "AS IS" basis, "WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND", and says nothing about outputs. Our comparison of open LLM licences for company use covers the other model licences.

The policy therefore moves the check into your pipeline. A licence scanner such as ScanCode Toolkit (Apache-2.0), which "detects licenses, copyrights, package manifests, direct dependencies", finds licence texts and notices by comparing your code with a database of licence texts. Its README does not claim to find fragments copied without their licence notice, so ask your software composition analysis vendor whether it matches snippets. Add two rules for developers: third-party code comes in as a declared dependency through the package manager, never pasted from a model's answer, and prompts do not ask the model to reproduce a named library. If a vendor's business terms offer a defence against third-party IP claims over output, read the conditions with your legal counsel; with a self-hosted model, no vendor stands behind the output.

The EU AI Act for development teams

A company whose developers use a coding assistant is a deployer under the AI Act, which Article 3(4) defines as a person or body "using an AI system under its authority". Article 4 has applied since 2 February 2025. In the version amended by the Digital Omnibus on AI, Regulation (EU) 2026/1744, in force since 27 July 2026, it requires providers and deployers to "take measures to support the development of AI literacy of their staff". For developers, useful topics are invented APIs and packages, insecure suggestions, instructions hidden in repository content and the licence rules above. Our guide to AI literacy training under Article 4 sets out content and records.

Teams that build AI into their own software can become providers, in Article 3(3) a body that develops an AI system or has it developed and places it on the market or puts it into service under its own name or trademark. While the work is still development, Article 2(8) states that the Regulation "does not apply to any research, testing or development activity regarding AI systems or AI models" before they are placed on the market or put into service, and adds that "Testing in real world conditions shall not be covered by that exclusion." Our EU AI Act guide for companies using LLMs covers the deployer duties and dates, and our article on fine-tuning and provider status covers modified models. A self-hosted assistant raises one more question for your legal counsel. Article 3(11) counts the supply of an AI system "for own use in the Union" as putting it into service, so a company that assembles its own assistant from an open model, a gateway and a tool such as Cline may count as its provider as well as its deployer.

Article 53(1) also requires providers of general-purpose AI models to have a policy to comply with Union copyright law and to publish "a sufficiently detailed summary about the content used for training". Under Article 53(2) a release under a free and open-source licence exempts the provider only from the documentation duties in points (a) and (b), so the copyright policy and the training summary apply to open models too. The Act requires only the summary to be made public; where a provider has published either, it is worth reading when you approve a model, and providers of models placed on the market before 2 August 2025 have until 2 August 2027 under Article 111(3).

How a self-hosted model simplifies the policy

With the model on your own server, the table above collapses to one decision per class: everything except secrets may go to the internal model within the developer's access rights, customer code as its contract allows and personal data as the DPO approves. No vendor retains prompts, no setting on a personal account decides about training, and no outside processor enters the chain that a customer contract would have to allow. The log is yours: a gateway with keys and a query log records who called which model, and you decide how long prompts with code are kept and who may read them, an agreement our article on the works council and an internal AI assistant helps to prepare.

What stays: the licence scan, the review of generated code, the secrets rule and AI literacy training. Cline (Apache 2.0) connects to any OpenAI-compatible server, and Kilo Code (MIT) documents Ollama. Kilo Code's documentation states that its autocomplete requests are routed through the Kilo Gateway (read 31 October 2026), so the policy should keep that feature off where code may not leave your network. Claude Code can be pointed at a model on Ollama or vLLM, although Anthropic states that it "doesn't support routing Claude Code to non-Claude models through any gateway"; our guide to Claude Code with a local model also shows how its managed settings pin it to the company gateway.

You can order the server alone, the setup of the model, the gateway and Cline or Kilo Code alone, or both together: the server delivered with everything installed and configured; write to us and we suggest the best solution for your tasks and budget.

Server sizes for a self-hosted coding assistant

The size of the server follows the number of developers who generate code at the same moment. Our guide to a server for coding agents explains the method behind these figures, our users-per-card rule: 90 per cent of the memory the driver reports, less 3 GiB per card, less the weights.

Our estimates as in our comparison of self-hosted Copilot alternatives, not measurements: sessions of 64K tokens with a 16-bit cache (FP8 cache in brackets); the first two rows are memory limits, the last two cap each session at 50 tokens per second from 1,792 GB/s (Workstation Edition, Max-Q) and 1,597 GB/s (Server Edition), an upper bound by our estimate. Weights from Hugging Face: gpt-oss-20b 13.76 GB, Qwen3-Coder-30B-A3B 31.2 GB, Qwen3-Coder-Next 80.4 GB in FP8.

A one-workstation pilot shows before a rollout which tools developers choose, how many generate at once and what the gateway log records. The four-card server is the inference node on our AI servers page, with 768 GB of DDR5 ECC memory, at about 3.4 kW by our estimate. Two Workstation Edition cards are the realistic maximum for that edition, and three or four Max-Q belong only in a chassis built for them with strong directed airflow.

We build these workstations and servers to order; send us your number of developers, the tools they use today and your Git platform, and our team replies with a configuration.

A policy template in twelve clauses

1. Scope. All tools that complete, generate, review or explain code, including agents, CLI tools and AI features of the Git platform.
2. Approved tools and accounts. Only listed tools, on company accounts or the internal model; no personal plans for company code.
3. Code classes. The table above, with the decision per tool.
4. Secrets. Never in prompts or repositories; tool ignore lists configured; any key that reached an external service is rotated.
5. Customer code. Only as the customer contract allows; legal confirms before the first project.
6. Personal data. No real personal data in fixtures, logs or dumps given to a tool, except as the data-protection officer approves.
7. Responsibility and review. The developer who commits is responsible; generated code passes the same review and tests as any other; a review bot on your own server, as in our guide to self-hosted AI code review, adds a second reader.
8. Licences. Public-code filters on where the tool has them; a licence scan in CI; third-party code only as declared dependencies.
9. Agents. Run in development containers without production credentials; commands that change systems need approval.
10. Logging. What the gateway records, how long it is kept, who may read it and which feedback and telemetry functions of the tools stay on, agreed with the data-protection officer and workers' representatives where they exist.
11. Training. AI literacy measures per role before access, with an internal record.
12. Review cycle. Vendor terms are checked again at a fixed interval and after every announced change, as GitHub's change of April 2026 shows.

FAQ