Know Where You Stand

However the requestor frames it, “Would you give our AI access to your data?” is the start of a negotiation. Before you determine your position, try to clarify exactly what the other party wants.

A few likely scenarios:

• They want their in-house AI to give employees answers based on your expertise. Basically, they want to put your brains inside a robo-consultant they can access on demand.
• They want to use your knowledge to create or improve a product they intend to sell. Now your expertise is fuel for someone else’s AI solution, possibly one your own clients will buy instead of your services.
• They want to study your taxonomy, decision logic, evaluation sets, or workflows. In other words, they don’t just want to consume your knowledge, they want to reverse engineer how you developed that data and expertise in the first place.
• They aren’t quite sure yet and want to “explore possibilities together.” Whether they’re being sincere or sneaky, they don’t just want your knowledge, they want you to help them figure out how to apply it, but don’t want to commit to paying for it.

Then, after determining (or guessing at) the other party’s position, figure out your own. Assuming you actually own the data the other party is asking for (and aren’t prevented from sharing it by privacy regulations or agreements with third parties) there are a number of possible stances you could take.

• Perhaps you can work out some kind of license, providing access to your data and charging by the query or by the year. Whether or not this arrangement is viable depends on how they’re accessing your data (we’ll get to that) and whether your data set is something that requires ongoing maintenance and upkeep that only a domain expert firm can provide.
• Maybe you should build the AI system, yourself. This might be a big change, especially if your business previously involved billing by the hour for human advice or a flat subscription rate to access a traditional software app, database, or document / media library. But, depending on your field’s exposure to AI disruption, it might be the only way to remain relevant in your niche.
• Consider if there’s an opportunity to integrate, where you build part of the solution (the one where your expertise lives) and they build another (e.g., maybe they have an accounting app and your solution feeds it up-to-date tax code information for the user’s jurisdiction, with expert guidance, and they can charge their customers for your module as an add-on.)
• Be prepared to sell if it makes sense. There’s no shame in recognizing when it’s time to cash out. Douglas Fregin, one of the co-founders of the company behind the BlackBerry phone, sold his company stock for just over a billion in 2007, right after Apple debuted the iPhone, rendering BlackBerry obsolete. Companies trading on data or expertise that AI can eventually get elsewhere might be wise to sell while their market value is still high.

That said, choosing among those options requires a clear sense of your organization’s place in the AI “knowledge supply chain.”

Selling Your Wares

People talk about AI as if it were one monolithic thing when, in reality, it’s more like an automobile with parts sourced from a dozen different countries. Any serious enterprise AI system is at least six things stacked on top of each other, and the strategic question is which parts of the supply chain you intend to own.

For a “decision support” type system, there is:

The Knowledge Itself

Your research, case files, regulations, historical records, client data, proprietary benchmarks. But also how it’s organized: has it been curated, tagged, normalized, deduplicated, dated, and structured with a real taxonomy… or treated as one enormous digital junk drawer? Two firms can hold identical documents yet have wildly different “knowledge assets” if only one of them put in the effort to make their collection legible to a machine.

If you were to supply this to another party, it might take the form of a one-time transfer of files and database records, or an ongoing subscription if the data is time-sensitive and expires quickly. But whatever the structure, understand one thing before you sign: once your data has been used to train a model, there is no taking it back. You can terminate a license, but you can’t make a model unlearn what it absorbed, and “delete our files when the contract ends” means little if the patterns in those files now live inside someone else’s AI.

That’s a strong argument for arrangements where the other party queries your data (access you can meter, monitor, and revoke) over ones where they permanently train their models on it. And if you do agree to training, the contract should spell out which models the data can be used for, whether derivative models are covered, and what you’re owed if your data ends up powering a product that competes with you.

The Retrieval Layer

The mechanism that gets the right information in front of the AI at the right moment for the question or task in front of it. This could be as lazy as “search a PDF for any mention of “vacation policy'” or as sophisticated as “do a multi-hop graph traversal starting with the user’s city, then the nearest airport, then all flights to Tokyo with vegan dinner options.”

