Copilot and other AI code tools: what companies must know

If your company’s developers use "GitHub Copilot", "Cursor", "Tabnine", or any other AI code tool, you are already a deployer of AI systems under the EU AI Act and must take measures to support the development of AI literacy among your staff and manage the use of these tools. This applies even if your company has only one developer. AI code tools are not exempt from regulation - in fact, they introduce specific risks that the rules governing "ChatGPT" conversations do not fully cover.

For a small Lithuanian company allowing employees to generate code with AI, three things are essential to understand: what obligations arise, what risks exist in intellectual property and security, and what records can help demonstrate the measures taken. For a broader view of software development companies, read separately how the EU AI Act applies to IT companies.

Does Copilot in a company fall under the EU AI Act?

Yes. "GitHub Copilot" and similar code assistants are general-purpose AI (GPAI) systems based on AI models, so they fall under the scope of the EU AI Act (Regulation (EU) 2024/1689). However, the key point is to understand your company’s role: you are not an AI provider (manufacturer), but a deployer - the entity using AI in your professional activities.

For deployers, the primary obligation already in force is AI literacy under Article 4, applicable since 2 February 2025. This article requires deployers to implement measures to foster the AI literacy of staff and other relevant persons, taking into account their knowledge, experience, training, the context of use, and the persons affected. It does not require guaranteeing a specific or sufficient individual level of literacy. In practice, this means that even if your team consists of just two developers using "Copilot" daily, your company already has an obligation whose non-compliance could become an issue during an audit or client review. In this regard, AI code tools are no different from any other AI system - the same basic rules apply.

Timeline to keep in mind:

In other words, if you are waiting for "everything to come into force" - you are already late, as the AI literacy obligation has been in effect for over a year.

How do AI code tools differ from simple "ChatGPT"?

Many companies treat AI code tools the same as a chatbot. This is a mistake. Code assistants have several specific characteristics that require separate rules from those described in the article on ChatGPT use in companies:

• They see your codebase. To suggest the right code, the tool often sends surrounding context to the server - adjacent lines, file contents, sometimes the entire project. This could include trade secrets or client intellectual property.
• They generate production-ready code, not drafts. A human still reviews and edits ChatGPT text. AI-generated code often enters production almost unchanged, so errors and security vulnerabilities spread directly into the live system.
• They pose licensing risks. The model is trained on public code, including code with strict licenses (e.g., GPL). A generated fragment could theoretically replicate licensed code.
• They are deeply integrated. The tool operates directly in the editor (IDE), so it is used almost without conscious decision - on "autopilot".

What are the main risks of using AI code tools in a company?

In practice, small companies face four key risks. It is worth listing them and having a clear answer for each:

1. Leakage of confidential data. If a developer works on a client system, client-owned code, API keys, passwords, or personal data may end up on the AI server. This also relates to GDPR requirements in the AI context if the code contains real personal data. In companies, the ban usually applies not to all AI tools, but to those that are unapproved or lack assessed safeguards - each case must be evaluated individually.

2. Security vulnerabilities in generated code. Research shows that a significant portion of AI-generated code contains vulnerabilities (e.g., SQL injection, insecure data handling). Without review, such code becomes an open door for attackers.

3. Intellectual property and licensing risks. A generated fragment may resemble licensed open-source work, creating legal uncertainty about the ownership of your product.

4. Over-reliance (automation bias). A developer, especially a junior one, may accept an AI suggestion without understanding what it does. This is where AI literacy becomes not just a formality, but a real safeguard.

These risks are not theoretical. In a small company, one carelessly pasted configuration file with login credentials into an AI tool, or one unchecked but vulnerable authentication function, can cost more than an annual license for all AI tools. The key point is that responsibility for the consequences remains with the company, not the AI provider - so risk management must be in the company’s hands, not the tool’s.

How can a company practically manage AI code tools?

A micro-company does not need corporate-scale policies. It needs a few clear, enforceable rules that every developer understands. Here is a minimal set:

• Define what can and cannot be fed into AI. For example: no client trade secrets, no passwords or .env files, no real personal data. Use the tools’ "business" plans, which do not train the model on your code, and enable appropriate privacy settings.
• Mandate human review. AI-generated code must go through code review just like human-written code. Responsibility for the code remains with the person, not the tool.
• Train the team. AI literacy training must cover the specific risks of code tools, not just a general "what is AI". Developers must be able to recognize when AI is "hallucinating" or suggesting an unsafe solution. Important: The EU AI Act does not require a specific duration of training, certificates, external trainers, audits, or a dedicated AI officer. These are recommended but not mandatory.
• Inventory the tools. Include every AI code tool used in the AI tools register, along with its purpose, responsible person, and risk assessment.
• Check license compliance. Use tool settings to block suggestions that match public code, if such a feature is available.

It is important that these rules are not abstract but tailored to your actual workflow. For example, if you work with a financial sector client, the rule "no real data in AI tools" should be linked to a specific requirement to use only synthetic test data. If you are creating a product to sell, licensing becomes critical - it is worth introducing a rule that any larger AI-generated block is flagged for review for potential overlap with open-source works. A good rule of thumb: if you cannot calmly explain to a client or auditor how a specific piece of code originated, then the process lacks control.

What documents can help a company organise its AI use?

Even a small software development company should have the same set of compliance documents as any other AI deployer. The only difference is that the content is adapted to the specifics of code tools. The EU AI Act does not require documents to be in a specific format or contain particular content - this is recommended but not mandatory.

• AI usage policy - describing how code assistants may be used, what data is prohibited, and how reviews are conducted.
• AI tools register - listing all AI code tools used and their risk categories.
• Compliance record under Article 4 - evidence that staff have been trained (e.g., training protocols, certificates).
• Employee AI guide - practical rules for developers’ daily work.
• AI literacy training with knowledge checks - to have documented proof that the team understands the risks.

You do not need to create these documents from scratch. nebedirbam.lt automatically prepares this entire set for a fixed €149 + VAT (€299) price, tailored to your company’s needs - from policy to training with certificates (see homepage). If you first want to train your team, there are also free AI literacy courses. The free path is for one signed-in participant; team training is included in the paid documentation package.

It is important to emphasize: these documents and training are practical measures, but they do not guarantee legal compliance with the EU AI Act.

Frequently asked questions

Do I need documents if only one developer uses AI? Yes. Article 4 of the EU AI Act does not make exceptions based on company size - the obligation to take proportionate AI literacy measures can apply even to a one-person business.

Can I just ban AI code tools and do nothing? You can, but in practice, this is difficult to enforce - developers may find ways to use them personally, leading to uncontrolled, undocumented usage. It is worth being aware of the "shadow AI" problem before imposing a ban.

Does using an AI code tool make me a "high-risk" AI system provider? Usually not. By using the tool for your work, you are a deployer. High-risk provider obligations arise only if you create and supply an AI system for certain regulated areas - this is discussed in the article on the AI Act for IT companies.

Does the EU AI Act require certificates, a specific document set, fixed training hours, external audits, or a dedicated AI officer? No. The Act does not require a specific training duration, certificates, external trainers, audits, or a dedicated AI officer. These may be useful, but they are not mandatory.

For more practical articles on EU AI Act compliance, see the full list of articles.

---

Legal basis for this article: EU AI Act Article 4 and EU AI regulatory framework.