Foreign Adversary Data Rules and AI: How DOJ’s Data Security Program Restricts AI Development

If your company develops AI — trains models, processes large datasets, operates cloud AI infrastructure, or employs developers overseas — there is a regulatory framework now in full effect that may apply to your operations in ways you have not considered.

The Department of Justice’s Data Security Program (DSP), which reached full enforcement on October 6, 2025, restricts and in some cases prohibits transactions that give certain foreign adversary countries or their controlled entities access to bulk sensitive personal data about Americans. The Protecting Americans’ Data from Foreign Adversaries Act of 2024 (PADFAA), which applies specifically to data brokers, creates an absolute prohibition on sales of personal data to entities controlled by foreign adversaries.

Together, these frameworks create a compliance obligation that cuts across the AI development lifecycle: from the datasets used to train models, to the overseas engineers who access those datasets, to the cloud AI vendor contracts that route data to foreign-operated infrastructure. For U.S. companies with global AI operations, understanding and complying with these restrictions is now a legal obligation, not a best practice.

This post explains how the frameworks work, where they intersect with AI development, and what compliance steps U.S. companies need to take.

The Two Frameworks: DSP and PADFAA

The DOJ Data Security Program

The DSP was created under Executive Order 14117, signed in February 2024, which directed the DOJ to establish regulations preventing foreign adversaries from accessing bulk sensitive personal data about Americans. The Final Rule was published in the Federal Register on January 8, 2025, took effect April 8, 2025, and reached full compliance requirements — including due diligence, auditing, and reporting — on October 6, 2025. The DOJ began active enforcement on July 8, 2025.

The DSP applies broadly to U.S. persons — including companies, citizens, and organizations — that collect, store, or transfer bulk U.S. sensitive personal data or government-related data. It regulates “covered data transactions,” which are defined as transactions involving:

• Access by a country of concern or covered person to bulk U.S. sensitive personal data or government-related data
• Through one of four transaction types: data brokerage agreements, vendor agreements, employment agreements, or investment agreements

The countries of concern under the DSP are China (including Hong Kong and Macau), Cuba, Iran, North Korea, Russia, and Venezuela.

Covered persons include entities that are 50% or more owned by or controlled by countries of concern, entities organized under the laws of countries of concern, certain officers, directors, and employees of those entities, and individuals who are residents of countries of concern.

PADFAA

PADFAA — the Protecting Americans’ Data from Foreign Adversaries Act of 2024 — is a statute, not a regulatory program. It applies specifically to “data brokers” and creates an absolute prohibition: data brokers may not sell, license, rent, trade, transfer, or otherwise make available personally identifiable sensitive data of U.S. individuals to a foreign adversary country or to any entity controlled by a foreign adversary.

PADFAA does not have the nuanced restricted/prohibited transaction distinction that the DSP uses. If you are a data broker, and the transaction involves a foreign adversary country or controlled entity, it is prohibited. Period.

The FTC has enforcement authority over PADFAA violations. Given the FTC’s active posture on data broker practices, companies in the data brokerage business — including companies that provide data licensing services, data enrichment, audience segmentation, or similar data commercialization products — need to assess whether they qualify as data brokers under PADFAA and whether any of their customer relationships implicate foreign adversary entities.

How the Frameworks Apply to AI Development

The intersection of these data security restrictions with AI development is not hypothetical. The DOJ itself identified AI training as a specific national security concern: foreign adversaries could exploit access to large datasets of U.S. personal data to train AI systems and develop military capabilities. Here is how the restrictions apply across the AI development lifecycle:

Training Data

The most direct application is to the datasets used to train AI models. If those datasets contain bulk sensitive personal data about Americans — health data, financial data, geolocation data, biometric data, or other covered categories — and they are accessed by or transferred to covered persons or countries of concern, that access or transfer is a covered data transaction under the DSP.

The bulk thresholds matter here. The DSP’s restrictions apply when the data involved exceeds specified volume thresholds:

• Human genomic data on more than 100 U.S. persons
• Biometric identifiers on more than 1,000 U.S. persons
• Precise geolocation data on more than 1,000 U.S. devices or persons
• Personal health data on more than 10,000 U.S. persons
• Personal financial data on more than 10,000 U.S. persons
• Covered personal identifiers linked to the above categories for more than 100,000 U.S. persons

AI training datasets — which often involve millions or billions of data points — routinely exceed these thresholds. Any company that has assembled a large dataset of U.S. personal data and uses it to train AI models should assess whether that dataset constitutes bulk sensitive personal data under the DSP.

