The Frontier Model Is Not Your Institutional Memory

There is a widespread enterprise instinct that says: do not send the company’s knowledge to OpenAI or Anthropic. The instinct is sound. The usual justification for it is not.

Stated as “the frontier labs will steal our data and train on it,” the argument is easy to dismiss, because it is mostly false under the commercial terms those companies actually publish. Stated properly, it is very hard to dismiss, and it points at a specific architecture rather than at abstinence.

The proper statement is this. Even when a frontier lab honours every confidentiality commitment it has made, close exposure to your workflows, your demand patterns and your integration requirements teaches it which vertical products to build. Those companies are already building them. The risk is not theft. It is gradual vertical encroachment plus operational dependency, and the defence against it is architectural rather than contractual.

This piece separates the risk into parts that can be evaluated independently, checks what the vendors actually say, looks at the architecture the market is converging on, and examines the evidence from the Nvidia and Palantir partnership announced in June 2026. It also corrects two arguments that sound good and do not survive checking.

Part one: three risks, not one

The single biggest analytical error in this debate is bundling. “They will take our data” collapses three separate risks with different likelihoods, different mitigations and different time horizons. Separated, each can be assessed on its merits.

Risk one: direct use of confidential content

This is the risk people name first and the one best covered by existing commitments.

For commercial products, customer inputs and outputs are not used to train the models by default. OpenAI states that data submitted through the API, ChatGPT Enterprise and ChatGPT Team is not used for training. Enterprise accounts default to no training.

So the strong claim fails. It would be inaccurate to assert that a pharmaceutical company’s research or a law firm’s client files are routinely ingested and folded into the next public model.

But “not used for training” and “not retained” are two different controls, and conflating them is the second analytical error in this debate. OpenAI retains API inputs and outputs for up to 30 days to operate the service and identify abuse, after which they are removed unless retention is legally required. Zero Data Retention is available, but it is not the default: it is granted on prior approval, for a qualifying use case, generally under an enterprise agreement, and it applies only to eligible endpoints.

That last clause matters more than it looks. A zero-retention guarantee scoped to eligible endpoints means that adopting a new stateful feature can quietly move data outside the arrangement you negotiated. The guarantee holds; your usage drifts out from under it.

So the honest version of risk one is not “they will train on it.” It is a list of questions that a contract lowers but does not eliminate:

A contractual promise reduces the probability of harm. It does not reduce the attack surface, and it does not reduce the dependency.

Risk two: the provider learns the market without reading your documents

This is subtler, more credible, and almost never mitigated by the contract everyone is arguing about.

A frontier provider does not need to read your molecular formulas or your legal briefs to learn:

None of that requires training on confidential content. It comes from aggregate usage patterns, support tickets, sales engagements, product telemetry, customer interviews and partnership work. It is ordinary product development. Any competent vendor does it. That is precisely the problem: an infrastructure provider doing normal product development learns exactly where to move up the value chain.

This is the classic platform conflict, and it is not new. Amazon’s marketplace sellers, Microsoft’s application vendors and Apple’s app developers have all worried about the same dynamic. The issue is not misconduct. It is informational asymmetry combined with vertical integration. The customer teaches the platform what is valuable, and the platform eventually packages that knowledge into a standardised product.

Note what is not required for this risk to be real: no bad faith, no breach, no policy violation, no training on your documents. It operates entirely inside the rules.

Risk three: the provider becomes a vertical competitor

This is no longer hypothetical, and the record here is more advanced than the general debate assumes.

Anthropic launched Claude for Healthcare in January 2026, with HIPAA-ready infrastructure, models trained specifically for healthcare and life sciences tasks, and native integrations to standard medical and scientific databases including the CMS Coverage Database, ICD-10 codes and PubMed. In June 2026 it followed with Claude Science, described not as an assistant to pharmaceutical research but as a workbench that runs it: a researcher can issue a single instruction, such as screening for a promising compound, and the platform carries out the analysis, runs the computing tasks and returns results on its own.

OpenAI moved in parallel with a different emphasis, launching ChatGPT Health as a consumer hub where users upload medical records, alongside OpenAI for Healthcare as an enterprise suite. One company is building for the laboratory and the regulatory office; the other is positioning for the individual patient. Both are in the building, and both were previously selling only the model underneath.

Neither is replacing hospitals, pharmaceutical companies or full-service law firms today. Mostly they are selling tools to those organisations. But the direction of travel is not ambiguous:

  1. Sell a general model.
  2. Learn which workflows are valuable.
  3. Add connectors, retrieval and domain tools.
  4. Package industry-specific agents.
  5. Sell completed outcomes instead of tokens.
  6. Capture part of the application-layer margin.

