Política de Privacidade

Quem somos e a quem esta política se aplica

1. Quem é o controlador

O ClinCRM é um sistema de gestão para clínicas (CRM), oferecido como serviço pela internet, com site público em https://clincrmapp.com e área logada no mesmo domínio. Toda a aplicação e o banco de dados rodam em um único servidor virtual contratado na Hostinger e operado por nós, com um único ponto de entrada exposto à internet.

Dados cadastrais do controlador:

Três ressalvas sobre esta tabela:

• A página de privacidade hoje no ar já publica o endereço privacidade@clincrmapp.com e promete resposta em 15 dias. BLOQUEANTE: confirmar que a caixa existe, tem responsável designado e rotina de monitoramento — nenhum prazo de resposta pode ir ao ar sem canal confirmado, sob pena de inadimplência desde o primeiro dia.
• Não há encarregado nomeado. A nomeação e a publicação do contato são obrigação do controlador (LGPD art. 41). A DEFINIR: nomear o encarregado e publicar o contato.
• A localização física do servidor não está declarada em nenhum documento do projeto. A DEFINIR: país e região do datacenter — esta política não pode afirmar "dados no Brasil" sem essa confirmação.

2. Para que serve este documento

Este documento explica, em linguagem direta: quais dados pessoais o ClinCRM trata, por quê, com quem compartilha, por quanto tempo guarda, quais medidas de segurança aplica e como o titular exerce seus direitos.

O que ele não é:

• Não é a política de privacidade da sua clínica. Se você é paciente, a clínica que cuida de você tem obrigações próprias e um documento próprio (ver item 4).
• Não é o contrato entre o ClinCRM e a clínica assinante. As obrigações contratuais de tratamento de dados entre nós e a clínica — o que a LGPD chama de instruções do controlador ao operador (art. 39) e o GDPR chama de contrato de processamento (art. 28(3)) — vivem em instrumento separado.
• Não é uma promessa de funcionalidade futura. Onde o texto marca [PENDENTE], o compromisso está assumido mas ainda não está implementado no sistema.

Sobre esse instrumento separado, o estado real é o seguinte. Toda clínica recebe, na criação da conta, três documentos de sistema, com versão identificada e registro de aceite. Eles já trazem cláusulas de controlador e operador, tratamento de dado sensível de saúde (LGPD art. 11), direitos do titular (art. 18), segurança (art. 46), guarda de prontuário por 20 anos e comunicação de incidente (art. 48). Mas:

• Esses textos foram redigidos pela equipe de engenharia, não passaram por revisão jurídica, e declaram no próprio corpo que não têm validade jurídica antes dessa revisão.
• Faltam neles cláusulas exigidas de um contrato de operador (LGPD art. 39; GDPR art. 28(3)): autorização e lista de subprocessadores com aviso prévio de troca; devolução ou eliminação dos dados ao fim do contrato; direito de auditoria da clínica; dever de confidencialidade nominal da equipe do ClinCRM; assistência em avaliação de impacto; e a hipótese de acesso técnico por conta global do ClinCRM, descrita no item 6.

BLOQUEANTE: submeter esses documentos à revisão jurídica e incluir as cláusulas de operador faltantes antes de tratá-los como contrato de tratamento de dados. BLOQUEANTE: a página de privacidade hoje no ar afirma ao visitante que existe "contrato próprio firmado na assinatura"; enquanto o instrumento não tiver validade jurídica, essa frase precisa ser corrigida ou removida.

3. A que este documento se aplica

Aplica-se a dois ambientes, que funcionam de formas bem diferentes:

O site é oferecido em cinco idiomas: português, inglês, francês, italiano e alemão. A DEFINIR: se o ClinCRM oferece deliberadamente o serviço a titulares na União Europeia, o GDPR (Regulamento UE 2016/679, art. 3(2)) se aplica e é preciso avaliar a nomeação de representante na UE (art. 27). A oferta comercial documentada hoje é para o mercado brasileiro, mas a interface nos quatro idiomas europeus é um fato que o advogado precisa pesar.

Fora do escopo deste documento: o que a clínica faz com os dados dela fora do sistema; o aplicativo WhatsApp instalado no telefone do paciente; e os destinos externos que a própria clínica configurar dentro do sistema (ver item 6).

4. Papéis: quando somos controlador e quando somos operador

Esta é a distinção mais importante do documento inteiro.

A LGPD (Lei 13.709/2018) separa dois papéis: controlador é quem decide sobre o tratamento — a finalidade e os meios (art. 5º, VI); operador é quem trata os dados por conta e sob as instruções do controlador (art. 5º, VII). O GDPR usa a mesma divisão, com os nomes *controller* (art. 4(7)) e *processor* (art. 4(8)).

O ClinCRM ocupa os dois papéis, dependendo de quem é o titular do dado:

Quatro precisões que acompanham esta tabela:

• Chamados de suporte. Somos controladores do conteúdo do chamado. Se a clínica inserir dado de paciente no texto, quanto a esse dado específico seguimos como operadores dela.
• Chat de IA do site. Ele usa um agente de âmbito global do ClinCRM. O provedor de IA que recebe a sua mensagem é escolhido e contratado pelo ClinCRM, não por nenhuma clínica: somos controladores desse tratamento e respondemos pela escolha do subprocessador e pela transferência internacional correspondente. O texto da sua mensagem não é gravado; a única escrita que a conversa produz é uma linha de contagem de consumo (provedor, modelo, origem e número de tokens), sem conteúdo.
• Formulário de contato e checkout. Seu telefone e e-mail ficam também numa coluna própria, usada para agrupar os seus contatos; o CNPJ e os demais dados do pedido ficam no corpo da mensagem.
• Modal "Cadastrar minha clínica". Esse formulário exibido no site não envia nada: os campos não são lidos e o envio é apenas simulado, mas a tela responde "Recebemos seu interesse!". Por esse canal o ClinCRM não coleta dado nenhum — e afirma ao visitante que recebeu. PENDENTE: ligar esse formulário ao recebimento de contatos ou corrigir a mensagem exibida. Enquanto não for corrigido, a declaração na tela é falsa.

5. O que essa diferença muda para você, na prática

Se você é visitante do site, lead ou interessado comercial: nós somos o controlador. Fale diretamente conosco, por privacidade@clincrmapp.com. Nós recebemos, decidimos e respondemos.

Uma exceção técnica precisa ficar clara: a sua resposta ao banner de métricas fica gravada apenas no seu navegador. Não guardamos nenhum registro que ligue essa escolha a você e não temos como alterá-la remotamente. Hoje, o único caminho efetivo para mudar de ideia é limpar os dados do site no seu navegador. PENDENTE: controle de revisão do consentimento na própria página.

Se você é paciente de uma clínica que usa o ClinCRM: o controlador dos seus dados é a clínica, não nós. Isso tem três consequências concretas:

1. Peça à clínica. Confirmação de tratamento, acesso, correção, anonimização, portabilidade e eliminação (LGPD art. 18; GDPR arts. 15 a 20) são pedidos que você endereça à clínica que te atende. É ela quem sabe se você é paciente dela, quem pode te identificar com segurança e quem tem base legal para agir.
2. Nós não atendemos você diretamente — e isso é proteção, não desculpa. Se recebermos um pedido seu, nós não o executamos por conta própria: encaminhamos à clínica controladora e a apoiamos tecnicamente, como manda a posição de operador (LGPD art. 39; GDPR art. 28(3)(e)). Atender um pedido de terceiro sem a instrução do controlador seria, ele mesmo, um tratamento indevido de dado de saúde. PENDENTE: não existe hoje no sistema um fluxo formal de recebimento e encaminhamento de pedido de titular; o canal é apenas o e-mail publicado.
3. O que a clínica consegue fazer hoje, pelo sistema, e o que não consegue. A exclusão do paciente existe e apaga em cascata prontuário, prescrições, medicamentos, exercícios, documentos, agendamentos, bioimpedância, planos alimentares, avaliações e as cobranças ainda não pagas. Se houver qualquer cobrança já paga, a exclusão inteira é recusada — a guarda fiscal prevalece e o pedido passa a exigir tratamento manual. PENDENTE: caminho de eliminação parcial que preserve apenas o que a lei fiscal exige. Não existe funcionalidade de exportação ou portabilidade: o site promete que a equipe combina a exportação com você, mas não há nenhuma função correspondente no produto. PENDENTE: implementar exportação de dados do titular; hoje o atendimento é manual. Também não existe função de anonimização. Alguns dados sobrevivem à exclusão do paciente por decisão de projeto ou por obrigação legal (trilha de auditoria, histórico de WhatsApp, registros com cobrança paga). Isso está detalhado na seção de retenção e eliminação.

Se você é funcionário de uma clínica assinante: para o seu cadastro (nome, e-mail, cargo, permissões), fale com a sua clínica. Para os registros de segurança que nós decidimos manter — dispositivos conhecidos com IP e descrição do navegador, alertas de novo acesso, contadores de tentativa de login —, fale conosco.

6. Os limites do nosso papel de operador

Ser operador não significa que não temos acesso. Significa que o acesso existe e é limitado por instrução, contrato e controle técnico. Três fatos que a clínica e o titular precisam saber:

a) Contas globais do ClinCRM alcançam os dados de qualquer clínica. Existem contas nossas, sem vínculo com nenhuma clínica, que podem trocar a clínica ativa da própria sessão para qualquer clínica existente, sem lista de autorização prévia. A partir daí, leem os mesmos dados que o médico da clínica lê — inclusive prontuário e documentos. Isso existe para suporte, correção de defeito e operação do serviço. Salvaguarda já implementada: o segundo fator de autenticação é obrigatório para essas contas. A trava adicional aplicada em produção bloqueia apenas escrita, não leitura. PENDENTE: restringir o acesso de conta global a autorização caso a caso e estender a exigência de segundo fator também à leitura.

b) Esse acesso é registrado, mas a clínica não consegue vê-lo. A abertura de prontuário é auditada. Porém, a ação feita por conta global é gravada sem vínculo com a clínica, e a tela de auditoria da clínica mostra apenas o que está vinculado a ela. Resultado: quando alguém do ClinCRM abre um prontuário da clínica X, o registro existe na nossa trilha global e não aparece na trilha da clínica X. PENDENTE: tornar visível à clínica todo acesso feito por conta global aos dados dela — é o mínimo para que a clínica cumpra o dever de controlar seu operador.

c) A clínica pode acrescentar destinos que nós não controlamos. Dentro do sistema, a clínica pode cadastrar um provedor de IA próprio, apontando para qualquer endereço compatível com o protocolo usado, e pode montar um bloco de automação que envia dados para uma URL escolhida por ela, incluindo nome e telefone de pacientes. Quando isso acontece, a escolha do destino, do país e do fornecedor é da clínica controladora, não nossa. Nós fornecemos o mecanismo; a decisão e a responsabilidade por essa transferência são de quem a configura (LGPD art. 39; GDPR art. 28(2)). A lista de subprocessadores deste documento, portanto, não é exaustiva por construção.

Há dois casos em que a escolha do destino é nossa, e neles respondemos integralmente pelo subprocessador e pela transferência internacional: o chat de IA do site público, e o complemento "IA do ClinCRM" quando contratado pela clínica. Nos dois, a chamada sai sob credencial da plataforma. Sem nenhum provedor conectado — nem pela clínica, nem pelo complemento —, o sistema responde localmente e nada sai do servidor.

7. Lacunas declaradas nesta seção

Para o revisor jurídico, o que falta preencher ou corrigir antes da publicação:

Quais dados tratamos

Aqui está o inventário completo, por categoria e por população: quais dados o ClinCRM trata, como eles chegam até nós e para quê.

Antes do inventário, três definições que mudam o sentido de tudo o que vem depois:

• Visitante do site é quem acessa https://clincrmapp.com sem fazer login.
• Usuário do sistema é a pessoa que acessa a área logada: gestor, médico, recepção, supervisor, ou membro da equipe do próprio ClinCRM.
• Paciente é a pessoa atendida pela clínica. O ClinCRM não tem relação direta com o paciente. Quem decide coletar, o que coletar e por quanto tempo manter é a clínica contratante, na condição de controladora (LGPD art. 5º, VI). O ClinCRM atua como operador (LGPD art. 5º, VII; GDPR art. 4(8)) — com duas exceções relevantes, descritas nos itens 3.4 e 4.3.

A DEFINIR: razão social, CNPJ e endereço da pessoa jurídica que opera o ClinCRM, e nome e contato do encarregado/DPO (LGPD art. 41; GDPR art. 37).

---

1. Visitante do site público

O site institucional tem três canais que recebem dados do visitante: o formulário de contato (que também recebe o pedido de assinatura), o chat de inteligência artificial e a medição de audiência. Fora deles, o sistema tem endereços públicos de autenticação — login, recuperação e redefinição de senha, verificação de e-mail —, descritos no capítulo de Segurança.

1.1 O que o chat do site faz com a sua mensagem

O chat do site usa um agente de âmbito global do ClinCRM. O provedor de inteligência artificial que recebe a sua mensagem é escolhido e contratado pelo ClinCRM, não por nenhuma clínica. Quanto a esse tratamento somos controladores, e respondemos pela escolha do subprocessador e pela transferência internacional correspondente.

Se houver provedor conectado, o texto que você digita sai do nosso servidor e é enviado a esse provedor para gerar a resposta. Se não houver, nada sai: o chat devolve um roteiro padrão, produzido localmente. O widget avisa isso na tela: "Respostas por IA, não envie dados pessoais". Do lado do banco ficam apenas contadores de consumo (provedor, modelo, quantidade de tokens), sem o conteúdo da conversa.

A DEFINIR: qual provedor de IA está conectado ao chat do site, seu país de processamento e o instrumento de transferência internacional (LGPD art. 33; GDPR art. 44-49).

1.2 O seu endereço IP é armazenado — e isso precisa ser dito com clareza

A medição de audiência não grava IP, identificador de visitante, descrição do navegador nem página de origem, e não cria uma linha por visita. Usuários logados são excluídos da contagem.

Mas o formulário de contato, o formulário de assinatura e o chat do site têm proteção contra abuso, e essa proteção grava o seu IP no banco: a chave de controle é o seu endereço IP associado ao formulário usado. O IP é o informado pelo servidor de borda que atende a sua conexão.

Finalidade: conter envio automatizado e abuso dos formulários. Prazo: hoje, indeterminado. Não existe no sistema nenhuma rotina que apague essas linhas por idade. O único apagamento existente remove a linha de controle depois de um login bem-sucedido ou de uma troca de senha — e isso alcança apenas as chaves de autenticação, nunca as criadas pelos formulários do site.

PENDENTE: expurgo automático por idade das linhas de controle de abuso, e prazo de retenção fixado para o IP de visitante.

1.3 O que fica gravado no seu navegador

O site público não instala nenhum cookie. Todos os cookies do produto são criados no momento do login (item 2.3). Quem nunca faz login não recebe cookie do ClinCRM. Ressalva honesta: os cookies da área logada valem para todo o domínio, então um usuário já logado que navegue pelo site público envia o cookie de sessão junto — e é exatamente isso que usamos para excluí-lo da contagem de audiência.

O que existe é armazenamento local no seu navegador, que não é enviado ao servidor:

A marca de visita alimenta um único envio ao servidor: um verdadeiro/falso dizendo se é a primeira visita do dia. O identificador em si nunca sai do seu aparelho. Recusar não quebra nada: a página funciona igual e a visita continua sendo contada de forma anônima; o que se perde é só a contagem de "visitantes distintos".

Duas ressalvas de honestidade:

• A escolha de idioma é gravada mesmo que você tenha recusado o aviso de cookies. O seletor de idioma não consulta a sua resposta ao banner.
• Hoje não existe, na interface, como revogar o aceite. O aviso só reaparece se a marca estiver ausente do navegador. A sua resposta fica gravada exclusivamente no seu aparelho: não guardamos nenhum registro que ligue essa escolha a você e não temos como alterá-la remotamente. O único caminho efetivo hoje é limpar os dados do site no seu navegador. Isso não atende ao direito de revogar o consentimento com a mesma facilidade com que ele foi dado (LGPD art. 8º, §5º; GDPR art. 7(3)). PENDENTE: controle de revisão e revogação do consentimento de métricas na própria página.

