Acordo de dados

Acordo de Tratamento de Dados (DPA)

Versão 1, em vigor desde 16 de outubro de 2026. · English version

No Sistema NAVSTEC, quem decide sobre os dados dos contatos é a empresa cliente. Nós só tratamos esses dados para prestar o serviço, do jeito que ela manda. Este acordo diz o que podemos e o que não podemos fazer com eles, como os protegemos, quem nos ajuda, o que fazemos num incidente e como tudo termina. Ele faz parte dos Termos do Sistema NAVSTEC.

1. Partes e papéis

• Operadora: NAVS TECNOLOGIA E CONSULTORIA LTDA, dona da marca NAVSTEC, CNPJ 69.476.914/0001-20, Av. Raja Gabaglia, 1617, sala 501, Luxemburgo, Belo Horizonte/MG, CEP 30380-435 (“NAVSTEC” ou “nós”).
• Controlador: a empresa que contrata o Sistema NAVSTEC (app.navstec.com e o app “NAVSTEC Sistema” da Meta), o “cliente”.

Os papéis seguem a Lei Geral de Proteção de Dados (LGPD, Lei 13.709/2018). Controlador é a pessoa “a quem competem as decisões referentes ao tratamento de dados pessoais” (art. 5º, VI). Operador é quem “realiza o tratamento de dados pessoais em nome do controlador” (art. 5º, VII). Chamamos de suboperador a empresa que nós contratamos e que trata dados do cliente para nos ajudar a prestar o serviço (seção 7).

Este acordo faz parte dos Termos do Sistema NAVSTEC e vale desde que o cliente aceita a proposta, assina o contrato ou começa a usar o sistema. Sobre dados pessoais, este acordo vale acima dos Termos. O contrato assinado pode acrescentar regras; só muda este acordo se disser isso de forma expressa.

Nos dados das pessoas que usam o sistema (login, segurança, suporte e cobrança), a NAVSTEC é a controladora, como explica a Política de Privacidade. Esses dados ficam fora deste acordo.

2. Objeto e instruções

Tratamos os dados pessoais do cliente só para prestar o Sistema NAVSTEC (CRM, Conversas e Dashboard) e o suporte, e só como o cliente manda. É o que diz a LGPD: “O operador deverá realizar o tratamento segundo as instruções fornecidas pelo controlador” (art. 39).

2.1 O que conta como instrução do cliente

• o contrato, os Termos e este acordo;
• o que o cliente configura e faz no sistema: ligar ou desligar canais (WhatsApp, Instagram, Messenger, Lead Ads), mandar mensagens, importar, exportar e apagar contatos, escolher cargos e permissões, ligar a API de Conversões, a ficha de saúde ou a inteligência artificial;
• pedidos escritos do administrador da conta para [email protected].

2.2 Instrução que parece ilegal

Se uma instrução nos parecer contrária à LGPD ou a outra lei, avisamos o cliente e podemos não a cumprir até ele esclarecer.

2.3 O que nunca fazemos com os dados do cliente

• vender ou alugar;
• usar nos nossos anúncios ou nos de terceiros;
• usar para treinar inteligência artificial;
• juntar com dados de outros clientes;
• ler as conversas, salvo no suporte que o dono da conta aprovar (seção 5) ou quando a lei obrigar.

2.4 Pedido de autoridade

Se uma autoridade ou um juiz nos mandar entregar dados do cliente, avisamos o cliente antes de entregar, salvo se a ordem proibir o aviso, e entregamos só o que a ordem pedir.

3. Que dados, de quem e para quê

Finalidade: prestar o Sistema NAVSTEC e o suporte ao cliente. Natureza: receber (pelas integrações e pelas telas), guardar, organizar, mostrar à equipe do cliente, mandar mensagens, exportar e apagar.

Titulares: os contatos, leads e clientes do cliente; nas contas de saúde, os pacientes; e as pessoas citadas nas conversas e nos arquivos.

Categoria	O que é
Identificação e contato	Nome, telefone, e-mail, foto do perfil (quando a plataforma a dá) e os identificadores de cada plataforma (WhatsApp, Instagram, Messenger).
Conversas	Texto, fotos, áudios, vídeos, documentos, reações e o estado de entrega e de leitura. Podem trazer dados sensíveis que a pessoa escreve por vontade própria, como sobre saúde.
Cadastros	Respostas aos formulários de Lead Ads e dos sites do cliente, com a campanha, o anúncio e o formulário de onde vieram.
Registros do CRM	Negócios, etapas do funil, valores, tarefas, notas, agendamentos e etiquetas.
Medição	Só se o cliente ligar: os avisos de conversão à Meta (API de Conversões), com e-mail, telefone e país em código (hash SHA-256) e os identificadores criados pela Meta. Nunca nomes, mensagens nem notas. Nas contas de saúde, vem desligado.
Ficha de saúde	Só nas contas com a ficha ligada: anamnese, termo de consentimento, assinatura, trilha da assinatura, fotos antes e depois e o consentimento de uso de imagem. É dado pessoal sensível (Anexo II).

