Meta Llama Under the EU AI Act: GPAI Model and System Classification

Meta's Llama family — Llama 2, Llama 3, and subsequent releases — sits at the intersection of two distinct EU AI Act compliance tracks. The model itself is a general-purpose AI (GPAI) model governed by Chapter V (Articles 51–56). The system you build by self-hosting, fine-tuning, or deploying Llama is a separate AI system, classified by what it does and governed by Articles 5 and 6. Conflating the two is the most common error companies make when assessing their Llama obligations.

This article works through both layers, flags the unresolved question about Llama's open-source status, and explains what self-hosting, fine-tuning, and deploying Llama means for your role and your compliance obligations under Regulation (EU) 2024/1689.

---

Layer 1: Meta as the GPAI Provider

Under Article 3(44), a GPAI model is one trained on large volumes of data, exhibiting significant generality, and capable of a wide range of tasks. Llama fits this definition — Meta has confirmed training compute in the relevant range for the larger variants. Meta is the GPAI provider under Article 3(3).

What Chapter V requires of Meta. Article 53(1) imposes four baseline obligations on all GPAI providers:

• (a) Prepare and maintain technical documentation under Annex XI.
• (b) Provide downstream AI system providers with information and documentation under Annex XII, enabling them to comply with their own obligations.
• (c) Put in place a copyright compliance policy covering training data, including the text-and-data mining opt-out under EU copyright law.
• (d) Publish a sufficiently detailed summary of training data used.

The GPAI obligations under Chapter V have applied since 2 August 2025.

The Open-Source Exemption — and Why It Is Arguable for Llama

Article 53(2) allows GPAI providers who release under a free and open-source licence to skip obligations (a) and (b) — the Annex XI technical documentation and the Annex XII downstream information — provided the model weights, architecture, and usage information are publicly available under a licence that genuinely permits use, modification, and distribution.

This matters because it determines whether Meta must publish the full Annex XI technical file and pass Annex XII information to downstream users building systems on top of Llama.

The complication: the Llama community licence — across versions 2 and 3 — contains commercial use restrictions. Companies above a certain user count (100 million monthly active users for Llama 2; commercial licences required above that threshold) and certain application categories require Meta's explicit permission. Whether that constitutes a "free and open-source" licence under the Act is genuinely uncertain. The Act does not define the term, and the AI Office has not published binding guidance. The traditional software definition requires freedom to use, modify, and distribute for any purpose without restriction — Llama's licence arguably falls short.

Until the AI Office clarifies this, companies relying on the Article 53(2) exemption as a reason not to assemble Annex XII-equivalent documentation themselves should be cautious. If Meta does not qualify, the Annex XII downstream information may not be forthcoming through official channels; you would need to source it from model cards, published evaluations, and your own testing.

What always survives regardless of exemption status: Article 53(1)(c) and (d) — the copyright compliance policy and the training-data summary — apply to every GPAI provider, open-source or not. There is no carve-out for these. The obligations have applied since 2 August 2025.

Systemic Risk

The Article 53(2) open-source exemption (to the extent it applies) does not help if Llama crosses the systemic-risk threshold. Under Article 51, a GPAI model is presumed to present systemic risk if trained using compute exceeding 10²⁵ floating-point operations. The AI Office may also designate lower-compute models on capability grounds. For the largest Llama variants, the compute position should be verified directly against published training disclosures. Systemic-risk models face additional obligations under Article 55: adversarial testing and model evaluation, risk mitigation, incident reporting to the AI Office, and cybersecurity safeguards. Open-source status is no defence against Article 55.

---

Layer 2: Your System Built on Llama

When you self-host, fine-tune, or build a product on Llama, the compliance frame shifts entirely. You are no longer asking what Meta owes — you are asking what you owe as the provider or deployer of the system you have built.

You Become the Provider (Article 16/Article 25)

Article 3(3) defines a provider as any person who places an AI system on the market or puts it into service under their own name or trademark. If you take Llama, fine-tune it, wrap it in an application, and deploy it to users — even internal users — you are the provider of that system under Article 16. Article 25 reinforces this: a deployer or distributor who puts their name on a system, substantially modifies it, or changes its intended purpose becomes the provider with the full obligation stack.

This is not academic. A 30-person legal-tech company that builds a contract-analysis tool on Llama 3 70B, markets it to law firms, and hosts it on EU cloud infrastructure is the provider of that AI system. Meta's open-source licence does not transfer compliance obligations to its users — it transfers the weights.

Classification by Use, Not by Model

