Building a Defensible Safety File

Intelligent machines, encompassing everything from collaborative robots on factory floors to autonomous medical diagnostic systems and AI-powered public infrastructure, present a fundamental challenge to traditional product safety paradigms. The challenge lies not merely in the complexity of the hardware but in the adaptive, learning, and often opaque nature of the software and data-driven components that govern their behaviour. Consequently, the documentation required to demonstrate conformity with European regulations—the safety file—is no longer a static collection of manuals and certificates. It is a dynamic, living dossier that must chronicle the machine’s entire lifecycle, from initial risk conceptualisation to decommissioning. Building a defensible safety file requires a synthesis of rigorous engineering practice, deep legal understanding, and a pragmatic appreciation for how intelligent systems fail and evolve.

This article addresses the core components of a safety file tailored for intelligent machines, navigating the intersection of the EU’s Artificial Intelligence Act (AI Act), the Machinery Regulation (EU) 2023/1230, and the General Product Safety Regulation (GPSR). It is written for the professionals—engineers, compliance officers, legal counsel, and system architects—who are tasked with ensuring that these systems are not only innovative but also demonstrably safe and legally compliant within the European Union.

The Concept of the Defensible Safety File

A “defensible” safety file is one that can withstand scrutiny from a Notified Body, a national market surveillance authority, or, critically, legal proceedings following an incident. It is not enough for the file to exist; it must be coherent, traceable, and complete. It serves as the primary evidence of conformity. In the context of intelligent machines, the file must bridge the gap between deterministic engineering principles and probabilistic AI behaviours. It must answer not only “what happens if a component fails?” but also “what happens if the model encounters data it has never seen before?”

The regulatory landscape is shifting from a purely ex-ante (pre-market) assessment to a model of continuous compliance. The AI Act, in particular, introduces obligations for post-market monitoring and the reporting of serious incidents. Therefore, the safety file is the central repository for the evidence that supports both initial conformity and ongoing regulatory adherence.

Legal Foundations and Applicable Frameworks

Understanding what belongs in the file begins with identifying the applicable legal framework. For most intelligent machines, two key regulations intersect:

• The Machinery Regulation (EU) 2023/1230 (MR): This regulation, which replaces the Machinery Directive, applies to machinery with integrated AI that performs a function with a high degree of autonomy. It explicitly addresses machinery that can modify its intended function, making it highly relevant for intelligent machines. It mandates a risk assessment and the integration of safety features into the design.
• The Artificial Intelligence Act (AI Act): This is the world’s first comprehensive legal framework for AI. If the intelligent machine is considered an AI System (or a High-Risk AI System, specifically), it must comply with strict requirements regarding data quality, transparency, human oversight, and robustness. For machinery that constitutes a High-Risk AI System, the conformity assessment may require the involvement of a Notified Body.

Furthermore, the General Product Safety Regulation (GPSR) acts as a horizontal safety net, ensuring that all products placed on the market are safe. It is particularly relevant for addressing risks that may emerge from unexpected usage or evolving contexts.

Core Pillars of the Safety File

A defensible safety file is structured around a set of core pillars. These are not isolated documents but interconnected pieces of evidence that tell the story of the machine’s safety.

Risk Assessment: The Living Document

The risk assessment is the bedrock of the safety file. For intelligent machines, this cannot be a one-time, static analysis performed at the end of development. It must be a living document that evolves alongside the system.

From Deterministic to Probabilistic Hazards

Traditional risk assessment (e.g., ISO 12100) focuses on foreseeable misuse and component failure. For intelligent machines, we must expand this to include:

• Algorithmic Hazards: What are the consequences of a false positive or false negative in the AI’s decision-making? For a medical diagnostic AI, a false negative could be life-threatening. For a collaborative robot, a false positive could cause erratic and unsafe movements.
• Data-Related Hazards: The risk of model drift, bias, or degradation due to changes in input data quality. The assessment must consider the provenance, representativeness, and quality of the training, validation, and testing datasets.
• Interaction Hazards: How might a human operator, a third party, or another machine interact with the system in an unanticipated way? This includes adversarial attacks designed to manipulate the AI’s perception or decision-making.