A LGPD chama de sensível o “dado referente à saúde ou à vida sexual, dado genético ou biométrico, quando vinculado a uma pessoa natural”, entre outros (art. 5º, II).

4. Duração

Este acordo dura enquanto o contrato durar e, depois dele, até os dados serem devolvidos e apagados (seção 12). O sigilo, os registros que a lei manda guardar e as regras de guarda do Anexo II continuam a valer depois do fim.

5. Deveres da NAVSTEC

• Seguir as instruções da seção 2 e tratar só os dados necessários.
• Sigilo da equipe: só tem acesso a dados do cliente quem precisa deles para o serviço, e cada pessoa assume por escrito o dever de sigilo antes do primeiro acesso. A LGPD manda que quem intervém no tratamento garanta a segurança “mesmo após o seu término” (art. 47).
• Suporte só com aprovação: a equipe da NAVSTEC não é membro das contas dos clientes. Só entra numa conta quando o dono aprova, por até 8 horas de cada vez, só para ler, e cada entrada fica registrada. O suporte nunca lê a ficha de saúde: o próprio banco de dados nega.
• Registro das operações: o sistema registra as ações importantes (entradas, exportações, mudanças de permissão, apagamentos, entradas do suporte), como pede a LGPD: “O controlador e o operador devem manter registro das operações de tratamento” (art. 37).
• Ajudar o cliente a cumprir a lei: com a informação que tivermos para o relatório de impacto (art. 38), para as respostas à ANPD e aos titulares e para avaliar riscos.
• Avisar o cliente se não pudermos cumprir este acordo.

6. Segurança

A LGPD manda os agentes adotarem “medidas de segurança, técnicas e administrativas aptas a proteger os dados pessoais de acessos não autorizados e de situações acidentais ou ilícitas de destruição, perda, alteração, comunicação ou qualquer forma de tratamento inadequado ou ilícito” (art. 46). Estas são as medidas que o sistema tem hoje:

• Dados no Brasil: o servidor e o banco de dados ficam na AWS, em São Paulo. Saem do país só a cópia de recuperação de desastre e o que passa pelos recursos e plataformas que o cliente liga (seção 8).
• Cada empresa vê só os próprios dados: o isolamento é feito no próprio banco de dados (segurança por linha do PostgreSQL, ligada e forçada em toda tabela com dados de clientes). O sistema entra no banco com um usuário sem poderes de administrador, que não consegue contornar essa regra. Antes de cada publicação, uma verificação automática tenta ler os dados de uma conta a partir de outra e, se conseguir, a publicação para.
• Criptografia: o banco de dados fica criptografado com uma chave própria, gerida no serviço de chaves da AWS (KMS), e as cópias de segurança também ficam criptografadas. As chaves de acesso da Meta e os segredos do login em duas etapas são criptografados uma segunda vez, cada um com a sua chave (cifra por envelope), presa à conta do cliente: copiados para outra conta, não abrem. Os arquivos das conversas e da ficha de saúde são criptografados um a um, do mesmo jeito.
• Login: a senha fica guardada só como código irreversível (Argon2id). A verificação em duas etapas é obrigatória para todas as pessoas, com aplicativo autenticador e códigos de recuperação, e com chave de acesso (passkey) quando estiver disponível. Depois de várias tentativas erradas, o login fica bloqueado por um tempo. A sessão acaba depois de 60 minutos parada ou 12 horas no total. Exportar e mudar permissões pedem a senha e o código de novo.
• Permissões por cargo: o administrador escolhe o que cada cargo vê e faz (por exemplo, ver telefones, exportar, ver fichas de saúde), e o banco de dados garante a regra.
• Registros de acesso e de ações: cada entrada fica registrada com data, hora e IP, por no mínimo 6 meses (Marco Civil da Internet, Lei 12.965/2014, art. 15). O registro das ações só aceita linhas novas e cada linha leva o código (hash) da anterior, para que uma mudança feita às escondidas apareça.
• Rede e acesso técnico: o banco de dados não tem endereço público e só aceita ligações do servidor do sistema. O acesso técnico ao servidor é só por chave e só a partir de endereços autorizados. Tudo passa por conexão protegida (HTTPS).
• Registros técnicos sem dados pessoais: os registros do servidor não levam nomes, telefones, e-mails nem mensagens e são apagados em 30 dias.
• Cópias de segurança: automáticas, com recuperação para qualquer momento dos últimos 35 dias, e uma cópia em outra região da AWS para desastres.

Certificação e auditoria externa: uma certificação (como ISO 27001 ou SOC 2) e uma invasão simulada feita por empresa de fora (pentest) entram no relatório de segurança (seção 11) quando forem feitas. Nenhum sistema é invulnerável; por isso existe a seção 9.

