Is a prompt telling AI not to exceed authority sufficient?

No. Prompts can guide behavior, but identity, allowlists, state preconditions, approval, idempotency and audit require deterministic enforcement.

Does human in the loop mean one person approves everything?

No. Data, knowledge, model, business decision and action ownership may belong to different roles. The system should record exactly what each person confirmed.

May AI automatically change a DCS or PLC setpoint?

Not by default. Automated control is a separate control-engineering problem requiring hazard analysis, testing, change approval and safety validation.

How can a team prove permissions exist beyond the design document?

Exercise unauthorized requests, invalid states, duplicate submissions, permission revocation, model failure and complete audit replay.

The Authority and Accountability AI Needs Inside Manufacturing

The problem: permission to ask is not permission to act

When manufacturers introduce AI, the first discussion often concerns access to MES, LIMS, ERP or a data platform. “System access,” however, is too broad to be a useful permission model.

A person may view quality records but lack authority to change a release status. The same person may ask AI to explain an anomaly but may not authorize it to submit a disposition. Reviewing a recommendation also does not automatically make that person accountable for the final decision.

AI permissions must therefore be attached to specific objects, business states, actions and roles.

A practical permission ladder

Read facts

AI reads only approved data scopes and records source, time and version. Existing restrictions on sensitive fields, sites, customers and objects remain in force.

“Read quality data” is still too broad. A useful grant specifies which plant, batch type, fields, time window and cross-domain relationships are allowed.

Explain and advise

AI may summarize evidence, flag anomalies and propose investigation paths. Confirmed facts, model inferences and missing information must remain distinct. Advice changes no business state.

This is the right starting point for many industrial scenarios: first prove that the system finds the correct context, communicates uncertainty and helps people narrow the investigation.

Draft business material

AI may prepare a review request, task description or approval draft. A responsible person checks and submits it.

This can remove substantial preparation work while preserving human control of facts, language and accountability.

Submit a governed business action

With explicit authorization, AI may use a controlled action interface to create a task, request a re-test or start an approval. The system still enforces:

identity and role checks;
object and action allowlists;
business-state preconditions;
duplicate-submission protection;
approval for high-risk actions;
complete audit and defined failure handling.

The digital expert submits a governed proposal. It does not directly edit a database.

Automatically execute a narrowly defined business action

This may be considered only where scope is narrow, consequences are controlled, rules are explicit and the behavior has been separately validated. Stop conditions, exception handling, monitoring and ownership must be documented.

A successful tool call in a demonstration is not production authorization.

This ladder applies mainly to production operations. DCS and PLC control logic and SIS safety protection do not become available merely because a general-purpose model can call tools.

Five responsibilities must remain explicit

“Human in the loop” is not a sufficient ownership model.

Responsibility	Owner’s concern
Data owner	Source, meaning, quality and access
Rule or knowledge owner	Method, applicability and version
Model owner	Evaluation, deployment, monitoring and rollback
Business decision owner	Accept, modify or reject advice
Action owner	Execute the disposition and record the result

One person may hold several roles, but the records should still distinguish them. Otherwise, an audit shows only that “someone approved” without revealing whether they confirmed data, advice, the business decision or the execution outcome.

A digital expert supplies evidence and advice; it does not become the accountable operational or legal actor.

Prompts are not permissions

Instructions such as “do not modify critical data” may guide model behavior, but they are not security controls.

Critical boundaries require deterministic enforcement: identity and role checks, object allowlists, state preconditions, idempotency, approval, electronic signature where required, complete audit and safe fallback to manual operation.

The model may explain a rule. It does not decide whether it may bypass that rule.

Why control boundaries need separate treatment

MES, QMS and LIMS manage business state and records. DCS, PLC and SIS carry different levels of deterministic control and safety responsibility. The fact that all can expose interfaces does not make their risk equal.

A general-purpose digital expert may read approved process data and prepare a parameter or investigation recommendation. It should not default to writing setpoints, changing interlocks or triggering shutdowns.

If automated control is a real objective, it must be treated as a separate control-engineering program with hazard analysis, strategy verification, failure design, change approval and safety validation. It is not achieved by opening another agent tool permission.

Pre-launch exercises

Teams should verify that:

a read-only identity cannot submit an action;
invalid states and duplicate requests do not create duplicate outcomes;
revoked permissions take effect for active agents;
missing evidence is reported rather than invented;
manual workflows continue when the model is unavailable;
any action can be replayed from evidence through approval to outcome;
restricted objects remain hidden from unauthorized roles.

These exercises provide stronger evidence than a permissions screenshot.

Boundary: governance depth should follow task risk

Low-risk knowledge support may remain read-only. Capabilities that affect quality, planning, maintenance tasks or business states require stronger permission and accountability design.

This framework does not replace process-safety analysis, quality governance or control-engineering approval. It defines how AI participates in organizational and business-system workflows while existing control and safety responsibilities remain intact.

Mature manufacturing AI is not measured by how much authority it accumulates. It is measured by how reliably it delivers within the least necessary authority and how safely it stops when conditions are uncertain.