Your system's risk tier is determined by what it does, not which model powers it. The classification logic follows Articles 5 and 6:

Unacceptable risk (Article 5) — prohibited, in force since 2 February 2025. If you deploy a Llama-based system for real-time remote biometric identification in publicly accessible spaces, for social scoring based on behaviour or personal characteristics, or for emotion recognition in workplaces or educational institutions, the system is prohibited regardless of architecture. Fine ceiling: €35 million or 7% of worldwide annual turnover (Article 99(3)). These prohibitions do not have a future deadline — they are already enforced.

High risk (Article 6 + Annex III) — stand-alone systems from 2 December 2027. A Llama-based system falls into the high-risk tier if its intended use lands in one of the eight Annex III areas. For most organisations self-hosting Llama, the most common high-risk scenarios are:

• Annex III, point 4 (employment): A Llama-based tool that screens CVs, generates candidate shortlists, or scores applicants — even as a decision-support layer for human recruiters — is a high-risk system. The classification applies because the system influences hiring decisions that affect natural persons' access to employment.
• Annex III, point 5(b) (creditworthiness): A Llama-based model used to assess individual credit risk or score loan applications falls within this category. Note: fraud-detection systems are explicitly carved out.
• Annex III, point 6 (law enforcement): A Llama-based tool used to assess recidivism risk or to analyse evidence for police investigations is high-risk.
• Annex III, point 3 (education): A Llama system that evaluates student work and generates scores, or recommends educational pathways that affect admission or placement, is high-risk.

The Article 6(3) filter applies: a system that falls within an Annex III area is not high-risk if it poses no significant risk of harm — for example, if it performs a narrow preparatory task without influencing a material decision. The burden is on the provider to document that assessment. Any system that profiles natural persons remains high-risk regardless of the filter.

Limited risk (Article 50) — from 2 August 2026. A Llama-based chatbot deployed to interact with natural persons in real time must disclose that users are talking to an AI (Article 50(1)). Synthetic media generated by Llama and presented as depicting real events must carry appropriate labels (Article 50(4)). These transparency obligations apply from 2 August 2026 and are not conditional on the system being high-risk.

Minimal risk. A Llama-based internal knowledge-retrieval assistant that answers staff questions about company policy, or a code-review tool that flags potential bugs, is minimal risk. No mandatory obligations attach. Voluntary codes of practice are encouraged.

Self-Hosting: Data Residency and Security

One of the frequently cited reasons for choosing Llama over an API-delivered model is data residency. Self-hosting on EU infrastructure means your training data, inference requests, and model outputs do not leave the EU. For systems processing personal data, this removes a GDPR transfer risk and gives you full control over data governance under Article 10.

For high-risk systems, Article 15 requires that the system achieve appropriate levels of accuracy, robustness, and cybersecurity throughout its lifecycle. When you self-host, you own the security posture: patch cadence, access controls, model update governance, and incident monitoring all sit with you. This is an advantage if your security engineering is strong; it is a gap if it is not.

Fine-Tuning and the GPAI Question

Standard fine-tuning — LoRA adaptation, instruction tuning, domain-specific RLHF — produces a system classified by its purpose. The fine-tuner is the provider of that specific-purpose system. If the system operates in an Annex III domain, the high-risk obligations attach.

Large-scale post-training work — continued pre-training at significant compute — could make the fine-tuner a GPAI model provider in their own right if the result remains broadly capable across a wide range of tasks. Crossing the 10²⁵ FLOP threshold through fine-tuning alone is unlikely for most organisations. But if your derivative model is broadly capable and you distribute it to third parties for them to build on, the GPAI provider analysis applies to you, not just to Meta.

---

Obligations for High-Risk Llama Systems

If your Llama-based system is high-risk, the provider obligation stack under Article 16 applies in full. The key requirements:

• Article 9 (risk management system): A documented, iterative process for identifying, estimating, evaluating, and mitigating risks over the system's entire lifecycle. For an LLM-based system, this includes failure-mode analysis specific to generative systems: hallucination, adversarial prompting, disparate performance across demographic groups, and data quality risks in fine-tuning datasets.
• Article 10 (data governance): Training and validation data must meet relevance, representativeness, and quality criteria. Fine-tuning datasets require particular attention to data origin, bias, and coverage. Article 10 is the data-governance article — not Article 4, which governs AI literacy.
• Article 11 (technical documentation per Annex IV): A technical file covering system architecture, training methodology, performance benchmarks, known limitations, and the risk management outputs. This must exist before the system goes to market and be kept current.
• Article 14 (human oversight): Measures allowing human oversight of the system's operation, the ability to intervene or halt, and appropriate monitoring. For a Llama-based recruitment tool, this means that no hiring decision is made solely on the system's output without a human reviewing and taking responsibility.
• Article 43 (conformity assessment): For most Annex III systems (other than biometrics, which requires the Annex VII notified-body route), self-assessment under Annex VI applies. This is the provider's documented, internal verification that the system meets the requirements of Articles 9–15 before it goes to market.
• Article 47 (EU declaration of conformity): Signed before or at the time the system is placed on the market; kept for ten years (Article 18).
• Article 49 (registration): High-risk systems must be registered in the EU database established under Article 71 before market entry. Providers claiming the Article 6(3) non-high-risk exemption must also register that assessment.

