Why LLMs Fail at Trade Compliance

An export manager at a mid-sized electronics manufacturer asks ChatGPT whether a new Vietnamese distributor appears on the OFAC SDN list. The answer comes back clean. Two months later, that distributor gets added to the list, and the manufacturer has shipped three orders in the interim without a single alert. This is the gap that no LLM closes: trade compliance software watches continuously. A language model only answers when asked. Large language models fail at trade compliance not because their individual answers are wrong, but because the job requires a process that runs between questions, and that is something conversational AI cannot do.

The Difference Between a Question and a Process

Compliance is a continuous process, not a question you ask when you remember. An LLM produces an answer on demand. That distinction matters more than any accuracy benchmark, and it's what OFAC's enforcement framework is built around: 15 CFR Part 730–774 defines export compliance as an ongoing obligation, not a transaction-by-transaction check.

Here's what it looks like in practice. An export operations team at a machinery distributor screens a new customer before onboarding: one partner, one moment in time, clean result. But the partner database doesn't freeze after that check. Existing customers get acquired, restructured, or individually designated. The team isn't asking about them anymore because the relationship is already active. When OFAC drops a Friday afternoon designation on an entity that's been a customer for fourteen months, no one in the company knows unless something is watching.

Process means continuous observation with documented results. It means a record showing which dataset version was active when a check was run, so a regulator can reconstruct what was knowable on a specific date. With OFAC publishing SDN updates on a rolling basis with no fixed schedule, any day of the week. An alert that fires on status change is not optional infrastructure. It's the only way to know Tuesday happened before Thursday ships.

We talk to export managers who built their early compliance workflows around periodic manual lookups, sometimes weekly, sometimes before major shipments. Most describe the same problem: the gap between checks is exactly where exposure accumulates. The Q1 2025 OFAC enforcement against a U.S. technology exporter ($2.8 million, repeated shipments to a newly-designated party) followed exactly that pattern. Lenzo is built specifically for that gap: continuous monitoring that runs between your checks, not instead of them. No LLM resolves that gap, because no LLM runs between conversations.

What LLMs Actually Can't Do in Trade Compliance

There are seven reasons no LLM qualifies as export compliance software. None of them are about accuracy. They're structural. The OFAC SDN, the BIS Entity List, the EU Consolidated List: all live databases that update daily. A conversational AI tool has no persistent connection to any of them.

No memory of your partners. Every conversation with an LLM starts from zero. There's no record of prior screenings, no partner history, no flagged changes from previous sessions. You're not building a compliance file. You're asking a one-off question with no connection to anything you asked before.

Version binding doesn't exist. When an LLM returns a result, there's no record of which SDN dataset it consulted, whether the data was current as of that session, or what version of the EU Consolidated List was active. You cannot reproduce the result. You cannot prove what was knowable on the date of a shipment. For any OFAC or BIS audit, that's a disqualifying gap.

No monitoring — and this is the one that gets companies fined. The OFAC SDN list changes more than 2,200 times per year. The BIS Entity List sees over 350 modifications annually. An LLM only answers when asked, so if a partner's status changes on Tuesday and your next check is Thursday, you've shipped into a two-day window of undetected exposure with no record it happened.

Scale breaks the model entirely. Running names against the SDN one at a time works for a single partner. It breaks at thirty partners. At two hundred SKUs across multiple counterparties per quarter, a conversational interface is not an operating model.

No audit trail. An OFAC audit requires documentation: the date of each check, which dataset was consulted, and evidence the process ran on a consistent schedule. An LLM chat session produces none of this. No timestamp. No source reference. That's not a logging problem. It's an architectural one.

The source data problem doesn't go away. OFAC distributes the SDN in XML format. The EU Consolidated List varies across sanction packages. The BIS Entity List updates asynchronously from the other major lists. An LLM doesn't solve the underlying fragmentation. It may have been trained on these lists, but training data is not a live feed, and a training snapshot from several months ago is already stale on a list that updates daily.

No connection to live regulatory data feeds. LLMs (even those with web search) do not maintain a persistent, structured connection to official sanctions data sources: OFAC SDN XML feed, BIS Entity List, EU Official Journal. Web search retrieves a page, not a versioned dataset. The model has no record of what changed since the last time you asked, and no way to tell you what changed specifically for your partners. Teams running names against the SDN need current, structured data, not a search result.

Each limitation individually creates exposure. Together, they add up to something specific: a tool that can't watch, can't remember, and can't prove. That's the gap an OFAC auditor exploits.

When LLMs Are Actually Useful in Trade Compliance

LLMs are genuinely useful in trade compliance research, just not in the operational process. That's not a hedge. It's a specific boundary, and getting it wrong in either direction costs time: dismissing AI entirely means slow classification work, and using it for monitoring means gaps you won't discover until a regulator does.

For initial ECCN classification of a novel product, running a description through a capable model and comparing the output to EAR Part 774 (15 CFR Part 774) gets you to a starting classification faster than reading the CCL cold. The output still requires human review and formal determination, but the model reduces the time from hours to minutes.

Parsing Federal Register notices is another genuine use case. Regulatory amendments can run to sixty-plus pages of dense legal text. A model that summarizes the operative changes and flags affected product categories is a useful research accelerator, not a replacement for legal review.

Answering one-off questions about EAR or ITAR rules works as a first-pass research tool, provided the answer gets verified against the current CFR text before it drives a decision. We've seen teams use this effectively when chasing down UBO chains on a potential distributor: the model pulls together the ownership structure logic quickly, and a compliance officer validates the conclusion against the actual CFR. Regulatory research and classification assistance fit well. Document summarization fits. These are appropriate applications.