1.4 O que o site público não faz

Estas são ausências reais, e não promessas genéricas:

• Não há Google Analytics, Google Tag Manager, Meta Pixel, Hotjar, PostHog, Clarity, Mixpanel, Plausible ou qualquer outro rastreador de terceiro.
• Não há cookie de publicidade nem cookie de terceiro, e nenhuma parte do site lê ou escreve cookies pelo navegador.
• Não há armazenamento de sessão, banco local no navegador, cache offline nem service worker em nenhuma parte do produto.
• Nenhum recurso é buscado em servidor de terceiro. As fontes tipográficas são hospedadas por nós. Não há CDN, não há mapas, não há imagem remota.
• Isso é reforçado por uma política de segurança de conteúdo que bloqueia no navegador qualquer conexão, script, fonte ou imagem de fora do nosso domínio.
• O site público não coleta nenhum dado de saúde. Não existe campo de saúde em nenhum dos canais públicos; o formulário aceita apenas nome, contato e um texto livre. Pedimos que você não escreva informação de saúde nesse texto livre nem no chat.
• Nenhum dado de cartão de crédito é coletado em lugar nenhum do produto. A tela de assinatura não tem campo de número, validade ou código de segurança.

1.5 Um formulário do site que não coleta nada

O modal "Cadastrar minha clínica", acessível a partir das páginas de ajuda e de planos, exibe campos de nome, clínica, e-mail, telefone e mensagem, e depois mostra a frase "Recebemos seu interesse". Na verdade ele não coleta nem envia nada: os campos não são lidos e o envio apenas aguarda meio segundo e mostra a confirmação. Do ponto de vista de proteção de dados, nenhum dado desse formulário é tratado. Do ponto de vista de veracidade da informação ao titular, a mensagem exibida é incorreta e será corrigida. PENDENTE: fazer o modal enviar de fato o contato, ou remover o formulário e a frase de confirmação.

---

2. Usuário do sistema (equipe da clínica e equipe do ClinCRM)

2.1 Dados de cadastro e de conta

Fornecidos pelo próprio usuário ou por quem o cadastra na clínica.

2.2 Dados gerados pelo uso da conta

Quanto ao conteúdo dos chamados de suporte, o ClinCRM é controlador: a finalidade e os meios do atendimento são nossos. Se a clínica inserir dado de paciente no texto do chamado, quanto a esse dado seguimos como operadores.

Duas observações exigidas pela honestidade:

• A trilha de auditoria não registra IP nem descrição de aparelho. Ela também é gravada em regime de melhor esforço: se a gravação falhar, a ação segue e o erro é silenciado. Portanto não afirmamos que a trilha é completa.
• O registro de erros captura a mensagem e a pilha de execução da falha. Ele não é projetado para conter dado pessoal, mas não existe hoje nenhuma rotina que remova dado pessoal desses textos. Não afirmamos ausência aqui. PENDENTE: sanitizar mensagem e pilha antes de gravar o registro de erro, e definir prazo de retenção.

2.3 Cookies da área logada

São três, e apenas três. Todos são httpOnly (inacessíveis a scripts), SameSite=Lax e marcados como Secure em produção.

Fato que precisa constar: ao sair do sistema, apagamos o cookie de sessão, mas não apagamos o cookie de dispositivo. E o encerramento de sessão remove o cookie do navegador sem invalidar o token no servidor: um token já emitido permanece válido até expirar (até 7 dias) ou até um evento que revogue todas as sessões daquele usuário, como troca de senha ou alteração de perfis. Não afirmamos, portanto, que "ao sair, a sessão é encerrada no servidor". PENDENTE: revogar o token no encerramento de sessão e apagar o cookie de dispositivo no logout.

2.4 Preferências gravadas no navegador do usuário

clincrm_theme (tema visual), clincrm_slotmin (granularidade da agenda), clincrm_lang (idioma), clincrm_sidebar_colapsada (estado do menu) e clincrm_db_v2 (configurações dos módulos de WhatsApp, IA e automações).

Nenhuma dessas chaves contém dado de paciente. A gravação usa uma lista explícita do que pode ser salvo, que exclui médicos, pacientes, agenda e conversas. Chaves de API e tokens são substituídos por texto vazio antes de gravar. Ao sair, a chave de configuração é apagada e os dados em memória são zerados. As preferências de tema, idioma, agenda e menu permanecem após o logout.

2.5 Dados de usuário enviados a terceiro

Enviamos e-mails transacionais por um provedor externo, o Resend. Vão para ele: e-mail e nome do usuário, o assunto e o conteúdo do e-mail — que inclui código de verificação em dois fatores, link de redefinição de senha e link de verificação de e-mail.

No alerta de acesso de aparelho novo, o conteúdo enviado ao provedor inclui também o endereço IP e a descrição do aparelho do usuário, além de data, hora e nome da clínica.

Nenhum dado de paciente e nenhum dado clínico é enviado a esse provedor. Em todos os pontos do sistema que disparam e-mail, o destinatário é um usuário do sistema, nunca um paciente.

A DEFINIR: país de processamento do provedor de e-mail e instrumento de transferência internacional (LGPD art. 33; GDPR art. 44-49).

---

3. Paciente

Os dados de paciente existem apenas dentro do sistema, sob decisão e responsabilidade da clínica contratante. O site público não trata dado de paciente.

3.1 Cadastro

Fornecidos pelo paciente à clínica, ou digitados pela equipe: nome, data de nascimento, CPF, nome da mãe, endereço, telefone, e-mail, convênio e número da carteirinha.

Finalidade: identificar o paciente, marcar e confirmar atendimentos, faturar e cumprir obrigações de registro assistencial.

3.2 Dados gerados pelo atendimento e pela cobrança

Sobre campanhas de mensagem, é preciso ser exato: o registro da campanha guarda apenas o segmento escolhido e contadores, sem lista de nomes. Mas o disparo cria, para cada destinatário, uma conversa no inbox de WhatsApp, com telefone, vínculo com o paciente e o texto enviado. A lista de quem recebeu, portanto, existe — dentro do módulo de WhatsApp, não no registro da campanha. No envio, o modelo de mensagem é preenchido apenas com o primeiro nome do paciente.

PENDENTE: exigir autenticação obrigatória no canal que recebe as mensagens de WhatsApp, hoje dependente de configuração do servidor — é a única porta do sistema que pode aceitar conteúdo de mensagem de paciente sem autenticação.

3.3 Quem, dentro da clínica, vê o quê

O acesso é decidido pelo servidor, não pela tela: cada endereço da API verifica o perfil e devolve recusa por conta própria.

• Gestor — todos os módulos, incluindo prontuário e financeiro.
• Médico — prontuário, painel, chat interno, contratos, ajuda e configurações.
• Recepção — não tem acesso ao prontuário nem ao financeiro.
• Supervisor — recepção mais médico, sem gestão e sem financeiro.

Há minimização real por perfil: quem não tem o módulo médico recebe a lista de pacientes sem nome da mãe, endereço, tipo sanguíneo, alergias e doenças crônicas.

Duas ressalvas que precisam constar:

• CPF, telefone, e-mail e data de nascimento são entregues a todos os perfis autenticados da clínica, inclusive à recepção.
• A recepção não acessa o prontuário, mas acessa o inbox de WhatsApp, cujo conteúdo pode conter relato clínico — e que este documento classifica como dado de saúde (item 4.2).

Entre clínicas o isolamento é estrito: a clínica ativa é fixada no token assinado no momento do login, não vem da requisição, e cada consulta filtra por ela. Paciente de outra clínica simplesmente não existe para quem consulta. Esse isolamento é garantido pela aplicação, não pelo banco: todas as clínicas compartilham as mesmas tabelas.

3.4 Acesso da equipe do ClinCRM aos dados das clínicas

Isto precisa ser dito sem rodeio, porque afeta diretamente o paciente.

Contas da equipe do ClinCRM (perfis "desenvolvedor", "dono do projeto" e "IA") são contas globais. Elas podem trocar a clínica ativa da própria sessão para qualquer clínica cadastrada, sem lista de autorização prévia. A partir daí, enxergam prontuário, prescrição, exames, documentos e conversas de WhatsApp da clínica escolhida, com o mesmo código que o médico dela usa. Esses perfis incluem os módulos de prontuário e de pacientes, ou seja, incluem acesso a dado de saúde.

Salvaguardas existentes: essas contas são obrigadas a usar segundo fator de autenticação, e o perfil "IA" não escreve nada, apenas lê.

Limitações que não escondemos:

• A obrigação de segundo fator para conta global bloqueia apenas escrita, não leitura.
• As ações da equipe do ClinCRM dentro de uma clínica ficam registradas, mas na trilha global do projeto, e não aparecem na tela de auditoria da clínica. O registro da ação de conta global é gravado sem vínculo com a clínica, e a tela da clínica mostra apenas os registros vinculados a ela. Na prática, a clínica não consegue ver que abrimos um prontuário dela.
• Nem toda leitura é registrada. Abrir um prontuário é auditado, mas listar pacientes e baixar um documento anexado não são.

PENDENTE: tornar visível para a clínica, na trilha de auditoria dela, toda ação executada por conta da equipe do ClinCRM sobre dados dela; e auditar o download de documento de paciente.

Sobre o contrato entre o ClinCRM e a clínica. Existem hoje documentos de sistema gerados para toda clínica no momento da criação, com aceite registrado, na versão v1-2026-07-20. Eles contêm cláusulas de controlador e operador, tratamento de dado sensível (LGPD art. 11), direitos do titular (art. 18), segurança (art. 46), retenção de 20 anos do prontuário e comunicação de incidente (art. 48). Dois fatos precisam ser ditos:

• Esses textos foram redigidos pela equipe de engenharia, não foram revisados por advogado, e declaram eles próprios que não têm validade jurídica antes dessa revisão.
• Faltam neles cláusulas exigidas do operador (LGPD art. 39; GDPR art. 28(3)): autorização e lista de subprocessadores com aviso prévio de troca; devolução ou eliminação dos dados ao fim do contrato; direito de auditoria da clínica; dever de confidencialidade nominal da equipe do ClinCRM; assistência em avaliação de impacto; e a previsão expressa da hipótese de acesso técnico por conta global descrita acima.

BLOQUEANTE: revisão jurídica dos documentos de sistema que hoje declaram não ter validade jurídica antes dessa revisão.

BLOQUEANTE: corrigir ou remover a afirmação já publicada na página de privacidade do site de que existe "contrato próprio firmado na assinatura" — hoje ela se apoia nesses documentos autodeclarados sem validade jurídica.

A DEFINIR: contrato de operador com as cláusulas ausentes listadas acima, em especial a previsão expressa do acesso técnico por conta global e das condições em que ele pode ocorrer.

---

4. Dado pessoal sensível de saúde (LGPD art. 11; GDPR art. 9)

Esta subseção é separada de propósito. Dado de saúde é dado sensível e tem regime jurídico próprio.

4.1 Onde esse dado existe — e onde não existe

Dado de saúde existe apenas dentro do sistema, sob controle da clínica. O site público não tem nenhum campo de saúde: os canais públicos aceitam somente nome, contato, mensagem livre, texto do chat e métricas de página. Nenhum deles grava informação clínica, e nenhum deles está vinculado a paciente.

O ClinCRM, como operador, não usa dado de saúde de paciente para nenhuma finalidade própria: não há treinamento de modelo, não há perfilamento comercial, não há venda ou compartilhamento com anunciante. Não existe no sistema nenhum rastreador de terceiro que pudesse observar telas clínicas — a política de segurança do navegador bloqueia toda conexão externa a partir da página.

4.2 Inventário do dado de saúde

Todos os registros abaixo são vinculados a um paciente identificado e a uma clínica.

Correção de um mal-entendido comum: não existe no sistema nenhum campo, registro ou tela de "foto de procedimento estético". O campo fototipo da avaliação estética é a escala Fitzpatrick de tipo de pele (I a VI), não uma fotografia. Imagens de paciente só podem entrar pelo anexo genérico de documentos, que aceita PDF, JPEG e PNG de até 10 MB.

Laudo de bioimpedância enviado para leitura automática: o arquivo é interpretado localmente, no nosso servidor, e não é gravado nem enviado a terceiro.

4.3 Dado de saúde e provedores de inteligência artificial — declaração exata

O módulo de inteligência artificial é opcional e vem desligado. Há três situações, e elas são diferentes entre si:

1. Sem provedor conectado — nem pela clínica, nem pelo add-on "IA do ClinCRM": nada sai do nosso servidor. O sistema responde com um texto local e determinístico.
2. Com provedor conectado pela clínica: a chamada sai sob a credencial da própria clínica, que é cifrada em repouso. O destino é escolha dela.
3. Com o add-on "IA do ClinCRM" ativo: a chamada sai sob credencial da plataforma, e o subprocessador é escolhido por nós. Nesse caminho não existe credencial da clínica envolvida.

O chat do site público é um caso à parte e segue sempre a regra do item 1.1: o provedor é escolhido e contratado pelo ClinCRM, e nesse tratamento somos controladores.

Quando há provedor conectado, o que sai do nosso servidor é o seguinte:

Declaração que corrige material publicado anteriormente. Textos do nosso site e da nossa documentação afirmam que as mensagens vão ao provedor de IA "com minimização LGPD: sem CPF, endereço ou dado clínico". Isso não corresponde ao que o sistema faz. O que existe é uma instrução dada ao modelo para que ele nunca peça nem repita CPF, endereço ou dados clínicos. Essa instrução age sobre a resposta do modelo; ela não filtra o que é enviado. Não existe no caminho de envio nenhuma remoção, nenhum reconhecimento de CPF, nenhuma anonimização.

Portanto, a afirmação correta é: se o paciente escrever CPF, endereço ou um sintoma na conversa de WhatsApp, esse texto é enviado ao provedor de IA em uso. PENDENTE: implementar filtro programático de remoção de identificadores e de conteúdo clínico antes do envio ao provedor, e corrigir os textos publicados no site e no painel.

A lista de provedores não é fechada. Suportamos Anthropic, OpenAI e Google, mas a clínica pode cadastrar qualquer endereço compatível como provedor próprio, e nesse caso o destino é escolhido por ela e desconhecido por nós.

Registramos apenas contadores de consumo dessas chamadas — provedor, modelo, origem e quantidade de tokens. O conteúdo do que foi enviado ou recebido não é armazenado.

A DEFINIR: país de processamento de cada provedor de IA — inclusive o usado pelo add-on "IA do ClinCRM" e pelo chat do site — e o instrumento de transferência internacional correspondente.

A DEFINIR: cláusula contratual que obrigue a clínica a informar ao ClinCRM qualquer provedor próprio que ela cadastre.

4.4 Envio de dados de paciente a destino escolhido pela clínica

