Data Is the New Specification – Requirements Engineering in the Era of the EU AI Act

The End of Classic “Given–When–Then”

Whether in traditional specifications or agile product backlogs, requirements engineering relied for decades on a comforting principle: determinism. A good requirement describes system behavior as a clear, single-valued function. In the agile world, acceptance criteria capture this logic succinctly using the familiar Given–When–Then schema: “Given X, when Y happens, then the system executes exactly Z.”

As soon as artificial intelligence enters the picture, this model collapses. Machine learning (ML) models are no longer programmed line by line. Instead, their behavior emerges from training data, model architectures, and learning algorithms. Consequently, a single, rigid Then cannot be defined in advance for every possible input. Instead, we can only specify the statistical performance, boundaries, and operating conditions within which the system must perform.

This is precisely where the EU AI Act comes into play. What was previously a methodological challenge for engineering teams is now a legal obligation: For high-risk AI systems, the EU regulation mandates verifiable quality, transparency, robustness, human oversight, and end-to-end traceability across the entire lifecycle.

The underlying paradigm shift goes even deeper: While traditional specifications describe behavior directly, AI engineering specifications define the properties of the data from which that behavior originates. The well-known adage “Code is Specification” is being replaced by a new reality: Data is the new specification.

From Deterministic Behavior to the Allowed Operating Space

Traditional requirements dictate specific functions: The system shall calculate… The system shall store… The system shall transmit…

In contrast, AI requirements define an allowed operating space¹. Instead of hardcoding every single model decision, you explicitly specify:

• which data may be used to train and validate the model,
• what statistical minimum performance must be achieved in operation,
• which error risks are acceptable and where operational limits lie,
• and how the system must handle uncertainty.

The focus of requirements engineering is shifting from purely functional descriptions to defining quality thresholds, data requirements, and governance rules. Because training data quality directly determines system performance, data analysis becomes an integral part of the specification process.

The EU AI Act Turns Data Into Engineering Artifacts

Article 10 of the EU AI Act establishes strict quality requirements for training, validation, and testing datasets: They must be relevant, representative, largely error-free, and managed in a documented, traceable manner. As a result, datasets are elevated to first-class engineering artifacts with the same status as requirements, architecture models, or test cases.

For requirements engineers, this marks a fundamental shift: Data is no longer just an internal implementation detail managed by data scientists; it is part of the system architecture. Modern AI requirements must now include:

• Documented Data Lineage: Complete traceability regarding dataset origins and transformations.
• Representativeness: Explicit parameters covering real-world operational scenarios (e.g., varying sensor resolutions or environmental conditions).
• Bias Thresholds: Defined metrics to prevent statistical bias.
• Versioning: Documented rules for dataset change management.

In this way, Data Requirements² are emerging as a distinct, indispensable class of requirements.

From Functional Requirements to Risk Controls

The EU AI Act adopts a consistent risk-based approach. Rather than considering risks in isolation during operation only, they are systematically incorporated as early as the specification phase. Each risk analysis leads directly to new, specific system requirements.

These include requirements for human intervention, traceability, robustness and monitoring, for example. Thus, requirements no longer merely describe functions, but also serve as control mechanisms for AI risks.

→ Read more about how the EU AI Act goes beyond traditional risk management in an upcoming blog post.

Statistical Performance Requirements Instead of Binary Correctness

Machine learning systems are rarely 100% ‘correct’ or ‘incorrect’. Its performance is measured in terms of mathematical probabilities. The requirements for AI systems call for measurable statistical metrics, such as precision and recall.

Example: “The image recognition system must achieve a precision of at least 99.2% and a recall of at least 98.5% on the released test dataset, “Dataset_V3″.”

It is equally important to specify the evaluation data. A statistical metric is worthless unless it is documented precisely on which test dataset it was determined.

Non-Functional AI Quality Attributes and the Principle of Uncertainty

The requirements regarding behaviour in cases of uncertainty are particularly important. AI systems require clear boundaries to define when automated decisions are permissible and when human intervention is necessary.

Example: “The quality assurance system may only automatically approve components if the confidence level is at least 90 per cent. Below this threshold, a manual inspection must be performed.”

This turns the required human oversight into a concrete, verifiable requirement.

Generative AI Needs Specifiable Requirements

The same principles also apply to generative AI. For example, quality requirements can be defined for grounding³, guardrails⁴ and human approvals. For business-critical applications, prompts and their versions should also be managed in a traceable manner.

The same principle remains crucial: All factors that significantly influence the behaviour of the AI system must be definable and traceable.

Rethinking Acceptance Criteria: Continuous Evaluation

In traditional requirements engineering, a requirement is considered complete once a test case has been passed. With AI systems, however, this is just the beginning: models age, real-world data changes and usage patterns shift over time. Phenomena such as data drift or concept drift cause a model that was originally perfectly validated to gradually lose accuracy during operation.

Acceptance criteria must therefore also specify

• when models should be revalidated using current field data, and

• which thresholds should trigger monitoring, retraining or re-approval.

Thus, the acceptance of an AI requirement evolves from a one-time check into a continuous quality process.

Logging and Audit Evidence as Core Requirement Building Blocks

For high-risk AI, logging becomes an integral part of the specification process. Model and dataset versions, relevant inputs, confidence values, decisions and human interventions must all be documented in a traceable manner. This information can then be used to conduct audits, error analyses, and compliance assessments.

New Standards Provide Methodological Grounding

While the EU AI Act specifies the desired outcome, international standards provide the methodological how. The most important guidelines for requirements engineers include the following:

• ISO/IEC 42001 Information technology – Artificial intelligence – Management system,
• ISO/IEC 5338 Information technology – Artificial intelligence – AI system life cycle and
• ISO/IEC 25059 Software engineering – Systems and software Quality Requirements and Evaluation (SQuaRE) – Quality model for AI systems.

Together, these standards bridge the gap between regulatory laws and day-to-day engineering practice.

The Expanded Traceability Chain for AI Systems

The more that requirements, data sets, model versions, risks and tests become interrelated, the more challenging it is to reliably track these relationships using Excel and Word.

For traditional software, the familiar chain (requirements → architecture → tests) was sufficient. However, for an auditable AI system under the EU AI Act, traceability must be expanded to include all data- and model-related artefacts.

Only this seamless integration can prove beyond a doubt to an auditor which data and validations a specific AI decision was based on. If this chain is broken at any point, for example, because a data set is incompletely documented, serious liability and compliance risks arise immediately.

Managing AI Requirements in objectiF RPM

Managing this influx of new artifacts and dynamic dependencies in static Word documents or Excel sheets is no longer viable.

Tools like objectiF RPM allow teams to manage AI specifications as living, interconnected artifacts throughout the development lifecycle:

• Specific requirement types: Define custom artefacts for data requirements, model requirements, prompt specifications and risk controls.
• Structured quality metrics: Centrally manage statistical thresholds and link them to test cases.
• Automated traceability: Link requirements directly to AI models, dataset versions and test reports.

Conclusion

The EU AI Act significantly broadens the scope of requirements engineering for AI systems. As well as functional requirements, data quality, performance limits, risks, human intervention and evidence must now also be treated as verifiable requirements.

This increases the number of artefacts and dependencies simultaneously. Therefore, end-to-end traceability, from requirements through to data, models, testing, and operation, is crucial.

objectiF RPM can help with this. It enables you to capture AI requirements in a structured manner, link them together, and manage changes in a traceable way.

Would you like to set up your requirements engineering for AI systems in a legally compliant manner?

In a personalized live presentation, learn how to use objectiF RPM to structure advanced AI requirements, integrate data artifacts, and ensure traceability.