The DOJ provided a telling example in its guidance: a U.S. online gambling company licenses a derivative AI algorithm trained on impulsivity identifiers for targeted advertising to a U.S. subsidiary of a company headquartered in a country of concern. Because the algorithm can reveal the raw training data, the transaction is prohibited when the subsidiary attempts to share the algorithm with its foreign parent company. The implication for AI development is significant: an AI model trained on covered data may itself be treated as carrying that data’s sensitivity — meaning export of the model to a covered entity may be restricted under the DSP even if the underlying data was not directly transferred.

Overseas AI Development Teams

Companies with AI development teams in China, Russia, or other countries of concern face a specific employment agreement coverage issue. The DSP covers employment agreements through which covered persons obtain access to bulk sensitive personal data. If engineers located in or controlled by entities in countries of concern have access to datasets that meet the DSP’s bulk thresholds, those access arrangements are covered data transactions.

The same issue arises for employees in countries of concern working for U.S. subsidiaries, affiliated entities, or branches: the DSP looks at where the individual is located and whether they are a covered person, not just whether the legal entity they work for is U.S.-based.

Companies that have global AI development teams — with engineers in China, Russia, or other countries of concern accessing centralized data repositories — should audit those access arrangements against the DSP’s definitions. The DSP does not prohibit these employment relationships, but it does require that restricted transactions proceed only under applicable CISA security requirements, with documentation, annual certifications, and vendor verification processes in place.

Cloud AI Vendor Contracts

The vendor agreement prong of the DSP is the least-anticipated compliance trigger for many AI companies. A vendor agreement is covered when it involves a covered person providing a service to a U.S. company and, in the course of that service, accessing bulk sensitive personal data.

In the AI context, this applies to:

Cloud AI providers. If a U.S. company uses a cloud AI platform — for model training, data processing, model hosting, or inferencing — and that platform is operated by or has data access arrangements with entities in countries of concern, the service contract is a covered vendor agreement. The U.S. company must assess whether the cloud provider or any subprocessors in its supply chain are covered persons, and if so, implement the DSP’s security requirements.

Data annotation and labeling vendors. AI model training frequently relies on third-party annotation services. Many annotation service providers operate in or have significant operations in China, India, and other jurisdictions. If those providers are covered persons and they access bulk sensitive personal data in the course of annotation work, those service contracts are restricted transactions under the DSP.

AI analytics and inference vendors. Companies that feed U.S. personal data into third-party AI inference or analytics services — for recommendations, fraud detection, risk scoring, or other purposes — need to assess whether those services involve covered persons accessing that data.

Prohibited vs. Restricted Transactions: What the Distinction Means

The DSP distinguishes between prohibited and restricted transactions:

Prohibited transactions are transactions that are flatly barred. Data brokerage transactions — the sale or licensing of covered data to countries of concern or covered persons — are prohibited. There is no compliance pathway that allows a prohibited transaction to proceed; the only option is a DOJ license.

Restricted transactions are transactions that may proceed, but only if specific security measures and contractual safeguards are in place. Vendor agreements, employment agreements, and investment agreements that would otherwise be covered can proceed as restricted transactions if the parties implement CISA’s Security Requirements for Restricted Transactions, execute required contractual provisions, maintain required records, and comply with reporting obligations.

The practical difference is significant for AI development:

• If your company licenses its AI training dataset to a Chinese company — that is likely a data brokerage transaction and is prohibited.
• If your company uses a cloud AI provider that is partially controlled by Chinese investors and that provider accesses your training data — that is likely a vendor agreement and is a restricted transaction that can proceed with appropriate safeguards.
• If your company employs AI engineers in China who access your U.S. health or financial dataset — that is an employment agreement transaction that is restricted and must comply with CISA security requirements.

CISA Security Requirements for Restricted Transactions

For restricted transactions to proceed lawfully, companies must implement CISA’s Security Requirements for Restricted Transactions. These requirements include:

Data minimization. Covered persons should only access the minimum data necessary for the specified purpose. Training pipelines and data access architectures should be designed to limit what data is actually accessible to covered persons.

Logical and physical access controls. Systems containing covered data must implement access controls that prevent unauthorized access by covered persons. This includes role-based access controls, multi-factor authentication, access logging, and network segmentation.

Data masking and anonymization. Where possible, sensitive fields should be masked or anonymized before being made accessible to covered persons. Note that masking and anonymization do not automatically resolve the issue — if the dataset can be re-identified through linkage with other data, it may still be treated as covered data.

Audit logging. All access to covered data by covered persons must be logged, and those logs must be retained for required record retention periods.

