AI Export Controls, in depth: classifying chips, weights and cloud access, a dated rule register, screening as a pipeline and the IaaS knowledge trigger

Four questions behind every export decision

Every export question has four parts, and a compliance system needs a field for each. What is the item, and what is its Export Control Classification Number (ECCN)? Where is it going, by country group? Who is receiving it, and are they on a restricted list? Why: what is the end use? A licence requirement can come from any one of the four. A chip with a high ECCN can ship freely to one country and need a licence for another. An unremarkable item (EAR99) can need a licence because the buyer is on the Entity List. And an item no list mentions can be caught by a catch-all end-use control because you know what it will be used for.

That last point is the one AI teams miss. Several AI-related controls are triggered by knowledge, which in the EAR includes awareness of a high probability, not just certainty. If your sales notes say a customer plans to train a frontier model for a restricted party, the system has knowledge, whether or not anyone read the note. So the inputs to screening are not only form fields; they are contracts, support tickets and usage telemetry, and the compliance pipeline has to be allowed to see them.

Classifying what an AI company ships

AI businesses ship three kinds of thing, and each is classified differently.

Hardware. Advanced accelerators fall under ECCN 3A090, and computers containing them under 4A090. Since the October 2023 rule (effective 17 November 2023), 3A090.a covers integrated circuits with a total processing performance (TPP) of 4800 or more, or a TPP of 1600 or more combined with a performance density of 5.92 or more. TPP is defined as 2 x MacTOPS x the bit length of the operation, taking the highest value across supported precisions; performance density is TPP divided by die area in square millimetres. Vendors publish their own ECCNs and you should use those, not compute your own, but the arithmetic tells you why a chip moved between categories.

Model weights and software. Software and technology that are published, meaning made available to the public without restriction, are generally outside the EAR, which is why openly released weights have not been the focus of controls. Closed weights are different. The January 2025 AI Diffusion Rule created ECCN 4E091 for the weights of certain closed frontier models. BIS announced the rescission of that rule on 13 May 2025, and public commentary at the time noted that BIS had not separately addressed 4E091. Treat the current status of weight controls as something to confirm with counsel against the live text of the EAR, not something to infer from news. Separately, most commercial software that uses encryption still needs an encryption classification (often 5D002 or the mass-market treatment), and inference servers are no exception.

Services. Renting GPU time is usually not an export of the GPU, because the chip does not move. But BIS guidance in May 2025 said that exporting advanced chips to an infrastructure-as-a-service (IaaS) provider triggers a licence requirement when there is knowledge that the provider will train AI models for or on behalf of parties headquartered in Country Group D:5 countries (which include China) or Macau. Cloud providers therefore carry an end-use obligation that flows down into customer onboarding.

Worked example: TPP arithmetic

A worked example shows why classification is arithmetic before it is law. Suppose a hypothetical accelerator delivers 1,000 dense tera multiply-accumulates per second at 8-bit precision. Its TPP is 2 x 1000 x 8 = 16,000, far above the 4800 line, so it is 3A090.a. Now suppose a cut-down version for a restricted market offers 150 TMAC/s at 8 bits on a 600 mm2 die: TPP is 2 x 150 x 8 = 2,400 and performance density is 2400 / 600 = 4.0. That is above 1600 but below 5.92 density, so it misses the 3A090.a test, though it may still fall under the lower 3A090.b tier, which counsel should check. This is the design space vendors navigated with export-specific SKUs.

Encode this in code only as a sanity check on vendor data, never as the classification of record:

def tpp(tmacs_per_s: float, bits: int) -> float:
    """Total processing performance: 2 x MacTOPS x bit length (per the 3A090 note)."""
    return 2 * tmacs_per_s * bits

def flag_3a090a(tmacs_by_bits: dict[int, float], die_mm2: float) -> bool:
    # take the highest TPP across precisions the chip supports
    t = max(tpp(v, b) for b, v in tmacs_by_bits.items())
    density = t / die_mm2
    return t >= 4800 or (t >= 1600 and density >= 5.92)

# sanity check vendor-declared ECCNs; disagreement opens a ticket for counsel
assert flag_3a090a({8: 1000.0, 16: 500.0}, die_mm2=800)
assert not flag_3a090a({8: 150.0}, die_mm2=600)

A dated rule register

Because the rules move, keep a dated register: one row per rule event, with the date it took effect, what it changed and which of your controls it touches. The table below is a starting register for AI compute, checked on the date of this article. Re-verify every row against the Federal Register before relying on it.

The January 2026 change is a good example of why the register needs a conditions column. Case-by-case review is available only if the applicant shows the export will not reduce production capacity available to US customers, that the Chinese purchaser has export compliance procedures including customer screening, and that the product passed independent third-party testing in the United States. Note that the second condition pushes screening duties onto the buyer as well.

Screening as a pipeline

