When AI Stops Looking Like Software

I keep coming back to a simple question with AI products:

What is the customer actually buying?

For years, the answer with software was usually pretty straightforward. The customer bought access. A login. A dashboard. A workflow tool. A place for people to store information, move information around, and hopefully work a little faster.

That model is not gone. It is not going away tomorrow.

But a lot of the AI market is clearly moving beyond that. The more interesting products are not just better interfaces or smarter dashboards. They are starting to sit inside the customer's workflow. They read, summarize, recommend, draft, classify, escalate, and in some cases take action.

At that point, the product stops feeling like software access.

It starts feeling like delegated work.

That shift matters. Not just for investors trying to decide what deserves a software multiple. It matters for the contracts.

The contract should match the job

A traditional SaaS agreement asks familiar questions.

Who gets access? What are the fees? What is the term? What support is included? What happens if the service goes down? Who owns the customer data? What is the liability cap?

Those questions still matter.

They just do not go far enough if the product is being trusted to do something closer to work.

If an AI product is reviewing customer communications, generating recommendations, processing sensitive data, drafting operational content, assisting with decisions, or connecting into other systems, the contract has to be more honest about the role the product is playing.

Not every AI tool needs a heavy agreement. That is not the point.

The point is that the agreement should not pretend the product is just sitting there waiting for someone to log in.

A product that stores data is one thing.

A product that acts on data is another.

"It's just a pilot" can hide a lot

This is where pilots get interesting.

A pilot usually begins with good intentions. The customer is curious. The startup wants to prove value. Nobody wants to turn a limited test into a giant negotiation.

That instinct is right.

But a pilot can still decide the shape of the relationship.

What data is being used? Who can access the system? Can the vendor use feedback to improve the product? Can either side talk publicly about the pilot? What happens at the end? Does the customer get preferred pricing if the pilot works? Can the tool be turned off cleanly?

These are not theoretical questions. They become very practical if the product starts working.

That is the funny thing about pilots. When they fail, everyone moves on. When they work, people suddenly care a lot about what the document said.

A good pilot agreement does not need to be a monster contract.

It just needs to answer the questions that become awkward if the test goes well.

Data is not just data anymore

Founders often focus on ownership of outputs.

That is understandable. If an AI product generates text, analysis, code, recommendations, or other content, people want to know who owns it.

But sometimes the more important issue is not the output.

It is what the vendor learns along the way.

A customer may be giving the vendor prompts, corrections, usage patterns, workflow signals, edge cases, performance feedback, and context about how the customer's business actually operates. That can be extremely valuable.

The vendor may reasonably want to use some of that information to improve the product. The customer may reasonably want to limit how its data and usage patterns are used.

Both positions can be fair.

What usually causes problems is silence.

If the vendor can use customer data, prompts, outputs, usage information, aggregated data, or derived insights to train, tune, improve, benchmark, or commercialize the product, the agreement should say that clearly.

Nobody wants to discover the real data bargain after the relationship has already become important.

Human oversight should mean something

A lot of AI products are sold with some version of "human in the loop."

That phrase can be useful. It can also be vague enough to become meaningless.

Who is the human? What are they reviewing? When do they review it? Can the AI act before approval? Are there permission levels? Can a customer reconstruct what happened if something goes wrong?

This matters because many companies are comfortable using AI to help prepare a decision, but not comfortable letting AI make the decision. They may be comfortable with a draft, but not with automatic delivery. They may be comfortable with a recommendation, but not with an unreviewed customer-facing action.

That distinction should show up somewhere.

In the product. In the implementation plan. In the contract.

Otherwise, everyone is relying on a shared understanding that may not actually be shared.

Liability caps should reflect the real failure mode

Most software agreements have liability caps. That is normal.

But AI changes the conversation because the most likely failure may not be simple downtime.

The product might produce a bad recommendation. It might misuse data. It might create a customer-facing error. It might trigger the wrong workflow. It might create a record that is hard to explain later.

That does not mean every AI customer should demand unlimited liability, and it does not mean every AI vendor should accept it. That is not how deals work.

It does mean both sides should be honest about the failure mode they are actually worried about.

If the product is business-critical, touches sensitive data, or affects external communications, the liability structure should not be written as if the only real problem is that the dashboard went offline for an afternoon.

The market is moving faster than the paperwork

The current AI funding environment has a way of making everything feel urgent.

New products are getting funded. Buyers are experimenting. Investors are trying to understand which categories are being replaced, which are being deepened, and which are just being renamed.

That pressure can be useful. It gets people moving.

It can also flatten important distinctions.

Not every AI company is the same. Not every product is replacing software. Not every agent is actually autonomous. Not every pilot is low-risk. Not every data use is harmless because the contract calls it aggregated.

The legal work is not to slow everything down.

The legal work is to describe the relationship accurately enough that the business can move without pretending the hard questions do not exist.

The practical point

I do not think the most useful question is whether AI "replaces SaaS."

That is too broad to help most companies.

The better question is smaller and more useful:

What role is this product playing in the customer's business?

If it is just software access, the old playbook may mostly work.

If it is becoming part of the customer's operating layer, the agreement needs to catch up. That means clearer pilot terms, better data language, real oversight mechanics, and a liability structure that reflects what could actually go wrong.

AI may change what software does.

It does not change the need to write down what the relationship is.