Ask a practice principal whether they can use AI on a live project and the honest answer is usually a worried shrug. The worry is reasonable — project files carry personal data (site survey contacts, client records, correspondence), and nobody wants to find out after the fact that it was quietly shipped to a model in another jurisdiction and used to train it. But the worry tends to attach to the wrong question. Under the UK GDPR and the Data Protection Act 2018, the question is not whether you are allowed to use AI. It is whether the AI you use keeps your data where it should be, uses it only for the job, and leaves a human accountable for what comes out.
Strip GDPR back to what it actually asks of an engineering practice and there are three practical tests. Where is the project data stored and processed, and can it leave the region you declared? Is it used for any purpose beyond delivering your job — most pointedly, is it reused to train a model? And does a human remain accountable for the output, or does a machine produce a finished-looking answer that nobody signed? Get those three right and using AI for MEP design is lawful. Get any of them wrong and the technology is irrelevant; you have a data-protection problem regardless of how good the tool is.
The trouble with a general-purpose AI copilot is that it tends to fail all three at once, and silently. The file goes to a public model endpoint in a region the buyer cannot name. The consumer terms permit the provider to retain prompts and train on them unless someone found and toggled an opt-out. And the output arrives looking complete — a drafted spec, a sized cable — with no record of who checked it and no signature behind it. None of that is malicious. It is simply what happens when a tool was built to be helpful to an individual user, not to stand up to a practice's data-processing obligations. The first time it matters is during a DPIA or a client security review, which is the worst time to discover it.
WYRM MEP is built the other way round, starting with where the data lives. Project data is held 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 data is processed outside the declared region. For practices that need to remove the question entirely, WYRM MEP can be deployed as an on-prem node or inside your own private single-tenant cloud, so project files — and any personal data inside them — never leave your infrastructure at all. That single architectural choice closes off most of the cross-border transfer and third-party access questions before they are asked.
The second test — training — is where WYRM's engineering design does the work for free. WYRM MEP does the maths with deterministic, rule-based calculation engines, not a model that learns from your files, so there is simply nothing being trained 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 drawings, your schedules, and the personal data they contain are never used to train anyone's model and are not kept by the model provider after the inference returns. Minimisation follows the same logic: WYRM MEP works from design data — loads, geometry, standards, plant — and processes personal data only as far as a task needs, encrypted in transit and at rest.
GDPR's accountability principle asks you to be able to show what you did, and this is where the audit trail earns its place. Every WYRM MEP output carries a full calculation pack — inputs, rule versions, sources, and an audit hash — and the decision logs are append-only and cryptographically verifiable, retained for seven years by default. If a client, an auditor, or a regulator asks what data was processed, on what basis, and who signed it off, the answer is a record rather than a reconstruction. That is the same property that makes the engineering defensible, applied to the data-protection question.
The third test is the one engineers care about most anyway: a human stays the authority. WYRM MEP is advisory by design. Nothing is issued on the agents' say-so — every output stays a draft until a named engineer reviews and signs it. There is no opaque, solely-automated deliverable leaving the building with a machine's confidence and no human behind it. That keeps engineering accountability and data-controller responsibility in the same place, with your practice, which is exactly where both belong. It also means the controller / processor split is clean: you decide what data is processed and why, you own the lawful basis and the client relationship, and WYRM processes that data only on your documented instructions under an Article 28 Data Processing Agreement, available on request and default on Enterprise.
None of this is legal advice, and it does not relieve a practice of its own obligations — you still set the lawful basis, run the DPIA where one is needed, and answer to your clients as the controller. What the architecture does is make those obligations cheap to meet rather than expensive to retrofit: the data stays in your environment, it is never used to train a model, the record is kept for you, and a human signs. We set the full position out plainly on the GDPR & MEP AI page at wyrm.ai/gdpr-mep-ai and in the WYRM trust centre, including residency, encryption, sub-processors and breach notification. WYRM MEP is in active pilot now, and the cohort is enlisting — if the data-protection question is the thing holding your practice back from putting AI near a real project, it is the first thing worth testing on your own files.