DeepSeek na empresa: riscos de dados, hospedagem e alternativas

DeepSeek na empresa: riscos de dados, hospedagem e alternativas

Usar DeepSeek na empresa é uma decisão sobre onde os dados vão parar, não sobre qual modelo é melhor. Com a API do fornecedor, o conteúdo enviado sai do seu controle e passa a seguir a política e a jurisdição do serviço. Com os pesos abertos rodando em infraestrutura que você controla, o risco de transferência muda de natureza, mas surgem custos de operação, segurança e avaliação.

Principais pontos

• API do fornecedor, aplicativo de chat e pesos abertos hospedados por você são três situações diferentes, com riscos diferentes. Tratar tudo como DeepSeek esconde a decisão real.
• Na API, a pergunta central é onde os dados ficam, por quanto tempo, quem os acessa e se podem ser usados para treinar modelos. Resposta não encontrada deve ser tratada como desconhecida.
• Pesos abertos tiram o fornecedor do caminho dos dados, mas a segurança, a licença, a avaliação e a operação passam a ser responsabilidade da empresa.
• A LGPD não proíbe modelos de origem estrangeira, mas exige saber quais dados pessoais entram, com qual base legal e por qual mecanismo ocorre uma eventual transferência internacional.
• O caminho mais seguro é limitar os dados, testar um fluxo real com logs e decidir com evidência se expande, ajusta ou para.

Qual a diferença entre usar a API e rodar os pesos abertos?

Muita conversa trata DeepSeek como uma coisa só. Na prática, existem formas de uso com riscos bem distintos:

• API do fornecedor: sua aplicação envia prompts e documentos para servidores operados por quem mantém o serviço e recebe a resposta.
• Aplicativo ou site de chat do fornecedor: pessoas digitam diretamente, muitas vezes com contas pessoais, fora de qualquer controle da empresa.
• Pesos abertos em infraestrutura própria: você obtém os arquivos do modelo publicados e executa em máquinas sob seu controle, sem enviar prompts ao fornecedor.
• Pesos abertos em provedor terceiro: uma nuvem hospeda o modelo e vende acesso por API. O criador do modelo não recebe seus dados, mas o provedor de hospedagem recebe, e é ele que você precisa avaliar.

Vale separar documentação oficial de hipótese. Que os pesos foram publicados e que cada versão tem uma licença que define os usos permitidos é algo que se confirma no cartão do modelo e no texto da licença. Já dizer que um modelo aberto é seguro por ser aberto é hipótese, e ela não se sustenta bem. Abrir os pesos permite inspecionar e hospedar. Não garante comportamento adequado, ausência de falhas nem qualidade no seu caso de uso.

Quais riscos de dados existem ao usar a API do fornecedor?

O primeiro passo é ler a política de privacidade e os termos de uso vigentes, direto nas páginas oficiais, e registrar a data da leitura. Esses textos mudam, e o que vale para sua decisão é a versão em vigor no momento da contratação.

O documento precisa responder a perguntas objetivas:

• Onde os dados enviados são armazenados e processados?
• Por quanto tempo prompts e respostas são retidos?
• O conteúdo pode ser usado para treinar ou melhorar modelos? Existe opção de recusar?
• Quem são os operadores e suboperadores com acesso ao conteúdo?
• Em que condições o fornecedor pode ser obrigado a entregar dados a autoridades de outros países?
• Existe contrato de tratamento de dados ou apenas termos de adesão?
• Como funciona a exclusão de dados e o atendimento a solicitações de titulares?

Se uma resposta não aparece de forma clara, trate como desconhecida, não como favorável. Para dados pessoais de clientes, dados financeiros, contratos, informações de saúde ou segredos comerciais, resposta desconhecida significa não enviar.

Há ainda um risco menos visível: o uso paralelo. Mesmo que a empresa nunca contrate a API, alguém pode colar um orçamento ou uma planilha de clientes no aplicativo de chat. Por isso a política de uso de IA na empresa deve citar ferramentas pelo nome, dizer que tipos de dado nunca entram em ferramentas não aprovadas e indicar o canal oficial para pedir a aprovação de uma nova.

O que muda ao hospedar os pesos em infraestrutura própria?

