Generative AI across the industrial value chain

A generative AI pilot is comparatively easy to produce: a bounded use case, curated data, an enthusiastic core group. Those three conditions all disappear in production.

There the application meets incomplete data, users without prior experience, processes full of exceptions, and requirements for traceability, access rights and auditability. The effort of that transition is routinely underestimated in planning, because the pilot worked.

The practical consequence for portfolio steering: a successful pilot is not evidence of scalability. Reliable evidence only emerges once a use case runs for several months without special support.

Across the range of industrial use cases, three areas show particularly robust economics: design and development, technical documentation, and technical service and aftersales.

The common denominator is text-heavy work with high reuse. In design it is specifications, standards research and variant derivation; in documentation, creation, updating and translation; in service, condensing fault patterns, histories and instructions into a usable answer.

These cases also share the property that benefit is directly measurable in processing time. That makes them suitable starting points — not because they are the most spectacular, but because they can be evidenced against a business case.

Generative AI amplifies the existing data situation; it does not replace it. Where master data is inconsistent, engineering data incomplete or service histories patchy, the model produces plausible answers on an inadequate basis — and in an industrial context that is more expensive than no answer at all.

An uncomfortable sequence follows. The effort for data cleansing, structuring and access rights falls before the benefit and is rarely visibly attractive. Yet it is the part that decides economics.

A pragmatic approach assesses data effort per use case rather than company-wide: which data does this one case need, at what quality, and what does it cost to produce? That question separates viable projects from expensive ones.

The experimentation phase typically produces several independent solutions: one in service, one in design, one in procurement, often with different vendors and access routes.

As a learning phase that makes sense; as a permanent state it is expensive. Duplicate licence and integration costs are the smaller problem. Heavier weight falls on inconsistent rules for data access, logging and release — and on the lack of reusability of preparatory work between departments.

A company-wide platform with clear governance standards solves both: defined rights and logging logic, shared data connections, reusable building blocks. The moment for this step typically lies after the first pilots and before scaling — afterwards, harmonization becomes considerably more expensive.

Model selection absorbs attention because it is technically tangible. For actual impact it is rarely decisive — available models sit close together in the relevant industrial use cases.

What decides is whether the application is adopted in the business. That requires changed workflows, qualification, clear rules for handling outputs, and leadership that expects usage rather than leaving it optional. Where these elements are missing, usage stays confined to a small group — and so does the benefit.

For budgeting this means a realistic plan places the majority of effort outside the technology. Calculating it the other way round funds licences for an application nobody adopts into daily work.