Satya Nadella calls it the Reverse Information Paradox: the buyer pays for intelligence, then risks giving away the proprietary knowledge required to make that intelligence useful. His proposed answer — an enterprise trust boundary that contains not just data but memory, traces, feedback, decisions, evaluations and adapted capability — is the framing most enterprise AI security programmes are still missing.

Most of those programmes start and end with the documents: where they are stored, whether providers use them for training, who can retrieve them, how long they are retained. Those questions remain necessary. They are no longer sufficient.

As AI becomes part of daily work, the organisation creates a record of how it thinks and acts. Prompts reveal what people are trying to accomplish. Tool calls reveal how work is performed. Corrections reveal what experts know. Evaluations reveal what the organisation considers good. That is precisely the knowledge an enterprise AI system needs to become useful — and the knowledge that makes the enterprise distinctive.

Trust layer or trust boundary?

Distinguish this from the "trust layer" language platforms such as Salesforce use. A trust layer enforces protections around an interaction: identity, permissions, prompt defence, data masking, output filtering. The trust boundary is the larger organisational boundary around what may leave the company at all — including traces, evals, corrections and the learning derived from them. You need both, but they solve different problems.

A conventional security boundary can guarantee a document is encrypted and excluded from provider training. Meanwhile, the surrounding application scatters prompts, traces, evaluations, corrections and workflow memory across several providers and employee-created agents. The files stay perfectly protected while the organisation quietly gives away control of the learning loop around them. In the cloud era, companies accumulated data. In the AI era, they also accumulate learning.

Why must the trust boundary include the orchestration layer?

The model does not create the whole learning loop. The orchestration layer decides what context reaches the model, which tools it may use, how results are evaluated, what corrections are retained and how that experience changes the next workflow. Protecting the database while renting all of those decisions, the piece argues, is like locking the filing cabinet and handing somebody else the keys to the factory.

The assets that should stay inside the boundary:

• workflow state and completion rules
• evaluations and definitions of a good outcome
• traces, corrections and human interventions
• organisational memory and entity relationships
• permissions and authority by workflow step
• model-performance, cost and reliability history

All of these should remain useful when the enterprise changes model providers.

What do corrections actually teach?

When an experienced product leader corrects an AI-generated recommendation, the value exceeds one better answer. The correction may reveal that a customer segment matters more, that a request conflicts with strategy, or that an internal term carries a precise meaning the public model could not know. If the correction disappears into a transcript, the organisation pays to rediscover it. If it becomes structured workflow knowledge, the next decision starts from a better position.

The fix is often prosaic rather than fine-tuning: change the retrieval, the workflow rule, the validation, the context, or the point where the system asks a person.

Who defines "good" — the benchmark or the business?

Generic benchmarks can show a model is capable. They cannot tell a company whether it made a good decision in context. Private evaluations should reflect real workflows, policies, data and trade-offs: did the system use the right evidence, respect authority, distinguish an isolated request from a recurring pattern, stop at the right point? These evals are proprietary because they encode how the organisation judges work — and they should be portable across models, not tied to one provider's agent environment.

Choice is part of trust. An enterprise does not control its learning loop if removing one model removes its ability to operate. True model independence is a resilience property, not just a procurement advantage.

How does governance reach the running workflow?

IBM now distinguishes periodic AI governance from continuous AI assurance. A policy records what an agent was approved to do; assurance asks whether the live system still does it after the model, tools, prompts, data and connected agents have changed. Permissions, approval points, validation and escalation cannot live only in a governance catalogue — the layer that assembles context and authorises actions must exercise them.

ProdPad positions itself inside this argument: its connected product system holds why ideas matter, what evidence supports them and what was rejected, while Conductor orchestrates that context — selecting relevance, applying rules, validating actions, retaining structured state instead of relying on a model to remember a conversation. A real enterprise trust boundary, the piece closes, protects not only what the company knows, but how the company learns — and as agentic workflows become the default operating mode, the teams that own their learning loop will treat model choice the way they treat cloud regions: swappable infrastructure, not identity.