Rodar os pesos abertos tira o fornecedor do caminho dos dados, mas coloca a responsabilidade em você. O que passa a ser seu:

• Infraestrutura: modelos grandes exigem hardware considerável. Versões menores ou destiladas rodam em máquinas mais simples, com uma perda de qualidade que precisa ser medida no seu caso.
• Segurança: acesso ao servidor, rede, autenticação, registro de uso e atualização do software de inferência.
• Origem dos arquivos: baixar de fonte oficial, conferir integridade e evitar versões alteradas de origem desconhecida.
• Licença: confirmar se o uso comercial pretendido é permitido na versão específica que você escolheu.
• Avaliação: testar com exemplos do seu processo, incluindo casos difíceis, em português do Brasil.
• Operação: monitorar disponibilidade, atualizar versões e ter alguém responsável quando algo falhar.

A hospedagem também tem variações. Em servidor próprio, os dados não saem da empresa. Em nuvem privada, a pergunta de transferência internacional depende da região escolhida e do contrato com o provedor, não do modelo. Para quem quer entender o caminho local com disciplina, vale ler como rodar um modelo local sem improvisar.

Um aviso importante: modelo local não elimina os riscos da aplicação. Se o agente tem acesso a CRM, e-mail ou arquivos, continuam valendo os riscos descritos no OWASP Top 10 para aplicações com LLM, como injeção de prompt e excesso de permissões. Hospedar por conta própria resolve a questão de para onde o dado vai, não a de o que o agente pode fazer com ele.

Como a LGPD entra na decisão?

A LGPD não proíbe usar um modelo de origem estrangeira. Ela pede que a empresa saiba quais dados pessoais trata, com qual finalidade e base legal, quem são os operadores e, se houver transferência internacional, qual mecanismo previsto em lei a sustenta. O detalhamento está em transferência internacional de dados com IA e LGPD.

Na prática, quatro perguntas organizam a análise:

• O fluxo envolve dados pessoais? Se o prompt contém nome, telefone, CPF ou histórico de compra, sim.
• Dá para reduzir? Mascarar identificadores, enviar só o trecho necessário e evitar anexos completos diminui a exposição.
• Qual é o papel do fornecedor? Se ele trata dados em nome da empresa, é preciso contrato que reflita isso, com instruções, segurança e regras de exclusão.
• Há transferência para outro país? Em caso positivo, a empresa precisa de um mecanismo válido e documentado, e a ANPD é a fonte para acompanhar a regulamentação aplicável.

A ANPD publica orientações e normas que devem ser consultadas diretamente. Este texto não substitui parecer jurídico: a escolha da hipótese de transferência e o texto do contrato devem passar por advogado ou pelo encarregado de dados da empresa.

Que checklist aplicar antes de qualquer piloto?

Um plano em etapas evita que a decisão seja tomada por entusiasmo ou por medo:

• Passo 1: descrever o processo em que o modelo atuaria, quem o executa hoje e como se mede o resultado atual.
• Passo 2: listar os dados que entrariam no fluxo e classificar cada um como público, interno, pessoal ou sensível.
• Passo 3: definir o que nunca entra, independentemente da opção escolhida.
• Passo 4: comparar as quatro formas de uso (API, aplicativo, pesos próprios, pesos em provedor) contra essa lista de dados.
• Passo 5: ler e registrar política, termos e licença vigentes, com data e responsável pela leitura.
• Passo 6: definir permissões do agente: que ferramentas ele chama, o que lê, o que pode alterar e o que exige aprovação humana.
• Passo 7: montar um conjunto de testes com exemplos reais anonimizados e critérios de aceitação combinados antes de começar.
• Passo 8: rodar o piloto em um único fluxo, com log de entradas, saídas e decisões, e um prazo para revisão.
• Passo 9: decidir com base no registro: expandir, ajustar ou parar.

O NIST AI Risk Management Framework é uma referência útil para estruturar esse tipo de gestão de risco em linguagem comum entre tecnologia, jurídico e operação.

Como ficaria na prática? Cenário ilustrativo

Cenário ilustrativo: uma distribuidora de materiais elétricos quer um assistente que ajude a equipe comercial a redigir respostas a clientes no WhatsApp, com base em catálogo e histórico de pedidos.

