Canonical: https://ai-nterprise.com/articles/the-model-is-rented/ Language: en Content status: published [Ideas](https://ai-nterprise.com/articles/) · Learning # The Model Is Rented. The Learning Must Be Yours. Ottaviano De Cicco · 15 July 2026 · 11 min read First published on [LinkedIn ↗](https://www.linkedin.com/pulse/model-rented-learning-must-yours-ottaviano-de-cicco-16xsf), 15 July 2026. ![](https://ai-nterprise.com/assets/editorial-learning.webp) *Satya Nadella's "Reverse Information Paradox" identifies the enterprise AI asset most companies are failing to protect.* Most companies have an AI budget. Almost none has a learning balance sheet. On July 12, 2026, Microsoft CEO Satya Nadella published a long-form post on X titled *The Reverse Information Paradox*. He starts with Kenneth Arrow's classic information paradox: a seller cannot demonstrate the value of information without revealing it, but once revealed, the buyer already possesses it. AI reverses the direction of exposure. To make an external model useful, the buyer must provide context: documents, workflows, exceptions, corrections, evaluation criteria, and the institutional knowledge that distinguishes one company from another. The more useful the system becomes, Nadella argues, the more the organization reveals about how it thinks. His conclusion is memorable: "In consuming intelligence, you are creating intelligence. And what you create should belong to you." It is a sharp observation. It is also easy to misunderstand. The quickest interpretation is a familiar one: do not upload confidential documents, negotiate no-training clauses, deploy open models on-premise, and keep sensitive data behind the firewall. All sensible measures. All incomplete. The strategic question is not only where your data travels. It is where your learning accumulates. ## The tension inside Nadella's paradox The paradox describes a real asymmetry: the provider can progressively learn how your business operates, while you have little visibility into what it learns in return. Read as a claim about foundation-model training, however, it requires an important qualification. Microsoft's own documentation states that prompts, completions, embeddings, and training data submitted to Models sold by Azure in Microsoft Foundry — including Azure OpenAI models — are not used to train foundation models without the customer's permission or instruction. OpenAI makes a similar commitment for its business products and API platform: business data is not used for model training by default. These protections do not eliminate every privacy, retention, security, or contractual risk — those remain dependent on the product, configuration, and agreement being used. But they do change the diagnosis: it is not accurate to assume that every enterprise prompt automatically enters the next training run of a frontier model. So how can the enterprise still pay twice? Because foundation-model training is not the only place where organizational learning can be lost. An employee asks an AI to prepare a proposal. The first version is wrong. A senior colleague corrects the positioning, removes an argument that does not work in that industry, changes the pricing logic, and explains which objection the client is really likely to raise. The final proposal is excellent. The task has been completed. But where did the correction go? Perhaps it remains inside one conversation. Perhaps it disappears into an employee's personal prompt history. Perhaps the next salesperson starts again from zero and makes the same mistakes. The vendor may not have learned anything from that interaction. But neither has the company. Call this learning leakage: the value created during human-AI interaction is not converted into a reusable, portable, organization-owned asset. Sometimes knowledge leaks outward. More often, it simply evaporates. An organization does not need to have its knowledge stolen in order to lose it. It only needs to fail to retain it. ## Every AI interaction produces two outputs The first output is visible. It is the report, the code, the forecast, the customer response, the legal summary, or the product recommendation the user requested. That output completes today's task. The second output is less visible. It is the record of what the user asked, which context mattered, which tools were selected, what the model misunderstood, what the expert corrected, which answer was rejected, how success was evaluated, and where human escalation became necessary. That output determines whether tomorrow's task will be performed better. The first is usually counted as productivity. The second is rarely accounted for at all. Most enterprise AI programs are designed to generate outputs. Very few are designed to capture the learning created while those outputs are being produced. This is the asset Nadella's essay points toward, even though the distinction deserves to be made more explicit: the real second payment is not always knowledge transferred to the provider. It is often knowledge created by the enterprise but never added to the enterprise. ## Data is not the same as learning Companies have spent two decades building data estates: customer records, product catalogs, contracts, transaction histories, policies, telemetry, and documents. That data is essential. But data describes what the organization knows. Learning describes how the organization decides. A policy document tells the model what the official rule is. An expert correction reveals when the rule should not be applied literally. A CRM database shows which deals closed. A senior salesperson's feedback explains why one argument worked and another damaged credibility. A risk model provides a probability. An experienced underwriter's decision reveals when the available variables fail to capture the real exposure. A product specification describes what can be built. An engineering escalation reveals which compromise the company is willing to accept when time, cost, safety, and customer expectations collide. The documents contain information. The exceptions contain judgment. Prompts reveal what people are trying to accomplish. Corrections reveal what the organization considers wrong. Private evaluations reveal what the organization considers good. Escalations reveal where accountability still requires human expertise. Together, these form something far more valuable than a prompt library: they form the organization's operational intelligence. A competitor can license the same foundation model. It may even acquire similar public data. What it cannot easily buy is twenty years of accumulated exceptions, trade-offs, rejected alternatives, and accountable decisions. The competitive asset is not the answer. It is the system that becomes better at recognizing what counts as a good answer. ## The Enterprise Learning Loop A functioning enterprise learning loop has a simple sequence: Context. Execution. Evaluation. Correction. Adaptation. Memory. Reuse. The model receives the relevant context and performs a task. A person or automated control evaluates the result. Errors and exceptions are captured. The workflow, retrieval layer, instructions, tools, or adapted model are improved. The approved learning enters organizational memory. The next execution begins from a higher level. The loop compounds only when the correction changes future performance. If an expert corrects an answer and the improvement affects only that conversation, the company has purchased a useful service. If the correction improves every relevant future interaction, the company has built a capability. That capability depends on several assets. Private evals encode what good performance means inside the organization. Traces preserve the context, tool use, sequence, and provenance behind an outcome. Structured feedback captures not only that an answer was wrong, but why. Organizational memory retains approved knowledge without turning every historical interaction into uncontrolled context. Orchestration determines which model, data source, tool, and human authority should handle each part of the workflow. Adaptation rights allow the organization to use its outputs, corrections, and evaluations to improve its own systems. These are not secondary pieces of telemetry. They are operating intellectual property. The enterprise does not necessarily need to own the foundation model, the GPUs, or every component of the infrastructure. It needs to own the layer that remembers why one answer was accepted and another was rejected. Own the loop, not necessarily the model. ## The model-removal test There is a practical way to determine whether an organization owns its learning. Imagine that its primary AI model or provider becomes unavailable on Monday morning. Can the company still run its private evaluations? Can it export and reuse its organizational memory? Can its workflows be directed toward another model without being rebuilt from scratch? Do its corrections, decision rules, prompt patterns, and escalation logic remain usable? Can it reproduce why important outputs were approved? Will the replacement system begin as a novice, or inherit the experience accumulated by its predecessor? If removing one model also removes the organization's acquired competence, the company has not created an enterprise AI capability. It has created a dependency. Legal ownership of inputs and outputs is important, but it is not sufficient. Operational ownership means being able to inspect, export, reuse, adapt, and continue learning when a supplier changes. Nadella recommends decoupling orchestration from any single model. That is exactly the right principle — and it should apply to Microsoft just as rigorously as it applies to OpenAI, Google, Anthropic, or any open-model provider. A principle of model independence is valuable only when it includes independence from the company proposing it. ## Cloud versus on-premise is the wrong argument The immediate response to this problem is often to frame it as a deployment choice: cloud or on-premise, closed or open source, API or owned infrastructure. These choices matter, but they answer different questions. On-premise deployment answers where computation occurs. An open-weight model makes its parameters available for local operation or adaptation; its license determines what an organization may legally do with them. Neither fact, by itself, guarantees that the complete system qualifies as open source — a distinction formalized by the Open Source Initiative. And neither decision, by itself, answers who owns the evaluations, memory, corrections, workflow logic, and accumulated judgment. A cloud architecture can preserve learning sovereignty when it provides strong tenant boundaries, explicit no-training commitments, usable export paths, customer-controlled memory, and model-independent orchestration. An on-premise architecture can still destroy it when evaluations live in scattered spreadsheets, corrections remain inside individual chat sessions, logs are inaccessible, and the entire workflow depends on one proprietary stack. The same is true of cost. Open models and self-hosted infrastructure can produce major savings in the right workload. But there is no universal 90% rule. One recent preprint estimates break-even periods ranging from months to years depending on model size and volume, while another finds that low utilization alone can increase the effective cost of self-hosted inference by more than twentyfold. "90% cheaper" may be the result of a particular benchmark. It is not an enterprise architecture. Deployment location is an implementation choice. Learning sovereignty is an operating-model choice. ## What enterprise leaders should do now Five actions should be on the leadership agenda for the next two quarters. **Inventory the second output.** Extend the traditional data inventory to include prompt patterns, evaluations, corrections, decision traces, agent tool calls, memories, fine-tuned components, workflow rules, and escalation logic. Identify where each asset resides, who can access it, how long it is retained, and whether it can be exported in a usable form. **Treat private evals as core intellectual property.** Public benchmarks tell you whether a model is broadly capable. They do not tell you whether it performs correctly inside your organization. The scenarios, thresholds, edge cases, and failure conditions used to evaluate AI should be versioned, governed, and owned like any other strategic asset. Whoever defines the evals defines what good means. **Capture expert correction at the point of work.** Do not expect senior professionals to maintain a separate knowledge-management system after completing the task. Build feedback capture into the workflow: what was accepted, what was rejected, what changed, why it changed, and what outcome followed. Expert attention is expensive. Paying for the same correction repeatedly is one of the least visible costs in enterprise AI. **Separate the learning layer from the model layer.** Evals, memory, workflow state, permissions, provenance, and business rules should not exist only inside a model provider's interface. Architect them as enterprise-controlled services that can work across multiple models. Then test that portability before a commercial or operational crisis makes the test unavoidable. **Negotiate operational ownership — and measure compounding.** Contracts should address more than input and output ownership. They should clarify retention, feedback use, deletion, portability, adaptation and fine-tuning rights, subprocessors, model substitution, and exit assistance. Internally, measure whether corrected errors recur, how quickly verified learning is reused, how performance changes against private evals, and what it would cost to switch providers. AI productivity is not compounding merely because usage is increasing. It compounds when every verified correction makes the organization permanently better. ## The moat is moving Access to a powerful model can provide an advantage today. But access diffuses. Competitors can subscribe to the same APIs, deploy the same open-weight models, hire from the same labor market, and connect similar enterprise data. The durable difference will be the speed at which each organization converts experience into retained intelligence. Two companies can use the same model on similar documents. One company's experts repeatedly correct the same errors in isolated conversations. The other captures those corrections, converts them into evaluations and workflow improvements, tests them, and distributes the resulting learning across the organization. After one interaction, the difference is small. After one million interactions, they are no longer using the same system in any meaningful sense. One has an AI tool. The other has an institutional learning machine. ## Trust, judgment, ownership In *The Trust Gap*, I argued that the emerging agent economy requires independent ways to verify what AI systems actually do. In *The Human Hallucination*, I argued that the human-machine pair must also be evaluated, because AI can increase a person's confidence faster than it increases their competence. The Reverse Information Paradox introduces the third layer. Trust asks whether the system performs as claimed. Judgment asks whether the human knows when it does not. Ownership asks whether each verified correction makes the organization permanently smarter. These are not separate governance problems. They form the control system of the AI-augmented enterprise. The board-level question should therefore no longer be only: *Which model are we buying?* It should be: *When our people teach an AI how this company works, who gets smarter permanently?* Rent the model when that is efficient. Never rent your organization's learning. **Sources:** Satya Nadella, "The Reverse Information Paradox," long-form post published on X, July 12, 2026; Kenneth J. Arrow, "Economic Welfare and the Allocation of Resources for Invention," in *The Rate and Direction of Inventive Activity* (1962); Microsoft, "Data, privacy, and security for Foundry Models sold by Azure"; OpenAI, "Enterprise Privacy at OpenAI"; Open Source Initiative, "The Open Source AI Definition 1.0"; G. Pan, V. Chodnekar, A. Roy, and H. Wang, "A Cost-Benefit Analysis of On-Premise Large Language Model Deployment: Breaking Even with Commercial LLM Services," arXiv:2509.18101 (2025, preprint); C. Patil, "Beyond Per-Token Pricing: A Concurrency-Aware Methodology for LLM Infrastructure Cost Estimation," arXiv:2606.11690 (2026, preprint). *Author's note: I am continuing to explore these themes through advisory work and ongoing research. I welcome conversations with leadership teams examining how to preserve institutional judgment, model choice, and learning sovereignty as AI moves from experimentation into core operations.* © 2026 Ottaviano De Cicco. [Use the Four Questions worksheet](https://ai-nterprise.com/tools/#four-questions) [Explore the book](https://ai-nterprise.com/book/)