Política de Privacidade

0. Como ler este documento

Esta política descreve o tratamento de dados pessoais no software de gestão odontológica ALVORA IA (o "Sistema"), contratado por clínicas e consultórios.

Ela fala de duas relações diferentes, e a distinção não é cosmética: ela decide quem responde pelo quê perante o titular e a ANPD.

• 1.A relação entre a ALVORA IA e a clínica que contrata o Sistema.
• 2.A relação entre a clínica e o paciente dela, cujos dados a clínica registra no Sistema.

Na primeira, a ALVORA IA é controladora de um conjunto pequeno de dados (a conta de acesso). Na segunda, a ALVORA IA é operadora: trata dado de paciente por conta e ordem da clínica, e não para finalidade própria. O §2 detalha.

O Sistema trata dado pessoal sensível (LGPD, art. 5º, II): dado referente à saúde. Isso muda o regime aplicável (art. 11, não apenas art. 7º) e é o motivo de este documento ser mais longo e mais específico do que o usual.

1. Identificação

2. Os dois papéis: quando a clínica é controladora e quando somos nós

Esta é a parte que a maior parte das políticas de software de saúde erra, e o erro custa caro, porque atribui à empresa de software decisões que são do profissional de saúde e vice-versa.

2.1 Dado do PACIENTE: a clínica é CONTROLADORA, a ALVORA IA é OPERADORA

Quem decide cadastrar um paciente, o que registrar no prontuário, quanto tempo manter, para quem enviar uma mensagem e se consulta o crédito de alguém é a clínica e o profissional de saúde que nela atua. A ALVORA IA fornece a ferramenta e executa o tratamento conforme essa determinação.

Consequências práticas, e são as que importam:

• O dever de informar o paciente sobre o tratamento dos dados dele, e de obter consentimento quando ele for a base legal aplicável, é da clínica. O Anexo A traz um checklist do que a clínica precisa dizer ao paciente dela, justamente porque essa informação depende de fatos técnicos que só nós conhecemos.
• Pedido de acesso, correção, portabilidade ou eliminação feito por um paciente deve ser dirigido à clínica. A ALVORA IA não tem relação direta com o paciente, não valida a identidade dele e não pode decidir sobre o prontuário de ninguém. Nós auxiliamos a clínica a atender o pedido, com as ferramentas descritas no §10.
• A ALVORA IA não usa dado de paciente para finalidade própria: não vende, não cede, não usa para publicidade e não usa para treinar modelos de inteligência artificial (não existe no Sistema nenhuma rotina de treinamento, ajuste fino ou construção de base de treino; ver §4.5).

2.2 Dado da CONTA de acesso: a ALVORA IA é CONTROLADORA

Para criar e manter a conta de quem usa o Sistema, a ALVORA IA é controladora. O conjunto é pequeno, e isso é verificável: o cadastro tem quatro campos (nome da clínica, e-mail, WhatsApp do responsável e senha). Não há coleta de CPF, CNPJ, endereço ou meio de pagamento no cadastro, e não existe cobrança automática nem armazenamento de dado de cartão em nenhum ponto do Sistema.

O WhatsApp é o campo novo desta versão, e ele não é apenas contato de suporte: ele alimenta também o acompanhamento comercial de quem testa e não assina. Como isso é finalidade nova e categoria nova, ele tem seção própria, com base legal, prazo e forma de pedir para parar: §3.1.1. Ele não é anunciado como "contato" e usado como "marketing" — está escrito na tela do cadastro e está escrito aqui.

2.3 Onde os dois papéis se encostam

Alguns dados são de paciente e trafegam por decisão de arquitetura nossa (por exemplo: a conversa de WhatsApp de um interessado, que entra no Sistema por um canal que nós operamos). Nesses pontos continuamos operadores, mas a escolha técnica é nossa e por isso está descrita em detalhe no §4 e no §5 — a clínica não pode informar o paciente dela sobre o que ela não sabe.

3. Dados tratados, por categoria, com finalidade e base legal

3.1 Dados da conta (ALVORA IA como controladora)

O IP e o navegador do aceite são a única captura de IP do Sistema — a decisão antiga da casa de não registrar IP vale para o paciente, que é terceiro e não é parte (ver §3.3). No aceite, o titular é a contraparte contratual, a base legal é execução de contrato e IP + data/hora é a evidência padrão de aceite eletrônico. A linha do aceite é imutável por trava no banco de dados: não pode ser alterada nem apagada, e o IP acompanha essa condição (§8.4).

3.1.1 O WhatsApp do responsável e o acompanhamento comercial

Esta seção existe porque o campo é novo, a finalidade é comercial e a alternativa seria coletar o número em silêncio. É o tipo de coisa que costuma ficar escondida sob "finalidades legítimas de negócio". Aqui vai escrito.

O que é coletado. O número de WhatsApp digitado no cadastro (guardado como foi digitado e também em forma normalizada, para não criar registro duplicado da mesma pessoa), com o nome da clínica, o e-mail, o plano escolhido no site e a página de origem — o endereço de onde a pessoa veio, informado pelo próprio navegador. O registro tem também campos de campanha (utm_*), e eles hoje ficam vazios: os links do site não propagam esses parâmetros até o cadastro, e nenhum código os preenche. Fica dito assim porque campo que existe e não é usado não é coleta — e descrever coleta que não acontece é tão inexato quanto esconder coleta que acontece. Se um dia os links passarem a propagar, é este parágrafo que muda junto. Não são coletados aqui o endereço IP nem a identificação do navegador: no registro de aceite eles são prova contratual (§3.1), aqui seriam coleta sem finalidade, e por isso ficaram deliberadamente de fora.

Para que serve, sem eufemismo. Duas coisas:

• 1.Falar com quem está testando, sobre o teste. Ajudar na implantação, avisar de pendência, responder dúvida, prestar suporte. Hoje o WhatsApp é o único canal de atendimento que existe: o produto não tem e-mail transacional (§13). Sem esse número, a clínica não tem por onde ser avisada de nada — nem de reajuste, nem de incidente, nem do fim do teste.
• 2.Contato comercial de acompanhamento, inclusive se a pessoa não assinar. Terminado o período de teste sem contratação, o número entra numa sequência de mensagens de acompanhamento comercial. Ela é curta e tem fim: hoje são no máximo sete mensagens ao todo, no máximo uma por dia, distribuídas entre os dias que antecedem o fim do teste e os 30 dias seguintes — e o próprio banco de dados impede repetir uma mensagem já enviada e enviar mais de uma no mesmo dia. Isso não é efeito colateral do item 1: é finalidade declarada, e é o motivo pelo qual o campo passou a existir.

