A mid-market manufacturer can slip into relying on AI one small permission at a time: a drafting tool here, a ranking model there, an assistant that can touch a record. Taken together, those permissions put AI in the path of operating decisions, employee work, and customer commitments. The company needs to have decided who is accountable before that happens, because accountability is much harder to assign after a tool is already embedded in daily work.
This article addresses one question: what governance should be in place before AI is allowed to influence operating decisions, employee work, customer communication, or system transactions? It does not argue for or against any platform. It lays out what to establish, what each choice costs, and how to sequence the work so that the effort stays proportionate to the risk.
The problem: AI changes who is accountable for the work
The risk is not only that a model is wrong. It is that nobody can say who decided to let it act, what it was allowed to see, and who could stop it. NIST's AI Risk Management Framework says that AI risks or failures that are not well defined or adequately understood are difficult to measure quantitatively or qualitatively. It adds that the inability to measure a risk does not imply that the system poses a high or low risk.
Third parties add to this difficulty. The same framework says third-party data or systems may complicate risk measurement, and that the risk metrics used by the organization developing a system may not align with the metrics used by the organization deploying it. If you buy AI capability inside an existing application, ask the vendor how its risks were measured.
The AI Village response to NIST described the diffusion and fragmentation of responsibility across functional areas, saying that it is not clear who will functionally own the creation and implementation of an organization's RMF. It named security, IT, data science, product, and compliance as candidates. Ask who in your company would own that work, and who would decide when a use is acceptable.
Why this is hard: constraints specific to a mid-sized plant
Several constraints shape the answer, and they interact. A control that works in a large enterprise with a dedicated security team may be unrealistic where one IT lead covers everything, so the constraints below should drive how much you attempt.
NIST's small-manufacturing guidance states that small manufacturers tend to operate with limited staff and limited resources, often causing cybersecurity to fall by the wayside. Plan for that honestly by choosing a few controls you can sustain rather than a long list you cannot maintain.
One-size-fits-all frameworks can also mislead. The AI Village response cautioned that an RMF could end up too watered down and generic to be useful across industries, and noted that an AI system used in health care is fundamentally different from one used in industrial controls. Start from your own list of AI use cases and the decisions each one touches.
AI also crosses systems. Each boundary raises questions of data ownership, access, and integration capacity. Those are business decisions before they are technical ones, and they belong with the people who own the processes and records involved.
Finally, the people side matters. NIST notes that the AI RMF provides opportunities to clearly define and differentiate the various human roles and responsibilities when using, interacting with, or managing AI systems. Decide deliberately who reviews, approves, and can override an AI output.
Approaches to compare
There is no single correct path. The options below are the realistic ones, and the tradeoffs depend on your environment. Treat each as a pattern to assess against your own systems and staff, not as a ranking.
Extend what you already run. Using AI features inside existing ERP or business applications keeps data where it is. The governance question becomes what those features can read, write, and send, and who approves turning them on. Ask the vendor how its risk measurement was done, since NIST identifies third-party opacity as a measurement complication.
Targeted integration. A narrow connection between a system of record and an AI service limits what the model can reach. It also requires someone to own the interface, its permissions, and its failure handling. Ask whether you have that integration capacity in-house or would need to arrange it.
Reporting or portal patterns. Presenting AI output to a person who then decides keeps a human in the transaction path. This places decision rights with an employee rather than with the model, and it lets you observe the output before granting it any authority over a record.
No platform change yet. Sometimes the sound choice is to inventory and classify use cases first and defer any build. This costs time, but it avoids committing to an architecture before ownership and data quality are understood.
A governed AI implementation or modernization. This fits only where a defined use case, an accountable owner, and tested controls exist. Changing a critical ERP, cloud workload, or custom system can disrupt operations and customer commitments, so this option carries migration risk and the potential for rework that the others do not.
Tradeoffs to weigh
Evaluate each option against implementation effort, data quality, ownership, permissions, adoption, and ongoing support. No option wins on all of these, and the right choice depends on which constraint binds hardest in your plant.
Security zoning illustrates cost-aware design. NIST describes security segmentation as a cost-effective and efficient security design approach for protecting cyber assets by grouping them based on both their communication and security requirements. The same paper says implementing all cybersecurity practices in the CSF Manufacturing Profile is probably not needed nor economically feasible for all manufacturing organizations.
Published guidance also has limits. NIST states that guidance available before the AI RMF was published does not comprehensively address many AI system risks, including harmful bias, generative AI, security concerns such as evasion and model extraction, and risks from third-party AI technologies and off-label use. Plan to review your governance periodically rather than treating it as a one-time policy.
Privacy and data protection carry their own cost. A checklist that Haileleol Tibebu of Loughborough University submitted to NIST lists Implement Data Minimization Principles among its encryption and anonymization items and Regular Incident Response Drills under incident response and recovery.
Next steps: a practical sequence
The following order keeps the work proportionate and gives each step something concrete to produce.
- Inventory. List every AI use case, including features embedded in software you already own. Record the data it uses, the models, prompts, and tools involved, the decisions it influences, and the owners, users, affected parties, and vendors.
- Classify risk. Rank each use by what it can affect: an internal summary differs from a message to a customer or a change to a transaction.
- Address the cross-cutting risks. Review privacy, intellectual property, cybersecurity, bias, reliability, explainability, cost, and vendor dependency for each higher-risk use.
- Assign human decision rights. Name who may approve, override, and stop each AI use, and provide training, an appeal path, and escalation.
NIST's guidance for a manufacturing cybersecurity solution says an organization should first conduct a risk assessment and determine the appropriate security capabilities required to mitigate those risks before using the sample architecture. As reader advice, apply the same sequence to AI: assess the risk first, then choose the controls.
Applying this to your operation
Start with questions you can answer this month, none of which requires buying anything. Their purpose is to show whether governance exists in practice or only in intention.
- Which AI features are already switched on in systems we use, and who approved them?
- Can AI in any workflow write to a record, send a message to a customer, or trigger a transaction without a person reviewing it?
- Who is the single accountable owner for each use, and who can disable it?
- What data can each use read, and who owns that data?
- If a vendor changed how its model works, how would we find out?
If you cannot answer these, treat that as your finding. It indicates that the next investment is governance and ownership, and that any build, integration, or modernization should wait until accountability is defined. Where a use is ready, begin with the narrowest option that keeps a person in the decision path, and widen permissions only as testing and monitoring show the controls hold.
