Export control when your AI engineer is in China

The idea that catches people out

Export control is usually imagined as a shipping question — hardware crossing a border with paperwork attached. The part that surprises engineering teams is that in both the UK and the US, making controlled technology or software available to a foreign national can itself be the controlled act, regardless of whether anything physically moves and regardless of where the person is sitting.

Which means the relevant events are ordinary ones. Adding somebody to a repository. Granting a cloud console role. Sharing model weights, training code or design files. Explaining a controlled technique in detail on a call. Each of those can be a transfer, and none of them looks like an export while you are doing it.

This is not a reason to avoid hiring in China. It is a reason to decide deliberately what a given person may reach, which is something you should be doing regardless.

Why AI work sits closer to the line than most software

General web and application engineering rarely touches controlled technology. Some AI and adjacent work does, and the categories that most often come up are:

• Semiconductor and chip design tooling. The most clearly controlled area, and the most actively enforced. If your work involves EDA tools or advanced chip design, take specialist advice before you scope the role, not after.
• Advanced computing infrastructure. Controls in this area have moved repeatedly in recent years and concern access to high-end compute as well as the hardware itself.
• Model weights above certain thresholds. The idea that a trained model can itself be controlled technology is newer than most policies, and it is the one engineering teams are least likely to have considered.
• Defence, aerospace, nuclear and cryptographic work. Long-established controls with their own regimes. If you are in these sectors you already have a compliance function, and this decision belongs with them.
• Anything with a government or defence customer. Your contract may restrict foreign-national access independently of export law, and contractual restrictions bite just as hard.

Conversely: an internal tool, a recommendation system, a customer-facing product, most NLP and computer-vision work, and the great majority of MLOps has no export-control dimension at all. Most engagements fall here — the point is to establish which side yours is on deliberately, rather than assuming.

US rules are stricter, and that matters if you are American

Both regimes exist, but they are not equivalent. US controls in advanced computing and semiconductors have been extended repeatedly and specifically with China in mind, and US persons and companies face obligations with no direct UK counterpart. They also reach further than people expect: a US-headquartered company's UK subsidiary may still be inside them, and some controls follow US-origin technology wherever it ends up.

So if your parent company is American, or your technology stack has US-origin controlled components, assume the US analysis governs and get it done by somebody who does this for a living. This is the single most common reason a US engineering manager's enthusiasm meets a flat no from their own legal team, and finding out in week one is enormously cheaper than in week twelve.

The practical answer: scope access, not trust

Most of this becomes manageable through access design, and the good news is that the controls are ones a well-run engineering organisation wants anyway:

• Least privilege, from day one. Access to the repositories the work needs, not the organisation. Retrofitting this after somebody has had broad access for three months does not undo the three months.
• Segment the environment. A development environment with synthetic or anonymised data, and no standing production access, resolves the data-protection question at the same time.
• Keep controlled material out of reach structurally. If some part of your estate is genuinely controlled, the answer is an access boundary, not a policy document saying people should not look.
• Log and review. Being able to state afterwards exactly what was accessible is worth a great deal, and impossible to reconstruct later if you did not capture it.
• Write down what was decided and why. If the position is ever questioned, a dated note recording the assessment is far better than a recollection.

Questions to settle before anyone starts

• Does this role touch chip design, advanced compute provisioning, model weights, cryptography, or defence work?
• Is the company, its parent, or its funding US-connected?
• Do any customer contracts restrict foreign-national access?
• What is the smallest set of systems this person needs, and can we grant exactly that?
• Who signs off that this assessment was made, and where is it recorded?

If the answer to any of the first three is yes or uncertain, that is a conversation with a specialist before a shortlist, not after an offer.

Where we stand on this

We are a recruitment business, not an export-control adviser, and nothing here is legal advice. What we will do is raise the question on the first call and tell you plainly if we think your use case needs specialist input — including when that means we do not take the engagement.

That is not caution for its own sake. An engagement that has to be unwound because nobody asked is worse for you than one we declined, and it is worse for us than the fee. Related: who owns the IP and the engagement model itself.