The deadline for stand-alone Annex III high-risk systems is 2 December 2027 under the Digital Omnibus agreed in May 2026. The original August 2026 date has been deferred. This is breathing room, not a reprieve — the Article 11 technical file and the Article 9 risk management system take months to assemble for a production LLM deployment.

---

How Confir Helps

When you register a Llama-based system in Confir, the classification engine asks what the system does and where it operates — not what model it runs on. The rule-based logic applies Article 6 and Annex III to your use-case description and derives the risk tier and your role. For minimal-risk uses, the output is a documented non-high-risk assessment. For high-risk uses, Confir surfaces the Article 9–15 obligation stack, walks through the Annex IV technical-documentation structure, and records the GPAI dependency — including the model identifier, licence terms, and the open-source exemption status question — as a structured entry in your AI inventory.

The tool also records whether the Annex XII downstream information from Meta is available or must be reconstructed from model cards and published benchmarks. Same intake, same output, every time — reproducible and audit-defensible.

---

FAQ

Is Meta Llama a GPAI model under the EU AI Act?

Yes. Llama meets the Article 3(44) definition: trained on large volumes of data, broadly capable, designed for integration into downstream applications. Meta is the GPAI model provider. Chapter V obligations for GPAI providers have applied since 2 August 2025. GPAI models on the market before that date must comply by 2 August 2027.

Does the open-source exemption (Article 53(2)) apply to Llama?

This is genuinely uncertain. Article 53(2) requires that the model be released under a licence permitting use, modification, and distribution without conditions. The Llama community licence restricts certain commercial uses and requires Meta's permission above defined scale thresholds. Whether this qualifies as "free and open-source" under the Act is not yet resolved; the AI Office has not published binding criteria. Treat the exemption as arguable rather than assumed, and verify whether Annex XII downstream documentation is available from Meta regardless.

If I self-host Llama, do I become the provider of an AI system?

Yes, if you deploy it for a specific purpose and put it into service under your own authority. You are the provider of the system you build, classified by what it does. Meta's GPAI obligations stay with Meta; your system obligations are derived from Article 6 and Annex III based on your use case.

When do high-risk obligations apply to a Llama-based recruitment tool?

Under the Digital Omnibus agreed in May 2026, stand-alone Annex III high-risk systems must comply by 2 December 2027. A Llama-based CV-screening or candidate-ranking system falls under Annex III, point 4 (employment). The conformity assessment under Article 43 must be completed and the system registered under Article 49 before it goes to market.

Does fine-tuning Llama make me a GPAI provider?

Standard fine-tuning for a specific purpose makes you the provider of an AI system, not a GPAI model provider. Large-scale post-training that preserves broad generality across unrelated tasks could attract GPAI analysis, but this is not typical for enterprise fine-tuning projects. If you distribute a fine-tuned derivative to third parties who build their own systems on it, the GPAI question is worth a direct assessment.

What are the penalties for non-compliance?

Deploying a prohibited Llama-based system (Article 5): up to €35 million or 7% of total worldwide annual turnover, whichever is higher (Article 99(3)). Non-compliance with high-risk obligations (Article 16, Articles 9–15, Article 43): up to €15 million or 3% (Article 99(4)). Non-compliance with Article 50 transparency obligations: also €15 million or 3% (Article 99(4)). For GPAI providers: up to €15 million or 3% imposed by the Commission (Article 101). For companies that qualify as SMEs, fines are capped at the lower of the percentage or the fixed amount under Article 99(6).

---

Related guides

• Article 6 risk classification tool
• open-source exemptions under the EU AI Act
• Open-source models and the EU AI Act
• LLM risk classification requirements
• Article 43 conformity assessment
• Article 26 deployer obligations
• deployer compliance framework
• Article 3 AI system definitions
• conformity assessment procedures
• 2026 compliance deadlines