The Cloud Loophole Wasn’t Built for a Controlled Quantum Computer

If your company provides AI or quantum tools as a cloud service to domestic and foreign customers, the legal foundation you’re probably relying on, often without knowing it by name, is a set of three BIS advisory opinions issued between 2009 and 2014. They’re short, they’re old, and they were written for a world where the compute behind a cloud service was never itself an export-controlled item. That world is over for quantum, and RASA (covered in Issue 01) is coming for the rest of it.

January 2009. A company asked BIS five questions about grid and cloud computing. The answers still define the industry’s compliance posture today: providing computational capacity is a service, not a transfer of a commodity, software, or technology, so it isn’t “subject to the EAR” by itself. More specifically, BIS held that the cloud provider is not the “exporter” of any data a customer generates or exports using that capacity, because the provider isn’t the “principal party in interest” in that transaction, the customer is, even though a foreign customer can’t actually be the “exporter” under the EAR’s own definition. That gap (someone benefits from the export, but no one is formally the exporter) is the seed of everything that follows. The opinion did flag two real limits: if you transmit EAR-controlled software or non-public technical documentation to enable use of the service, that transmission is an export; and the broad catch-all in § 744.6(a)(2) — the restriction on U.S. persons’ support for certain proliferation end uses, which applies regardless of whether any controlled item is involved, can still apply if you have “knowledge” the service will assist missile or chemical/biological weapons work, regardless of whether the underlying item is controlled at all.

January 2011. The follow-up addressed a narrower but critical question: if your cloud provider employs foreign nationals to administer the servers, does letting them near the infrastructure trigger a deemed export to their home country? BIS said no…but not for the reason usually assumed. The opinion’s mechanism is exporter-attribution, not an access condition: because the provider is not the exporter of technology its users place on the network, the provider needs no deemed export licenses for foreign-national IT staff even where those staff can access export-controlled data sitting on the servers. The deemed-export obligation, if any, belongs to the user whose controlled technology is released. That reallocation, not an infrastructure/content distinction, is what is doing the quiet work in how cloud and SaaS companies staff their operations teams, and it means the provider’s real exposure is contractual: your foreign-national administrators can create a licensing problem for your customer.

November 2014. The last piece: if a foreign user works entirely inside a cloud-based application, a SaaS storefront, in the opinion’s terms, without downloading the software itself, no export of that software has occurred. The user sends data in, gets processed data back, and the software never left the building, legally speaking.

Put together, these three opinions are the entire reason the SaaS and cloud computing industry has been able to sell globally for fifteen years without treating every login as a potential export event. They were never elevated to formal regulation, they’re advisory opinions responding to specific fact patterns, and BIS says as much in each one. But the industry has relied on them as though they were. One adjacent piece did make it into regulation: since 2016, § 734.18 has provided that transmitting or storing technology or software secured with end-to-end encryption is not an export. Note its limits, though, it protects data in transit and at rest; it says nothing about a foreign user remotely operating a controlled item, which is exactly the gap this issue is about.

Every one of those three opinions assumes the compute itself isn’t an export-controlled item. The service is what is being analyzed, precisely because the underlying hardware was not on the Commerce Control List. That assumption doesn’t hold anymore for quantum.

In September 2024, BIS’s plurilateral “Implemented Export Controls” rule added ECCN 4A906, covering quantum computers above a qubit-count and error-rate threshold (34 or more physical qubits, depending on gate error rate), a tiered control in which the qubit floor rises as the permitted error rate rises, so 34 is the floor, not the test, plus related components under 3A901 (cryogenic CMOS ICs, parametric amplifiers), 3A904 (cryocooling systems), 3B904 (cryogenic wafer probing equipment), and associated software and technology under 4D906/4E906. These carry worldwide licensing requirements, not just controls on a handful of adversary destinations, with a license exception available only for countries that have adopted comparable controls.

If the system underlying your cloud service is a quantum computer that clears the 4A906 threshold, you’re no longer in the fact pattern the 2009 opinion analyzed. That opinion’s entire holding rests on the provider not shipping or transmitting a controlled commodity, but if the “commodity” is the quantum computer itself, and a foreign customer is directing its use remotely, the 2009 logic doesn’t cleanly answer whether that remote direction is itself the kind of access BIS would treat as reaching the item. Nobody has tested this in a published opinion. That’s not a comfortable place to run a business from, but it’s where the law currently sits.

Don’t assume the 2011 opinion carries over to your quantum obligations at all: its protection runs to technology your customers put on your systems, not to your own. Where the controlled technology on the stack is the provider’s,  4E906 technology and 4D906 software on the provider’s own hardware, the provider is the principal party, and foreign-national engineers touching that stack present a plain-vanilla deemed export analysis with no cloud gloss. The September 2024 rule includes its own, narrower deemed export treatment: a general license authorizing deemed exports and reexports of certain quantum software and technology (under 3D901, 3E901, 4D906/4E906) to foreign persons whose most recent citizenship or permanent residency is in Country Group D:1 or D:5, but only if they aren’t otherwise a “prohibited person” under Part 744 (not on the Entity List, for instance). Two more features the audit will care about: the rule separately grandfathers foreign-person employees who already had access to the newly controlled technology and remained employed as of September 6, 2024, an exclusion that is analytically prior to the general license, and the general license itself carries reporting obligations, including annual updates on covered foreign-national employees and notification of terminations. Relying on the general license without the reporting is itself a violation. That’s a specific, conditional exclusion tied to particular ECCNs and citizenship categories. It is not the same thing as the 2011 opinion’s exporter-attribution logic, and treating them as interchangeable is exactly the kind of shortcut that gets flagged in an audit. If you have foreign-national engineers anywhere near the quantum stack, not just the cloud layer, check which framework actually covers their specific role and access.

Issue 01 covered the Remote Access Security Act in the context of AI compute. It applies with at least as much force here. RASA would amend the Export Control Reform Act to treat remote access to an item subject to the EAR, cloud and API access included, as an export event in its own right, when BIS determines the access poses a serious national security or foreign policy risk. A quantum computer classified under 4A906 is squarely an “item subject to the EAR.” If RASA passes the Senate in anything like its current House-passed form, a foreign customer remotely directing computations on your quantum hardware stops being a question BIS arguably lacks clear authority to reach and becomes one it can license, condition, or prohibit outright, the bill grants the authority rather than self-executing a license requirement, so the practical trigger would be BIS’s implementing rules or orders, regardless of what the 2009 opinion says about who’s the “exporter.” The bill’s sponsors have said explicitly that closing exactly this kind of cloud/remote-access gap is the point.

This issue is for informational purposes and is not legal advice. If your organization has specific exposure here, talk to export control counsel (we are cool and helpful) before your next product launch, not after.