O número não é vendido, não é cedido a terceiro, não entra em lista de terceiros e não é usado para oferecer produto de outra empresa. Ele serve para falar da ALVORA IA com quem pediu para testar a ALVORA IA, e para mais nada.

Base legal — são duas, e a divisão é o ponto.

• Execução de contrato e de procedimentos preliminares a pedido do titular (art. 7º, V), para o item 1 e para todo o período em que o teste ou o contrato estiverem em curso. Quem clica em "começar teste grátis" pede o serviço; falar com essa pessoa sobre o serviço que ela pediu, no canal que ela mesma indicou, é executar o que foi pedido — ainda mais quando esse canal é o único que existe.
• Legítimo interesse (art. 7º, IX), para o item 2, depois que o teste termina sem contratação. Aí não há mais contrato nem procedimento preliminar em curso, e continuar invocando o art. 7º, V para o que já é prospecção seria desonesto. A hipótese passa a ser o interesse legítimo do fornecedor em retomar uma negociação que o próprio titular iniciou.

Por que não consentimento. Consentimento (art. 7º, I) tem de ser livre (art. 8º), e o campo é obrigatório para criar a conta. Caixa marcada para conseguir o teste não é manifestação livre, e registrar isso como "consentimento" seria produzir um registro que afirma algo falso — exatamente o defeito que este documento aponta no §3.2.5 a respeito da consulta de crédito. Não se repete o erro em outra seção do mesmo texto. Legítimo interesse é a base honesta, e ela vem com um preço que é assumido aqui: o titular pode se opor a qualquer momento, sem justificar (art. 18, §2), e a oposição é definitiva.

Anote-se a dependência, porque ela é o gatilho de reescrita desta seção: a análise acima vale enquanto o campo for obrigatório. Se um dia ele virar opcional, com a finalidade comercial dita ao lado e sem prejuízo para quem não preencher, aí sim existe espaço para consentimento livre — e é o texto daqui que tem de mudar junto com o formulário, não depois dele.

Teste de balanceamento, em resumo. O titular é a pessoa responsável por uma clínica que, por iniciativa própria, pediu o teste de um software pago e informou o número para ser contatada a respeito; a expectativa desse contato é razoável (art. 10, II). O dado é de contato profissional, não é dado sensível, e é o mínimo necessário para a finalidade. As salvaguardas são: informação no próprio ato da coleta, finalidade restrita, número limitado de contatos, prazo curto de retenção — hoje cumprido por execução manual, e a ressalva está logo adiante —, opt-out sem login e nenhuma cessão a terceiro.

Como pedir para parar (opt-out). Descrevendo o que existe, e não o que seria bonito:

• Hoje nenhuma mensagem é enviada. A ALVORA IA não tem número de WhatsApp próprio (§13) e o disparo da sequência está desligado no código. O que existe hoje é o registro do prospect; a régua não roda.
• Quando passar a enviar, o caminho que encerra na hora, sozinho, é um só: o link de descadastro que acompanha toda mensagem, que não exige login nem conta ativa. É ele, e só ele, que o rodapé da mensagem oferece.
• Responder à conversa pedindo para parar também vale, e é oposição como qualquer outra (art. 18, §2) — mas ela é atendida por pessoa, não por automação, e isso precisa estar escrito: o canal por onde a ALVORA IA enviaria é só de saída, e não existe no Sistema código que leia resposta nesse canal. Quem responder "pare" está exercendo um direito válido, e o pedido é tratado pelo canal do §13, no prazo da lei — mas não é encerramento automático, e chamá-lo de automático seria descrever uma porta que não abre. Enquanto for assim, o link é o caminho a usar por quem quer efeito imediato.
• Regra que a ALVORA IA assume aqui: a sequência não pode ser ligada antes de existirem três coisas — um número real, publicado no §13; o link de descadastro funcionando (a página que o atende ainda não existe); e coerência entre a saída que a mensagem oferece e a saída que o código atende sozinho. Se um dia a mensagem passar a dizer "responda PARE", o tratamento automático dessa resposta tem de existir antes. Régua de mensagem sem caminho de saída não sobe, e caminho de saída anunciado e não implementado é pior do que não anunciar.
• O pedido também pode ser feito pelo canal do §13, e vale para todos os registros da mesma pessoa.
• O opt-out é definitivo: a sequência passa a ignorar o registro, e disparo posterior não o reativa.

Retenção — 180 dias, e por que esse número. Passados 180 dias do fim do período de teste sem contratação, o registro é eliminado: apagado, com o número junto — não anonimizado, não arquivado. Como isso é executado hoje, sem arredondar: a rotina que apaga existe no banco de dados, mas não está agendada — nenhuma parte do Sistema a chama, e o único agendamento criado nesta versão é o da própria sequência de mensagens, que serve para enviar e nunca para apagar. Enquanto o agendamento não existir, cumprir estes prazos depende de alguém executar a rotina, e o prazo é compromisso assumido, não automatismo. Ligá-lo é pré-requisito registrado no Anexo B (item 24), e o §8.1 repete a ressalva no lugar onde se procura prazo. O prazo foi escolhido assim: seis meses é o horizonte em que uma clínica que testou e não contratou ainda pode reabrir a decisão (fim de contrato com o sistema atual, virada de exercício, entrada de sócio), e é curto o bastante para que a base não vire lista permanente de gente que já disse não. Quem pede opt-out é eliminado 30 dias depois do pedido — a folga existe apenas para que a régua não reinclua a pessoa nesse intervalo —, pela mesma rotina e com a mesma ressalva do parágrafo acima. Quem contrata deixa de ser prospect: dali em diante valem os prazos de conta e de contrato (§8.3).

Uma consequência precisa ser dita, porque é o efeito de escolher apagar em vez de manter lista: eliminado o registro, some junto a informação de que aquela pessoa pediu para não ser procurada. Se ela se cadastrar de novo depois disso, entra de novo na régua. A alternativa seria manter lista de supressão permanente por número, isto é, guardar indefinidamente o dado de quem pediu para sumir. Entre as duas, escolheu-se apagar, e o novo cadastro é tratado como nova manifestação de interesse dela.

Onde esse dado fica e por onde passa. O registro fica no mesmo banco de dados do Sistema (§5), em tabela separada dos dados da clínica: é registro comercial da ALVORA IA sobre a clínica, e a clínica não o lê nem o edita. Quando a sequência for ligada, a mensagem trafegará pelos subprocessadores já listados no §5 para o canal de WhatsApp (Evolution API e Meta), e por nenhum outro.

