Is AI for MEP engineering GDPR-compliant?
It can be — if the AI keeps your project data in your environment, never trains a model on it, and keeps a named engineer as the authority. That is exactly how WYRM MEP is built: UK data residency or an on-prem node, no-training and no-retention terms, an append-only audit trail, and an Article 28 DPA — with your practice staying the data controller.
The short answer
GDPR isn't about whether you use AI. It's about where the data goes.
Most practices ask the wrong question first. Under UK GDPR, AI is not banned for MEP — what matters is data residency, purpose, and accountability.
How WYRM MEP maps to GDPR
Six controls, each tied to a GDPR principle.
Not a policy page — architecture. Every control below is a design choice in WYRM MEP, held to what the WYRM trust centre commits to.
Your data stays in your environment
Residency · Art 44–49 transfers
Hosted in the UK by default (EU or UK-only on Enterprise), with no data processed outside the declared region. Where you need it, WYRM MEP runs as an on-prem node or a private single-tenant deployment, so project files and any personal data inside them never leave your infrastructure.
Never used to train a model
Purpose limitation · Art 5(1)(b)
The engineering is done by deterministic rule-based engines, not a model that learns from your files. The language models WYRM uses run under contracted no-training, no-retention terms as Article 28 sub-processors — your project data is never reused to train anyone's model.
Only what the calculation needs
Data minimisation · Art 5(1)(c)
WYRM MEP works from design data — loads, geometry, standards, plant — not personal data. Where files carry personal data (site surveys, client contacts, correspondence), it is processed only as far as a task requires and is encrypted in transit (TLS 1.3) and at rest (AES-256).
Everything leaves a record
Accountability · Art 5(2)
Every output carries a full calculation pack — inputs, rule versions, sources and an audit hash — and decision logs are append-only and cryptographically verifiable, retained for seven years by default. You can show what was processed, on what basis, and who signed it.
A named engineer is the authority
Human oversight
WYRM MEP is advisory, never authority. Nothing is issued on the agents' say-so: every output stays a draft until a named engineer reviews and signs it. The human stays in the loop and accountable — there is no opaque, solely-automated output leaving the building.
Processor terms in writing
Processor duties · Art 28 & 33
An Article 28 Data Processing Agreement is available on request and default on Enterprise, naming the sub-processors used (AI providers included, with Art 28(2) change notice), UK residency, and a breach-notification commitment aligned to the 72-hour ICO requirement under Article 33.
Generic AI copilot vs WYRM MEP
The same prompt, two very different data-protection postures.
A consumer AI copilot and WYRM MEP can both draft a spec. Only one of them is built to stand up to a DPIA.
| Generic AI copilot | WYRM MEP | |
|---|---|---|
| Where your data goes | Often a public model endpoint, region unclear | UK/EU residency, or on-prem in your environment |
| Training on your data | Frequently allowed unless you opt out | Never — no-training, no-retention terms |
| Who does the maths | A language model — opaque, non-deterministic | Deterministic rule-based engines, cited |
| Audit trail | Little or none — a chat history at best | Append-only calc pack with an audit hash |
| Accountability | Unclear — output looks finished | Advisory only; a named engineer signs |
| Processor agreement | Generic consumer terms, no DPA | Article 28 DPA; you stay the controller |
Who is responsible for what
You stay the controller. WYRM is the processor.
Your practice — data controller
You decide what project data is processed and why, you own the client relationship and the lawful basis, and your named engineer reviews and signs every output. The engineering responsibility and the data-controller responsibility both stay with you.
WYRM — data processor
WYRM processes that data only on your documented instructions under an Article 28 DPA, keeps it in your declared region (or your own infrastructure), never trains on it, and gives you the audit trail to evidence it. WYRM is advisory — it never becomes the authority.
This page is a plain-English summary of how WYRM MEP is built, not legal advice. For the full data-handling position — residency, encryption, sub-processors, breach notification and the DPA — see the trust centre and the privacy notice.
GDPR & MEP AI — FAQ
The questions practices ask before they let AI near a project.
Is it GDPR-compliant to use AI for MEP design?
Using AI for MEP design can be GDPR-compliant, but it depends on the tool, not the technology. UK GDPR turns on three practical questions: where your project data is stored and processed, whether it is used for any purpose beyond your job (such as training a model), and whether a human remains accountable for the output. An AI MEP tool meets GDPR when project data stays within a known region and your control, is never reused to train a model, is minimised to what the calculation needs, leaves an audit trail, and is covered by an Article 28 Data Processing Agreement — with a named engineer as the authority. WYRM MEP is built to satisfy each of those conditions.
Does WYRM MEP train its AI on our project data?
No. WYRM MEP does the engineering with deterministic, rule-based calculation engines, not a model that learns from your files — so there is nothing to train on your data. The language models WYRM uses only read, plan, draft and coordinate inside grounded prompts, and they run under contracted no-training, no-retention terms as Article 28 sub-processors. Your project data, drawings and any personal data they contain are never used to train anyone's model and are not retained by the model provider after inference.
Where is our project data stored?
Customer data is stored in the United Kingdom by default, with EU residency available on the Enterprise tier and a UK-only option for public-sector and regulated buyers. No customer data is stored or processed outside the declared region. For practices that require it, WYRM MEP can be deployed as an on-prem node or inside your own private cloud tenancy, so project files never leave your environment at all. Data is encrypted with TLS 1.3 in transit and AES-256 at rest.
Can WYRM MEP run on-premises or in our own cloud?
Yes. Alongside the hosted UK/EU service, WYRM MEP supports an on-prem node and private single-tenant deployment, with per-tenant isolation. This keeps project data — and any personal data in site surveys, client records or correspondence — inside your own infrastructure, which is the cleanest way to remove cross-border transfer and third-party access questions under GDPR.
Is there a Data Processing Agreement for WYRM MEP?
Yes. A Data Processing Agreement under Article 28 of the UK GDPR is available on request and is applied by default on Enterprise contracts. It sets out WYRM as your processor, the sub-processors used (including AI model providers, with change notification under Article 28(2)), UK data residency, and a breach-notification commitment aligned to the 72-hour ICO requirement under Article 33. The full position is set out in the WYRM trust centre.
Who is the data controller when we use WYRM MEP?
Your practice remains the data controller — you decide what project data is processed and why. WYRM acts as the processor, handling that data only on your documented instructions under the Data Processing Agreement. WYRM MEP is also advisory by design: every output stays a draft until a named engineer reviews and signs it, so engineering accountability and data-controller responsibility both stay with your practice. WYRM gives you the tooling and the records to meet your GDPR obligations; it does not take them over.