Annual certifications. Companies engaged in restricted transactions must maintain written, annually certified policies describing compliance and security measures. These certifications must be made by a senior executive with knowledge of the company’s data practices.

Annual independent audits. Companies engaged in restricted transactions must conduct annual independent audits to ensure that compliance programs are functioning as intended. Audit reports must be retained for 10 years.

10-year record retention. Complete, accurate records of all restricted transactions must be retained for at least 10 years.

Annual reporting for cloud-based transactions. Companies involved in restricted cloud-based transactions must file annual reports with the DOJ summarizing the prior year’s activities.

Reporting Obligations

The DSP creates specific reporting obligations that AI companies with global operations need to understand:

Rejected prohibited transaction reporting. If a company receives and rejects a transaction that would have been a prohibited data brokerage transaction — for example, a license inquiry from an entity controlled by China — it must report that transaction to the DOJ within 14 days.

Annual cloud transaction reporting. Companies with ongoing restricted vendor agreements involving cloud-based data transactions must file annual reports.

These reporting obligations mean that DSP compliance is not a one-time due diligence exercise. It requires ongoing monitoring of transaction flows, vendor relationships, and employment access patterns, with documented reporting at regular intervals.

Enforcement Posture

The DOJ began active enforcement of the DSP on July 8, 2025. The program is administered by the DOJ’s National Security Division, which brings deep experience in national security enforcement and is not known for lenient treatment of willful violations.

During the initial 90-day period following the rule’s April 8, 2025 effective date, the DOJ adopted a limited enforcement policy for companies making good-faith compliance efforts — but reserved the right to pursue egregious or willful violations even during that window. As of July 8, 2025, that grace period ended.

Penalties for violations can be substantial. The DSP’s enforcement authority includes civil and criminal penalties. The same companies that are struggling to comply with the CISA cybersecurity requirements applicable to government contractors, or with BIS export controls on AI chips, will now also face DSP enforcement if their data access arrangements involve covered persons.

Practical Compliance Steps for U.S. Companies with Global AI Operations

Map your data against the DSP’s bulk thresholds. Identify every dataset in your AI development environment that could constitute bulk sensitive personal data. The volume thresholds are not high by AI training standards — 10,000 U.S. persons’ health or financial data, or 100,000 covered personal identifiers, are amounts that many AI training datasets exceed by orders of magnitude.

Audit your overseas AI development team access. For every team member located in or controlled by a country of concern who has access to covered datasets, document the access arrangement, assess whether it constitutes a restricted transaction, and implement the CISA security requirements if it does.

Review your cloud AI vendor contracts for covered person exposure. Assess whether your cloud AI vendors, annotation vendors, or data processing vendors are covered persons or have covered persons with access to your data as part of their service delivery. This requires looking beyond the primary contracting entity to subprocessors and infrastructure providers.

Implement a data access governance framework. Restricted transactions require documented, certified compliance programs. If you do not have a formal data access governance framework — with defined access controls, audit logging, and annual certification processes — build one.

Build DSP compliance into AI vendor procurement. Every new AI vendor contract should include representations from the vendor about covered person access, CISA security requirement compliance, and data handling practices. Flow-down obligations should require subprocessors to comply with DSP requirements applicable to covered data.

Assess your PADFAA exposure if you provide data services. If your business model involves data licensing, audience segmentation, data enrichment, or any service that could qualify as data brokerage, assess whether any of your customers are entities controlled by foreign adversaries. If they are, the transaction is flatly prohibited.

Consult the DOJ’s FAQ and consider an advisory opinion. The DOJ has published implementation guidance and an extensive FAQ for the DSP. For genuinely ambiguous situations, the DOJ provides an advisory opinion process through which companies can obtain formal guidance on whether a specific transaction is covered and how to proceed.

The Bigger Picture

The DSP and PADFAA are part of a broader U.S. government effort to address the national security implications of foreign adversary access to Americans’ personal data. That effort includes CFIUS reviews of foreign investment in data-intensive businesses, BIS export controls on AI chips and model weights, and the AI-specific provisions of NSPM-11 and EO 14409. For companies building AI, these frameworks are not isolated compliance obligations — they form an interlocking set of restrictions on how data flows across borders and how AI capabilities can be shared with foreign parties.

The AI companies that will navigate this environment most successfully are those that build national security compliance into their development processes from the beginning, rather than treating it as an afterthought. The data that trains your models, the engineers who build your systems, and the infrastructure that delivers your AI products are all subject to scrutiny under frameworks that are now fully in force and actively enforced.

This post is for general informational purposes only and does not constitute legal advice. Reading this post does not create an attorney-client relationship. If you have questions about your specific situation, consult a qualified attorney.