7. Suboperadores

A lista de suboperadores, com o que cada um faz, o país e a base da transferência, está no Anexo I. O cliente autoriza o uso dessa lista ao aceitar este acordo.

• Só usamos suboperadores que têm termos de proteção de dados por escrito e só lhes damos o necessário para o serviço que prestam.
• Os recursos opcionais (inteligência artificial, sites hospedados por nós) só mandam dados ao suboperador quando a conta do cliente liga o recurso.
• Respondemos perante o cliente pelo que os suboperadores fizerem no serviço que nos prestam, nos limites da seção 13.

7.1 Como avisamos mudanças

• Aviso de 30 dias: antes de um suboperador novo receber dados do cliente, avisamos o administrador da conta por e-mail, com 30 dias de antecedência, e atualizamos o Anexo I e o histórico de versões.
• Direito de objeção: o cliente pode se opor por escrito em até 15 dias depois do aviso, com um motivo ligado à proteção de dados. Procuramos uma solução (por exemplo, não usar o novo suboperador na conta dele). Se não houver solução, o cliente pode encerrar o contrato, ou só a parte afetada, sem multa.
• Emergência: se for preciso trocar um suboperador de repente, para proteger os dados ou manter o serviço, avisamos logo que possível, e o direito de objeção continua a valer.

7.2 O que não é suboperador

As plataformas que o cliente liga com as próprias contas (WhatsApp, Instagram, Messenger, Facebook e as contas de anúncios da Meta) e as integrações que o cliente escolher ligar são uma relação direta entre o cliente e esse fornecedor, sob os termos dele. O sistema só envia e recebe dados por elas porque o cliente mandou. Estão listadas à parte, no Anexo I, para o cliente saber por onde os dados passam.

8. Transferência internacional

Os dados do sistema ficam no Brasil. A LGPD só permite transferir dados pessoais para outro país nos casos do art. 33. Para empresas, os caminhos comuns são dois: um destino que a ANPD reconheceu como de proteção “adequada” (art. 33, I) e as “cláusulas-padrão contratuais” da ANPD (art. 33, II, “b”).

8.1 Como as regras estão hoje

• União Europeia: adequada. “Fica reconhecida a União Europeia como organismo internacional que proporciona grau de proteção de dados pessoais adequado ao previsto na Lei nº 13.709, de 14 de agosto de 2018, para fins de transferência internacional de dados” (Resolução CD/ANPD nº 32/2026, art. 1º). Vale também para a Islândia, o Liechtenstein e a Noruega.
• Estados Unidos: sem decisão de adequação. Mandar dados para lá pede outro mecanismo, em geral as cláusulas-padrão da ANPD.
• Cláusulas-padrão da ANPD: o texto é o do Anexo II da Resolução CD/ANPD nº 19/2024 e só vale com a “adoção integral e sem alteração do texto disponibilizado no Anexo II, mediante instrumento contratual firmado entre o exportador e o importador” (art. 16). Entre dois operadores (nós e um suboperador), usa-se a opção “exclusiva para as transferências internacionais de dados realizadas entre operadores”, com o cliente indicado como “Terceiro Controlador”.
• Cláusulas de outros países não bastam: a ANPD pode reconhecer cláusulas estrangeiras como equivalentes (Res. 19/2024, art. 18), mas até hoje não reconheceu nenhuma, nem as cláusulas-padrão europeias que aparecem nos contratos dos fornecedores.

8.2 O que é possível hoje e o que não é

• É possível: mandar dados para a União Europeia, com base na adequação; e para os EUA, quando o fornecedor assina as cláusulas-padrão da ANPD.
• Não é possível: obrigar um fornecedor grande a assinar um texto que ele não oferece; usar as cláusulas europeias como se fossem brasileiras; ou adotar as cláusulas da ANPD só “por referência”, sem um instrumento assinado pelas duas empresas.
• A nossa regra: nenhum dado do cliente sai do Brasil para um destino sem base válida. Cada saída do Anexo I tem a sua base. Quando não há base, o dado fica no Brasil ou na União Europeia, ou o recurso fica desligado.

8.3 O que sai do Brasil

