Blog / Guides
EU AI Act for self-hosted LLMs: what to review now
Running an open-weight model in your own cloud account gives you control over infrastructure. The EU AI Act asks a different set of questions: what the system does, who provides it, who uses it and how its outputs affect people.
An internal assistant that helps draft documents and a system used to assess job applicants may share the same model while needing different reviews. Start with the intended use and the organization's role. The location of the GPU does not answer either question.
Distinguish the model from the system built around it
The AI Act distinguishes providers and deployers of AI systems from providers of general-purpose AI models. Integrating an existing model into a system supplied under your own name can create system-provider responsibilities without making you the original model provider.
The Commission's GPAI guidance treats downstream modification as a separate question. Its indicative compute criterion refers to more than one third of the original model's training compute. It is not a universal safe harbor based on one third of 1023 FLOPs, and it does not settle your responsibilities for the surrounding application.
For a review, record whether you are using unchanged weights, fine-tuning, redistributing a model or placing a system into service under your own name. Give the legal reviewer the product behavior and modification details rather than only a model identifier.
The dates are different for different obligations
The Commission's AI Act overview and Regulation (EU) 2026/1744 set out the current timetable. The July 2026 amendment deferred specified high-risk provisions; it did not postpone the entire Act.
| Date | Relevant milestone |
|---|---|
| 2 February 2025 | Initial application of prohibited-practice rules and AI literacy provisions, subject to later amendments |
| 2 August 2025 | GPAI-model obligations began applying, with transitional arrangements for older models |
| 2 August 2026 | Article 50 transparency obligations began applying |
| 2 December 2026 | Deadline for Article 50(2) marking compliance for covered systems placed on the market before 2 August 2026 |
| 2 December 2027 | Deferred Chapter III Sections 1–3 for Annex III high-risk systems, apart from Article 6(5) |
| 2 August 2028 | Deferred Chapter III Sections 1–3 for Article 6(1) and Annex I high-risk systems, apart from Article 6(5) |
A deployment's precise transition treatment depends on the system and when it entered the market or service. Use the dates to organize the review, not as blanket permission to defer all work.
Apply the right transparency duty to the right actor
The Commission's Article 50 guidance separates several duties. Providers of systems that interact directly with people must address disclosure that the interaction is with AI, unless this is obvious in context. Providers of systems generating synthetic content have machine-readable marking and detectability obligations, subject to the provision's qualifications and exceptions.
Deployers have distinct disclosure duties for deepfakes and certain AI-generated public-interest text. Human review and editorial responsibility can affect the public-interest-text requirement. This is not a rule that every internal generated sentence needs the same visible label.
For a chatbot, examine the actual first-use screen, shared conversation views and exported outputs. A clear disclosure in one interface may be absent from another. For generated media or published text, identify who controls marking and who controls the final disclosure.
Support staff literacy and choose logs deliberately
The current AI literacy guidance reflects the amended Article 4: providers and deployers must take measures supporting staff literacy in context, without guaranteeing a particular competence level for every individual. A practical session can cover unreliable answers, approved data, checking outputs and how to report a problem.
For covered high-risk use, Article 26 addresses automatically generated logs under the deployer's control, generally for an appropriate period of at least six months unless other law provides otherwise. That is not a universal six-month instruction to retain every prompt. A deployment audit log records infrastructure actions; it does not by itself supply all application records a regulated use may require. See the Act's deployer provisions alongside the amended application dates.
Prepare a useful deployment review
- Describe the intended use, affected people and decisions the system supports.
- Name the model, system provider, deployer and operational owner.
- Map inputs, outputs, logs, storage and third-party services.
- Document model evaluation, known limitations and human review steps.
- Assign owners for disclosures, access, retention and incident handling.
- Have the appropriate reviewer record the classification, applicable duties and next review trigger.
Model licensing, GDPR and sector-specific rules remain separate parts of the assessment. An open license or EU region is useful information, but neither establishes compliance for a complete application.
LLM Hangar's access controls and deployment records can support the operational evidence. Your organization still needs to decide how the application should behave, which data it may process and how people review its results.
Questions people ask
Does self-hosting settle my AI Act role?
No. Review what the system does, whose name it operates under, who uses it and whether the underlying model is modified. Infrastructure ownership alone is insufficient.
What should I prepare before asking for a legal review?
Provide the intended use, model and system details, audiences, data flows, modification history, operational controls and launch dates. A concrete system description makes the assessment more useful.
Is a platform audit log enough?
It is one source of evidence. Match the records to the application, applicable duties and retention policy; infrastructure events and application behavior answer different questions.