What doesn't work is using any of that for the operational layer. We've watched teams try this: setting up scheduled prompts to ask an LLM about their partner list every Monday morning. It failed for a reason that should have been obvious in advance: the LLM had no memory of last week's result, no record of what changed. No way to tell them whether Tuesday's designation had been caught. The check that runs every day, the alert that fires when something changes, the audit record that survives a regulator's examination. An LLM can't do any of that regardless of how well it handles the research tasks. That's the operational layer, and it's what Lenzo is built for.

What a Compliance System Actually Requires

The gap between what an LLM provides and what trade compliance software provides isn't about answer quality. Under 15 CFR Part 730.7, exporters must be able to demonstrate they used current, accurate data at the time of each transaction, and reconstruct that demonstration on demand. An LLM session produces nothing that supports that reconstruction. Lenzo is designed around exactly that requirement: every screening run is timestamped, dataset-versioned, and exportable as a PDF record. The difference is infrastructure: partner history, dataset versions, monitoring, audit-ready output.

Partner history matters because relationships are ongoing. A compliance system maintains a record of every check run against every counterparty: when it ran, what it returned. That history, with the partner's current status attached, is what makes a compliance file defensible when OFAC or BIS examines it.

Dataset versioning is a legal requirement, not a convenience. Exporters are expected to demonstrate they used current screening data at the time of each transaction, which means the record needs to show which dataset version was active on which date. An LLM session cannot be reconstructed after the fact.

Monitoring and alerts address the frequency problem directly. With OFAC publishing more than 2,200 SDN changes per year and BIS adding over 350 Entity List modifications annually, a system that only checks when asked will miss changes. Continuous compliance monitoring means the alert fires within hours of a designation, not the next time someone remembers to run a name.

Scale matters for teams processing more than a handful of partners per week. A compliance operation running several hundred records per quarter needs batch processing and sortable results, with a way to review exceptions that doesn't involve opening a separate conversation for each one.

PDF export with source references is what turns a compliance check into a compliance record: the document that gets attached to the shipment file, reviewed during an internal audit, or submitted in response to a government inquiry.

The table isn't a technology comparison. It's a description of what a compliance program needs to be defensible, and which category of tool provides it.

The Right Way to Use AI in Trade Compliance

Wrong application of AI in export compliance doesn't produce bad answers. It produces missing records. That's a harder problem, because missing records don't show up until OFAC asks for them.

Research tasks belong in an LLM. Classification questions, regulatory summaries, Federal Register digests: these are tasks where a capable model saves real hours, and where the stakes of a wrong first-pass answer are manageable because a human reviews the output before it drives a decision.

Operational tasks belong in compliance software: screening runs, partner monitoring, dataset-versioned records, audit-ready exports. The part of compliance that runs every day without someone remembering to start a conversation.

The line is this: research tools generate information for human review. Compliance systems generate documentation for regulatory examination.

Teams that blur that line don't fail because they lack knowledge about compliance requirements. They fail because their documentation of what they checked, and against which dataset, doesn't hold up when a regulator asks for the records. Lenzo handles the operational layer so the research utility of an LLM and the process infrastructure of a compliance system work together, rather than teams discovering the difference at audit time.

FAQ

Why can't an LLM replace dedicated sanctions screening software?

An LLM answers a question at the moment you ask it. Sanctions screening requires a system that monitors continuously, stores a versioned record of every check, and fires an alert when a partner's status changes between sessions. These are not features an LLM lacks. They are architectural properties it cannot have. A language model has no memory between conversations, no connection to live list data, and no mechanism to act without being prompted.

What does "no audit trail" actually mean in a compliance context?

When OFAC or BIS audits an export compliance program, they ask for documentation: which dataset was screened, on which date, who reviewed the result. An LLM chat session produces none of this. There is no timestamp, no record of which version of the SDN or BIS Entity List was current at the time of the query, and no exportable log. Under 15 CFR Part 730.7, the inability to reconstruct a screening record is not a minor gap. It is the gap that turns a missed designation into a willfulness finding.

How is trade compliance software different from just asking an LLM about a partner?

Dedicated trade compliance software maintains a persistent partner database, runs each record against versioned, live-updated sanctions lists, and logs every check with a timestamp and source reference. When a partner's status changes, OFAC publishes over 2,200 SDN updates per year and the system fires an alert without being asked. An LLM check is a one-off query against training data of unknown recency. The difference is not accuracy. It is continuity and proof.

Can I use an LLM for ECCN classification and then run sanctions checks separately?

Yes, and this is roughly the right division of labor. LLMs handle classification research well: comparing a product description against EAR Part 774 (15 CFR Part 774), surfacing relevant CCL categories, summarizing Federal Register amendments. That work is research-oriented and benefits from language model capabilities. Sanctions screening and denied party monitoring require a dedicated compliance system with live list feeds, version binding, and an audit trail. Those are not research tasks. Using both in their appropriate roles is more practical than forcing either to cover the other's function.

What happens operationally when a company relies on LLM checks instead of a compliance system?

The failure mode is not a wrong answer. It's a missing record. An LLM check produces no timestamped log, no dataset version, no exportable documentation. If a partner is designated between the last LLM query and the next shipment, no alert fires. When OFAC investigates, the company cannot demonstrate what was checked, when, or against which list version. The Q1 2025 enforcement case against a U.S. technology exporter ($2.8 million) followed exactly this pattern: repeated shipments after a designation, no monitoring system in place to catch the change.

The practical split is simple: use an LLM to understand what the rules say, use a compliance system to prove you followed them. The first part is optional. The second is what OFAC asks for.