What actually happens to your files.

Start with our answer, not the essay

If you are here because you are about to send us a design history file, this is the part you need:

• Your documents are not used to train any model. Not ours, not a vendor's. This is contractual, in the statement of work, before you send anything.
• Your files live in an access-controlled workspace for the engagement, and are deleted or returned on your instruction at the end. The retention and deletion terms are written down before transfer, not described afterwards.
• Your work is never shared with another client, and never used as an example, a case study, or a demo. The demonstrations on this site run on synthetic data against fictional devices for exactly this reason.
• For sensitive programs, the AI layer can run on hardware you control, so the documents never leave your network at all. That is local AI, and it is a real option rather than a brochure line.

The rest of this page is why those four commitments are the right ones, and where the genuine risk actually sits.

The fear, stated fairly

The concern goes like this: we paste a design input specification into an AI assistant, the vendor keeps it, trains on it, and some fragment of our novel mechanism surfaces in a competitor's answer eighteen months later. For a company whose entire enterprise value is a mechanism and a clearance, that is not a paranoid worry. It is a correctly identified category of harm — irreversible, undetectable, and uninsurable.

It deserves a real answer rather than a reassuring one, because the reassuring version — "enterprise AI is secure" — is the kind of sentence that makes a careful reader trust you less.

The honest assessment

The single most important distinction is the one almost nobody makes explicitly: consumer-tier and business-tier access to the same model are governed by different contracts. They are not the same product with a different price. The consumer tier is generally governed by terms that permit the provider to use submitted content to improve their systems. The business and API tiers are generally governed by terms that do not.

That distinction is the whole ballgame, and it is why "is AI safe for our data" is an unanswerable question as posed. Safe under which agreement?

Check the agreement you actually have. Training, retention and zero-retention terms change over time and differ by vendor, by tier and by region, so read the current terms for the specific plan your team uses rather than relying on a general rule — including this one.

What you should require, in writing, from any AI-assisted vendor — including us:

• A contractual statement that your content is not used to train models.
• A stated retention period, and a deletion mechanism you can invoke.
• Named subprocessors, so you know who is actually in the chain.
• Which tier and which agreement they are operating under. "We use AI responsibly" is not an answer to this.

If a vendor cannot answer the fourth question quickly, they have not thought about it, and the first three answers are worth less than they appear.

The comparison nobody makes

Almost every device company reading this already keeps its design history file in a cloud eQMS, its CAD in a cloud PDM, its email with a hyperscaler, and its clinical data in a cloud EDC. Each of those is a third party holding the same intellectual property, under a contract, with a retention policy and a subprocessor list.

That does not make AI safe by association. It makes the standard clear: AI tooling should be evaluated the same way you evaluated your eQMS — contract, retention, subprocessors, deletion, audit rights — rather than as a new category requiring either blanket refusal or blanket trust. Device companies are unusually good at this evaluation. It is the same muscle as supplier qualification.

The risk that actually deserves the worry

The realistic exposure in most device companies is not the vendor's contract. It is that an engineer under deadline pasted a requirements document into a personal account on a consumer tier, and nobody knows.

Shadow AI is the first-order problem and it is chronically under-weighted, because it is embarrassing rather than technical. A procurement-blocked company with no sanctioned tool does not become a company where nobody uses AI. It becomes a company where AI use is invisible, unlogged, on personal accounts, under consumer terms — which is precisely the tier whose contract permits training on submitted content.

The uncomfortable conclusion: a blanket ban usually increases exposure. It moves usage from a governed tier to an ungoverned one and removes your ability to see any of it. If you take one operational thing from this page, make it that.

Second-order risks, in the order they actually bite:

• Output quality accepted uncritically. A confidently wrong AI-drafted rationale that nobody checked is a worse day than a data-handling question, and it is far more likely. This is why every deliverable we produce carries a named human reviewer and a record of what they changed.
• Prompt content in logs and integrations. The AI vendor is often not the only party in the chain — the plugin, the browser extension, and the workflow tool each have their own terms.
• Model-generated content entering the DHF unlabelled. Not a privacy risk, a records-integrity one, and an auditor will find it.

A decision framework

Classify by consequence-if-leaked rather than by document type. The question is not "is this confidential" — everything is — but "what happens if this specific content is exposed."

Most organisations apply the fourth row's caution to all four rows, which sounds conservative and is actually just expensive: it blocks the safe uses, delivers no protection on the genuinely sensitive ones, and pushes everyone to shadow tools.

Where local AI enters

For the bottom row — and for organisations whose customers or regulators make the question moot — the answer is that the model runs on hardware you control. Nothing transits, nothing is retained elsewhere, and the data-handling question stops being a contract question and becomes a network question, which your IT function already knows how to answer.

That is not free. Local models are meaningfully less capable than frontier cloud models, the hardware is real capital, and someone has to maintain it. We say so plainly on the local AI page rather than selling it as a strictly better option, because for most content in the table above it is not.

What we do, concretely

• Contractual no-training on your content, in the SOW, before transfer.
• An access-controlled workspace per engagement, with retention and deletion terms agreed in writing up front.
• Named subprocessors on request, before you send anything.
• A named human reviewer on every AI-assisted deliverable, with a record of what they corrected — the control for the output-quality risk, which is the one most likely to actually hurt you.
• A local-deployment option for programs where nothing may leave the building.
• Demonstrations on this site that run on synthetic data against fictional devices, because using a client's file as a demo is exactly the behaviour this page argues against.

If you want the specifics for your program, ask at the scoping review. It is a reasonable thing to interrogate, and a vendor who gets defensive about the question has answered it.

AI in our pictures and assistants

Some pictures on this site are AI-generated illustrations, including scenes of design, machining, lab and packaging work. They show the kind of work we do. They are not a specific project, client, device or facility, and no picture here is a test result.

Amp, and any other named assistant on this site, is AI, not a member of our team. Assistants look things up and point you to a person. They do not make judgment calls about your device.