BIS Guidance to Prevent Diversion of Advanced Computing Integrated Circuits

The guidance's most significant compliance implication is its explicit movement away from transaction-point screening toward a lifecycle analysis model that extends the exporter's compliance obligation well beyond the moment of shipment—a shift that requires structural changes to compliance program design rather than simply enhanced screening at existing checkpoints:

• Full product lifecycle visibility as the new compliance standard replacing destination and party screening as the primary due diligence mechanism — BIS's guidance makes explicit that exporters of advanced computing ICs are responsible for evaluating not only who they are selling to and where, but who ultimately uses the chips and in what computational environment they are deployed; this lifecycle visibility standard cannot be satisfied by restricted party screening and destination review alone—it requires due diligence that extends through distribution chains, cloud service relationships, and end-user infrastructure profiles to confirm that computational capacity is not being accessed by or redirected to restricted parties after the initial transaction is completed.
• Infrastructure capability verification as a new due diligence requirement that has no direct precedent in standard commercial export compliance — The guidance's expectation that exporters confirm whether data center customers have the infrastructure capacity consistent with their chip orders introduces a due diligence requirement with no standard commercial compliance analogue; exporters must develop methodologies for assessing whether a customer's claimed data center infrastructure is real, appropriately scaled to the order volume, and genuinely operated for the stated purpose—assessments that require technical engagement with customers that goes substantially beyond the documentation-based verification that standard export compliance processes provide.
• Distribution chain transparency requirements extending compliance obligations to intermediaries and resellers whose downstream customers may be the actual end-use risk — Advanced computing ICs sold through distributors, resellers, or cloud infrastructure providers reach their actual computational end-users through intermediary relationships that traditional export compliance frameworks were not designed to penetrate; compliance programs must establish what visibility into downstream distribution and end-use the exporter can and must obtain—including contractual transparency obligations, reseller compliance representations, and periodic downstream monitoring—rather than treating the sale to a distributor as the end of the compliance obligation.
• Cloud and IaaS customer due diligence requiring evaluation of access controls and geographic restriction practices that the cloud provider applies to its own customers — For exporters supplying chips to cloud infrastructure providers, the compliance question extends to how the cloud provider controls its own customers' access to the computational capacity those chips provide; cloud providers whose customers can access advanced AI computing infrastructure from restricted jurisdictions, or who do not implement geographic access restrictions consistent with export control requirements, present a diversion risk at the infrastructure layer that chip-level export screening cannot address without cloud-level due diligence.
• Compliance program documentation requirements expanding to capture lifecycle analysis methodology and conclusions rather than only transaction-point screening results — The expanded compliance standard the guidance establishes requires documentation that goes beyond recording screening results and license determinations to capturing the analytical methodology and conclusions of lifecycle end-use analysis; organizations whose compliance records document only transaction-point due diligence without capturing the reasoning behind lifecycle risk assessments cannot demonstrate to BIS that they applied the standard the guidance establishes, regardless of whether the underlying analysis was conducted.

The guidance's non-exhaustive red flag list is an analytical starting point rather than a compliance checklist—and converting it into operational compliance behavior requires program design that develops pattern recognition across transaction populations rather than mechanically evaluating individual indicators in isolation:

• Transaction pattern analysis across order history rather than red flag evaluation limited to individual transaction characteristics — Many of the red flags the guidance identifies are most meaningful when evaluated against a transaction pattern rather than in isolation; a first-time buyer ordering a modest volume of advanced ICs presents a different risk profile than the same buyer placing that order as part of an escalating order pattern inconsistent with their stated business scale; compliance programs must maintain transaction history data that enables pattern analysis across the customer relationship rather than evaluating each transaction independently against the guidance's red flag indicators.
• Customer business profile plausibility assessment requiring technical judgment about whether the chips ordered align with the customer's actual computational requirements — The guidance's red flag of customers with no clear business justification for high-performance chips requires compliance reviewers to assess whether the customer's business activities would actually require the computational capabilities of the chips being ordered; this plausibility assessment requires technical understanding of what AI, HPC, and data center applications actually demand in terms of chip performance—knowledge that compliance personnel without semiconductor or AI technical background may not possess and that technical function input must provide.
• Online presence and corporate history verification as baseline due diligence steps that should be systematically documented rather than informally assessed — The guidance's identification of minimal online presence and inconsistent multilingual websites as red flags implies a verification obligation that compliance programs must standardize; baseline verification of customer online presence, corporate registration history, industry presence, and the coherence of their commercial identity across available information sources should be a documented step in the customer onboarding and order review process rather than an informal judgment call that individual compliance reviewers apply inconsistently.
• Freight forwarder and intermediary analysis specifically addressing whether their involvement in the transaction is commercially explained — The guidance's identification of unusual freight forwarder and reseller involvement as a red flag requires that compliance programs evaluate not just who the intermediaries are but why they are in the transaction; a freight forwarder with no documented expertise in advanced semiconductor logistics, or a reseller with no apparent customer base for high-performance computing applications, presents an intermediary red flag whose resolution requires commercial logic analysis rather than simply confirming the intermediary is not on a restricted party list.
• Holistic risk scoring frameworks that aggregate multiple indicators into a composite risk assessment rather than evaluating each red flag as an independent pass/fail criterion — BIS's explicit statement that no single red flag is determinative points toward a risk aggregation approach in which compliance decisions are based on the combined weight of multiple indicators rather than the presence or absence of any single factor; compliance programs that establish risk scoring frameworks—weighting individual indicators and generating composite risk assessments that determine due diligence depth and escalation requirements—operationalize the holistic review standard more effectively than those that treat the red flag list as a sequential checklist.

The guidance's due diligence expectations go substantially beyond standard commercial KYC practices—requiring technical and infrastructural verification that most compliance programs were not designed to conduct and that must be operationalized without creating commercial friction that drives customers to less compliant competitors:

• Corporate history and incorporation date verification as a systematic new customer onboarding requirement rather than a discretionary red flag response — The guidance's recommendation to verify incorporation dates and corporate history reflects BIS's awareness that front companies established specifically for restricted chip procurement are frequently new entities with limited verifiable commercial history; systematic verification of incorporation date relative to order size and sophistication, and confirmation of corporate history through registry sources rather than customer-provided documentation alone, should be standard new customer onboarding steps for advanced IC transactions rather than enhanced measures reserved for transactions that have already raised concerns.
• Beneficial ownership investigation for customers whose corporate structure includes holding companies, nominee arrangements, or jurisdictional complexity that obscures the actual controlling party — The guidance's reference to reviewing ownership structures for links to high-risk jurisdictions implies a beneficial ownership investigation requirement that goes beyond identifying the presenting legal entity to understanding who actually controls the customer and whether that controlling party presents restricted jurisdiction or prohibited end-user risk; beneficial ownership investigation for new customers in sensitive product categories should be a documented onboarding step with defined methodology rather than an ad hoc response to obvious opacity.
• Technical capability assessment confirming that the customer's infrastructure can actually deploy the chips they are ordering in the manner they describe — The guidance's expectation that exporters assess whether customer business activity aligns with chip usage, and whether data centers can confirm infrastructure capacity for advanced chips, implies a technical verification obligation that requires engagement beyond document review; for significant advanced IC orders, compliance programs should establish a methodology for confirming the customer's technical infrastructure through data center verification, capacity confirmation, or technical reference checks that demonstrate the customer's claimed deployment environment is real and appropriately scaled.
• IaaS customer access control verification requiring specific assessment of how cloud providers restrict advanced computing access by geography and end-user identity — For advanced IC exporters supplying cloud infrastructure providers, the guidance's IaaS-specific due diligence expectations require evaluation of the cloud provider's own customer access control practices; this verification must address specifically whether the IaaS provider implements geographic restrictions that prevent customers in restricted jurisdictions from accessing the computational capacity provided by the chips, and whether the provider's identity verification practices for its own customers are sufficient to detect restricted party access attempts.
• Due diligence documentation standards that capture methodology, information sources, and conclusions rather than only screening outcomes — Enhanced due diligence for high-risk customers must be documented with sufficient specificity that the methodology and reasoning behind the compliance conclusion can be demonstrated to BIS if the transaction is later scrutinized; documentation that records only that due diligence was conducted without capturing what information was reviewed, what conclusions were drawn from it, and why those conclusions supported proceeding provides no evidentiary defense of the compliance process that the guidance expects exporters to apply.

The guidance's extension of catch-all control analysis to AI training environments represents one of its most significant compliance implications—expanding export control scrutiny into computational workflows that many organizations have not previously treated as within the EAR's scope:

• Catch-all control knowledge standard applying to AI training applications whose outputs could support restricted military or WMD-related end uses regardless of the training workload's stated civilian purpose — EAR catch-all controls apply when an exporter knows or has reason to know that items will be used in connection with restricted military applications or WMD development; the guidance extends this standard to AI training workloads by making clear that chips used to train AI models may trigger catch-all scrutiny if the resulting model capabilities could support prohibited end uses—a standard that applies based on the potential application of training outputs rather than the stated purpose of the training workload itself.
• AI workload repurposability analysis as a new compliance due diligence requirement for cloud and data center customers whose computational use cases may not be fully disclosed — The guidance's identification of AI workload repurposing risk—where chips used for apparently civilian AI training could be redirected to military modeling, weapons simulation, or other sensitive applications—requires compliance programs to evaluate not just the customer's stated AI application but whether the computational infrastructure and model architecture being developed has characteristics that make it readily adaptable to restricted end uses; this repurposability analysis requires AI technical knowledge that compliance functions must either develop internally or access through technical function partnerships.
• Compute cluster geographic access analysis identifying whether advanced IC-powered infrastructure is accessible from restricted jurisdictions regardless of where the physical infrastructure is located — The guidance's concern about compute clusters being accessed from restricted jurisdictions reflects the cloud computing reality that physical infrastructure location and computational access location are decoupled; a data center physically located in a permissible jurisdiction can provide computational access to users in restricted jurisdictions if geographic access controls are inadequate; compliance programs for advanced IC exporters supplying cloud infrastructure must evaluate access control practices rather than treating physical infrastructure location as determinative of end-use geography.
• Cloud customer identity masking risk requiring due diligence on how IaaS providers verify the identity and location of their own customers accessing advanced AI computing resources — The guidance's reference to cloud customers masking end-use intentions identifies a specific diversion scenario in which restricted end-users access advanced computing infrastructure through cloud accounts established under false or obscured identities; compliance programs must address this risk by evaluating IaaS providers' customer identity verification practices—including KYC procedures, payment method verification, and geographic access logging—rather than treating the cloud provider's existence as a complete barrier between the chip exporter and the ultimate computational end-user.
• Compliance program documentation extending to catch-all control analysis conclusions for AI-related transactions where standard ECCN licensing analysis does not identify a triggering control — For advanced IC transactions where standard classification and licensing analysis concludes that no specific export license is required, compliance programs must additionally document the catch-all control analysis conducted for AI-related end-use scenarios; the absence of a specific ECCN licensing trigger does not eliminate the catch-all analysis obligation, and compliance records that document only standard licensing conclusions without addressing catch-all applicability leave a documentation gap that BIS's expanded expectations make consequential.

The guidance's KYC expectations go beyond commercial due diligence best practice to impose a legal standard whose violation carries enforcement consequences—and the explicit warning against self-blinding behavior makes the adequacy of KYC investigation a direct determinant of liability exposure:

• Affirmative investigation obligation converting red flag presence from a concern-raising event into a compliance-required investigation trigger — BIS's warning against self-blinding behavior makes explicit that the presence of red flags creates an affirmative obligation to investigate rather than a discretionary prompt to seek additional information; exporters who document red flag observations without conducting proportionate investigation, or who structure their compliance processes to minimize the information they receive about suspicious transactions, are treated as having constructive knowledge of the diversion risk regardless of whether they took active steps to confirm it—closing the willful ignorance defense that self-blinding behavior is designed to create.
• EAR notification obligation requiring exporters to inform customers that transactions are subject to export control restrictions before the transaction is completed — The guidance's expectation that exporters inform customers that exports are subject to EAR imposes a customer communication obligation that is distinct from and in addition to the exporter's own compliance review; this notification serves both a compliance education function and an evidentiary function—establishing that the customer was informed of export control restrictions before the transaction, which is relevant to subsequent enforcement proceedings if the customer misrepresents end-use information.
• Transaction refusal obligation applying when knowledge or reason to know of diversion risk exists regardless of the transaction's commercial value — The guidance's explicit statement that companies should refuse transactions when knowledge suggests diversion risk establishes a compliance-required outcome for transactions where KYC investigation has not resolved red flags satisfactorily; compliance programs must establish that the authority to refuse transactions—without exception for commercial relationship value, deal size, or customer relationship duration—is organizationally real and that compliance personnel are empowered to exercise it without requiring senior commercial override.
• KYC documentation standards requiring that investigation methodology, information sources, conclusions, and decision rationale are captured regardless of whether the transaction proceeds — KYC documentation must be maintained not only for transactions that are declined but for transactions that proceed following red flag investigation; the documentation must capture what red flags were identified, what investigation was conducted, what information was obtained, and why the compliance conclusion reached was that the transaction could proceed—creating an evidentiary record that demonstrates KYC was genuine rather than formulaic and that the decision to proceed was based on analyzed information rather than uninvestigated assumption.
• Escalation framework design ensuring that high-risk KYC conclusions reach compliance and legal review with sufficient lead time to conduct meaningful analysis before transaction deadlines — KYC programs that identify high-risk transactions but route escalations through processes that cannot deliver compliance and legal review within the transaction's commercial timeline create pressure to proceed before review is complete; escalation frameworks must define the transaction hold periods that apply when KYC concerns are escalated, establish the authority levels required to clear escalated transactions, and ensure that commercial timelines are extended rather than that compliance review is compressed when KYC concerns require meaningful investigation.