3.2 Dados do paciente (clínica como controladora, ALVORA IA como operadora)

3.2.1 Cadastro e contato

Nome, CPF, data de nascimento, telefone/WhatsApp, e-mail, endereço completo (logradouro, número, complemento, bairro, cidade, UF, CEP e código do município) e observações livres.

• Finalidade: identificar o paciente, agendar, orçar, cobrar e comunicar.
• Base legal (definida pela clínica): execução de contrato de prestação de serviço odontológico (art. 7º, V) e, quanto ao CPF e endereço, cumprimento de obrigação legal e fiscal (art. 7º, II).

3.2.2 Dados de saúde (sensíveis)

Anamnese (versionada, com histórico), evoluções clínicas assinadas, alerta clínico destacado na ficha, prescrições e receituários, atestados, rastreabilidade de implantes, fotografias clínicas, questionários pós-consulta, termos de consentimento assinados (TCLE), anamnese pré-consulta preenchida pelo próprio paciente por link, e a transcrição de áudio de consulta quando a clínica usa o recurso de prontuário por voz.

• Finalidade: registro clínico, continuidade do cuidado, cumprimento de deveres do profissional de saúde.
• Base legal (definida pela clínica): tutela da saúde, exclusivamente em procedimento realizado por profissionais de saúde ou serviços de saúde (art. 11, II, "f") e cumprimento de obrigação legal e regulatória de guarda de prontuário (art. 11, II, "a"). Para fotografia usada fora do prontuário, ver §3.2.6.

3.2.3 Agenda e atendimento

Agendamentos, horários de chegada e de início/fim de atendimento, faltas, remarcações, etiquetas do agendamento, lista de espera, check-in.

• Finalidade: operação da agenda e gestão do atendimento.
• Base legal: execução de contrato (art. 7º, V).

3.2.4 Financeiro

Orçamentos e itens, condições de pagamento, cobranças, parcelas, entradas, pré-vendas, identificadores e links de cobrança gerados no meio de pagamento.

• Finalidade: cobrar e controlar o recebimento.
• Base legal: execução de contrato (art. 7º, V) e obrigação legal fiscal (art. 7º, II).

3.2.5 Consulta de crédito (leia antes de publicar)

Quando a clínica usa o recurso de análise de crédito, o Sistema envia CPF ou o identificador do cliente no meio de pagamento a um birô de crédito, por intermédio do provedor de pagamentos, e grava o resultado da consulta.

Sobre os "60 dias", que é onde uma cláusula de praxe erraria: 60 dias é o prazo de reaproveitamento, não de descarte. Dentro desse prazo o Sistema reusa a última consulta em vez de chamar o birô outra vez (economia de custo e menos exposição do CPF). Passados os 60 dias, a consulta seguinte é nova — mas o registro antigo continua onde está. O que fica gravado é: o CPF consultado, o score, a situação do CPF, a existência de pendências, a resposta bruta do provedor, a data/hora da consulta, o campo de consentimento e, quando houver, a sobreposição manual com o motivo e o autor. Esse registro é conservado por prazo indeterminado, porque hoje não existe no Sistema nenhuma rotina que o elimine (ver §8.4).

Duas coisas precisam ser ditas com precisão, e nenhuma delas cabe numa cláusula de praxe:

• 1.O Sistema grava o campo "consentimento dado" como verdadeiro em todos os casos. A exigência de consentimento prévio do paciente para essa consulta existiu e foi removida por decisão de produto em 19/07/2026. A coluna de consentimento continua no banco, mas não condiciona mais a consulta. Ou seja: hoje há um registro afirmando consentimento sem que o consentimento tenha sido necessariamente colhido.
• 2.Esta política não pode afirmar que a consulta é feita com consentimento. Enquanto o item 1 valer, qualquer redação nesse sentido seria falsa.

3.2.6 Imagens de caso (antes e depois)

Imagens usadas como prova social no orçamento ficam em um repositório de arquivos público: quem tem o endereço do arquivo consegue abri-lo, sem autenticação. O controle de consentimento existe, mas ele governa a exibição no link do orçamento, não o armazenamento: uma imagem enviada antes de o consentimento ser marcado já está gravada nesse repositório. A única proteção do endereço é ele ser um identificador aleatório e não divulgado.

3.2.7 Conversas de WhatsApp

Quando a clínica usa o canal de WhatsApp do Sistema, ficam registradas as mensagens recebidas e enviadas, o número, o nome de exibição do WhatsApp, o identificador da mensagem, o tipo de mídia e o endereço da mídia. Áudios recebidos podem ser transcritos automaticamente (§4.1). Imagens, vídeos, áudios e documentos recebidos são guardados em repositório privado, acessível por link temporário.

• Finalidade: atender, agendar, orçar e acompanhar o interessado.
• Base legal: execução de contrato ou tratativas preliminares (art. 7º, V); quando a mensagem tiver conteúdo de saúde relatado pelo próprio paciente, aplica-se o art. 11.
• Atenção: o WhatsApp é serviço da Meta Platforms. O conteúdo trafega pela infraestrutura da Meta por definição do canal, independentemente do Sistema.

3.2.8 Comunicações automáticas e preferências

O Sistema registra preferências de comunicação do paciente por finalidade (marketing, pós-operatório, cobrança, pesquisa). Hoje essa preferência é respeitada apenas na régua de cobrança, que não envia a quem negou expressamente. O robô de atendimento, as cadências de reativação, a confirmação de consulta e o pós-operatório não consultam essa preferência antes de enviar. Esta política não afirma o contrário.

3.3 Dados de quem acessa por link público

O Sistema tem páginas acessíveis por posse de link, sem login: orçamento interativo, portal do paciente, anamnese pré-consulta, check-in, agendamento online, assinatura de termo de consentimento, pesquisa pós-consulta, contrato, simulador e links curtos rastreáveis.

O que é registrado nesses acessos, verificado no código:

• As páginas públicas por link não registram endereço IP nem o identificador completo do navegador de quem as abre. No orçamento interativo guardamos apenas um identificador aleatório de sessão e a classe do dispositivo (celular, computador, tablet). A única tabela do Sistema com coluna de IP é a do registro de aceite dos documentos legais (§3.1), que é do usuário contratante e nunca do paciente.
• O link curto rastreável conta o clique e redireciona. Nada mais.
• Ressalva, e ela é relevante: quando o orçamento traz vídeo do avaliador, o vídeo é reproduzido pelo próprio provedor dentro da nossa página (YouTube, Vimeo ou Loom, os três permitidos). O navegador do paciente passa a falar direto com esse provedor, que recebe o IP, a identificação do navegador e o endereço de origem da página — não o link completo, que contém o código do orçamento — e pode gravar cookies próprios no dispositivo. Esse dado não passa por nós e não é registrado por nós, mas a página é nossa: está declarado aqui e no §14 em vez de omitido. Sem vídeo no orçamento, nada disso acontece.
• As páginas públicas devolvem o mínimo: o portal do paciente e o orçamento público expõem apenas o primeiro nome, sem CPF e sem conteúdo clínico.
• A anamnese pré-consulta é a exceção relevante: ela recebe respostas de saúde digitadas por visitante não autenticado. Essas respostas entram como material informativo e só se tornam anamnese vigente depois da revisão do profissional.

Os endereços de link do paciente (portal e anamnese) são estáveis: não têm prazo de validade e não existe, hoje, função de revogação no Sistema. Quem tem o link tem acesso enquanto o cadastro existir.

3.4 Dados de operação e segurança

• Trilha de auditoria: o Sistema registra quem fez o quê em tabelas sensíveis (ação, entidade, autor, data/hora e as colunas alteradas). A trilha é imutável: não aceita alteração nem exclusão, por travas no banco de dados. Ações do robô ficam fora da trilha.
• Registro de decisão do robô: cada desfecho do motor de atendimento é gravado como evento do interessado. Hoje não existe tela que exiba esse registro ao cliente; ele é consultável internamente.
• Registros técnicos (logs) da hospedagem e do banco: gerados e retidos pelos respectivos provedores conforme a configuração deles.

4. Inteligência artificial: o que sai, para onde, e o que volta

Esta seção existe porque é o que a clínica precisa saber para poder informar o paciente dela. Ela descreve o comportamento real do código, recurso por recurso.

4.1 Robô de atendimento por WhatsApp

• O que sai: o texto integral da conversa daquele interessado (mensagens recebidas e enviadas) mais um bloco fixo de instruções, para a Anthropic (Estados Unidos). Não são enviados nome, telefone nem os campos estruturados do cadastro; o que o interessado escreveu em texto livre, porém, vai integralmente, e é comum que contenha relato de dor, doença ou tratamento.
• Áudio recebido: o áudio da mensagem é enviado integralmente à AssemblyAI (Estados Unidos) para transcrição, qualquer que seja a duração — não existe corte por duração nem por tamanho do arquivo. O que existe é um teto de espera: o Sistema aguarda o resultado por até 90 segundos (contados do início do envio) e, se a transcrição não concluir nesse prazo, o robô desiste de ler o texto e pede ao interessado que escreva. O áudio já foi transmitido ao provedor mesmo nesse caso. Quando conclui, a transcrição substitui o áudio no fluxo do robô.
• Otimização de custo: o bloco fixo de instruções é armazenado temporariamente pelo provedor para reaproveitamento entre chamadas (prompt caching). O ponto de corte fica antes do conteúdo da conversa: o que é cacheado é a instrução, não o diálogo.
• Voz sintética: quando ativada, apenas o texto da resposta do robô é enviado à ElevenLabs (Estados Unidos) para gerar o áudio. Nenhum áudio ou dado do paciente vai para lá.

4.2 Prontuário por voz

• O que acontece: o áudio da consulta é gravado, armazenado em repositório privado e enviado para transcrição na AssemblyAI (Estados Unidos), com separação de falantes (dentista e paciente) em português. Tecnicamente, o áudio não é carregado para lá: é gerado um link temporário (1 hora) do arquivo privado e o provedor faz o download.
• O texto da transcrição é então enviado à Anthropic (Estados Unidos) para ser organizado em três campos de evolução (realizado, próxima consulta, observações). A instrução enviada proíbe explicitamente inventar procedimento, dente, material ou conduta.
• O áudio é apagado logo depois. Ao gerar o rascunho, o Sistema remove o arquivo do repositório e limpa a referência. Duas ressalvas honestas: a remoção é best-effort (falha do repositório não interrompe o fluxo), e se a transcrição falhar ou nunca concluir, o áudio permanece até 30 dias, quando é varrido por rotina automática diária. O teto real de retenção do áudio é, portanto, 30 dias, não "imediato".
• O rascunho é sempre revisado por um profissional antes de virar evolução assinada. A IA não assina prontuário e não decide conduta.
• No fluxo assíncrono, o Sistema informa ao provedor de transcrição um endereço próprio para retorno da conclusão, protegido por token.

4.3 Copiloto do atendimento e assistente de indicadores

• Copiloto: envia a conversa do interessado à Anthropic e devolve um rascunho de resposta para o atendente humano decidir. Não envia sozinho.
• Assistente de indicadores: envia à Anthropic apenas números agregados (contagens de interessados por etapa, orçamentos por situação, somas do financeiro). Nenhum nome de paciente e nenhum dado clínico saem nesse fluxo. Verificado no código.

4.4 O que a IA NÃO faz

• Não decide sozinha sobre tratamento, diagnóstico ou conduta clínica. O rascunho gerado é material de trabalho do profissional.
• Não é usada para treinar modelo. Não existe no Sistema qualquer rotina de treinamento, ajuste fino ou construção de base de treino.
• Não recebe o cadastro estruturado do paciente nos fluxos de conversa (nome, telefone e campos do cadastro não são enviados ao modelo).

5. Subprocessadores

Lista nominal, com país e finalidade. Cada linha foi conferida no código.

5.1 O que NÃO é subprocessador, apesar de aparecer no produto

Para evitar lista inflada e, pior, lista errada:

• Meta Lead Ads: a rota de integração é um esboço desativado e devolve erro por padrão. Nenhum dado é enviado à Meta por esse caminho hoje. Registro de risco: se a integração for ativada como está, o conteúdo do formulário do interessado (nome, telefone, respostas) passa a ser escrito nos registros técnicos da hospedagem.
• ITI (Instituto Nacional de Tecnologia da Informação): o endereço do validador oficial aparece apenas como texto dentro de um QR Code impresso em PDF. Não há nenhuma chamada de rede ao ITI.
• Provedor de assinatura digital (Lacuna): integração presente no código, mas em modo de demonstração por padrão. O PDF gerado carrega o aviso "assinatura de demonstração, sem validade". Esta política e os Termos não podem afirmar assinatura digital com validade jurídica enquanto for assim.

5.2 Subprocessador escolhido pela própria clínica

