Introduction
Here’s the assumption baked into a lot of product roadmaps right now: a startup builds a feature on top of an OpenAI, Anthropic, or open-source LLM. They didn’t train the model. They didn’t write the transformer architecture underneath it. They just call an API and build a product on top. Surely the patent exposure belongs to the model provider, not the company calling the API?
That assumption is wrong more often than founders realise.
Patent risk in an AI product doesn’t stay neatly inside the foundational model layer. It moves through how you integrate the model, how you process its outputs, and what you build on top — and each of those layers can independently carry exposure regardless of which model sits underneath. This article covers how patent infringement risk actually flows through an AI product stack, and what an infringement search needs to look like for a product built on someone else’s AI model.
Where Patent Risk Actually Sits in an AI Product Stack
Think of an AI-powered product as three layers, each with its own patent exposure profile.
Layer 1: The Foundational Model — the LLM, diffusion model, or other AI system itself. Covered by the provider’s own patents, and potentially infringing on others’ patents — architecture-level innovations like specific attention mechanisms, training methods, or model compression techniques.
Layer 2: The Integration Layer — how your product calls the model, processes its outputs, and combines them with your own logic. This is where most teams assume there’s no patent exposure — and where a meaningful amount of exposure can actually exist.
Layer 3: The Application Layer — your specific product features built on top of the AI output. Often the most overlooked layer for patent risk, because teams are focused on the AI component and not the surrounding feature implementation.
Most teams assume risk sits entirely in layer 1 — and that it’s the model provider’s problem to manage, not theirs. In reality, layers 2 and 3 can independently infringe patents covering specific implementation methods, regardless of which foundational model is doing the underlying generation. A patented method for how you fine-tune, post-process, or combine model outputs with proprietary logic doesn’t disappear just because the model itself came from someone else.
The Architecture Risk: What Google’s Transformer Patents Mean for You
Google holds foundational patents related to the transformer architecture that underlies most modern large language models. For the major foundational model providers — OpenAI, Anthropic, Google itself, Meta — this is a known commercial dynamic. It’s often described as mutually assured destruction: all the major players likely infringe each other’s patents to some degree, and litigation rarely makes economic sense between them because of the retaliation risk.
For smaller companies building on top of these models via API, the practical risk from the architecture layer itself is lower — you’re not the one implementing the transformer mechanism, the provider is. But that risk isn’t zero, and it shifts depending on how you use the model. If your integration method goes beyond simply calling a black-box API and instead implements a specific patented technique — a particular fine-tuning approach, a specific attention optimisation, a distinctive method for chaining model calls — you may be implementing patented technology yourself, independent of what the model provider is doing underneath.
The distinction that matters: are you a consumer of the model’s output through a standard API call, or are you implementing your own technique on top of it? The first carries lower direct exposure. The second is where infringement search needs to focus.
Why API Indemnification Clauses Don’t Always Cover You
Most AI API providers include indemnification language in their terms of service — a promise to defend customers against certain infringement claims related to use of the API. Founders often treat this as a complete safety net. It isn’t.
The coverage is narrower than most people assume, in three specific ways:
- Coverage typically applies to claims arising from the model itself — not from how you’ve integrated or built upon it. If the infringement claim is about the foundational model’s architecture, the provider’s indemnification likely covers you. If it’s about your specific implementation choices, it likely doesn’t.
- Coverage often excludes claims related to fine-tuning or combination with proprietary methods. Once you’ve customised the model’s behaviour or combined it with your own technology in a way the provider didn’t anticipate, you’ve moved outside the indemnification’s typical scope.
- Indemnification doesn’t protect you from your own patent applications being challenged. If your product incorporates a method that turns out to overlap with someone else’s patent — unrelated to the AI model itself — the provider’s indemnification has nothing to do with that exposure.
Reading the specific indemnification language in your AI vendor’s terms of service — and understanding exactly where the coverage line sits relative to your actual implementation — is a practical first step that most product teams skip.
“Indemnification clauses are written to protect the vendor’s own model, not your specific implementation choices. The gap between what’s covered and what you’ve actually built is exactly where infringement exposure tends to live.”
What an Infringement Search for an AI-Integrated Product Actually Covers
Given how risk distributes across the stack, an infringement search for an AI-integrated product needs a different scope than a traditional product infringement search. Here’s what it should cover.
- Integration-layer technique patents. Patents covering the specific AI techniques your product implements at the integration layer — not just the foundational model architecture. This includes specific fine-tuning methods, prompt engineering techniques that go beyond simple prompting, and methods for chaining or orchestrating multiple model calls.
- Application-layer feature patents. Patents covering your product features that may exist independently of the AI component — a specific UI workflow, a particular use-case implementation, or a method for presenting AI-generated content to users. These patents may have nothing to do with AI at all, but still cover how your product functions.
- Vendor indemnification scope review. A structured comparison between the exposure identified in the search and what your AI vendor’s terms actually cover — so you know precisely where your own legal exposure begins.
- Ongoing monitoring given filing volume growth.
How Our Infringement Search Service Covers AI-Integrated Products
Our patent infringement search service covers the full AI product stack — foundational model architecture patents relevant to your specific implementation, integration-layer technique patents, and application-layer feature patents. For startups and product teams building on third-party AI models, we provide a structured risk assessment that separates genuine exposure from theoretical risk, rather than treating ‘it’s an AI feature’ as a single undifferentiated risk category.
Where relevant, we also review your AI vendor’s indemnification language against the specific gaps we identify — giving you a clear picture of where vendor protection ends and your own exposure begins. For companies actively building differentiated technology on top of generative AI, our broader analysis on the IP implications of generative AI covers the wider landscape of ownership, authorship, and infringement questions that AI-driven products now have to navigate.
Building a product on top of a third-party AI model? Our infringement search service maps the patent risk across your full AI stack — not just the foundational model. → Contact Us
Conclusion: The Takeaway
The assumption that patent risk belongs entirely to your AI model provider is the single most common blind spot in AI product development right now. Risk flows through the integration and application layers just as much as the foundational model layer — and indemnification clauses rarely cover the full distance.
Understanding where exposure actually sits — and what your vendor’s terms do and don’t cover — is the foundation of a defensible AI product. The companies that map this early are the ones that build with confidence. The ones that don’t are building on an assumption that may not hold up.
