AI is changing how customers use data: less like a destination they visit, and more as a layer inside their day-to-day workflows. That creates a clear opportunity for providers, but also a risk that valuable usage becomes embedded before it is properly priced or controlled. Providers that get the rights, access model, and pricing right can turn that risk into a new source of growth.
AI is changing the interface of data, information, and analytics businesses. It is already beginning to create value for customers and providers and has the potential to create much more.
But the market is still emerging. Figuring out where to focus and how to commercialize AI is not straightforward, and providers risk failing to capture the full incremental value AI can create because they do not ask the right questions at the start.
We at Simon-Kucher believe all providers need to concretely answer three questions:
Where should we focus, customer AI rights or our own AI products? We believe too many providers are jumping to a conclusion on where to focus their efforts without first spending the time to understand where they will truly deliver incremental value vs. alternatives, and where their real right to win is.
How should we monetize customers using our data in AI? We see providers giving away too many rights, too early, without getting the upside from the additional value they deliver by allowing their data to be used by client-side AI tools.
How should we monetize AI products we build ourselves? AI tools change the pricing paradigm for traditional data, information, and analytics businesses. We often see providers go to one of two extremes. They might not sufficiently adjust their monetization model to account for the different ways they now deliver value. Or, they might jump straight into wanting a complex usage model before having the basic requirements in place or the fundamental value dynamics to warrant it.
These questions often get blurred together, but each requires a different commercial logic. The first is about strategic focus. The second is mainly about usage rights, contractual permissions, and IP protection. The third is a more classic new product monetization question.
Choose where to play: Customer AI rights, provider-built products, or both
Define your role in the AI value chain
We often find providers jumping straight to building AI-enabled products without first having an honest view of where their moat sits and where they have a right to win. This creates a risk of building AI products for vanity’s sake: impressive demos, weak willingness to pay, and limited differentiation against what advanced customers can build internally.
Providers need to consider their AI maturity versus their customers’. In this context, it means having both the technical capability and the domain expertise to deploy that capability in a commercially useful way.
Customer AI maturity: Some customers are still manually uploading PDFs, exports, or charts into approved AI tools. Others are connecting enterprise AI tools to approved content sources. More advanced customers are building internal RAG layers, knowledge graphs, and workflow tools that combine provider data with internal and third-party sources. The most advanced are beginning to trial automated agents that can perform workflows using providers’ data with limited human prompting.
Provider AI maturity: Some providers are still at basic AI UX: search, summaries, and Q&A. Others are building content-aware assistants across subscribed products. More advanced providers are building structured workflow tools, model-driven decision support, monitoring products, and AI-enabled analytical workflows.
If customers are more AI-mature than the provider, the latter may struggle to sell them advanced AI tools. These customers often want to build internally, combine multiple data sources, and apply their own domain expertise. For them, the priority should be paid rights for AI usage, governed access, and clear licensing.
If the provider is more AI-mature than the customer, provider-built AI products become more attractive. Less advanced customers may not want to build their own internal RAG layer, knowledge graph, or analytical agents. For them, the priority should be building and selling AI-native tooling.
Ultimately, the answer is rarely just selling rights or building products. Most data, information, and analytics businesses will need both because they sell to a diverse group of customers with a range of AI sophistication. But it is important to do the thinking and position the right offering to the right customer, rather than building AI products for vanity’s sake.
Monetize customer-side AI use of your data
For many providers, the most immediate AI monetization opportunity is selling the right for customers to use proprietary data, content, and analytics inside their own AI environments.
In its basic form, it does not require substantial technical lift from the provider. It is also a space where we typically find customers proactively asking for the right, creating a low-friction upsell opportunity.
The commercial task is to avoid giving those rights away accidentally, or for less than their real value.
AI access rights should typically be monetized in addition to standard access
The access mechanism matters, but it is not the main source of value being sold. API, Snowflake, bulk feeds, managed connectors, and MCP are routed into the data. The value being sold is permission to use that data in an AI-enabled system.
Over time, some internal AI usage rights may become more commoditized. Customers may increasingly expect a basic level of enterprise AI usage in the same way they expect online portal access today, and some data sectors increasingly expect API access. But right now, there is still willingness to pay, especially where the use case gives the customer broader internal distribution, workflow integration, machine-led consumption, or the ability to build their own intelligence layer.
MCP can create a more governable and monetizable route than client-hosted RAG
MCP is attracting attention because it gives AI systems a more standardized way to connect to external data and tools. For data, information, and analytics providers, the value goes beyond technical convenience. MCP can create a differentiated customer experience through a semantic layer, more precise retrieval, and the ability to support specific question types or workflows. In some cases, that can dramatically change the offering itself.
It also creates a more governable and more monetizable route than sending data through bulk feeds or API and then licensing customers for internal RAG rights.
MCP can help solve a longstanding problem for B2B data providers: once data is delivered through an API or bulk feed, providers can become partly blind to how it is being used. MCP and other governed retrieval routes can reduce that blindness, although API can still support some controls such as rate limits.
Compared with sending bulk data into a client-hosted RAG environment, a provider-controlled access layer can make it easier to:
- check entitlements at a more granular level
- see what content is being queried and where demand is emerging
- distinguish occasional human-led use from automated or agent-led use
- identify upsell opportunities when users ask questions that require non-subscribed content
- develop derivative insight products based on aggregated demand signals, where customer confidentiality and market norms allow
This creates new pricing options. Providers can consider premium skills, use-case packages, fair-use limits, usage tiers, workflow-based pricing, or agent-style fees once they have enough evidence of how customers are using the access route.
It is also significantly more governable and poses a lower risk from a value leakage perspective. If the provider can govern retrieval, observe usage, and control entitlements, it is in a stronger position than if it simply delivers a large dataset and loses visibility once it enters the customer’s environment.
The commercial implication is that MCP should often be preferred over giving broad rights to internal RAG. For some providers, this may mean moving towards an MCP-first model. For others, it may mean retaining both while making MCP more commercially attractive.
Usage pricing fails where usage is a poor proxy for value
Usage-based pricing is attractive in theory. AI usage can scale quickly, especially when agents begin querying, monitoring and analyzing content without a human manually asking each question.
But usage is not always a good proxy for customer value. A single high-value decision may involve limited usage. A high-volume workflow may create relatively modest incremental value. In some cases, the value comes from access, confidence, or availability rather than from the number of queries.
There is also an operational constraint. A credible usage model needs reliable telemetry, entitlement control, billing mechanics, contract language, and a metric that customers can understand. Without those foundations, usage pricing creates friction. Sales teams struggle to explain it, customers struggle to forecast it, and providers struggle to enforce it.
For many providers, the better near-term answer can be simpler, such as a fixed AI access fee, an uplift on the existing subscription, or a differentiated subscription based on content access or use case scope.
Once telemetry, entitlement control, billing mechanics, and the commercial logic are in place, and there is a strong case that usage is a good proxy for value, then usage-based pricing can be considered. Until then, simple access-based or rights-based pricing may be the more practical answer.
Monetize provider-built AI products and workflow tools
The second monetization route is provider-built AI: tools, assistants, and workflows that sit inside the provider’s own product environment or are sold as standalone capabilities.
This needs a different logic from customer AI access rights. The real test is whether the AI product creates enough additional value to warrant a separate charge, not just which rights the customer should receive.
Basic AI search usually belongs to the core product
In-product AI search, summarization, and Q&A are quickly becoming part of the baseline experience for information products. This functionality can improve engagement, make existing subscriptions more useful, and support retention.
One key condition is that, if included, it should normally be limited to subscribed content. If AI helps a customer navigate, summarize, or interpret content they already subscribe to, it is part of the product experience. If it queries broader datasets, combines unsubscribed content, or produces answers from assets the client has not licensed, that becomes a different proposition.
Workflow tools offer a stronger case for incremental commercialization
Not every provider-built AI tool should be priced the same way.
A simple assistant that helps users find and understand subscribed content may belong in the core product. A tool that runs scenarios, screens portfolios, benchmarks assets, drafts analytical outputs or monitors market changes has a stronger case for a separate fee.
The reason is not that it uses AI. The reason is that it helps complete a higher-value workflow.
LexisNexis Protégé is a useful example of where the market is heading. It is positioned not just as AI search, but as an AI legal assistant for research, drafting and legal workflows, with repeatable processes grounded in trusted sources and a firm’s own knowledge.
The key is to identify the workflows where you can add real value and where you have an edge versus internal build through your domain expertise, data assets, and/or AI technical capability.
Match the monetization model to how value is created
A practical way to think about the monetization options is:
| Monetization model | When it fits |
|---|---|
| No incremental charge, with underlying content entitlement required | AI improves discovery, navigation, summarization, or interpretation of subscribed content and helps drive additional cross-sell. |
| Flat access fee | The tool provides clear incremental value, but value does not scale clearly with each use. Value scales more with access than with usage. |
| Usage-based pricing | The tool consumes meaningful compute and/or value scales with repeated execution, scenarios, calculations, or model runs. |
| Agent / virtual analyst fee | The tool performs recurring analytical work, such as monitoring, alerting, or regular report creation that can be translated into an analyst-style fee. |
Content packaging and entitlement design to get full value from selling AI tools
AI makes content packaging and entitlement design much harder.
In a traditional platform model, users search within the products, modules, or datasets they have bought. In an AI model, the best answer may require reasoning across multiple datasets, some of which the customer does not subscribe to.
There are three broad options.
| Entitlement model | Commercial implication |
|---|---|
| Strict entitlement | AI only accesses content the customer already buys. Clean and protective, but can limit the user experience. |
| Entitlement plus awareness / preview | AI signals that relevant additional content exists, but does not expose the full answer without entitlement. |
| Broad AI awareness | AI can reason across wider content, even where the customer does not subscribe. Strong experience, but high value leakage risk. |
For most providers, entitlement plus awareness is likely to be the strongest default. It protects the existing revenue model while turning AI into a discovery and upsell channel.
Broad AI awareness may still make sense if the tool is being sold to a customer segment that is unlikely to use the core content offering, or if the provider can monetize the tool strongly enough to outweigh the cannibalization risk to core content revenue.
A separate question: Third-party AI platforms and aggregators
Third-party AI platforms raise a separate set of issues and deserve their own treatment.
There is a major difference between a ring-fenced customer-specific deployment and a repeatable third-party product that ingests proprietary data, builds an intelligence layer, and resells the derived value.
The first may be licensable under the right control. The second can disintermediate the provider, weaken the customer relationship, and create material IP leakage risk by enabling a third party to build a competing product using the provider’s own IP.
Companies must understand where their real value and moat lies, where customers will build for themselves, and where AI-enabled rights or workflows create value that should not be given away for free. Get in touch with our experts on how to get this right.
For a separate deeper discussion of partnership models and third-party AI aggregator strategy, stay tuned.
