The question isn’t whether copyright lawsuits involving AI will reshape enterprise liability. They already are. What’s shifting now is that enterprises are building large-scale AI systems without clarity on what they’re legally exposed to—and that gap is widening, not closing.

Three major litigation tracks are running simultaneously. The first involves generative AI companies and the datasets they used to train large language models. Several high-profile cases allege that training on copyrighted material without permission or compensation violates copyright law. The second track involves enterprise use of foundation models—if you’re using foundation models to generate content that replaces work that would have been licensed, you may be moving risk. The third, less visible but arguably most dangerous for enterprises, involves the training data you’re collecting and using internally.

Most enterprises aren’t thinking about the third category. They should be.

The Data You Control, Not the Models

When a foundation model company faces copyright liability, they shoulder it. They built the model; they made the decisions about what data to include. But when you build an internal AI system—a customer service chatbot trained on your internal documentation, a code-generation tool trained on your private repositories, a content classifier trained on labeled examples—you’re making the same decisions. And you’re controlling the dataset.

If your training data includes copyrighted material, you’ve made a choice. If it includes customer personal data that you’ve used for model training without explicit consent or legal basis, you’ve created another liability. If it includes third-party data that you licensed for one purpose but then used for model training without renegotiating the terms, you’ve created a third.

This isn’t hypothetical. Enterprises are building on top of open-source code that has licensing restrictions. They’re fine-tuning models on customer data without revisiting their data governance policies. They’re using datasets that were collected before large-scale AI was a consideration, and the original privacy or usage terms never contemplated model training.

Where Most Organizations Have a Blind Spot

The typical audit process asks: “Are we using a licensed model or an open-source model?” If it’s licensed, they assume the vendor handled copyright. If it’s open-source, they check the license (GPL, MIT, Apache, etc.) and call it secure. What they miss is the training data itself.

You may have a fully licensed foundation model deployment, but if you’re feeding it proprietary customer data that you’re then using to fine-tune another model, or if you’re processing it through the API and storing the results in a way that violates your customer’s original consent, the licensing status of the base model becomes secondary.

Similarly, open-source models have become attractive precisely because they seem to sidestep the copyright questions that plague foundation models. But if you’re training an open-source model on a dataset you don’t have clean rights to, the licensing of the model is not your primary risk.

What’s Changing Now

Up until recently, enterprises could move reasonably fast because copyright enforcement was theoretically the problem of the model builders, not the model users. That assumption is breaking down. Courts are beginning to articulate theories of liability that flow backward—from end users toward the data sources and the choices made about what data to use.

The litigation landscape is also clarifying that “we didn’t know it was copyrighted” is not a defense if you had reason to know. A Fortune 500 company has more reason to know than a startup. If you’re building internal AI systems, courts will likely assume you had the capacity to verify your data sources.

There’s also a subtle but important shift in how regulators and advocates are framing the issue. It’s moving from “did you train on copyrighted material” to “did you have a process for knowing what you were training on.” Process failures are easier to prosecute than content mistakes.

What You Need to Start Doing

First, document the provenance of every dataset used for training. Not in aggregate (“we used publicly available data”), but specifically: where did this data come from, who originally created it, what license or terms govern its use, was it collected with consent for this purpose, and did we verify any of that.

Second, revisit your vendor contracts for any data you’re licensing or procuring. The boilerplate language you signed three years ago probably doesn’t address foundation model training. It should. If you’re licensing customer data or third-party data, the terms should explicitly cover (or explicitly prohibit) use for AI model training.

Third, audit your internal datasets. If you’re using customer service transcripts, product documentation, customer feedback, code repositories, or any other internal source as training data, verify the original consent and licensing basis. If it doesn’t exist, you have a choice to make: get the consent retroactively, limit what you do with the model, or don’t use that data.

Fourth, establish a practice where anyone proposing a new AI system documents the data sources upfront, not as an afterthought. Make the data liability question as visible as the technical question.

The Cost of Waiting

The earliest enterprises to address this will have a practical advantage: they’ll know what they can and can’t do. More importantly, they’ll have a documented process that demonstrates reasonable care. That matters in litigation. The enterprises that move slowly will face a much harder conversation when they discover, in the middle of a deployment, that their training data has clean-title problems.

The copyright landscape around AI is clarifying month by month. The visibility enterprises have into their own data governance is not. That gap is where the liability sits.