Se a clínica ativar o recurso de automação externa, o Sistema passa a enviar nome, WhatsApp, procedimento e data do paciente para um endereço de internet que a própria clínica cadastra, junto com os identificadores da clínica e do paciente. Nesse caso, quem escolhe o destinatário é a clínica; a ALVORA IA não conhece, não controla e não audita esse destino, e a responsabilidade pela adequação dele é da clínica. Sem endereço cadastrado, nada sai.

O mesmo vale para a API de integração: com um token gerado pela clínica, sistemas escolhidos por ela podem ler pacientes (identificador, nome, telefone, e-mail e data de nascimento; sem CPF), agenda e cobranças.

6. Transferência internacional de dados

Três subprocessadores contratados por nós processam dados fora do Brasil, todos nos Estados Unidos: Anthropic, AssemblyAI e ElevenLabs. O que sai para cada um está descrito no §4 e resumido no §5. Nos dois primeiros, o conteúdo pode incluir dado de saúde: a transcrição de uma consulta odontológica é dado de saúde inequívoco, e o texto livre de uma conversa de WhatsApp frequentemente contém relato de sintoma.

Há uma quarta situação, de natureza diferente e por isso separada: quando a clínica insere vídeo no orçamento, o navegador de quem abre o link contata YouTube (Google), Vimeo ou Loom, todos com sede nos Estados Unidos. O dado transferido aí é o IP, a identificação do navegador e a origem da página — nenhum dado clínico e nenhum dado do cadastro — e quem faz a requisição é o navegador do paciente, não o nosso servidor. É tratamento por terceiro provocado por uma escolha de arquitetura nossa, e por isso está declarado (§3.3, §5 e §14) em lugar de omitido.

Isso é transferência internacional na acepção da LGPD (arts. 33 a 36) e precisa de mecanismo próprio de adequação. Os Estados Unidos não têm decisão de adequação da ANPD. Os caminhos possíveis são cláusulas-padrão contratuais, cláusulas contratuais específicas, normas corporativas globais, ou uma das hipóteses do art. 33 (entre elas o consentimento específico e destacado do titular, art. 33, VIII).

A ANPD disciplinou o tema na Resolução CD/ANPD nº 19/2024, que aprovou as cláusulas-padrão contratuais e fixou prazo de adequação para contratos internacionais preexistentes.

7. Com quem mais compartilhamos

Além dos subprocessadores do §5, dados podem ser compartilhados:

• com autoridade pública ou judicial, quando houver requisição legal (art. 7º, II e art. 11, II, "a");
• para exercício regular de direitos em processo judicial, administrativo ou arbitral (art. 7º, VI; art. 11, II, "d");
• em reorganização societária, hipótese em que o adquirente fica vinculado a esta política Pendente o advogado quer prever sucessão empresarial aqui e nos Termos?.

Não vendemos dado pessoal, não cedemos base de dados a terceiros e não fazemos publicidade com dado de paciente.

8. Retenção e eliminação

Esta é a seção onde a maioria das políticas escreve "guardamos pelo tempo necessário e depois eliminamos". Aqui isso seria falso. O que segue é o que o código realmente faz.

8.1 O que expira sozinho, por rotina automática

Registro de prospect (§3.1.1): prazo assumido, execução ainda manual. Ele não está na tabela acima, e a razão é essa. Os prazos são 180 dias após o fim do período de teste e 30 dias após o pedido de opt-out, e a rotina que apaga existe no banco de dados — mas ela não está agendada: nenhum código a chama. O único agendamento criado nesta versão é o da sequência de mensagens do §3.1.1 — que serve para enviar (e hoje nem isso: está desligada) e nunca para apagar. Enquanto isso não mudar, a eliminação nesses prazos depende de execução manual. Está escrito assim, e não como "rotina automática diária", porque é o que se pode verificar no código hoje — qualificar de automático o que ninguém dispara transformaria esta seção no contrário do que ela se propõe a ser. Agendar a rotina é pré-requisito registrado no Anexo B, item 24.

8.2 O que é guardado por obrigação legal

Prontuário (anamnese, evoluções, prescrições, atestados) e documentos fiscais são retidos pelos prazos exigidos da clínica e do profissional pela legislação e pela regulamentação do exercício profissional.

8.3 O que é retido enquanto o contrato existir

Dados de conta, contrato, apuração de uso e trilha de auditoria são retidos durante a vigência do contrato com a clínica.

8.4 O que hoje NÃO é eliminado, porque não existe rotina que elimine

Dito sem rodeio, porque é a informação que a clínica precisa para informar o paciente dela: além dos itens do §8.1, nenhum outro dado do Sistema tem prazo automático de eliminação. Isso inclui, entre outros:

• o histórico integral das conversas de WhatsApp, incluindo transcrições de áudios enviados pelo interessado;
• as mídias recebidas por WhatsApp (áudio, imagem, vídeo, documento);
• fotografias clínicas, PDFs de prescrição, imagens de caso e imagens anexadas a orçamento;
• eventos de visualização do orçamento interativo, apuração de uso e trilha de auditoria;
• os registros de consulta de crédito, que guardam o CPF consultado em claro, além de score, situação, pendências e a resposta bruta do birô. Os 60 dias do §3.2.5 são prazo de reaproveitamento, não de descarte;
• o registro de aceite dos documentos legais, que inclui o endereço IP e a identificação do navegador de quem aceitou (§3.1). Aqui a perpetuidade não é só omissão: a linha é imutável por trava no banco de dados e não pode ser apagada nem por nós.

Uma varredura no código por rotina de expiração, purga ou retenção efetivamente agendada encontra uma coisa: o arquivo do prontuário por voz. Nada mais tem prazo que o código execute sozinho. O expurgo do registro de prospect (§3.1.1), criado nesta versão, não entra nesta conta: a rotina está escrita no banco de dados e ninguém a chama, e para efeito de retenção rotina que não roda equivale a rotina que não existe.

Registre-se o desconforto em dobro, porque ele é o ponto desta seção: a massa de dado de paciente listada acima continua sem prazo nenhum, e o único prazo novo desta versão — que é do dado comercial da ALVORA IA, não do paciente — nasceu escrito e desligado. É exatamente o defeito que esta seção denuncia, agora também na parte do documento que fala de nós. Prazo em política sem código que o execute é promessa vazia, e por isso ele foi tirado da tabela do §8.1 em vez de ficar lá com cara de automático.

8.5 O que a imutabilidade impede de apagar

Três coisas não podem ser alteradas nem excluídas por ninguém, nem por nós, por travas gravadas no próprio banco de dados:

• 1.Evolução clínica assinada. Correção se faz por aditamento (novo registro), e somente pelo autor. Isso é intencional: é o que dá ao prontuário valor médico-legal.
• 2.Trilha de auditoria.
• 3.Registro de aceite dos documentos legais (§3.1), incluindo o IP. A única alteração que a trava tolera é preencher, uma única vez, o vínculo com a clínica que ainda não existia no instante do clique.

Consequência jurídica, declarada aqui em vez de silenciada: um pedido de eliminação de dados dirigido a uma evolução assinada não pode ser atendido tecnicamente. O fundamento é a obrigação de guarda de prontuário e o exercício regular de direitos (art. 16, I e II; art. 11, II, "a" e "d"), e não a conveniência do fornecedor.

8.6 Exclusão de cadastro de paciente: limite técnico real

A exclusão do cadastro de um paciente é impedida quando existir orçamento, agendamento, cobrança, evolução, anamnese, pré-venda, prescrição ou atestado vinculado. Na prática, praticamente todo paciente atendido é indelével. Alguns registros satélites (fotografias clínicas, termos, pesquisas, implantes, consultas de crédito) são removidos junto quando a exclusão é possível.

Registro de defeito conhecido, que o advogado deve saber porque afeta o atendimento de pedidos do titular: a tela indica sucesso mesmo quando a exclusão é recusada pelo banco de dados (o erro não é verificado). Isto é correção de código.

9. Direitos do titular e como exercer

A LGPD (art. 18) garante ao titular: confirmação da existência de tratamento; acesso aos dados; correção; anonimização, bloqueio ou eliminação de dado desnecessário, excessivo ou tratado em desconformidade; portabilidade; eliminação dos dados tratados com base em consentimento; informação sobre compartilhamentos; informação sobre a possibilidade de não consentir; e revogação do consentimento.

9.1 Se você é PACIENTE de uma clínica que usa o Sistema

Dirija o pedido à clínica. Ela é a controladora dos seus dados, é ela quem conhece sua identidade e é ela quem decide sobre o seu prontuário. A ALVORA IA presta apoio técnico à clínica no atendimento do pedido, mas não decide sobre ele e não responde diretamente ao paciente.

9.2 Se você é USUÁRIO da conta (dono ou equipe da clínica)

Fale com a ALVORA IA pelo canal do §13.

Um direito seu tem caminho próprio e não depende de pedido formal: a oposição ao contato comercial de acompanhamento (art. 18, §2). Ela se exerce pelo link de descadastro que acompanha a mensagem, que não exige login e encerra o envio na hora. Responder à própria conversa pedindo para parar também é oposição válida, mas hoje ela é atendida por pessoa, pelo canal do §13 — o canal de envio é só de saída e nenhum código lê a resposta. O §3.1.1 descreve os dois caminhos e o estado atual de cada um.

9.3 O que o Sistema oferece hoje, e o que ele não oferece

Sendo específico, para que ninguém prometa demais ao paciente:

• Acesso e portabilidade por paciente: existe exportação estruturada, restrita a administradores e registrada na trilha de auditoria. Ela traz cadastro, orçamentos (com itens e condições), cobranças (com parcelas), agendamentos, evoluções e anamneses.
• O que essa exportação NÃO traz (e portanto um pedido de portabilidade atendido só com ela entrega menos do que a clínica guarda): fotografias clínicas, prescrições e receituários, atestados, conversas de WhatsApp, termos de consentimento assinados, pesquisas pós-consulta, rastreabilidade de implantes, pré-vendas e anamnese pré-consulta.
• Não existe exportação da clínica inteira nem cópia de segurança self-service. O que existe além do item acima é o relatório em planilha (que inclui nome de paciente na aba de faltas) e o importador de pacientes, que é entrada e não saída.
• Correção: os cadastros são editáveis, com exceção da evolução assinada, que se corrige por aditamento (§8.5).
• Eliminação: limitada pelo §8.5 e §8.6.

9.4 Fim do período de teste ou do contrato: leitura preservada

Quando o período de teste termina ou a assinatura é encerrada, o Sistema para de aceitar novos lançamentos, mas não apaga nada e não bloqueia a leitura. Isso é desenho explícito e verificável: o corte comercial existe apenas no caminho de escrita; leitura, relatórios e exportação continuam funcionando. Prontuário é registro médico-legal e não pode virar refém de fatura.

Duas ressalvas de honestidade: esse corte de escrita é aplicado na camada da aplicação, e ele é fail-open por desenho (se a verificação do contrato falhar, a escrita é liberada em vez de bloqueada) — o risco aqui é nosso, de receita, não do cliente nem do paciente.

10. Segurança

O que existe de verdade, e é conferível:

• Isolamento por clínica no banco de dados. Toda tabela é escopada por clínica e protegida por Row Level Security, com o vínculo derivado da sessão do usuário autenticado. Funções de escrita derivam a clínica da sessão e nunca aceitam a clínica como parâmetro. Funções internas nascem sem permissão para usuário anônimo. O que essa regra governa, e o que ela não governa: ela vale para o acesso dos usuários. A operação do Sistema usa também uma chave administrativa de servidor que não está sujeita a esse isolamento — e isso precisa ser dito, porque uma política de dado de saúde que descreve a RLS e cala a chave descreve metade do desenho. Ela é necessária para criar a clínica no cadastro (que acontece antes de existir vínculo), receber as mensagens de WhatsApp (que chegam sem sessão de usuário), executar as rotinas automáticas, dar baixa nos pagamentos que o meio de pagamento confirma, processar o encerramento da assinatura e prestar suporte. Na prática, ela dá à ALVORA IA acesso técnico irrestrito ao dado de todas as clínicas, inclusive prontuário. O uso é limitado a essas finalidades; escritas em tabelas sensíveis ficam na trilha de auditoria imutável; a chave é exclusivamente de servidor e nunca vai ao navegador. Não usamos esse acesso para finalidade própria (§2.1).
• Trilha de auditoria imutável em tabelas sensíveis (§3.4).
• Imutabilidade da evolução assinada (§8.5).
• Arquivos sensíveis em repositórios privados, acessados por link temporário (300 segundos para mídia de conversa, 1 hora para fotografias e prescrições). Exceção declarada: as imagens de caso (§3.2.6).
• Chaves de serviço nunca expostas ao navegador; a chave administrativa é exclusivamente de servidor.
• Comunicação cifrada em trânsito (HTTPS) e cifragem em repouso pelo provedor de banco de dados.
• Segregação de acesso por papel, com preset por função e itens de menu ocultos para quem não tem direito.
• Rotinas automáticas protegidas por segredo e webhooks protegidos por token dedicado.
• Token de integração armazenado como resumo criptográfico (não em texto claro), com limite de requisições por minuto.

