A mixed-method survey posted to arXiv on 18 May 2026, From Obligation to Specification: A Survey on Validating EU AI Act Requirements in RE, reports that the organizations responsible for complying with the EU AI Act mostly lack the Requirements Engineering machinery that conformity assessment presumes: structured capture of regulatory obligations, propagation of those obligations into projects, and lifecycle-wide traceability linking each risk-management measure to a validated model property. The practical consequence is direct. ML teams shipping high-risk systems into the EU will be assessed against an evidence chain their pipelines do not currently produce, and the paper, a preprint, not peer-reviewed, locates the gap primarily in organizational process, even as its participants actively want tooling to help close it.
What does EU AI Act conformity assessment demand of the specification layer?
Conformity assessment under the Act operates on documents and traces, not on model behavior observed in a lab, so what gets assessed is the quality of a team’s requirements pipeline rather than the model itself. That distinction is the one ML organizations keep missing. A model can perform well on every internal benchmark and still fail assessment if the submitting organization cannot show, in writing, which obligation generated which requirement, which requirement generated which validation target, and which test result closes the loop.
The survey’s authors, a team spanning Requirements Engineering and machine learning research, put the problem in lifecycle terms. Compliance is not a gate at the end of development. It is a chain that starts when a legal obligation is captured, continues as that obligation is translated into a testable requirement, and persists as the requirement is re-validated every time the model, the data, or the regulation itself changes. Each link needs an artifact. The chain breaks if any link exists only in someone’s head, in a slide deck, or in a commit message nobody can trace back to a legal text.
The survey’s central empirical finding is that this chain is broken in practice. According to the abstract, participants across RE, data science, development, and compliance roles view the EU AI Act as highly relevant to their work, yet structured mechanisms to capture regulatory obligations, propagate updates into ongoing projects, and maintain lifecycle-wide traceability and evidence are “often missing” in their organizations. High perceived relevance paired with absent infrastructure is a specific and uncomfortable combination: these are not teams that ignore the regulation, they are teams that acknowledge it and still have no pipe connecting the legal text to their model registry.
One clarification before going further. The survey’s abstract frames the obligations generically, naming transparency, risk management, and traceability without enumerating specific provisions of the Act. What the survey does establish, on its own evidence, is the artifact gap and practitioner attitudes toward closing it.
Why do stochastic models strain specification-based conformity?
The structural problem is that conformity assessment inherits the assumptions of traditional software certification, where a requirement states a behavior and a test confirms the behavior, while machine learning systems are defined by the property that their behavior is learned and probabilistic rather than specified and fixed. Machine learning, by standard definition, is the development and study of statistical algorithms that learn from data and generalize to unseen data. Generalization is the point of the technology. It is also the property that makes a sentence like “the system shall produce output X under condition Y” impossible to validate in the way a notified body would validate the same sentence about a PLC or a flight-control routine.
Traditional requirements engineering assumes a deterministic implementation underneath the requirement. The spec says the function returns a value in a range; the function either does or does not, reproducibly, every time. An ML model under the same spec regime returns a distribution. The honest requirement for a classifier is not “the system shall flag fraudulent transactions” but “the system shall maintain recall above a threshold on a defined population, under a defined drift budget, measured by a defined procedure.” That second sentence is harder to write, harder to test, and, critically, there is no agreed methodology for validating it. The survey identifies this translation problem as the core of the obligation-to-specification gap; what it does not and cannot supply is a ratified method for specifying stochastic performance bounds, because no such consensus method exists yet in the field it surveyed.
This is where the compliance burden migrates. When the model cannot deterministically satisfy a specification, the specification layer itself becomes the assessed artifact. Assessors end up evaluating whether the team’s stated performance bounds are well-formed, whether the drift thresholds are monitored, whether the evidence trail connects each risk-management measure to a measured model property. The mathematics of the situation has been understood for a long time, the vocabulary of stochastic processes dates to the 1930s, but regulatory frameworks built for deterministic systems are only now colliding with it at assessment time. Teams that treat the model as the compliance surface are optimizing the wrong layer.
What does lifecycle-wide traceability look like inside an ML pipeline?
Lifecycle-wide traceability means every regulatory obligation in scope can be followed forward to a requirement, forward again to a validation result on the deployed model, and backward from any production incident to the obligation it implicates, with artifacts at each step. The survey treats this closed loop as the definition of readiness, and its conclusion sketches minimum requirements for what the authors call an EU AI Act-ready closed-loop approach.
Concretely, for an ML pipeline, the loop has more moving parts than it does for conventional software, and it helps to enumerate them. At the front sits obligation capture: a structured record, not a PDF in a compliance inbox, mapping each applicable provision of the Act to an owner and a system component. Next is propagation: when the regulation is amended, when guidance lands, when the model is retrained on new data, the record has to update and the update has to reach the project. The survey’s finding that propagation mechanisms are “often missing” is, in operational terms, a finding that most organizations have no answer to the question “which of our requirements changed when the legal interpretation changed last quarter.”
The middle of the chain is requirement formulation, where the stochastic problem bites. A requirement over a model has to name the property (a performance bound, a robustness margin, a fairness constraint), the population and data distribution it holds over, the measurement procedure, and the threshold that constitutes failure. Teams that have only ever written functional requirements for deterministic services do not have templates for this, and the survey’s participants, despite their stated confidence in the Act’s relevance, largely work in organizations without structured mechanisms to produce them.
The back of the chain is evidence: validation results, monitoring outputs, and post-deployment measurements that must be organized so an assessor can walk the trace in either direction. This is the part ML pipelines actively work against. Retraining overwrites the artifact that was validated. Data pipelines mutate the population the requirement was stated over. Experiment-tracking systems record metrics but rarely record which legal obligation a metric discharges. The evidence exists in fragments, a model card here, a monitoring dashboard there, an evaluation harness somewhere else, and the survey’s finding that participants want tooling for “organizing evidence” is best read as a finding that the fragments currently do not assemble into a chain.
None of these artifact types are exotic. What is new is the constituency: ML teams, whose pipelines were built for iteration speed, now have to operate the artifact discipline of a certified industry, on systems whose stochastic behavior makes the discipline harder to apply than it is in the industries that invented it.
Where do LLM-based validation tools fit, and what safeguards do practitioners want?
The survey positions LLM-based agentic tools as a plausible assistive layer for obligation-to-requirement translation, and its participants agree with three specific uses while rejecting full automation. According to the abstract, participants see LLM-based tools as promising for mapping obligations to requirements, for assessing coverage of the requirement set against the legal text, and for organizing evidence. Those are exactly the three stages of the chain where the work is voluminous, textual, and pattern-matching in nature: reading a provision, finding the requirements it touches, and checking whether every requirement points back at a provision.
The three accepted uses share a property: the LLM proposes, a human disposes. Mapping suggestions can be reviewed. Coverage gaps can be confirmed or dismissed. Evidence organization can be audited. Participants’ strong concerns about full automation, and their stress on safeguards, land on the failure mode anyone who has graded LLM output against legal text would predict: a fluent mapping that is subtly wrong is worse than no mapping, because it enters the trace with false authority. In a conformity-assessment context, a hallucinated link between an obligation and a requirement is not a productivity loss. It is a defect in the assessed artifact, discoverable by the assessor, and corrosive to the credibility of everything submitted alongside it.
There is also a recursive irony the survey does not dwell on but practitioners will notice: the proposed remedy for AI Act compliance gaps is itself an AI system with stochastic outputs, subject to the same specification problems described above. An LLM validation tool used in the compliance pipeline of a high-risk system inherits the evidentiary questions of that pipeline. Teams adopting such tooling should expect assessors to ask how the tool’s mappings are validated, which brings the argument full circle to human review as the safeguard of record.
The authors’ hypothesis is that agentic tooling can help close the spec-translation gap. The surveyed practitioners accept the hypothesis only in its assistive form. That is the mature position, and teams building tooling in this area should read the finding as a product requirement: the market wants a reviewer-augmenting instrument with explicit safeguards, not an autonomous compliance agent, and a vendor selling the latter will be selling against the stated preferences of the people who have to sign the submissions.
What should ML teams build now?
Build the Requirements Engineering pipeline now, with humans at the validation points, and deploy LLM assistance where the survey’s participants say it helps; waiting for a fully automated toolchain means waiting for something the practitioners closest to the problem say they do not trust. The sequence matters. Obligation capture and propagation are organizational mechanisms, and they are the pieces the survey finds “often missing.” Standing up a structured register of applicable obligations, assigning ownership, and wiring updates into project backlogs requires no new technology and no resolution of the stochastic-specification debate. It is the cheapest part of the gap and the one with no tooling excuse.
The harder, longer-lead work is requirement formulation over stochastic behavior: deciding, per system, which model properties the risk-management measures depend on, how those properties are bounded and measured, and what drift invalidates the validation. No consensus methodology exists, which means teams that start now are writing methodology their assessors will help define, and teams that start later will have methodology handed to them. The survey’s small sample cannot tell anyone which specific artifact set a notified body will accept, because the field has not converged on one; that ambiguity is an argument for engaging early, not for waiting.
The limitations deserve equal weight in the decision. The evidence base is ten interviews and fifteen survey responses, self-reported and exploratory. The publicly available abstract does not enumerate the Act’s articles, does not name specific techniques such as model-card-as-requirement patterns or distributional property specifications, and does not document notified-body rejection criteria; claims about those specifics require the full paper and, ultimately, assessment practice that does not yet exist. The paper is a preprint. What survives those caveats is narrower and still useful: the organizations surveyed recognize the EU AI Act as binding on their work, lack the traceability infrastructure conformity assessment presumes, and want LLM tooling that assists human validators rather than replacing them. Teams that build to that specification, RE pipeline first, automation assistive and safeguarded, performance bounds treated as first-class requirements, will be aligned with the best available evidence on where assessment is heading, and honest about how thin that evidence still is.
Frequently Asked Questions
Does the EU AI Act apply to ML models trained outside the EU but deployed within member states?
The Act applies to providers placing high-risk AI systems on the EU market or putting them into service, regardless of where the provider is established. It also applies to users of high-risk AI systems located within the Union. This territorial scope means a US-based startup training models in California must still produce the traceability artifacts if it deploys those models to customers in Berlin or Paris.
How does the EU AI Act’s traceability requirement differ from standard MLOps model registry practices?
Standard MLOps registries track version, metrics, and deployment status, but rarely link specific model properties back to legal provisions. The Act requires a closed loop where each risk-management measure traces to a validated model property and a specific legal obligation. Most registries do not store the legal text or the mapping logic, creating a gap between technical versioning and regulatory evidence.
What is the risk of using LLMs to generate the traceability artifacts themselves?
LLMs can hallucinate mappings between legal text and technical requirements, creating false authority in the evidence chain. Since the Act requires validated model properties, a hallucinated link is a defect in the assessed artifact. Assessors will likely scrutinize the provenance of these mappings, making human-in-the-loop verification essential to maintain credibility during conformity assessment.
Can a single model card satisfy the lifecycle-wide traceability requirement for a high-risk system?
A model card alone is insufficient because it typically captures a snapshot of model behavior rather than the full traceability chain. The Act requires evidence of obligation capture, propagation, and continuous validation. A model card does not show how updates to the regulation triggered changes in the model’s requirements or how drift thresholds were monitored over time. Teams must supplement model cards with structured registers and validation logs.
