AI assistants in PLC and HMI code: what they help with, what stays human, and how the code stays validatable

Late on a Thursday, three weeks before the factory acceptance test, an integrator’s engineer pastes a function block into a chat window. It runs the rinse sequence of a clean-in-place skid. He asks for comments, a tidier state machine and the alarm texts in English and French. Four minutes later he has all three, and they look good. On Monday the site’s validation lead asks two questions nobody had prepared for: who checked the new version, and where did the project file go?

A February 2026 feature in Automation.com lists what automation engineers already hand these tools: message lists to translate, blocks to document, manuals to search, code to check against a house standard, test lists for acceptance tests. All of that is real, and most of it is useful. What the feature does not settle is what a regulated site has to add so that logic drafted with a language model can still be released, inspected and changed years later.

The model stays on the desk. The code goes to the line

An assistant used to write code is a development tool. It never runs on the controller. What reaches the line is a program in one of the languages of IEC 61131-3, whose fourth edition (May 2025) defines structured text, ladder diagram and function block diagram, plus sequential function chart elements; the 2013 edition still listed instruction list as well. Whoever typed it, that program executes fixed rules, cycle after cycle, and can be read, compared and tested like any other.

The texts that deal with AI draw the same line, each in its own way.

Draft EU GMP Annex 22 covers AI models embedded in computerised systems and used in critical GMP applications. It excludes generative AI and large language models, which “should not be used in critical GMP applications”; in non-critical uses, qualified and trained personnel remain responsible for the output, with a human in the loop (§1). It went out for consultation from 7 July to 7 October 2025 and is still a draft. The EMA has since said the consultation showed support for potentially enabling generative AI in manufacturing, so that line may yet move.

The AI Act, in recital 12 of Regulation (EU) 2024/1689, keeps out of the definition of an AI system those “based on the rules defined solely by natural persons to automatically execute operations”. Our reading is that a block an engineer has reviewed and adopted is that kind of software: the assistant is the AI system, the PLC program is not. And the FDA’s January 2025 draft guidance on AI for regulatory decision-making on drugs leaves out models used for “operational efficiencies (e.g., internal workflows…)” that do not affect patient safety, drug quality or the reliability of study results.

The consequence is a helpful one. You do not validate a language model in order to use it for engineering work. You validate what it helped produce, and you control how it is used.

Generated code is still custom software

The GAMP software categories do not care who wrote the logic. The PIC/S guide on computerised systems, PI 011-3, puts it in one line of its category table: “Manage any custom (bespoke) programming as Category 5.” A sequence written for your skid, your recipe and your interlocks is exactly that. EU GMP Annex 11 asks, for bespoke or customised systems, for “a process in place that ensures the formal assessment and reporting of quality and performance measures for all the life-cycle stages of the system” (§4.6).

The second edition of GAMP 5 (ISPE, July 2022) treats categories 3 to 5 as a continuum and the category as “just one factor”. It adds appendices on critical thinking (M12) and on software tools (D9), the tools that support the life cycle without directly supporting GxP processes or holding GxP records. A coding assistant fits there. The code it helps to produce stays under appendix D4, management, development and review of software. More on the edition in GAMP 5 second edition.

In practice the validation plan does not change because a block was drafted with help. The development procedure does, in three places: review, testing and configuration control.

What the assistant can take on, and what stays with a named engineer

Read down the table and the pattern repeats. The assistant saves time on text. The decisions that make a sequence safe stay with someone who can be named in the record, and who has read what they sign.

Review is the step that makes the code yours

The PIC/S guide was written long before language models, and its advice fits them well: “Code review (walk-through) is best done as early in the process as possible, preferably before submitting a module to test” (§13.2). For AI-drafted logic, three habits make that review worth the time.

1. Review against a written standard. Without one, review is a matter of taste. PLCopen published its Coding Guidelines in April 2016 (version 1.0), rules for IEC 61131-3 programs such as “Physical outputs shall be written once per PLC cycle”, “Floating point comparison shall not be equality or inequality” and “Error information shall be tested”. An assistant can check a block against such rules in seconds, which leaves the reviewer free for what no rule catches.
2. The reviewer is not the author. The engineer who prompted the assistant is the author of the block, whatever share of it the tool wrote. A second person reviews, and reviews the diff against the last released version, not the whole block from memory.
3. The review looks for the faults assistants actually make. Instructions or library blocks that do not exist on your platform. A timer or a data type that compiles but behaves differently on your firmware. A state machine that looks complete but never says what happens when power returns or an emergency stop is released mid-step. A comment describing what the code should do rather than what it does. Fluent output is precisely what makes these easy to miss.

Safety logic is a separate case. For a safety PLC, IEC 61508-3 (2010) already sets requirements for support tools such as “development and design tools, language translators, testing and debugging tools”. A general-purpose assistant has no place there unless your functional safety management has assessed it.

Tests do not get thinner because a tool wrote the code