Every step of that is rational for the provider and legitimate. And every step of it makes the following questions rational for the customer:

A legal research company asks why it should route all of its queries, its failure cases and its workflow requirements through a company that could offer legal research directly.

A pharmaceutical platform asks why it should expose its proprietary research process to a provider that has just shipped a life sciences workbench.

A consultancy asks why it should teach the model provider how its analysts run engagements, when the provider intends to sell autonomous research and advisory agents.

These are legitimate strategic questions even when the provider behaves impeccably under the contract. They are questions about position, not about trust.

Part two: why agents change the magnitude

Everything above was already true in the chatbot era, and enterprises largely tolerated it. Agentic systems change the scale enough to change the conclusion.

A chatbot receives one carefully selected document, pasted by a person who has had a moment to think about whether it should be pasted.

An enterprise agent sees internal databases, customer records, research results, email and communications, prior decisions, pricing, competitive analyses, workflow sequences, tool outputs, employee corrections, which recommendations were accepted, and whether the business outcome eventually succeeded.

That is not content. That is the organisation’s operating process.

Here is the part most often missed. The most valuable proprietary information is frequently not any single document. It is the sequence: which data the organisation retrieves, how it analyses it, which tools it calls, which exceptions trigger escalation, and how experts correct the system when it is wrong.

That sequence is exactly what somebody would need in order to build a competing agent. Documents describe what a company knows. Workflow traces describe what a company does, which is the harder thing to reconstruct and the more durable advantage.

So agentic adoption raises the value of keeping memory, orchestration and feedback under enterprise control, at the same time as it raises the volume of material flowing outward. Those two facts move in opposite directions, which is why the architecture question becomes urgent precisely when agents arrive.

Part three: what this argument does not justify

Two conclusions do not follow, and a piece that skips this section is advocacy rather than analysis.

It does not justify refusing frontier APIs. Organisations already entrust extraordinarily sensitive material to Microsoft, Amazon, Google, Oracle and Salesforce. The same organisations will use OpenAI and Anthropic where the capability advantage is large and the enterprise safeguards are credible. An absolute local-only position is not what sophisticated buyers are choosing, and predicting that they will is a bad forecast.

It does not require assuming bad faith. The argument works even if every provider is honest, competent and permanently well-intentioned. That is its strength. An argument that depends on the vendor misbehaving is refutable by the vendor behaving; an argument that survives good behaviour is a structural argument, and structural arguments are the ones worth building systems around.

The realistic destination is hybrid and multi-model. The question is not whether to use frontier models. It is what they are allowed to hold.

Part four: the architecture that follows

The design principle is one sentence.

Treat the frontier model as a stateless cognitive processor, not as your institutional memory.

Everything else falls out of it.

What stays inside the enterprise boundary

What is sent outward, selectively

What runs locally on open models

The frontier model becomes an occasional specialist consulted on hard problems, rather than the repository through which everything passes.

What the enterprise must own

Memory. Context construction. Retrieval. Permissions. Tool execution. Workflow orchestration. Evaluations. Audit trails. Model routing. Feedback and outcome data.

The external model receives the minimum information needed for one reasoning step and returns an answer. It never holds the persistent state of the business.

The second-order benefit is the one that matters commercially: this makes models replaceable. If a provider becomes a competitor, raises prices, changes retention policy, alters refusal behaviour or withdraws a model, the task routes to a different provider or an internal model. The accumulated institutional asset does not move, because it was never theirs to hold.

Part five: the Palantir and Nvidia evidence

On 29 June 2026, Palantir and Nvidia announced an engine for running Nvidia AI and Nemotron open models in sovereign environments, aimed at United States government agencies and critical infrastructure operators. Nvidia’s own write-up carried the phrase that summarises the whole strategy: open models, closed environments.

The combination pairs Nvidia’s compute, ecosystem and open models with Palantir’s AIP, Ontology, Foundry and Apollo. What makes it evidence rather than marketing is the list of properties the offering is built around: explicit data authorisation, secure perimeter enforcement, architecturally enforced customer-specific isolation, data portability, right to erasure, and full auditability.

Read that list again as a design specification. Every item is a control the customer holds against the model, not a promise the model provider makes to the customer. That is the distinction this entire argument turns on.

Palantir does not reject frontier models, it subordinates them

The position is not that OpenAI or Anthropic should never be used. It is that the organisation must be able to route, audit, replace and deploy model capability on its own terms, because access restrictions, retention rules, model behaviour and policy decisions can otherwise be changed from outside.