A primeira ideia é enviar as conversas completas para a API de um fornecedor. Ao aplicar o checklist, a empresa percebe que as conversas trazem nome, telefone, endereço de entrega e condições comerciais negociadas. A política do fornecedor não deixa claro por quanto tempo o conteúdo é retido nem se pode ser usado para treinamento. Pelo critério definido, resposta desconhecida significa não enviar.

A empresa então separa o fluxo em duas partes. A parte que só precisa do catálogo e de regras de produto passa a usar texto sem dados pessoais, o que permite testar diferentes modelos com baixo risco. A parte que exige histórico do cliente é avaliada com um modelo aberto hospedado em ambiente controlado pela empresa, em um piloto pequeno, com um vendedor responsável por revisar cada rascunho antes do envio. O assistente só sugere, quem envia é uma pessoa.

No fim do piloto, o time compara os rascunhos com as respostas humanas, revisa os registros e decide se mantém o modelo, troca por outro ou volta ao processo manual para aquele tipo de caso. Quem for operar esse canal deve também conhecer as regras da plataforma, como as de mensagens ativas, templates e opt-in no WhatsApp.

Quais alternativas existem e como decidir?

DeepSeek é uma opção entre várias. Um guia de decisão em forma de lista ajuda a não começar pela ferramenta:

• Se o fluxo usa apenas dados públicos ou internos de baixo risco, a API do fornecedor pode ser aceitável depois da leitura dos termos, com chaves controladas e sem anexar dados pessoais.
• Se o fluxo usa dados pessoais e o fornecedor não oferece contrato, retenção e localização claros, prefira outra opção ou anonimize antes do envio.
• Se a empresa tem capacidade técnica para operar infraestrutura, pesos abertos em ambiente próprio dão o maior controle sobre onde o dado fica.
• Se não tem essa capacidade, um provedor de nuvem com contrato de tratamento de dados e região definida pode ser melhor do que um servidor improvisado.
• Se a tarefa é simples e repetitiva, como classificar mensagens ou extrair campos, um modelo menor pode bastar. Veja quando modelos pequenos resolvem e como testar.
• Se a tarefa exige julgamento sobre pessoas, crédito, saúde ou direitos, mantenha decisão humana, independentemente do modelo.

O método de trabalho que costuma funcionar é curto: mapear o processo atual e a linha de base, limitar dados e ações, pilotar um fluxo real com logs e uma métrica de sucesso combinada, e transferir a operação para quem vai mantê-la, decidindo então se expande, ajusta ou para. Ele vale para qualquer modelo, inclusive os que não são DeepSeek, e evita que a escolha técnica venha antes da análise de risco.

Perguntas frequentes

É seguro usar a API do DeepSeek com dados de clientes? Depende do que a política e o contrato vigentes dizem sobre armazenamento, retenção, uso para treinamento e acesso por terceiros, e da base legal que a empresa tem para o tratamento. Se esses pontos não estiverem claros, o caminho prudente é não enviar dados pessoais e testar apenas com informações públicas ou anonimizadas. A decisão final deve envolver o encarregado de dados ou assessoria jurídica.

Rodar os pesos abertos em servidor próprio resolve o problema de privacidade? Resolve a parte de envio de dados ao fornecedor do modelo, porque os prompts ficam na sua infraestrutura. Não resolve segurança do servidor, permissões do agente, licença de uso nem a qualidade das respostas, que continuam sendo responsabilidade da empresa. Também é preciso proteger os registros gerados, que podem conter dados pessoais.

Preciso proibir o DeepSeek para os funcionários? Não necessariamente, mas é preciso definir regras claras: quais ferramentas são aprovadas, que tipos de dado nunca entram em ferramentas externas e quem aprova exceções. Uma proibição genérica sem alternativa aprovada tende a empurrar o uso para contas pessoais, onde a empresa perde qualquer visibilidade.

Por onde começar se a empresa ainda não tem política de IA? Comece escolhendo um processo, listando os dados envolvidos e definindo o que nunca pode sair da empresa. Depois, rode um piloto pequeno com registro de entradas e saídas, revisão humana e uma métrica simples combinada antes. Com esse histórico em mãos, a política deixa de ser abstrata e passa a refletir o que a empresa realmente faz.

Fontes

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