A model knows everything except your business.

Here is the strange thing about the models available in 2026. The one you are evaluating has read more about your industry than anyone who works for you. It can explain the mechanics of your contracts, the seasonality of your revenue, and the failure modes of your supply chain. It has no idea that your company exists.

It does not know your customers, your accounts, your inventory, your open matters, or what happened on Tuesday. It has never seen a single one of your records. Ask it about your business and it will give you a fluent, confident, generic answer about businesses like yours.

The data foundation is the layer that closes that gap. It is the difference between a system that knows about your industry and a system that knows about you. Everything else in an AI build sits on top of it, and inherits whatever quality it has.

What a data foundation actually is

It is worth saying what it is not, because the phrase sounds heavier than the thing.

It is not a migration. Nothing has to move off the systems you already run. It is not a warehouse project, and it is not eighteen months of plumbing before you see anything work.

A data foundation is the set of connections that let a system see what it needs to see, at the moment it needs to see it, with a record of what it saw. That is the whole definition. Sometimes a connection is read access to a shared inbox. Sometimes it is a nightly financial export, a public records feed, or a database you have run for a decade.

“The layer is not a thing you buy. It is a thing that accumulates while the work happens.”

The important part is that it grows. The first version connects the two or three sources one workflow actually needs. The tenth version connects far more, because each build reveals the next thing the system should be able to see.

The four things a business actually has

Almost every source you would connect falls into one of four kinds, and each behaves differently once a system can read it.

Records. Rows in a system somewhere: customers, invoices, properties, matters, orders, tickets. Structured, queryable, and usually the easiest thing to connect. This is what makes an answer traceable, because a record has an identity you can point at.

Documents. Contracts, statements, reports, correspondence, scans. Enormously valuable and enormously messy. The work here is turning a folder of files into something a system can search by meaning rather than by filename.

Events. Things that happened and when: an email arriving, a payment clearing, a status changing, a threshold being crossed. Events are what let a system act on its own schedule instead of waiting to be asked, and they are the most commonly skipped of the four.

Rules. The knowledge that has never been written down anywhere. Which client gets called before the report goes out. What counts as a real exception. Why that account is coded the way it is. This is the hardest one to capture and the one that separates a system that is technically correct from one your team trusts.

Most companies assume the first two are the whole job. The systems that end up genuinely useful are the ones that got the third and fourth as well.

Handling it safely, which is most of the work

Connecting a system to your business is the moment the security conversation stops being theoretical. It deserves more attention than it usually gets, and the good news is that the answers are concrete rather than philosophical.

There are five questions worth asking about any AI system before it touches a real record.

What can it read, and what can it write? These are completely different levels of risk and should never be granted together by default. A system that can read your entire accounting history and write nothing is a research tool. A system that can write is an operator, and it needs a much narrower grant.

Who is it acting as? A well built system inherits the permissions of the person it is working for, rather than holding its own master key. If an analyst cannot see a record, the system should not be able to surface it to them. Access rules that already exist in your business should be the same rules the AI obeys.

Where does the data go? Ask directly whether anything you send is retained, and whether it is used to train a model. Ask it about every vendor in the chain, not just the one whose logo is on the proposal. The answers should be in writing and they should be specific.

What is the record of what happened? Every read and every write should leave a row: who, what, when, against which record, under whose authority. An audit trail is not a compliance checkbox here. It is the only way to answer the question that always eventually gets asked, which is why did it do that.

What happens when it is wrong? Not if. A system handling real volume will be wrong sometimes, and the design question is whether being wrong is visible, reversible and logged. A quiet mistake is much more expensive than a loud one.

None of these require a new security posture. They are the controls you already apply to a new employee with database access, written down and enforced by the system instead of by memory.

Why it decides everything above it

Here is the part that is easy to miss when you are comparing AI products.

Two companies can buy the identical model, the identical tooling and the identical interface, and get results that are not remotely comparable. The model is the same. The context underneath it is not.

An AI system reading a complete, current, well connected picture of your business gives specific answers about your accounts, cites the record it used, and notices things nobody asked it about. The same system reading a partial, stale, disconnected picture gives fluent, plausible, generic answers. It sounds equally confident in both cases, which is exactly why the foundation matters more than it appears to.

“Every capability you buy is multiplied by the quality of what sits underneath it. Multiplied, including by zero.”

This is also why the data foundation is worth building even before you know every system you will eventually want. The connections are the durable part. Models change every few months and interfaces get replaced, but a governed, audited, well understood picture of your own business keeps its value regardless of what you build on it next.

Where to start

Narrow. Pick one workflow that a real person does regularly and that matters when it goes wrong. Connect only the sources that workflow genuinely needs, with read access first and a full audit trail from day one.

Then let the second workflow tell you what to connect next. That sequence produces something working early, and it means every connection you add has a reason attached to it rather than a hope.

The companies that get real value out of AI are almost never the ones that bought the best model. They are the ones whose systems can actually see the business.

— James