The model provides intelligence. The model provider does not control who may access what, does not permanently possess workflow history, does not become inseparable from operational systems, and cannot disrupt the business by changing prices, retention or refusal policy. The model is a component inside a governed operating system, rather than the operating system.

The ontology is the asset

An ontology encodes the organisation’s data, relationships, logic, permissions and actions, and connects model reasoning to the actual operating structure of the business while preserving security controls.

A pharmaceutical ontology might represent compounds, targets, experiments, researchers, clinical trials, manufacturing capacity, regulatory submissions, access permissions and approved analytical procedures. An agent should never receive unrestricted access to all of that. The control layer decides which information a given agent may retrieve, which tools it may call, which actions require human authorisation, what must be logged, which model receives which portion of the context, and whether a request may leave the sovereign environment at all.

The effect is to prevent the model from becoming an omniscient external observer of the organisation. Not by trusting it less, but by never assembling that view in a place it can see.

The feedback loop stays inside

The most telling detail in the announcement is easy to skim past. The engine collects user telemetry and trace data and uses it to post-train and align the model to the tasks where it adds most value, so the model improves at that organisation’s specific work.

That is the feedback loop described earlier as the crown jewel, and in this architecture it accrues inside the customer’s environment and improves the customer’s model. The same loop, run through a frontier API, accrues to the provider. The mechanism is identical; only the beneficiary differs. That is the whole argument compressed into one product decision.

Security means more than preventing theft

Framing this as data protection undersells it. The risks a control layer addresses are:

Confidentiality risk. Documents or workflow context retained, logged, exposed in a breach, accessed under legal process, or moved through a component with different retention rules.

Control risk. The provider can unilaterally change access rules, model behaviour, safety policy, API features, geographic availability, prices, rate limits and supported models. A mission-critical system should not depend on decisions made by an outside company on its own schedule.

Strategic intelligence risk. Risk two above. Demand signal flows upstream whether or not content does.

Competitive risk. Supplying revenue and market intelligence to an organisation that has already entered your vertical.

Operational risk. Outage, model withdrawal, unexplained behavioural change, or a refusal-policy change that breaks a workflow that worked yesterday.

Sovereignty risk. Governments, defence organisations and regulated industries need assurance that data, models and controls remain inside defined national or organisational boundaries.

Only the first is about theft. The other five persist under a perfectly honoured contract.

What good and bad look like

The reckless pattern: give employees a frontier chat interface, let them paste internal material into it, connect the model directly to databases, grant broad tool permissions, store agent memory with the provider, build workflows around provider-specific features, and assume the contract handles the rest. The result is a diffuse shadow-AI estate with no accountability and compounding vendor dependence.

The disciplined pattern: keep data and persistent memory inside the boundary; apply granular identity-based and purpose-based permissions; construct the minimum context per task; use local open models for sensitive and routine work; escalate to frontier models when the capability delta justifies it; redact or abstract before external processing; log every retrieval, model call, tool execution and consequential action; keep model routing under your own control; and preserve the ability to replace any single model.

Part six: the moat question, and a correction

Here the argument commonly overreaches, in a way worth correcting carefully because the corrected version is stronger.

The tempting claim is that the Palantir partnership uniquely strengthens Nvidia because AMD, Google, Amazon and Cerebras have no equivalent partner. That is factually wrong, and checkably so.

Palantir is not Nvidia-exclusive. On 4 June 2026, three weeks before the Nvidia announcement, Palantir and Google Cloud expanded their own partnership: Palantir available on Google Cloud Marketplace, two-way data federation between BigQuery and Foundry, two-way semantic exchange between Google’s Knowledge Catalog and Foundry’s Ontology, and deeper connectivity between Gemini and AIP, already in production at Eaton. Foundry also runs across AWS, Azure and Oracle Cloud. Palantir sells a control layer, and a control layer whose value proposition is model replaceability can hardly refuse to be infrastructure-portable.

The competitors have coalitions of their own, and they formed quickly. On 22 July 2026, Cerebras announced a partnership with CrowdStrike to power Falcon AI Detection and Response with wafer-scale inference. The next day, AMD and Cerebras announced a disaggregated inference solution pairing AMD Helios rackscale systems with the Cerebras Wafer-Scale Engine, splitting the work so that AMD handles prompt processing and large context windows while Cerebras accelerates token generation, with modelling suggesting up to five times the tokens per second per watt of a wafer-scale-only configuration, arriving through Cerebras Cloud in the second half of 2026. That came a day after AMD’s five billion dollar investment in Anthropic. Cerebras separately holds a multi-year OpenAI agreement reported above twenty billion dollars, and an AWS partnership.