• Cópia de recuperação de desastre (AWS): hoje fica numa região da AWS nos Estados Unidos (Virgínia do Norte). A AWS não oferece as cláusulas-padrão da ANPD: o contrato de dados dela só traz as cláusulas da União Europeia, do Reino Unido e da Suíça. E a cópia automática do banco feita a partir de São Paulo só pode ir para os Estados Unidos. Por isso, antes de o primeiro cliente pôr dados no sistema, a cópia de desastre passa a ser feita numa região da AWS na União Europeia (destino adequado) ou fica só no Brasil. Dados de clientes não vão para a cópia nos Estados Unidos.
• Inteligência artificial (quando existir e o cliente ligar): os fornecedores previstos (Anthropic e OpenAI, nos Estados Unidos) também não oferecem as cláusulas da ANPD. A IA só é ligada numa conta de cliente com uma base válida: as cláusulas-padrão da ANPD assinadas pelo fornecedor, o processamento na União Europeia ou um fornecedor que trate os dados no Brasil. Até lá, fica desligada.
• Formulários dos sites que hospedamos (Cloudflare, quando contratado): a Cloudflare também não oferece as cláusulas da ANPD. Só hospedamos formulários de clientes com o banco dos formulários guardado na União Europeia.
• Plataformas da Meta (WhatsApp, Instagram, Messenger): na API do WhatsApp, a Meta é operadora do cliente, e os termos dela já incorporam as cláusulas-padrão da ANPD, com o cliente como exportador e a Meta Platforms, Inc. como importadora. A Meta também usa alguns dados como controladora, para a segurança e a integridade da plataforma dela.
• Google e TikTok (quando o cliente ligar): os dados vão pela relação direta do cliente com cada um (seção 7.2).

8.4 Transparência

O controlador tem de publicar, em português e em linguagem simples, informações sobre as transferências internacionais, como o país de destino e a finalidade (Res. 19/2024, art. 17, § 2º), e entregar ao titular que pedir “a íntegra das cláusulas utilizadas” (art. 17), em 15 dias. Esta seção e o Anexo I trazem essas informações, e o cliente pode apontar para esta página na política de privacidade dele. Se um titular pedir as cláusulas, mandamos a cópia ao cliente em até 5 dias úteis.

9. Incidentes de segurança

Para a ANPD, incidente de segurança é “qualquer evento adverso confirmado, relacionado à violação das propriedades de confidencialidade, integridade, disponibilidade e autenticidade da segurança de dados pessoais” (Resolução CD/ANPD nº 15/2024, art. 3º, XII).

9.1 Avisamos o cliente em até 24 horas

Avisamos o administrador da conta em até 24 horas a contar do momento em que soubermos de um incidente que afete dados do cliente, mesmo sem ter ainda todos os detalhes. O prazo é curto de propósito: quem comunica à ANPD e aos titulares é o cliente (LGPD, art. 48), e o prazo dele é de “três dias úteis” (Res. 15/2024, art. 6º), contado “do conhecimento pelo controlador de que o incidente afetou dados pessoais” (art. 6º, § 1º). O mesmo prazo vale para avisar os titulares (art. 9º). A ANPD orienta que o operador informe o controlador “sem demora injustificada” e lhe dê todas as informações necessárias.

9.2 O que o aviso leva

O que soubermos de cada item que a ANPD pede na comunicação (Res. 15/2024, art. 6º, § 2º), e o resto assim que soubermos:

• a descrição do incidente e a causa principal, se já for possível identificá-la;
• a data em que ocorreu, quando for possível determiná-la, e a data em que soubemos;
• a natureza e a categoria dos dados pessoais afetados;
• o número de titulares afetados, com crianças, adolescentes e idosos à parte, quando der para saber, e o total de titulares da conta;
• as medidas de segurança usadas antes e depois do incidente;
• os riscos e os possíveis impactos para os titulares;
• o que já fizemos e o que vamos fazer para conter o incidente e reduzir os efeitos;
• a nossa identificação como operadora e o contato de quem cuida do caso.

9.3 O que fazemos depois

• Conter e guardar provas: cortamos o acesso indevido, trocamos as chaves envolvidas e guardamos os registros, sem expor mais dados pessoais.
• Completar: mandamos as informações novas assim que as tivermos, a tempo de o cliente completar a comunicação à ANPD, o que ele pode fazer “no prazo de vinte dias úteis, a contar da data da comunicação” (Res. 15/2024, art. 6º, § 3º).
• Ajudar a avisar os titulares: o aviso tem de ser em “linguagem simples” e “de forma direta e individualizada, caso seja possível identificá-los” (art. 9º, § 1º). Ajudamos o cliente com a lista dos afetados e o texto.
• Não falamos em nome do cliente: não comunicamos à ANPD nem aos titulares em nome dele, salvo se ele pedir por escrito ou se a lei nos obrigar.
• Registro: registramos cada incidente, mesmo os que não precisam ser comunicados, por no mínimo 5 anos, e damos ao cliente o que ele precisa para o registro dele, que a ANPD exige “pelo prazo mínimo de cinco anos” (Res. 15/2024, art. 10).

10. Direitos dos titulares

Pela LGPD (art. 18), o titular pode pedir, entre outras coisas, a confirmação e o acesso aos dados, a correção, a anonimização, o bloqueio ou a eliminação, a portabilidade e a revogação do consentimento. Quem responde é o cliente, que é o controlador. Nós ajudamos assim:

• O sistema tem as ferramentas: ver, corrigir, exportar e apagar um contato. Apagar leva o contato para a lixeira por 30 dias, para desfazer um engano; depois ele sai de vez.
• Pedido que chega a nós: encaminhamos ao cliente em até 2 dias úteis e não respondemos no lugar dele, salvo se ele pedir.
• O que o sistema não fizer sozinho, fazemos a pedido do cliente em até 5 dias úteis, para ele cumprir o prazo da lei: a declaração completa ao titular tem de sair “no prazo de até 15 (quinze) dias, contado da data do requerimento do titular” (art. 19, II).

11. Auditoria

• Relatório e questionário: uma vez por ano, ou depois de um incidente, entregamos ao cliente que pedir um relatório de segurança (medidas, suboperadores, incidentes e verificações feitas) e respondemos a um questionário razoável de segurança em até 30 dias.
• Inspeção: se o relatório não bastar, o cliente, ou um auditor dele com dever de sigilo, pode inspecionar o cumprimento deste acordo, com aviso de 30 dias, em horário comercial, no máximo uma vez por ano, salvo depois de um incidente ou por ordem da ANPD. A inspeção não dá acesso a dados de outros clientes nem a chaves e segredos de segurança.
• Custo: cada parte paga o próprio custo da inspeção. Se ela mostrar que descumprimos este acordo de forma relevante, pagamos também o custo razoável do cliente.
• ANPD: colaboramos com a Agência Nacional de Proteção de Dados (ANPD) quando ela pedir informações sobre o tratamento que fazemos para o cliente.

12. Fim do contrato: devolução e eliminação

• Exportação: no fim do contrato, por qualquer motivo, o cliente tem 30 dias para exportar os dados dele (contatos, negócios e conversas, em arquivos de formato aberto, como CSV ou JSON; nas contas de saúde, também as fichas, como diz o Anexo II), pelo próprio sistema ou com a nossa ajuda.
• Eliminação: depois desses 30 dias, apagamos os dados do cliente em até mais 30 dias.
• Cópias de segurança: ficam criptografadas e os dados saem delas quando cada cópia vence (as automáticas do banco, em até 35 dias). Até lá, não são usadas, salvo para recuperar o sistema de um desastre; se isso acontecer, apagamos de novo o que já tinha sido eliminado.
• O que fica: só o que a lei manda guardar, como os registros de acesso (6 meses, Marco Civil, art. 15), o registro das ações e dos incidentes e os documentos fiscais. A LGPD permite guardar para “cumprimento de obrigação legal ou regulatória” (art. 16, I).
• Declaração: se o cliente pedir, entregamos uma declaração por escrito de que os dados foram eliminados.

13. Responsabilidade

• Cada parte responde pelos danos que causar ao violar a LGPD ou este acordo (LGPD, arts. 42 a 45).
• O cliente responde pela base legal de cada tratamento, pelo aviso aos titulares, pelo conteúdo que põe no sistema e pelas instruções que dá.
• A NAVSTEC responde pela segurança que promete aqui e por seguir as instruções lícitas do cliente. A LGPD diz que “o operador responde solidariamente pelos danos causados pelo tratamento quando descumprir as obrigações da legislação de proteção de dados ou quando não tiver seguido as instruções lícitas do controlador” (art. 42, § 1º, I).
• Quem pagar um dano ao titular pode cobrar do outro a parte dele (art. 42, § 4º).
• Limite entre as partes: a responsabilidade total da NAVSTEC perante o cliente por este acordo fica limitada ao valor que o cliente pagou à NAVSTEC nos 12 meses antes do fato, salvo dolo, culpa grave ou quando a lei não permitir limite. O limite vale só entre as partes: não diminui os direitos dos titulares nem as sanções da ANPD.

14. Lei e foro

Valem as leis do Brasil, em especial a LGPD e as resoluções da ANPD. Fica eleito o foro da comarca de Belo Horizonte/MG, sem prejuízo dos direitos do consumidor previstos em lei. Há uma versão em inglês; se houver diferença, vale esta, em português.

15. Contato

• Encarregado e qualquer assunto deste acordo: [email protected]. É o mesmo canal do encarregado da Política de Privacidade.
• Incidentes: o mesmo e-mail e o WhatsApp (31) 97557-1835, com a palavra “Incidente” no início.
• Não mande dados de contatos ou de pacientes por e-mail ou WhatsApp: o e-mail passa pelo Google (Gmail) e o WhatsApp pela Meta. Para mostrar um caso, use o próprio sistema ou diga só o identificador do contato.

Anexo I. Lista de suboperadores

I.1 Suboperadores da NAVSTEC

