Secure AI deployment in a European factory: a guide for both worlds — the plant floor and the business

A modern European factory is really two factories. The first is the plant floor: PLCs, sensors, production lines, maintenance — the world of operational technology (OT). The second is the commercial engine: the e-commerce store, marketing campaigns, ERP, customer data. AI is landing in both today — predictive maintenance on the floor, customer profiling in sales — and that is exactly why deployment becomes a trap. These two worlds have opposite risk profiles, yet most teams try to cover them with a single, averaged-out policy.

On the plant floor, what matters most is availability and physical safety, plus the integrity of data — a false sensor reading can damage a machine or halt production, and there is little personal data involved. On the commercial side it is the reverse: personal data and privacy dominate, and the stakes are regulatory fines and customer trust. This article walks through both worlds: first the foundation common to both, then each in turn, then the new front — attacks on the models themselves — and finally the regulatory umbrella and a practical deployment playbook.

Foundation: classify your data and define zones before you deploy anything

Every secure AI deployment starts not with the model but with a question: what data feeds this model, how sensitive is it, and where does it flow. This is an architectural decision that determines everything else.

The first trap sounds like this: "it's only machine data, so GDPR doesn't apply to us." Not true. Plant-floor data can be personal data — operator identifiers, shift patterns, the productivity of specific workers, and often data that becomes re-identifiable when combined with other datasets. Before an OT stream reaches cloud analytics, you need to know whether it carries traces of specific people.

The second principle comes straight from CISA's December 2025 "Principles for the Secure Integration of AI in OT": do not aggregate everything into one unsegmented data lake. The more you concentrate in one place, the more attractive and dangerous a single point of compromise becomes. Data should be classified (public / internal / sensitive / personal), segmented, and access granted on a least-privilege basis.

In practice, to start: inventory your data sources (PLC, ERP, GA4, ad pixel, CRM), assign each a sensitivity class, establish a legal basis for processing any personal data — and only then design which of them should reach the model at all.

World one: the plant floor (OT)

Predictive maintenance, PLC readings, integrations via API, inference at the network edge — these are today's most common AI uses on the floor. And the most critical, because an error doesn't end with a bad email but with a damaged machine or a production halt. The context is serious: manufacturing has been the most-attacked sector for four years running, ransomware incidents rose by more than 60% in 2025, and the Jaguar Land Rover breach was described as the most economically damaging in British industrial history.

Architecture: IT/OT separation is not a luxury, it's the first line of defense. Segmentation following the zones-and-conduits model of the IEC 62443 standard (and the Purdue architecture) is the single most effective defense against lateral movement from the office network into production. OT data should flow to AI analytics one-way — a data-diode / one-way transfer pattern means telemetry goes "up" to the model, but nothing comes back "down" to the controllers. This is crucial: an AI agent analyzing machine health should never have write access to the PLCs without a hard, human gate. The dream of "fully automated control by AI" is a blueprint for disaster.

Edge and API. If inference happens at the edge (on the floor), secure it per IEC 62443-4-2: secure boot, signed firmware, encryption. Treat the API between the OT layer and the model as a trust boundary — authentication, narrowly scoped authorization, validation of everything crossing it. Keep in mind a statistic that should worry you: 55% of OT environments already have four or more remote-access tools — each one an attack surface.

Incident response on the OT side is different from IT. You can't just "reboot" a line or pull it off the network mid-production. Playbooks must account for safe shutdown, continuity and physical safety — not just data recovery. Bring OT into security operations (SecOps) deliberately, with people who understand the realities of the floor.

In practice: zone/conduit segmentation (IEC 62443), one-way OT→analytics flow, no AI write access to controllers without oversight, edge hardening (62443-4-2), narrow APIs with validation, OT-specific IR playbooks, an inventory of remote-access tools.

World two: the commercial side (e-commerce, ERP, marketing)