So the “no comparable partner” version of the argument collapses on contact with a week of news.

The defensible version is about density, not exclusivity. No competitor currently matches the combination of Nvidia’s hardware breadth, software velocity and cross-environment reach with an operational control layer engineered for sovereign and security-sensitive deployment. Nvidia’s advantage is that its many relationships all reinforce the same platform, whereas its competitors’ relationships are individually strong and collectively fragmented.

Player Strength Weakness against the combination
AMD Competitive hardware, improving software, aggressive partnering Less mature operational and enterprise software ecosystem
Google Vertically integrated TPU, Gemini, BigQuery, Vertex stack Cloud-centric, not a neutral cross-cloud platform
AWS Distribution, enterprise relationships, breadth of services Trainium ecosystem is less portable outside AWS
Cerebras Extremely fast specialised inference, now well partnered Narrower workload coverage, smaller deployment ecosystem
Nvidia with Palantir Cross-cloud and on-premises compute plus governed operational AI Expensive, and Palantir is not exclusive to it

There is a second mechanism worth naming, because it is where the commercial value actually sits. In large organisations, hardware is often specified indirectly by the application and the implementation partner. If a sovereign AI architecture is validated and optimised around Nvidia, an agency or manufacturer adopting it ends up buying Nvidia GPUs, Nvidia networking, certified systems and the enterprise software stack, while believing it is buying an operational application. The implementation partner becomes a distribution channel, and displacing it requires more than a cheaper accelerator: a competitor must displace a validated combination of hardware, software, ontology, security controls, workflows and implementation expertise.

That is an architecture moat rather than a contract, and it is reinforced by a loop. Deployments in defence, manufacturing, healthcare, energy and logistics surface constraints that benchmark-driven vendors never see: which agent workflows actually produce useful results, where latency genuinely matters, which actions need human approval, how permissions should propagate through agents, which models must run locally, and how systems fail under real operating conditions. That evidence guides hardware and library priorities, the improvements get packaged into new operational applications, and the combined system becomes easier to sell and harder to replace.

Whether it becomes durable depends on accumulation rather than announcement: validated reference architectures, security certifications, reusable industry workflows, tuned agents, operational evaluation datasets, long-lived deployments, trained implementation staff, procurement frameworks, real integration switching costs, and evidence of better business outcomes. If those accumulate, a rival cannot win with a faster inference benchmark, because the customer would have to revalidate an entire institutional system and accept fresh operational risk to switch.

Part seven: where the moat actually sits for the customer

Step back from the vendors, because the most important conclusion is not about them.

The enterprise’s durable advantage will not be owning a particular model. Models improve, converge and become interchangeable, and this is the one prediction in this piece that seems safe. The advantage is the combination of proprietary data, trusted relationships, domain expertise, workflow design, evaluation history, expert corrections, regulatory permissions, integration with physical operations, accumulated agent memory, and evidence that the system produces better outcomes than the alternative.

Every one of those is an asset that can be accumulated inside your own boundary or surrendered upstream, and the choice is made by architecture rather than by policy. A company that routes all of it through a single frontier provider gains convenience now and weakens both its negotiating position and its differentiation later. It is a trade that looks free for as long as the provider stays out of your market.

What the control layer has to do

If the conclusion is that the enterprise keeps memory, permissions, orchestration and feedback, then something has to implement that. Stated as requirements rather than as a product, the control layer must:

None of this is exotic. It is the same list every organisation eventually writes down after it has connected a few agents to a few systems and asked what would happen if one of them misbehaved.

Bottom line

The weak form of the argument is that OpenAI and Anthropic will steal customer data and hand it to competitors. That claim is not supported by their published commercial terms, and leading with it invites a rebuttal that ends the conversation.

The strong form is this. Even when frontier labs honour confidentiality and do not train on enterprise content, close exposure to customer workflows, demand patterns and integration requirements teaches them which vertical products to build. They have already built several. Enterprises therefore have a rational incentive, independent of trust, to keep proprietary data, memory, orchestration and outcome feedback under their own control.

The strategic risk is not theft. It is gradual vertical encroachment and accumulating dependency, and the answer is not abstinence.

Use the frontier models. They are extremely good and will remain, for some tasks, indispensable. Use them as replaceable reasoning components inside a system you control, consulted with the minimum context required, holding none of your persistent state. Keep the memory, the permissions, the orchestration, the evaluations and the feedback loop on your side of the boundary.

Not because the labs are adversaries. Because a system designed to survive the possibility that they might become adversaries is also a better system for every other reason: it is portable, it is auditable, it is resilient to outages and policy changes, and it compounds its advantages in your favour rather than someone else’s.