Full text · 36,856 chars
Your Company’s Best AI Workflow Is a Business Asset
The AI does not need to put your recipe into a public model to process it, retain it, review it, and turn it into product knowledge.
Imagine that a company has spent years learning how to acquire customers, price its work, classify information, handle exceptions, and decide what must be checked before anything is published. That method may never appear in a patent. It may not even exist in one document. It lives in the sequence of operations, the private vocabulary, the thresholds, the shortcuts, the files, the scripts, and the judgment of experienced people.
That is a business recipe.
Now put the recipe into a cloud AI assistant. Give the assistant your internal Skills, custom instructions, code, files, connected applications, browser state, and examples of the decisions you want it to reproduce. The assistant becomes more useful because it can see more of how the company works.
Then a reassuring sentence in their Terms of Service: “Your data is not used for training.”
That sentence may be true and still leave the central risk unresolved.
A provider does not need to put a raw workflow into a shared foundation model to receive, retain, review, classify, evaluate, summarize, or derive value from that workflow.
This is not a claim that OpenAI, Anthropic, or Google secretly train on every prompt or copy every customer into a public model. I found no evidence that supports that universal accusation. The documented concern is narrower and more serious: the valuable context can enter a provider-controlled system through several paths that the word “training” does not describe.
Google is unusually explicit about many agent and connected-app data paths. That makes its system easier to audit. It does not make the system harmless. Anthropic and OpenAI are not safer merely because a user has to assemble their disclosures from a privacy policy, a product page, a feedback rule, an API retention table, and a separate agent document.
In fact, fragmented documentation creates its own risk. A user can read “not used for training” on one page and miss the five-year feedback rule, the safety exception, the default abuse log, the prompt cache, the hosted container, or the legal hold described somewhere else.
The investigation therefore asks the same questions of all three companies:
- What can enter the provider’s systems?
- What can be retained, reviewed, classified, evaluated, or sent to a contractor?
- What can still happen after a user turns off model improvement?
- Which protections apply only to a particular account tier, endpoint, region, or product?
- What could a provider learn about a business without ever placing its raw recipe into a general model?
A company recipe is larger than a prompt
The mental model of a prompt is too small for an agentic system. A proprietary workflow may include:
- system prompts, custom instructions, Skills, saved preferences, and project files;
- the order in which tasks are performed;
- quality gates, failure conditions, and exception handling;
- customer names, segmentation logic, pricing rules, or internal thresholds;
- source code, scripts, documents, images, spreadsheets, and knowledge bases;
- tool calls, MCP servers, connector permissions, browser pages, cookies, and schedules;
- screenshots, screen captures, model-step information, retries, errors, and action history;
- the final answer, the rejected answers, and the feedback explaining why one was accepted.
A single prompt can be disposable. A repeated workflow can be a compressed operating manual.
When an agent runs inside a repository, a browser, a connected drive, or a remote computer, the exposure object is no longer just the text typed into a chat box. It is the environment needed to complete the task.
Five different questions are hiding inside “not used for training”
Foundation-model training
What it actually asks: Did this material enter a dataset used to update model weights?
Why the training answer is insufficient: This is important, but it is only one route to provider value.
Service improvement
What it actually asks: Can the provider use content to improve products, classifiers, evaluations, routing, or safety systems?
Why the training answer is insufficient: “Training” may refer only to generative model training, not every internal improvement process.
Operational telemetry
What it actually asks: What usage, latency, reliability, error, and performance data are collected?
Why the training answer is insufficient: Telemetry can optimize a product even when it contains no raw prompt.
Access and review
What it actually asks: Can employees, contractors, support teams, safety reviewers, or subprocessors see the material?
Why the training answer is insufficient: A human does not need to update model weights to understand a business method.
Retention and disclosure
What it actually asks: Where do logs, files, caches, memories, derived data, backups, and legal holds live?
Why the training answer is insufficient: Deletion of a visible chat is not necessarily deletion of every derivative or preserved copy.
Anthropic is not the clean comparison
Anthropic’s public identity is built around AI safety. Its current privacy documents nevertheless provide some of the clearest evidence that user data can become part of a model-development and safety-improvement pipeline.
Anthropic’s Privacy Policy is marked effective July 8, 2026. It lists data that users or crowd workers provide, including Inputs and Outputs from Anthropic’s Services unless users opt out, among the sources used to train its models. It also lists feedback, materials flagged for safety, security, or policy review, and internally generated data.
Anthropic’s own current policy does not describe user content only as a temporary input needed to answer a question. It describes user Inputs and Outputs, feedback, and safety-flagged materials as potential training sources, with opt-out settings and exceptions.
The same policy says Anthropic may use Inputs and Outputs to train and improve its models unless the user opts out. It then gives two important exceptions: conversations flagged for safety review, and materials explicitly reported through feedback mechanisms.
Anthropic’s Consumer Terms, effective October 8, 2025, state that Materials may be used to provide, maintain, improve, and develop products and services, including training models, unless the user opts out. The Terms also preserve training use when the user provides Feedback or Materials are flagged for safety review.
That is not a secret-training allegation. It is a documented data-use design.
How a conversation could become a learning signal
Anthropic does not publish a public, prompt-by-prompt diagram showing exactly which user conversation becomes which training example. We should not invent one. The policy does identify the categories that can enter the pipeline, and Anthropic’s technical papers show the general methods by which feedback can become model-improvement data.
- Service interaction: the provider receives the prompt, files, tool context, and model output required to answer the task.
- Selection and filtering: feedback, safety flags, reports, and operational failures identify material that may be useful for review or improvement.
- Annotation or comparison: a human or another model can critique an answer, compare alternatives, label a failure, or create an evaluation example.
- Post-training: preference data can train a reward model, fine-tune a model, build an evaluator, improve a safety classifier, or generate synthetic training material.
- Deployment learning: usage, latency, reliability, and error patterns can change routing, tooling, thresholds, or product design without changing the model weights.
Anthropic’s published papers on helpful and harmless assistants trained with human feedback and Constitutional AI using AI feedback establish that feedback and preference signals are normal technical ingredients in modern post-training. They do not prove that a particular user’s Claude conversation entered a model. Anthropic’s current privacy policy supplies the additional fact that user Inputs and Outputs, feedback, and safety-flagged materials can be sources for model training under its stated settings and exceptions.
The unresolved questions are exactly the questions a serious customer should ask: what fraction of content is selected, which products are included, how de-identification works, who decides that a conversation is useful, how training examples are removed, and whether derived evaluations or synthetic examples survive deletion. Anthropic’s public documents do not answer all of them.
The Claude Code documentation makes the trust boundary concrete
Claude Code is closer to a company’s operating system than a normal chat window. Anthropic’s current Claude Code data-usage documentation describes several separate paths:
- Consumer Free, Pro, and Max users can allow their data to be used to improve future Claude models, including when Claude Code is used through those accounts.
- Consumers who allow model improvement have a five-year retention period. Consumers who do not allow it have a 30-day retention period.
- Claude Code /feedback ,/bug , and/share transcripts are retained for five years.
- An optional follow-up asking Anthropic to inspect a session can upload the conversation transcript, subagent transcripts, raw session log, source code, file contents, and other conversation content as-is. The documentation says those shared transcripts are retained up to six months.
- Claude Code on the web clones a repository into an Anthropic-managed isolated virtual machine. Prompts, code changes, and outputs follow the account’s data policy.
- Local Claude Code sends all user prompts and model outputs over the network to the selected model provider. Local clients store session transcripts in plaintext under ~/.claude/projects/ for 30 days by default to support session resumption.
- For direct Claude API use, Claude Code sends operational metrics including latency, reliability, and usage patterns to Anthropic and third-party logging infrastructure. The documentation explicitly says those metrics do not include code, prompts, or file paths.
- The WebFetch safety check sends requested hostnames to Anthropic’s API even when another model provider is being used. The full URL and page contents are not sent for that check, but the provider still sees the hostname unless the check is disabled.
The last two points are where the speed hypothesis needs precision.
Does Anthropic receive speed-related telemetry?
What the evidence supports: Yes. Latency, reliability, and usage-pattern metrics are documented, and metrics are on by default for direct Claude API use unless disabled.
What it does not support: It does not show that the metrics contain prompts, code, or file paths.
Can those metrics improve the service?
What the evidence supports: Reasonably, yes. They can inform capacity planning, routing, reliability work, feature prioritization, and product optimization.
What it does not support: There is no public evidence that latency metrics alone reconstruct a company’s proprietary recipe.
Does Claude Code send the workflow content?
What the evidence supports: Yes, the prompts, outputs, and task context required for model operation cross the selected provider boundary. Feedback and model-improvement paths can add further use.
What it does not support: A fast response does not prove that Anthropic extracted the raw content for training.
The responsible conclusion is not “Anthropic’s speed proves data extraction.” The responsible conclusion is more uncomfortable: Anthropic has a documented learning pipeline for consumer content, a documented retention and feedback pipeline, and a documented operational telemetry pipeline. The public evidence does not tell us that latency data contains the recipe. It does show why “the model is fast” cannot be treated as evidence of privacy.
Commercial Anthropic is different, but not provider-blind
Anthropic’s Commercial Terms, effective June 17, 2025, are stronger than its consumer terms. They say commercial Inputs and Outputs are not used to train generative models by default unless the customer provides the data for model improvement, such as through the Development Partner Program. They also define Customer Content as confidential and limit Anthropic’s rights to what is reasonably necessary to provide the service.
Those protections matter. They should not be converted into a fantasy of local sovereignty.
- The service still has to receive and process the code, prompts, files, and outputs.
- Confidential information can be disclosed to people who need to know, and disclosures can be required by law or court order.
- Standard commercial retention is a separate question from model training.
- Zero data retention is not automatically included in standard Enterprise. Anthropic’s Claude Code documentation says qualified Enterprise accounts need it enabled per organization by the account team.
- Product behavior differs across Anthropic’s own API, Amazon Bedrock, Google Cloud’s Agent Platform, Microsoft Foundry, and Anthropic-hosted services.
The commercial contract is a meaningful guardrail. It is not evidence that no Anthropic system, subprocess, safety classifier, support workflow, or connected provider can process the material.
OpenAI is not the safe opposite
OpenAI’s public documentation creates a different kind of risk: the strongest protections are often associated with business accounts, APIs, approvals, and endpoint-specific controls, while consumer ChatGPT and Codex have broader model-improvement and feedback paths.
Consumer ChatGPT and Codex
OpenAI’s current Help Center material says that individual services such as ChatGPT improve through further training on conversations unless the user opts out. The same page says OpenAI may use content from ChatGPT and Codex to train its models. Users can opt out for new conversations and Codex tasks, but the opt-out has a documented exception: if a user provides feedback, the entire conversation associated with that feedback may be used to train models.
That is an important design choice. A user can turn off model improvement, submit a thumbs-down report because an answer exposed a problem, and thereby make the associated conversation available for training. The interface presents a rating. The policy describes the entire associated conversation.
OpenAI’s own model-improvement page describes the value directly: the company says models improve through exposure to real-world problems and data, and that permitted user content helps models become more accurate at specific problems while improving general capabilities and safety. This is not proof of malicious extraction. It is a first-party explanation of why real user interactions have economic and technical value to the provider.
OpenAI’s consumer documentation also describes authorized OpenAI personnel and trusted service providers accessing content for abuse or security investigations, support, legal matters, or model performance where the relevant setting permits it. Content may be stored on OpenAI systems and trusted service-provider systems in the United States and around the world. The same material says selected portions may be sent to service providers for annotation and safety purposes.
OpenAI’s retention documentation adds more layers:
- Chats remain in an account until deleted.
- Deleted chats are scheduled for permanent deletion within 30 days, unless they were already de-identified and disassociated or must be retained for security or legal reasons.
- Files can live in a Library separately from the chat that referenced them.
- Files attached to custom GPTs and projects can remain until the GPT or project is deleted.
- Temporary Chats are automatically deleted within 30 days, but “not used for training” is still not the same as “never processed.”
OpenAI business and API protections are real, then the footnotes begin
OpenAI’s Business Terms are effective January 1, 2026. They say Customer Content is used only as necessary to provide the services, comply with law, enforce policies, and prevent abuse. They also say OpenAI will not use Customer Content to develop or improve the services unless the customer explicitly agrees.
This is a meaningful contractual difference from consumer ChatGPT. It is also not a provider-blind environment.
The same terms allow necessary rights for subcontractors and subprocessors. They allow OpenAI to use and exploit Feedback without restriction or compensation. Termination requires deletion within 30 days, but legal retention and abusive-content exceptions remain. Customer Content can be processed by the infrastructure required to deliver the service, and confidential information can be accessed by people who need to know under the agreement.
The current OpenAI API data-controls documentation is more concrete than the marketing phrase “API data is not used for training.” It says:
- Abuse-monitoring logs may contain prompts, responses, and metadata derived from customer content, such as classifier outputs.
- Those logs are generated for all API feature usage by default and retained for up to 30 days, with longer retention when required by law or reasonably necessary to protect the service or a third party from harm.
- Zero Data Retention and Modified Abuse Monitoring require prior OpenAI approval and acceptance of additional requirements.
- Even approved controls have exceptions for application state, rare image and file inputs, safety retention, and severe-risk investigations that may include human review.
- Prompt caching can retain encrypted key-value tensors on GPU-local storage for up to 24 hours.
- The Responses API can retain application state for at least 30 days by default.
- Hosted Skills and hosted containers have their own lifecycle and storage behavior.
- Remote MCP servers are third-party services whose retention policies apply to data sent to them.
- Computer-use image and file inputs are scanned for safety. Potential child sexual abuse material matches can be retained for manual review even when Zero Data Retention or related controls are enabled.
- Data residency does not cover all system data, metadata, usage data, analytics, support requests, billing information, or other non-content information.
This is not secret training. It is a documented operational surface that a business must govern endpoint by endpoint.
Codex changes the size of the boundary
OpenAI’s current Codex security documentation says Codex Cloud runs in isolated OpenAI-managed containers. The local product uses OS-level sandboxing and approval policies, while cloud tasks run in a provider-managed environment. Local Codex telemetry is off by default, but when enabled it can cover chats, API requests, user prompts if explicitly logged, approval decisions, and tool results.
The Help Center also says Codex has separate controls for allowing training on full environments, and that changing the ordinary ChatGPT interface or privacy-portal setting does not change those Codex controls. The important distinction is not that every Codex trace is secretly used for training. The distinction is that a cloud coding agent needs workspace context to perform useful work. The codebase, instructions, tool results, and action history become part of the trust boundary. The same “not training” sentence cannot make a remote container local.
Legal retention is a real counterexample to simple deletion language
OpenAI’s public response to The New York Times describes an earlier legal order requiring indefinite retention of consumer ChatGPT and API data until September 26, 2025. OpenAI later said a historical April through September 2025 set remained locked under legal hold, and described a request for a random sample of 20 million consumer conversations from December 2022 through November 2024. OpenAI says the data was limited to legal obligations and that business, Enterprise, and API customers were excluded from the sampling described there.
This is provider-reported evidence, not independent proof of training. It does establish the practical limit of a deletion promise: litigation can create a separate preservation regime. A privacy policy can say “delete within 30 days,” while a legal hold creates a controlled copy that is not deleted on that schedule.
Google is clearer, and still dangerous
Google’s documentation is the clearest illustration of the operational context an agent can receive. It is also the place where the earlier article made its biggest comparison mistake. Clarity is not innocence.
Consumer Gemini exposes the environment around the prompt
Google’s current Gemini Apps Privacy Notice is dated June 29, 2026, and the Gemini Apps Privacy Hub reports that it was last updated August, 2026. It describes data such as prompts, uploads, generated content, information about technology steps, feedback, usage information, browser and device data, Connected Apps, and interactions with Gemini features.
Its agent documentation is especially important for a business recipe. It explicitly discusses Skills, Gems, saved instructions, MCP tools, connected applications, remote-browser cookies, screen captures, code, remote-computer files, schedules, logged-in websites, and sensitive information retrieved through connected services.
Gemini Spark makes the boundary even more concrete. Google says Spark can use task context, schedules, Skills, Connected Apps, remote-browser cookies and page content, logged-in websites, and remote-computer files. On macOS it can interact with local files placed in connected folders. The remote computer can save and execute Markdown files, code, and other task information. Google says this data can be used to make future chats easier, and that necessary information may be shared with other services and third parties. Deleting ordinary Gemini Apps Activity does not delete or control remote-browser and remote-computer data; Spark has separate settings for that data.
Google says that when Keep Activity is off or temporary chats are used, relevant data can still be retained for 72 hours so Gemini can respond and protect Google, users, and the public. It also says temporary chats are not used to train Google’s AI models, and that future chats with Keep Activity off are not used to improve AI unless the user submits feedback. Feedback can include the feedback itself, the last 24 hours of context, uploads, and Connected App data. Google says reviewed feedback-related data can be retained for up to three years and disconnected from the account.
Google also explicitly says Gemini Apps chats are not used to show ads. That is a meaningful counterweight to exaggerated claims about advertising surveillance. It does not erase the separate service-improvement, human-review, Connected Apps, Spark, safety, retention, and technical-metadata pathways documented on the same Hub.
That is not a small privacy footnote. It means a user can submit one rating and create a larger review package containing the context that produced the answer.
The Google API comparison needed correction
The old simple table said unpaid API content could be used for improvement while paid API prompts were excluded. The current documents require more precision.
Gemini consumer apps
Current documented position: Consumer activity settings, feedback, safety, connected apps, and agent features have separate rules.
Risk that remains: Skills, browser state, cookies, files, code, screenshots, human review, feedback retention, and 72-hour temporary storage can still matter.
Unpaid Services
Current documented position: Google’s API Terms allow submitted content and generated responses to be used to provide, improve, and develop services and machine-learning technologies. Human review is possible. The terms cover prompts, system instructions, cached content, files, and responses.
Risk that remains: Do not send proprietary workflows through an unpaid path unless that use is deliberate.
Billing-enabled API logs
Current documented position: Google’s Logs Policy says logs are private to the Cloud project and, by default, are not used for product improvement. The default maximum retention is 55 days, configurable down to 7 days.
Risk that remains: Logs still exist for operation, safety, abuse, debugging, and governance. Users can opt in to share logs or datasets for improvement.
Paid Services
Current documented position: Prompts and responses are excluded from product improvement under the API Terms.
Risk that remains: Safety and legal logging, technical metadata, usage, performance, errors, identifiers, IP information, and grounding-specific storage remain. Third-party services have their own rules.
Shared datasets
Current documented position: Google says shared datasets can be used for model training and evaluation and may have no set retention period.
Risk that remains: An explicit sharing decision can create a longer-lived training and review path than ordinary request logs.
The corrected conclusion is not “Google is safe because it tells you more.” It is: Google tells you more about a serious surface, while OpenAI and Anthropic often distribute comparable questions across product pages, support documentation, approvals, and exceptions. A clearer warning is not a smaller warning.
The company does not need to steal the whole recipe
It is tempting to imagine a dramatic theft: an engineer at a provider copies one complete workflow and launches a competing company. That scenario is possible in the abstract, but it is not the only way a provider can benefit.
Provider value can arise through smaller and more ordinary mechanisms:
- Product intelligence: repeated tasks reveal which workflows people need, where the model fails, and which features customers will pay for.
- Evaluation data: feedback, safety flags, support reports, and quality reviews can turn real edge cases into tests, annotations, or improvement targets.
- Operational learning: latency, reliability, usage patterns, and error data can optimize capacity, routing, pricing, and feature design.
- Workflow reconstruction: a provider may see enough partial signals across prompts, files, tools, and retries to infer priorities without holding one document titled “our business recipe.”
- Strategic exposure: unreleased product plans, pricing experiments, customer problems, internal vocabulary, and automation choices can reveal where a company is going.
- Model capability improvement: when content is actually allowed into a training, feedback, safety, or evaluation path, the model or its surrounding systems can improve from the real-world example.
None of these statements proves that a provider systematically identifies and commercializes every user’s workflow. They describe why the risk cannot be reduced to a binary question about model weights.
Where the speed hypothesis fits
The user’s suspicion is understandable: cloud providers offer enormous usage, fast responses, and sometimes heavily subsidized access. They are not doing this as a charitable exercise. The services have multiple value streams, including subscription revenue, API revenue, enterprise contracts, feedback, usage patterns, and real-world problem exposure.
That is an economic inference, not a clause saying “we sell your recipe.” The provider documents are more specific than that. Anthropic says Claude Code collects latency, reliability, and usage-pattern metrics. OpenAI describes classifier outputs, performance data, prompt caching, application state, and service analytics. Google describes usage, performance, safety, and connected-service information.
The evidence supports three levels of conclusion:
Confirmed: providers collect operational data and, depending on product and settings, can use content for model development, feedback, safety, evaluation, support, or abuse prevention.
Reasonable inference: operational data can optimize latency, routing, capacity, product quality, and feature design. Repeated use can reveal workflow structure even when the raw text is not in a training dataset.
Not established: latency metrics themselves are a covert channel for extracting a company’s raw recipe. A fast response is not proof of hidden training or deliberate theft.
The strongest investigative question is therefore not “Can I prove they stole my workflow?” It is “Why would I give a concentrated AI company the opportunity to learn from a workflow that gives my company an advantage?”
Incidents and technical research show why the risk is practical
There are three different kinds of evidence here, and they should not be mixed.
Exposure incidents
In 2023, Samsung employees reportedly submitted sensitive source code and other internal material to ChatGPT. The incident did not prove that OpenAI trained on Samsung’s code. It proved that employees can move proprietary material into a cloud AI workflow before a company has built a boundary around it.
OpenAI’s own report on the March 20 ChatGPT outage described a period in which some users could see titles from another user’s chat history and some users had limited payment-related information exposed. That did not prove training. It demonstrated that cloud AI is software with operational failure modes, database boundaries, and incident-response risk.
Training-data extraction research
Carlini and colleagues demonstrated that large language models can memorize and reproduce verbatim sequences from training data, including code and personally identifying information. Later work has explored scalable extraction and membership inference.
This produces a conditional risk, not a verdict about a particular provider: if sensitive customer material enters a training path, memorization and extraction become relevant concerns. The research does not show that ordinary opted-out workflows entered the training data of OpenAI, Anthropic, or Google.
Deletion is not one event
Visible conversation
Question that must be answered: Did the chat disappear from the user’s account?
Files and projects
Question that must be answered: Did separate Library, project, custom-agent, or repository files disappear too?
Operational logs
Question that must be answered: Were abuse, safety, classifier, support, or error logs deleted?
Caches and application state
Question that must be answered: Were prompt caches, hosted containers, vector stores, embeddings, or response state removed?
Human copies
Question that must be answered: Were reviewer, annotation, support, or feedback copies removed?
Derived data
Question that must be answered: Were summaries, labels, evaluations, or synthetic examples removed?
Legal preservation
Question that must be answered: Was every legal hold released, and which retention promise governed the hold?
Model influence
Question that must be answered: If data already entered training, can its effect be removed from model weights?
Most consumer interfaces answer only the first question.
Anthropic says opting out does not remove data already used in training or its influence on models already trained. OpenAI and Google document legal, safety, and operational exceptions. The existence of these exceptions does not mean every provider keeps everything forever. It means a user should not treat a settings toggle as a complete deletion certificate.
Why local AI changes the trust boundary
This is why I do not see Local AI as a nostalgic preference or a rejection of useful cloud models. I see it as a boundary decision.
When inference runs locally, raw business context can remain inside infrastructure I control. That does not create perfect privacy. Endpoints can be compromised. Local administrators can access files. Logs can leak. A browser extension can upload data. A connector can cross the boundary. Backups, model updates, physical access, and remote administration still need governance.
Local inference changes the default, though. A cloud provider does not automatically receive the raw files, private Skills, tool traces, and workflow just because I asked a model to work with them.
My practical setup is local-first: the Mac Mini remains the canonical Hermes and Telegram gateway, while the MX Linux machine provides the local AI station. A local Qwen 27B-class model runs through llama-server on the MX system. The exact model is less important than the data path. The goal is to keep the raw business context, private files, and proprietary workflow Skills on infrastructure that is under my control.
Hybrid AI is more realistic than local-only
I still want frontier cloud models when they are genuinely better at a bounded task. The answer is not to pretend that one local model will beat every specialized service at everything. The answer is to split the workflow.
- Local ingress: receive the raw files, customer context, private Skills, credentials, and proprietary workflow locally.
- Local classification: decide whether the task is public, disposable, sensitive, or strategically differentiating.
- Local preparation: remove names, credentials, customer identifiers, proprietary thresholds, and unnecessary raw material.
- Cloud gateway: send only a sanitized task, schema, abstract plan, or bounded question when the benefit justifies it.
- Local execution: use local tools or a local model to apply the result to the real files and environment.
- Local validation: check the output against local rules and keep the audit trail locally.
- Explicit escalation: require a deliberate decision before more context crosses the boundary.
Public information and disposable brainstorming
Default path: Cloud acceptable
Reason: The material is not strategically sensitive.
Low-risk drafts and sanitized summaries
Default path: Hybrid
Reason: Cloud reasoning can help without receiving the original context.
Operational workflows and proprietary Skills
Default path: Local by default
Reason: The sequence and decision rules are the valuable asset.
Credentials, customer data, private code, strategy, and business thresholds
Default path: Local only
Reason: The cost of exposure is higher than the convenience of remote reasoning.
Sanitization is not magic. A clever model can infer more than a redaction tool expects. The objective is reduction: if the cloud receives an abstract task instead of the entire business context, it has less material from which to reconstruct the recipe.
What I will and will not trust
I will trust a provider more when the contract and product documentation answer these questions directly:
- Are raw inputs and outputs excluded from all model training, including safety and evaluation models?
- Can a feedback action attach the entire conversation?
- Are agent traces, screenshots, browser state, tool outputs, and action histories retained?
- Which employees, contractors, subprocessors, and connected services can access the material?
- What happens when content is flagged for safety?
- What happens when support or legal teams need access?
- Are embeddings, caches, memories, hosted containers, and derived summaries covered?
- What survives deletion, backup, and legal hold?
- Can the provider certify deletion and identify every endpoint used?
- What is the remedy if a proprietary workflow is exposed?
“Not used for training” is useful information. It is not a complete answer to these questions.
My position
I am not leaving AI. I am changing where I allow the valuable context to live.
Cloud AI is useful. Frontier models can solve problems that local systems sometimes cannot. But usefulness does not create confidentiality, and a privacy setting does not automatically create a trust boundary.
My rule is local first, hybrid when it earns its place, and cloud only with a deliberate data boundary.
The most valuable part of my work is not the answer generated by a model. It is the system that knows what to ask, what to ignore, what to verify, and what to do next.
That system is the recipe.
The question I want to leave you with
If your AI assistant knows how your business works, where does that knowledge live?
Do not answer only with the word “training.” Ask which systems received it, which people could review it, which traces remain, which exceptions apply, and whether you needed to send the whole recipe at all.
This article does not claim that any provider routinely steals every customer’s business model. It argues for a stricter trust boundary because the documented systems already expose more than the word “training” suggests.
Transparency note: This article was written and reasoned by Manolo Remiddi. The Resonant Augmentor (AI) assisted with research, editing and clarity. The image was also AI-generated.