Here AI does something different: it collects and analyzes data from campaigns on Meta and Google, from Google Analytics, joins it with ERP and CRM, to profile the customer and personalize the offer. The business value is obvious — but this is also the area where personal data dominates, and with it regulatory risk. Recall the scale of enforcement: GDPR fines alone reached €1.2 billion in a single year.

Consent and tracking. Almost all marketing tracking (GA4, the Meta pixel) is non-essential processing that requires valid consent under ePrivacy and GDPR — real, freely given, granular, not coerced through a dark pattern. The sunset of third-party cookies shifts the weight to first-party data and server-side tracking; this improves privacy, but it does not remove the consent obligation or the need for a legal basis.

Profiling and automated decisions (GDPR Article 22). This is the most frequently underestimated boundary. GDPR grants the right not to be subject to a decision based solely on automated processing where it produces legal or similarly significant effects. Personalizing an offer or targeting ads usually doesn't cross that line — but it can sit on its edge, and dynamic price differentiation or customer scoring may cross it outright. The CJEU's SCHUFA ruling (December 2023) extended Article 22's reach even to scoring that merely feeds a later human decision, and stated clearly that "rubber-stamping" — a person formally signing off on the algorithm's recommendation — counts as a fully automated decision. Where that line is crossed, you need real human oversight with the power to overturn the decision.

Purpose limitation and data provenance. Data collected to fulfil orders is not automatically fuel for training a marketing model — that's a different processing purpose. A new obligation is emerging too: training-data provenance. When you deploy a model, you must be able to show that the data it runs on was lawfully obtained.

Anonymization — and its most common myth. "We anonymized it, so we're outside GDPR" is a trap, because the bar for anonymization is set very high. The EDPB Opinion (28/2024) makes clear that anonymity is assessed case-by-case, and that personal data can be "absorbed" into a model and resurface in its outputs. Moreover, per the EDPB Guidelines (01/2025), pseudonymization is not anonymization — pseudonymized data is still personal data. Real risk-reduction techniques are minimization, masking, differential privacy, k-anonymity, and model "unlearning" mechanisms.

In practice: valid consent for tracking, server-side as support (not exemption), a map of where profiling touches Article 22, human oversight where the effect is significant, separation of purposes (orders ≠ marketing training), documented data provenance, deliberate anonymization rather than the illusion of it.

A new front common to both worlds: attacks on the models themselves

Whether the model predicts a bearing failure or suggests an offer, the model itself is a new attack surface. It helps to separate two kinds of threat.

Attacks on predictive (classic ML) models. The canonical reference is the NIST taxonomy (AI 100-2e2025). Three classes. Poisoning — corrupting training data or the sensor stream; an attacker who can subtly taint the data training a predictive-maintenance model will produce false "time-to-failure" forecasts, and therefore bad service decisions or sabotage of availability. Evasion — small, almost invisible perturbations of input that fool an already-deployed model (the same mechanism evades ML-based detection systems). Privacy attacks — membership inference and model inversion, i.e. extracting information about training data from the model. Defense: monitor model metrics (accuracy, error rate, anomalies) as a signal of compromise, use adversarial training and robust statistics, log model performance for security anomalies.

Attacks on the agent/LLM layer. Here the OWASP Top 10 for LLM Applications (2025) applies. The most dangerous is prompt injection, especially the indirect kind — malicious instructions hidden in content the model retrieves itself: in technical documentation, in a service ticket, in a product description inside a RAG store. The model reads it as data but executes it as a command. The second pillar is excessive agency: the more tools and permissions an agent has (access to ERP, to the plant API, to sending emails), the more dangerous a single poisoned entry becomes. A good design rule is to break the so-called lethal trifecta — an agent becomes truly dangerous only when it simultaneously has access to private data, exposure to untrusted content, and the ability to communicate externally. Cut off one of those legs. And always treat the model's output as untrusted data — never directly execute generated code, SQL or commands.