Limite que é preciso declarar em vez de esconder: o isolamento por clínica é forte no banco de dados, e ainda não é completo no canal de WhatsApp e no meio de pagamento, que hoje operam com configuração global (§3.2.7).

11. Incidentes de segurança

Se ocorrer incidente de segurança que possa acarretar risco ou dano relevante aos titulares, a ALVORA IA comunicará a clínica, na qualidade de controladora, em prazo razoável, com as informações necessárias para que ela avalie a comunicação à ANPD e aos titulares (LGPD, art. 48). A comunicação à ANPD e aos titulares de dados de paciente é atribuição da clínica, com nosso apoio técnico.

12. Decisões automatizadas

Dois pontos do Sistema produzem efeito a partir de tratamento automatizado, e o titular tem direito a revisão (LGPD, art. 20):

• 1.Liberação de pagamento parcelado por boleto condicionada a corte de score de crédito. A decisão final é do profissional: existe recurso de sobreposição do resultado, com motivo registrado e auditável. Falha técnica na consulta não nega crédito.
• 2.Respostas do robô de atendimento, que conversa com o interessado e classifica o interesse. O desfecho de cada decisão do robô é registrado. Hoje não há tela que exiba esse registro ao cliente (§3.4); o acesso é sob solicitação.

13. Encarregado pelo tratamento de dados (DPO)

Encaminhamento sugerido, para o advogado avaliar: indicar nome do encarregado e um canal que exista de fato no dia da publicação. Se a decisão for usar WhatsApp como canal único no início, isso deve estar escrito assim, com o número real, e não disfarçado de "central de privacidade".

14. Cookies e rastreamento

Neste ponto o Sistema está acima da média, e a afirmação é verificável — mas ela tem uma exceção, e a exceção vem declarada em vez de arredondada:

• O único cookie gravado pelo Sistema é o cookie de sessão da biblioteca de autenticação, necessário para manter você conectado. É cookie estritamente necessário.
• Não usamos ferramenta de analytics, pixel de rede social, mapa de calor ou gravador de sessão próprios em nenhuma página, inclusive nas páginas públicas de venda e de cadastro. Uma varredura no código por essas ferramentas não retorna nenhuma ocorrência. Não medimos audiência, não perfilamos visitante e não fazemos remarketing.
• Precisão que esta versão passou a dever, por causa do §3.1.1: quando alguém conclui o cadastro, a página de origem — o endereço de onde a pessoa veio, informado pelo próprio navegador — é gravada junto com o registro de prospect. Isso é atribuição de origem no instante do cadastro — não usa cookie, não acompanha a pessoa entre sites, não observa quem apenas visita e some junto com o registro no prazo do §3.1.1. Está declarado aqui, e não só na seção de dados, porque é registro de origem e a seção de rastreamento é onde se procura por isso. Os campos de campanha (utm_*) do registro hoje ficam vazios, porque os links do site não propagam esses parâmetros até o cadastro (§3.1.1).
• Exceção — cookie de terceiro na página pública do orçamento. Quando a clínica insere um link de vídeo no orçamento, a reprodução é feita pelo provedor do vídeo (YouTube, Vimeo ou Loom) dentro da página que o paciente abre. Nessa hipótese o provedor recebe o IP, a identificação do navegador e o endereço de origem da página, e pode gravar cookies próprios no dispositivo do paciente — cookies que não são nossos e que não são estritamente necessários. Hoje o Sistema não usa o modo sem cookies do YouTube. Sem vídeo no orçamento, nenhum cookie de terceiro entra em jogo.
• Não há banner de consentimento de cookies hoje. Enquanto a exceção acima existir, esta política não pode justificar essa ausência dizendo que não há cookie a consentir além do necessário — nas páginas com vídeo, há.
• As páginas públicas por link não registram IP nem identificador completo do navegador do lado do Sistema (§3.3). A única captura de IP é o registro de aceite dos documentos legais, que é do usuário contratante (§3.1).

15. Crianças e adolescentes

O Sistema é usado em odontologia, inclusive odontopediatria: é esperado que haja dados de crianças e adolescentes cadastrados pelas clínicas, incluindo dado de saúde. O tratamento desses dados deve observar o art. 14 da LGPD (melhor interesse do titular e, quando aplicável, consentimento específico de pelo menos um dos pais ou responsável legal).

Sendo preciso: o Sistema não tem hoje campo de responsável legal no cadastro de paciente, nem trava que diferencie menor de idade, nem registro de consentimento parental. A data de nascimento é registrada, mas não governa nenhuma regra.

16. Alterações desta Política

Esta Política é versionada. Cada versão recebe número e data de vigência, e as versões anteriores permanecem publicamente consultáveis, para que se possa saber exatamente qual texto valia em qual data.

O número acompanha o texto: mudou o corpo do documento, sobe o número, ainda que a mudança não altere o estágio de revisão jurídica (ver a nota do topo). É o que permite ao registro de aceite — que guarda número e resumo criptográfico juntos — provar qual redação cada pessoa aceitou. Foi o que aconteceu nesta versão, cuja alteração substantiva é a coleta do WhatsApp e o tratamento do §3.1.1.

Anexo A — Checklist para a clínica informar o paciente dela

A clínica é a controladora (§2.1) e por isso tem o dever de informar. O que segue são os fatos técnicos que só nós conhecemos e que a clínica precisa para cumprir esse dever. Este anexo é material de apoio, não transfere responsabilidade.

