GitHub Copilot Under the EU AI Act: Minimal Risk, Real Governance

GitHub Copilot is a coding assistant built on GPAI models (OpenAI's Codex lineage, distributed by GitHub/Microsoft). Most organisations deploying it for internal software development face minimal risk under Regulation (EU) 2024/1689 — the EU AI Act. The tool does not appear in Annex III, is not a prohibited practice under Article 5, and ordinary internal dev use does not trigger the Article 50 transparency duties that apply to chatbots or emotion-recognition systems.

That does not mean you can ignore it. Inventorying the tool, recording the classification reasoning, applying Article 4 AI literacy requirements, and managing the real engineering risks — IP exposure, generated-code security, secrets leakage — are all legitimate obligations. This guide explains what the Act actually requires, where the real governance work sits, and what a correct compliance record looks like.

---

Why Copilot Is Not High-Risk Under the EU AI Act

High-risk classification flows from Article 6 and the Annex III list. Annex III covers eight specific areas: biometrics; critical infrastructure safety components; education and vocational training; employment and worker management; access to essential private and public services; law enforcement; migration and border control; administration of justice and democratic processes.

A coding assistant used for internal development fits none of these categories. It does not make decisions about individuals. It does not profile natural persons. It does not determine creditworthiness, screen job applicants, or manage border crossings. It suggests the next line of code.

Article 6(3) provides a further filter: even a system that nominally falls in an Annex III area is not high-risk if it does not pose a significant risk of harm to health, safety or fundamental rights — for example, if it performs a narrow procedural task without replacing or influencing human assessment. Copilot, used in its standard form, would clear that filter even if one tried to argue an Annex III link. In practice, no credible reading of the Act puts a general-purpose code-completion tool in the high-risk tier.

The bottom line for classification: for the deploying organisation, Copilot is minimal risk (the Act's lowest tier, carrying no mandatory obligations beyond those that apply to all AI systems).

The Hypothetical High-Risk Exception

There is one scenario where the classification shifts: if your organisation builds a product whose core function falls within Annex III — say, a recruitment system that screens CVs — and you embed Copilot so deeply in that product's decisional logic that Copilot itself becomes the AI system performing the Annex III function, then the relevant AI system (the recruitment screener, not Copilot per se) is high-risk, and whoever places it on the market bears the full provider obligations under Articles 9–17, 43, 47, 49.

That is not a story about Copilot the tool. It is a story about what you built with it. The coding assistant that helped write the recruitment model is not itself the high-risk system; the recruitment model is. Classify by function, not by the tools used to write the code.

---

What the Act Does Require for Copilot

Article 4 — AI Literacy (in force since 2 February 2025)

Article 4 requires providers and deployers to take measures to ensure sufficient AI literacy among staff and others who operate AI systems on their behalf. This applies regardless of risk tier. Developers using Copilot should understand what it does, what it does not do, how it generates suggestions, and where it can go wrong (plausible-sounding but incorrect code, reproduced patterns from training data, potential security anti-patterns). Document the literacy measures you have in place: an internal briefing, onboarding materials, a usage policy. These are proportionate, low-effort steps that satisfy Article 4 for a minimal-risk tool.

Inventorying the Tool

Good governance — and Confir's core workflow — starts with getting Copilot into your AI register. That means recording what it is, what it does, who uses it, and what risk tier it lands in. For Copilot, that entry should capture:

• Tool: GitHub Copilot (provider: GitHub, Inc./Microsoft)
• Function: Code suggestion and completion
• Deploying role: Deployer (Article 26) — you use a third-party AI system under your authority
• Risk classification: Minimal (Article 6 and Annex III: no match; Article 5: not prohibited; Article 50: no trigger for standard internal dev use)
• Classification reasoning: documented, so an auditor or regulator can follow the reasoning without you having to reconstruct it

Recording the reasoning is not bureaucratic excess. If a regulator ever asks why you did not treat Copilot as high-risk, a contemporaneous register entry showing the Article 6 analysis is far more defensible than a verbal assertion.

GPAI Context: Where Provider Obligations Sit

Copilot is built on GPAI models. The Act's GPAI obligations (Articles 51–55, in force since 2 August 2025) fall on the GPAI provider — in this case GitHub/Microsoft/OpenAI — not on organisations that use Copilot to write code. The downstream deployer does not inherit GPAI provider duties simply by using a tool built on a foundation model.

What you should verify is that GitHub/Microsoft has complied with its Article 53 obligations: publishing a copyright policy for training data, providing downstream technical information, and maintaining a summary of training data. GitHub has published a usage policy and technical details on Copilot. Review this documentation and note it in your register — it is part of due diligence under Article 26, which requires deployers to use high-risk systems in accordance with the provider's instructions. For a minimal-risk tool this is advisory rather than strictly mandatory, but it is good practice.

---

The Real Governance Concerns for Copilot

The EU AI Act is largely silent on what actually keeps legal and IT teams up at night with Copilot. These concerns are real, but they sit in adjacent legal regimes, not the AI Act's risk hierarchy.

IP and Open-Source Licence Exposure

Copilot is trained on public code repositories, including code under various open-source licences. There is ongoing legal uncertainty — including litigation in the United States — about whether Copilot suggestions reproduce training-data code verbatim and whether that reproduction creates licence obligations. The Copilot interface has a "duplication detection" filter that can be enabled to flag suggestions that match training data; this reduces but does not eliminate the risk.

Governance actions: enable duplication detection, include AI-generated code in your IP screening process, define in your internal policy whether developers must disclose when significant blocks of code were Copilot-sourced. This sits in copyright and IP law, not the EU AI Act.

Security of Generated Code

Code-completion models can suggest syntactically correct but insecure patterns — SQL injection vulnerabilities, missing input validation, hardcoded placeholder credentials that developers forget to replace. The National Cyber Security Centre (UK) and similar bodies have flagged this as a practical risk for development teams relying heavily on AI assistance without mandatory security review.

Governance actions: require static analysis (SAST) tooling on Copilot-assisted code before production merge; include AI-generated code in your standard code review; make explicit in your internal security policy that Copilot suggestions are not pre-vetted for security. These controls belong in your engineering security practice, not an EU AI Act conformity package.

Secrets Leakage

Developers sometimes paste context — including environment variables, API keys, or configuration snippets — into the Copilot prompt window or in comments near Copilot-assisted code. This data is sent to GitHub's servers. If that context contains secrets, you have a data-handling risk.

Governance actions: configure your IDE or GitHub settings to limit data sent to Copilot where possible; include Copilot in your secrets-management policy; brief developers explicitly on this risk as part of the Article 4 literacy measures. Copilot for Business and Copilot Enterprise both offer policies to limit data retention and block certain transmission; verify your tier's settings.

Internal Policy: Usage Scope and Review Requirements

Most of the practical governance for Copilot resolves into a usage policy: which contexts Copilot is approved for, what review is required before Copilot-assisted code merges, how IP and security are handled, and who is accountable. This policy does not need to reference the EU AI Act (because minimal-risk tools carry no mandatory Act obligations). It should exist because responsible engineering practice requires it.

---

How to Classify Copilot: A Short Worked Example

A 60-person software company builds SaaS tools for professional services firms. Developers use Copilot daily for internal feature development, test generation, and refactoring. The company has no products in Annex III territory.

Classification walk-through under Article 6:

1. Article 5 prohibited practices — Copilot is not a social scoring system, subliminal manipulation tool, or real-time biometric identifier. Not prohibited.
2. Article 6(1) — Copilot-generated code is not embedded in a product subject to Annex I harmonisation legislation (e.g., medical devices, machinery). Not applicable.
3. Article 6(2) and Annex III — The tool does not perform any of the eight Annex III functions. Not high-risk.
4. Article 50 — Copilot is not a chatbot interacting with end-users, does not generate synthetic media, does not use emotion recognition. No limited-risk transparency duty in standard dev use.
5. Result: minimal risk.

The same company then builds a new product: an automated CV screening module sold to HR teams. The CV screener is high-risk under Annex III point 4(a) (recruitment and selection of natural persons for employment). The CV screener's provider must comply with Articles 9, 10, 11, 13, 14, 15, 16, 43, 47, and 49 before the product reaches customers, with the high-risk deadline of 2 December 2027 under the Digital Omnibus agreed in May 2026. The fact that the CV screener's code was written with Copilot's assistance is irrelevant to its classification. Copilot remains minimal risk in your register; the CV screener gets its own entry as a high-risk system in development.

---

How Confir Helps

Confir's intake workflow walks through the Article 5 and Article 6 questions in plain language, derives the minimal-risk classification for Copilot, and records the reasoning against the relevant articles — creating an audit-ready register entry without requiring you to interpret the regulation yourself. Because the classification logic is rule-based and deterministic, the same answers produce the same finding: no discretion, no hallucination, no ambiguity about which rule fired.

For organisations with a mixed portfolio — some tools clearly minimal, others requiring closer examination — Confir's register gives you the full picture in one place, with each tool's classification and the reasoning documented.

---

Frequently Asked Questions

Is GitHub Copilot high-risk under the EU AI Act?

No. For an organisation using Copilot for internal software development, the tool is minimal risk under the EU AI Act. Coding assistance does not appear in Annex III, is not a prohibited practice under Article 5, and does not trigger the Article 50 limited-risk transparency duties that apply to chatbots or synthetic-media tools. The classification could shift only if Copilot's output became the decisional core of a product performing an Annex III function — in which case the product (not Copilot) would be the high-risk system.

What obligations does the EU AI Act actually impose on Copilot deployers?

The main Act obligation is Article 4 AI literacy, in force since 2 February 2025: deployers must ensure staff who use AI systems have sufficient understanding of the technology and its risks. For a minimal-risk tool, this is proportionate — an internal policy or onboarding briefing is adequate. Beyond literacy, the practical compliance step is registering the tool in your AI inventory with a documented classification rationale, so the reasoning is on record.

Where do GitHub's GPAI provider obligations fit?

Copilot is built on GPAI models. The Act's GPAI obligations under Articles 51–55 (in force since 2 August 2025) apply to the GPAI provider — GitHub/Microsoft/OpenAI — not to your organisation. GitHub must maintain technical documentation, publish a copyright policy for training data, and provide downstream information to business customers. Your obligation as a deployer is due diligence: check that GitHub has published the relevant documentation, and note this in your register. You do not inherit Article 53 provider duties by using the tool.

What are the real compliance risks with Copilot if not the AI Act?

Three areas: (1) IP and open-source licence exposure — suggestions may reproduce training-data code, potentially triggering licence obligations; enable Copilot's duplication detection and screen generated code during your IP review process. (2) Security of generated code — AI-generated suggestions can include insecure patterns; apply static analysis tooling and require code review before production. (3) Secrets leakage — context sent to Copilot's servers may include API keys or credentials; include Copilot in your secrets-management policy and brief developers explicitly.

Does using Copilot to build a high-risk AI system make Copilot itself high-risk?

No. The relevant classification is of the AI system you build and deploy, not the tools used to write its code. If you build an automated recruitment screener (Annex III point 4(a)), that screener is high-risk and you bear the provider obligations for it. Copilot — the coding tool used during development — remains minimal risk in your register. Classify by what the system does, not how it was written.

When is the compliance deadline for minimal-risk AI tools like Copilot?

The EU AI Act's mandatory high-risk obligations (Articles 9–17, conformity assessment under Article 43, registration under Article 49) apply from 2 December 2027 for stand-alone Annex III systems, under the Digital Omnibus agreed in May 2026. These obligations do not apply to minimal-risk tools at all — not in 2027 and not now. Article 4 AI literacy has applied since 2 February 2025. General application of the Act, including Article 50 limited-risk transparency duties, applies from 2 August 2026. For Copilot as a minimal-risk tool, the practical action is AI literacy documentation and register entry — both achievable now.

Do we need a Fundamental Rights Impact Assessment (FRIA) for Copilot?

No. Article 27 FRIAs apply to deployers of high-risk AI systems in specific circumstances (public bodies deploying high-risk systems; deployers of certain creditworthiness or insurance systems). Copilot is minimal risk. No FRIA is required.

---

Related guides

• Article 6 risk assessment framework
• Articles 9 & 11 compliance obligations
• EU AI Act risk classification levels
• Annex III risk management tools
• Article 3 compliance definitions
• critical infrastructure safety requirements