In practice: monitor predictive-model metrics, adversarial training, validate and filter sensor streams; for agents — treat RAG/tool content as untrusted, least-privilege tools, human-in-the-loop for high-impact actions, output validation, break the lethal trifecta, consumption limits, and adversarial testing of the deployment.

The regulatory umbrella: AI Act, GDPR and NIS2 at once

Three regimes run in parallel and must be mapped onto both worlds.

EU AI Act. The level of obligation depends on the use case. Predictive maintenance of a component relevant to a machine's safety may fall into the high-risk category of Annex I (AI embedded in regulated products) — and here, following the Digital Omnibus changes, the deadline for obligations has been pushed to 2 August 2028. Use-based high-risk systems under Annex III were moved to December 2027. Transparency obligations (Article 50), however, take effect on schedule on 2 August 2026 — if an e-commerce chatbot talks to a customer, that customer must know it's AI; generated content may be subject to labeling (provider-side watermarking was deferred to December 2026). General-purpose AI (GPAI) obligations have applied since August 2025. Penalties reach €35 million or 7% of global turnover. An important distinction of roles: building a solution on someone else's model via API usually makes you a "deployer"; substantially modifying a model can make you a "provider" with heavier obligations.

GDPR. The entire commercial side as above; add the observation that human oversight is a requirement of both GDPR Article 22 and the AI Act — the two regimes converge here, so one well-designed human-in-the-loop mechanism serves both compliance needs.

NIS2. Manufacturing is within the directive's scope as an important entity — meaning obligations for cybersecurity risk management, incident reporting, and management accountability. Technical frameworks (IEC 62443, NIST SP 800-82) provide an auditable basis to demonstrate compliance.

Deployment playbook: from design to operations

Putting this into practice, the safest deployments follow a lifecycle (design → procurement → deployment → operations) and a few cross-cutting principles:

• First assess whether AI is the right tool for the task, with clear success metrics — straight from CISA's OT guidance.
• Classify data and segment before connecting the model; separate processing purposes.
• Least privilege everywhere — for agents, APIs, tools and data streams; one-way OT→analytics flow.
• Human-in-the-loop for decisions with significant effect (one mechanism for both GDPR Article 22 and the AI Act).
• EEA-first and data residency — know where data actually goes; processing within the European Economic Area simplifies compliance and reduces transfer risk.
• Provenance and documentation — lawful origin of training data, an audit trail of the model's decisions.
• Continuous testing, not a one-off audit — adversarial testing of the deployment and monitoring of model metrics as an early signal of compromise.

Conclusion

Securely deploying AI in a European factory is not one project but two parallel ones — with opposite priorities — bound together by a shared model layer and a shared regulatory umbrella. On the floor you protect availability, integrity and physical safety; on the commercial side, privacy and compliance. In both, the new front is the model itself, which must be treated as an active part of the attack surface rather than a black box. The key is to design security and compliance in from the start — data classification, segmentation, least privilege, human oversight and continuous testing — instead of bolting them on at the end.

This is the philosophy on which we built Obsigen AI — a European enterprise-grade AI agent operating exactly at the intersection of these worlds: manufacturing and supply chain, cybersecurity, and e-commerce and sales. An EEA-first architecture, data processing within the European Economic Area, grounding answers in internal knowledge (RAG) and an emphasis on auditability are not add-ons but a response to precisely the challenges this article describes. More at obsigen.com.

Sources: CISA and partners, "Principles for the Secure Integration of AI in OT" (2025); ISA/IEC 62443 and NIST SP 800-82 Rev. 3; the NIS2 Directive; NIST AI 100-2e2025 (Adversarial ML); OWASP Top 10 for LLM Applications (2025); the EU AI Act (Reg. 2024/1689) together with the Digital Omnibus on AI agreement; GDPR (Reg. 2016/679), including Article 22 and the CJEU SCHUFA ruling (C-634/21), EDPB Opinion 28/2024 and Guidelines 01/2025. Dates and figures are described conservatively; some AI Act deadlines may change before the amendments are formally adopted.