> ## Content Index > Fetch the complete content index at: https://www.missionviewpoint.com/llms.txt > Use this file to discover other available public pages before exploring further. # Whose Data Does Artificial Intelligence Compound On? - URL: https://www.missionviewpoint.com/whose-data-does-the-intelligence-compound-on/ - Published: 2026-08-25T23:18:14.000Z - Updated: 2026-08-25T23:31:51.000Z - Author: Scott Dickson - Tags: Topic: AI & Automation, Topic: Enterprise Data, ABA Stack *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](https://www.missionviewpoint.com/youre-using-ai-thats-not-the-same-as-building-it/) 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](https://www.missionviewpoint.com/point-ai-at-your-operation-not-your-software/) 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.