AI approval routing can reduce the time spent finding the right reviewer, assembling evidence, and chasing routine decisions across manufacturing. It can classify a request, identify the applicable policy, summarize maintenance or quality records, recommend a route, and remind an approver. It should not quietly acquire the authority to release product, bypass a safety interlock, alter a validated process, or approve its own exception.
The design problem is therefore not simply 'add AI to approvals.' It is to preserve decision rights while making evidence and routing faster. This guide covers change requests, maintenance work, quality deviations, supplier exceptions, purchase approvals, and production-impacting access. Teams planning a wider program can connect this approach to AI automation, enterprise systems, and industrial IoT delivery.
1. Choose an approval with a clear decision boundary
Select a workflow with a named requester, decision owner, evidence set, policy, and completion state. A request to replace a production asset, approve overtime, disposition nonconforming material, or change a recipe may all be called an approval, but their consequences differ. Record whether the decision affects worker safety, product quality, regulatory records, production availability, cost, or customer commitments.
Avoid beginning with a high-consequence process whose policy is mostly tribal knowledge. First make the current route explicit. Observe real cases, including withdrawals, delegation, missing evidence, emergency work, and rejected requests. AI cannot make an undefined approval model accountable.
| Approval type | Useful AI assistance | Authority that remains human or deterministic | Required evidence |
|---|---|---|---|
| Maintenance work order | Classify asset and summarize history | Permit, isolation, scheduling and return-to-service decision | Asset, risk assessment, parts, competency and test results |
| Quality deviation | Group defect evidence and find related cases | Disposition and release decision | Batch or serial record, inspection, specification and traceability |
| Engineering change | Summarize affected documents and dependencies | Technical approval and controlled release | Drawing, bill of materials, validation and effective date |
| Procurement exception | Compare request with policy and supplier record | Budget, supplier and conflict approval | Quote, threshold, supplier status and business justification |
2. Map authority, evidence and segregation of duties
Build a decision table before choosing a model. For every route, define who may request, review, approve, delegate, execute, verify, and close. Use role and context: site, line, asset class, product family, monetary threshold, shift, certification, and risk level. Segregation of duties should prevent the same identity from requesting, approving, and verifying a consequential action where policy requires independence.
The evidence package should be assembled from authoritative systems using stable identifiers. Free-text summaries are helpful navigation, not substitutes for the work order, inspection result, controlled document, or approved policy. Show source timestamps and missing fields to the approver. If evidence changes after approval, invalidate or re-route the decision rather than relying on the old state.
| Control | Implementation | Failure to test | Evidence |
|---|---|---|---|
| Policy routing | Versioned rules determine mandatory reviewers and thresholds | A model routes around a required function | Rule version and evaluated inputs |
| Identity and role | Current workforce and contractor attributes drive authorization | Transferred or expired staff retain approval rights | Identity, role, site and validity period |
| Delegation | Time-bound delegation with scope and conflict checks | Blanket delegation defeats segregation | Delegator, delegate, reason and expiry |
| Execution boundary | Approved action is translated into a constrained command | Approval text is treated as unrestricted permission | Action type, parameters, actor and result |
| Revalidation | Material evidence changes reopen the decision | A stale approval acts on new conditions | Change event and new approval chain |
3. Separate recommendation, authorization and execution
Use three explicit components. The AI component classifies and summarizes; a policy engine evaluates deterministic obligations; the workflow engine records state and requests action from an authorized person or system. Execution occurs through narrow, authenticated interfaces only after required conditions pass. This separation makes it possible to improve a model without changing who has authority.
Keep operational technology boundaries intact. NIST SP 800-82 Rev. 3 emphasizes that OT security must account for performance, reliability, and safety. An approval application should normally exchange business events through controlled integration services, not establish broad direct access from an AI service to controllers or safety systems. Where a workflow results in plant action, existing engineered protections and operating procedures still apply.
Limit every tool by function, object, and parameter. For example, a service may create a draft work order but cannot change equipment state; it may retrieve a batch record but cannot alter the release status. Treat maintenance notes, supplier files, emails, and retrieved documents as untrusted input. Instructions embedded in them must not expand permissions or override policy.
4. Make human review usable under real operating pressure
An approver needs the decision, consequence, evidence, policy, uncertainty, and alternatives in one place. Do not bury source records behind a confident summary. Highlight conflicts and omissions. Allow the reviewer to request more evidence, re-route, reject, or record a reason that can improve the process. A generic approve button invites automation bias.
Escalation needs elapsed-time and operating-context rules. A production stoppage may require a faster path but not weaker authority. Define emergency procedures separately, including the retrospective review and evidence required after service is restored. Never let the AI invent an emergency route because the normal approver is unavailable.
5. Test safety, quality and workflow failure modes
Create test cases from historical approvals and deliberately difficult scenarios: ambiguous asset identifiers, conflicting quality results, expired certifications, absent approvers, duplicate requests, late evidence, malicious document instructions, and integration outages. Compare route selection, evidence completeness, policy outcome, reviewer decision, and final system state. A correct summary with an incorrect authority route is a failed test.
The NIST AI RMF organizes risk work around govern, map, measure, and manage. Apply those functions to the complete workflow. Record model and prompt versions, but also policy versions, source snapshots, user actions, integration results, and overrides. Test rollback of model, rules, and workflow configuration independently.
- Run shadow mode against live cases without allowing the service to act.
- Measure missing-evidence detection and incorrect routing, not just classification accuracy.
- Test denied requests and unauthorized identities as carefully as happy paths.
- Exercise OT and enterprise integration outages with a documented manual route.
- Review sampled approvals with operations, quality, safety, security, and internal control owners.
6. Roll out by site, workflow and consequence
Begin with one site and a workflow that has a stable owner. Start with evidence assembly and routing suggestions, then enable low-consequence actions only after performance is understood. Do not copy the workflow to another plant without checking roles, local policy, equipment naming, shifts, language, and system interfaces.
Track approval lead time, queue age, re-routing, evidence defects, overrides, emergency use, duplicate actions, integration failures, and post-approval exceptions. Segment by site and approval class. Faster routing is valuable only if the quality and safety outcomes remain at least as strong.
7. Estimate scope and cost from integration and control depth
The largest cost drivers are usually process discovery, identity integration, policy formalization, evidence quality, workflow integration, validation, and change management. Model usage can be material at scale, but it is rarely the only or largest implementation cost. Estimate separately for discovery, foundation, one production workflow, additional sites, and ongoing operation.
| Work package | Cost driver | Planning output |
|---|---|---|
| Process and control discovery | Workflow variants and undocumented exceptions | Decision rights and exception map |
| Data and integration | Number, quality and age of ERP, MES, QMS, CMMS and identity interfaces | Source contracts and integration backlog |
| AI and policy layer | Classification complexity, retrieval and rule volume | Evaluation set and release thresholds |
| Validation and rollout | Consequence, site variation and training needs | Test evidence, cohort plan and manual fallback |
| Operations | Monitoring, reviews, source changes and support | Ownership, service levels and run cost |
Key takeaways
- Automate evidence and routing before granting action authority.
- Use deterministic policy for mandatory reviewers and thresholds.
- Keep AI services outside direct OT control paths unless specifically engineered and validated.
- Present uncertainty and source records to the approver.
- Test stale evidence, unavailable people, duplicate requests, and hostile documents.
- Scale only after one site can operate, audit, and recover the workflow.
Frequently asked questions
Can AI approve manufacturing requests automatically?
It may execute narrowly defined low-consequence decisions when policy, law, quality systems, and risk owners permit. Safety, release, financial, and exception decisions generally need stronger deterministic controls or an accountable human. The authority matrix, not model confidence, decides.
Does approval routing require a generative model?
No. Rules and conventional classifiers often handle structured routes. Generative models are most useful for summarizing unstructured evidence and explaining a recommendation. Use the least complex approach that meets measured requirements.
What should the audit record contain?
Retain request and evidence identifiers, policy and model versions, route decisions, human actions and reasons, delegation, timestamps, integration outcomes, final execution state, and any later revalidation or override. Retention should follow applicable quality, legal, and company rules.
Change control also applies to the automation itself. A new model, prompt, policy rule, role mapping, integration, or plant-data source can change the route even when the user interface looks identical. Classify those changes by consequence, require appropriate review, run regression cases, and release to a limited cohort. Keep the previous configuration and workflow state recoverable. Where the approval supports a validated quality process, align records and validation with the organization's quality-system requirements rather than assuming ordinary software deployment evidence is sufficient.
For ongoing assurance, review samples across shifts, sites, request types, and approver groups. Look for routes that are repeatedly overridden, evidence that arrives too late, and approvals that wait on one person. Those patterns may reveal a process or staffing problem rather than a modeling problem. Improve the underlying policy and system of record before tuning the AI around broken work.
Conclusion
AI approval routing is valuable when it makes manufacturing decisions easier to inspect without weakening who is accountable. Separate recommendation from policy and execution, preserve OT protections, and give reviewers complete evidence and usable exceptions. That architecture improves speed while keeping safety, quality, and operational authority visible.