EU AI Act and Self-Hosted LLMs: Provider or Deployer?
Self-hosting an LLM for staff makes you a deployer under the EU AI Act, and building it yourself makes you a provider too. No internal-use or on-premise exemption.
The EU AI Act applies to internal, self-hosted LLM deployments: running an open-weight model on your own hardware for your own staff makes your organisation a deployer under Article 3(4), and assembling the system yourself usually makes you a provider as well. There is no internal-use exemption and no on-premise exemption. Scope follows the role you play and the purpose the system serves, not where the GPUs sit. Of the two obligations that bite hardest for internal deployments, Article 50 transparency applies from 2 August 2026, while the Annex III high-risk regime now applies from 2 December 2027 after the July 2026 amendments to the Act.
This post is general information about Regulation (EU) 2024/1689 (the AI Act), as amended, traced to its articles. It is not legal advice. Confirm your own position with counsel.
Does the EU AI Act apply to an LLM you run on your own servers?
The EU AI Act applies to a self-hosted LLM because Article 2 defines scope by role and territory, not by hosting model. A deployer under Article 3(4) is any organisation using an AI system under its own authority in the course of a professional activity. Deployers established in the Union are in scope, as are providers placing systems on the Union market or putting them into service there, and providers and deployers in a third country where the system’s output is used in the Union.
The only relevant carve-out is Article 2(10), which excludes natural persons using AI in a purely personal, non-professional activity. Employees using an internal assistant to do their jobs are doing the opposite of that. Article 2(3) also excludes systems used exclusively for military, defence or national security purposes, and Articles 2(6) and 2(8) exclude systems developed for the sole purpose of scientific research and development and any research, testing or development activity prior to placing on the market or putting into service. So a genuine internal research prototype that is never put into service sits outside the Act until you roll it out.
What applies on 2 August 2026, and what moved to 2027?
2 August 2026 remains the general application date for the AI Act, but parts of the Regulation already bind organisations today, and the heaviest tier has been pushed back.
| Date | What applies |
|---|---|
| 2 February 2025 | Article 5 prohibited practices; Article 4 AI literacy duty on providers and deployers |
| 2 August 2025 | Chapter V general-purpose AI model obligations; governance; Article 99 penalties |
| 2 August 2026 | General application, including Article 50 transparency |
| 2 December 2026 | Content-marking transition ends for generative systems already on the market; new Article 5 prohibitions on generating child sexual abuse material and non-consensual intimate imagery |
| 2 August 2027 | GPAI models placed on the market before August 2025 must be brought into compliance |
| 2 December 2027 | Annex III high-risk regime, and the Article 26 deployer obligations that ride on it |
| 2 August 2028 | High-risk systems embedded in Annex I regulated products |
Article 99 sets penalties at up to 35 million euro or 7 percent of worldwide annual turnover for breaching the Article 5 prohibitions, and up to 15 million euro or 3 percent for breaching most other provider and deployer obligations, including Article 50.
One update on dates. The digital omnibus package the European Commission proposed in November 2025 is now law: Regulation (EU) 2026/1744 was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026. It deferred the standalone Annex III high-risk regime to 2 December 2027 and Annex I embedded high-risk systems to 2 August 2028, softened the Article 4 AI literacy duty into an obligation to take measures supporting AI literacy rather than to guarantee a level, and added the two new Article 5 prohibitions above. Article 50 was not deferred. Deferral is not repeal: the high-risk duties still arrive, and conformity work for an Annex III use case takes longer than the extension buys you.
Are you a provider or a deployer when you self-host?
This is the question internal teams get wrong most often. Article 3(3) makes you a provider if you develop an AI system and place it on the market or put it into service under your own name or trademark. Article 3(11) defines putting into service as the supply of a system for first use “directly to the deployer or for own use”. Own use is the operative phrase: building it for yourself still counts.
| Your situation | Provider (Art. 3(3)) | Deployer (Art. 3(4)) |
|---|---|---|
| You license a finished AI product and run it on your own servers | Vendor | You |
| You download an open-weight model and build a RAG assistant for staff | You | You |
| You wrap a vendor system in your own UI and brand it as yours | You, per Art. 25(1)(a) | You |
| You repurpose a general-purpose system into an Annex III use case | You, per Art. 25(1)(c) | You |
Hosting location does not determine provider status; system authorship does. A team that self-builds an internal assistant and assumes “we are only a deployer” has usually understated its obligations rather than overstated them.
Does the EU AI Act apply to open-source and open-weight models?
The AI Act applies to open-source models, with a narrow exemption. Article 2(12) states that the Regulation does not apply to AI systems released under free and open-source licences, unless they are placed on the market or put into service as high-risk AI systems or as a system that falls under Article 5 or Article 50. The exemption disappears exactly where the risk starts. Article 53(2) separately relieves providers of open-source general-purpose models from some documentation duties, unless the model presents systemic risk.
Two traps follow. First, the exemption protects the release of the model, not your use of it: downloading exempt weights and deploying them for HR screening still puts your deployment in the high-risk regime. Second, many popular open-weight licences impose acceptable-use or scale restrictions, which may put them outside “free and open-source” for Article 2(12) purposes. If licence terms drive your model shortlist, see the Teclops AI guide to choosing an open-weight LLM for on-premise deployment.
When does fine-tuning shift you toward provider obligations?
Fine-tuning an open-weight model for internal use rarely, by itself, makes you a provider of a general-purpose AI model. Chapter V obligations under Article 53 attach when a model is placed on the market, and a fine-tune that never leaves your estate has not been made available to third parties. Recital 109 limits a modifier’s obligations to the modification itself rather than the whole model, and the Commission’s 2025 guidelines on general-purpose AI provider obligations offer an indicative compute threshold, a modification using more than roughly a third of the compute used to train the original model, for when a downstream modifier becomes the provider of a new model. Those guidelines are non-binding.
What does move your role is Article 25. You become the provider of a high-risk system if you put your name or trademark on one (25(1)(a)), make a substantial modification to one (25(1)(b), with “substantial modification” defined in Article 3(23)), or change the intended purpose of a non-high-risk system, including a general-purpose one, so that it becomes high-risk (25(1)(c)).
The mental model: fine-tuning weights rarely changes your legal role. Changing what the system decides almost always does.
Which internal AI use cases are high risk under the EU AI Act?
Work the tiers in order: prohibited (Article 5), high-risk (Article 6 with Annex I and Annex III), transparency-only (Article 50), then minimal. “Limited risk” is common shorthand, not a term the Act defines.
| Internal use case | Likely tier | Trigger |
|---|---|---|
| Inferring employee emotions from face or voice | Prohibited | Art. 5(1)(f); Commission guidance ties it to biometric data, with a narrow medical and safety exception |
| Screening, filtering, or ranking job applicants | High risk | Annex III, 4(a) |
| Promotion, termination, task allocation, performance monitoring | High risk | Annex III, 4(b) |
| Creditworthiness scoring of natural persons | High risk | Annex III, 5(b) |
| Student admissions or evaluating learning outcomes | High risk | Annex III, 3 |
| Internal knowledge assistant over policy and product documents | Minimal, plus Art. 50(1) | Interacts directly with people |
| Meeting summaries, drafting, code assistance | Minimal, plus Art. 50(1) if conversational | No Annex III purpose |
Article 6(3) offers a derogation: an Annex III system is not high-risk if it performs only a narrow procedural task, improves the result of a completed human activity, detects decision patterns without replacing human assessment, or performs a preparatory task, and does not materially influence the outcome. Two conditions apply. Profiling of natural persons is always high-risk regardless, and Article 6(4) requires you to document the assessment and still register the system, now through a simplified procedure. It is not a shortcut you can assert after the fact.
What does Article 50 require from an internal AI assistant?
Article 50(1) requires providers to design AI systems that interact directly with natural persons so that those persons are informed they are interacting with an AI, unless that is obvious to a reasonably well-informed person. Employees are natural persons, so an internal chatbot is covered, and Article 50(5) requires the disclosure to be clear, distinguishable, and given at the latest at the time of the first interaction or exposure.
- 50(2): providers of systems generating synthetic audio, image, video, or text must mark outputs in a machine-readable format detectable as artificially generated, as far as technically feasible. An exception applies where the system performs an assistive function for standard editing and does not substantially alter the input data.
- 50(3): deployers of emotion recognition or biometric categorisation systems must inform the people exposed to them. In the workplace, Article 5(1)(f) will usually have blocked the emotion use case already.
- 50(4): deployers must disclose deep fakes, and must disclose AI-generated text published to inform the public on matters of public interest, unless a human reviewed it and someone holds editorial responsibility. Internal drafts do not trigger this; publishing that draft externally can.
Article 50 compliance for an internal assistant is cheap: a persistent AI label in the interface, a first-interaction notice, and content marking in the generation path. Failing to do it is what costs money.
How do EU AI Act duties map to components in a self-hosted stack?
Each obligation on a self-hosted internal assistant lands on a specific component, which is what makes the Act tractable for an engineering team rather than only a legal one.
| Obligation | Binds | Component in a self-hosted stack |
|---|---|---|
| Art. 4 AI literacy | Provider and deployer | Recorded role-based training before access is granted |
| Art. 50(1) AI disclosure | Provider | Persistent label and first-interaction notice in the chat UI |
| Art. 50(2) content marking | Provider | Output marking and metadata in the generation service |
| Art. 10 data governance | Provider (high-risk) | Curated corpus, documented sources, permission-aware index |
| Art. 12 and 19 logging | Provider (high-risk) | Append-only, tamper-evident audit log in your own log store |
| Art. 26(6) log retention | Deployer | Retention policy of at least six months on that same store |
| Art. 14 and 26(2) human oversight | Provider and deployer | Named reviewers, plus source citations that make review possible |
| Art. 26(5) monitoring | Deployer | Self-hosted quality and drift telemetry with alerting |
| Art. 26(7) worker notice | Employer-deployer | Notice to workers and their representatives before go-live |
| Art. 73 serious incidents | Provider | Incident detection and a reporting path that meets the 15-day baseline, and the shorter deadlines for the gravest incidents |
Two rows are engineering work rather than paperwork: the tamper-evident log and the monitoring signals. Teclops AI covers the second in on-premise LLM observability without a SaaS, including why exporting prompts to a hosted monitoring tool undoes the point of self-hosting.
Why does on-premise deployment make AI Act evidence easier?
On-premise deployment makes the evidence side of the AI Act easier because the records the Act asks for are generated and retained inside your own estate. Article 26(6) obliges deployers to keep automatically generated logs “insofar as such logs are under their control”, and control is what a self-hosted stack gives you: no vendor export request, no retention window set by someone else’s terms, no open question about who else can read the trail. It also removes the cross-border transfer analysis that a third-party endpoint forces, which Teclops AI examines in AI data residency and sovereignty.
Be honest about the tradeoff. On-premise deployment does not reduce your obligations; it usually increases them, because self-building makes you the provider as well as the deployer, and provider duties under Articles 9 through 15 are the heavier set. What on-premise gives you is not a lighter burden but a provable one.
For internal knowledge assistants, the design that makes Article 50 and Article 26 straightforward is one that already cites its sources and logs what it did. Samvad AI is a source-cited RAG assistant that runs on-premise, air-gapped, or hybrid, answers only from your documents, cites the exact passage behind every answer, says plainly when an answer is not in your sources, enforces role- and row-level permissions, and writes a tamper-evident audit log. Those properties turn human oversight and record-keeping from a policy statement into something you can show an auditor.
If you are mapping an internal AI deployment against the August 2026 date, Teclops AI builds and operates AI systems inside your own infrastructure, with logging and permission controls designed in rather than bolted on. Reach the team at teclops.ai@gmail.com. Again: general information, not legal advice.
Frequently asked questions
Does the EU AI Act apply to AI systems used only internally by employees?
Yes. The EU AI Act has no internal-use exemption. Article 2(10) carves out only natural persons using AI in a purely personal, non-professional activity, so staff using an internal assistant for work are covered and the employing organisation is a deployer under Article 3(4). This is general information, not legal advice.
Am I a provider or a deployer if I self-host an open-weight LLM?
Often both. Article 3(11) defines putting into service to include supplying an AI system for your own use, so an organisation that assembles a retrieval assistant from an open-weight model and rolls it out to staff is the provider of that system as well as its deployer. If you licensed a finished product and merely run it on your own hardware, the vendor remains the provider and you are the deployer.
Does the EU AI Act apply to open-source and open-weight models?
Partly. Article 2(12) exempts AI systems released under free and open-source licences, but the exemption falls away if the system is placed on the market or put into service as high-risk, or falls under the Article 5 prohibitions or the Article 50 transparency duties. Article 53(2) separately relieves open-source general-purpose model providers of some documentation duties unless the model carries systemic risk. Open-weight licences with field-of-use restrictions may not qualify as free and open-source at all.
Do we have to tell employees before deploying an internal AI assistant?
Yes, twice over. Article 26(7) requires an employer deploying a high-risk AI system at the workplace to inform workers' representatives and affected workers before it is put into service or use, and Article 50(1) requires the system itself to tell any person that they are interacting with an AI. National labour and works council rules can add further consultation duties on top.
Is an internal knowledge assistant high risk under the EU AI Act?
Usually not. An assistant that answers staff questions from internal policy or product documents does not fall under any Annex III category on its own, so it typically sits outside the high-risk tier and owes mainly the Article 50(1) duty to disclose that a person is talking to an AI. It becomes high risk when it is pointed at an Annex III decision, such as screening job applicants or evaluating employee performance.