Whose Data Does Artificial Intelligence Compound On?

Part Three of MissionViewpoint's series: AI doesn't create organizational intelligence. It amplifies it.

Imagine an ABA provider spends two years using AI to improve utilization.

At the end of those two years, what does the organization possess that it didn't possess when it started?

It has more data.

But that's not the interesting part.

The organization knows something it didn't know before.

In the last article, I described the mechanism that can make that happen: an organizational learning loop connecting operating questions, data, AI analysis, human judgment, operational change, and outcomes.

Run that loop once and you have an experiment.

Run it repeatedly and something can begin to accumulate.

Which raises the question I've been working toward throughout this series:

Where does that knowledge live?

Getting Your Data Out May Not Be Enough

ABA providers have spent years debating data ownership.

Can I access my data? Can I export it? Does my vendor provide an API? If I change platforms, can I take my records with me?

Those remain important questions.

But AI may make them incomplete.

Suppose our provider eventually changes the technology supporting that utilization process.

Its client records move. Its authorizations move. Its schedules move. Its claims history moves.

The data migration is successful.

But what happens to everything the organization learned while using the old system - the operator corrections and the reasoning behind them, the exceptions it discovered, the payor-specific distinctions and refined business rules, the interventions it tried and the history connecting each one to what happened next?

Some of that may exist as ordinary data and move easily.

Some may exist in configuration, workflow logic, instructions, or other forms that are technically retrievable but difficult to reproduce elsewhere.

And some may never have been represented as a portable artifact at all.

Yet those things may contain some of the most valuable operating knowledge the organization created.

That suggests a distinction between data portability and intelligence portability.

Data portability asks:

Can I take my records with me?

Intelligence portability asks:

Can I take what my organization has learned with me?

What Actually Compounds?

I used the word accumulate at the end of the last article deliberately.

It would be easy to describe every AI interaction as another contribution to some growing body of intelligence.

That's not what I mean.

A commercial foundation model doesn't necessarily retrain itself every time an operator rejects a recommendation. A thousand conversations with an AI tool don't automatically make the thousand-and-first better. Saving every prompt and response doesn't turn a provider into a learning organization.

The important learning doesn't have to happen inside the model.

It happens around it.

Each time the loop from the last article runs, the next analysis begins with something the previous one didn't have - a variable that was missing, an exception now made explicit, a business rule that has been refined, an intervention whose outcome is finally known.

That's what compounds.

At first, the experienced operator knows far more than the system.

After ten cycles, recurring exceptions begin to emerge.

After a hundred, the organization may understand which combinations of authorization status, staffing, geography, family availability, and payor behavior tend to precede underutilization - and different combinations may begin triggering different interventions.

After a thousand, it holds more context, exceptions, intervention history, and outcome evidence than any individual employee reasonably could.

The model itself may be exactly the same.

The organization isn't.

That is the distinction I care about.

Every operating decision has the potential to make the next decision better.

Potential is doing a lot of work in that sentence.

Most operating decisions don't.

A scheduler solves an unusual staffing problem. An authorization specialist learns something about a payor. A regional leader discovers why a case that looks problematic on a dashboard really isn't.

The problem gets solved.

Then the reasoning disappears.

The next person encounters the same situation and reconstructs the answer.

The opportunity isn't simply to capture more information. It's to make useful experience reusable.

When that happens, previously invisible context becomes explicit. Repeated distinctions become operating rules. Workflows adapt. Outcomes provide evidence about which interventions work. Judgment that once existed only in one person's head becomes available beyond that person.

That's organizational learning.

AI can make much more of it possible to capture, test, retrieve, and apply.

Whose Intelligence Should Compound?

There's an obvious temptation to take the argument from here in a very different direction:

Providers need to own all of this.

I don't think that's right.

Some intelligence may be considerably more valuable when it compounds at the vendor level.

Consider a revenue-cycle technology company operating across hundreds of healthcare providers.

Subject to the appropriate contractual, privacy, security, and data-use arrangements, that company may be able to recognize patterns in claim behavior that no individual provider could discover from its own experience.

That's not a problem to be solved.

It's one of the reasons to buy their software and services.

A technology company operating across hundreds of customers can potentially learn from a broader range of conditions, edge cases, and outcomes than any individual provider will ever encounter. If that learning improves the product, every customer can benefit from scale it could never create independently.

So the strategic question isn't whether intelligence should compound with the provider or the vendor.

It should probably do both.

The more useful question is:

Which intelligence becomes more valuable at market scale, and which becomes more valuable because it is specific to the organization?

Generalized understanding of claim behavior may benefit enormously from vendor scale.

But how one ABA provider staffs difficult cases, responds to cancellations, allocates BCBA capacity, handles regional differences, interprets family availability, or chooses among competing operational priorities may reflect that provider's particular operating model.