The guidance's scope across semiconductor manufacturers, cloud providers, and logistics companies reflects BIS's recognition that advanced IC diversion requires compliance intervention at multiple points in the supply and distribution chain—and the program changes it implies differ meaningfully across these industry sectors:

• Semiconductor manufacturers and exporters requiring classification and licensing program enhancements that address performance threshold monitoring, catch-all control analysis, and lifecycle end-use documentation as integrated compliance requirements — For chip manufacturers and exporters, the guidance's primary compliance implications are in classification currency monitoring—ensuring that chip specifications are continuously evaluated against evolving BIS performance thresholds—and in end-use due diligence depth that extends beyond transaction-point screening to lifecycle infrastructure analysis; compliance program investment priorities for this sector should focus on technical monitoring capabilities, customer infrastructure verification methodologies, and catch-all control analysis documentation standards that reflect the guidance's expanded expectations.
• Cloud and IaaS providers requiring KYC program enhancements that address downstream customer access controls as a compliance obligation rather than solely a commercial service design choice — For cloud infrastructure providers, the guidance's most significant implication is that customer access control practices—including geographic restrictions, identity verification, and end-use monitoring—are export compliance obligations rather than only commercial service design choices; compliance investment for IaaS providers should prioritize the integration of export compliance requirements into customer onboarding, access provisioning, and ongoing account monitoring processes in ways that enable detection and restriction of restricted jurisdiction access to advanced computing resources.
• Logistics companies and freight forwarders requiring enhanced screening for advanced IC shipments that evaluates their own role in transactions as a potential red flag indicator — The guidance's identification of unusual freight forwarder involvement as a transaction red flag creates a specific compliance obligation for logistics companies to evaluate whether their involvement in advanced IC transactions is commercially explainable—and to decline transactions where they cannot confirm that the shipment chain has a coherent commercial logic consistent with permissible end use; logistics compliance programs for advanced semiconductor shipments should include shipper due diligence, routing logic review, and transaction refusal authority that reflects the guidance's expectations.
• Cross-sector compliance program coordination among semiconductor exporters, cloud providers, and logistics companies whose combined due diligence can address diversion risks that no single sector can fully mitigate independently — The diversion scenarios BIS addresses in the guidance exploit gaps between the compliance programs of different supply chain participants; semiconductor exporters who sell to cloud providers, cloud providers who sell computational access to downstream customers, and logistics companies who move chips between these parties each have visibility into different portions of the diversion risk picture; industry-level compliance coordination—including information sharing about suspicious transaction patterns and coordinated due diligence standards—can address the inter-sector gaps that individual company compliance programs cannot close.
• Compliance program audit and gap assessment against the guidance's specific expectations as an immediate priority for organizations whose existing programs were designed against prior BIS standards — Organizations whose advanced IC compliance programs were designed before the May 2025 guidance was issued should conduct a structured gap assessment that evaluates their current program against the guidance's specific expectations—including lifecycle end-use analysis, infrastructure capability verification, catch-all control documentation, and KYC anti-self-blinding requirements; gap assessment findings should drive a prioritized compliance investment plan that addresses the most significant departures from the guidance's expectations before BIS enforcement actions test program adequacy in the advanced computing IC space.