Using DeepSeek in Business: Data Risks, Hosting and Alternatives

Using DeepSeek in Business: Data Risks, Hosting and Alternatives

Using DeepSeek in business is a decision about where your data ends up, not about which model is best. With the vendor's API, the content you send leaves your control and follows the policy and jurisdiction of the service. With open weights running on infrastructure you control, the transfer risk changes in nature, but you take on the costs of operation, security and evaluation.

Key takeaways

• The vendor API, the vendor's chat app and open weights hosted by you are three different situations with different risks. Treating them all as "DeepSeek" hides the real decision.
• With the API, the core questions are where the data is kept, for how long, who can access it and whether it can be used to train models. An answer you cannot find should be treated as unknown.
• Open weights take the vendor out of the data path, but security, licensing, evaluation and operations become your company's responsibility.
• LGPD (Brazil's data protection law) does not ban foreign-origin models, but it requires you to know which personal data goes in, under which legal basis, and through which mechanism any international transfer happens.
• The safest path is to limit the data, test one real workflow with logs, and decide on evidence whether to expand, adjust or stop.

What is the difference between using the API and running open weights?

Much of the conversation treats DeepSeek as a single thing. In practice there are several ways to use it, with very different risks:

• Vendor API: your application sends prompts and documents to servers operated by whoever runs the service, and receives the answer back.
• Vendor chat app or website: people type directly into it, often with personal accounts, outside any company control.
• Open weights on your own infrastructure: you download the published model files and run them on machines you control, without sending prompts to the vendor.
• Open weights at a third-party provider: a cloud hosts the model and sells access through an API. The model's creator does not receive your data, but the hosting provider does, and that provider is the one you need to evaluate.

It helps to separate official documentation from assumption. That the weights were published, and that each version has a license defining permitted uses, can be confirmed on the model card and in the license text. Saying an open model is safe because it is open is an assumption, and it does not hold up well. Open weights let you inspect and host the model. They do not guarantee appropriate behavior, absence of flaws or quality for your use case.

What data risks come with the vendor's API?

The first step is to read the current privacy policy and terms of use directly on the official pages, and to record the date you read them. These texts change, and what matters for your decision is the version in force when you sign up.

The documents need to answer concrete questions:

• Where is the submitted data stored and processed?
• How long are prompts and responses retained?
• Can the content be used to train or improve models? Is there an opt-out?
• Who are the processors and subprocessors with access to the content?
• Under what conditions might the vendor be required to hand data to authorities in other countries?
• Is there a data processing agreement, or only click-through terms?
• How does data deletion work, and how are data subject requests handled?

If an answer is not clearly stated, treat it as unknown, not as favorable. For customer personal data, financial data, contracts, health information or trade secrets, an unknown answer means do not send.

There is also a less visible risk: parallel use. Even if the company never signs up for the API, someone may paste a quote or a customer spreadsheet into the chat app. That is why your company AI use policy should name tools explicitly, say which types of data never go into unapproved tools, and point to the official channel for requesting approval of a new one.

What changes when you host the weights on your own infrastructure?

Running open weights takes the vendor out of the data path, but it puts the responsibility on you. What becomes yours:

• Infrastructure: large models need substantial hardware. Smaller or distilled versions run on simpler machines, with a quality loss that has to be measured in your own case.
• Security: server access, network, authentication, usage logging and updates to the inference software.
• File provenance: download from an official source, verify integrity and avoid altered versions of unknown origin.
• License: confirm that your intended commercial use is allowed for the specific version you chose.
• Evaluation: test with examples from your own process, including hard cases, in Brazilian Portuguese if that is your working language.
• Operations: monitor availability, update versions and name someone responsible when something fails.

Hosting also has variations. On your own server, the data does not leave the company. On a private cloud, the international transfer question depends on the region you choose and the contract with the provider, not on the model. If you want to understand the local path with discipline, read how to run a local model without improvising.

One important warning: a local model does not remove the risks of the application around it. If the agent has access to a CRM, email or files, the risks described in the OWASP Top 10 for LLM applications still apply, such as prompt injection and excessive permissions. See prompt injection protection for AI agents for a practical view. Self-hosting settles where the data goes, not what the agent can do with it.

How does LGPD affect the decision?

LGPD does not prohibit using a foreign-origin model. It asks the company to know which personal data it processes, for what purpose and under which legal basis, who the processors are, and, if there is an international transfer, which legal mechanism supports it. The details are in international data transfer under LGPD when using AI providers.

In practice, four questions organize the analysis:

• Does the workflow involve personal data? If the prompt contains a name, phone number, tax ID or purchase history, yes.
• Can you reduce it? Masking identifiers, sending only the necessary excerpt and avoiding full attachments all lower exposure.
• What is the vendor's role? If it processes data on the company's behalf, you need a contract that reflects that, with instructions, security and deletion rules.
• Is there a transfer to another country? If so, the company needs a valid, documented mechanism, and the ANPD (Brazil's data protection authority) is the source to follow for applicable regulation.

The ANPD publishes guidance and rules that should be consulted directly. This article does not replace legal advice: the choice of transfer mechanism and the contract text should go through a lawyer or the company's data protection officer.

What checklist should you apply before any pilot?

A step-by-step plan keeps the decision from being driven by enthusiasm or fear:

• Step 1: describe the process where the model would act, who performs it today and how the current result is measured.
• Step 2: list the data that would enter the workflow and classify each item as public, internal, personal or sensitive.
• Step 3: define what never goes in, regardless of the option chosen.
• Step 4: compare the four ways of using it (API, chat app, your own weights, weights at a provider) against that data list.
• Step 5: read and record the current policy, terms and license, with the date and the person responsible for the reading.
• Step 6: define the agent's permissions: which tools it calls, what it reads, what it can change and what requires human approval.
• Step 7: build a test set with real, anonymized examples and acceptance criteria agreed before you start.
• Step 8: run the pilot on a single workflow, with a log of inputs, outputs and decisions, and a deadline for review.
• Step 9: decide based on the record: expand, adjust or stop.

The NIST AI Risk Management Framework is a useful reference for structuring this kind of risk management in language shared by technology, legal and operations.

What does this look like in practice? Illustrative scenario

Illustrative scenario: an electrical supplies distributor wants an assistant that helps the sales team draft replies to customers on WhatsApp, based on the catalog and order history.

The first idea is to send full conversations to a vendor's API. When applying the checklist, the company notices the conversations contain names, phone numbers, delivery addresses and negotiated commercial terms. The vendor's policy does not make clear how long content is retained or whether it can be used for training. Under the rule the company set, an unknown answer means do not send.

The company then splits the workflow in two. The part that only needs the catalog and product rules uses text without personal data, which allows testing different models at low risk. The part that needs customer history is evaluated with an open model hosted in an environment the company controls, in a small pilot, with a salesperson responsible for reviewing every draft before it is sent. The assistant only suggests, and a person sends.

At the end of the pilot, the team compares the drafts with the human replies, reviews the logs and decides whether to keep the model, switch to another or return to the manual process for that type of case. Whoever runs this channel should also know the platform rules, such as those for WhatsApp outbound messages, templates and opt-in.

What alternatives exist and how do you decide?

DeepSeek is one option among several. A decision guide in list form helps you avoid starting with the tool:

• If the workflow uses only public or low-risk internal data, the vendor API may be acceptable after you read the terms, with controlled keys and no personal data attached.
• If the workflow uses personal data and the vendor does not offer a clear contract, retention terms and data location, prefer another option or anonymize before sending.
• If the company has the technical capacity to operate infrastructure, open weights in your own environment give the most control over where the data stays.
• If it does not have that capacity, a cloud provider with a data processing agreement and a defined region may be better than an improvised server.
• If the task is simple and repetitive, such as classifying messages or extracting fields, a smaller model may be enough. See when small language models are enough and how to test them.
• If the task requires judgment about people, credit, health or rights, keep a human decision, whatever the model.

The working method that tends to hold up is short: map the current process and its baseline, limit data and actions, pilot one real workflow with logs and an agreed success metric, and hand operation to whoever will maintain it, then decide whether to expand, adjust or stop. It applies to any model, including those that are not DeepSeek, and it keeps the technical choice from coming before the risk analysis.

Frequently asked questions

Is it safe to use the DeepSeek API with customer data? It depends on what the current policy and contract say about storage, retention, use for training and third-party access, and on the legal basis the company has for processing. If those points are not clear, the prudent path is to send no personal data and test only with public or anonymized information. The final decision should involve the data protection officer or legal counsel.

Does running open weights on my own server solve the privacy problem? It solves the part about sending data to the model vendor, because prompts stay on your infrastructure. It does not solve server security, agent permissions, license compliance or answer quality, which remain the company's responsibility. You also need to protect the logs you generate, which may contain personal data.

Do I need to ban DeepSeek for employees? Not necessarily, but you need clear rules: which tools are approved, which types of data never go into external tools and who approves exceptions. A blanket ban with no approved alternative tends to push use onto personal accounts, where the company loses all visibility.

Where should we start if the company has no AI policy yet? Start by choosing one process, listing the data involved and defining what can never leave the company. Then run a small pilot with a record of inputs and outputs, human review and a simple metric agreed in advance. With that history in hand, the policy stops being abstract and reflects what the company actually does.

Sources

• ANPD: Autoridade Nacional de Proteção de Dados
• NIST AI Risk Management Framework
• OWASP Top 10 for LLM Applications