Suboperador	O que faz	País	Base da transferência
Amazon Web Services (AWS)	Servidor (EC2), banco de dados PostgreSQL (RDS), chaves de criptografia (KMS), segredos do sistema (Secrets Manager), e-mails do sistema (SES), registros técnicos e alertas (CloudWatch) e, quando ligado, armazenamento de arquivos (S3).	Brasil (São Paulo)	Não há transferência internacional.
Amazon Web Services (AWS): cópia de desastre	Cópia criptografada das cópias de segurança do banco, para recuperar o sistema se a região de São Paulo falhar.	Hoje, Estados Unidos (Virgínia do Norte). Para dados de clientes, União Europeia ou Brasil.	União Europeia: adequação (LGPD, art. 33, I; Res. CD/ANPD nº 32/2026). Estados Unidos: a AWS não oferece as cláusulas-padrão da ANPD, por isso a cópia lá não recebe dados de clientes (seção 8.3).
Cloudflare	Endereços (DNS) do sistema, sem passar os dados por ela (sem proxy): não recebe dados pessoais do sistema. Só quando a NAVSTEC hospeda o site do cliente: os formulários desse site (Worker e banco D1).	Estados Unidos (empresa) e rede mundial	DNS: não há transferência de dados do sistema. Formulários: banco na União Europeia (adequação); a Cloudflare não oferece as cláusulas-padrão da ANPD.
Anthropic	Quando o cliente ligar; ainda não disponível. Inteligência artificial de texto: resumo, sugestão de resposta, etiquetas e agentes. Nunca a ficha de saúde.	Estados Unidos	Só com base válida (seção 8.3); sem ela, a IA não é ligada.
OpenAI	Quando o cliente ligar; ainda não disponível. Transcrição de áudio. Nunca a ficha de saúde.	Estados Unidos	Só com base válida (seção 8.3); sem ela, a transcrição não é ligada.

Quando a inteligência artificial ou a hospedagem de sites forem lançadas, vale o aviso de 30 dias da seção 7.1 antes de qualquer dado de cliente seguir para esses fornecedores.

I.2 Plataformas e integrações que o cliente liga (não são suboperadores da NAVSTEC)

Plataforma	Para quê	País	Relação
Meta Platforms	WhatsApp (API oficial), Instagram, Messenger e Lead Ads: por onde as mensagens e os cadastros entram e saem. API de Conversões, só se o cliente ligar.	Vários países	Termos da Meta com o cliente, que já incorporam as cláusulas-padrão da ANPD (seção 8.3).
Google	Quando o cliente ligar; ainda não disponível. Google Ads e Google Analytics 4 (conversões), Google Agenda (agendamentos) e Google Drive (arquivos que o cliente escolher). Detalhes na Política de Privacidade, item 3.8.	Vários países	Relação direta do cliente com o Google.
TikTok	Quando o cliente ligar; ainda não disponível. Marketing API e Events API (conversões e resultados dos anúncios). Detalhes na Política de Privacidade, item 3.9.	Vários países	Relação direta do cliente com o TikTok.

Anexo II. Aditivo de dados de saúde

Este aditivo completa o acordo nas contas com o setor de saúde ligado: clínicas e profissionais que usam a ficha de saúde (anamnese), o termo de consentimento e as fotos antes e depois. Ligar a ficha liga o setor de saúde da conta e, depois disso, ele não se desliga. Se houver conflito, este aditivo vale acima do resto do acordo.

II.1 Base legal

• A ficha trata dado pessoal sensível (LGPD, art. 5º, II). Quem escolhe a base legal é a clínica, que é a controladora.
• Para atender o paciente, a base costuma ser a do art. 11, II, “f”: “tutela da saúde, exclusivamente, em procedimento realizado por profissionais de saúde, serviços de saúde ou autoridade sanitária”. Ela só serve quando quem atende é profissional ou serviço de saúde.
• Se não for o caso, a clínica deve usar o consentimento do art. 11, I: “quando o titular ou seu responsável legal consentir, de forma específica e destacada, para finalidades específicas”.
• Para crianças, vale o “consentimento específico e em destaque dado por pelo menos um dos pais ou pelo responsável legal” (art. 14, § 1º).
• Usar a foto em redes sociais, anúncios ou portfólio é outra finalidade e pede um consentimento à parte (II.7).

II.2 O que fica no sistema

Item	O que guardamos
Ficha (anamnese)	As perguntas do modelo, na versão usada, e as respostas da pessoa, criptografadas.
Termo de consentimento	O texto exato da versão que a pessoa leu. Cada versão do modelo fica congelada, com o código (hash SHA-256) das perguntas e do termo.
Assinatura	O desenho feito com o dedo ou o nome escrito pela pessoa.
Trilha	Quando o link foi enviado, aberto (com IP e navegador), preenchido, o termo lido, o código conferido (se usado) e a ficha assinada, sempre na hora do servidor, e o número de WhatsApp de destino.
Documento final	Um PDF da ficha assinada e o código SHA-256 do documento: qualquer mudança depois da assinatura muda o código.
Fotos antes e depois	As fotos, por procedimento e por dia.
Ficha em papel	A foto ou o PDF da ficha assinada no papel, que a clínica anexa.
Uso de imagem	Se a pessoa permite ou não o uso das fotos fora do atendimento, com a data.
Aviso clínico	Só um sinal de que há um aviso (por exemplo, uma alergia marcada), sem o conteúdo, para a equipe que atende ver.

