AI
Acceptance of a robotic cell with AI: the 5 documents your client will ask you for
Your client is accepting delivery of a robotic cell with an integrated AI component. Before signing the acceptance report, their quality team and HSE manager will go through the cell with a fine-tooth comb. Here are the five documents they will require and how to prepare them without improvising at the end of the project.
Documentation pressure on AI robotic cell deliveries has tightened since 2025. Two concrete reasons: the Machinery Regulation 2023/1230 strengthens the obligation of result on the integrator, and the EU AI Act imposes traceability requirements on any AI system classified as high-risk (Annex III). The deadline for high-risk systems embedded in machinery: August 2026. Your automotive, food processing, and logistics clients are already incorporating these requirements into their acceptance specifications, sometimes before their own procurement teams have updated their templates.
This guide covers the five concrete documents you will need to produce. Not general legal principles. The actual deliverables the client project manager will put on the table at the FAT or SAT.
1. The AI Model Qualification Report
The client wants to know whether your model has been tested under conditions close to their real operating environment. This is not a question of global accuracy on the training dataset. It is a question of behavior at the edges: greasy parts, variable lighting, product references never seen during training.
An AI model qualification report covers at minimum:
Performance on a dataset representative of the target production environment, not just training data
The explicit validity domain: which references, which lighting conditions, which throughput range
Out-of-distribution (OOD) test results: what does the model do when it encounters a situation it has never seen?
Per-prediction reliability metrics, not just aggregate metrics
The limit of the standard report
A report based on a global accuracy of 97% says nothing about the model's behavior on the remaining 3%. It also doesn't say whether the model "knows when it doesn't know." A client with high quality standards, automotive or pharmaceutical will raise this point. Every time.
Per-prediction reliability changes that. For each inference, an individual confidence score is produced, making it possible to state in the report: "Across 12,000 test cycles, 98.7% of predictions had a confidence score above the operational threshold. The 1.3% below the threshold triggered escalation to the operator." That level of granularity is what demanding clients expect in 2026.
2. AI Risk Management Documentation (Article 9, EU AI Act)
Article 9 of Regulation EU 2024/1689 requires the provider of a high-risk AI system to establish and maintain a risk management system covering the entire lifecycle. For an integrator delivering a robotic cell, you are in the position of a deployer — and sometimes a provider if you trained the model.
This document must cover:
Identification of potential failure scenarios
Associated mitigation measures: emergency stop, safety zone, human oversight, minimum confidence threshold
Evidence that these measures have been tested
The real-time monitoring protocol for post-deployment
The difference between Machinery Directive risk analysis and AI risk management
Your client knows EN ISO 10218 or ISO 13849 risk analysis. What they additionally expect is that you document the risks specific to the AI component. The two frameworks do not cover the same ground.
Machinery Directive analysis covers mechanical, electrical, and ergonomic risks. AI risk management covers silent model failures: erroneous detection without any alarm signal, model drift in production, unexpected out-of-distribution behavior. These are risks your client cannot see on the cell floor. They are asking you to have mapped them.
Dimension | Machinery Directive Risk Analysis | AI Risk Management (Article 9) |
|---|---|---|
Scope | Mechanical, electrical, ergonomic risks | AI model failures, out-of-distribution behavior |
Method | FMEA, ISO 13849 | Failure scenario mapping, OOD testing |
Compliance evidence | CE marking, technical file | EU AI Act technical documentation, monitoring logs |
Responsibility | Integrator (Machinery Regulation 2023/1230) | Integrator as deployer (EU AI Act Article 26) |
3. Per-Inference Traceability Logs (Article 12, EU AI Act)
Article 12 of Regulation EU 2024/1689 requires that every high-risk AI system generate event logs enabling the reconstruction of operational sequences. For a robotic cell: for every prediction driving a physical action in a safety-relevant context, a timestamped log must be retained.
An Article 12-compliant log contains at minimum:
The inference timestamp (millisecond precision)
The prediction identifier
The prediction confidence score
The triggered action or refusal to act
Operational context: product reference, cell identifier, operating mode
Why existing logs don't cover this
SCADA histories, PLC logs, machine supervision journals: none of these meet this requirement. They record machine states and sensor readings. They do not record the AI component's reliability metrics at the moment of the decision.
The difference matters when an incident occurs. If a robotic arm causes damage and your client needs to reconstruct the sequence in front of a supervisory authority or their insurer, the question will be: "At what confidence level did the AI model decide to act?" Without a per-inference reliability log, the answer is: "We don't know." With one, the answer is traceable.
Black-box-compatible systems like TrustalAI generate these logs at the reliability layer level, without modifying the underlying model or the industrial process. Each inference produces a structured record including the confidence score, ready for audit and Article 12 compliance. Latency: under 100ms in normal production, 20ms on edge deployment.
4. The CE Technical File and Machinery Regulation (EU 2023/1230)
Your client requires this document for every machine. But integrating an AI component changes what the file needs to cover. The Machinery Regulation 2023/1230 explicitly brings AI systems into the scope of conformity assessment.
A CE technical file for a robotic cell with AI includes:
Risk assessment integrating the AI component's behavior — not just the mechanics
Justification of the operational confidence threshold chosen: why this threshold, on what testing basis
Evidence that the human oversight system is functional (Article 14, EU AI Act)
The CE declaration of conformity
What changes with AI in the file
Until recently, a CE file for a picking cell documented deterministic behavior: the arm does X when the sensor detects Y. With an AI component, that is no longer entirely the case. The documentation must justify how model uncertainty is controlled and how human oversight kicks in when confidence is insufficient.
This point is regularly underestimated at the design stage. Automotive and food processing clients with formal supplier qualification processes, PPAP, IATF 16949 will raise it. Better to document it before the acceptance review than to negotiate it after.
5. The Continuous Monitoring and Model Maintenance Plan
An AI model deployed in production is not static. Conditions change: new product references, new raw material suppliers, shifts in lighting conditions or throughput. Model drift always comes eventually. What your client wants to know: how you detect it before it causes an incident, and how you update the model without stopping production.
The continuous monitoring plan documents:
The drift detection protocol: which indicators, what frequency, who gets alerted
Alert thresholds and stop thresholds
The model update procedure: regression testing, validation before deployment, rollback capability
Post-acceptance responsibilities: you, the client, or a third party
The contractual question that will come up
"Who is responsible if the model drifts six months after delivery and causes a line stoppage?"
This is as much a contractual scope question as a technical one. Integrators who haven't documented this upfront end up in an ambiguous position. Those who provided a monitoring plan with explicit thresholds have an answer and a form of protection.
Post-deployment monitoring doesn't require continuous retraining. A plug-and-play reliability layer can continuously detect drift in input distributions without accessing training data or modifying the model. The alert signal arrives before performance visibly degrades on the production line.
Per-Prediction Reliability vs Post-Mortem Monitoring: The Distinction Your Client Will Make
A common source of confusion at acceptance reviews: aggregate monitoring tools, weekly performance dashboards, drift reports do not replace per-inference reliability logs. Your client knows this, or will find out quickly.
Post-mortem / Aggregate Monitoring | Per-Prediction Reliability | |
|---|---|---|
When? | After execution, across time windows | Before the action, for each individual prediction |
Granularity | Metrics across N inferences | Score per inference |
Use at acceptance | Global qualification report | Article 12 logs, proof of real-time oversight |
Use post-deployment | Drift detection over time | Immediate escalation on unreliable prediction |
EU AI Act compliance | Insufficient alone for Article 12 | Article 12 compliant |
Both are necessary. What your client requires at acceptance is proof that both layers are in place not one or the other.
FAQ
What documents must an integrator provide at the acceptance of a robotic cell with AI?
Five documents are required: the AI model qualification report (performance on representative data, OOD testing, per-prediction reliability metrics), the AI risk management documentation (Article 9, EU AI Act), per-inference traceability logs (Article 12, EU AI Act), the CE technical file incorporating AI risk assessment (Machinery Regulation 2023/1230, EN ISO 10218, ISO 13849), and the continuous monitoring plan with drift detection protocol.
Does the Machinery Regulation 2023/1230 already apply to my current projects?
The Machinery Regulation 2023/1230 has been in force since 2023 with a transition period: new equipment placed on the market after July 2027 must comply. But projects integrating high-risk AI also fall under EU AI Act obligations, with the Annex III deadline set at August 2026. For cells currently in design, it is better to anticipate both frameworks now.
What does an Article 12 EU AI Act-compliant traceability log look like for a robotic cell?
An Article 12-compliant log records, for each inference of the AI component driving a physical action in a safety-relevant context: the timestamp (millisecond precision), the prediction confidence score, the triggered action or refusal to act, and the operational context. Standard SCADA or PLC logs do not meet this requirement, they record machine states, not the model's reliability metrics at the moment of the decision.
How do you document human oversight in the CE file for an AI-integrated cell?
Human oversight (Article 14, EU AI Act) must be documented technically: when the system stops to request operator input, at what confidence threshold, which interface alerts the operator, how they take over or validate the prediction. These mechanisms must be tested, and the test evidence must appear in the CE technical file. Writing "an operator can intervene" is not sufficient.
Can a black-box AI model generate the traceability logs required by the EU AI Act?
Yes, provided a black-box-compatible reliability layer is connected in parallel. This layer intercepts the model's predictions, computes per-inference reliability metrics, and generates structured logs without accessing the model weights or modifying it. This plug-and-play architecture enables commercial vision models, Cognex, Keyence, Basler or custom models to achieve Article 12 compliance without retraining.
Share
Related articles
