The Data Act is not a sharing mandate — it is a training-rights battleground
When the EU Data Act takes full effect in September 2025, most machine builders in the DACH Mittelstand will read it as a compliance obligation: customers gain new rights to access data generated by connected products, and manufacturers must build technical workflows to honour those requests. Legal teams will draft access policies, IT will provision APIs, and the organisation will treat the entire exercise as a cost centre. That framing misses the strategic shift.
The Data Act does not merely redistribute access to telemetry streams, service logs, and usage patterns. It redistributes the economic value of those streams as training inputs for industrial AI. Every time a CNC machine logs a spindle vibration anomaly, every time a packaging line reports a jam sequence, every time a compressor adjusts its duty cycle in response to ambient temperature, that event becomes potential training data for predictive maintenance models, process optimisation algorithms, or generative design systems. Under the old regime, the machine builder controlled that loop by default: telemetry flowed back to the manufacturer's cloud, models trained on aggregated fleet data, and the resulting intelligence became a proprietary product advantage or a premium service tier. Under the Data Act, customers can demand their own telemetry, route it to third-party analytics platforms, or pool it with competitors' machines to train models that bypass the original equipment manufacturer entirely.
The decisive question is not whether you will share data — the regulation settles that — but who will capture the learning loop. If a customer exports telemetry to a cloud platform that offers pre-trained industrial AI models, that platform ingests your machine's operational fingerprint and uses it to refine models sold to your competitors. If a maintenance service aggregates data from mixed fleets, it builds predictive capability that commoditises your aftermarket advantage. If a customer trains its own models on telemetry from multiple suppliers, it becomes the centre of intelligence for its production line, and you become a replaceable component provider. The Data Act accelerates all three scenarios, and the window to position your organisation on the right side of that shift is shorter than most Geschäftsführung assume.
Telemetry is not exhaust — it is the raw material for competitive moats
Industrial telemetry has always been valuable, but its value was historically locked inside vertical silos: a machine builder might use fleet data to improve the next product generation, or a large customer might analyse its own operations to optimise throughput. The Data Act, combined with the maturation of industrial AI tooling, changes the economics in two ways. First, it lowers the cost of aggregating cross-supplier telemetry, because customers and third parties no longer need to reverse-engineer proprietary protocols or negotiate bespoke data-sharing agreements. Second, it raises the value of aggregated telemetry, because modern AI models improve with scale and diversity—though domain expertise and labeling quality often matter more than raw volume. A predictive maintenance model trained on two thousand machines from multiple suppliers can outperform a model trained on five hundred machines from one supplier, assuming the multi-supplier dataset benefits from better feature engineering and more diverse failure modes.
The implication for machine builders is that data exclusivity is no longer a sustainable moat. If your competitive advantage rests on being the only organisation that sees how your machines behave in the field, the Data Act dismantles that advantage by design. The sustainable moat is not exclusivity but velocity and application: can you turn telemetry into actionable intelligence faster than a third party, and can you embed that intelligence into products and services that customers cannot easily replicate by exporting raw data? A machine builder that treats telemetry as a passive archive will lose to one that treats it as a live training corpus for models that optimise machine performance, predict part failures, or generate adaptive control strategies in real time.
This shift is already visible in adjacent industries. In automotive, the question of who trains on vehicle telemetry — the OEM, the fleet operator, the insurance company, or the cloud platform — is reshaping business models and partnership strategies. In building automation, the same contest is playing out between equipment manufacturers, facility managers, and energy-optimisation platforms. Machine builders in the DACH Mittelstand are entering the same arena, and the Data Act is the starting gun.
Map your data rights, or someone else will map them for you
The first strategic task is to inventory what telemetry your machines generate and classify it by training value and contractual exposure. Not all telemetry is equal. Operational parameters that reveal your control algorithms, proprietary tuning heuristics, or design trade-offs are high-value training inputs that you want to protect or monetise. Usage logs that describe customer behaviour but do not expose your intellectual property are lower-risk sharing candidates. Diagnostic codes, error sequences, and maintenance intervals sit somewhere in between: they are useful for training predictive models, but their value depends on aggregation scale and labelling quality.
The Data Act distinguishes between data generated by the product and data derived from it, and it allows manufacturers to protect trade secrets and commercially sensitive information. The practical challenge is that trade-secret claims are only as strong as your documentation. If you cannot demonstrate that a specific telemetry stream embeds proprietary knowledge, a customer or regulator will treat it as shareable by default. Many machine builders have never formalised this distinction because they never needed to: telemetry stayed inside their own systems, so the legal boundary was irrelevant. The Data Act makes it load-bearing.
The second task is to design customer data-access workflows that preserve your training optionality. The regulation requires that data be made available in a usable format, but it does not prescribe the technical implementation. A machine builder that provides raw telemetry dumps via FTP loses control of the training loop. A machine builder that provides structured APIs with granular access controls, usage telemetry, and model-training exclusions retains leverage. The difference is not just technical — it is strategic. If you know which customers are exporting telemetry, which third parties they are routing it to, and which use cases they are pursuing, you can make informed decisions about where to invest in your own AI capabilities, which partnerships to pursue, and which data streams to ringfence.
The third task is to audit your existing contracts and platform partnerships. Many machine builders already share telemetry with cloud providers, analytics vendors, or service partners under agreements that were drafted before the Data Act and before industrial AI became a contested domain. Those agreements often grant the platform provider broad rights to use telemetry for model training, benchmarking, or service improvement. If a customer now exercises its Data Act rights to access the same telemetry, and you are contractually obligated to let your platform partner train on it, you have created a scenario where your customer's data trains a model that your platform partner sells back to your competitors. The time to renegotiate those terms is before the customer makes the request, not after.
The AI strategy is not what you build — it is what you prevent others from building
For many DACH machine builders, the instinctive response to the Data Act will be defensive: minimise what you share, delay access requests, and treat the entire regime as a regulatory burden. That response is understandable but incomplete. The organisations best positioned post-Data-Act are those that either accelerate their own AI capabilities or establish strategic partnerships that preserve training optionality. For firms with fewer than fifty-person IT teams and limited ML expertise, strategic partnerships with contractual training-data protections are typically more viable than building in-house capabilities; for larger Mittelstand with existing data teams, selective in-house development may be feasible. If customers can export telemetry and train their own models, the only way to remain strategically relevant is to train better models faster, embed them into products and services that customers value, and make the cost of replicating that intelligence higher than the cost of staying in your ecosystem.
This does not require a hyperscaler-scale AI lab. It requires a clear view of which operational problems your telemetry can solve, which models can solve them, and how to deploy those models in ways that create customer lock-in rather than data lock-in. A predictive maintenance model that runs on-premise and updates itself with local telemetry is stickier than a cloud service that requires continuous data upload. A generative design tool that suggests machine configurations based on historical performance is stickier than a dashboard that visualises raw telemetry. A control algorithm that adapts to process variations in real time is stickier than a static parameter set that customers can reverse-engineer.
The economic logic is straightforward: if your competitive advantage depends on customers not having access to their own data, the Data Act has already eliminated that advantage. If your competitive advantage depends on turning data into intelligence that customers cannot easily replicate, the Data Act becomes an opportunity to differentiate. The organisations that treat it as the former will spend the next two years in a defensive crouch. The organisations that treat it as the latter will spend the next two years building the AI capabilities that define the next decade of industrial competition.
The deadline is not September 2025 — it is the moment your customer asks
The Data Act's enforcement date is a regulatory milestone, but the strategic deadline is the first time a customer, a platform partner, or a competitor asks for telemetry access and you do not have a coherent answer. That moment will expose whether you have mapped your data rights, designed your access workflows, and built the AI capabilities that make telemetry sharing a manageable risk rather than an existential threat. For most machine builders, that moment is closer than they think.
The work is not legal or technical in isolation — it is strategic. It requires Geschäftsführung to decide which telemetry streams are core to future competitive advantage, which can be shared without material risk, and which require new AI capabilities to defend. It requires IT and product teams to design systems that make data access auditable, controllable, and monetisable. It requires commercial teams to rethink service models, partnership terms, and customer contracts in a world where telemetry is no longer a passive asset but an active training input. And it requires all three functions to move faster than the platforms, aggregators, and competitors who are already positioning themselves to capture the learning loop.
A Fit Call maps your machine telemetry landscape, identifies high-value training assets, and designs the access and AI workflows that turn the Data Act from a compliance obligation into a competitive advantage — before your customer routes your data to a platform that trains your competitors' models.
This article draws on the author's experience advising DACH industrial firms on AI strategy and data governance in regulated environments. No external studies or regulatory guidance documents were cited.