II.3 Quem vê

• O administrador da conta e quem ele autorizar com a permissão “Ver fichas de saúde”. Ela não vem ligada em nenhum cargo novo: o administrador tem de a dar de propósito.
• Quem tem só a permissão “Enviar fichas” (a recepção, por exemplo) envia o link e acompanha o estado (enviada, assinada) sem ver as respostas.
• Cada leitura fica registrada: respostas, termo, fotos e PDF. O administrador vê quem leu a ficha de quem e quando.
• O suporte da NAVSTEC nunca lê a ficha, nem com a aprovação do dono. A conta de revisão da Meta também não tem acesso. Quem nega é o próprio banco de dados.

II.4 O que nunca sai do sistema

• Pixel e API de Conversões: nada da ficha vai para a Meta. Nas contas de saúde, os avisos de conversão vêm desligados. Se a clínica os ligar, vai só a lista fechada da seção 3, nunca nada da ficha, e a clínica responde por seguir as regras da Meta sobre saúde.
• Inteligência artificial: o conteúdo da ficha nunca vai para a IA. Nas contas de saúde, a IA vem desligada. Se o administrador a ligar nas conversas, um filtro no nosso servidor barra, antes de sair, o texto que pareça ser de saúde.
• WhatsApp: pelo WhatsApp vai só o link da ficha (e o código, se ligado). As perguntas e as respostas abrem numa página nossa, fora do WhatsApp.
• Exportações e relatórios: a ficha não entra na exportação de contatos nem no Dashboard. Sai só pelo PDF de cada ficha, para quem tem a permissão, e na devolução do fim do contrato (II.6).
• Cópia da pessoa: quem assina recebe a própria cópia por um link de download que funciona uma vez e vale 24 horas.

A LGPD proíbe “a comunicação ou o uso compartilhado entre controladores de dados pessoais sensíveis referentes à saúde com objetivo de obter vantagem econômica”, salvo nos casos que ela lista (art. 11, § 4º). A ficha não serve para anúncios.

II.5 Assinatura eletrônica

Como a pessoa assina (a clínica escolhe por modelo):

• Link no WhatsApp: a pessoa recebe no WhatsApp dela um link que só funciona uma vez e vence em 72 horas (a clínica escolhe de 1 hora a 30 dias). Abre, responde, lê o termo até o fim e assina com o dedo ou escrevendo o nome.
• Link + código: igual, mais um código de 6 dígitos mandado ao mesmo WhatsApp na hora de assinar. O código vale 10 minutos e aceita até 5 tentativas.
• Na chegada: no celular ou no tablet da clínica; o link vale 2 horas.
• No papel: a pessoa assina o papel e a clínica anexa a foto ou o PDF.

O que a lei diz, em palavras simples. Entre a clínica e o paciente, vale a assinatura eletrônica que as partes aceitam como válida. A Medida Provisória 2.200-2/2001 diz que a ICP-Brasil “não obsta a utilização de outro meio de comprovação da autoria e integridade de documentos em forma eletrônica, inclusive os que utilizem certificados não emitidos pela ICP-Brasil, desde que admitido pelas partes como válido ou aceito pela pessoa a quem for oposto o documento” (art. 10, § 2º). A Lei 14.063/2020 dá os três níveis (art. 4º):

• simples: “a que permite identificar o seu signatário”;
• avançada: a que, aceita pelas partes, “está associada ao signatário de maneira unívoca”, usa dados que o signatário pode, “com elevado nível de confiança, operar sob o seu controle exclusivo” e está ligada ao documento “de tal modo que qualquer modificação posterior é detectável”;
• qualificada: a que usa certificado digital ICP-Brasil.

Onde a ficha se encaixa (a nossa leitura): só com o link, é uma assinatura simples, com a trilha de provas. Com o link + código, tem as três características da avançada: só a pessoa recebe o link e o código no WhatsApp dela, e o código SHA-256 mostra qualquer mudança. Para isso valer, o termo deve dizer que a pessoa aceita assinar por meio eletrônico e reconhece essa assinatura como válida. A ficha nunca é assinatura qualificada, porque não usa certificado ICP-Brasil.

Documentos do profissional são outra regra. A ficha é assinada pelo paciente. Receitas de medicamentos de controle especial e atestados médicos eletrônicos só valem com assinatura qualificada do profissional (Lei 14.063/2020, art. 13), e os outros documentos do profissional de saúde pedem assinatura avançada ou qualificada (art. 14). O sistema não emite receitas nem atestados.

