Is It Safe to Use DeepSeek and Open-Weight Models at Work?

Using DeepSeek at work can be safe or unsafe depending on which DeepSeek you mean. Sending company data to the hosted DeepSeek app or API is mainly a data-jurisdiction and contract question, and many organisations will not be able to approve it for confidential data. Running DeepSeek's open weights on infrastructure you control removes that data flow, but leaves you responsible for model provenance, safety testing and serving security. The same split applies to every open-weight model family. Make the decision per model and per deployment path, then enforce it in routing.

Two different things called "DeepSeek"

A lot of confused policy comes from treating a model family as one product. There are really three ways people use it:

A ban on the first path is common and easy to justify. A ban on the third path is a different decision, because the weights do not send anything anywhere by themselves. Running them is closer to running any other third-party software.

The hosted app and API: a data-flow question

For hosted use, ask the same questions you would ask any SaaS vendor that receives confidential data:

• Jurisdiction. Which country's law governs the service, and could authorities there compel access to stored data?
• Terms. Does the service keep prompts, and may it use them to improve its models?
• Contract. Can you sign a data processing agreement that meets your obligations, for example under GDPR?
• Transfer rules. Does sending personal data to that country require a transfer mechanism your legal team can support?

If any of these answers is no or unknown, do not approve confidential data for that path. This is the same analysis behind data residency for AI agents, applied to one provider.

The practical problem is that a ban alone does not stop use. Employees who find a model useful will try it in a browser tab. You need visibility into which models are actually called, and a sanctioned alternative that is good enough to make the unsanctioned one unnecessary.

Self-hosted open weights: a supply-chain and safety question

Self-hosting changes the risk, it does not remove it.

Provenance. Weights downloaded from a model hub are an artefact like any other dependency. Confirm the publisher, pin the exact revision, record a hash, and prefer formats that do not execute code on load. The AI agent supply chain security post covers this in more depth.

Safety and robustness. Independent evaluations have reported that some open-weight models are weaker than leading closed models on safety-relevant tests. In September 2025, NIST's Center for AI Standards and Innovation (CAISI) published an evaluation of DeepSeek models and reported that they lag behind US models in performance, cost, security and adoption (NIST CAISI evaluation). Treat findings like this as a reason to run your own tests, not as a final verdict on every version or fine-tune.

Built-in bias and refusals. Models reflect the data and alignment choices of their developers. A model may answer some topics in a slanted way or refuse others. For an internal coding assistant this may not matter. For a customer-facing agent it can.

Agent use raises the stakes. A model that only drafts text has limited blast radius. A model that drives tool calls can be hijacked by instructions hidden in the content it reads. If a model is easier to jailbreak, every tool it can reach becomes easier to misuse.

Serving security. The inference server is now yours to harden. Local model servers often listen without authentication by default, and an exposed one is an open door. See the self-hosted LLM hardening checklist.

A decision checklist per model

Before approving any model, open-weight or not, for a workload, answer these:

• Deployment path chosen. Hosted app, hosted API, cloud provider, or self-hosted. Each needs its own decision.
• Data class allowed. Which data classes may reach this model on this path: public, internal, confidential, personal data.
• Provenance recorded. Publisher, exact revision, hash, licence, and where the artefact is stored.
• Licence reviewed. Open weights do not always mean unrestricted commercial use.
• Use-case tests passed. Jailbreak, prompt-injection and refusal tests relevant to what the model will actually do.
• Tool access scoped. If the model drives an agent, the agent's tools and permissions match the model's tested robustness.
• Guardrails in place. Input and output checks run regardless of which model serves the request.
• Routing enforced. The model is reachable only through the approved path, and unapproved models are blocked.
• Review date set. Re-assess when the model version, the provider terms or the use case changes.

Enforce an allow-list, not a memo

A written policy that says "use approved models only" is not enforced unless traffic can only reach approved models. The usual pattern:

1. Put model access behind one gateway. Applications and agents call the gateway, never a provider directly. The gateway holds the provider keys.
2. Register only approved configurations. Each approved combination of provider, model and deployment path becomes a configuration. Anything not registered cannot be reached.
3. Route by policy. Decide which workloads may use which configuration. A cheaper open-weight model may be fine for summarising public documents and not fine for customer data. Model routing trade-offs explains how to make those choices.
4. Apply the same guardrails to every model. Do not lower input and output checks because a model runs on-premises. The risk from a weak model is behavioural, not just about where the data goes.
5. Watch for bypass. Look for agents or services that call model endpoints directly, and bring them under the gateway.

What to tell employees

Policy only works if people understand it. Keep the message short and concrete:

• Do not paste company data into consumer AI apps that are not on the approved list. This includes hosted DeepSeek, and any other chatbot without a company agreement.
• Use the sanctioned tools. Name them, and explain how to get access. A good sanctioned option removes most of the reason to go elsewhere.
• Ask before adding a model to a product. Engineering teams that want to try an open-weight model should request a configuration, not wire a new endpoint into code.
• Report what you find. If a tool or agent calls a model directly, flag it so it can be brought under the gateway.

How Praesidia helps

Praesidia gives you one place to make and enforce this decision:

• Discover. See which agents call which models, so unapproved models and direct provider calls become visible.
• Secure. The BYOK model registry supports major hosted providers, including DeepSeek, as well as Ollama for self-hosted open-weight models and custom OpenAI-compatible endpoints. You register only the configurations you have approved, keep keys encrypted, and send traffic through the Praesidia gateway where guardrails can block, redact or warn on every request, whatever model serves it.
• Prove. Praesidia records its decisions in an append-only, hash-chained audit trail, so you can show which model handled which request and which guardrails applied.

The question is not "DeepSeek, yes or no". It is "which model, on which path, for which data, with which controls". For the wider gateway picture, see the AI gateway guide.