The risk assessment must be traceable. Every identified hazard must be linked to a specific technical implementation, a mitigation measure, and a piece of verification evidence. This traceability is what makes the assessment defensible.

Test Evidence and Verification & Validation (V&V)

Test evidence demonstrates that the mitigations identified in the risk assessment are effective. For intelligent machines, this requires a multi-layered approach to V&V that goes beyond standard unit testing.

Simulation, Real-World Testing, and Adversarial Scenarios

Regulators increasingly accept simulation as a valid form of evidence, particularly for systems like autonomous vehicles where real-world testing at scale is impractical or unsafe. However, the safety file must contain:

• Simulation Validation: Evidence that the simulation environment accurately reflects the real world (the “digital twin” concept). This includes physics fidelity, sensor noise modeling, and the representation of diverse environmental conditions.
• Real-World Test Logs: For physical machines, logs from physical tests must be preserved. These logs should include sensor data, system states, and environmental conditions, providing a verifiable record of the test execution.
• Adversarial and Edge Case Testing: The file must demonstrate that the system has been tested against “edge cases” and potential adversarial inputs. This is particularly important for High-Risk AI systems, where robustness against errors and manipulation is a legal requirement.

Regulatory Interpretation: Under the AI Act, robustness must be proven “to address errors and inconsistencies” that may arise during the system’s lifecycle. This implies that test evidence must show the system’s performance not just in ideal conditions, but under stress, data drift, and unexpected inputs.

Maintenance, Monitoring, and Post-Market Surveillance

Intelligent machines, particularly those with learning capabilities, are not “finished” at the point of sale. The safety file must contain a clear plan for their maintenance and monitoring throughout their operational life.

The Feedback Loop and Model Retraining

This section of the file details the mechanisms for:

• Performance Monitoring: How will the system’s safety-critical performance be monitored in the field? This could involve telemetry, log analysis, or specific performance metrics tracked over time.
• Incident Reporting: A clear protocol for capturing, analyzing, and reporting “serious incidents” as defined by the AI Act. This is a strict legal obligation for providers of High-Risk AI Systems. The file should contain templates and procedures for these reports.
• Model Update and Retraining Protocol: If the machine uses a learning model, the file must describe the process for updating it. This includes how new data is collected, validated, and used for retraining, and how the updated model is verified before deployment. This process must be controlled to prevent the introduction of new risks.

The distinction between a “minor” software update and a “substantial modification” is critical. A substantial modification, as defined by the AI Act and Machinery Regulation, triggers a new conformity assessment. The safety file must contain the criteria and decision-making process for classifying updates.

Training, Instructions, and Warnings

Human oversight is a key risk mitigation for intelligent machines. The documentation provided to users is therefore a critical safety component.

Intended Purpose and Foreseeable Misuse

The instructions for use must be exceptionally clear and specific to intelligent systems. They should include:

• Defining the Intended Purpose: This is a crucial legal concept. Vague definitions can lead to regulatory non-compliance. The instructions must precisely define the operational context, the types of data the system can handle, and its limitations.
• Training Requirements: The file must specify the level of training and competency required for operators and supervisors. For AI systems, this may include training on how to interpret the system’s outputs, how to override its decisions, and how to recognize signs of model drift or malfunction.
• Transparent Warnings: Warnings must go beyond physical hazards. They must address the limitations of the AI, such as its potential for bias or its inability to handle certain edge cases. For example, a medical AI tool must warn that it is an assistive tool and not a replacement for a clinician’s judgment.

Under the AI Act, transparency is a legal requirement. The system must be designed to ensure its outputs are interpretable by humans, and the instructions must support this. The safety file should contain the rationale for the chosen level of explainability and the evidence that users can understand the system’s decisions.

Change Control and Configuration Management

