General-Purpose AI Models EU Compliance Tracker

A score is the percentage of the publicly-checkable part of a requirement that a provider's own published documents satisfy. It measures disclosure against our set of indicators: how much of what the Code asks for a provider has put on the public record. It is not a measure of whether a model is safe, and it is not a finding of legal compliance; only the EU AI Office can make that determination. A low score means we could not verify something in the public record, not that the provider is failing to do it. We are simply basing our scores on the complete set of publicly available information.

Because it turns "is this provider doing what the Code asks?" into something anyone can check. For every requirement we point to the exact public documents and quotes behind the score, so a journalist, a researcher, or the AI Office can reproduce it and see for themselves where the public evidence is solid and where it is thin. It is, to our knowledge, the first clause-by-clause, source-linked public record of what frontier providers have actually disclosed against the Code, which makes the conversation about compliance concrete instead of anecdotal and shows providers exactly where a little more disclosure would close a visible gap.

What it does not tell you is what a provider has disclosed privately to the regulator, or what it does internally. We can only speak to what a provider has, or has not, put on the public record against each requirement, with the exact documents and quotes to back it. So a low score is a statement about the public evidence available to us on a given date, not an airtight safety or compliance verdict on the company.

No. A high score is a measure of what a provider has disclosed, not whether its models are safe, and not whether it is legally compliant. Only the EU AI Office can make a compliance determination. A high score means a company has both published and satisfied, in spirit, what the Code asks for; a low score means we could not find it in public.

The asterisk beside a provider's logo means that provider has not formally signed the Code of Practice. Hover it to see the same note.

We score every provider we track against the same requirements, whether or not they signed. We are an independent observatory, not the AI Act's regulator, so a signature is not our gate: the Code is the most detailed public statement of what good practice looks like for a general-purpose AI model, and a reader is entitled to ask how any major provider measures up against it. Treating signatories and non-signatories differently on the board would also make the scores incomparable, which is the one thing a comparison table has to get right.

What changes is what the score can be used for. For a signatory, the Code is the yardstick they chose, and a gap is a gap against their own commitment. For a non-signatory, the Code is our yardstick, not theirs: the same number describes how much of the same public material they have disclosed, but it is not a shortfall against anything they agreed to, and it cannot be read as non-compliance with a commitment that was never made. In neither case is a score a legal compliance finding; only the EU AI Office can make one.

Signature is also per chapter. The Code has three, and a provider can sign some and not others. xAI, for example, signed the Safety and Security chapter and not Transparency or Copyright. Providers who signed nothing at all carry the same asterisk. The chapter-level detail is not on the board because it would imply the scores mean different things in different sections, and they do not. The European Commission publishes the current signatory list, which is where we take ours from.

For each provider we build and maintain a full library of what they have published publicly: a record of every relevant blog post, announcement, web page, system and model card, safety and responsible-scaling framework, acceptable-use and usage policy, model specification, transparency report, and similar document. Every document is collected, dated, and stored in an open dataset, so the exact sources behind any score can be inspected, downloaded, and reproduced. For each measure we score against the subset of document types most relevant to it. For 7. Safety and Security Model Reports, for example, that means the model report (the primary source), together with the model specification, systemic-risk report, internal and external evaluation reports, safety and security mitigations reports, framework changelog, and serious-incident report.

Each measure of the Code is broken down into granular indicators: small, concrete, objective checks that together capture what the measure asks for. An indicator aims to be atomic (one requirement), traced back to the exact clause of the Code it comes from, and paired with an indication of whether it is a publicly checkable requirement or something that can only be assessed through private channels between the EU AI Office and the provider. Indicators are developed through a multi-step pipeline: first proposed through a structured long-form Delphi-protocol debate between large language models from six different providers. Then, each clause of each indicator is manually read, reviewed, and edited by a human expert on our team before it is ever used to score.

We do not, and that is deliberate. Every indicator, and every clause within it, carries a property that marks whether it is something we can confirm from the public record or something that can only be satisfied through private channels between a provider and the EU AI Office. Clauses in that second group are set aside and left out of the score entirely. We do the same for clauses that simply do not apply to a given provider: many requirements are conditional (for example, a clause that only applies to a model the provider has itself classified as posing systemic risk), and where the condition does not hold, the clause is counted neither for nor against them. A provider's score is therefore a flat measure over only the requirements we can actually check in public, so nothing counts against a provider for a requirement that is not publicly verifiable or does not apply to it. This is how we stay fair: we only score what we can see.

Every publicly-checkable clause is assessed by a panel of large language models from six different model providers (both open and closed source), using a structured elicitation modeled on the IDEA protocol (Investigate, Discuss, Estimate, Aggregate). When we score a given provider, that provider's own model is excluded from judging it to account for self-bias. A clause is only marked satisfied where the panel can cite a verbatim quote from the provider's own documents, checked back against the original source. We run each IDEA pipeline multiple times to account for inter-run variance, and each score is reported with a confidence interval that reflects how strong and consistent the supporting evidence is. The determination of whether a publicly verifiable clause is met or not met is then checked by a human expert who is familiar with the indicator: they read the evidence produced by the IDEA protocol, read the original system cards to confirm whether the met or not-met verdict holds, and ratify the score. These granular clause verdicts roll up into a score for the indicator, indicators into a score for the measure, and so on up the tree.

No. We do not apply any importance or "materiality" weights to particular measures or indicators. Within a measure, every clause counts equally and the measure's score is a flat average across its clauses. Splitting or merging indicators cannot move the score: it reflects what the provider disclosed, not how we happened to group the requirements together.

Our aim is to stay neutral and fair. Where we use domain expertise, it goes into deciding what a complete disclosure should contain, the concrete elements to look for under each requirement, not into judging whether a provider's disclosed practices are adequate or good enough.

Where the Code itself makes a requirement non-negotiable, through its own "shall", "must", or "before placing on the market" language, that emphasis comes from the Code, not from us. We are building a separate non-compensatory step to reflect it, so that a failure on a genuinely mandatory item cannot simply be averaged away by easy wins elsewhere.