Does the EU AI Act Apply to Internal AI Tools?

Internal use is not an exemption

A common assumption in regulated enterprises is that a copilot, coding assistant or employee-facing agent sits outside the EU AI Act because nothing is offered to customers or the public. The text does not support that assumption as a general rule.

The exclusions in the Act are specific. They include AI systems not placed on the market or put into service in the Union whose output is used in the Union exclusively for military, defence or national security purposes. They also cover deployers who are natural persons acting in a purely personal, non-professional capacity. Free and open-source licensed AI systems are excluded too, unless they are placed on the market or put into service as high-risk systems or as systems under Article 5 or Article 50. An employer's internal tool fits none of these by default.

The nearest thing to an internal-use carve-out is a recital on models. It says obligations for models should not apply when an organization uses its own model for purely internal processes that are not essential for providing a product or service to third parties, and the rights of natural persons are not affected. Three points limit it. It is stated for models, not AI systems. It carries conditions. And the same text says the rules for models apply in addition to the rules for AI systems. Teams relying on this recital should confirm which obligations they actually rely on it for, because it does not remove system-level duties.

Provider, deployer, or both

The Commission's FAQ frames obligations around two roles. Providers build the tool, for example the developer of a CV-screening tool. Deployers use it, for example a bank using that tool. Providers of general-purpose AI models carry their own obligations as well.

For internal tools, the answer is often mixed. An organization that licenses a third-party copilot and gives it to staff is plainly using it. An organization that builds an internal agent, or configures a system for its own employees, may need to examine whether it also holds the provider role. The Act's definitions of AI system, provider, deployer and putting into service decide this, and the outcome should be read from the full text for each tool rather than assumed.

Treat role determination as a governance task. Assign an accountable owner per tool, record the reasoning, and version the decision so it can be revisited when guidance changes.

Which obligations follow, and when

Obligations depend on the use case, not on whether the audience is internal. Two layers matter most for internal tools.

The first is prohibited practices. The prohibitions and general provisions have applied since 2 February 2025, and every internal use case should be checked against Article 5. The Act as a whole applies from 2 August 2026, when enforcement powers also begin. Enforcement is shared between the Commission's AI Office, the European Data Protection Supervisor and national competent authorities. A further prohibition, on generating or manipulating non-consensual intimate material and CSAM, applies from 2 December 2026.

The second is high-risk classification. The Commission lists AI tools for employment, management of workers and access to self-employment, such as CV-sorting software for recruitment, among the high-risk uses. An internal HR assistant that ranks candidates or informs decisions about workers sits in this area, while a general drafting assistant usually does not. The Commission has published guidelines for providers and deployers of high-risk systems, with practical examples, to help with classification.

Timelines have moved. The Digital Omnibus on AI was proposed on 19 November 2025 and set fixed dates, and the Council and Parliament reached a provisional agreement on 7 May 2026. Commission pages dated October 2026 state that rules for high-risk systems in areas including employment apply from 2 December 2027, and rules for systems embedded in regulated products from 2 August 2028. As of November 2026, plan to those dates and confirm the adopted amending text before relying on them. The Commission also notes that AI Act rules apply in addition to any workers' consultation rules that already exist.

Where evidence matters most

Some obligations can be met largely by documentation. Others depend on what happens during use. The text requires high-risk AI systems to be designed and developed, including with appropriate human-machine interface tools, so that natural persons can effectively oversee them while in use. Oversight that cannot be shown to have occurred is hard to defend.

The following is practical inference rather than a statement of what a regulator will require. A policy document describes intent. A per-interaction record shows that a specific policy was applied to a specific prompt or tool call, and whether the result was allowed, redacted, blocked or escalated to a person. For escalated actions, the record should also capture who approved or rejected the action, when, and how that decision is retained and retrieved.

Tagging each internal interaction with its use case adds a second benefit. It lets a team separate employment-related, potentially high-risk uses from general productivity use, and apply stricter handling to the former. Details such as deployer log content, retention periods and incident reporting should be taken from the full text of the relevant articles before any retention design is fixed.

The tradeoff is scope. Enforcement at runtime only covers traffic that passes through the control point, so the inventory step is what tells you which tools and tool calls are outside it.

Where Trussed fits

Trussed is relevant to one part of this problem: showing that controls were applied to internal AI use. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Enforcement happens at the level of individual interactions and tool calls, with actions to allow, redact, block, rate limit or escalate for human approval. Enforced at runtime, not reviewed after the fact, each decision produces audit-ready evidence, which is mapped to the EU AI Act among other frameworks.

This does not determine your role or risk tier. Those judgments remain with your compliance team, and the evidence supports them rather than replacing them. Trussed does not certify compliance. It can be self-managed in your cloud, with configurable retention and data residency, which matters when evidence must stay inside defined boundaries. It has run for 18+ months in continuous production in a regulated enterprise and supports 100+ models under one policy plane.