1Problem one: you cannot get the corpus

Every build plan assumes the patent data is available. It is available in the sense that you can download something. It is not available in the sense that you can index the world’s patent literature in full text and search it.

What the free and public sources actually contain

The EPO’s DOCDB is the worldwide backbone and it states its limits plainly: it contains “bibliographic data, abstracts, citations and the DOCDB simple patent family, but no full text or images.”² Full text from the EPO comes in two narrower sets: EP full-text data covering EPO publications since 1978, and national full-text data whose character-coded extracts “cover France, Spain, Switzerland and the United Kingdom.”^{3, 4} Four countries.

The Google Patents Public Data set on BigQuery is the other common starting point. Its own documentation describes it as a “worldwide bibliographic and US full-text dataset of patent publications,” provided by IFI CLAIMS Patent Services in collaboration with Google under a Creative Commons Attribution 4.0 licence.⁵ Worldwide bibliographic, US full text. The maintaining GitHub repository was archived read-only on 18 April 2026, which is not proof the tables stopped updating but is a governance signal worth checking before you build on it.⁶

PATENTSCOPE closes the door explicitly. Its FAQ states “bulk download is prohibited. The usage of automatic robot is all prohibited,” and its terms state that “more than 10 search related actions per minute from a single IP address can be considered excessive,” prohibit bulk acquisition, downloading, storing, reformatting and redistribution, and state that the data cannot be sold or sublicensed without WIPO’s permission.^{7, 8}

US data is the genuine bright spot. The USPTO’s Open Data Portal is free and consolidates what used to sit in separate systems.⁹ Note one recent change if your plan involves PatentsView: it migrated into the Open Data Portal on 20 March 2026, and the USPTO stated that “some PatentsView functions, including search, APIs, visualizations, and support services, will pause temporarily.”¹⁰

2Problem two: retrieval is the hard part, and patents are the hard case

The instinct in a build project is that the LLM is the clever bit and retrieval is plumbing. The research points the other way.

A 2024 study of search and retrieval configurations for retrieval-augmented generation found that “gold document recall is a far bigger factor for QA performance than search recall,” and that “lowering search accuracy has minor implications for RAG performance.”¹¹ The practical reading is uncomfortable for a build plan: tuning your vector search matters far less than whether the right document is in your corpus and surfaces at all. Which returns you to problem one.

A second 2024 study found that “the level of recall required to match the performance of standalone LLMs varies significantly across models and datasets, from as low as 20% to as high as 100%,” and, more awkwardly, that “RAG systems with perfect retrieval recall still fail on a significant proportion of instances where standalone LLMs succeed.”¹² There is no recall threshold you can hit and declare the system finished.

Why patents specifically

Prior art is not a same-field lookup. The reference that kills a claim often comes from an adjacent technology. DAPFAM, a 2025 family-level benchmark built for exactly this question, ran 249 controlled experiments across BM25, dense transformer retrieval and rank fusion over 1,247 query families and 45,336 target families, and reported that “OUT-domain performance remains roughly five times lower than IN-domain across all configurations.” Asked which method closes the gap, the paper’s answer is “none.”¹³

Absolute numbers are sobering too. A multi-task evaluation of 22 embedding models over a 113,148-patent corpus and 46,069 citation-graph queries reported a best retrieval score of roughly nDCG@10 = 0.197, achieved by an 8B-parameter embedding model on title, abstract and claims.¹⁴ That is the state of the art for off-the-shelf embeddings on citation-based patent retrieval, and it is a long way from a finished product.

None of this says patent retrieval is impossible. It says the gap between a demo and a system you would put a filing decision on is measured in years of domain-specific retrieval work, not in a sprint. A widely cited engineering paper on RAG failure modes concluded that validation is only really feasible during operational use and that robustness develops iteratively rather than being established up front.¹⁵

3Problem three: what happens when it goes wrong is now on the record

This used to be a theoretical risk. It is now a documented one, in patent matters specifically.

Stanford researchers measured hallucination in general-purpose LLMs answering verifiable questions about real court cases, across more than 800,000 queries. The finding: “LLMs hallucinate at least 58% of the time,” ranging from 58% for one frontier model to 88% for another, and they “struggle to predict their own hallucinations.”¹⁶ The same group then tested purpose-built commercial legal research tools with retrieval augmentation and found that while hallucinations are reduced relative to general-purpose chatbots, the leading tools “each hallucinate between 17% and 33% of the time.”¹⁷

Read those two numbers together, because they are the core of the build-versus-buy argument. Adding retrieval to a general model roughly halves the hallucination rate in a legal domain, which is a real improvement and still nowhere near a rate you would accept in a filing decision. Purpose-built systems built by companies with large engineering teams and licensed corpora land at 17% to 33%. A team building its first RAG pipeline on a partial corpus should expect to start well behind that.

The consequences are now priced

The reference case is Mata v. Avianca, where the court sanctioned the lawyers $5,000 after they submitted fabricated authorities, finding that they “abandoned their responsibilities when they submitted non-existent judicial opinions with fake quotes and citations created by the artificial intelligence tool ChatGPT.”¹⁸

What matters for IP teams is that this reached patent litigation. In Lexos Media IP, LLC v. Overstock.com, a patent infringement case in the District of Kansas, the court issued Rule 11 sanctions on 2 February 2026 against five lawyers after a brief contained nonexistent quotations and citations. The order records that counsel used ChatGPT “as a shortcut to find 10th [C]ircuit and Federal Circuit case law consistent with the facts of the case” and “admits that he did not check these citations, quotations, or statements of authority for accuracy.” Fines totalled $12,000, with one lawyer’s pro hac vice admission revoked and a self-report to state disciplinary authorities ordered.¹⁹

