Skip to main content
School of Engineering JudgmentThe verification gateA mapping call, at no cost
WhatsApp058-4887876
A mapping call, at no cost

All articles

AI policy for a plant: what to write, who checks, who signs

Published

An AI policy for a plant: allowed, forbidden, who checks, in seven sections. Two tables and one rule.

An AI policy for a plant is a short document that answers three questions: what is allowed, what is forbidden, and who checks. It takes effect when it holds two things. One is a list of tools that someone has signed. The other is a rule: no signature on a deliverable without a check against a source. Everything else supports those two.

AI use policy, AI policy, generative AI policy: three names for the same document. The article on AI in industry explains why you need one: what Shadow AI is, and how a gauge failure looks. This one goes through the document itself, section by section, far enough that you can write it.

Why a verbal instruction is not enough

For drafting, translating, summarising and organising, these tools work well. They fail at the points where a practising engineer must sign. A plant has many such points. Some do not look like signatures: a purchase order, a work instruction, a client report, an entry into an organisational system.

A verbal instruction cannot answer the auditor's question: who approved this, and on what basis? A document with an approver and a date can.

Professional bodies already take a similar position. ASHRAE adopted a policy on the subject in February 2025 (ASHRAE 2025), and ASTM International has a comparable one (ASTM 2025). Both, as we read them, treat AI output as material that a human must review and take responsibility for. Neither specifies a method for the person doing the work. That is the part your plant's document has to supply.

The seven sections

This is the structure of the policy template. Each section carries one decision that somebody has to make.

  1. Scope. Who it applies to: every employee who uses a generative AI tool at work. This section also defines the words: tool, output, authoritative source, deliverable, commitment. Without definitions, every department reads the document differently.
  2. Tools. Two tables to fill in. One of approved tools: tool, maximum level, approver, date. One of documents that may never go to a cloud tool: confidentiality, classification, IP. The policy forbids any tool that is not in the table.
  3. The gate. Nobody signs, submits or sends a deliverable that has not passed the gate. This section holds the three steps and the four results of any check: match, gap, not verifiable, missing.
  4. Records. One log accompanies every deliverable. Every submission and organisational deliverable also carries a seven-field use declaration. A deliverable without a log is not a deliverable.
  5. Roles. Who signs, who attaches the source, who approves a level. One named policy owner, with a signature. A section with no person's name in it is a wish.
  6. Training. A workshop on the plant's own deliverables that ends with an error-hunt quiz, no tool.
  7. Review. Review the policy once a year. Measurement runs once a quarter: which failure classes recur, in which deliverables, and what changes in tagging.

The appendix holds the five-level scale and the tagging table to fill in.

The hard decision: the tools table

Most of the wording is easy. The difficult part is deciding what goes in the tools table.

An empty list looks careful and leaves everything undocumented. People keep using the tools anyway, and that is exactly Shadow AI: use the organisation has not tagged, not approved and does not check. So start by asking what is already in use, and only then decide what you approve and at which level.

The policy itself names no products. It speaks of tasks, and tool names go only in the plant's own table. A new version of a tool then needs a new row, and the policy stays as it is.

Be concrete on the never-to-cloud list. Write down the kinds of documents your people actually handle.

An example: four rows of the tagging table

The levels here are an example for illustration. Your plant sets them by the consequence of an error on its own site, and the difficulty of the task does not come into it.

Level 4 is extensive use including analysis and organisation, only with the supervisor's explicit approval. An untagged task is level 0 until someone tags it otherwise. An organisation may tighten a level. It may not loosen a level beyond what the policy permits.

What to do tomorrow morning

Start with two lists, before you even open the template.

  1. The deliverables that get signed or lead to a commitment, and who signs each one.
  2. The documents that may never go to a cloud tool.

After that the order does not change. Every deliverable on the list receives a level in writing, with a reason and an approver. The log and the declaration go into the plant's existing templates, with no new form. Only then comes training.

Three mistakes keep recurring here.

Where ISO 42001 comes in

The policy refers to ISO 42001, a standard for managing AI systems in an organisation, as a frame of reference only. It is not certification to the standard and does not replace it, and it does not declare conformance. If your plant needs certification, that is a separate process.

What the policy does not do

It does not make output correct. It requires that someone checked every item against a source and recorded the result. If the source is wrong, the deliverable is wrong, and the log shows exactly where.

It does not apply everywhere. Where there is no authoritative source, the gate blocks the item. Certified engineering calculation software is not a tool in the sense of this policy.

It does not replace professional competence, and responsibility stays with the signer. It is not legal advice either.

And the evidence behind it measures the failures, not the policy. The working paper is not peer-reviewed, and it reports no collected data. We have no figure yet for what a plant gains from a policy like this.

Template or signed policy

The template is a document you fill in yourself, under an open licence. It holds the two things above: the tables and the rule before signature. An organised person with authority is enough to complete it.

A policy adapted to your organisation and signed by a registered engineer is different work. It fits when an audit is coming, or when nobody in-house can sign these choices. Either way, the two lists above are the first step.

References