• 1.Se a clínica usa o prontuário por voz: o áudio da consulta é enviado a um serviço de transcrição nos Estados Unidos, e o texto resultante é enviado a um serviço de inteligência artificial também nos Estados Unidos para organizar a evolução. O áudio é apagado após a transcrição e, em qualquer hipótese, em até 30 dias. O rascunho é sempre revisado pelo profissional. O paciente deve ser informado antes de a gravação começar, e é a clínica que faz isso.
• 2.Se a clínica usa o robô de atendimento: o texto da conversa de WhatsApp do paciente é enviado a um serviço de inteligência artificial nos Estados Unidos; áudios recebidos são transcritos por serviço nos Estados Unidos. Se a voz sintética estiver ativa, o texto da resposta do robô vai a um terceiro serviço nos Estados Unidos.
• 3.Se a clínica usa a análise de crédito: há consulta a birô de crédito sobre o CPF do paciente. Leia o §3.2.5 antes de usar o recurso.
• 4.Se a clínica usa a biblioteca de casos: as imagens de antes e depois ficam em repositório público (§3.2.6). Não use imagem de paciente que não tenha autorizado por escrito, especificamente, o uso em material de divulgação.
• 5.Se a clínica ativa a automação externa: nome, WhatsApp e procedimento do paciente passam a ser enviados a um endereço escolhido pela clínica, e a responsabilidade por esse destino é dela (§5.2).
• 6.Preferência de "não quero receber mensagens": hoje ela é respeitada apenas na régua de cobrança (§3.2.8). Se um paciente pedir para não ser contatado, a clínica precisa garantir isso operacionalmente.
• 7.Links do paciente (portal e anamnese) não expiram e não podem ser revogados hoje (§3.3). Trate o link como dado sensível ao encaminhá-lo.
• 8.Evolução assinada não pode ser apagada (§8.5), e paciente com histórico não pode ser excluído (§8.6).

Anexo B — Lista dos [[CONFIRMAR]]

Ordenados por bloqueio. Os quatro primeiros impedem a publicação do documento (o item 4 já foi respondido e fica registrado para memória da decisão).

Bloqueiam a publicação:

• 1.CNPJ da ALVORA IA TECNOLOGIA LTDA. (§1) — a empresa está constituída?
• 2.Endereço completo da sede (§1).
• 3.Canal de contato válido e identidade do encarregado (§13) — não existe e-mail, e o número de WhatsApp publicado é de exemplo. Este item passou a bloquear também o §3.1.1: sem número real não há régua de acompanhamento, e é também para este canal que se dirige quem pede para parar sem usar o link de descadastro (item 16, "c").
• 4.RESOLVIDO em 25/07/2026 — qual marca assina: ALVORA IA (§1). Ortho+ é a clínica do fundador e primeiro cliente do Sistema, não é fornecedora e não é parte. Resta a correção do site público, que ainda assina "Ortho+" — correção de site, não de documento.
• 5.Endereço do Sistema na internet (§1) — alvora.ia.br não está registrado e alvora.ai é de terceiro.

Decisões que mudam o produto, não o texto:

• 6.Base legal e retorno da exigência de consentimento na consulta de crédito, e o campo que hoje grava "consentimento dado" como verdadeiro sempre (§3.2.5).
• 7.Mecanismo de transferência internacional para Anthropic, AssemblyAI e ElevenLabs, e aplicação das cláusulas-padrão da Resolução CD/ANPD nº 19/2024 (§6).
• 8.Prazo de retenção das conversas de WhatsApp e mídias recebidas, hoje perpétuas por omissão (§8.4).
• 9.Prazo de retenção após o encerramento do contrato da clínica, e a rotina que o execute (§8.3).
• 10.Imagens de antes/depois em repositório público (§3.2.6).
• 11.Links de paciente sem validade e sem revogação (§3.3).
• 12.Central de preferências de comunicação valendo em todos os caminhos de envio (§3.2.8).
• 13.Completar a exportação por paciente e criar exportação da clínica (§9.3).
• 14.Isolamento por clínica no canal de WhatsApp e no meio de pagamento (§3.2.7).
• 15.Consentimento do responsável legal para paciente menor de idade (§15).
• 16.Pré-requisitos para ligar a régua de acompanhamento comercial (§3.1.1), e são três: (a) número de WhatsApp real da ALVORA IA; (b) link de descadastro sem login funcionando — a página que atende esse link ainda não existe; (c) coerência entre a saída que a mensagem oferece e a saída que o código atende sozinho: o canal da ALVORA IA é só de saída, nenhum código lê resposta, então a mensagem só pode oferecer o link (é o que ela oferece hoje). Anunciar "responda PARE" exige, antes, tratar essa resposta; enquanto não existir, quem responder é atendido por pessoa, pelo canal do §13 (§3.1.1 e §9.2). Faltando qualquer um dos três, a régua fica desligada — é regra assumida no texto, não recomendação.
• 17.Relatório de legítimo interesse (§3.1.1) formalizado, datado e assinado, para a hipótese do art. 10, §3. O esboço do balanceamento está escrito no §3.1.1.

Fatos a verificar antes de publicar:

• 18.Região real do projeto de banco de dados de produção (§5) — sem isso não se afirma "dados no Brasil".
• 19.A voz sintética está ativa em produção? (§4.1).
• 20.O prontuário por voz está em modo de demonstração? (§4.2).
• 21.A análise de crédito está em modo de demonstração? (§3.2.5).
• 22.A descrição da cobrança enviada ao meio de pagamento contém nome de procedimento? Se sim, o provedor passa a receber indício de dado de saúde (§5).
• 23.Garantias contratuais de não-treinamento e retenção dos provedores de IA (§4.4).
• 24.A rotina de expurgo do §3.1.1 está agendada? VERIFICADO: NÃO — pendente. A função que apaga existe no banco de dados e nenhum código a chama; o único agendamento criado nesta versão é o da régua de acompanhamento, que envia e não apaga. Por isso o §8.1 tirou o prospect da tabela do que expira sozinho e o §8.4 conta uma rotina agendada, não duas: prazo escrito em política e não executado por código é promessa vazia, e este documento não podia denunciar isso no resto do Sistema e praticar o mesmo na seção sobre nós. Enquanto a rotina não for agendada, os 180 dias e os 30 dias dependem de execução manual — que é o que o texto declara hoje. Agendá-la (rotina diária; agendamento com frequência menor que o dia faz o deploy ser rejeitado em silêncio na plataforma que hospeda o Sistema) devolve o prazo ao código e permite reescrever §8.1, §8.4 e §3.1.1 na forma automática.

Definições jurídicas:

• 25.Prazo de guarda de prontuário a citar, com a norma (§8.2).
• 26.Prazo de comunicação de incidente entre operador e controlador (§11).
• 27.O registro de aceite grava IP e navegador, por quanto tempo, integral ou truncado (§3.1).
• 28.Previsão de sucessão empresarial (§7).
• 29.Data de vigência e regra de aviso de nova versão (§16 e frontmatter).
• 30.Re-aceite por causa desta versão (§3.1.1): quem aceitou a versão 0 aceitou um texto que não falava em contato comercial de acompanhamento. Como a régua nasce desligada e o campo de WhatsApp só passa a existir com este texto, a leitura prática é que não há prospect anterior a proteger — mas quem decide se cabe re-aceite é o advogado, não o autor deste rascunho.