Every Company Is Becoming a Technology Company. Legal Has to Catch Up.

There was a time when calling a company a technology company actually narrowed the field. You probably meant software. Maybe hardware. Something built by engineers, sold as technology, and understood by everyone involved to belong in a category of its own.

That distinction is becoming increasingly meaningless.

Retailers run on software. Manufacturers depend on connected systems, automation and data. Consumer brands rely on e-commerce platforms, advertising technology, customer-data tools and an entire ecosystem of SaaS vendors most of their customers will never see. Healthcare organizations operate through layers of digital platforms and integrations. Sports leagues are no longer simply sports organizations; they are media companies, data companies and increasingly technology companies too.

And nearly every business now has someone somewhere experimenting with artificial intelligence.

Sometimes leadership knows about it. Sometimes Legal knows about it. Sometimes nobody realizes the company is “using AI” until a vendor quietly adds an AI feature to software the business has been using for three years.

That is usually a fun afternoon.

The point is not that every company should suddenly start describing itself as a technology company. The point is much simpler: technology is no longer sitting beside the business. It is how the business operates.

That changes the legal work.

A technology agreement is rarely just an IT contract anymore. One SaaS platform may touch customer information, confidential business data, intellectual property, employees, regulated information, payment flows, marketing activity or a core business process. The contract that arrives in Legal looking like a routine software agreement may raise questions about privacy, cybersecurity, artificial intelligence, data rights, intellectual property, business continuity, subcontractors, international transfers, regulatory obligations and whether the vendor can use everything flowing through its platform to “improve its services.”

Lawyers may put those issues into different buckets. The business does not experience them that way.

You cannot meaningfully negotiate a data provision without knowing what data is actually moving. You cannot evaluate an AI provision without understanding what the product is doing. You cannot assess a security requirement without knowing what information the system will hold. And you cannot allocate risk intelligently without understanding which party actually controls it.

This is where technology contracting can go sideways.

We negotiate the clause because the clause has a familiar name: Data Processing. Artificial Intelligence. Information Security. Intellectual Property. Limitation of Liability.

But the name of the clause is not the analysis.

I increasingly start technology deals with questions that sound less legal than operational. What is the company buying? Why does it need it? What information goes into the product? What comes out? Who has access to it? What can the vendor do with it? What has Sales promised? What does the customer think it is buying? What happens if the system is unavailable? What happens if the output is wrong?

Once you understand what is actually happening, the paper gets considerably easier to evaluate.

Artificial intelligence is making this even more obvious because AI is not arriving neatly packaged as a standalone category of technology. It is appearing inside customer-service platforms, productivity tools, marketing systems, analytics products, HR software, development environments, contract tools, research products and software that nobody originally purchased because it contained AI at all.

A company can therefore have substantial AI use without ever making a centralized decision to “adopt AI.”

That makes the old question — Does our company use AI? — less useful by the day.

The better questions are: Where is AI entering the business? What is it doing there? What information is moving through it? And what decisions, if any, are people making based on what comes out?

That may sound basic. It is also where a surprising amount of governance loses the plot.

Emerging technology creates uncertainty, and lawyers understandably respond to uncertainty by creating structure. Policies. Approval processes. Committees. Inventories. Risk classifications. Forms. More forms.

Sometimes all of that is appropriate.

But if the first move is to build a forty-page AI policy before anyone understands how employees are actually using the technology, the company may end up with an immaculate description of a world that does not exist.

People will use tools that make their jobs easier. Business teams will adopt technology because it makes something faster, cheaper or better. SaaS platforms will add functionality whether the customer has developed a philosophical position on artificial intelligence or not.

If governance becomes so cumbersome that people simply route around it, the company has not eliminated the risk. It has moved the risk somewhere Legal cannot see it.

Good governance should make responsible adoption easier.

That usually begins with reality rather than policy. What tools are people actually using? What data enters them? What does the vendor have the right to do with that information? Can it train or improve anything with customer data? Who owns the inputs? Who owns the outputs? Does the output matter enough that a human should review it? Are external claims about the technology consistent with how it actually works?