O módulo de automações tem um bloco "Chamar API externa". Quando a clínica o utiliza, o sistema envia para o endereço que ela configurou os registros selecionados no fluxo, incluindo nome completo e telefone do paciente, data, hora, situação, tipo e valor. Aqui não há a redução a primeiro nome que existe no bloco de IA. O endereço exige conexão segura (https://), mas o destinatário, sua identidade e seu país são escolha exclusiva da clínica.

4.5 Como esse dado é protegido — e o que ainda não é

Para não induzir a erro, declaramos o estado real:

• Senhas, tokens e códigos de recuperação são guardados apenas como hash.
• Estão cifrados em repouso (AES-256-GCM) exatamente dois itens: o segredo do segundo fator e a chave de API do provedor de IA.
• Os dados clínicos não são criptografados em repouso. Prontuário, CPF, diagnóstico e arquivos anexados são gravados em texto e em binário simples nas colunas do banco. Não há cifragem em nível de coluna, de banco ou de disco documentada. Não afirmamos que os dados de paciente estão criptografados em repouso. PENDENTE: cifragem em repouso do banco e dos anexos, e cifragem dos backups.
• O banco não é exposto à internet; escuta apenas localmente no servidor, e o acesso administrativo é feito por túnel seguro.
• O segundo fator de autenticação é opcional para os usuários de clínica, inclusive para quem acessa prontuário. Só é obrigatório para as contas da equipe do ClinCRM. PENDENTE: tornar o segundo fator obrigatório para todo perfil com acesso ao módulo médico.

A DEFINIR: país onde fica o servidor que hospeda o banco de dados. Essa localização precisa ser confirmada junto ao provedor de hospedagem (Hostinger) antes da publicação desta política.

---

5. Resumo das ausências — o que o ClinCRM não trata

Cada item abaixo é uma ausência real, e não uma generalidade:

1. Não coletamos dado de cartão de crédito, débito ou conta bancária em nenhuma tela. Existe a infraestrutura de faturamento da assinatura da clínica, hoje em modo simulado; nenhum adaptador de gateway de pagamento real está implementado, e configurar um provedor real faz a operação falhar com erro explícito. Nenhuma tela do produto coleta número, validade ou código de segurança de cartão.
2. Não usamos nenhuma ferramenta de análise de audiência de terceiro, nenhum pixel de rede social e nenhum rastreador publicitário. Nossa medição é própria, agregada, e não guarda identificador de visitante.
3. Não vendemos, alugamos nem cedemos dados pessoais a anunciantes ou corretores de dados. As únicas saídas externas do nosso servidor são: o provedor de e-mail (Resend), os provedores de inteligência artificial (Anthropic, OpenAI, Google ou o endereço que a clínica cadastrar), o serviço de WhatsApp hospedado por nós, o endereço de automação escolhido pela clínica, e a autoridade certificadora que emite o certificado de segurança do site (Let's Encrypt).
4. Não usamos dados de paciente para treinar modelos de inteligência artificial.
5. Não há integração com a API oficial da Meta para WhatsApp: não existe nenhuma chamada a serviços da Meta no produto. O transporte de WhatsApp é feito por um serviço hospedado no nosso próprio servidor, sem porta pública. Ressalva honesta: como o canal é o WhatsApp, a entrega final da mensagem ao paciente necessariamente trafega pela rede do WhatsApp, como em qualquer uso do aplicativo.
6. Não há login social nem autenticação por conta Google. A tela que menciona integração com agenda do Google é uma simulação e não faz nenhuma chamada de rede.
7. Não enviamos cópia do banco de dados para nenhum serviço externo de armazenamento. Os backups são diários e ficam no próprio servidor, com 7 dias de retenção.
8. O repositório de código não recebe nem hospeda dado de aplicação.
9. A trilha de auditoria não guarda IP nem descrição de aparelho.
10. O registro de consumo de IA não guarda o texto das conversas.
11. O registro de campanhas não guarda a lista de destinatários — mas o disparo cria uma conversa de WhatsApp por destinatário, e essa lista existe no módulo de WhatsApp (item 3.2).
12. Nenhum dado clínico é gravado de forma persistente no navegador do usuário — a lista do que pode ser gravado exclui pacientes, agenda, médicos e conversas, e é apagada ao sair.

Bases legais

Toda operação de tratamento de dados pessoais no ClinCRM precisa de uma base legal. Abaixo listamos uma base por finalidade — não usamos duas bases para a mesma finalidade nem trocamos de base depois. Se a base for consentimento, você pode recusar sem perder o serviço. Se não for consentimento, o pedido de exclusão obedece às regras da própria base (ver a seção de direitos do titular).

Duas observações antes da tabela, porque elas mudam quem responde pelo quê:

• Quando você é paciente de uma clínica que usa o ClinCRM, a clínica é a controladora dos seus dados de saúde e nós somos operadores (LGPD art. 5º, VI e VII; GDPR art. 4(7) e 4(8)). A base legal do tratamento clínico é definida pela clínica, no relacionamento dela com você. O que descrevemos abaixo para esses dados é a base que sustenta a nossa atuação como operador e o tratamento que fazemos por conta própria.
• Quando você é visitante do nosso site, cliente assinante ou usuário do sistema, nós somos os controladores. Também somos controladores do conteúdo dos chamados de suporte e das mensagens trocadas com o chat de inteligência artificial do site.

A DEFINIR: razão social, CNPJ e endereço do controlador

BLOQUEANTE: confirmar que o canal de privacidade publicado (privacidade@clincrmapp.com) existe, tem responsável designado e é monitorado, e indicar o nome e o e-mail do encarregado/DPO — nenhum prazo de resposta pode ser publicado antes disso

A DEFINIR: se há representante na União Europeia, para o caso de o GDPR ser aplicável — GDPR art. 27

Tabela de finalidades e bases

Teste de balanceamento do legítimo interesse

O legítimo interesse (LGPD art. 7º, IX e art. 10; GDPR art. 6(1)(f)) exige justificar a necessidade e demonstrar que ela não passa por cima dos seus direitos. Resumimos aqui os cinco casos em que o usamos (itens 3, 4, 11, 13 e 20 da tabela).

Interesse legítimo perseguido. Impedir que a conta de um profissional de saúde seja invadida, porque atrás dela existe prontuário de paciente; impedir força bruta e envio automatizado em massa nos formulários públicos; conseguir provar, se questionados, que uma pessoa aceitou determinada versão dos termos; responder a quem faz uma pergunta comercial no site; e enxergar as falhas técnicas do sistema para corrigi-las.

Necessidade. Para o item 3, não há como reconhecer um acesso suspeito sem guardar algo do acesso anterior — usamos IP e User-Agent, que são o mínimo para dizer "isto veio de um lugar novo". Para o item 4, o limite por IP é o mecanismo mais simples que funciona sem exigir cadastro, CAPTCHA ou perfilamento do visitante. Deliberadamente não aplicamos limite por IP na contagem de audiência do site, justamente para não criar registro de IP ali. Para o item 20, um erro só é corrigível se ficar registrado com o contexto em que aconteceu.

Balanceamento e expectativa razoável. São dados de conexão, não de conteúdo. Não montamos perfil comportamental, não cruzamos esses dados com outras bases, não fazemos publicidade, não vendemos e não compartilhamos com terceiros para fins próprios deles. Um usuário de um sistema de saúde espera que o login seja protegido e que receba aviso de acesso novo — o tratamento está dentro da expectativa. O alerta de acesso é, além disso, um benefício direto para o próprio titular.

Salvaguardas aplicadas. A trilha de auditoria não guarda IP nem User-Agent. Os dados de dispositivo têm teto de 20 por usuário, e os mais antigos são apagados. Você pode excluir um dispositivo conhecido a qualquer momento. O alerta de acesso tem limite de 5 envios a cada 15 minutos. Os cookies de sessão e de dispositivo são acessíveis apenas pelo servidor (httpOnly) e não são enviados em navegação vinda de outros sites (SameSite=Lax).

Salvaguardas que ainda faltam — e declaramos. Os IPs guardados no controle de tentativas de login não são apagados hoje: o registro é reaproveitado e nunca excluído por vencimento; não existe rotina de expurgo por idade. O IP e o User-Agent dos dispositivos conhecidos só saem por poda de quantidade, não por tempo. O registro de aceite de termos, com IP, nunca é apagado por desenho. Os registros de erro também não têm expurgo automático. PENDENTE: implementar expurgo por idade dos registros de tentativa de login e dos registros de erro, e definir prazo máximo de retenção de IP e User-Agent nos dispositivos conhecidos; sem isso, a retenção de dado de conexão é indefinida e o balanceamento fica mais frágil do que deveria

Seu direito de oposição. Você pode se opor a qualquer tratamento fundado em legítimo interesse (LGPD art. 18, § 2º; GDPR art. 21) pelo canal de privacidade. Avaliamos caso a caso; se o tratamento for o que impede a invasão da sua própria conta, explicaremos por que a oposição pode significar sair do serviço.

Onde há consentimento — e onde não há

Há consentimento em um único lugar: o aviso de cookies do site público, que controla se marcamos no seu navegador que você já visitou aquela página hoje. Ele é livre (o site funciona igual se você recusar), informado, específico e registrado com a sua resposta literal, "sim" ou "não", no seu próprio navegador, sob o nome clincrm_metricas. A marca de visita só é escrita depois do aceite, e recusar apaga as marcas que já existiam.

Falha conhecida na revogação. Consentimento tem de ser tão fácil de retirar quanto de dar (LGPD art. 8º, § 5º; GDPR art. 7(3)). A sua resposta fica gravada apenas no seu navegador: não temos como alterá-la remotamente e não guardamos nenhum registro que ligue essa escolha a você. Hoje, quem já respondeu ao aviso não tem, na interface, como voltar atrás — o aviso só reaparece se a marca sumir do navegador. O único caminho efetivo, no momento, é limpar os dados do site no seu navegador. PENDENTE: criar um controle visível de "rever minha escolha de cookies", que permita mudar de sim para não e vice-versa a qualquer momento, na própria página

Uma escrita fora do fluxo de consentimento. A preferência de idioma (clincrm_lang) é gravada no seu navegador quando você usa o seletor de idioma, sem consultar a resposta do aviso. Entendemos que essa gravação se enquadra na exceção de armazenamento estritamente necessário para prestar o serviço que você pediu ao clicar (Diretiva 2002/58/CE art. 5(3), segunda hipótese) e, portanto, dispensa consentimento. A DEFINIR: confirmação do advogado quanto a esse enquadramento

Não usamos consentimento como base para: manter sua sessão logada, proteger a conta, guardar prontuário, emitir nota fiscal, registrar auditoria ou executar o contrato de assinatura. Usar consentimento nesses casos seria falso — você não teria liberdade real de recusar, e a lei não admite consentimento obtido em situação de desequilíbrio (GDPR Considerando 43).

Não pedimos consentimento para publicidade, perfilamento ou venda de dados, porque não fazemos nada disso. Não há Google Analytics, Google Tag Manager, pixel de rede social, Hotjar, Mixpanel, PostHog, Clarity, Plausible, monitoramento de erro externo, mapa, script hospedado por terceiro ou fonte remota em nenhuma página nossa. As fontes são hospedadas por nós mesmos, e a política de segurança de conteúdo do site impede o seu navegador de abrir conexão com qualquer terceiro. Não existe cookie de terceiro nem cookie de publicidade.

Não há decisão automatizada com efeito jurídico ou impacto significativo sobre você (LGPD art. 20; GDPR art. 22). A IA sugere respostas de atendimento e pode criar um agendamento em nome do paciente. Esse agendamento é um registro real na agenda, com status "aguardando" e com um profissional da clínica atribuído automaticamente pelo sistema, sem critério clínico, e depende de confirmação da recepção. A IA não nega tratamento, não define diagnóstico, não recusa contrato e não pontua ninguém.

Ressalvas críticas sobre a base legal do tratamento por IA

Estas quatro afirmações precisam constar porque afetam diretamente a validade da base legal invocada nos itens 13, 16 e 17.

1. Não existe filtro técnico que remova dado pessoal antes de enviar à IA. O sistema instrui o modelo a nunca pedir nem repetir CPF, endereço ou dados clínicos, mas isso é uma instrução sobre a resposta do modelo, executada depois que o texto já foi enviado. Não há anonimização, detecção de CPF ou lista de bloqueio no caminho de envio. Se o paciente digitou o CPF ou o sintoma na conversa de WhatsApp, esse texto vai literalmente ao provedor. A única minimização programática real está no bloco de automação, que envia apenas o primeiro nome, a data, a hora e o status, no máximo 30 registros. PENDENTE: implementar redação e filtro de dado pessoal e clínico antes do envio ao provedor de IA — e, até lá, corrigir os textos hoje publicados na página de planos e na tela de configuração de provedores, que afirmam uma remoção que não ocorre

2. No chat do site, quem escolhe o provedor de IA somos nós. O chat público usa um agente de âmbito global do ClinCRM. O provedor que recebe a sua mensagem é escolhido e contratado por nós, não por nenhuma clínica. Somos controladores desse tratamento e respondemos pela escolha do subprocessador e pela transferência internacional correspondente.

3. A lista de provedores de IA não é fechada. Além de Anthropic, OpenAI e Google, a clínica pode cadastrar qualquer endereço compatível e o sistema enviará as conversas para lá. O mesmo vale para a chamada de API externa das automações, que aceita qualquer endereço seguro. Nesses casos, a escolha do destinatário e a base legal correspondente são responsabilidade da clínica controladora — inclusive quanto à transferência internacional. Há uma exceção: se a clínica assinar o serviço de IA gerenciada do ClinCRM, a chamada sai sob credencial nossa e o provedor passa a ser subprocessador nosso. Sem provedor conectado — nem pela clínica, nem pelo serviço gerenciado — o sistema responde localmente e nada sai do nosso servidor.

Sobre o contrato que deveria sustentar essa divisão de responsabilidade: hoje existem documentos de sistema gerados para toda clínica no momento da criação da conta (versão v1-2026-07-20), com aceite registrado, e eles já tratam de controlador e operador, dado sensível (art. 11), direitos do titular (art. 18), segurança (art. 46), retenção do prontuário e comunicação de incidente (art. 48). Mas esses textos foram redigidos pela equipe de engenharia, não passaram por revisão jurídica e declaram, no próprio corpo, que não têm validade jurídica antes dessa revisão. Faltam neles cláusulas exigidas pelo GDPR art. 28(3) e pela LGPD art. 39: autorização e lista de subprocessadores com aviso prévio de troca; devolução ou eliminação dos dados ao fim do contrato; direito de auditoria pela clínica; dever nominal de confidencialidade da nossa equipe; assistência em avaliação de impacto; e o tratamento da hipótese de acesso técnico às contas por perfil administrativo global. BLOQUEANTE: revisão jurídica desses documentos e inclusão das cláusulas faltantes — enquanto isso não ocorrer, nem esta política nem qualquer página do site podem afirmar que existe contrato de operador firmado

4. Nenhum destino externo tem país de processamento documentado. Não temos declarada a região de processamento do Resend (envio de e-mail), dos provedores de IA (Anthropic, OpenAI, Google), da autoridade certificadora (Let's Encrypt / ZeroSSL) nem do servidor onde a aplicação roda (Hostinger). Isso impede afirmar aqui, com honestidade, se há e como se legitima transferência internacional (LGPD art. 33; GDPR arts. 44 a 49). A DEFINIR: confirmar a região de processamento de cada subprocessador junto ao painel do fornecedor e ao contrato, e então declarar a base da transferência internacional — cláusulas-padrão, decisão de adequação ou outra BLOQUEANTE: firmar as cláusulas contratuais com cada subprocessador antes de publicar esta política

Se a base legal mudar

Se precisarmos tratar um dado para uma finalidade nova, avaliamos antes se a nova finalidade é compatível com a original (LGPD art. 6º, I; GDPR art. 6(4)). Não sendo compatível, informamos você e obtemos a base adequada antes de começar. Não trocamos silenciosamente a base de um tratamento já em curso.

Cookies e armazenamento no seu dispositivo

Por que o aviso fala em "cookies"

O aviso que aparece na primeira visita ao site usa a palavra "cookies" porque é o termo que as pessoas reconhecem. Sendo exato: a medição de audiência do ClinCRM não usa cookie nenhum. Ela usa localStorage, que é um espaço de armazenamento dentro do seu próprio navegador.

A diferença é prática, e é a favor de quem visita: cookie é enviado ao servidor em cada requisição; `localStorage` não é enviado nunca. As chaves de medição gravadas no seu navegador (clincrm_metricas e clincrm_visita:<página>) ficam só no seu aparelho. O que o servidor recebe é um valor verdadeiro/falso dizendo se aquela é a primeira visita do dia à página — não o identificador, não a chave, não o histórico.

Os cookies que existem no ClinCRM são apenas os de login e segurança da área do sistema, listados abaixo. Um visitante que nunca faz login não recebe cookie nenhum do ClinCRM — a gravação de cookie acontece apenas no momento da autenticação. Ressalva honesta: como os cookies valem para todo o domínio (path=/), quem já está logado e navega no site público continua enviando o cookie de sessão — e a medição usa exatamente isso para excluir essa pessoa da contagem.

Tabela completa

Esta é a lista integral. Não há outro cookie nem outra chave de armazenamento no produto.

\* A marca Secure (que impede o cookie de trafegar fora de HTTPS) é ativada em ambiente de produção por configuração de servidor. A documentação de infraestrutura registra que a chave capaz de desligá-la foi removida do ambiente de produção em 15/07/2026. A DEFINIR: confirmação, pelo responsável técnico, do valor efetivo em produção antes da publicação.

Nenhum dos itens de localStorage acima guarda dado de paciente, prontuário, agenda ou conversa: a lista de campos gravados exclui esses conteúdos por desenho, e o logout também os limpa da memória.

Duas observações de transparência:

1. `cliniccrm_did` não é apagado no logout. O logout remove apenas o cookie de sessão; nada apaga o cookie de dispositivo. Ele permanece no navegador até vencer (cerca de 400 dias) ou até você limpar os dados do site.
2. clincrm_db_v2 pode ser criada assim que a área do sistema é aberta, possivelmente antes da autenticação. PENDENTE: verificar esse comportamento em navegador e, se confirmado, adiar a escrita para depois do login.

O que NÃO existe

• Não há cookie de terceiro. Todos os cookies acima são gravados pelo próprio domínio do ClinCRM.
• Não há cookie de publicidade, remarketing ou perfilamento comercial. Nenhum.
• Não há rastreamento entre sites. Não usamos Google Analytics, Google Tag Manager, pixel de rede social, Hotjar, Mixpanel, PostHog, Clarity, Plausible nem equivalente.
• Nenhum script das nossas páginas lê ou grava cookie pelo navegador.
• Não usamos `sessionStorage`, IndexedDB, Cache API nem service worker.
• Não há `<iframe>` nem qualquer recurso carregado de endereço externo nas páginas. As fontes tipográficas são hospedadas por nós, a partir de arquivos do próprio projeto — não vêm do Google Fonts nem de CDN.
• A medição de audiência não guarda IP, User-Agent, referenciador nem identificador de visitante, e não cria um registro por visita: o servidor apenas soma contadores por página e por dia.

Ressalva necessária para não induzir a erro: a frase acima vale para a medição de audiência. O ClinCRM registra o endereço IP por outro caminho — no controle de excesso de requisições dos formulários públicos (contato, checkout e chat do site) e do login. Isso está descrito na seção sobre dados coletados e retenção, e não depende de cookie nem de localStorage.

A política de segurança do site bloqueia script externo

O ClinCRM envia, em todas as páginas, um cabeçalho Content-Security-Policy. Na prática, para o seu navegador:

• script-src 'self' — nenhum script vindo de outro domínio é carregado, mesmo que alguém tente injetá-lo;
• connect-src 'self' — a página não consegue enviar dados a nenhum servidor que não seja o nosso. Qualquer integração externa do produto acontece de servidor para servidor, nunca a partir do seu navegador;
• img-src 'self' data: blob: e font-src 'self' data: — nenhuma imagem ou fonte é buscada em servidor de terceiro;
• form-action 'self' — formulários não podem ser enviados para fora do nosso domínio;
• frame-ancestors 'none' — o site não pode ser embutido em página de terceiro.

Sobre o embutimento em página de terceiro, sejamos precisos: a aplicação emite X-Frame-Options: DENY; a configuração documentada do proxy de borda, que é quem responde ao seu navegador, emite SAMEORIGIN. O bloqueio efetivo em navegadores atuais vem da diretiva frame-ancestors 'none' da política de segurança de conteúdo. A DEFINIR: conferir o cabeçalho realmente devolvido por https://clincrmapp.com

Ressalva técnica honesta: a diretiva inclui 'unsafe-inline' para scripts e estilos do próprio documento, exigência do framework que usamos. Isso não permite script de domínio externo, mas significa que essa política, sozinha, não é uma defesa completa contra injeção de código (XSS). PENDENTE: migrar a política para `nonce` ou `hash`, eliminando `'unsafe-inline'`.

Como recusar

No site público, a escolha aparece no aviso exibido na primeira visita, com dois botões: "Aceitar cookies" e "Recusar cookies".

• Recusar grava clincrm_metricas = "nao" e, no mesmo instante, apaga todas as marcas de visita já existentes no seu navegador. Nenhuma marca nova é escrita depois disso.
• Recusar não prejudica nada: todas as páginas funcionam igual. O único efeito é que deixamos de saber se você é um visitante distinto naquele dia; a contagem agregada de visitas da página continua, sem qualquer identificador seu.
• Os cookies de sessão, de dispositivo e de 2FA não entram nessa escolha: são estritamente necessários para autenticar e proteger o acesso à área do sistema, com base no legítimo interesse em segurança da informação (LGPD art. 7º, IX, e art. 10; GDPR art. 6º(1)(f), e considerando 49). Recusá-los equivaleria a não poder entrar no sistema.

A escolha do idioma é gravada mesmo se você recusar. Quando você usa o seletor de idioma, a chave clincrm_lang é escrita sem consultar sua resposta ao aviso. Consideramos essa gravação estritamente necessária para entregar a página no idioma que você pediu — ela não identifica ninguém, não sai do seu aparelho e não alimenta medição. A DEFINIR: confirmação, pelo advogado, de que essa gravação se enquadra como estritamente necessária.

Como mudar de ideia depois

Aqui precisamos ser francos, porque a alternativa seria prometer algo que o produto ainda não faz.

Hoje não existe, na interface, um botão para revogar ou alterar a resposta ao aviso. O aviso só é exibido enquanto a chave clincrm_metricas estiver ausente do seu navegador; depois de respondido, ele não volta a aparecer, e não há outra tela que o reabra.

Também precisamos ser francos sobre o nosso limite: a sua resposta ao aviso fica gravada exclusivamente no seu navegador, e nós não temos como alterá-la remotamente. Não guardamos nenhum registro que ligue essa escolha a você, e não existe canal técnico pelo qual possamos executar a revogação no seu aparelho.

Por isso, hoje o único caminho efetivo é este: limpar os dados do site no seu navegador. Nas configurações do navegador, apague os dados armazenados por clincrmapp.com. Isso remove as chaves de localStorage e os cookies do ClinCRM. Na visita seguinte o aviso reaparece e você escolhe de novo. Se você estiver logado, será desconectado.

Você também pode nos escrever em privacidade@clincrmapp.com para registrar a sua manifestação e tirar dúvidas — mas, pelo que está exposto acima, esse contato não apaga por si só a marca gravada no seu aparelho. BLOQUEANTE: confirmar que essa caixa existe, tem responsável designado e é monitorada, antes de publicar o endereço nesta página.

Compromisso: vamos disponibilizar, na própria página de privacidade, um controle que permita rever e trocar a resposta ao aviso a qualquer momento, com o mesmo esforço com que ela foi dada — como exige a facilitação da revogação do consentimento (LGPD art. 8º, § 5º; GDPR art. 7º(3)). PENDENTE: implementar o controle de revisão do consentimento no site, e permitir reexibir o aviso a pedido.

A revogação vale para o futuro. Ela apaga as marcas de visita do seu aparelho, mas não desfaz os contadores agregados por página e por dia já somados no nosso banco — esses números não contêm identificador nenhum e não podem ser associados a você.

Nenhuma das escolhas desta seção afeta seus demais direitos como titular (LGPD art. 18; GDPR arts. 15 a 22), descritos na seção correspondente.

Com quem compartilhamos

O ClinCRM não vende dados pessoais. Não cedemos dados a terceiros para publicidade, marketing de terceiros, enriquecimento de base, score de crédito ou revenda. Não usamos dados de pacientes para treinar modelos de inteligência artificial, próprios ou de terceiros: o sistema não possui nenhuma rotina de treinamento de modelo. O único registro que guardamos sobre o uso de IA é uma linha de consumo — provedor, modelo, origem e número de tokens —, sem o texto enviado e sem o texto da resposta. Essa linha de consumo é criada inclusive quando o sistema responde localmente, em modo simulado, sem nenhuma chamada externa.

Uma ressalva honesta sobre o parágrafo acima: nós não treinamos modelos e não enviamos dados com essa finalidade. O que os provedores de IA contratados fazem com o conteúdo recebido é regido pelos contratos e políticas deles. PENDENTE: obter e arquivar, de cada provedor de IA efetivamente ativado, a cláusula contratual de "no training on customer data" e a política de retenção de prompts; até que isso esteja formalizado, não podemos garantir ao titular o que ocorre do lado do provedor.

Compartilhamos dados apenas nas hipóteses abaixo:

1. Com os operadores (LGPD art. 5º, VII; GDPR art. 28 — *processors*) listados nesta seção, estritamente para executar o serviço.
2. Com a própria clínica contratante, que é a controladora dos dados dos pacientes dela.
3. Por obrigação legal, regulatória ou ordem judicial (LGPD art. 7º, II e VI).
4. Quando a própria clínica configura um envio para um destino escolhido por ela (ver "Destinos escolhidos pela clínica").

---

Papéis: quem é controlador e quem é operador

A DEFINIR: razão social, CNPJ e endereço do controlador ClinCRM. A DEFINIR: nome e e-mail do Encarregado (DPO) — LGPD art. 41; GDPR art. 37.

---

Lista de operadores (subprocessadores)

Esta é a lista dos operadores possíveis. Um provedor de IA só recebe dados quando há um provedor conectado — pela clínica, ou por nós.

Servidor de WhatsApp: o componente que conversa com a rede do WhatsApp roda na nossa própria infraestrutura, na mesma rede interna, sem porta aberta para a internet. Não é um terceiro que recebe dados — está coberto pelo item "Hostinger". Ele recebe o telefone e o texto da mensagem para entregá-la na rede do WhatsApp.

---

Todas as saídas de dados do nosso servidor

Para que as listas não fiquem soltas, estas são todas as saídas de dados a partir do nosso servidor:

• o serviço de e-mail transacional (Resend);
• o provedor de IA, quando há provedor conectado;
• a rede do WhatsApp, pelo componente hospedado por nós;
• a autoridade certificadora (Let's Encrypt / ZeroSSL), que recebe apenas o nome do domínio na renovação do certificado;
• o endereço externo escolhido pela própria clínica em uma automação.

Não há outra. O GitHub recebe apenas o código-fonte, nunca dados da aplicação. Não há chamada a nenhum gateway de pagamento: nenhum adaptador real está implementado.

---

O que a IA envia, exatamente

1. Não há filtro técnico que remova dados pessoais antes do envio.

É preciso ser exato aqui. Quando um agente de IA está ativo, o texto das mensagens trocadas com o paciente é enviado integralmente ao provedor. Incluímos no prompt uma instrução ao modelo para que ele nunca peça nem repita CPF, endereço ou dados clínicos — mas isso governa o que o modelo responde, não o que sai do nosso servidor. Se o paciente digitar espontaneamente o CPF, o endereço ou um sintoma, esse texto vai para o provedor.

A única exceção é o bloco de automação, onde há minimização real e programática: sai apenas o primeiro nome, data, hora e status, no máximo 30 registros, sem telefone.

PENDENTE: implementar redação automática (mascaramento de CPF, telefone e endereço) antes do envio ao provedor de IA. Até lá, a interface do produto e o material comercial não devem afirmar que há "remoção" de dados no prompt.

2. A lista de provedores de IA não é fechada.

O sistema permite que a própria clínica cadastre um endereço de IA de sua escolha, compatível com o padrão de mercado. Nesse caso, o destino, o país e a identidade do receptor são definidos pela clínica, não por nós. A clínica que faz isso assume a responsabilidade de controladora por essa transferência.

3. No chat do site público, a escolha é nossa.

O assistente do site usa um agente de âmbito global do ClinCRM. O provedor de IA que recebe a mensagem do visitante é escolhido e contratado pelo ClinCRM, não por nenhuma clínica. Somos controladores desse tratamento.

---

Destinos escolhidos pela clínica (fora do nosso controle)

Além do provedor de IA personalizado, existe o bloco "Chamar API externa" nas automações. Quando a clínica monta esse bloco em um fluxo, o sistema envia para a URL indicada por ela os registros selecionados, incluindo nome completo e telefone do paciente — sem a minimização aplicada no bloco de IA. Exigimos que a URL use HTTPS. Não controlamos o destino, o país nem o receptor.

PENDENTE: exibir aviso na interface, no momento da configuração desse bloco, informando que ele envia nome e telefone de pacientes para fora, e registrar o aceite do responsável da clínica.

---

Transferência internacional de dados

Declaração de transparência: neste momento, não temos documentada a região de processamento de nenhum dos destinos externos — nem da infraestrutura que hospeda o banco, nem do serviço de e-mail, nem dos provedores de IA. Preferimos declarar a lacuna a afirmar uma localização que não podemos comprovar.

O que isso significa na prática: é provável que parte do tratamento ocorra fora do Brasil e fora do Espaço Econômico Europeu. A LGPD (art. 33) só admite transferência internacional em hipóteses específicas — entre elas, país com nível adequado de proteção (inciso I) ou garantias contratuais como cláusulas-padrão (inciso II). O GDPR exige o mesmo (arts. 44 a 49), tipicamente por decisão de adequação (art. 45) ou Cláusulas Contratuais Padrão (art. 46).

No caso do assistente do site público, a transferência internacional é nossa: o titular é o visitante, o controlador somos nós e o provedor foi escolhido por nós.

PENDENTE: levantar a região efetiva de cada operador, celebrar o contrato de tratamento de dados com cada um e publicar aqui o mecanismo de transferência correspondente. Enquanto isso não estiver feito, esta seção permanece incompleta e deve ser lida como tal.

PENDENTE: manter uma página pública e versionada com a lista atualizada de subprocessadores, e avisar as clínicas contratantes antes de incluir um novo (GDPR art. 28(2)).

---

O contrato com as clínicas

A relação entre o ClinCRM e cada clínica é de operador e controlador, e precisa de um contrato de tratamento de dados que satisfaça a LGPD (art. 39) e o GDPR (art. 28(3)).

BLOQUEANTE: os textos contratuais hoje aceitos pelas clínicas na contratação foram redigidos internamente, ainda não passaram por revisão jurídica e declaram, no próprio corpo, que não têm validade jurídica antes dessa revisão. Faltam neles cláusulas exigidas: autorização e lista de subprocessadores com aviso prévio de troca; devolução ou eliminação dos dados ao fim do contrato; direito de auditoria pela clínica; dever de confidencialidade nominal da equipe do ClinCRM; assistência em avaliação de impacto; e a previsão do acesso técnico da nossa equipe aos dados da clínica. Enquanto isso não for resolvido, nenhuma página pública pode afirmar que existe contrato próprio firmado na assinatura — a afirmação hoje publicada nesse sentido precisa ser removida ou corrigida.

---

O que nunca acontece

• Não há venda de dados pessoais. Nenhuma.
• Não há cessão de dados a terceiros para marketing — nem nosso, nem de parceiros.
• Não há uso de dados de paciente para treinar modelos de IA. Não existe rotina de treinamento no sistema, e o registro de uso de IA guarda apenas contadores de token, sem conteúdo.
• Não há nenhum rastreador de terceiros no site nem no sistema. Não existe Google Analytics, Google Tag Manager, pixel de rede social, Hotjar, PostHog, monitoramento de erros externo ou equivalente. A política de segurança de conteúdo do site só autoriza scripts e conexões vindos do nosso próprio servidor — na prática, o navegador do visitante não consegue enviar dado nenhum para um terceiro. Toda integração externa é feita de servidor para servidor.
• Não há CDN, firewall de aplicação externo ou proxy de terceiro na frente do sistema.
• Não há fonte de letra, mapa ou imagem carregada de servidor externo. As fontes são hospedadas por nós.
• Não há gateway de pagamento integrado. Existe a infraestrutura de faturamento da assinatura da clínica, hoje em modo simulado. Nenhum adaptador de gateway real está implementado: configurar um provedor real faz a operação falhar com erro explícito. Nenhuma tela do produto coleta número, validade ou código de segurança de cartão, e nunca armazenamos dados de cartão.
• Não há integração com a API oficial da Meta (WhatsApp Cloud API). É um plano futuro, não uma realidade atual.
• Não há login social nem autenticação por conta Google. A tela existente é simulada e não faz chamada de rede.
• Nenhum dado de paciente e nenhum dado clínico transita pelo serviço de e-mail. Em todos os pontos de envio, o destinatário é sempre um usuário do CRM.
• Nenhuma cópia do banco de dados sai da nossa infraestrutura. Os backups são locais. Não há, hoje, armazenamento externo recebendo cópia do banco.
• O laudo de bioimpedância enviado para leitura não vai para terceiro e não é armazenado: o processamento é local e determinístico.

---

Limites do que podemos afirmar hoje

• A lista de operadores acima descreve quem pode receber dados. Um provedor de IA só recebe dados se houver uma chave conectada — pela clínica ou por nós. A DEFINIR: publicar aqui a lista dos operadores **efetivamente ativos** hoje em produção, distinguindo-a da lista de operadores possíveis.
• A região física de processamento de cada operador externo não está documentada. A DEFINIR: confirmar com cada operador.
• Sobre a Meta, afirmamos apenas que a mensagem de WhatsApp trafega pela rede dela; não descrevemos o desenho interno da infraestrutura da Meta.

BLOQUEANTE: confirmar, antes da publicação desta página, que o segredo de verificação do canal que recebe as mensagens de WhatsApp está configurado no servidor. Sem ele, esse canal aceita conteúdo de mensagem de paciente sem autenticação — é a única porta do sistema nessa condição, e ela precisa estar fechada antes de qualquer publicação.

Por quanto tempo guardamos

Aviso de honestidade, e ele vale para toda a seção: hoje o ClinCRM não possui nenhuma rotina automática que apague dados por idade. As exclusões que existem no sistema são disparadas por ação humana ou pela substituição de um registro por outro mais recente — nenhuma delas tem cláusula de data. O único prazo que roda sozinho hoje é o das cópias de segurança (7 dias). Onde a tabela abaixo indica um prazo sem marca de pendência, esse prazo é cumprido de fato. Onde aparece [PENDENTE] ou [A DEFINIR], o prazo é aquele a que nos comprometemos — e ainda não está em vigor.

---

Tabela de prazos

---

Guarda do prontuário: os 20 anos da Resolução CFM 1.821/2007

O prontuário médico é o caso em que a lei obriga a guardar, e essa obrigação prevalece sobre o pedido de eliminação do titular (LGPD art. 16, I, e art. 18, §4º). A Resolução CFM 1.821/2007 estabelece o prazo mínimo de 20 anos a partir do último registro do paciente.

O que o sistema faz hoje, com exatidão:

1. O sistema não conta esse prazo. Não existe verificação de data em lugar nenhum. O número 20 aparece apenas no texto contratual exibido ao cliente.
2. O sistema não impede a exclusão antes dos 20 anos. A exclusão de um paciente apaga consultas, prescrições, medicamentos, exercícios, documentos, agendamentos, bioimpedância, planos alimentares e avaliações estéticas em cascata, sem consultar a data do último atendimento.
3. A única barreira implementada é fiscal, não médica: paciente com cobrança paga não pode ser apagado.
4. Há uma barreira correlata do lado do profissional: um profissional que tenha prontuário registrado não pode ser excluído — o prontuário é do paciente, não do médico.

[BLOQUEANTE: os documentos contratuais que hoje sustentam o prazo de 20 anos, o tratamento de dado sensível, os direitos do titular e a comunicação de incidente foram redigidos pela equipe de engenharia e declaram, no próprio texto, que não foram revisados por advogado e que não têm validade jurídica antes dessa revisão. Enquanto isso não for sanado, nenhuma página pública deve apresentá-los como contrato firme.]

[PENDENTE: implementar (a) o bloqueio de exclusão de prontuário dentro do prazo da CFM 1.821/2007, com a data do último registro como critério, e (b) a rotina de eliminação ao término dos 20 anos.]

[A DEFINIR: quem é o controlador do prontuário para efeito desse prazo. No modelo do ClinCRM, a clínica é a controladora dos dados de seus pacientes e o ClinCRM atua como operador (LGPD art. 5º, VI e VII). Cabe ao contrato entre as partes definir se, ao término do contrato, a obrigação de guarda dos 20 anos permanece com a clínica — hipótese que exige entrega dos dados a ela — ou se o ClinCRM a assume por delegação, com remuneração e responsabilidade próprias.]

---

O que acontece quando você exclui um paciente

A clínica pode excluir um paciente pelo sistema, atendendo ao direito de eliminação (LGPD art. 18, VI; GDPR art. 17). Nesse momento, apagamos em cascata todo o prontuário, os anexos, os agendamentos, as medições, os registros de atendimento vinculados e as cobranças ainda não pagas. O sistema também neutraliza o nome do paciente em campos de texto livre de movimentação de estoque.

Sobrevive à exclusão do paciente:

[PENDENTE: fazer a exclusão do paciente alcançar também o histórico de WhatsApp e os lançamentos financeiros que não estejam sob prazo fiscal.]

---

O que sobrevive ao encerramento do contrato com a clínica

Aqui precisamos ser diretos, porque é o ponto em que a expectativa do cliente e o produto mais divergem hoje.

Não existe, no sistema, exclusão de clínica. O que existe é suspensão lógica — um campo que marca a clínica como inativa. A única exclusão de clínica prevista no sistema é o desfazimento automático de uma criação que falhou no meio, não um encerramento de conta. Além disso, várias partes da base são protegidas contra remoção enquanto houver registros vinculados: usuários, uso de IA, aceites de termo, documentos legais, contratos, conversas de chat e de WhatsApp.

Em termos práticos: encerrado o contrato, os dados da clínica não são apagados — a conta é desativada e a base permanece.

Não existe função de exportação de dados. Não há tela, botão ou rotina de exportação ou de portabilidade. As menções a "exportação" no site e nos termos descrevem um processo manual, conduzido por pessoas da nossa equipe. O mesmo vale para anonimização: não há nenhuma função que anonimize dados — a palavra aparece apenas em texto de tela e de contrato.

[PENDENTE: implementar o encerramento de conta com (a) exportação completa dos dados para a clínica controladora, (b) período de carência definido e (c) eliminação efetiva ao fim dele, respeitados os prazos legais de prontuário e fiscais.]

[PENDENTE: implementar exportação de dados do titular e da clínica em formato estruturado e interoperável (LGPD art. 18, V; GDPR art. 20), e função de anonimização como alternativa à eliminação quando houver prazo legal de guarda.]

[A DEFINIR: prazo contratual de carência entre o encerramento do contrato e a eliminação dos dados, e a forma de entrega da base à clínica — deve constar do contrato de prestação de serviço e do acordo de tratamento de dados entre controlador e operador (LGPD art. 39; GDPR art. 28).]

[A DEFINIR: os documentos contratuais atuais não contêm a cláusula de devolução ou eliminação dos dados ao fim do contrato exigida pelo art. 28(3) do GDPR e pelo art. 39 da LGPD, nem a autorização e a lista de subprocessadores com aviso prévio de troca, o direito de auditoria da clínica, o dever nominal de confidencialidade da nossa equipe, a assistência em avaliação de impacto e a hipótese de acesso técnico por conta global. Precisam ser redigidas e assinadas.]

---

Correções ao que já estava publicado

Registramos aqui, para transparência, três afirmações da versão anterior desta política que não correspondem ao funcionamento do sistema e que foram corrigidas acima:

1. "Tokens de redefinição de senha são apagados após o uso" — não são. São marcados como usados e a linha permanece no banco.
2. "Encerrado o prazo ou a finalidade, os dados são eliminados ou anonimizados" — não há nenhum mecanismo que faça isso. Nenhuma eliminação por prazo ou por cessação de finalidade existe hoje no sistema.
3. Nada era dito sobre a retenção indefinida de endereços IP, sobre a sobrevivência do histórico de WhatsApp à exclusão do paciente, nem sobre a inexistência de exclusão de clínica. Os três pontos passam a constar.

---

O que ainda falta nesta seção

[BLOQUEANTE: não publicar nenhum prazo de resposta a pedidos de titular antes de confirmar que existe caixa de correio ativa para privacidade, responsável designado e rotina de monitoramento.]

[A DEFINIR: identificação do controlador (razão social, CNPJ, endereço da sede), nome e contato do encarregado pelo tratamento de dados pessoais (LGPD art. 41), e o canal oficial para exercício dos direitos do titular.]

[A DEFINIR: se há alguma limpeza manual de tabelas feita diretamente no servidor, fora do que está implementado no produto — se houver, precisa ser descrita aqui, com critério e periodicidade.]

Seus direitos

Esta parte da política explica os direitos que você tem sobre os seus dados pessoais, o que o ClinCRM entrega na prática quando você exerce cada um deles, e o que ainda não está implementado no sistema.

Onde a lei pede algo que o nosso software ainda não faz de forma automática, dizemos que o atendimento é manual e marcamos a pendência. Preferimos declarar uma lacuna a publicar uma promessa que não cumprimos.

---

1. Antes de tudo: de quem você deve cobrar esses direitos

O ClinCRM é usado por grupos de pessoas muito diferentes, e isso muda para quem você escreve.

Sobre o visitante do site, uma precisão: os contatos enviados pelo formulário de leads e pelo checkout ficam num escopo global do produto, separado de qualquer clínica, e só são lidos por contas internas da nossa equipe. Nenhuma clínica assinante enxerga leads do site.

A DEFINIR: razão social, CNPJ e endereço completo do controlador ClinCRM

---

2. Os direitos, lado a lado — LGPD e GDPR

A LGPD (Lei 13.709/2018) e o GDPR (Regulamento UE 2016/679) protegem quase as mesmas coisas com nomes diferentes. A tabela abaixo põe os dois lado a lado e diz o que você recebe na prática hoje.

---

3. Revogação de consentimento — uma limitação que precisamos declarar

No site público, a única coisa que depende do seu consentimento é a marca de "visitante distinto" das métricas de audiência. Ela fica guardada no armazenamento local do seu próprio navegador, e nada dela sai do seu aparelho além de um "sim/não".

Limitação real: a revogação depende do seu aparelho. A sua resposta ao banner fica gravada só no seu navegador, e nós não temos como alterá-la remotamente — não guardamos nenhum registro que ligue essa escolha a você, e por isso também não podemos registrar uma revogação em seu nome. Depois que você responde ao banner, ele não volta a aparecer. Hoje o único caminho efetivo é limpar os dados do site no seu navegador.

PENDENTE: controle permanente de "rever minha escolha de cookies" na própria página de privacidade, que hoje não existe na interface

---

4. Decisão automatizada e uso de inteligência artificial

Nenhuma decisão com efeito jurídico ou impacto significativo sobre você é tomada automaticamente por máquina no ClinCRM. Não há sistema de pontuação, triagem clínica automática, aprovação ou negação de atendimento por algoritmo, nem perfilamento com esse efeito.

O que existe é assistência conversacional: um agente de IA que pode responder mensagens de WhatsApp e marcar horários, e um chat no site que responde dúvidas comerciais. Três pontos que você precisa saber:

• O agendamento feito pela IA é real, não um rascunho. Quando você pede um horário ao agente, o sistema cria um agendamento de verdade, com status "aguardando", e atribui um profissional da clínica automaticamente, sem critério clínico — é uma atribuição operacional, sujeita a confirmação pela recepção. O vínculo com o seu cadastro é definido pelo servidor, não pelo modelo de IA.
• Sempre existe um humano do outro lado. Há um mecanismo de escalonamento por palavras-chave configuradas pela clínica, que transfere a conversa para uma pessoa.
• Você pode pedir revisão por pessoa natural (LGPD art. 20; GDPR art. 22) se entender que uma resposta automatizada afetou seus interesses. Atendemos esse pedido pelos canais do item 5.

Para onde vai o texto que você escreve. O conteúdo das mensagens trocadas com o agente sai do nosso servidor para o provedor de IA. Não há filtro técnico que remova CPF, endereço ou dado clínico do que você escreve — o que existe é uma instrução ao modelo para não pedir nem repetir esses dados.

No chat do site, o provedor de IA que recebe a sua mensagem é escolhido e contratado pelo ClinCRM, não por nenhuma clínica. Somos controladores desse tratamento e respondemos pela escolha do subprocessador (Anthropic, OpenAI ou Google, conforme a configuração vigente) e pela transferência internacional correspondente. Nesse chat, o texto da sua mensagem não é gravado no nosso banco de dados: a única escrita que a conversa produz é uma linha de contagem de consumo (provedor, modelo, origem e número de tokens), sem conteúdo. A seção de compartilhamento desta política detalha os destinatários.

---

5. Como pedir

Canal principal: privacidade@clincrmapp.com

BLOQUEANTE: confirmar que esta caixa de e-mail existe, está sob monitoramento diário e tem responsável designado — sem isso, não publicar esta política nem o prazo de resposta do item 9

Encarregado pelo Tratamento de Dados Pessoais (DPO) — LGPD art. 41; GDPR arts. 37 a 39:

• Nome: A DEFINIR: nome completo do encarregado
• Contato: A DEFINIR: e-mail direto do encarregado
• Endereço para correspondência: A DEFINIR: endereço postal
• A DEFINIR: se há representante na União Europeia nos termos do art. 27 do GDPR, ou se o ClinCRM se enquadra em alguma das exceções do art. 27(2)

O que escrever no pedido, para agilizar:

1. Qual direito você quer exercer (pode ser mais de um).
2. Se você é paciente, funcionário de clínica ou visitante do site.
3. Se for paciente: o nome da clínica onde é atendido.
4. Um contato para resposta.

Você não precisa usar linguagem jurídica, nem citar artigo de lei. Um pedido em português comum é válido.

---

6. Confirmação de identidade — o que pedimos e por quê

Antes de entregar dados ou apagar um cadastro, precisamos ter certeza de que você é quem diz ser. Essa checagem existe para proteger você: entregar o prontuário de alguém para a pessoa errada é, em si, um vazamento de dado sensível de saúde.

O que pedimos, do menos invasivo para o mais:

Compromissos que assumimos no atendimento manual. O que segue não descreve uma rotina automatizada do sistema; é a conduta que nos obrigamos a seguir:

• Pedir o mínimo necessário. Não exigimos documento quando o e-mail cadastrado já resolve.
• Não guardar cópia de documento apresentado só para conferência de identidade além do tempo de tratar o pedido.
• Se a verificação falhar, dizer exatamente por quê e como você pode tentar de novo. Não recusamos em silêncio.
• Nunca pedir senha, código de acesso ou dado de cartão para confirmar identidade. Se alguém pedir isso em nosso nome, não é a gente. Nenhuma tela do produto coleta número, validade ou código de segurança de cartão.

PENDENTE: procedimento interno escrito de verificação de identidade e rotina de descarte dos documentos recebidos, com registro de cada pedido atendido e do critério usado — hoje não existe fluxo de requisição de titular dentro do produto, o atendimento é integralmente manual

---

7. Quando o pedido é sobre dado de paciente: quem responde é a clínica

Este ponto é central e vale repetir com todas as letras.

Para os dados de pacientes, a clínica é a controladora e o ClinCRM é o operador (LGPD art. 5º, VI e VII; GDPR arts. 4(7) e 4(8), e art. 28). Quem decide o que é coletado, para quê e por quanto tempo é a clínica. Nós fornecemos o software e processamos os dados seguindo as instruções dela.

Na prática:

1. Se você é paciente e escreve para nós, encaminhamos seu pedido à clínica em até A DEFINIR: prazo interno de encaminhamento e avisamos você de que encaminhamos, identificando a clínica responsável.
2. Nós não apagamos nem alteramos o prontuário de um paciente por conta própria. A exclusão é executada pela clínica, pela interface do sistema.
3. Damos apoio técnico à clínica para que ela consiga cumprir o prazo dela: levantamos os registros, montamos a exportação, executamos o que ela determinar.
4. Se a clínica não responder, você pode reclamar diretamente à autoridade (item 10), e o direito de acionar a clínica é seu — nós não somos intermediários obrigatórios.

O contrato que rege esse papel de operador. Toda clínica aceita, na criação da conta, um conjunto de documentos gerados pelo sistema, com o aceite registrado e datado. Duas declarações honestas sobre eles:

• Esses textos foram redigidos pela nossa equipe de engenharia e ainda não passaram por revisão de advogado; eles próprios declaram que não têm validade jurídica antes dessa revisão. BLOQUEANTE: revisão jurídica desses documentos e correção de qualquer trecho do site que já os apresente como contrato validado
• Faltam neles cláusulas exigidas do operador (LGPD art. 39; GDPR art. 28(3)): autorização e lista de subprocessadores com aviso prévio de troca; devolução ou eliminação dos dados ao fim do contrato; direito de auditoria pela clínica; dever de confidencialidade nominal da nossa equipe; assistência em avaliação de impacto; e a hipótese de acesso técnico à base por conta global da nossa equipe. BLOQUEANTE: incluir essas cláusulas antes de apresentar o instrumento como contrato de operador

O que a exclusão de um paciente apaga, e o que sobrevive. Você precisa saber antes de pedir:

Um esclarecimento sobre dinheiro: a retenção fiscal de 5 anos alcança o que já foi liquidado. Uma cobrança em aberto é destruída junto com o cadastro, antes de qualquer prazo fiscal.

Quando a eliminação pode ser legitimamente recusada (LGPD art. 16; GDPR art. 17(3)):

• Paciente com cobrança já paga: o sistema recusa a exclusão inteira e devolve erro, por causa da obrigação fiscal de guarda. Nesse caso o caminho seria a anonimização — que ainda não implementamos (item 2).
• Profissional de saúde com prontuário lançado: a conta não é excluída, porque o prontuário pertence ao paciente, não ao profissional, e há guarda obrigatória do registro médico (Resolução CFM 1.821/2007).
• Registro de aceite de termos: nunca é apagado, por ser a prova de consentimento e de contratação.

Em qualquer recusa, dizemos qual é a base legal e por quanto tempo o dado ficará retido.

Exclusão de conta de clínica: PENDENTE: hoje não existe no produto uma função que exclua uma clínica; o que há é suspensão lógica da conta. Um pedido de encerramento com eliminação da base é atendido por procedimento manual, ainda não padronizado.

---

8. Uma pendência de segurança que afeta o seu dado

BLOQUEANTE: o canal que recebe as mensagens de WhatsApp aceita conteúdo sem autenticação quando o segredo de verificação não está configurado no ambiente. Garantir a exigência do segredo em produção antes da publicação desta política.

---

9. Prazo de resposta

Se aplicarmos os dois regimes ao mesmo pedido, seguimos o prazo mais curto.

Se não formos atender, informamos dentro do mesmo prazo, com a justificativa de fato e de direito, e com a informação de que você pode reclamar à autoridade e ao Judiciário (LGPD art. 18, § 4º; GDPR art. 12(4)).

Quando você é paciente e o pedido é da alçada da clínica, o prazo legal corre para ela. Nós encaminhamos e apoiamos, mas não podemos responder no lugar do controlador.

Este prazo só vale a partir do momento em que o canal do item 5 estiver confirmado e monitorado.

---

10. Gratuidade

Exercer seus direitos é gratuito. Não cobramos taxa de nenhum tipo, em nenhuma frequência, para confirmar tratamento, dar acesso, corrigir, exportar ou eliminar dados (LGPD art. 18, § 5º combinado com art. 19; GDPR art. 12(5)).

A única ressalva é a que a própria lei europeia admite: se um mesmo pedido for manifestamente infundado ou repetitivo, o GDPR (art. 12(5)) permite cobrar um valor razoável de custo administrativo ou recusar o pedido. Se algum dia usarmos essa faculdade, explicaremos por escrito o motivo e o cálculo — e o ônus de demonstrar o caráter abusivo é nosso, não seu.

Você não precisa justificar por que quer exercer um direito.

---

11. Se você discordar da nossa resposta

Você não depende da nossa boa vontade. Existem três caminhos, e eles são cumulativos — usar um não impede os outros.

1. Fale conosco de novo. Peça revisão ao encarregado A DEFINIR: contato do encarregado. É o caminho mais rápido e frequentemente resolve.

2. Reclame à autoridade de proteção de dados.

*No Brasil — ANPD (Autoridade Nacional de Proteção de Dados)* Peticionamento eletrônico pelo sistema oficial do Governo Federal (gov.br), com canal de denúncias e petições de titular em www.gov.br/anpd. A reclamação é gratuita e você pode fazê-la sozinho, sem advogado. Recomendação prática: a ANPD costuma exigir que você tenha tentado antes o contato com o controlador — por isso vale guardar o e-mail que nos enviou e a nossa resposta.

*Na União Europeia — autoridade de controle do seu país* Você pode reclamar (GDPR art. 77) à autoridade do Estado-Membro onde você reside, onde trabalha, ou onde ocorreu a suposta violação. Você escolhe. A lista oficial e atualizada das autoridades nacionais é publicada pelo European Data Protection Board (EDPB), em edpb.europa.eu. Exemplos: CNIL (França), AEPD (Espanha), Garante (Itália), BfDI e autoridades estaduais (Alemanha), CNPD (Portugal).

*Fora do Brasil e da UE*: A DEFINIR: se o ClinCRM atender titulares em outras jurisdições — Reino Unido, Suíça, países da América Latina —, listar as autoridades correspondentes

3. Vá ao Judiciário ou aos órgãos de defesa do consumidor. Você pode acionar a Justiça a qualquer momento, sem precisar esgotar as vias anteriores (LGPD art. 22 e art. 42; GDPR arts. 79 e 82). No Brasil, também cabe reclamação nos Procons e no consumidor.gov.br.

A DEFINIR: foro de eleição para litígios contratuais — observando que, em relação de consumo e em matéria de proteção de dados, prevalece o foro do domicílio do titular

---

12. Resumo honesto do que ainda não fazemos

Reunimos aqui, num lugar só, todas as pendências espalhadas nesta seção — para que você não precise procurar, e para que ninguém possa dizer que escondemos.

Nada nesta lista limita os seus direitos. São direitos legais, exigíveis desde já; o que declaramos é que hoje os cumprimos por processo humano, e não por automação — e que estamos comprometidos a automatizá-los.

Segurança da informação

O ClinCRM guarda prontuário, diagnóstico, prescrição e documentos de saúde. Isso é dado pessoal sensível (LGPD art. 5º, II; GDPR art. 9º). Adotamos as medidas descritas abaixo. Onde uma proteção ainda não existe, a ausência está declarada no mesmo lugar, com a pendência correspondente.

Nenhum sistema é 100% seguro. Não prometemos segurança absoluta, inviolabilidade nem ausência de incidente. O que assumimos é o dever de adotar medidas técnicas e administrativas aptas a proteger os dados (LGPD art. 46; GDPR art. 32) e o dever de comunicar quando algo der errado.

---

1. Senha e acesso à conta

2. Sessão

• A sessão é um token JWT assinado (HS256) guardado em cookie httpOnly — ou seja, JavaScript da página não consegue ler o cookie. A chave de assinatura fica na configuração do servidor; o sistema recusa iniciar sem ela. Nenhuma chave está no código-fonte.
• Atributos do cookie: httpOnly, SameSite=Lax, Path=/, validade de 7 dias. O atributo Secure (só trafega por HTTPS) é ligado automaticamente em produção. Existe uma opção de configuração capaz de desligá-lo, prevista para desenvolvimento local; a documentação interna de infraestrutura registra que ela foi removida do ambiente de produção em 15/07/2026. A DEFINIR: conferir, no servidor de produção, que o atributo `Secure` está efetivamente ativo hoje
• Revogação existe. Cada usuário tem um contador de versão de sessão, conferido no banco a cada requisição. Trocar a senha, redefinir a senha por e-mail ou alterar os papéis de um usuário incrementa esse contador e derruba todas as sessões daquele usuário em qualquer dispositivo.
• Limitação que declaramos abertamente: o botão "sair" apaga o cookie do navegador, mas não invalida o token no servidor. Um token que já tenha sido copiado por um terceiro continua aceito até expirar (no máximo 7 dias) ou até um dos eventos acima subir a versão de sessão. Não afirmamos que "ao sair, a sessão é encerrada no servidor" — hoje isso seria falso. PENDENTE: invalidar a sessão no servidor no momento do logout
• O conteúdo do token inclui identificador, nome e e-mail do usuário, papéis e a clínica ativa. O token é assinado, não cifrado: quem obtiver o cookie consegue ler esses campos.

3. Verificação em duas etapas (2FA)

• Implementação própria de TOTP (RFC 6238): 6 dígitos, janela de 30 segundos, tolerância de um passo. Compatível com Google Authenticator, Authy e equivalentes. O segredo é guardado cifrado no banco.
• Proteção contra reuso de código: o último passo de tempo aceito é registrado e códigos iguais ou anteriores são recusados.
• Alternativa por e-mail: código de 6 dígitos válido por 10 minutos, guardado apenas como hash com chave (HMAC-SHA256), exigindo e-mail já verificado. É apagado assim que usado.
• Códigos de recuperação: 8 códigos, guardados apenas como hash (SHA-256) e consumidos no uso.
• Todas as comparações de código são feitas em tempo constante.
• Entre a senha correta e o segundo fator existe um token intermediário separado, com validade de 5 minutos. A sessão real só nasce depois do segundo fator.

O que o 2FA ainda não cobre — declarado por honestidade:

• O 2FA é obrigatório apenas para as contas globais do ClinCRM (nossa equipe). Para os usuários das clínicas — gestor, médico, recepção — ele é opcional. Nenhuma regra hoje obriga 2FA para quem acessa prontuário. PENDENTE: tornar o 2FA obrigatório para perfis com acesso a dado de saúde
• Mesmo para a conta global, a trava por falta de 2FA bloqueia operações de escrita, não de leitura. Uma conta global sem 2FA ativo ainda consegue ler dados. PENDENTE: bloquear também a leitura enquanto o 2FA não estiver ativo

4. Cifra de segredos e o que NÃO é cifrado

Usamos AES-256-GCM (com vetor de inicialização aleatório e verificação de integridade) para cifrar, no banco, exatamente duas coisas:

1. o segredo do TOTP de cada usuário com 2FA;
2. a chave de API do provedor de IA cadastrada pela clínica (dela ficam legíveis apenas os 4 últimos dígitos, para identificação na tela).

A credencial de IA da própria plataforma — usada quando a clínica contrata a IA gerenciada pelo ClinCRM e quando o chat do site é atendido por um provedor externo — fica na configuração do servidor, fora do banco de dados.

A chave de cifra é derivada por hash direto do segredo do servidor, não por função de derivação com salt e iterações (PBKDF2, scrypt ou Argon2). Como consequência, trocar o segredo do servidor hoje tornaria indecifráveis todos os segredos de TOTP e todas as chaves de IA das clínicas — o 2FA de toda a base precisaria ser reconfigurado. PENDENTE: migrar a derivação da chave para um KDF apropriado e criar um plano de rotação de chave que preserve os segredos de 2FA e as chaves de IA

Declaração explícita de ausência, porque a política precisa afirmar ausências:

> Os dados de paciente não são cifrados em nível de campo. Nome, CPF, nome da mãe, endereço, telefone, diagnóstico (CID), texto do prontuário, prescrição, medições de bioimpedância, planos alimentares, avaliações estéticas e os arquivos anexados (exames, laudos, imagens) ficam em texto claro no banco de dados. > > Não há cifra de disco nem cifra em nível de banco documentada. Não afirmamos "dados criptografados em repouso", porque não seria verdade. > > PENDENTE: avaliar e implantar cifra em repouso — no mínimo cifra de volume no servidor, e cifra de campo para CPF e anexos

Também são irreversíveis por desenho (hash, não cifra, portanto não recuperáveis nem por nós): senha, tokens de redefinição de senha e de verificação de e-mail, códigos de recuperação do 2FA, código de e-mail do 2FA e o identificador do cookie de dispositivo.

5. Transporte (TLS) e cabeçalhos de segurança

Todo o tráfego entre o navegador e o ClinCRM passa por HTTPS. O certificado é emitido automaticamente por autoridade certificadora pública (Let's Encrypt, com ZeroSSL como alternativa), e o servidor de borda negocia TLS 1.3. O único processo com portas abertas para a internet é esse servidor de borda; o banco de dados escuta apenas no endereço interno da máquina e nunca está exposto à internet.

A aplicação envia, em todas as respostas:

Como a aplicação e o servidor de borda divergem no valor de X-Frame-Options, o cabeçalho efetivamente entregue ao navegador precisa ser conferido antes da publicação desta política. A DEFINIR: conferir os cabeçalhos realmente devolvidos por https://clincrmapp.com, em especial `X-Frame-Options` e `Strict-Transport-Security`

Ressalvas honestas sobre a CSP: as diretivas de script e de estilo incluem 'unsafe-inline', exigido pelo funcionamento do framework. Isso significa que a CSP não é, hoje, uma defesa forte contra XSS — ela impede carregar código de domínios externos, mas não bloqueia script inline. Não a descrevemos como "proteção contra XSS". PENDENTE: adotar nonce ou hash na CSP e remover `'unsafe-inline'`

Não existem hoje os cabeçalhos Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy, Cross-Origin-Embedder-Policy, nem relatório de violação de CSP.

6. Separação entre clínicas

• A clínica ativa de cada sessão é resolvida no servidor, no momento do login, e viaja dentro do token assinado. Ela não vem de parâmetro enviado pelo navegador — logo, o usuário não consegue trocar de clínica manipulando a requisição.
• Toda consulta de dados filtra pela clínica da sessão. Paciente de outra clínica responde 404, não 403 — o sistema não confirma sequer a existência do registro.
• Sessões antigas sem clínica definida são recusadas, justamente para impedir uma consulta sem filtro.
• O acesso a dados fora de uma clínica específica é explícito e restrito às contas globais do ClinCRM; usuário de clínica que tentar recebe 403.

Limitação arquitetural que declaramos: o isolamento é feito pela aplicação, não pelo banco. Todas as clínicas compartilham o mesmo banco e as mesmas tabelas, e o usuário de banco da aplicação enxerga a base inteira. Não há isolamento por linha (row-level security) no banco de dados. Na prática, cada rota nova precisa aplicar o filtro por clínica corretamente; uma rota escrita sem esse cuidado poderia expor dados entre clínicas. Mitigamos com padrão de código, componentes comuns de acesso e revisão, mas isso é controle de processo, não garantia estrutural. PENDENTE: acesso ao banco escopado por clínica de forma obrigatória, ou isolamento em nível de banco

7. Controle de acesso por perfil (RBAC)

O controle de permissão é aplicado no servidor, em cada rota, e não apenas escondendo botões na tela. A interface esconde módulos por conveniência; quem decide é o servidor, que devolve 401 (sem sessão) ou 403 (sem permissão) por conta própria.

• Recepção não tem acesso ao módulo médico: não vê prontuário nem financeiro. Mas a recepção tem acesso ao módulo de WhatsApp, e a caixa de mensagens contém o texto integral das conversas com pacientes — conteúdo que pode incluir relato clínico. O sigilo do prontuário, portanto, não se estende automaticamente à conversa.
• Quem não tem o módulo médico recebe a lista de pacientes sem nome da mãe, endereço, tipo sanguíneo, alergias e doenças crônicas.
• Atenção — o que não é minimizado: CPF, telefone, e-mail e data de nascimento são entregues a todos os perfis autenticados da clínica, inclusive recepção. PENDENTE: avaliar mascarar CPF para perfis sem finalidade clínica
• Existe um perfil somente leitura, com bloqueio central de qualquer operação de escrita.
• Toda rota que lê ou grava dado de paciente exige sessão válida e permissão. São públicas por desenho apenas as rotas de entrada e de recuperação de acesso (login, recuperação e redefinição de senha, verificação de e-mail), a verificação de saúde do sistema, o formulário de contato do site e o registro de métrica de página. Os webhooks são autenticados por um segredo comparado em tempo constante.
• Ressalva: o webhook de recebimento de mensagens de WhatsApp aceita requisição sem autenticação caso o segredo correspondente não esteja configurado no servidor. É um comportamento de fallback do sistema, e é a única porta que pode receber conteúdo de mensagem de paciente sem autenticação. PENDENTE: fechar a rota por padrão quando o segredo não estiver configurado A DEFINIR: confirmar que o segredo está configurado no ambiente de produção

8. Acesso da equipe do ClinCRM aos dados

Isto precisa ser dito com todas as letras, porque é o ponto de maior impacto para o titular:

Existem contas globais do ClinCRM que podem alternar para qualquer clínica assinante e ler os dados dela — inclusive prontuário, prescrição, exames anexados e conversas de WhatsApp — com o mesmo sistema que o médico da clínica usa. É um acesso de operação e suporte, não um acesso irrestrito ao banco por fora do sistema, mas é acesso a dado de saúde.

Salvaguardas que existem hoje:

• 2FA obrigatório para toda conta global (com a ressalva do item 3: a trava barra escrita, não leitura).
• A troca de clínica e a abertura de prontuário são registradas na trilha de auditoria.

Limitações que declaramos:

> A clínica não consegue ver, na própria tela de auditoria, os acessos feitos pelas contas globais do ClinCRM. Esses registros existem, mas são gravados na trilha global do projeto, e a tela de auditoria da clínica mostra apenas os registros dela. PENDENTE: expor à clínica os acessos feitos por contas globais aos dados dela

> Os documentos hoje firmados com a clínica não preveem expressamente esse acesso técnico nem trazem cláusula nominal de confidencialidade da equipe do ClinCRM. A DEFINIR: cláusula contratual que autorize, limite e documente o acesso técnico das contas globais, e dever de confidencialidade nominal da equipe

A DEFINIR: número de pessoas com conta global hoje, e se há termo de confidencialidade assinado por cada uma

9. Trilha de auditoria

Registramos, para ações sensíveis: identificador e nome do usuário, papel, ação, entidade afetada, identificador da entidade, detalhes opcionais, clínica e data/hora. A leitura de prontuário é auditada. Também são auditados login, troca de clínica, criação, edição e remoção de paciente, entre dezenas de outras ações.

Fatos que declaramos por precisão:

• A trilha não registra IP, user agent nem dispositivo.
• A cobertura não é total. Boa parte das ações do sistema grava auditoria, mas não todas. Notadamente não são auditados a listagem e a busca de pacientes, nem o download de um documento anexado. PENDENTE: auditar listagem, busca e download de documento
• A gravação é "melhor esforço": se o registro falhar, a operação continua e o log se perde em silêncio. Não prometemos trilha completa nem inviolável.
• Não há prazo de retenção nem expurgo de log. Os registros ficam por tempo indeterminado, e sobrevivem à exclusão do paciente ou do usuário — inclusive com o nome da pessoa em campos de detalhe. PENDENTE: definir prazo de retenção da trilha e expurgo automático

10. Limite de tentativas (rate limit)

Limites são persistidos no banco, e portanto sobrevivem a reinício e valem entre as instâncias da aplicação. Janela padrão de 15 minutos.

O IP é lido da posição correta do cabeçalho encaminhado pelo servidor de borda, para que não possa ser forjado pelo cliente.

Consequência para a privacidade, declarada aqui: as chaves desse controle contêm o endereço IP (e, no login, o identificador usado). Os registros de tentativa de login são apagados quando o login é bem-sucedido ou quando a senha é trocada. Fora desses dois casos, nenhuma rotina apaga essas linhas — o vencimento da janela apenas zera a contagem. Portanto IPs de quem tentou login sem sucesso, usou o formulário de contato ou o chat do site ficam retidos por prazo indeterminado. PENDENTE: rotina de expurgo das linhas de limite de tentativas após o vencimento da janela

Também retêm IP: o registro de dispositivos conhecidos (com user agent, podado apenas quando passa de 20 dispositivos por usuário, não por idade) e o registro de aceite de termos (que, por desenho, nunca é apagado).

11. Servidor, rede e cópias de segurança

O ClinCRM roda em servidor virtual dedicado contratado junto à Hostinger, em containers. A DEFINIR: país e região do datacenter — nenhum documento interno declara essa informação, e ela precisa ser confirmada no painel do provedor antes da publicação, por causa dos arts. 33 a 36 da LGPD e do Capítulo V do GDPR

Pendências de infraestrutura, declaradas:

• O acesso administrativo remoto por senha e o login direto como administrador continuam habilitados, conforme a documentação interna, que descreve o fechamento como tarefa pendente. Não afirmamos "acesso administrativo somente por chave". PENDENTE: desabilitar a autenticação por senha e o login direto de administrador no acesso remoto
• Não existem monitoramento externo de disponibilidade, WAF, sistema de detecção de intrusão nem SIEM. PENDENTE: implantar monitoramento externo e detecção de intrusão
• Não há relatório de teste de intrusão (pentest) nem teste automatizado de segurança. PENDENTE: contratar avaliação de segurança independente

Cópias de segurança:

Portanto não prometemos redundância geográfica nem plano de recuperação de desastre testado. Se o servidor for perdido por completo, as cópias podem ser perdidas junto. PENDENTE: cópia externa cifrada fora do servidor, e teste periódico de restauração documentado

Consequência prática para o titular: um dado eliminado a seu pedido ainda pode existir nas cópias de segurança por até 7 dias depois da eliminação. Nesse intervalo ele não é usado para nenhuma finalidade — existe apenas dentro do arquivo de cópia.

Existem ainda cópias arquivadas do banco de dados anterior, guardadas no servidor sem prazo declarado, que podem conter dados de pacientes anteriores a julho de 2026. PENDENTE: inventariar o conteúdo, definir prazo e eliminar as cópias arquivadas do banco anterior

12. O que a política de segurança do site impede

Como consequência direta da configuração descrita no item 5:

• Não há Google Analytics, Google Tag Manager, pixel de rede social, Hotjar, PostHog, monitoramento de erros de terceiro, mapa incorporado ou qualquer script de terceiro no site ou no sistema.
• As fontes tipográficas são hospedadas por nós; o navegador não faz requisição a servidor de fontes de terceiro.
• As métricas de audiência do site e o registro de erros da aplicação são de primeira parte: gravados no nosso próprio banco.
• Nenhuma integração externa acontece pelo navegador do usuário — a política do site bloqueia conexões de saída para outros domínios. Toda integração com terceiro é feita servidor a servidor.

13. Comunicação de incidente de segurança

Não prometemos que um incidente nunca vai acontecer. Prometemos como agiremos quando acontecer.

O que consideramos incidente: qualquer acesso não autorizado, perda, alteração indevida, destruição ou divulgação acidental ou ilícita de dados pessoais sob nosso tratamento.

Nosso procedimento

1. Contenção e apuração. Ao detectar ou ser informados de um incidente, contemos o acesso indevido e forçamos a troca de senha das contas afetadas — o que invalida todas as sessões daquele usuário em qualquer dispositivo. Não existe hoje um comando único de revogação global de sessões, e a troca do segredo do servidor tem o efeito colateral descrito no item 4. PENDENTE: rota de revogação global de sessões, e plano de rotação do segredo do servidor que preserve os segredos de 2FA e as chaves de IA
2. Registro. Registramos internamente todos os incidentes, com fatos, efeitos e medidas adotadas — inclusive os que não exigirem comunicação externa (GDPR art. 33(5)).
3. Comunicação à autoridade.

- Brasil (LGPD art. 48): comunicamos a ANPD e os titulares afetados quando o incidente puder acarretar risco ou dano relevante, em prazo razoável, conforme a regulamentação vigente da autoridade. A DEFINIR: fixar o prazo exato conforme a norma da ANPD aplicável na data de publicação - União Europeia (GDPR art. 33): quando o GDPR se aplicar, notificamos a autoridade de controle competente em até 72 horas a partir do momento em que tomamos conhecimento do incidente, salvo se for improvável que ele resulte em risco para os direitos e liberdades dos titulares. Se as 72 horas forem ultrapassadas, a notificação vai acompanhada da justificativa do atraso. - Comunicação direta ao titular (GDPR art. 34): quando o incidente puder resultar em alto risco para o titular, comunicamos também diretamente a ele, sem demora injustificada.

1. Papel de operador. Quando atuamos como operador dos dados que a clínica controla (o caso da maior parte dos dados de paciente), comunicamos a clínica controladora sem demora injustificada ao tomar conhecimento do incidente (LGPD art. 39; GDPR art. 33(2)), com as informações necessárias para que ela cumpra os próprios deveres de notificação. A decisão de comunicar o paciente é da clínica; nós damos apoio técnico e informação.

O que a comunicação vai conter — no mínimo, e na medida do que soubermos no momento (LGPD art. 48, §1º; GDPR art. 33(3)):

O que você, titular, pode esperar de nós

• Comunicação em linguagem clara, dizendo o que aconteceu, quais dados seus foram afetados e o que fazer a respeito — não um comunicado genérico.
• Não vamos minimizar nem omitir a existência do incidente para preservar imagem.
• Orientação prática: se o incidente envolver credenciais, pediremos a troca de senha e a ativação do 2FA — e a troca de senha, por si só, derruba as sessões abertas daquela conta.
• Um canal aberto para perguntas específicas sobre o seu caso.
• O direito de peticionar à ANPD (LGPD art. 18, §1º) ou à autoridade de controle da UE (GDPR art. 77) independentemente de nós, e de buscar reparação por dano (LGPD art. 42; GDPR art. 82).

Como falar conosco sobre segurança

• Canal do encarregado: privacidade@clincrmapp.com. BLOQUEANTE: confirmar que essa caixa está ativa e monitorada antes da publicação A DEFINIR: nome e qualificação do encarregado (DPO), exigido pela LGPD art. 41
• Relato responsável de vulnerabilidade: se você encontrar uma falha de segurança no ClinCRM, escreva para o mesmo endereço. Comprometemo-nos a responder e a não tomar medida legal contra quem relatar de boa-fé, sem acessar dado de terceiro e sem tornar a falha pública antes da correção. A DEFINIR: prazo de resposta e política formal de divulgação responsável
• Prazo de resposta a pedidos do titular: BLOQUEANTE: não publicar prazo antes de confirmar caixa ativa, responsável designado e rotina de monitoramento que sustentem o prazo

A DEFINIR: razão social, CNPJ e endereço do controlador; foro; e se existe seguro de responsabilidade civil cibernética a ser mencionado

Crianças e adolescentes

O site público não se destina a menores

O site https://clincrmapp.com é dirigido a clínicas, profissionais de saúde e pessoas responsáveis por elas. Não é dirigido a crianças nem a adolescentes, e não coletamos dados de menores de forma consciente por esse canal.

No site institucional, os canais que recebem dado digitado pelo visitante são estes, e todos são comerciais:

Além desses canais, o site tem páginas públicas de entrada no sistema (login, recuperação e redefinição de senha, verificação de e-mail). Elas se destinam a pessoas que já têm conta na clínica, não a visitantes, e estão descritas no capítulo de Segurança.

Não há verificação de idade em nenhum desses canais. Não pedimos data de nascimento do visitante e não temos como confirmar a idade de quem escreve. O chat do site exibe o aviso "Respostas por IA, não envie dados pessoais" e é instruído a não pedir dados pessoais.

Quem recebe a mensagem do chat do site. O chat do site usa um agente de âmbito global do ClinCRM. O provedor de inteligência artificial que recebe a sua mensagem é escolhido e contratado pelo ClinCRM, não por nenhuma clínica — hoje os provedores possíveis são Anthropic, OpenAI e Google. Somos controladores desse tratamento e respondemos pela escolha do subprocessador e pela transferência internacional correspondente. Isso vale igualmente para a mensagem de um visitante menor de idade. Sem provedor conectado, o chat responde localmente e nada sai do nosso servidor.

Se identificarmos que recebemos dado pessoal de uma criança ou de um adolescente pelo site sem o amparo legal exigido, eliminamos o registro. Hoje isso é feito manualmente: alguém da equipe do ClinCRM com o perfil de maior privilégio apaga a conversa de lead, e as mensagens e os participantes dela são apagados junto. Não existe rotina automática para isso. PENDENTE: criar procedimento formal e registrado para receber, avaliar e executar pedidos de eliminação de dado de menor recebido pelo site, com prazo definido

Ressalva honesta sobre IP. O formulário de lead e o chat do site aplicam limite de requisições por endereço IP, e esse controle guarda o endereço IP do visitante no nosso banco de dados. Não há nenhuma rotina que apague esses registros — o IP fica retido por prazo indeterminado, e isso vale também para um eventual visitante menor de idade. PENDENTE: implementar expurgo periódico dos registros de controle de requisições que guardam endereço IP

Não usamos qualquer forma de publicidade comportamental, perfilamento ou rastreamento de terceiros no site. Não há Google Analytics, pixel de rede social, gerenciador de tags, Hotjar ou equivalente em nenhuma página; as fontes são hospedadas por nós; e a política de segurança de conteúdo do site bloqueia scripts e conexões externas. A única métrica de audiência é agregada por página e por dia, sem IP, sem identificador de visitante, sem informação sobre o navegador e sem origem de acesso. Isso vale para todos os visitantes, inclusive menores.

Sobre a escolha de aceitar ou não essa métrica: a sua resposta fica gravada apenas no seu navegador. Não guardamos nenhum registro que ligue essa escolha a você e não temos como alterá-la remotamente. Hoje o único caminho efetivo para mudar de ideia é limpar os dados do site no navegador. PENDENTE: controle de revisão do consentimento na própria página

Paciente menor de idade dentro do sistema

O ClinCRM é usado por clínicas. Um paciente cadastrado pode ser menor de idade — o sistema não impede nem restringe isso, e não há nenhuma trava, alerta ou fluxo específico para paciente menor.

Nesse tratamento, a clínica é a controladora e o ClinCRM é operador: tratamos o dado do paciente por conta e ordem da clínica. Cabe à clínica obter o consentimento específico e em destaque de pelo menos um dos pais ou do responsável legal, quando esse for o fundamento legal aplicável (LGPD art. 14, §1º), e cabe a ela avaliar quando o tratamento se apoia em outra hipótese — em especial a tutela da saúde por profissional ou serviço de saúde (LGPD art. 11, II, "f"), que é a base típica do prontuário e não depende de consentimento. O ClinCRM não decide essa qualificação pela clínica.

O que o sistema faz e o que não faz, exatamente:

PENDENTE: criar campos de responsável legal e registro auditável do consentimento parental (titular, responsável, versão do termo, data, IP), para que a clínica possa comprovar o art. 14, §1º dentro do sistema

Uso dos dados do menor. Os dados de um paciente menor são usados apenas para o atendimento e a gestão da clínica que o cadastrou. Não usamos dados de paciente — de qualquer idade — para publicidade, para venda a terceiros ou para treinar modelos de inteligência artificial. Não existe no produto qualquer fluxo de treinamento de modelo, enriquecimento de base ou compartilhamento comercial de dado de paciente.

Quem, dentro da clínica, enxerga o menor. O acesso é separado por perfil e a recepção não acessa o prontuário. Mas a recepção acessa o inbox de WhatsApp, cujo conteúdo pode conter relato clínico do paciente, inclusive de um paciente menor.

Atenção — WhatsApp e inteligência artificial. Se a clínica ativar o módulo de WhatsApp com um agente de inteligência artificial, o conteúdo das mensagens trocadas com o paciente sai para o provedor de IA correspondente. Isso inclui mensagens de um paciente menor ou de seu responsável. Três pontos precisam ficar claros:

• O texto é enviado como foi escrito. O comando dado ao modelo pede que ele não solicite nem repita CPF, endereço ou dados clínicos, mas isso é uma instrução ao modelo, não um filtro que remova conteúdo antes do envio.
• Se a clínica conectar a própria chave, o provedor é escolhido por ela. Se a clínica contratar o adicional "IA do ClinCRM", a chamada sai sob credencial da plataforma e o subprocessador é escolhido por nós. Sem provedor conectado por nenhum dos dois caminhos, o sistema responde localmente e nada sai.
• Quando o agente marca horário, ele cria um agendamento real, com status "aguardando", atribuído a um profissional da clínica pelo próprio sistema e sujeito a confirmação da recepção. Não é um registro provisório.

Retenção das conversas. As conversas de WhatsApp com o paciente ficam guardadas no sistema. PENDENTE: definir o prazo — 20 anos quando a conversa integrar o registro assistencial, alinhado ao prontuário; 24 meses quando for exclusivamente agendamento ou assunto administrativo, com critério de classificação ainda a definir

Idade e proteção reforçada (GDPR)

Para tratamento sujeito ao GDPR (Regulamento UE 2016/679), o consentimento de serviço da sociedade da informação oferecido diretamente a uma criança exige autorização do titular das responsabilidades parentais abaixo da idade definida pelo Estado-Membro, entre 13 e 16 anos (GDPR art. 8º, 1). O ClinCRM não oferece serviço diretamente a crianças: o contrato é com a clínica, e o dado do paciente é tratado sob a responsabilidade dela. A DEFINIR: se o ClinCRM opera ou pretende operar em algum Estado-Membro da União Europeia e, em caso positivo, qual a idade-limite aplicável e quem é o representante na UE nos termos do GDPR art. 27

O ClinCRM também não faz esforço razoável de verificação de que o consentimento foi dado pelo responsável (LGPD art. 14, §5º; GDPR art. 8º, 2) — esse esforço, hoje, é integralmente da clínica, fora do sistema. PENDENTE: definir e implementar mecanismo de verificação, ou deixar contratualmente expresso que essa obrigação é da clínica controladora

O contrato com a clínica

Toda clínica recebe, na criação da conta, um conjunto de documentos de sistema com versão datada, e o aceite fica registrado. Esses textos tratam de papéis de controlador e operador, dado sensível de saúde, direitos do titular, segurança, retenção de prontuário e comunicação de incidente. Dois fatos precisam constar:

• Eles foram redigidos pela equipe do projeto e ainda não passaram por revisão de advogado; os próprios documentos declaram que não têm validade jurídica antes dessa revisão.
• Eles não contêm cláusula sobre consentimento parental, nem as cláusulas de operador exigidas pelo GDPR art. 28(3) e pela LGPD art. 39: autorização e lista de subprocessadores com aviso prévio de troca, devolução ou eliminação dos dados ao fim do contrato, direito de auditoria da clínica, dever de confidencialidade nominal da equipe, assistência em avaliação de impacto e disciplina do acesso técnico por conta de âmbito global.

BLOQUEANTE: revisão dos documentos contratuais por advogado antes de esta política afirmar que a obrigação de obter consentimento parental está contratualmente atribuída à clínica

A DEFINIR: se o contrato com as clínicas passará a exigir declaração expressa de que a clínica obteve o consentimento parental quando aplicável, e em que cláusula

Contas de acesso ao sistema

O ClinCRM não cria conta de acesso para pacientes. Só existem contas para pessoas da clínica e para a equipe do projeto. Não há portal do paciente, aplicativo do paciente ou autoatendimento: todo acesso a dado clínico exige sessão de um usuário da clínica.

Como pedir a eliminação de dado de menor

Pai, mãe ou responsável legal que queira exercer os direitos do titular menor (LGPD art. 18; GDPR arts. 15 a 22) deve procurar primeiro a clínica onde o menor é paciente, porque é ela a controladora desses dados. A exclusão do paciente é executada pela clínica dentro do sistema e apaga em cascata consultas, prescrições, medicamentos, exercícios, documentos, agendamentos, bioimpedância, cobranças, planos alimentares, procedimentos e avaliações estéticas.

Três ressalvas que precisam constar, porque são verdadeiras:

1. O que sobrevive à exclusão. Permanecem: o nome do paciente na trilha de auditoria, lançamentos financeiros sem vínculo formal com o cadastro e todo o histórico de conversas de WhatsApp, que apenas se desvincula do cadastro em vez de ser apagado — não existe função de exclusão de conversa ou de mensagem de WhatsApp.
2. Cobranças. Se o paciente tiver qualquer cobrança já paga, o sistema recusa a exclusão inteira do cadastro, por retenção fiscal. As cobranças ainda não pagas, por outro lado, são apagadas junto com o cadastro: a retenção fiscal de 5 anos alcança apenas o que foi liquidado.
3. Backups. Um dado eliminado ainda existe nas cópias de segurança por até 7 dias.

Não existe no sistema função de exportação ou portabilidade de dados do titular; esse atendimento é hoje um processo manual da equipe. PENDENTE: implementar exportação de dados do titular

Para falar diretamente com o ClinCRM sobre dados de crianças e adolescentes: privacidade@clincrmapp.com. BLOQUEANTE: confirmar que essa caixa existe, tem responsável designado e rotina de monitoramento — nenhum prazo de resposta pode ser publicado antes disso A DEFINIR: nome e contato do encarregado pelo tratamento de dados pessoais (DPO), LGPD art. 41

IA, decisões automatizadas, mudanças e contato

1. Uso de inteligência artificial

O ClinCRM tem recursos de IA. Eles são opcionais e vêm desligados.

Sem nenhum provedor conectado — nem por chave cadastrada pela clínica, nem pelo add-on "IA do ClinCRM" — o sistema responde com um texto simulado local e nada sai para fora. No chat do site, sem provedor conectado a resposta é um roteiro fixo.

Quando o add-on "IA do ClinCRM" está ativo, a chamada sai sob credencial da plataforma: nesse caso o subprocessador é escolhido e contratado por nós, não pela clínica.

Onde a IA atua hoje, quando ligada:

No chat do site, o texto da sua mensagem não é gravado. A única escrita que a conversa produz é uma linha de contagem de consumo — provedor, modelo, origem e número de tokens — sem conteúdo.

2. Não há decisão automatizada com efeito jurídico ou impacto significativo

Esta é a declaração central desta seção.

O ClinCRM não toma nenhuma decisão automatizada que produza efeito jurídico sobre você ou que afete significativamente seus interesses (LGPD, art. 20; GDPR, art. 22). Especificamente, não existe no sistema:

• nenhum escore, perfilamento, classificação de risco ou pontuação de qualquer titular — nada no sistema atribui nota a paciente, lead ou usuário;
• nenhuma análise de crédito, aprovação ou recusa automática de contrato;
• nenhuma triagem clínica automatizada, sugestão de diagnóstico ou de conduta gerada por máquina. Os registros clínicos (evolução, avaliação, plano e prescrições) são preenchidos por profissional humano;
• nenhuma decisão automática sobre cobrança, negativação ou bloqueio de atendimento;
• nenhuma aprovação ou recusa automatizada de pagamento. Existe a infraestrutura de faturamento da assinatura da clínica, hoje em modo simulado. Nenhum adaptador de gateway real está implementado: configurar um provedor real faz a operação falhar com erro explícito. Nenhuma tela do produto coleta número, validade ou código de segurança de cartão.

O que a IA faz é conversar e sugerir. O ato mais consequente que ela pratica é marcar um horário por WhatsApp: a IA cria um agendamento real, com status "aguardando", atribuído a um profissional da clínica pelo próprio sistema (sem critério clínico na atribuição) e sujeito a confirmação da recepção. É uma marcação de horário, revisável e cancelável pela clínica, não uma decisão sobre direitos. Nenhuma outra ferramenta de escrita é exposta ao modelo.

Há ainda controles automáticos de segurança que não são decisão sobre pessoa, e sim proteção do serviço: limite de tentativas de login e de envio de formulários por endereço de rede, que resultam em erro temporário, e o encaminhamento automático da conversa a um atendente humano quando o paciente digita palavras configuradas pela clínica — isso amplia o contato humano, não o substitui.

3. Sempre há um humano no controle

A IA responde mensagens; a clínica decide. Todo prontuário, prescrição, cobrança e confirmação de agendamento é ato de um profissional identificado, com registro na trilha de auditoria.

Limites técnicos que você deve conhecer, declarados com honestidade:

• O texto que você escreve numa conversa de WhatsApp é enviado na íntegra ao provedor de IA (as últimas mensagens da conversa, até doze). O sistema instrui o modelo a nunca pedir nem repetir CPF, endereço ou dados clínicos, mas isso é uma instrução de comportamento, não um filtro técnico: se você digitar esses dados, eles seguem para o provedor. Remoção automática de dados antes do envio existe apenas nos textos gerados pelo módulo de automações.

- PENDENTE: implementar filtro programático (redação de CPF, telefone, endereço e termos clínicos) antes do envio ao provedor de IA nos caminhos de WhatsApp e do chat do site. - BLOQUEANTE: corrigir, antes desta publicação, os textos hoje no ar na página de planos e na tela de configuração de provedores, que afirmam haver "remoção" de dados pessoais e clínicos onde existe apenas instrução ao modelo.

• No chat do site público, o aviso "Respostas por IA, não envie dados pessoais" é exibido antes da conversa. Leve-o a sério.
• Modelos de linguagem erram. Nenhuma resposta da IA do ClinCRM é orientação médica, e nenhuma substitui a avaliação do profissional que atende você.

4. Direito à revisão (LGPD, art. 20)

Ainda que hoje não haja decisão automatizada com efeito jurídico, você tem, e nós garantimos:

1. Pedir revisão humana de qualquer resultado gerado por IA que afete você — por exemplo, um agendamento marcado por bot ou uma resposta automática que considerou incorreta.
2. Pedir informação clara sobre os critérios e procedimentos usados na decisão automatizada, observados os segredos comercial e industrial (LGPD, art. 20, §1º).
3. Se opor ao tratamento por IA e ser atendido por uma pessoa. No WhatsApp, basta pedir um atendente na própria conversa; o sistema encaminha para humano.
4. Sob o GDPR, quando aplicável, o direito a intervenção humana, a expressar seu ponto de vista e a contestar a decisão (art. 22, §3º).

O pedido de revisão é atendido pelo canal da seção 8.

Prazo de resposta: BLOQUEANTE: não publicar prazo de resposta antes de confirmar caixa de e-mail ativa, responsável designado e rotina de monitoramento A DEFINIR: prazo assumido comercialmente — a LGPD fixa 15 dias apenas para o pedido do art. 19, II.

Quem responde a você: se você é paciente de uma clínica que usa o ClinCRM, a controladora dos seus dados de saúde é a clínica, e nós atuamos como operador (LGPD, art. 5º, VI e VII). Encaminhe o pedido à clínica; se preferir, escreva para nós e repassamos a ela. Se você é visitante do site ou lead, a controladora somos nós.

5. Provedores de IA e transparência sobre quem processa

Quando a IA está ligada, o texto sai para o provedor conectado. Os provedores suportados pelo catálogo do produto são Anthropic, OpenAI e Google.

Quem escolhe esse provedor depende do caminho:

Essa lista de provedores não é exaustiva por construção: a clínica pode cadastrar um endpoint próprio, compatível com o padrão OpenAI, e o sistema envia para lá. Nesse caso, o destino é escolhido pela clínica controladora e o ClinCRM não conhece nem controla o receptor.

• A DEFINIR: país/região de processamento e cláusulas de transferência internacional de cada subprocessador de IA efetivamente contratado (LGPD, arts. 33 a 36; GDPR, cap. V).
• A DEFINIR: publicar quais provedores de IA estão efetivamente conectados hoje no ambiente de produção, incluindo os contratados pelo ClinCRM para o chat do site e para o add-on.
• PENDENTE: publicar e manter uma lista atualizada de subprocessadores, com a obrigação contratual de aviso prévio em caso de troca.

6. Como esta política muda, e como avisamos

Esta política pode mudar quando a lei mudar, quando um recurso novo entrar no ar ou quando um subprocessador for trocado.

Nosso compromisso:

Se você não concordar com uma mudança material, pode encerrar o uso e solicitar seus dados antes da data de vigência.

Estado atual, declarado sem maquiagem:

• Não existe hoje mecanismo automático de aviso de mudança de política dentro do produto. O único registro existente é o do aceite de termos, que guarda nome, identificador do usuário, endereço de rede, versão e data do documento aceito. Nenhuma rotina dispara notificação quando a versão do documento muda.

PENDENTE: implementar disparo de aviso (e-mail + banner no sistema) na virada de versão da política, e bloqueio suave até o novo aceite.

• O ClinCRM não envia e-mail a pacientes. Todo e-mail do sistema tem como destinatário um usuário do CRM (funcionário da clínica) e sai pelo provedor de e-mail contratado, a Resend. Por isso, o aviso de mudança chega ao paciente pela clínica, não por nós.
• Versões anteriores: PENDENTE: manter arquivo público das versões anteriores desta política, com data de vigência de cada uma, para consulta e comparação.

7. Versão e data de vigência

BLOQUEANTE: corrigir, junto com esta publicação, as afirmações do texto de privacidade hoje no ar que o sistema não sustenta — "remoção de dados pessoais e clínicos no prompt"; "tokens de redefinição de senha apagados após o uso" (eles são marcados como usados, não apagados); e "encerrado o prazo ou a finalidade, os dados são eliminados ou anonimizados" (não há rotina de expurgo por prazo).

8. Canal de contato

Para exercer qualquer direito (acesso, correção, eliminação, portabilidade, revisão de decisão automatizada, oposição), tirar dúvidas sobre esta política ou comunicar um incidente:

Prazo de resposta: BLOQUEANTE: não publicar prazo antes de confirmar que a caixa privacidade@clincrmapp.com existe, está ativa, tem responsável designado e rotina de monitoramento — publicar prazo sem canal confirmado cria inadimplência desde o primeiro dia.

• Para identificar você e evitar entregar dados à pessoa errada, podemos pedir confirmação de identidade antes de atender o pedido (LGPD, art. 18, §5º).
• Não existe hoje autoatendimento no sistema para exportação de dados do titular. O atendimento é manual, feito pela nossa equipe. PENDENTE: implementar exportação de dados do titular em formato estruturado e interoperável (LGPD, art. 18, V; GDPR, art. 20).
• Não existe hoje rotina de anonimização. A palavra aparece em textos de interface e de termos, sem implementação correspondente. PENDENTE: implementar anonimização para os casos em que a eliminação é barrada por retenção fiscal ou por norma do CFM.

9. Identificação da controladora

Relação contratual com as clínicas clientes. Toda clínica recebe, na criação da conta, documentos de termos gerados pelo sistema, com aceite registrado (nome, usuário, endereço de rede, versão e data). Esses documentos contêm cláusulas de controlador/operador, tratamento de dado sensível (LGPD, art. 11), direitos do titular (art. 18), segurança (art. 46), retenção de 20 anos conforme norma do CFM e comunicação de incidente (art. 48).

Dois fatos que o titular e o revisor precisam conhecer:

• Esses textos foram redigidos pela equipe de engenharia, não foram revisados por advogado e declaram, eles próprios, não ter validade jurídica antes dessa revisão.
• Faltam neles cláusulas exigidas de um contrato de operador (LGPD, art. 39; GDPR, art. 28(3)): autorização e lista de subprocessadores com aviso prévio de troca; devolução ou eliminação dos dados ao fim do contrato; direito de auditoria da clínica; dever de confidencialidade nominal da equipe do ClinCRM; assistência em avaliação de impacto; e a hipótese de acesso técnico por conta global de administração.

BLOQUEANTE: submeter esses termos a revisão jurídica e suprir as cláusulas faltantes antes de esta política afirmar a existência de contrato de operador; e corrigir a afirmação hoje publicada de que existe "contrato próprio firmado na assinatura", que se apoia num instrumento autodeclarado sem validade jurídica.

10. Lei aplicável e foro

Esta política é regida pelas leis da República Federativa do Brasil, em especial a Lei Geral de Proteção de Dados Pessoais (Lei 13.709/2018), o Marco Civil da Internet (Lei 12.965/2014) e, nas relações de consumo, o Código de Defesa do Consumidor (Lei 8.078/1990).

Quando o titular estiver no Espaço Econômico Europeu ou o tratamento se enquadrar no art. 3º do Regulamento (UE) 2016/679, aplicam-se também as disposições do GDPR. A DEFINIR: confirmar com o advogado se o ClinCRM oferece serviço a titulares na UE. Não há indício de operação fora do Brasil; a interface tem tradução para quatro idiomas além do português — inglês, francês, italiano e alemão —, o que **não** é, por si só, oferta de serviço na UE, mas é fato que o revisor deve considerar.

Foro: A DEFINIR: comarca eleita para dirimir controvérsias. Atenção do revisor: cláusula de eleição de foro em contrato de consumo ou de adesão pode ser afastada; avaliar redação que preserve o foro do domicílio do titular consumidor, nos termos do CDC, art. 101, I, e do CPC, art. 63, §3º.

Nada nesta cláusula limita seu direito de peticionar diretamente à Autoridade Nacional de Proteção de Dados (ANPD) (LGPD, art. 18, §1º) ou, sendo o caso, à autoridade de controle do seu Estado-membro (GDPR, art. 77).