This is not an isolated pair of cases. A public database tracking court decisions that address AI-generated hallucinations recorded 1,922 cases as of 18 August 2026.²⁰

4Problem four: the duties you inherit the moment you build

An internal tool does not create a softer standard. It moves the entire compliance burden onto your team, and there is published guidance describing exactly what that burden is.

The USPTO’s April 2024 guidance on AI-based tools in practice before the Office is direct: “simply relying on the accuracy of an AI tool is not a reasonable inquiry,” and a party must “perform an inquiry reasonable under the circumstances confirming all facts presented in the paper have or are likely to have evidentiary support and confirming the accuracy of all citations to case law and other references.”²¹ Under 37 CFR 11.18(b), the person who signs certifies that statements are true to their own knowledge and that contentions have evidentiary support after a reasonable inquiry.²² A fabricated reference is not existing law and does not acquire evidentiary support because an internal system produced it.

The same notice warns that AI use for prior art searches or drafting “may result in the inadvertent disclosure of client-sensitive or confidential information to third parties,” that “AI systems may retain the information that is entered by users,” and that tools running on servers outside the United States raise export control and national security questions.²¹ Building in-house does not remove that analysis, because your build almost certainly calls a third-party model API.

For lawyers, ABA Formal Opinion 512 adds an explicit requirement: “a client’s informed consent is required prior to inputting information relating to the representation into such a GAI tool,” and reliance on output “without an appropriate degree of independent verification or review… could violate the duty to provide competent representation.”²³ WIPO frames the commercial version of the same risk: organisations using generative AI tools “may inadvertently give away trade secrets or waive confidentiality in commercially sensitive information if such information is used for training or prompting AI tools.”²⁴

The practical consequence for a build project is a set of deliverables nobody scopes at the start: a model provider contract with zero retention, a data residency and export control assessment, an audit log tying every output to its sources, an evaluation set with examiner-cited ground truth, and a documented review procedure. That work is not optional and it is not small.

5Problem five: the running costs nobody models

Token pricing is the visible cost and the least significant one. The costs that decide the business case are the ones a demo never incurs.

Indexing. Embedding a corpus is a recurring cost, not a one-off, because you pay it again every time you change embedding model or re-chunk. Published embedding prices sit around $0.02 to $0.12 per million tokens depending on model tier.²⁵ To make that concrete: embedding only the abstract and claims of 100 million documents at roughly 1,000 tokens each is 100 billion tokens, which at $0.06 per million is about $6,000 for a single pass. That figure is arithmetic from published unit prices on stated assumptions, not a quoted price, and the point is not the number but that it repeats.

Querying the raw data. If the corpus lives in BigQuery, on-demand querying is charged by bytes scanned, at $6.25 per tebibyte after the first tebibyte per month free.²⁶ Exploratory work over a multi-hundred-gigabyte patent table adds up quickly during development, which is when you scan the most.

Evaluation. You cannot improve what you do not measure, and patent search evaluation requires a labelled set. The only credible ground truth is examiner citations, which means building and maintaining an evaluation corpus and re-running it on every change. This is usually the single largest hidden cost and the first thing dropped under deadline pressure.

The odds. A RAND report published in August 2024 opens by noting that “by some estimates, more than 80 percent of AI projects fail,” twice the rate of failure for information technology projects that do not involve AI.²⁷ Read that carefully before you use it. RAND attributes the number to an outside survey rather than measuring it, and RAND’s own contribution is a root-cause analysis built on 65 semi-structured interviews with industry practitioners and academics conducted between August and December 2023. It is a well-sourced framing from a named institution rather than a measured census, and it should be cited that way. It is still the most defensible version of a claim that circulates widely in far less careful forms.

6When building genuinely is the right answer

There are real cases for building, and they share a shape: the thing you build is close to your own process and far from the retrieval problem.

• Workflow and integration. Routing disclosures from your invention management system, applying your own review gates, pushing outputs into your docketing system. Nobody else knows your process and no vendor will build it for you.
• Internal knowledge. Your own filings, your own office action history, your own technical reports and lab notebooks. This corpus is small, you own it outright, and no vendor has it. Retrieval over a few tens of thousands of internal documents is a tractable engineering problem.
• Scoring and triage rules. How your organisation decides which disclosures proceed is a policy question specific to your business model. Encoding it is a good build project.
• Evaluation harnesses. Building your own evaluation set, drawn from your own examiner citations, is valuable whether you build or buy, and it is the only way to hold any vendor to account.

What these have in common is that none of them requires you to reconstruct a worldwide patent corpus or to solve cross-domain retrieval.

The middle path, and why most teams end up there

The version of this that works is to buy the layer that is expensive to build and build the layer that is expensive to buy. In practice that means treating patent retrieval and analysis as an API rather than as a product you open in a browser.

The Patsnap Open Platform publishes 32 MCP servers described as connecting “Patsnap’s domain-specific AI agents to LLM platforms such as Claude or custom models using the Model Context Protocol.” They cover patent research including novelty and both invention and design freedom to operate, a cross-domain TRIZ case library, a workspace reader and 3GPP TDoc tools. Setup is an API key plus a generated connection link in Cursor, Claude Desktop or any MCP-compatible client, and the Starter tier is free with 10,000 credits valid for 90 days.^{1, 28}

Your engineer still gets to build. They build the orchestration, the triage logic, the integrations and the evaluation harness, on top of a corpus of 200M+ patents across 174 jurisdictions with SOC 2, ISO 27001, GDPR and CCPA compliance and no AI training on user data, and with search quality that is published and measurable rather than assumed.^{29, 30} What they do not build is a licensed worldwide corpus, a cross-domain patent retrieval stack, and a compliance regime, which is the part of the project that would otherwise consume the year.