Making generative AI usable on the factory floor

The Challenge

Siemens is bringing generative AI to the shop floor. The Industrial Copilot sits inside the engineering workflow, where automation engineers configure production lines in the TIA Portal, an environment with decades of accumulated conventions and very little tolerance for surprises.

The opportunity was obvious. The risk was less so. An AI assistant that guesses in a factory context is worse than no assistant at all, because a wrong change does not produce a bad user experience, it produces downtime.

The constraint that shaped everything was expertise. These are not casual users being introduced to a chatbot. They are specialists who already know the correct answer most of the time, and who need the copilot to be faster than doing the work themselves rather than merely capable of it. That reframed the design question. The interesting problem was not how a user asks a question, it was how a user stays in control of what the AI is about to do.

Key Decisions

1. 01

   Made the copilot’s context visible instead of inferring it

   Considered

   A chat panel that silently picks up whichever project the engineer has open, the pattern most assistants use.

   Chose

   An always-visible statement of which project context, which plugin and which agent the copilot is operating with, changed deliberately by the user.

   An assistant whose scope is invisible cannot be trusted with anything consequential. I would rather an engineer spend two seconds confirming the context than five minutes working out why the answer was wrong.

2. 02

   Treated agents and plugins as objects the engineer wields

   Considered

   A single assistant persona that decides internally which capability to apply.

   Chose

   Agents and plugins as explicit things the user selects and combines.

   This is less magical, and it is the difference between a tool and a toy. Engineers are comfortable with tools that have visible parts, and they are rightly uncomfortable with systems whose behaviour they cannot predict.

3. 03

   Kept the copilot inside the existing workflow

   Considered

   A destination of its own, which is what a new product with a new team usually becomes.

   Chose

   A surface inside the engineering environment the user is already in.

   The engineer’s workflow already exists and already holds their attention. An assistant that requires leaving it has to be dramatically better to be worth the switch. One that lives inside it only has to be slightly better.

4. 04

   Made every generated result reviewable before it lands

   Considered

   Applying results directly, which reads as faster and demos better.

   Chose

   A review step as the default path rather than an advanced option.

   Nothing the AI produces is applied silently. In a domain where being wrong is expensive, predictability buys more trust than capability does.

The Solution

A copilot experience carried from first concept through to the launched interface: concept development, low and high fidelity prototyping, and UI design, with support from ideation through to launch.

Alongside the screens, a specified data layer behind every state, so the engineering team was not left to infer what the interface expected. The delivery was concept documentation, that data-layer specification, and launch-ready screens.

The Results

The concept carried from first sketch through to the launched product interface without being redrawn, and the patterns established here (visible context, explicit capability, review before apply) held across the feature set as it grew.