When does a general-purpose AI model count as having systemic risk under the AI Act?
A provider of a general-purpose AI model needs to know early whether its model is classified as having systemic risk, because that classification triggers the additional duties in Article 55. Under Article 51(1), a model has systemic risk through one of two routes. The first is high-impact capabilities evaluated with appropriate technical tools and benchmarks. The second is designation by the Commission using the Annex XIII criteria, which cover parameters, data set size, training compute, modalities, benchmarks and reach. The Commission can designate on its own initiative or after a qualified alert from the scientific panel. Article 51(2) adds a presumption: when cumulative training compute exceeds 10^25 floating point operations, high-impact capabilities are presumed. That presumption shifts the burden to the provider, which must notify the Commission and may argue the exception under Article 52(2) and (3).
The classification is therefore the provider's own obligation to establish and report, not a label an assessor grants. An independent auditor does not certify that a model is outside the category. The provider must document its compute count, its capability evaluation and its reasoning, then notify within the deadline in Article 52(1), which is without delay and in any event within two weeks after the threshold is met or it becomes known that it will be met. The Commission's GPAI factpage says the 10^25 threshold is under review, and Article 51(3) allows it to be amended by delegated act. Confirm the current threshold and any pending amendment on that factpage before you rely on the figure in a planning document.
Which models and teams does the classification affect?
Classification under Articles 51 and 52 turns on a few scoping decisions: where the model is placed, whether it is open source, and how compute is counted. Each decision touches a different team, so the cards below cover both the technical choices and the people who must own the records behind them.
EU market placement
The notification and systemic risk duties attach to providers who place a general-purpose AI model on the EU market, and Article 2 reaches providers established outside the EU when their output is used in the Union. Before counting compute, confirm which releases, APIs and hosted endpoints count as placing the model on the market, and record the date each one became available to EU users. A model that is trained abroad but offered to EU customers still needs this analysis.
Open-source status and its limits
Whether a model is released under a free and open-source licence affects some Chapter V duties, but it does not remove the systemic risk analysis for a model above the presumption threshold. Legal and product teams should confirm the licence text, any usage restrictions and whether the weights are distributed, because these details decide which exemptions are even available. Do not assume an open licence settles classification.
Cumulative compute across training stages
The presumption applies to cumulative training compute, so pretraining, fine-tuning, continued training and any reinforcement stages add together. An ML platform team should log each run with its start and end time, hardware, precision and estimated floating point operations, then sum them per model version. Missing a fine-tuning run is the most common way a provider underestimates its position.
Compute records owned by finance
Cloud invoices and reserved capacity contracts often show accelerator hours more reliably than training logs. Finance teams can reconcile those invoices against the ML platform's run records, flag runs that were billed but never logged, and keep the reconciliation for audit. The two sources rarely match exactly, so the variance and the method used to reconcile it should be documented.
Notification ownership in legal
Article 52 gives the provider two weeks from the moment the threshold is met, or from when it becomes known that it will be met, to notify the Commission. Legal should own the trigger: a named person who receives compute reports, decides when the threshold is reached and files the notification. Set an internal escalation path so the clock is not lost between the platform team and the legal team.
Upstream base models and fine-tuners
A downstream team that fine-tunes a third-party base model may cross the threshold through its own training, and it must also know the upstream model's compute history, because cumulative compute includes the base training run. Ask the base model provider in writing for the training compute figure, the date it was completed and whether it has notified the Commission. If the answer is missing, treat the fine-tuned model as unclassified until the gap is resolved.
Two routes to systemic risk and what each one needs
Under Article 51(2), a general-purpose AI model is presumed to have high-impact capabilities when its cumulative training compute exceeds 10^25 floating point operations. The presumption is triggered by a measurable figure, so the provider's first job is to count compute across the whole training run, including every pre-training and fine-tuning stage that feeds the final model. Article 52(1) then sets the clock: the provider must notify the Commission without delay and in any event within two weeks after the threshold is met, or after it becomes known that it will be met.
- Cumulative compute record: Keep a dated log of training runs, hardware hours and estimated floating point operations per stage, with the method used to calculate each figure.
- Forecast of threshold crossing: Record planned runs and projected compute so the provider can see when notification becomes due, not only when the threshold has already been passed.
- Notification file: Store the notification, its submission date and the Commission's acknowledgement, so the two-week window can be shown to have been met.
- Threshold status: The Commission's factpage says the 10^25 threshold is under review, and Article 51(3) allows amendment by delegated act, so record which threshold version the provider relied on.
Before relying on this route, confirm the current threshold text and the Commission's latest guidance with the AI Office, because the figure is open to change.
Under Article 51(1), the Commission can designate a model as having systemic risk using the Annex XIII criteria, either on its own initiative or after a qualified alert from the scientific panel. A designation does not depend on compute alone. The Annex XIII criteria cover parameters, data set size, training compute, modalities, benchmarks and reach. Where a model is available to at least 10 000 registered business users in the EU, high market impact is presumed under the same annex, so the provider needs a clear count of its registered business users.
- Parameter and data set records: Keep documented figures for model parameters and training data set size, with the source and date of each count.
- Modality and benchmark evidence: Record which input and output modalities the model supports and the benchmark results that describe its capabilities.
- Reach figures: Maintain a count of registered business users in the EU, updated on a fixed schedule and reviewed against the 10 000 presumption.
- Designation correspondence: Log any Commission request, notice or alert handling, including the response and the date sent.
Confirm with the AI Office how it counts registered business users and how it will use benchmark results, since the factual basis for these criteria is set out in the annex rather than in a single calculation.
The two routes are not mutually exclusive. A model can cross the compute threshold, be designated on Annex XIII grounds, or meet both. The provider should therefore keep one classification file that records each route separately, the evidence for each, and the date of each assessment. This makes it clear which route drives the duty to notify, and which route the Commission might use independently of any notification.
- Single classification file: Hold compute, capability, reach and designation evidence in one place, with an owner and review date.
- Route-by-route conclusion: For each model version, record whether the compute presumption applies, whether high-impact capabilities were evaluated, and whether the reach presumption applies.
- Version control: Tie each conclusion to a specific model version, because a fine-tuned or retrained model can change the outcome.
- Trigger log: Note each event that could change classification, such as a new training run, a change in EU user numbers or a Commission communication.
Check with legal counsel whether the classification file meets your internal approval process before the model is placed on the market.
Article 52(2) and (3) allow a provider to argue in its notification that its model exceptionally does not present systemic risk, even though the compute presumption applies. The Commission rejects arguments that are not sufficiently substantiated, so the rebuttal must rest on documented evidence rather than assertion. Article 52(5) allows a provider to request reassessment of a designation at the earliest six months after the decision, and Article 52(6) requires the Commission to publish and update a list of models with systemic risk.
- Rebuttal dossier: Assemble evaluation results, capability tests and a reasoned explanation of why high-impact capabilities are absent, with the test methods and dates recorded.
- Evidence quality: Show the benchmarks, tools and procedures used, so an assessor can repeat the analysis rather than accept a conclusion.
- Reassessment calendar: Track the earliest date a reassessment request can be made, six months after the decision, and the material changes that would support it.
- Public list monitoring: Check the Commission's published list regularly and record the date each model appears or changes status.
Decide with counsel whether a rebuttal is worth the effort, because the argument must be substantiated and the outcome depends on the Commission's assessment.
How an assessor tests the systemic risk classification
This table compares each test an AI Office or auditor-style reviewer would run on a systemic risk classification, the evidence it expects, and the findings that most often cause problems. Read it as a checklist of what your records must prove, not as a certification of the classification itself.
| Test area | What the reviewer checks | Common finding |
|---|---|---|
| Cumulative training compute | Whether training compute records, summed across all training runs that contribute to the model, are compared against the 10^25 floating point operation presumption in Article 51(2) | Compute estimates with no stated counting method, missing runs, or figures that cannot be traced to logs |
| Compute method and records | Whether the estimation method is documented, reproducible and tied to hardware usage, run logs and configuration records | Figures given as a single number with no method, assumptions or source records attached |
| Notification timing | Whether the notification to the Commission was made without delay and within two weeks of the threshold being met or known to be met, under Article 52(1) | Late notification, or no record of when the team first knew the threshold would be crossed |
| Rebuttal arguments | Whether any argument that the model exceptionally does not present systemic risk under Article 52(2) and (3) is specific, evidenced and tied to the Annex XIII criteria | Generic arguments with no benchmark results, or claims that rely on data the provider cannot show |
| High-impact capability evidence | Whether capability evaluations use appropriate technical tools and benchmarks under Article 51(1), with results kept for review | Evaluations that were run once before release and never repeated after fine-tuning or capability changes |
| Annex XIII reach monitoring | Whether the provider tracks registered business users in the EU and other Annex XIII indicators, such as parameters, data set size and modalities | No counting process for registered business users, so the 10 000 user presumption is never tested |
| Post-release monitoring | Whether the provider reviews these indicators over the life of the model and records each review decision | No monitoring after release, so a model that crosses a threshold later goes unnoticed |
| Reassessment and list status | Whether the provider knows when a reassessment request is possible and tracks the Commission's published list of models with systemic risk | No owner for regulatory status, and no record of when the model was added to or removed from the list |
How to implement the classification process, step by step
This sequence turns the systemic risk rules into a working routine: it measures training compute, watches the thresholds, documents capability evaluations, and prepares notifications and reassessment requests so that the provider can meet the Article 52 duties on time.
Define the compute accounting method and owner
Name one accountable owner, usually the head of model training or a compliance lead, and write a short method that defines how cumulative training compute is counted for each model. The method should state which runs count, how pre-training, fine-tuning and continued training are added together, and how estimates are checked against hardware logs. The output is an approved accounting method stored in the governance record. It is done when every model in scope has a named owner and the method has been signed off by someone outside the training team.
Instrument training runs to record cumulative FLOP
Configure training jobs so that each run writes its compute usage, hardware type, duration and dataset size to a durable log, and so that the running total for each model is updated automatically. Keep the raw logs, not only dashboard totals, so that an assessor or the Commission can trace the figure. The output is a per-model compute ledger that reconciles with the cluster or cloud billing records. It is done when a test run produces the same total from both sources within the tolerance set in the method.
Set a tripwire well below the 10^25 threshold
Set an internal alert at a lower compute level than the presumption threshold in Article 51(2), so that the team has time to act inside the two-week notification window in Article 52(1). The alert should trigger a review that includes the model owner, legal counsel and the person who holds the notification duty. The exact tripwire value is a judgment for the organization, and it should be recorded with its rationale, especially because the Commission's GPAI factpage notes the threshold is under review. The output is a documented tripwire and an escalation path. It is done when a test alert reaches the named reviewers within the same working day.
Document the high-impact capability evaluation
Run and record the evaluations that show whether the model has high-impact capabilities under Article 51(1), using appropriate technical tools and benchmarks. Store the benchmark versions, prompts, settings, scores and the reasoning that links each result to a capability conclusion. Vulnerability probing can support this record: garak (Apache-2.0) probes language models for issues such as prompt injection and data leakage and writes a JSONL report of every attempt plus a hit log, which gives reviewers a reproducible trail. The output is a dated evaluation file for each model version. It is done when a second reviewer can rerun a selected benchmark and reach the same result.
Track Annex XIII reach and market indicators
Maintain a register of the Annex XIII criteria for each model, including parameters, data set size, modalities, benchmarks and reach. Track the number of registered business users in the EU, because Annex XIII presumes high market impact when a model is available to at least 10,000 registered business users in the EU. Record how each figure was obtained, such as from account records or API key registrations, and who reviewed it. The output is a reach register updated on a fixed review cycle set by the governance policy. It is done when the register can answer whether any model is near the user threshold without manual reconstruction.
Prepare the notification and any rebuttal
Draft the notification to the Commission in advance so that it can be sent without delay once a threshold is met or known to be coming. The file should identify the model, the compute figure and its ledger, the capability evaluations, and the reach data. Where the provider believes the model exceptionally does not present systemic risk, prepare a rebuttal under Article 52(2) and (3) with specific technical evidence, because the Commission rejects insufficiently substantiated arguments. The output is a ready-to-send notification pack and, where relevant, a substantiated rebuttal. It is done when legal and technical owners have both approved the pack and the send process is tested.
Calendar reassessment requests under Article 52(5)
After a designation decision, record its date and calculate the earliest date a reassessment request may be filed, which is six months after the decision under Article 52(5). Add reminders for reviewing the Commission's published list of models with systemic risk under Article 52(6), since the list is updated over time. Pair each entry with the evidence that supports a request, such as changed capabilities or revised compute figures. The output is a dated calendar and a reassessment file per designated model. It is done when each designated model has a recorded earliest request date and a named owner.
Evidence that shows the classification is sound
A provider that concludes its model is or is not a model with systemic risk needs a file that shows how the conclusion was reached and when each step happened. The artifacts below connect the compute count, the capability evaluation, the Commission notification and any later challenge, and each one should be kept current between audits.
Compute ledger per training run
A ledger that records, for each training run, the cumulative training compute in floating point operations, the counting method, the data and parameters used to derive the figure, and the named person who signed off on it. Article 51(2) measures against 10^25 FLOP, so the ledger is the first thing an assessor will ask for. Keep the method under version control so a changed counting approach is visible, and restrict edit rights so that only the compute owner and the approver can change a signed entry.
Notification record with timestamps
A dated record of when the threshold was met, or when it became known that it would be met, and when the notification reached the Commission. Article 52(1) sets the outer limit at two weeks, so the record should show both the trigger date and the submission date. Keep the record in an audit-logged system so the timestamps cannot be quietly edited, and confirm with the Commission's current submission route how receipt is evidenced.
High-impact capability evaluation report
A report that records the tools, benchmarks, test sets and results used to assess whether the model has high-impact capabilities under Article 51(1), including any results that point in each direction. Because the presumption can be rebutted and the Commission can designate on its own initiative, the report should be re-run and dated when the model or its training changes. Store each version with its inputs so a reviewer can reproduce the result, and keep reviewer comments attached to the version they concern.
Rebuttal file with substantiating data
The file that holds any argument that the model exceptionally does not present systemic risk, with the data that supports each claim. Under Article 52(2) and (3), the Commission rejects insufficiently substantiated arguments, so every claim needs traceable sources, measurements and reasoning. Keep each argument and its supporting data as a dated version, and limit write access to the named authors so that no figure changes after it has been submitted.
Annex XIII reach log
A running log of the Annex XIII indicators, including parameters, data set size, modalities, benchmark results and the number of registered business users in the EU. High market impact is presumed at 10 000 registered business users, so a provider needs a defensible count and a documented method for counting. Review the log on a fixed schedule, record who approved each entry, and keep prior entries intact so changes over time can be explained.
Reassessment request trail
A record of every request to reassess a designation, with the date of the decision it concerns, the earliest date the request could be made, the grounds raised and the Commission's responses. Article 52(5) allows a request no earlier than six months after the decision, so the trail should show when that window opened. Keep the trail with the model's classification file, and confirm the current submission channel and any content requirements with the Commission before filing.
What meeting the classification duties costs in money and effort
This table lists the cost components behind classifying a general-purpose AI model and handling its notification, rebuttal and reassessment, with who is paid, whether each cost is one-time or recurring, and what drives it. No price is given here because the Act and its supporting facts do not set one, and DeployOpen quotes follow a written scope. Use the last column to see what to request in a quote.
| Cost component | One-time or recurring, and who is paid | What drives the cost | What to ask for in a quote |
|---|---|---|---|
| Compute accounting engineering | One-time build of a cumulative training compute record, then recurring upkeep as new training runs occur. Paid to internal engineers or an implementation partner. | Number of training runs, distributed training setups, and whether compute logs already exist for each run. | Scope of the compute ledger, data sources it reads, the audit trail it produces, and who maintains it after handover. |
| Capability evaluation tooling and time | Tooling is a one-time setup with recurring runs after each major model change. Paid to staff, benchmark licensing where applicable, and any evaluation partner. | Number of benchmarks, model variants, and whether high-impact capabilities are tested against appropriate technical tools. | Which benchmarks and tools are covered, how results are recorded, and how often reruns are included. |
| Legal review of notification and rebuttal | Recurring per notification event, plus a one-time review of the internal process. Paid to in-house or external counsel. | Whether the threshold is met or expected to be met, and the need to argue exceptional circumstances with substantiated evidence. | Hourly or fixed-fee basis, what a single notification review includes, and whether a rebuttal file is priced separately. |
| Reach monitoring | Recurring. Paid for ongoing tracking of EU registered business users and availability, mostly in internal staff time or tooling. | Size of the user base, number of channels through which the model is offered, and how user registrations are counted. | How user counts are sourced, how often the figure is reviewed, and how changes trigger a reassessment review. |
| Documentation and record keeping | One-time template setup, then recurring updates for each model version. Paid to internal staff or a consultant. | Number of model versions, the depth of evidence kept, and the link to Commission notifications and the public list. | Document set delivered, version control approach, and retention period set in writing. |
| External evaluation or review | Optional. One-time per review or recurring if retained. Paid to an independent evaluator or assessor. Issues opinions, not a Commission decision. | Scope of testing, whether adversarial testing is included, and how many independent reviews are needed. | Named deliverables, independence arrangements, and whether results are reusable for later notifications. |
| Reassessment preparation | Occasional. Paid per request, after the earliest point in the Act for requesting one, or when the model changes materially. | Length of the designation history, changes in capability or reach, and the evidence the Commission will need. | Triggers for new work, turnaround expectations confirmed with the Commission process, and a fixed-scope boundary. |
Who owns the classification and who can help
Your organization is the provider, so the duty to assess the model, notify the Commission and keep the record sits with you. Under Article 52(1), the notification is made by the provider, and the rebuttal argument under Article 52(2) and (3) is your argument to make. Nobody else can decide that your model is below the threshold on your behalf.
- Compute ledger ownership: Accountable executives confirm which training runs count toward cumulative training compute and sign off the figures.
- The classification call: Legal, compliance and the model owners decide whether the 10^25 floating point operation presumption applies and whether any high-impact capability evidence points the other way.
- Notification sign-off: A named officer approves the notification sent to the Commission within the two-week window.
- Reassessment requests: Someone must track the six-month earliest date for requesting reassessment under Article 52(5) and watch the Commission's list of models with systemic risk.
- Governance documents: Decision memos, approval records and the reasoning behind any rebuttal stay under your control.
Before you engage anyone, confirm which individuals hold each of these decisions in writing.
An implementation partner such as DeployOpen can build the systems that make your classification file traceable and repeatable. The partner works inside your infrastructure and prepares evidence. It does not decide whether your model is systemic, does not sign the notification, and does not issue any report or designation.
- Compute ledger: Build a record of training runs, compute estimates, data set sizes and the dates each figure was computed, so the cumulative total can be reproduced.
- Evaluation pipeline: Set up repeatable capability evaluations with open-source tooling, such as garak for probing language models, and keep the JSONL reports and hit logs.
- Evidence store: Configure version-controlled documentation, for example in XWiki, and role-based access in BookStack so each decision keeps its history and approvals.
- Notification file preparation: Assemble the draft notification package for your signatory to review, including the Annex XIII criteria mapping supported by evidence.
- Operational support: Ongoing monitoring of the compute ledger and evaluation runs can be scoped as a retainer.
Ask any partner to put the division of responsibilities into the written scope before work starts.
The independent reviewer and the regulator test the record, not your intent. Independent auditors, assessors and certification bodies review evidence and issue their own conclusions. The Commission's AI Office is the authority that designates a model under Annex XIII and publishes the list of models with systemic risk. Neither role can be filled by your implementation partner.
- Reviewer scope: An independent reviewer checks whether the compute figures, evaluation results and approvals are complete, consistent and traceable to source.
- Commission decision: The Commission rejects insufficiently substantiated rebuttal arguments and may designate a model on its own initiative or after a qualified alert from the scientific panel.
- Independence line: A partner that built the evidence store should not also be the party that certifies it as adequate.
- Engagement terms: Confirm with any reviewer whether they assess the record against the Act directly, and what they will not conclude.
- Regulator contact: Keep a named contact and a process for responding to Commission requests.
Confirm with the AI Office or your national competent authority which procedural steps apply to your situation before you rely on any timeline.
Where organizations fall short on systemic risk classification
Most gaps in systemic risk classification are process gaps, not technical ones. Providers rarely fail because they cannot count compute; they fail because no one measured it on a schedule, no one started the notification clock, or no one tracked the facts that could change the classification later.
Compute estimated after the fact
Many providers work out cumulative training compute only when someone asks, reconstructing it from memory, invoices or incomplete run logs. Article 51(2) measures cumulative training compute against the 10^25 floating point operation presumption, so an undocumented method leaves no defensible number. Check that each training run records its accelerator hours, precision, and the formula used, and that the method is written down before the next run starts.
No tripwire before the threshold
A model that crosses 10^25 FLOP without warning gives the team no time to prepare the notification. Teams should set internal alert levels well below the presumption, tied to planned training runs, so that the compute trend is reviewed before a run is launched. Ask who owns the alert, what level triggers review, and whether the review is recorded.
Notification clock not started
Article 52(1) runs the two-week clock from the moment the threshold is met or it becomes known that it will be met, not from the day a lawyer reviews the file. Teams that wait for a formal sign-off often miss the window because the foreseeable point came months earlier in a planning document. Confirm who decides that a threshold is foreseeable, how that decision is timestamped, and who is authorized to send the notification to the Commission.
Rebuttals without substantiation
Under Article 52(2) and (3), a provider can argue that a model exceptionally does not present systemic risk, but the Commission rejects arguments it finds insufficiently substantiated. A rebuttal built on general statements about safeguards or intended use will not carry weight. Build the file in advance with benchmark results, evaluation methods, and evidence about capabilities, and have it reviewed by people who did not write it.
No monitoring of Annex XIII reach
Annex XIII treats high market impact as presumed when a model is available to at least 10 000 registered business users in the EU, and it also weighs parameters, data set size, modalities, and benchmarks. Designation can follow from these factors even when compute stays below the presumption. Ask whether anyone tracks registered business users by model and whether the Annex XIII factors are reviewed at each release.
No reassessment plan
Providers may request reassessment of a designation at the earliest six months after the decision under Article 52(5), and the Commission updates its list of models with systemic risk under Article 52(6). Without a calendar, a provider may stay designated after a model has changed, or miss the chance to ask for review. Set a recurring review date, record the evidence that would support a request, and assign an owner for the Commission list.
Common questions about systemic risk classification
When does the two-week notification clock start for a general-purpose AI model?
The clock starts when the provider's cumulative training compute reaches the threshold in Article 51(2), or when the provider learns that it will reach it. Article 52(1) requires notice to the Commission without delay and in any event within two weeks of either point, so the trigger is the earlier of the two. Because the second trigger covers planned training runs, a provider that forecasts crossing the threshold during a run may have to notify before the run ends. Engineers should therefore track projected compute as well as actual compute, and record the date on which the forecast first showed the threshold would be met. Confirm the internal escalation path with legal counsel, since the two-week window is short.
Can a rebuttal stop a systemic risk designation?
A rebuttal can change the outcome only if it is substantiated. Under Article 52(2) and (3), a provider that presents a presumed model may argue, in its notification, that the model exceptionally does not present systemic risk. The Commission rejects arguments that are insufficiently substantiated, so a rebuttal built on assertions will not hold. Strong submissions rely on evaluation results, capability benchmarks and documented analysis of reach and market impact, measured against the Annex XIII criteria. A rebuttal does not pause the notification duty. Organizations should prepare the evidence package before any threshold is close, because assembling benchmark data under deadline is where weak arguments usually come from.
How much effort does the compute ledger take, and what drives it?
The effort depends on how many training runs, checkpoints and continued-training stages a provider has, and on whether compute is recorded automatically. The threshold counts cumulative training compute, so every run that contributes to a model must be logged, including pretraining, fine-tuning runs that change the model, and runs on rented or shared clusters. The main cost drivers are the number of runs, the number of teams and vendors involved, and whether job-level compute data is captured by the training platform or reconstructed later from invoices. Ask for a written method for converting hardware-hours into floating point operations, and confirm how the Commission's current factpage guidance on the threshold is applied, since the threshold is under review.
Does a fine-tuner inherit the systemic risk classification of the base model?
Not automatically. Systemic risk is assessed for a general-purpose AI model, and whether a fine-tuned version is a new model depends on the modification and on who is the provider under the Act. The compute used to fine-tune counts toward cumulative training compute for that model, so a fine-tuner that adds substantial compute on top of a classified model may cross the threshold itself. Organizations that modify a model should record the compute of each modification, the data used, and the provider status they claim, then obtain a legal view on whether they have become a provider. The Commission's guidance on who counts as a provider should be checked as part of that analysis.
How often can a provider request reassessment of a designation?
A provider may request reassessment at the earliest six months after the Commission's decision, under Article 52(5). That is the earliest point, not a fixed interval, so a request made at six months must still show a material change in the model, its capabilities or its reach. The request should rely on new evaluation results and updated Annex XIII evidence. The Commission publishes and updates a list of models with systemic risk under Article 52(6), so providers should monitor the list and keep their designation records current. Ask counsel how a reassessment request interacts with ongoing notification and obligation timelines.
Can DeployOpen run the classification process for us, or only prepare evidence?
DeployOpen can prepare the evidence, but it cannot run the process as the provider or make the legal determination. The organization owns its notification, its rebuttal and its legal position. An implementation partner can instrument training pipelines so compute and run metadata are captured, set up version-controlled records of decisions, and assemble an evidence file mapped to the Annex XIII criteria. Engagements are fixed-scope, with deliverables agreed in writing before work starts, and any quote follows from that written scope. Legal interpretation, the notification itself and any submission to the Commission remain with the provider and its counsel.
Which tools can record the evidence behind a classification decision?
Three self-hosted open-source tools map to this evidence, though none calculates compute or makes the classification. Langfuse (MIT) captures traces of model operations, which can support evaluation records and timing data when configured for that purpose. XWiki (LGPL-2.1-or-later) keeps every page change under version control, showing what changed, when and by whom, which suits a decision log. BookStack (MIT) assigns abilities through roles that can be overridden at shelf, book, chapter or page level, which can limit who edits notification files. Confirm each tool's fit against your own training infrastructure before relying on it.
How DeployOpen prepares classification evidence
DeployOpen works on the technical and documentary side of Articles 51 and 52: the self-hosted systems that record how a model is evaluated, how compute is tracked, and how notification and reassessment records are kept. The organization decides its classification position, and an independent assessor or the Commission reaches any formal determination.
How we scope
- Engagements are fixed-scope, with the systems, models and evidence sets agreed in writing before work starts.
- Scope records which models are in view, how cumulative training compute is measured, and who owns each classification decision.
- The written scope names the Annex XIII criteria the organization will document and the benchmark evidence it expects to collect.
- Scope also states who receives the notification and reassessment records and who signs off the internal position.
How we build
- We deploy self-hosted tracing so training and evaluation runs keep inputs, outputs, timing and metadata for later review.
- We set up a probe harness, such as garak, to run adversarial evaluations and keep the JSONL attempt reports and hit logs.
- We configure version-controlled documentation for the classification memo, the compute log and each threshold decision.
- We apply role-based permissions so only approved staff can edit classification records or submit notification drafts.
How we hand over
- We deliver a classification evidence pack covering the compute calculation, the evaluation results and the decision trail.
- We document the two-week notification workflow, including who triggers it, who drafts it and how it is logged.
- We provide a rebuttal file template and a reassessment calendar keyed to the six-month earliest window in Article 52(5).
- We hand over runbooks so the client team can repeat the evaluations and update records without DeployOpen involved.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers when models or thresholds change.
- Retainer work can refresh evaluations after a new model version, a material training run or a Commission list update.
- Questions on whether a formal determination or independent assessment is needed should go to qualified legal counsel and the AI Office guidance.
