Subprocessadores
Subprocessadores da plataforma BeSafe
Quem recebe dado pessoal quando a plataforma funciona, para quê, quais dados, em que país e sob qual instrumento. Separa o que a BeSafe usa para operar do que só entra quando a sua empresa conecta o próprio ambiente.
Atualizado em 20 de outubro de 2026
Em uma página
Versão 1.0, redigida em 3 de outubro de 2026. A data de vigência é a da publicação, mostrada no topo desta página.
Subprocessador é o terceiro que trata dado pessoal para que a BeSafe consiga prestar o serviço. Quando o dado é da base de colaboradores de uma empresa cliente, esse terceiro é um suboperador: trata em nome da empresa, que é a controladora, e só para a finalidade do serviço.
Esta lista foi montada a partir do código da plataforma. Só entra fornecedor que o sistema de fato aciona. Onde o país ou o instrumento contratual ainda não estão definidos, o texto diz isso, em vez de estimar.
Há três grupos. Os fornecedores que a BeSafe usa para operar. Os serviços que o navegador de quem usa a plataforma acessa diretamente. E os serviços do ambiente da própria empresa cliente, como Microsoft, Google, Slack e Meta, que só recebem algo se a empresa conectar a conta dela.
Parte importante do tratamento não passa por terceiro: o e-mail de simulação sai por servidor de envio próprio, a transcrição de voz roda em servidor próprio e os arquivos ficam em armazenamento próprio. Isso está descrito em seção separada.
Inclusão ou troca de suboperador é avisada antes à empresa cliente, que pode se opor.
Aviso necessário: este documento precisa de revisão jurídica antes de ser publicado. Revisão jurídica prevista antes da constituição da empresa.
Como ler cada linha
Cada fornecedor aparece num parágrafo, sempre na mesma ordem: nome; finalidade; dados que ele recebe; país onde trata os dados; instrumento contratual. A data de inclusão não foi registrada nesta primeira versão: a lista nasce com os fornecedores abaixo, e cada inclusão posterior gera uma versão nova com a data.
Instrumento é o contrato ou a cláusula que obriga o fornecedor a tratar o dado só para a finalidade indicada, com confidencialidade e segurança. Quando o dado sai do Brasil, inclui a salvaguarda exigida pelo artigo 33 da LGPD.
Nesta fase de MVP, a BeSafe usa cada fornecedor nos termos de serviço e de tratamento de dados que ele publica. Contrato negociado e salvaguarda específica de transferência internacional ainda não estão definidos, e por isso não aparecem aqui como cumpridos.
Fornecedores que a BeSafe usa para operar
OpenAI, modelos de linguagem e de embeddings. Finalidade: gerar a resposta do assistente; analisar mensagens no verificador de golpes, inclusive com decisão tipada; vetorizar a base de conhecimento e as consultas feitas ao assistente; escrever a recomendação do relatório executivo mensal; e escrever o rascunho de um template de simulação quando o administrador pede. Dados: o texto que a pessoa digita no assistente e a consulta derivada dele; para o administrador, números agregados da organização; o texto colado no verificador depois de redigido, sem a parte local de endereços de e-mail, CPF, CNPJ, telefone, número de cartão, chave Pix aleatória e códigos de verificação; no relatório executivo, apenas números agregados; e, no rascunho de template, a ideia descrita pelo administrador, sem dado de colaborador. País: Estados Unidos. Instrumento: termos de uso da API da OpenAI; não há contrato de tratamento de dados assinado especificamente nesta fase, e a retenção e o uso do conteúdo para treinar modelos seguem esses termos. Salvaguarda do artigo 33: não definida nesta versão.
Toda chamada a esse fornecedor sai com a opção que pede que a interação não fique armazenada como registro consultável no provedor. Isso não equivale a retenção zero e não substitui a cláusula contratual. As chamadas só acontecem quando a operação liga, por configuração, o acesso da inteligência artificial à rede externa e a chave do fornecedor está presente. Sem isso, o assistente e o verificador funcionam sem enviar nada para fora.
Google, serviço Web Risk. Finalidade: consultar a reputação dos endereços de internet que aparecem numa mensagem analisada no verificador de golpes. Dados: o endereço de internet encontrado na mensagem, que pode carregar identificador de pessoa quando quem montou o golpe o colocou ali. País: não confirmado nesta versão. Instrumento: termos de serviço publicados pelo Google para o Web Risk. Salvaguarda do artigo 33: não definida nesta versão.
Stripe. Finalidade: processar a assinatura, a cobrança e o portal de faturamento da empresa cliente. Dados: razão social, CNPJ como dado de conciliação, e-mail de cobrança e o identificador interno da organização. Os dados do meio de pagamento são digitados na página da própria Stripe e não passam pela BeSafe. Neste tratamento a BeSafe é controladora, porque o dado é da conta do cliente, e não da base de colaboradores. Nesta fase de MVP, a Stripe opera em modo de teste, sem cobrança real. País: não confirmado nesta versão. Instrumento: termos de serviço publicados pela Stripe. Salvaguarda do artigo 33: não definida nesta versão.
Provedor de e-mail transacional, Resend. Finalidade: entregar os e-mails de serviço, como verificação de conta, convite de membro, recuperação de senha, código de reautenticação, código de entrada no portal do colaborador, lembrete de treino, avisos de cobrança e certificado de eliminação. Dados: endereço de e-mail do destinatário, nome da organização e o conteúdo do aviso. Para colaboradores, isso inclui o e-mail corporativo, o código de entrada no portal e o nome do módulo de treino. Este provedor nunca entrega mensagem simulada. País: Estados Unidos. Instrumento: termos de serviço publicados pela Resend. Salvaguarda do artigo 33: não definida nesta versão.
Provedor de hospedagem, Hostinger (Hostinger International Limited). Finalidade: hospedar a plataforma inteira, inclusive o banco de dados, a fila, os arquivos e o servidor de envio de simulação. Dados: todos os dados da plataforma, guardados no disco do servidor. Os campos mais sensíveis, como e-mail e telefone de colaborador, ficam cifrados pela própria aplicação antes de chegar ao disco. País: Brasil, com o servidor em Campinas (SP). Instrumento: termos de serviço publicados pela Hostinger.
Armazenamento externo de backup: ainda não contratado. Nesta fase, as cópias de segurança do banco de dados e dos arquivos ficam cifradas no próprio servidor, com rotação de 35 dias, e nenhum terceiro as recebe. Quando um armazenamento externo for contratado, ele entra nesta lista em versão nova.
Serviços que só entram se a empresa cliente conectar
Estes serviços pertencem ao ambiente da própria empresa cliente. Ela tem contrato direto com cada fornecedor, e a conexão é feita pelo administrador dela, com a credencial dela, pelo painel. Nada é acionado se a empresa não conectar.
A BeSafe usa o aplicativo que ela registra em cada plataforma para entregar a mensagem do programa ou para ler o diretório. O país e as regras de tratamento do lado do fornecedor seguem o contrato da empresa cliente com ele. Desde: a data em que a empresa conecta o serviço. O aplicativo que a BeSafe registra em cada plataforma segue os termos de desenvolvedor publicados por ela; não há outro instrumento documentado nesta versão.
Slack. Finalidade: entregar mensagens do programa a membros do workspace conectado, sempre com a identidade do aplicativo da BeSafe. Dados: o identificador do destinatário no workspace e o texto da mensagem, que pode conter primeiro nome, nome da empresa, área, data e o link da simulação.
Microsoft, nos serviços Teams, Microsoft 365 e Entra ID. Finalidade: entregar a mensagem do bot do aplicativo instalado no tenant da empresa; autorizar a conexão dos canais Teams e Outlook; e, se a empresa quiser, ler o diretório de usuários para importar ou sincronizar a base, com permissão só de leitura. Dados: no Teams, o identificador da conversa e o conteúdo da mensagem. Na leitura do diretório o fluxo é de entrada: a BeSafe recebe os campos permitidos da base, como nome, e-mail, área e cargo, e envia ao fornecedor apenas a autorização e a consulta. O e-mail simulado do canal Outlook não é entregue pela Microsoft como fornecedora da BeSafe: ele sai do servidor de envio próprio e chega à caixa de correio da empresa.
Google Workspace, pela API de administração do diretório. Finalidade: ler o diretório de usuários da empresa, com permissão só de leitura, para importar ou sincronizar a base. Dados: o fluxo é de entrada. A BeSafe recebe os campos permitidos da base e envia ao fornecedor apenas a autorização e a consulta.
Meta, pela API do WhatsApp Business. Finalidade: entregar conteúdo educativo do programa, nunca simulação enganosa, só com modelo aprovado pela Meta e só para número corporativo declarado com aceite registrado da pessoa. Dados: o número de telefone corporativo e as variáveis do modelo aprovado.
O que roda na infraestrutura da BeSafe
Os componentes abaixo rodam no servidor da BeSafe. Eles não são terceiros, mas aparecem aqui porque a pergunta sobre eles é frequente.
Envio do e-mail de simulação: servidor de envio próprio, com assinatura DKIM e domínios de simulação registrados pela BeSafe. Nenhum provedor de e-mail transacional recebe mensagem simulada.
Transcrição de voz do assistente: serviço Whisper rodando no próprio servidor. O áudio vai em memória para a transcrição e não é gravado pela plataforma.
Armazenamento de arquivos: serviço compatível com S3, o RustFS, no próprio servidor. Antivírus dos arquivos enviados: ClamAV, no próprio servidor. Leitura de texto em imagem no verificador: Tesseract, no próprio servidor.
Monitor de disponibilidade, quando ativado: Uptime Kuma, no próprio servidor.
O que não está nesta lista, e por quê
Emissor de nota fiscal eletrônica: não há. Nesta fase de MVP, os pagamentos pela Stripe estão em modo de teste, não há cobrança real nem emissão de nota fiscal, e ainda não há empresa constituída para emiti-la. O emissor entra nesta lista quando for contratado.
Monitoramento de erros por terceiro: o código prevê a configuração, mas ela fica vazia e nenhum dado vai para esse tipo de serviço nesta versão.
Um segundo provedor especializado em decisões tipadas de inteligência artificial está previsto, mas não há integração ativa. Hoje essas decisões usam o mesmo fornecedor de modelos listado acima.
Consultas públicas de registro de domínio: o verificador consulta o registro público de domínios, no Registro.br e no serviço de descoberta da IANA. Vai apenas o nome do domínio que aparece na mensagem, sem dado de quem a colou.
Fontes de inteligência de ameaças: a plataforma só lê conteúdo público delas. Nada sobre pessoas é enviado.
Consulta de senhas vazadas: quando alguém cria ou troca a senha do painel, a plataforma consulta a base pública Have I Been Pwned. Vão só os cinco primeiros caracteres do resumo SHA-1 da senha nova; a senha, o resumo inteiro e o e-mail nunca saem do servidor, e o serviço não tem como saber qual senha nem de quem.
Inclusão, troca e direito de oposição
Antes de incluir ou trocar um suboperador que trate dado da base de colaboradores, a BeSafe avisa as empresas clientes. O prazo e o canal desse aviso ainda não estão definidos nesta fase de MVP e devem constar do contrato.
A empresa cliente pode se opor à inclusão, com justificativa, dentro desse prazo. O que acontece se a oposição não for resolvida ainda não está definido nesta fase e deve constar do contrato.
Cada mudança gera uma versão nova desta página, com a data de inclusão do fornecedor.
Transferência internacional
Parte destes fornecedores pode tratar dados fora do Brasil. A LGPD só admite a transferência internacional nas hipóteses do artigo 33, com as salvaguardas da Resolução CD/ANPD nº 19/2024, entre elas as cláusulas-padrão aprovadas pela Autoridade.
Nesta fase de MVP, o instrumento de transferência internacional adotado com cada fornecedor ainda não está definido nem documentado: as transferências seguem os termos de serviço e de tratamento de dados que cada fornecedor publica. Os dados da plataforma ficam armazenados no Brasil, no servidor da Hostinger em Campinas (SP).
Revisão jurídica
Aviso necessário: este texto foi redigido a partir do que o código da plataforma faz hoje e de modelos editoriais. Ele não substitui a análise de um advogado e precisa de revisão jurídica antes de ser publicado.
Este aviso fica no documento até que um advogado revise o texto. Revisão jurídica prevista antes da constituição da empresa.
Pontos de atenção nesta lista: se os serviços do ambiente da empresa cliente devem figurar como suboperadores da BeSafe; o enquadramento dos serviços acessados pelo navegador; e a regra de só listar fornecedor contratado, já que esta versão parte do que o código integra.
Histórico de versões
Versão 1.0, redigida em 3 de outubro de 2026. Primeira versão deste documento, criada na revisão dos documentos legais da plataforma completa. Não há versão anterior.
Cada versão publicada fica arquivada com o período em que vigorou, e uma versão publicada nunca muda de texto: qualquer correção vira versão nova.
Pedidos de titular, dúvidas sobre tratamento e solicitações de acesso passam pelo e-mail bernardo.iannini14@gmail.com ou pelo formulário de contato. Respondemos no prazo legal.