Systems engineering has handled complexity for decades. It gave us the methods to build aircraft flight control systems, satellite constellations, and nuclear power plant instrumentation — systems where requirements had to be unambiguous, traceability had to be complete, and verification had to be formal.
AI systems engineering extends that discipline to products where some of the most important behavioral decisions are made by machine learning models rather than deterministic code. That extension turns out to require more than adding AI to the existing checklist.
What Makes AI Systems Different
Classical systems engineering rests on an assumption: if you specify a requirement correctly and implement a system that satisfies it, you can verify that it does. The requirement says the landing gear deploys within 5 seconds of actuation under any condition in the operational envelope. You test it. It either does or it doesn’t.
AI components don’t work that way. A computer vision model that classifies objects in an autonomous vehicle’s path doesn’t satisfy a requirement — it approximates a distribution. Its accuracy varies with lighting conditions, sensor calibration, object novelty, and weather. You can characterize its performance envelope statistically. You cannot specify its behavior deterministically.
This breaks the traditional requirements and verification model in several ways:
Requirements must be probabilistic. Instead of “the system shall detect obstacles greater than 30cm at distances up to 50m,” an AI system requirement might be “the obstacle detection model shall achieve ≥99.7% recall on objects ≥30cm at distances ≤50m under the operating conditions specified in ODD-001, with a false positive rate not exceeding 0.3% at confidence threshold 0.85.”
Failure modes are different. Deterministic systems fail in ways that can be enumerated during design. AI models fail in ways that emerge from the interaction between the model, its training data, and conditions that weren’t represented in that data. Failure mode analysis requires statistical characterization and operational domain definition, not just fault tree analysis.
Traceability has new artifact types. Classical traceability links requirements to design to code to tests. AI systems engineering adds: model behavior specifications, training data requirements, operational design domain (ODD) definitions, performance envelopes by operating condition, and model card documentation.
Verification requires different methods. Testing an AI component requires statistical sampling across the operational design domain, adversarial testing, distributional shift analysis, and runtime monitoring — not just functional test coverage.
The Core Disciplines of AI Systems Engineering
AI systems engineering draws from classical systems engineering and extends it with methods from machine learning engineering, safety engineering, and human factors:
Operational Design Domain (ODD) definition specifies the conditions under which the AI system is designed to operate. For an autonomous vehicle, the ODD might specify road type, weather conditions, time of day, geographic region, speed range, and traffic density. Requirements are valid within the ODD. Behavior outside it is a separate safety concern.
AI model behavior specification translates system-level behavioral requirements into specifications that constrain model development: performance metrics, acceptable error types, confidence thresholds, and behavioral guardrails. This is the interface between systems engineering and the ML team.
Dataset requirements define the data characteristics needed to train a model that meets the behavior specification: distribution requirements, labeling standards, coverage of edge cases, minimum dataset size, and data quality criteria.
Uncertainty quantification requirements specify how the system should characterize and communicate its confidence in AI model outputs — essential for safety architectures where downstream systems or human operators need to understand when AI output is reliable.
Human-machine interface requirements for AI systems are more complex than for deterministic systems because the system’s behavior is variable. Operators need to understand not just what the system is doing but how confident it is and when to intervene.
Why This Matters for Requirements Management
The implications for requirements tooling are direct. A requirements management tool designed for deterministic systems engineering handles hierarchical text requirements with traceability links to verification records. That’s necessary but not sufficient for AI systems.
AI systems engineering requires tools that can:
- Model AI behavioral requirements as structured specifications with quantitative performance parameters, not just prose
- Connect system behavioral requirements to model behavior specifications to dataset requirements in a traceable chain
- Track operational design domain definitions as first-class artifacts with dependencies on requirements that reference them
- Support the distinct verification methods for AI components alongside traditional test-based verification
Tools that were designed for classical systems engineering and have added AI features as an afterthought typically handle the prose requirements well and the AI-specific artifact types poorly — they end up stored in appendices or external documents that break the traceability chain.
Tools built with AI systems engineering as a design consideration from the beginning treat model behavior specifications, ODDs, and performance envelopes as native artifact types within the requirements model.
The Standards Landscape
AI systems engineering is converging on standards, but the landscape is still developing:
Aerospace has been fastest. EASA’s AI roadmap and supplements to DO-178C and DO-254 address machine learning in certified systems. The focus is on model assurance levels, learning assurance, and dataset sufficiency.
Automotive is addressing AI through ISO 21448 (SOTIF — Safety of the Intended Functionality), which specifically covers performance limitations of AI sensors and processing, and through extensions to ISO 26262 for AI-relevant failure modes.
Medical devices are addressed by the FDA’s framework for AI/ML-based software as a medical device, which introduces the concept of predetermined change control plans — recognizing that AI models may need to update post-market.
Defense is addressing AI systems through the Department of Defense’s AI principles and emerging guidance from DO-178C supplemental material for learning systems.
All of these frameworks share common threads: operational domain specification, performance envelope definition, data management requirements, and runtime monitoring. AI systems engineering is converging on a discipline, even if the specific standards differ by domain.
Practical Starting Points
For engineering teams beginning to adopt AI systems engineering practices, the most impactful starting points are:
Define your operational design domain explicitly. Every AI component in your system should have an ODD that specifies the conditions it was designed for. This is where system-level safety requirements for AI components begin.
Write quantitative behavioral specifications for AI components. Prose requirements (“the system shall accurately detect obstacles”) are not sufficient. Specify performance metrics, confidence thresholds, acceptable error types, and test conditions.
Add AI artifact types to your requirements model. If your requirements tool doesn’t have native support for model behavior specifications and ODD definitions, establish a convention for how these connect to your requirements hierarchy.
Involve ML teams in requirements authoring, not just implementation. The interface between systems requirements and AI model specifications should be negotiated between systems engineers and ML engineers, not handed over as a black box specification.
The discipline is developing fast. Teams that establish AI systems engineering practices now are building organizational capability that will matter as AI becomes standard in hardware products across every industry.