Nvidia and Palantir pulled back from frontier AI. Here’s what they know that you don’t.

What actually happens, from chat to agent

A chat question. The model is far too large to run on your laptop, so your question is sent over an encrypted connection to the AI company's servers, or to a cloud provider hosting the model for them. It goes with the whole conversation so far and any files attached. The bundle is run through the model on racks of GPUs in a datacentre, the answer comes back, and along the way separate systems may scan the exchange for abuse and the company logs it. One human decision, one request, one copy.

An agent doing a task. Tell an agent to "chase the overdue invoices" and something different happens. It queries your finance system, reads the customer records, opens the email threads, drafts the messages, maybe sends them, and reports back. Each of those is a separate request to the model, and each request carries the data the agent pulled from your systems, not data a human chose to paste. A single task can mean dozens of model calls, each one a copy of something that lives inside your business.

Three things change when the agent, not the person, decides what to send. The volume goes up by orders of magnitude. The selection is made by software against whatever permissions it was given, not by someone's judgement about what is sensitive. And the agent takes actions in your systems, so the record of what it did is as important as the record of what it saw.

Where your data actually goes

Whether sent by a person or an agent, the data is almost always stored, at least for a while. What happens next depends on which door it went through, and agents add a door most organisations have not mapped.

Consumer apps (free tiers and personal subscriptions). Conversations are saved to your account and typically kept for a period after you delete them. Most providers reserve the right to review flagged conversations for abuse. Whether your chats train future models varies by company and by setting: some train by default unless you opt out, some ask you to opt in, and the policies change. This is the door most people use at work without realising it is the weakest one.

Business and enterprise plans. These are sold with a contractual promise that your data is not used for training, plus controls over retention, access, audit and where data is stored. If your organisation has a paid AI contract, it almost certainly has better terms than the personal app on your phone.

API access (developers building products). Data sent through the API is usually excluded from training by default, with short retention windows for abuse monitoring. Some providers offer zero-retention arrangements for sensitive workloads.

Third-party apps built on these models. When a tool "uses Claude" or "is powered by GPT", your data passes through that app's company first. Their privacy policy governs what they keep; the model provider's policy only covers the hop to the model and back. Many breaches of AI data will not be the model provider's fault at all.