Crucially, this layer also decides what doesn’t apply. Suppose a physician is evaluating anticoagulants for a patient whose chart is tagged with diabetes, and the system surfaces a promising study on a blood thinner. Did that study include diabetic patients? If nobody has tagged it either way, then you’re playing dice with whether an AI model notices that omission- and a system that quietly treats an untagged study as generally applicable just made a dubious clinical judgment. Ideally, the retrieval mechanism would exclude the study, or flag it in a way that’s visible to both the AI model formulating the recommendation and the physician.

If you were to supply other parties with retrieval as a service, you might set up an endpoint to receive database queries with reasonable daily, monthly, and yearly limits, or even a vector database or MCP server (which serve up data and tools in a format AI models can easily parse and interact with.)

The Decision Architecture

The “thought process” the system should follow when generating output. Which variables it should account for, which questions it should answer, which exceptions override the rule, what triggers escalation to a human, and when the correct output is “I don’t know.” This is the layer most organizations overlook: they give an AI model a pile of factual data then say “refer to this when answering the user’s question” without any further guidance on how to evaluate the user’s request, conduct additional discovery, and formulate a well- considered answer.

In theory you could offer to implement your decision architecture on a client’s technology platform, as a service (and my own company has done this once or twice.) However, that would likely expose your intellectual property such that the client could reverse engineer it, so you would need to proceed with extreme caution.

The Orchestration and Application Layer

How the decision architecture manifests in software: how the interaction is broken into stages, how it transitions between those states, what information the system is fed at each stage, what it remembers between sessions, what buttons it can press when interfacing with other systems, and – just as importantly – what it’s prevented from doing.

While there is some overlap between configuration of the orchestration / application layer and your decision architecture, they are distinct. The orchestration / application layer is how you configure the platform (as well as the traditional software and hardware infrastructure it runs on.) The decision architecture is the process and outcomes you would try to recreate if you had to rebuild the whole thing on a different platform tomorrow.

Providing an orchestration layer as a product means becoming a full on software and infrastructure company. This plus the knowledge retrieval layer are the primary layers where my company operates (along with bigger companies like Palantir and DataBricks.)

The Model

The engine that performs the calculations to predict what comes next in the conversation, based on the input provided. Saying that “Claude is a model” or “ChatGPT is a model” is only true in some situations: the popular chatbots built around those models are in fact larger systems that include an orchestration layer, some generic decision architecture, a retrieval system, plus whatever additional knowledge it can pull in from your Microsoft 365 integration or a Google search. The underlying models themselves are increasingly commoditized and interchangeable.

Building your own models is a potentially massive undertaking that can theoretically pay off under very specific conditions. For instance, a colleague of mine works at a company that built an AI model specifically trained to suggest medical diagnosis based on the sound of a patient’s cough. That is legitimately something mainstream models like Claude and Gemini cannot do. There’s also the case of a customer service call center that received 58,000 calls per day and used that as training data for its own proprietary AI model to handle calls.

However, attempting to train your own model just to answer everyday questions about how to plan corporate events or summarize entries from your company’s product catalog for emails is something the mainstream models can definitely do just fine. Attempting to develop your own model for that type of thing is an expensive vanity, as Bloomberg found after investing millions in developing a model trained on its financial news database only to have the model eclipsed for performance on financial questions by the next general release of ChatGPT.

Distribution and Customer Relationships

Who actually owns the commercial relationship with the buyer and collects the money. The end user might not know the components that make up an AI system, but they know who sold it to them. And this is what you usually give up when you agree to become somebody’s data source rather than a platform vendor.

Staking Your Claim

Nobody needs to own all six layers (though the big frontier labs certainly try.) A boutique firm that advises on airport security might have excellent decision architecture (even if it resides in their consultants’ heads), but probably shouldn’t bother training their own model to answer client questions. Likewise, an environmental engineering company might have an enviable collection of data going back fifty years, but might not have the capacity (or the appetite) to develop their own software applications on top of that data.

At the same time, you need to identify which layers of the AI ecosystem you currently serve, which ones you could serve, which you would want to serve, and where you could either pay for someone else’s capacity or let someone else pay for yours. That, ultimately, determines how you respond to proposals from tech companies and clients.