Papel: guarde o original. A foto anexada não substitui o papel. Para destruir o original, a Lei 13.787/2018 pede uma digitalização com “certificado digital emitido no âmbito da Infraestrutura de Chaves Públicas Brasileira (ICP-Brasil) ou outro padrão legalmente aceito” (art. 2º, § 2º) e a análise de uma comissão de revisão de prontuários (art. 3º). O sistema não faz essa digitalização certificada.

II.6 Guarda e eliminação

• Prazo da lei: “Decorrido o prazo mínimo de 20 (vinte) anos a partir do último registro, os prontuários em suporte de papel e os digitalizados poderão ser eliminados” (Lei 13.787/2018, art. 6º), e isso vale também para os documentos “gerados e mantidos originalmente de forma eletrônica” (art. 6º, § 5º).
• No sistema: cada ficha assinada e cada foto ficam guardadas, por padrão, 20 anos a contar da assinatura (ou do envio da foto). A clínica pode mudar o prazo na configuração da ficha. A lei conta os 20 anos do último registro do prontuário: se a pessoa continuar a ser atendida, a clínica deve manter as fichas antigas por mais tempo.
• Antes do prazo, não se apaga: nem o administrador consegue apagar uma ficha assinada. Se o contato for apagado, a ficha continua guardada e só o administrador a vê. Depois do prazo, a ficha não sai sozinha: só a clínica decide apagá-la.
• Pedido do paciente para apagar: a clínica avalia. A guarda legal prevalece, porque a LGPD permite guardar para “cumprimento de obrigação legal ou regulatória pelo controlador” (art. 16, I).
• Fim do contrato: dentro dos 30 dias da seção 12, entregamos à clínica a exportação de todas as fichas (o PDF de cada uma, com a trilha, os termos, as fotos e os arquivos do papel). A partir daí, a guarda pelo prazo legal fica com a clínica. Depois, apagamos tudo como diz a seção 12, salvo acordo escrito para continuarmos a guardar.

II.7 Consentimento de uso de imagem

• As fotos antes e depois servem ao atendimento. Usá-las fora dele (redes sociais, anúncios, portfólio) pede um consentimento separado, que o sistema registra como “permite” ou “não permite”, com a data. O registro mais novo é o que vale.
• A pessoa pode retirar o consentimento quando quiser: “O consentimento pode ser revogado a qualquer momento mediante manifestação expressa do titular, por procedimento gratuito e facilitado” (LGPD, art. 8º, § 5º).
• A imagem também é protegida pela Constituição (“são invioláveis a intimidade, a vida privada, a honra e a imagem das pessoas”, art. 5º, X) e pelo Código Civil (art. 20).
• O sistema não publica fotos em lugar nenhum. Quem publica é a clínica, e só com o “permite” válido.

II.8 Deveres da clínica

• escolher e registrar a base legal (II.1) e informar os pacientes, no aviso de privacidade dela, de que usa o Sistema NAVSTEC;
• incluir no termo a aceitação da assinatura eletrônica (II.5) e rever os textos dos modelos prontos antes de usar;
• dar a permissão “Ver fichas de saúde” só a quem precisa e tirar o acesso de quem sair da equipe;
• não escrever dados de saúde fora da ficha (notas, etiquetas, nomes de etapas ou de campanhas);
• seguir as regras do conselho da sua profissão sobre prontuário e sigilo;
• indicar o encarregado (LGPD, art. 41) e fazer o relatório de impacto quando a ANPD pedir (art. 38).

Regras dos conselhos profissionais. O piso da lei são os 20 anos desde o último registro (Lei 13.787/2018, art. 6º). Alguns conselhos têm regras próprias. O CFO, por exemplo, fixa “o prazo mínimo de 10 (dez) anos, a partir do último registro” para o prontuário em papel e “a guarda permanente” para o prontuário arquivado eletronicamente (Resolução CFO-91/2009, arts. 8º e 7º). O CFM repete os 20 anos para o papel (Parecer CFM nº 19/2026). Por isso, o sistema guarda 20 anos por padrão; se a regra da sua profissão pedir mais tempo, aumente o prazo na configuração da ficha. A mesma resolução do CFO só permite eliminar o papel digitalizado com um sistema de “Nível de garantia de segurança 2 (NGS2)” e certificado ICP-Brasil (arts. 3º e 5º). O Sistema NAVSTEC não tem essa certificação: guarde o papel original.

II.9 Incidente com dado de saúde

Vale a seção 9, com o mesmo prazo de aviso. Dado de saúde é sensível, o que pesa na avaliação de risco. Ajudamos a clínica a avisar cada paciente afetado, de forma individual, quando a comunicação for devida.

Histórico de versões

Versão	Data	O que mudou
Versão 1	16/10/2026	Primeira versão do acordo, com o Anexo I (suboperadores) e o Anexo II (aditivo de dados de saúde).

Mudanças que reduzam a proteção dos dados são avisadas ao administrador de cada conta com 30 dias de antecedência. As versões antigas ficam disponíveis a pedido.

Versão 1 — 16/10/2026