On-Prem AI for Your Business and Privacy

A Breakthrough With an Awkward Shadow

Navier–Stokes equations describe the movement of fluids such as air and water. The Millennium problem asks whether smooth three-dimensional flow can always remain smooth or whether it can develop a singularity, a point where the mathematical description breaks down. OpenAI says its system proved that a singularity can form in finite time under the official formulation it addressed.

Buckmaster and Alpöge's work was related, not identical. Reporting on the dispute has sometimes collapsed their forced Euler result, their broader research direction, and OpenAI's claimed Navier–Stokes solution into one story. That makes the accusation sound more settled than it is. OpenAI's published account says it began after hearing rumours that outside researchers were close to Millennium results, then used its own internal agents and intermediate results. It explicitly denies using the pair's specific private data.

Still, I understand why the episode rattled researchers. The same company can supply the tool, operate the infrastructure, observe at least some usage metadata, improve future systems, and become a competitor in the field where the customer is working. Even when a provider follows its stated policy, the customer has accepted a concentration of trust that would look extraordinary in almost any other research relationship.

For a business, replace an unpublished proof with an acquisition plan, a new drug candidate, a pricing model, or the customer list behind next quarter's launch. The discomfort becomes easier to feel.

The Frightening Version Needs a Correction

It would be inaccurate to say that OpenAI, Anthropic, or another provider can simply retrieve and reuse anything entered into every model. Products have different terms. OpenAI says business and API data is not used for training by default. Its standard API may retain some inputs and outputs for up to 30 days for abuse monitoring, while qualifying customers can use eligible Zero Data Retention endpoints. Access to stored business data is restricted under its published policy.

That correction should not make anybody casual. A hosted model has to process the information you send. Depending on the product, settings, provider, endpoint, tools, logs, and legal obligations, some of that information may cross systems or be retained. A consumer chat, a business workspace, an API with standard retention, and a contracted ZDR deployment are not interchangeable just because they display the same model name.

Here is the rule I would use inside a small business: if disclosure would expose a person's identity, move money, reveal credentials, break a contract, damage a negotiation, or surrender a genuine trade secret, do not paste it into an unapproved AI tool. Not once. One employee can copy a payroll sheet or a customer export into a convenient chat before management even knows the company has adopted AI.

Financial records and personally identifiable information need a documented route. The business should know the product tier, retention policy, training policy, subprocessors, region, access controls, deletion process, and what happens when a plugin or external tool receives the prompt. Privacy is a property of that entire route, not a promise attached to the model's name.

Keep the Sensitive Route Under Your Control

In a strict on-premises setup, the model weights, inference engine, retrieval index, logs, and business documents run on hardware the organisation controls. That hardware might be a workstation, an office server, a NAS with suitable compute, or a private cluster. The important point is that a prompt does not need to leave the controlled environment for the model to answer it.

This is the clearest route for material that should not reach an outside inference provider. It can also make retention and deletion easier to explain because the business owns the storage and access policy. An open model can be selected for the job, tested against a fixed version, and kept behind the same identity and network controls as other internal systems.

On-prem does not mean magically safe. Somebody still has to patch the server, protect model and document stores, manage accounts, encrypt backups, monitor access, and test what the application reveals. Local agents can leak data through web searches, email tools, analytics, error reporting, or careless logs. If the system can reach the internet, the privacy boundary must include every tool it can call.

There is also a capability and cost trade-off. A smaller local model may handle document search, classification, extraction, drafting, and routine internal questions well. It may not match the strongest hosted frontier model on difficult reasoning. Buying enough hardware to serve a large model quickly can make little sense for a small team with irregular demand.

Most Small Businesses Need a Hybrid

Not every business can operate its own GPU infrastructure, and most do not need to. A useful middle route keeps documents, permissions, retrieval, and workflow state inside a local or business-controlled system, then sends only the minimum information needed for a particular task to a hosted model. The business pays for the inference it uses and can choose between frontier and open models according to the job.

OpenRouter is relevant here because it supplies one API across many model providers, usage-based billing, and routing controls. Its Zero Data Retention setting can restrict a request to endpoints whose providers state that they do not retain prompts or responses. OpenRouter says it does not retain prompt content unless the customer opts into logging, and its documentation exposes provider-specific training and retention policies.

But the selected prompt and context do not stay on the local computer. They must travel through OpenRouter to the chosen inference provider so the model can process them. Local retrieval can reduce the disclosure by sending a few relevant passages instead of an entire database. Redaction can remove names, account numbers, and other identifiers first. Neither technique turns remote inference into local inference.

ZDR needs to be enforced, not assumed. OpenRouter notes that provider policies differ by endpoint and that plugins and tools can have separate retention rules. A fallback route can also weaken privacy if it silently sends a request to a provider with different terms. For sensitive workflows, provider allowlists, ZDR enforcement, blocked logging, regional requirements, and tool restrictions should be part of the configuration rather than a note in somebody's setup document.

Do Not Give Every Prompt the Same Route

The practical answer is rarely all-cloud or all-local. Public marketing copy does not need the same controls as bank details. An internal procedure is different from a medical record. A contract summary may be safe with names and values removed, while the original agreement remains on-prem. The architecture should follow the consequence of disclosure.

At Brownsmith Dynamics, we would begin by mapping the data and the task. Which fields are genuinely required? Can identifiers be removed? Does the model need the full document or a retrieved excerpt? Is a smaller local model good enough? If hosted inference is necessary, which provider and retention policy are allowed? What evidence will show where each request went?

This produces a usable split rather than a ban. Highly sensitive records and secrets remain local. Redacted or narrowly retrieved context can use approved ZDR endpoints when the capability gain justifies it. Public and low-risk work can use a broader selection of models. Employees get a sanctioned route instead of being told not to use AI and quietly opening a consumer account anyway.