None of that requires the lawyer to become a machine-learning engineer.

Everyone involved will be happier if I do not attempt to debug the API.

But there is a meaningful difference between technical expertise and technical fluency. Modern commercial counsel does not need to build the product. Legal does need to understand it well enough to recognize when the contract, the data flow, the customer promise and the actual product are telling four different stories.

Privacy presents the same problem from another angle.

Companies have spent years building increasingly sophisticated privacy programs, appropriately so. But technology has made data relationships more varied, not less. The instinct to attach a data processing addendum to every agreement involving information may feel protective, but the name of the document does not determine the relationship.

Sometimes a vendor is processing personal information on behalf of a customer, and a DPA is exactly what the relationship requires. Sometimes the vendor is independently collecting information to provide its own service. Sometimes the company is licensing a data set. Sometimes the information has been de-identified. Sometimes almost no personal information moves at all.

The document should follow the data.

What information is involved? Who collected it? On whose behalf? For what purpose? What does each party need the right to do with it? What law actually applies to that activity?

Start there and the contract becomes more useful.

Start with the template and everyone may spend two weeks negotiating a beautifully drafted description of a relationship that does not actually exist.

The same principle applies to commercial risk.

A lawyer can demand every conceivable protection in a SaaS agreement and still produce a bad result for the client. An unlimited liability provision may make perfect sense in one relationship and be completely irrational in another. A customer may appropriately require heightened security commitments from a platform holding highly sensitive information and have very little reason to impose that same framework on a vendor that never touches the data.

A party may also have enough leverage to demand a right it has absolutely no business reason to exercise.

The useful question is rarely just whether Legal can ask for something.

It is whether the business needs it.

That distinction matters because legal risk is not the only risk a company manages. Delay is risk. Lost revenue is risk. A failed launch is risk. An operational commitment the business cannot actually perform is risk. Spending $20,000 negotiating a low-value contract is risk. Creating a legal process so disconnected from operations that the business starts avoiding it is also risk.

The job is not to pretend those risks disappear because one of them happens to have a legal label.

The job is to calibrate them.

Sometimes the right answer is no. Sometimes there is a risk the company should not accept, a data use it should not permit, a contractual obligation it cannot responsibly make or a product claim that needs to change.

Sometimes the answer is yes.

And very often the useful answer is some version of: yes, but here is the risk, here is what matters, and here is how I think we manage it.

That is where knowing the business matters.

There is a version of legal practice where the lawyer receives a document, marks it up, returns it and considers the assignment complete. That model still works for some things. It works less well when the technology decision is also a business decision.

If Legal is going to give useful advice, someone has to understand why the company is buying the tool, how it will be used, what information will move through it, what the commercial leverage actually looks like and what happens if the deal does not close.

That is not business advice instead of legal advice.

It is what makes the legal advice useful.

A perfectly drafted provision that prevents the company from using the product it purchased is not a successful outcome.

Neither is waving through material risk because everyone wants to launch by Friday.

The work is knowing the difference.

And that is ultimately why I think the disappearing distinction between “technology companies” and everyone else matters for Legal.

Technology moves quickly enough that the law will frequently be incomplete, unsettled or several steps behind the product. Regulators will be catching up. Legislatures will be debating definitions. Courts will eventually draw lines that did not exist when the business had to make the decision.

Meanwhile, the company still has customers.

It still has employees.

It still signs contracts.

It still buys software.

It still launches products.

It still needs an answer.

Knowing the law is the beginning of that work. The harder part is knowing what to do next.

Understand the law. Understand the technology well enough to ask the right questions. Understand the business well enough to know what actually matters. Understand the risk well enough to distinguish something material from something merely unfamiliar.

Then make a decision.

Every company may not call itself a technology company.

Increasingly, every company is operating like one.

Legal has to catch up to the company the business has already become.