AI strategy discussions in manufacturing often begin in the wrong place. Teams debate model accuracy, available data, whether to use a cloud model or an edge model, and which pilot could demonstrate value fastest. Those are valid questions. But once AI becomes part of a connected machine, inspection device, human-machine interface or maintenance product, a more fundamental constraint appears: can the organisation operate that capability as a secure product over its full lifecycle?
The Cyber Resilience Act changes the practical framing. For products with digital elements, cybersecurity is no longer something that can sit beside product development as a late-stage review. Vulnerability handling, secure configuration, software updates, technical documentation and incident processes become part of what it means to release and maintain the product.
For manufacturers, this is particularly important because AI is rarely deployed in isolation. It is embedded in equipment sold to customers, connected through service networks, integrated with industrial control environments or exposed through remote access. A useful AI feature can therefore create a new route into a customer environment, a new dependency on external software, or a new operational failure mode. The question is not simply whether the model works. It is whether the product team can explain, secure, update and support the system after it leaves the factory.
AI turns a feature into a lifecycle commitment
A prototype can run with a frozen model, a controlled dataset and a small group of internal users. A product cannot rely on those conditions. In production, inputs change, software libraries develop vulnerabilities, credentials expire, interfaces are modified and customers expect equipment to remain usable for years.
This distinction matters for AI-enabled products because the model is only one component in a larger chain. An image-based inspection device may include cameras, firmware, an operating system, an inference runtime, model files, a data-preparation workflow, remote support software and a web interface. A machine assistant may combine an HMI, user accounts, knowledge retrieval, diagnostic data and a connection to a service platform. Every element has a security posture, a maintenance requirement and an owner.
The model is not the product boundary. A product team that treats the model as the sole AI asset will miss the components that are most likely to create avoidable exposure: unsigned update packages, poorly managed service credentials, unsupported libraries, overly broad remote access or undocumented third-party dependencies.
This is why an AI proof of concept can look successful while the path to commercial release remains unclear. The innovation team may have proved that a vision model identifies a quality defect. It has not necessarily proved that the organisation can distribute model updates securely, reconstruct which version ran on a customer site, respond to a discovered vulnerability or prevent manipulated input from causing unsafe or unreliable behaviour.
Product security requirements should shape the architecture early
The expensive mistake is to build the AI function first and add compliance controls when the product is nearing release. At that point, architectural choices are already embedded. The chosen inference engine may not support the required update approach. The device may lack a trustworthy identity mechanism. The system may be unable to produce meaningful logs without collecting more customer data than intended. The team may not know precisely which open-source packages are contained in the deployed software.
These are not paperwork problems. They are engineering decisions.
Secure updates are a design capability. AI-enabled equipment will need a deliberate process for releasing software, configuration and model changes. That process should establish what is being changed, who authorised it, how integrity is checked, how the change reaches a customer environment and what happens if the installation fails. Model updates deserve the same discipline as firmware or application updates. A new model can alter product behaviour materially, even where the application code is unchanged.
For many mid-market manufacturers, this does not require a vast platform programme. It requires a dependable baseline: a controlled release process, a clearly owned update mechanism, an inventory of deployed versions and an escalation path when an issue affects customers. The objective is not to make every machine permanently connected. In industrial settings, connectivity may be constrained for sound operational reasons. The objective is to ensure the organisation has a realistic, secure method to maintain what it sells.
Dependency visibility must include AI components. A software bill of materials is often discussed as a compliance artefact. Used well, it is an operational tool. It helps product security, engineering and support understand what is present in a device or product release when a vulnerability emerges. With AI products, that inventory should extend beyond conventional software packages. Teams need to know which model runtime, data-processing libraries, model artefacts and externally operated services are part of the delivered capability.
An AI feature dependent on an external API introduces a different set of questions from one that runs locally at the edge. Neither is automatically superior. The external service may simplify model operations but raise questions around service continuity, data flows and change management. Edge deployment may improve local control and resilience but increase the burden of distributing and monitoring updates across a fleet. The correct choice follows the product’s risk, operating environment and support model, rather than a generic preference for cloud or edge.
Vulnerability handling is where organisational gaps become visible
Many machine builders have robust quality processes yet fragmented vulnerability processes. Engineering knows how to handle a product defect. IT knows how to patch internal systems. Customer service knows how to coordinate a field intervention. An AI-enabled connected product can require all three functions to act together, often under time pressure.
A credible vulnerability-handling process answers practical questions before an incident occurs. Where can a researcher or customer report an issue? Who assesses whether the report is credible? Who can determine affected product versions? How does the business decide whether a mitigation, update or customer communication is needed? Who owns the relationship with a component supplier when the issue is in a dependency rather than proprietary code?
Responsibility cannot be outsourced with the component. A supplier may provide a model, a gateway, an operating system image or a managed AI service. That supplier relationship is important, but it does not remove the manufacturer’s need to understand the resulting product risk. Procurement terms, technical interfaces and support arrangements must be aligned with the security obligations the product team carries.
This is where innovation-led AI programmes often struggle. They may have a vendor demonstration, a promising prototype and a business sponsor, but no agreement on who owns the product after deployment. If no team owns software maintenance, vulnerability triage and customer communication, the organisation does not yet have an AI product capability. It has an experiment with a route to market problem.
AI-specific risks should be handled without theatre
AI introduces genuine security and reliability concerns, but it also attracts exaggerated claims. A sensible product-security approach distinguishes between conventional software risks and risks created by the AI function itself.
Conventional risks include exposed APIs, weak authentication, insecure remote access, vulnerable packages and unprotected update channels. These remain highly relevant because AI components add software complexity. AI-specific considerations include manipulated inputs, unexpected model outputs, degraded performance as real-world conditions change, and unintended disclosure through prompts or retrieved information where generative interfaces are involved.
The answer is not to promise that the model will never fail. It is to define where AI output is advisory, where it can trigger action, what boundaries apply and how the product behaves when confidence is low or a supporting service is unavailable. A visual inspection system may flag uncertain cases for human review. A maintenance assistant may cite the source document it used rather than presenting an untraceable instruction. A machine-control function should not be granted authority merely because a demonstration appears convincing.
Safety, security and product quality must meet in one release decision. In many manufacturers, these disciplines have separate governance structures. Embedded AI exposes the cost of that separation. A release decision should establish not only that a feature meets performance expectations, but also that its dependencies are known, its update route is viable, its failure behaviour is understood and its operational owner is prepared.
Make compliance a delivery advantage, not a late gate
The contrarian view is that product-security obligations can improve AI delivery. They force decisions that pilot programmes otherwise postpone: which use cases deserve productisation, which data flows are acceptable, which suppliers can be depended on, and which teams will operate the capability over time.
That discipline helps management distinguish a compelling demonstration from a viable offering. A customer-facing AI feature that cannot be updated safely is not ready. A connected diagnostic function with no clear vulnerability response process is not a finished product. A model that relies on undocumented dependencies does not yet have a supportable commercial foundation.
For DACH manufacturers, the practical move is to bring product security, software engineering, service and commercial leadership into the AI decision before architecture becomes fixed. Start with the intended product lifecycle, not the model shortlist. Decide how the feature will be maintained, supported and retired. Then design the AI capability within those constraints.
That is not a brake on innovation. It is how an AI feature becomes something customers can buy with confidence and the organisation can maintain without accumulating invisible operational debt.
A Fit Call helps you test whether an AI-enabled product has a credible route from prototype to secure, maintainable release — before security obligations become an expensive late-stage redesign.
Context note: This article provides practical product-lifecycle considerations and is not legal advice.