Agent platforms and connectors. This is the new door. An agent typically runs on a platform (the model provider's own, a cloud vendor's, or a startup's), connects to your systems through integrations, and may hand sub-tasks to other agents or tools. Data now flows through the model provider, the agent platform, each connector, and any third-party tool the agent calls, each with its own retention and logging. Ask who holds the record of a given step and the honest answer is often several companies, or nobody in a form you could produce to an auditor.

Human review. Even with no training, a small fraction of conversations may be seen by people: for safety enforcement, debugging, or where you reported a problem.

Location. Most frontier models are served from datacentres in the United States, with growing options in the EU and elsewhere. If data residency matters to you (GDPR, client confidentiality, regulated sectors), it is a question to ask, not assume.

The risks nobody briefs you on

The risk is not that the model will remember your secret and tell your competitor. The risk is that copies of your data now exist in places you don't control, created by software at a rate no person could review, and that for a regulated business you may be unable to show what happened.

• Pulling replaces pasting. A person pastes one document. An agent with access to a shared drive can read ten thousand. The judgement call that used to protect you, someone deciding not to share the client file, is gone unless you rebuilt it as a permission.
• Over-permissioned by default. Agents are usually set up with the access of the person who installed them, because that is easiest. That person's inbox, drives and systems become the agent's reach, and so become data that can leave.
• Retention is exposure over time. Data that is kept can be breached, subpoenaed, requested in litigation discovery, or swept up in a regulatory investigation. A conversation kept for 30 days is a 30-day exposure. An agent's logs, multiplied by every step it took, are a far larger surface kept for the same period.
• Training is a one-way door. Data used to train a model cannot be deleted afterwards. No later opt-out gets it back. That is why the training setting matters more than any other single control, and why it must cover the agent platform and connectors, not just the model.
• The audit gap. Regulators in financial services, healthcare, law and the public sector expect you to show who accessed what, when, and why. That expectation does not pause because an agent did it. If the agent's reasoning, tool calls and actions are not logged in a form you can retrieve, you have a process you cannot evidence.
• Actions, not just text. An agent that can send email, update a record or move money creates records in your systems and theirs. When something goes wrong, you need to reconstruct the chain: what it read, what it decided, what it did. Few deployments can.
• Shadow agents. Staff connect personal AI accounts to work systems because the official tool is slower or does not exist. The organisation then has no idea what has left the building, under consumer-grade terms it never agreed to.
• Confidentiality and privilege. Routing privileged legal advice, confidential client material or personal data through a chain of third parties can weaken privilege or breach your own duties, regardless of what any provider does with it.

Who has already pulled back, and why

None of these need a malicious provider. They need only ordinary stored data, ordinary over-broad permissions, and ordinary bad luck.

This is not a theoretical worry. Some of the most technically sophisticated companies in the world have looked at where their data goes and changed course.

Samsung, 2023: the leak that started it. Engineers pasted confidential source code into ChatGPT to debug it, at a time when the consumer service could use submitted content to improve the model. Samsung banned the tool and said it would build its own internal AI instead. Apple, Amazon, JPMorgan and Bank of America restricted employee use around the same time, for the same reason: not that the model was bad, but that nobody could say where the pasted text ended up.

Palantir, Nvidia and Booz Allen Hamilton, 2026: the sophisticated buyers. According to reporting by The Information, summarised by VentureBeat in September 2026, all three have restricted their use of frontier models or demanded stronger contractual guarantees, over concern that proprietary information could ultimately benefit the AI companies supplying them. These are organisations with world-class security teams and enterprise contracts already in place. Their concern was not the absence of a no-training promise; it was whether a promise is enough, and what the metadata still collected under those contracts actually reveals.

The research "snoop-and-scoop" problem. The same VentureBeat piece describes disputes in which researchers using AI coding tools questioned whether their unpublished work could have influenced later AI-generated results. No transfer was proven, but the fact that it could not be ruled out is precisely the point: once your data has gone in, you are relying on someone else to tell you what happened to it.

The shift to models you can run yourself. Databricks, which sells hosting for both kinds of model, reported in November 2026 that its enterprise customers are routing a growing share of workloads to open-weight models they control, with data sovereignty and retention policy among the stated reasons. Its field engineers note that some frontier providers have changed their retention terms after customers had built compliance policies around the old ones, and that in one security incident a response team fed attack logs to an open-weight model after hosted frontier models refused. A vendor's blog is not neutral evidence, but the direction matches what the buyers above are doing.

The pattern across all of these is the same. Nobody moved because the frontier models stopped being good. They moved because they could not fully answer the question in the title of this article, and they decided that for their most sensitive data, not knowing was no longer acceptable.

The response from providers is telling too. OpenAI's September 2026 announcement of customer-controlled storage and hardware-attested safety review is an admission that "trust us, we don't train on your data" is no longer closing enterprise deals on its own. The market is moving from promises to proof.

Why retention, controls and audit are the whole game

You cannot stop data leaving your systems once an agent is connected to them. What you can control is how much leaves, what happens to the copy, and whether you can prove it afterwards. That comes down to a short list of contractual and technical controls, and for agents the list is longer than it was for chat.

• Training exclusion. The one that matters most. Non-negotiable for any business use, and it must cover the model, the agent platform and every connector.
• Retention period. Shorter is safer. Ask for the number of days, the exceptions (abuse flags, legal holds), and what happens on deletion. Then ask the same of every other company in the chain.
• Least-privilege access for the agent. Scope it to the systems and records the task needs, not the installer's full access. Review it the way you would review a new employee's permissions.
• Audit logs you own. Every tool call, every record read, every action taken, with timestamps, exportable to your own systems and retained on your schedule, not the vendor's. If you cannot produce this on request, do not deploy the agent on regulated data.
• Human approval gates. For actions with consequences (sending to clients, changing financial records, deleting anything), a person approves before the agent acts. The log records who.
• Provider access. Who at the provider can read your data, under what circumstances, and is that access logged.
• Data residency. Where the data is stored and processed, and whether you can choose a region.
• Identity and sub-processors. SSO, admin visibility of which agents are connected to what, and a named list of every company that touches the data, with notice when it changes.
• Deletion on exit. What is destroyed when you leave, and whether they will confirm it in writing.

Same model, completely different risk

The gap between a consumer chat app and a well-governed agent deployment is not a nice-to-have. On one side, data flows out at machine speed, may be retained for years, possibly trained on, under terms someone accepted by clicking, with no record you could hand to an auditor. On the other, it is excluded from training, deleted on a schedule you agreed, scoped to what the task needs, and every step is logged in a system you control. Same model, same productivity, completely different risk.

What to do on Monday

• 1. Inventory every agent and AI connector touching company systems, including the ones staff set up themselves. You cannot govern what you have not found.
• 2. For each one, write down three numbers: retention in days, who can access the data, and whether training is excluded. If any answer is "don't know", that is your first problem.
• 3. Cut each agent's permissions to what its task needs. Most are running with far more.
• 4. Confirm you can export a complete log of what each agent read and did, and that it lands in a system you keep. If you cannot, stop it running on regulated data until you can.
• 5. Decide what never goes through an agent: client identifiers, credentials, health data, unreleased financials, privileged advice. Write it down, enforce it with permissions, and tell people.

The productivity is yours to keep

None of this is a reason to avoid agents. It is a reason to treat them as what they are: software that moves your data to other companies at machine speed, under terms you may not have read, and acts in your name.

That is the problem Udal is built to solve. It installs inside your own environment — your cloud, your datacentre, or fully air-gapped — and puts every agent behind the controls this article asks for. Content is classified before it is sent, and policy decides which model may see it: routine and sensitive work stays on open-weight models you run yourself, frontier models stay available only where you have allow-listed them. Each agent's access is scoped to the task rather than inherited from whoever installed it. Actions with consequences wait for a human approval, with separation of duties. Every read, decision and action is written to an audit record you hold and can export. And where a control cannot be enforced, the agent fails closed instead of carrying on.

Use the door with the right controls and the right audit trail, and the productivity is yours to keep.