The pipeline has five stages. Intake captures the organisation, claimed country, ultimate parent, intended use and, for compute, expected scale. Enrichment adds what the customer did not say: company registry data, the parent's headquarters, payment country, IP and network signals. Restricted-party screening matches names and addresses against the US government's Consolidated Screening List, which aggregates the Entity List, the Unverified List, the Military End User List, OFAC's SDN list and others. Destination and end-use evaluation applies country-group rules and the IaaS training trigger. Finally a rules engine combines everything into allow, hold or deny, and writes the inputs, the list versions and the rule version to an append-only log.

Two design choices matter more than the matching algorithm. First, screening must run continuously, not only at signup: lists are updated often, and a customer who was clean last month can be listed today. Second, the decision has to be replayable: given a date, you must be able to show which list version and which rule version produced the decision. That is what an investigator will ask for.

from dataclasses import dataclass
from rapidfuzz import fuzz          # any token-based fuzzy matcher works

D5_OR_MACAU = {"CN", "MO", "IR", "KP", "RU", "BY"}   # illustrative subset; load the real
                                                    # country groups from a versioned file
@dataclass
class Party:
    name: str; country: str; parent_hq: str | None; use: str; gpu_hours_month: int

def list_hits(p: Party, entries, threshold=88):
    hits = []
    for e in entries:                       # entries from the Consolidated Screening List
        score = fuzz.token_set_ratio(p.name.lower(), e["name"].lower())
        if score >= threshold:
            hits.append((e["source"], e["name"], score))
    return hits

def decide(p: Party, entries, list_version: str, rules_version: str):
    reasons = []
    if hits := list_hits(p, entries):
        reasons.append(f"restricted-party match: {hits[:3]}")
    hq = p.parent_hq or "UNKNOWN"
    if hq == "UNKNOWN":
        reasons.append("red flag: parent HQ cannot be determined")
    if p.use == "model_training" and hq in D5_OR_MACAU:
        reasons.append("IaaS training for party headquartered in D:5 or Macau")
    outcome = "deny" if any(r.startswith("IaaS") for r in reasons) else \
              "hold" if reasons else "allow"
    return {"outcome": outcome, "reasons": reasons,
            "list_version": list_version, "rules_version": rules_version}

The code never auto-clears a fuzzy match: a hit goes to a human, who records why it was a false positive. Tune the threshold on your own labelled history.

Red flags as computed signals

BIS's May 2025 guidance listed red flags for diversion of advanced computing chips. Each can be turned into a signal your pipeline computes rather than a paragraph in a policy.

For a cloud provider the equivalents are behavioural: a new account that immediately requests thousands of GPU-hours, payment from a third country, access patterns from networks inconsistent with the claimed location, or weights uploaded that match a model family associated with a restricted developer. None of these alone is proof; together they justify a hold.

Handling model weights

If you train closed models, treat weights as controlled until counsel says otherwise. Practical controls are the same ones you would use for any crown-jewel asset: weights in a dedicated storage account with no public access, access by named role, download disabled by default, every read logged, and serving from regions you have chosen deliberately. Two less obvious issues: a deemed export happens when controlled technology or source code is released to a foreign person inside the United States, so access reviews must consider nationality where controlled technology is involved; and replicating weights to a region for latency is an export decision, not only an infrastructure one. If you publish weights openly, keep a record of when and how they were published, since publication is what takes them outside the rules.

Failure modes

• Screen once, never again. A customer added to the Entity List keeps renting GPUs for months. Fix: re-screen the whole customer base on every list update.
• Country from billing only. The paying entity is in a permitted country; the parent is not. Fix: resolve ultimate parents and screen them too.
• Knowledge silos. Sales knows the end use; compliance never sees it. Fix: make the intended-use field mandatory and route deal notes to the rules engine.
• Auto-cleared fuzzy matches. A transliterated name scores just under the threshold. Fix: a review band below the threshold, and labelled examples to tune on.
• Stale rule files. The engine encodes the January 2025 tiers months after rescission. Fix: version rules, date them and tie each to a register row with an owner.
• No evidence. The decision was right but cannot be reconstructed. Fix: log inputs, list version and rule version with every outcome.

Trade-offs

Strict screening costs revenue and onboarding time; loose screening risks penalties and loss of export privileges, which for a hardware or cloud business is existential. Most teams settle on allow-by-default for low-risk signals, hold for any list hit or missing parent, and deny only on clear rule matches, with a review SLA measured in hours. Buying a screening service saves building list ingestion but not the end-use logic, which is specific to your products. And geo-blocking by IP alone is weak evidence in either direction; use it as one signal, never as the control.

What to do next

1. List every item you ship (hardware, software, weights, cloud access) and record its ECCN with the source of that classification.
2. Create the dated rule register above in your own repo and assign an owner to each row.
3. Add intended use, ultimate parent and expected compute scale to onboarding as required fields.
4. Ingest the Consolidated Screening List on a schedule and re-screen all customers on every update.
5. Implement the five BIS red flags as computed signals with a human review band.
6. Log every decision with list and rule versions, and practise reconstructing one.
7. Put model-weight storage, replication and access reviews under the same change control.
8. Read AI Regulation Deep Dive for the applicability engine pattern, AI Regulatory Watch for tracking rule changes, AI Compliance Program for ownership, and NIST AI RMF for mapping controls to a framework.