Webinar Recap: Future-Proofing Physical AI Systems for Certification Readiness

Physical AI systems are advancing across robotics, autonomous systems, industrial automation, and mobility. As organizations move these systems toward deployment, safety, software quality, and certification readiness need to be addressed throughout the product lifecycle.

This webinar brought together Matthias Haynl, Business Unit Manager, Functional Safety & Cyber Security, and Bouthaina Abdou, AI Deputy Manager, from TÜV Rheinland, Jan Aarsaether, Business Development at Qt Group, and Erik Reynolds, Founder and Chairman of Reynolds & Moore.

The hour-long discussion focused on when certification planning should begin, how AI changes the safety lifecycle, what evidence assessors need, and how organizations can manage systems that continue to evolve.

Watch the Full Webinar Recording

Key Takeaways From TÜV Rheinland, Qt Group, and Reynolds & Moore

Begin With Certification Readiness in Mind
“Start with safety at the whiteboard, not in the test lab,” Erik Reynolds said.

Certification readiness begins as teams define a system’s intended use, architecture, and technologies. Waiting until development is nearly complete can reveal structural gaps after major design decisions have already been made.

Matthias Haynl described certification as a system-level activity. An assessment considers the AI, software, hardware, interfaces, intended use, and lifecycle controls rather than evaluating an AI model in isolation.

TÜV Rheinland’s certification path begins by establishing the system scope and identifying applicable standards. A concept assessment then examines the safety architecture, interfaces, and planned measures for avoiding or controlling faults. During the main assessment, teams must demonstrate that those measures were implemented and supported by complete, traceable, and reproducible evidence. Certification follows once the requirements have been met, while later changes to the hardware, firmware, or AI model may require reassessment or recertification.

Safety specialists, quality personnel, and engineers from each discipline should work together throughout that process. Bringing a safety or compliance engineer in near the end can require teams to reconstruct development evidence or redesign parts of the system.

Account for the AI Lifecycle
AI introduces considerations that traditional functional safety methods do not address on their own. Data collection, preprocessing, model training, verification, validation, and the hardware running the model must be considered alongside the broader system lifecycle.

Bouthaina Abdou emphasized the relationship among data, model performance, and hardware. Larger datasets and model changes can affect computing needs, while insufficient hardware can create latency or degrade performance. Those connections need to be considered as part of the system architecture rather than treated as separate development decisions.

Data must also represent the system’s intended operating conditions. A model developed and evaluated for a controlled warehouse cannot automatically be expected to perform the same way outdoors. If the operational design domain changes, teams may need to adjust the data, model, hardware, and supporting evidence.

The discussion also introduced Application Usage Levels, or AULs, in the developing ISO/IEC TS 22440 series. Under the distinction, AUL A1 applies when failure of the AI component can lead directly to a hazardous outcome. In AUL A2, AI supports or monitors conventional safety logic rather than serving as the decisive element in the safety function.

That classification affects the architecture, required metrics, and assessment pathway. Where practical, separating AI-specific functions from conventional safety components allows teams to apply established functional safety methods to deterministic parts of the system while directing additional evaluation toward the AI component.

Keep Established Software Practices in the Lifecycle
AI-specific evaluation does not replace established software quality practices.

Jan Aarsaether explained that the traditional V-model connects requirements and architecture with component, integration, system, and acceptance testing. Static analysis, code coverage, architecture verification, and functional testing can help teams identify problems early and maintain traceability between the intended design and its implementation.

Introducing those practices and tools early allows testing to progress alongside development. Automated quality gates can also identify issues as code is added or changed, helping teams maintain evidence through more frequent development cycles.

Erik Reynolds described the traditional lifecycle as the foundation of the safety case. AI requires a complementary lifecycle that adds AI-specific requirements, empirical evidence of system behavior, and evaluation of robustness, uncertainty, and operating limits.

Build Evidence Beyond Accuracy
Accuracy alone does not demonstrate that an AI system is trustworthy.

Erik Reynolds illustrated this point using the example of a perception model with 99.999% object detection and classification accuracy. Even at that level, teams would still need evidence showing how the model performs across the conditions and edge cases within its defined operating environment.

AI models may encounter rare conditions or combinations of inputs that were not adequately represented during development. Teams need evidence showing how the system behaves under normal conditions, at the boundaries of its intended use, and in rare or unexpected situations.

That evaluation requires more than measuring average performance. It must examine observable behavior, uncertainty, robustness, and how the wider system responds when conditions move outside the validated range.

The central point from the discussion was that trust comes from structured behavioral evidence, not accuracy alone.

Plan for Continued Change
Certification readiness continues after an initial assessment. AI-enabled systems may change as models are retrained, datasets expand, hardware is updated, or operating environments evolve.

Certification evidence is tied to a defined use case, model version, hardware configuration, software version, and operating environment. A change to any of those elements may require updated evidence or additional assessment.

A model that continues to learn or is retrained must be handled through controlled change management. Each resulting version may require further assessment or recertification. Teams need to reproduce test results, trace evidence to requirements, and show how each update affects the system’s safety case.

Teams must also account for the context-specific nature of certification. Evidence developed for one application or operating environment cannot automatically be transferred to another.

Preparing for a Developing Standard
Current functional safety standards do not yet provide a certification path for AI performing safety-related functions in machinery and robotics. ISO/IEC TS 22440 is being developed to help address that gap.

Organizations can prepare by defining intended use and operating limits, establishing clear ownership, managing data quality, testing system behavior, and documenting decisions throughout development. Beginning that work before a formal assessment can reduce the risk of major changes later in the product lifecycle.

Continue the Conversation
Have questions about certification readiness for physical AI systems? Contact one of the presenters.

related posts