Your team just shipped a killer new feature using an LLM. Maybe it's a RAG pipeline that summarizes internal documents or a chatbot that helps users navigate your product. The demos were great, the metrics are up, and everyone is happy. But there's a question you probably haven't asked: do you know exactly where that model's intelligence came from?
It’s a question that’s becoming a lot less academic. As The Verge reported, The Seattle Times and Newsday are the latest in a line of publishers suing OpenAI and Microsoft for copyright infringement. They claim their journalism was used to train models without permission, and that those models sometimes reproduce their work verbatim. This isn't just a headache for OpenAI's lawyers. It's a flashing red warning light for every developer, architect, and CTO building on top of these platforms. You've introduced a new dependency into your stack, and it has a data supply chain you can't see and a legal risk you can't quantify.
The New Supply Chain: From npm to LLMs
We've been through this before, just in a different form. A decade ago, we were all just grabbing packages from npm or PyPI without a second thought. Then left-pad broke the internet, and we slowly realized that our applications were built on a complex, rickety tower of dependencies maintained by strangers.
So we developed tools and best practices. We started using lockfiles, vulnerability scanners like Snyk and Dependabot, and software bill of materials (SBOMs). We learned to treat dependencies not as free magic, but as a liability to be managed. We accepted that when you npm install, you are inheriting the code, the licenses, and the security posture of that package.
An LLM is the ultimate black-box dependency. It’s left-pad on an unimaginable scale. You get an API key and a client library, but you have zero visibility into what's inside. You don't know the training data, you don't know the architectural decisions, and you certainly don't have a package-lock.json for its knowledge base. You are making a bet on the provider's legal and ethical hygiene, and the recent flood of lawsuits suggests that's a very risky bet.
This isn't just about OpenAI. Every major foundational model, from Google's Gemini to Anthropic's Claude, has faced questions about its training data. When you build a core feature of your product on one of these models, you are not just using a tool. You are making that model's data supply chain a part of your data supply chain. And right now, that chain is looking pretty fragile.
Quantifying an Unquantifiable Risk
As an engineering leader, your job is to manage risk. You think about infrastructure uptime, security vulnerabilities, and bus factors on your team. You can model those risks. You can buy insurance. You can implement redundant systems. How do you model the risk that the core dependency for your flagship AI feature gets fundamentally altered by a court order?
This isn't a hypothetical. Let's walk through the second-order effects that a successful lawsuit against a model provider could have on your product.
Sudden Model Degradation
The most likely outcome of these lawsuits isn't that OpenAI goes out of business. It's that they are forced to identify and remove all infringing content from their training data and retrain the models. What does that do to model performance? Nobody knows. Maybe nothing. Or maybe GPT-5's ability to reason about current events or write in a journalistic style plummets overnight.
If your product relies on that specific capability, your feature just got measurably worse, and you had no say in it. The p95 latency of your API calls is easy to monitor. The subtle degradation of semantic quality is not. You'll just get a slow trickle of user complaints that the "AI isn't as good as it used to be."
Pass-Through Liability
This is the one that should keep your company's general counsel up at night. The lawsuits claim that models often reproduce copyrighted text verbatim. If a user of your product gets a response that is a direct, unattributed quote from The New York Times, who is liable? The model provider? Or you, for surfacing it in your application?
Your terms of service probably say you're not responsible, and OpenAI's terms probably say the same. But that's a fun argument to have in court. At a minimum, you'll be dealing with takedown notices and angry publishers. This isn't just about text. Imagine building a feature on an image generation model that was trained on a dataset of copyrighted photography. The legal minefield is enormous.
Defensive Engineering for an Unstable World
So what can we actually do about it? We can't audit OpenAI's S3 buckets. But we can build our own systems with the assumption that our AI dependencies are unstable and potentially dangerous. It's not about abandoning AI. It's about practicing safe engineering.
Isolate Your AI Dependencies
First, do not let a specific AI provider's SDK bleed into your core application logic. Your business logic shouldn't know or care if it's talking to OpenAI, Anthropic, or a self-hosted Llama 3 instance. The best way to do this is with a classic adapter pattern.
Create your own internal interface for LLM services. It might look something like this in pseudocode:
// In your application's core interfaces
export interface LanguageModelProvider {
generateCompletion(prompt: string, options: ModelOptions): Promise<string>;
generateStreamingCompletion(prompt: string, options: ModelOptions): AsyncGenerator<string>;
}
Then, you implement a concrete class for each provider you might want to use.
// In infrastructure/llm/openai_provider.ts
import OpenAI from 'openai';
import { LanguageModelProvider } from '@/core/interfaces';
export class OpenAIProvider implements LanguageModelProvider {
private client: OpenAI;
constructor(apiKey: string) {
this.client = new OpenAI({ apiKey });
}
async generateCompletion(prompt: string, options: ModelOptions): Promise<string> {
const response = await this.client.chat.completions.create({
model: 'gpt-4o',
messages: [{ role: 'user', content: prompt }],
// ...map your options to the OpenAI API
});
return response.choices[0].message.content || '';
}
// ... implement streaming method
}
Your application code now depends on LanguageModelProvider, not OpenAI. If you need to switch providers because of a legal ruling, a pricing change, or a massive performance degradation, you only have to change one file, not fifty.
Log and Audit AI Outputs
If your application shows raw LLM output to users, you need to be logging every single generation. Store the prompt you sent, the full response you received, and a timestamp. Why? Because when you get a complaint that your AI plagiarized something, your first line of defense is proving that the content came from your upstream provider, not from your own code. It won't absolve you of responsibility, but it's critical for diagnostics and for any conversation with your provider's support team.
This also allows you to run offline analysis. You can build simple checks to flag outputs that contain long, verbatim strings, which are often a sign of regurgitated training data. It's not a perfect solution, but it's better than flying blind.
Consider Smaller, Controllable Models
The biggest, most capable models have the most legally dubious training data because they scraped the entire internet. But you might not need to scrape the entire internet. For many business tasks (classifying support tickets, summarizing meeting notes, generating SQL queries from a known schema), a smaller, open-source model can perform just as well or better when fine-tuned on your specific data.
Fine-tuning a model like Mistral 7B or Llama 3 8B on your own, legally-clean data gives you a massive advantage: control. You own the data supply chain. You're not exposed to whatever The New York Times decides to do next. The upfront cost is higher, both in terms of engineering time and compute, but you are effectively buying insurance against the instability of the general-purpose model ecosystem.
What This Means for Your Team
The OpenAI lawsuits are a signal. The era of treating foundation models as free, stable, and risk-free infrastructure is over. It’s time to have a pragmatic conversation about the risks you've imported into your stack. Here are a few things to discuss in your next architecture review or planning session:
- Map your dependencies. Which specific features in your product call out to an LLM? Which models are they using? What happens if that model's API is deprecated or its performance changes?
- Review your contracts. What does your AI provider's Terms of Service say about indemnification for copyright claims? (I'll give you a hint: it probably puts all the responsibility on you).
- Isolate your AI client code. Look at your codebase. Is
import OpenAI from 'openai'sprinkled through dozens of files? If so, create a ticket to refactor it behind an adapter. It's a boring task, but it will save you one day. - Evaluate the build vs. buy trade-off. For your most critical AI-powered feature, what would it take to replace the general-purpose model with a smaller, fine-tuned one you control? The answer might be less expensive than you think, especially when you factor in the unquantified risk of the third-party provider.
This isn't about being an AI skeptic. It's about being a realist. We're software engineers. Our job is to build resilient systems on top of unreliable components. For the last 18 months, we've largely given LLMs a pass on the reliability front. Now, the legal system is reminding us that no dependency is ever truly free.
Building something in this space? AgileStack helps teams ship enterprise-grade software without the consulting-firm overhead. Book a 30-minute call and tell us what you're working on.