Annex 11 asks for evidence of test methods and scenarios covering “parameter limits, data limits and error handling”, and adds: “Automated testing tools and test environments should have documented assessments for their adequacy” (§4.7). If the assistant writes test scripts or drives a simulation, that sentence applies to it.

The subtler risk is a shared blind spot. Tests generated by the model that wrote the code tend to check what the code does, not what the process needs. Let the assistant propose test cases by all means, then derive the acceptance tests from the user requirements and the functional specification and trace them there (§4.4 asks for requirements to be traceable throughout the life cycle). Depth still follows the impact of a failure, as set out in how deep a test should go. The FDA’s final guidance on computer software assurance for device production and quality system software (September 2025, reissued February 2026) makes the same trade: more rigour where process risk is high, not where a tool happened to be used.

The tool itself: supplier, contract, and what may leave the site

A cloud assistant is a service that processes your data. Annex 11 §3.1 names that case: when third parties are used “for data processing”, “formal agreements must exist” with clear responsibilities, and §3.2 makes competence and reliability the selection criteria, with an audit where the risk justifies it. For a coding assistant the questions are concrete. Is your code used to train the model? How long are prompts kept, and where are they stored and processed? Who at the provider can see them, and what happens at the end of the contract?

The content matters as much as the contract. Joint guidance from CISA, the Australian Cyber Security Centre and seven partner agencies (December 2025) puts logic diagrams, operations sequences and safety-related information under “engineering configuration data”, which has “enduring value” and is “highly valuable to cyber adversaries”. It asks operators to minimise risk “by not sharing sensitive data with AI models”, especially models hosted by third parties in public cloud infrastructure. There are other owners to think of too. An integrator’s library or a machine builder’s code is often covered by a licence or a non-disclosure agreement that never imagined someone pasting it into a chat window.

The AI Act weighs less here than people often assume. The obligations on general-purpose models (Chapter V, applicable since 2 August 2025) fall on their providers. A coding assistant is not one of the high-risk uses of Annex III, whose critical-infrastructure point covers AI used as a safety component. What remains is Article 4, rewritten by Regulation (EU) 2026/1744 (in force since 27 July 2026): deployers “shall take measures to support the development of AI literacy” of their staff. For an automation team, that means knowing what the tool gets wrong.

After go-live: every AI-proposed fix is a change

The pressure point is the night shift, when an assistant suggests a two-line fix for a sequence that hangs and the line is waiting. Annex 11 §10 still applies: “Any changes to a computerised system including system configurations should only be made in a controlled manner in accordance with a defined procedure.” The emergency route and the routine one are set out in when a repair becomes a requalification.

One habit is specific to generated code. Ask the same question twice and you may get two different blocks. Never regenerate a whole routine to fix one line: edit the released version, and let the comparison with the previous version show exactly what changed.

Where to start

A site procedure on AI-assisted engineering fits on one page. Ours usually has eight lines:

1. Scope. The assistant may draft, translate, document and review. It never downloads to a controller and is never connected to the control network.
2. Approved tools. A named list, each assessed as a supplier under Annex 11 §3, with the contract terms on training, retention and location written down.
3. What may be pasted: the three levels in the figure, with examples from your own projects.
4. Authorship: the engineer who uses the assistant is the author and signs as such.
5. Marking: the change record says that AI assistance was used, with which tool, for which blocks.
6. Review against a written coding standard, by a second person, on the diff.
7. Tests derived from the requirements, independently of the tool that drafted the code.
8. Training. A short module on typical assistant faults, recorded like any other GMP training.

Five common mistakes

• Pasting the whole project. The complete project file carries network addresses, recipes, passwords left in comments and the safety logic. Paste the block, never the project.
• Accepting fluent code as correct code. Well-commented output invites a lighter review, when it deserves a heavier one until the team knows the tool’s habits.
• Letting the assistant write both the code and its tests. Two outputs from one source share the same misunderstanding of the process.
• Treating the tool as a GxP system to validate. Weeks spent qualifying a language model add nothing to the evidence on the code. Assess the supplier, control its use, validate the output.
• Using it outside change control after go-live. A suggested fix applied online at night is an unrecorded change to a validated system, however good the suggestion was.

The assistant can write the first draft of a sequence. The signature under the released version still has to belong to someone who read every line.

References

• Automation.com, How AI Is Transforming Industrial Automation Software Development, 9 February 2026, the starting point of this article.
• PIC/S, PI 011-3, Good Practices for Computerised Systems in Regulated “GxP” Environments, 25 September 2007.
• European Commission, EU GMP Annex 11, Computerised Systems, 2011, and draft Annex 22, Artificial Intelligence, consultation version, July 2025.
• Regulation (EU) 2024/1689 (AI Act), as amended by Regulation (EU) 2026/1744.
• CISA, ASD’s ACSC and partners, Principles for the Secure Integration of Artificial Intelligence in Operational Technology, 3 December 2025.