Industrial AI Compliance Guide: What to Check Before Factory Deployment
Before an AI system reaches the factory floor, technical evaluators need evidence that it can operate safely, securely, and within applicable regulatory requirements.
The deployment decision should rest on a defined operating envelope, verified controls, and traceable records. Accuracy benchmarks alone cannot establish readiness for industrial use.
This industrial intelligence compliance guide explains what to check across intended use, legal classification, data governance, cybersecurity, human oversight, validation, and ongoing change management.
Whether assessing welding inspection, precision metrology, or intelligent torque control, begin with one question: what happens when this system produces a plausible but incorrect result?
1. Define What the AI Can Actually Influence
Document the system’s intended purpose before reviewing certifications or model scores. Specify its users, equipment interfaces, operating conditions, outputs, and authority over production decisions.
An inspection assistant that highlights suspected weld defects presents different risks from software that automatically accepts joints or changes welding parameters during an active cycle.
Map the complete decision chain: sensor input, preprocessing, model inference, decision thresholds, operator response, controller communication, and the physical action that ultimately follows onsite.
Include foreseeable misuse, such as operators applying a model to unsupported alloys, bypassing review during production peaks, or treating confidence scores as calibrated measurement uncertainty.
Record where the system must stop or defer. Missing sensor data, unfamiliar part geometry, excessive latency, and unsupported tooling should trigger explicitly defined responses.
2. Identify Applicable Laws Before Selecting Standards
Build a jurisdiction matrix covering deployment location, destination markets, product category, personal data processing, and contractual obligations. There is no universal industrial AI approval.
Determine whether the organization acts as a provider, deployer, importer, distributor, or machinery manufacturer under relevant legislation. Responsibilities can change when systems undergo substantial modification.
For EU deployment, assess the AI Act alongside applicable machinery, product safety, data protection, and cybersecurity requirements. AI classification does not replace equipment compliance.
Industrial use alone does not automatically make AI high risk. Under the EU AI Act, product-related classification depends on specific conditions, including relevant conformity-assessment requirements.
Employment applications require separate scrutiny. AI used to allocate tasks based on individual behavior or monitor worker performance may raise obligations beyond production quality control.
Check provisions and application dates against the deployment schedule. The AI Act applies in stages, and requirements affecting particular product-related systems follow different timelines.
For US facilities, examine workplace safety duties, sector rules, state privacy requirements, and customer specifications. Avoid assuming that voluntary AI frameworks constitute government approval.
Assign an accountable reviewer to every legal conclusion. Record the supporting provision, applicability rationale, required evidence, and unresolved interpretation before authorizing factory use locally.
3. Separate Legal Duties, Standards, and Supplier Claims
Standards help organize technical evidence, but their legal significance depends on jurisdiction, scope, edition, and recognition. A relevant standard does not automatically establish compliance.
ISO/IEC 42001 addresses AI management systems, while ISO/IEC 23894 provides AI risk-management guidance. Neither independently proves that a particular factory application operates safely onsite.
ISO 12100 supports machinery risk assessment. ISO 13849-1 or IEC 62061 may inform safety-related control design, depending on the machinery and applicable regulatory context.
The IEC 62443 series provides industrial cybersecurity guidance and requirements across different roles and system levels. Select the relevant parts rather than claiming blanket coverage.
Ask suppliers which entity, product, version, location, and activity each certificate covers. Management-system certification should never be presented as product-specific validation or regulatory authorization.
4. Require Evidence That Matches the Production Decision
Convert general assurances into an evidence checklist. Every important claim should connect to an identified requirement, a verification method, and a named acceptance owner.
Where evidence remains incomplete, define the permitted pilot scope and compensating controls. Keep experimental outputs from acquiring production authority through informal operator workarounds onsite.
5. Test Data Quality Against Real Factory Variation
Request dataset provenance, collection conditions, labeling procedures, usage rights, and access restrictions. Establish whether supplier contracts permit training on production images or process records.
Check that validation data represent actual materials, equipment, lighting, surface finishes, fixture variation, and operating shifts. Convenient laboratory samples rarely cover the full production envelope.
Keep related samples together when splitting datasets. Images from the same component, batch, or production sequence can otherwise leak information into the evaluation set.
For weld inspection, assess defect categories separately, including rare but critical conditions. Overall accuracy can conceal unacceptable false acceptance rates for safety-relevant discontinuities in production.
For metrology, examine reference traceability, calibration status, environmental effects, and measurement uncertainty. A model’s probability score does not establish dimensional accuracy or fitness for tolerance decisions.
When cameras capture workers or identifiers, assess privacy obligations, retention limits, access permissions, and required notices. Remove unnecessary personal information from training and operational records.
6. Validate Consequences, Not Just Average Accuracy
Define acceptance criteria before final testing. Tie thresholds to defect severity, downstream detectability, process capability, contractual requirements, and the consequences of an incorrect decision.
Measure false accepts and false rejects separately. Include confidence intervals and explain whether sample sizes support conclusions about rare failures that could cause serious harm.
Test beyond nominal conditions: dirty lenses, sensor dropout, tool wear, unfamiliar parts, network disruption, delayed inference, and conflicting inputs should produce predictable system behavior.
For intelligent torque control, verify the complete fastening result. Predicted torque suitability cannot substitute for evidence that the required joint characteristics were actually achieved.
Use staged commissioning where appropriate: offline evaluation, shadow operation, supervised trials, and controlled production release. Define measurable entry and exit criteria for each stage.
Record the exact model, software, configuration, hardware, and dataset versions tested. Approval should apply to an identifiable configuration rather than an evolving product name.
7. Keep Safety Controls Effective When AI Fails
Identify whether AI participates in a safety function or can create hazards through ordinary control actions. Consider unexpected motion, overheating, defective joints, and misleading measurements.
Where practicable, use independently engineered protective measures to maintain safety when AI fails. Their adequacy must follow the machinery risk assessment and required safety performance.
If AI forms part of a safety-related function, demand evidence appropriate to that role. General model validation cannot substitute for the required functional safety justification.
Define a safe response for each failure scenario. Stopping may be appropriate, but certain processes require controlled shutdown, isolation, or another specifically engineered transition.
Verify recovery as carefully as shutdown. Restart should require restored conditions, appropriate authorization, and safeguards against repeating an unsafe command or releasing unverified production.
8. Review Cybersecurity Across the Full Integration
Inventory the model runtime, operating system, libraries, gateways, engineering workstations, cloud services, and remote support connections. Include ownership and support status for each component.
Apply network segmentation, least-privilege access, managed credentials, and controlled administrative interfaces. Verify that supplier maintenance access can be authorized, monitored, and revoked when necessary.
Protect models, configurations, and deployment packages against unauthorized changes. Verify update authenticity and integrity, and maintain a tested route back to an approved version.
Assess AI-specific attack paths where relevant, including manipulated inspection images, poisoned retraining data, and altered decision thresholds. Prioritize threats that can affect physical production.
Agree on vulnerability reporting, patch delivery, incident notification, and support periods. Test security changes for production compatibility before installation, including timing and controller communication effects.
9. Make Human Oversight Work Under Production Pressure
Human oversight requires sufficient information, authority, competence, and response time. Adding an approval button provides little protection when operators cannot independently assess the recommendation.
Show the suspected defect, relevant measurement, operating limitation, and required action. Avoid interfaces that encourage operators to equate a confident presentation with a reliable result.
Define who can override decisions, change thresholds, approve exceptions, or restart equipment. Log consequential interventions without creating incentives to conceal uncertainty or bypass controls.
Train personnel using realistic failure scenarios. Confirm that staffing and line speed allow intervention before defective products escape or hazardous conditions develop during production.
10. Make Release Approval Traceable and Conditional
Assemble the release package around intended use, legal assessment, risk analysis, validation results, cybersecurity controls, operator instructions, and outstanding issues. Identify every accountable approver.
Release only when applicable obligations and critical acceptance criteria are satisfied. A restricted pilot needs documented boundaries, effective safeguards, and an explicit expiry or review point.
Define monitoring thresholds for defect escapes, false rejects, overrides, drift, latency, and system availability. Each alert needs an owner and a predetermined response procedure.
Require change review for retraining, threshold adjustments, new materials, camera relocation, firmware updates, and altered interfaces. Determine which changes require renewed validation or conformity assessment.
Keep incident records and retain enough configuration history to reconstruct consequential decisions. Reassess approval when operating conditions or evidence no longer support the original conclusion.
Deployment Readiness Depends on Verifiable Evidence
A factory AI system is ready when its intended role, legal obligations, performance limits, protective measures, and operational responsibilities form a coherent, documented release decision.
Technical evaluators should withhold production authority whenever unresolved gaps could invalidate safety, product conformity, or critical quality decisions. Resolve those gaps through evidence and effective controls.
Use this industrial intelligence compliance guide as a release checklist, then maintain it throughout operation. Compliance depends on the deployed configuration and its continuing use.

