The deemed export trap
This article was drafted with AI assistance and reviewed by our team before publishing.
If your studio builds AI integrations or SaaS products for clients who touch military systems, dual-use hardware, or defense-adjacent supply chains, you may already have an export control problem — and you almost certainly don't know it yet. The trap isn't in what you ship. It's in how you work. The International Traffic in Arms Regulations (ITAR) — the U.S. framework that governs the export of defense-related technology — has a legal concept called a "deemed export." In plain terms: sharing controlled technical data with a foreign national, *anywhere*, counts as an export to their home country. No shipment. No customs form. No crossing of a physical border. The moment a Ukrainian QA contractor views a repository containing certain training data, or a German engineer joins a debugging session over Zoom, that can constitute a transfer under U.S. law. In 2026, with AI-enabled defense capabilities now firmly in regulators' crosshairs, the exposure has quietly expanded into territory that catches digital studios completely off guard. This isn't a niche compliance risk for defense primes and Beltway contractors anymore. It's a live issue for any founding team that writes software, trains models, or integrates AI systems for clients whose products end up enhancing military capability — even indirectly, even unintentionally, and even when the client is based in Europe.
How 'Defense-Adjacent' Became a Moving Target
The problem starts with the U.S. Munitions List (USML) — the catalog of articles, services, and data that ITAR controls. Software and data that "enhance combat capability" or "support USML-controlled systems" are included. The phrase sounds concrete, but the boundary it draws is blurry by design. A fleet management SaaS that routes autonomous vehicles for a logistics company sounds civilian. Add a client who supplies those vehicles to a NATO procurement program and the calculus shifts. Train a computer vision model on imagery derived from defense-system specifications, and the training data itself may become controlled — even if the resulting model is deployed in a commercial context. As legal analysis from the National Law Review has outlined, targeting algorithms, autonomous decision-making systems, and AI models used in sensor fusion or battlespace awareness now sit squarely in the ITAR enforcement frame. The inflection point — the moment a project crosses from civilian to controlled — is rarely obvious during scoping calls. It becomes visible in retrospect, usually after a DDTC (Directorate of Defense Trade Controls) inquiry letter arrives.
The Ordinary Dev Workflow That Creates Extraordinary Risk
Here's where founders in digital studios get blindsided: the exposure doesn't come from doing something unusual. It comes from doing completely standard things on the wrong project. Consider a typical mid-size AI integration studio in 2026. Offshore QA team has access to the monorepo. A senior engineer in Bangalore reviews pull requests. A contractor in Warsaw joins weekly sprint calls where architectural decisions — including decisions about model training pipelines — are discussed openly. A training dataset derived from a defense client's internal documentation lives in an S3 bucket with IAM permissions that weren't audited when the project scope expanded. None of these practices are reckless. They are the default. But under ITAR's deemed export provisions, each one is potentially a violation if the underlying technology is controlled. Research from SIPRI on regulating AI algorithm and training data transfers makes clear that export control frameworks are increasingly being applied not just to finished systems but to the underlying algorithms, weights, and datasets — the very artifacts that live in your repositories and get shared across distributed teams every single day. The financial and reputational stakes are not theoretical. Civil penalties under ITAR can reach into the millions per violation, and violations are counted per instance of transfer — not per project.
Why AI Makes This Harder to Manage
AI projects compound ITAR exposure in ways that traditional software projects don't. The issue is the data layer. A conventional SaaS app has a relatively clean boundary between its code and its client's sensitive information. An AI integration doesn't. Training data, fine-tuning datasets, and model weights are often derived directly from client operational data — and if that client operates in a defense context, the data inherits that sensitivity. Model outputs can also re-encode controlled information in ways that are non-obvious. A logistics optimization model trained on military supply chain data may, in its weights, implicitly represent operational patterns that are themselves controlled. Analysis from Legal 500 covering ITAR's application to AI-enabled defense technologies emphasizes that regulators are catching up fast, specifically targeting autonomous systems and the algorithmic layer underneath them. The ambiguity isn't going away — if anything, it's being used as an enforcement lever, because it means a company can be found non-compliant even when it made a good-faith judgment call. The broader geopolitical context matters too. As CSIS analysis of U.S. allies' AI and semiconductor export control authority notes, allied nations are increasingly implementing their own parallel frameworks — meaning European studios serving both U.S. and EU defense-adjacent clients may face layered obligations from multiple jurisdictions simultaneously.
Practical Steps for Studios That Might Be in Scope
The goal here isn't to make every founder paranoid. It's to identify the decision points where a small amount of diligence prevents a very large problem. **Audit your client list against a simple dual-use checklist.** Before your next project kicks off with a defense-adjacent client, ask: does this client supply, operate, or maintain systems that appear on the USML? Does the deliverable — model, integration, SaaS tool — touch data derived from those systems? If the answer to either is "possibly," you need outside counsel before scoping begins, not after. **Treat repository access as a compliance event.** This is the operational change most studios resist because it creates friction. But granting a foreign-national contractor access to a repo that contains controlled technical data is, legally, an export. Add a nationality and work-authorization review step to your onboarding process for any project in the defense or dual-use space. This is not about discrimination — it is about license compliance, the same way you'd check software licensing before distributing a library. **Segregate sensitive training data at the infrastructure level.** If a client provides data derived from defense specifications, that dataset should live in a segregated environment with access controls that are audited and logged. Commingling it with a general-purpose development environment — the kind where your whole distributed team has ambient access — creates diffuse, hard-to-trace exposure. **Get a Technology Control Plan (TCP) in place early.** A TCP is a formal internal document that describes how your organization identifies, handles, and protects controlled technical data. It's required as part of many ITAR licenses and is increasingly expected by defense-adjacent clients during vendor qualification. Having one — even a lightweight version — signals operational maturity and creates a documented record that your team acted in good faith. **Know the difference between ITAR and EAR.** ITAR covers defense articles and services (the USML). The Export Administration Regulations (EAR) cover dual-use items, including many commercial AI tools and components. Some of your exposure may fall under EAR rather than ITAR, which carries a different licensing structure and different penalties. The distinction matters for how you structure your compliance posture, and conflating the two is a common mistake in studios that haven't worked in this space before. Kova Design Studio has worked with international AI studios navigating exactly this intersection — distributed teams, defense-adjacent client scopes, and workflows that were never designed with export control in mind. In practice, the most useful early interventions tend to be operational: mapping where controlled data actually lives in the development environment, identifying which team members have ambient access they don't need, and producing the basic documentation — access logs, data handling policies, a draft TCP — that demonstrates good-faith compliance efforts if questions are ever raised. Studios that have already gone through this process tend to find that the structural changes aren't as disruptive as anticipated; the harder part is knowing where to start. *This article is for informational purposes only and does not constitute legal advice. Studios that believe they may have exposure under ITAR, EAR, or related export control frameworks should consult qualified export-control counsel before making compliance decisions.* The founding teams most at risk are not the ones being reckless. They're the ones doing normal work, for interesting clients, with distributed teams — and not yet realizing that the regulatory frame around "interesting" changed while they were shipping.