A defensible safety file is underpinned by a robust change control process. Every component of the intelligent machine—hardware, firmware, AI model, training data—must be version-controlled and traceable.

Traceability from Data to Deployment

The change control section of the file should demonstrate:

• Versioning: Unique identification of every version of the software, model, and dataset used in production. This allows for precise identification of the system state in the event of an incident.
• Impact Analysis: A process for assessing the safety impact of any proposed change. For a model update, this analysis must consider whether the change affects the risk assessment or requires new V&V activities.
• Approval Gates: Clear criteria for who must approve changes, particularly those that affect safety-critical functions. This is a key element of the “quality management system” required by the AI Act for High-Risk AI Systems.

This rigorous approach ensures that the safety file remains a reliable record of the specific product configuration that was placed on the market and assessed as safe.

EU-Level vs. National Implementation: Navigating the Nuances

While the AI Act and Machinery Regulation are EU-wide regulations, their implementation and enforcement involve national authorities. Understanding this interplay is essential for maintaining a defensible file.

The Role of Notified Bodies and Market Surveillance

For High-Risk AI systems integrated into machinery, a Notified Body is often required. The safety file is the primary document they will review. It must be structured to facilitate their assessment, mapping directly to the essential requirements of the relevant regulations. The file should be organized to show clear evidence for each requirement, such as:

• Requirement: Robustness against errors. Evidence: Adversarial testing report.
• Requirement: Transparency to the user. Evidence: User manual and interpretability analysis.

Post-market surveillance is conducted by national Market Surveillance Authorities (MSAs). They have the power to request the safety file at any time. If the file is disorganized, incomplete, or lacks traceability, the manufacturer faces significant legal and commercial risk. The AI Act harmonizes these powers, but the specific investigative focus may vary between, for example, the French CNIL (data protection authority) and the German Federal Institute for Occupational Safety and Health (BAuA).

National Specificities in Enforcement

Even with harmonized regulations, national interpretations can differ. For instance, Germany’s “Technische Regeln für Betriebssicherheit” (TRBS) may provide more detailed guidance on how to assess the risks of AI in machinery, which should be reflected in the risk assessment section of the safety file. Similarly, the UK’s approach post-Brexit (with its own AI Safety Institute and evolving regulatory framework) requires a separate consideration for products placed on the UK market.

A defensible safety file anticipates this. It is written with a level of detail and justification that would satisfy the most stringent national authority. It avoids ambiguity and relies on established standards (e.g., ISO/IEC 23894 for AI risk management, ISO 10218 for robot safety) to provide a common technical language that is understood across Europe.

Practical Implementation: Building the File

Creating this dossier is not a documentation task to be left until the end of a project. It must be an integral part of the engineering workflow.

Integrating Documentation into the Engineering Workflow

The most effective approach is to treat the safety file as a product of the development process itself, not an afterthought. This can be achieved by:

• Using a Requirements Management Tool: Tools like Jama Connect, DOORS, or modern ALM platforms can link risks to requirements, design elements, and test cases, automating much of the traceability needed for the file.
• Automating Evidence Collection: CI/CD pipelines can be configured to automatically generate and archive test reports, code analysis results, and model performance metrics, feeding them directly into the safety file repository.
• Versioning Everything: Using systems like Git not just for code but also for documentation, risk assessments, and test plans ensures that the entire history of safety decisions is preserved and auditable.

The “Defensible” Mindset

When compiling the file, constantly ask: “If an incident occurred five years from now, would this document prove we took all reasonably practicable steps to ensure safety?” This mindset shifts the focus from mere compliance to creating a robust legal and technical defense. Every claim must be backed by evidence. Every assumption must be stated and justified. Every risk must be assessed and mitigated or accepted with clear rationale.

In the era of intelligent machines, the safety file is the definitive record of a product’s integrity. It is the bridge between the complex, probabilistic world of AI and the deterministic, high-stakes requirements of European product safety law. Building it with the precision, foresight, and rigor outlined here is not just a regulatory hurdle; it is a fundamental engineering discipline.