Those aren't necessarily secrets.

They are context.

And context is exactly what determines whether a generalized capability can make a useful decision inside a particular organization.

The boundary won't always be obvious.

Providers should want their vendors to get smarter.

But they should also understand which parts of their own operating capability are becoming inseparable from the technology through which that learning occurs.

The Next Switching Cost

That matters for a reason I've written about recently.

ABA providers already face substantial costs when they change practice management platforms. The records have to move, integrations have to be rebuilt, workflows have to change, and employees have to learn a new system - all while continuing to deliver care.

Now imagine that AI-enabled applications increasingly become places where operating judgment accumulates too.

Return to our utilization example.

For two years, operators taught the process that a narrow-availability family in one region isn't a staffing failure but an exception to leave alone. That a case flagged as high-risk because of geography is actually fine because an experienced technician is transferring into the area. That one payor's remaining-units pattern warrants concern while another payor's identical-looking pattern is routine.

Hundreds of these distinctions accumulate, and the at-risk list gets quietly, steadily better.

Then the provider changes platforms.

The client records arrive intact - authorizations, schedules, claims history, all of it.

Does the learning?

The at-risk list becomes noisy again. The new system re-flags the narrow-availability families. It doesn't know the payor distinctions the organization spent two years making explicit. An authorization specialist recognizes the false positives immediately - because she remembers teaching the old system to stop producing them. She just has nothing to teach the new one with.

The records moved.

The judgment didn't.

That isn't necessarily because a vendor owns that judgment or refuses to provide it.

The problem may be much less dramatic.

Organizational knowledge may have become embedded in configurations, workflow states, feedback histories, instructions, and rules that were never designed to travel between systems.

Historically, switching costs have included migrating data, rebuilding integrations, recreating workflows, and retraining employees.

AI may introduce another one:

the cost of relearning.

And that's why intelligence portability matters.

A provider can successfully migrate its records and still find itself reconstructing distinctions it already spent years learning.

I don't think intelligence portability is a major procurement criterion for most ABA providers today.

But if AI becomes as embedded in operating workflows as I expect it will, it probably should become one.

Preserve What Would Be Expensive to Relearn

The answer isn't to own every component.

It's definitely not for every ABA provider to build its own AI platform.

Providers can buy or rent foundation models, cloud infrastructure, integration technology, workflow software, development services, and specialized applications. In many cases they should.

The model itself may ultimately be one of the more replaceable components.

What deserves more attention is the organizational knowledge that would be difficult to reconstruct if one of those components changed.

That might include normalized information connecting multiple applications, business rules and decision logic, organizational definitions, meaningful operator overrides, learned exceptions, workflow logic, and the history connecting interventions to outcomes.

It probably isn't every prompt ever written.

It isn't every AI response.

And it isn't every judgment an employee makes.

Trying to preserve everything would produce another enormous repository of information that nobody knows how to use.

A simpler test is:

If this technology disappeared tomorrow, what would we have to relearn?

That's ultimately a more useful way to think about intelligence portability than asking whether every artifact can technically be exported.

The things that would be expensive to relearn are the things worth making durable.

The Question Behind the Question

I called this article Whose Data Does the Intelligence Compound On?

I now think that's only half the question.

Whose data matters.

A vendor may improve a generalized capability across hundreds of customers. A provider may improve a capability using its own operating history. Both can create substantial value.

But the deeper question is:

Where does the resulting learning accumulate?

That's what connects the three articles in this series.

Part One asked what the intelligence can see.

An AI capability bounded by an application can become extremely good at that application's job. But organizational questions often require context that crosses application boundaries.

Part Two asked how the organization learns.

The answer wasn't a more sophisticated model. It was a loop connecting operating questions, information, AI analysis, human judgment, operational change, and outcomes.

This article asks what happens after that loop runs hundreds or thousands of times.

What does the organization retain?

Because if the answer is nothing, the loop isn't really compounding. It's producing a series of better-informed decisions.

Useful, certainly.

But not the same thing as building organizational intelligence.

Models will continue to improve. AI capabilities will spread through nearly every software category ABA providers use. The technology will become more powerful and, in many cases, more accessible.

That means simply having access to AI will become less distinctive.

The strategic asset isn't simply the model.

It isn't simply the data.

It's the organization's ability to turn operating experience into reusable knowledge—and carry that knowledge forward as employees, applications, vendors, and models change.

And it becomes more urgent, not less, as AI stops recommending and starts acting. An agent that acts on organizational judgment nobody captured is just a faster way to repeat the mistakes the organization already made. (more on that topic later!)

Part One started with a distinction between using AI and building organizational AI capability.

This is what I mean by building it.

Not building the model.

Building an organization that doesn't have to keep relearning what it already knows.

That's where organizational intelligence compounds.