If all you own is the knowledge, your leverage depends on what kind of knowledge it is, and what the other party wants to do with it. A static archive, or expertise that’s largely documented elsewhere, is a commodity that decays as general AI models improve. If that’s you, your best option might be to find a buyer, and fast.

Continuously generated data (claims records, transaction logs, field measurements) is more durable, but only in one of two scenarios. If the other party needs the exact figures or text (this month’s reimbursement rates, the current version of a regulation), they’ll need your latest records again and again, and that’s worth an ongoing license. If they only want to train a model on the patterns in your data, the math changes. A model that has learned from your 2014–2026 records may gain little from adding 2027, unless the underlying patterns shift. In that case, the bulk of your leverage is spent the day they complete the first training run, so price that first transfer accordingly.

If you own the retrieval layer and the workflows that keep knowledge current and AI-legible, you potentially have something that can be sold by the year or by the query rather than by the file. 

If you own the decision architecture, you own the thing frontier labs value most, which is why they’re paying professionals six-figure sums to help train their models. But it’s also your most portable asset. Unlike a database, judgment can walk out the door with any consultant who takes a retainer, and it can be partially reverse engineered just by studying enough of your system’s outputs. It holds its value only as long as you keep it close: embedded in systems you control, protected by contracts that bar using your outputs to train competing models, and continually refined so that any copy is already out of date.

If you own the model or the orchestration / application layer, then you are in a technology arms race, likely against better-funded competitors.

Finally, if you own the customer relationships, that is the last layer that technology will disrupt directly, but you need to make sure customers see your firm as their trusted partner in applying AI within your domain, not the “old guard” expert consultant they’re replacing with somebody else’s AI system.

Deciding which layers you could own is the easy half. The hard half is being honest about whether your organization can actually operate them.

We’ve written before about what it takes to “own a robot” (i.e., an AI system): design, testing, implementation, support, and the unglamorous maintenance that never ends. Moving from domain expert to AI solution provider sounds marvelous in a strategy session. Then somebody has to hire engineers, build evaluation suites, survive a security review, support an API (or MCP server), keep it running, get the solution past procurement and IT / compliance reviews, and answer a ticket from a customer in Germany at three in the morning who can’t understand why the AI system you built for dental treatment planning refuses to fill out the insurance paperwork (even when that refusal is a guardrail you deliberately designed into the system).

This isn’t to say a consulting firm or data provider that doesn’t want to become a software company has no choice but to capitulate to the tech giants. The frontier labs pay handsome retainers for professionals to help train their general-purpose models precisely because expert domain knowledge is hard to come by. That scarcity is leverage, whether you choose to negotiate with the tech companies encroaching on your space or compete against them.

The Decision Before You

Getting back to “the call”, what should you say when someone with an AI system wants to consume your data or codify your decision-making approach? 

It comes down to five questions.

1. What exactly do you possess that they want, and why can’t they get it cheaply somewhere else?
2. Are they paying to consume the output of your expertise, or acquiring the ability to reproduce the capability that generates it?
3. Do the assets they’re asking for hold their value through continuous maintenance, or is their scarcity going to decay as general AI models improve?
4. What could you realistically build from it yourself, at which layers, given your actual capital, capabilities, distribution, and appetite for pain?
5. Which deal structures would let you monetize whatever you have in the present, without unduly limiting your options later?

While the answers might not change your position, they can at least help you name your price.

Conclusion

While their motives might seem suspect, the people asking for your data or your decision-making framework are not villains. They’re just following their own incentives: if somebody else’s hard-won expertise would make their AI system meaningfully better, of course they want access to it. 

Likewise, you have an equal obligation to work out what that access is worth, or whether to turn the tables by building an AI solution around your knowledge assets and offering that to your customers.

Ultimately, the fact other parties are calling about your knowledge is a good sign. It means that people with budget and technical capability have concluded that what you have is easier to obtain from you than to reproduce without you. The only question is whether, by letting them harvest your knowledge, you might be unwittingly selling the farm.