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 — são quatro travas cumulativas (canal dedicado inexistente, chave de ativação desligada, interruptor por passo no banco e textos não aprovados), e a primeira já barra. O envio também recusa usar o número que atende paciente. O que existe hoje é o registro do prospect — a tabela está criada e vazia —; a régua roda todo dia em modo de prévia, que calcula a fila e não escreve nem envia.
• 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.
• A página de descadastro já existe. Verificado em 26/07/2026: a rota pública que atende o link está no ar, dispensa login e a função de banco que ela usa é a única daquele conjunto liberada para acesso não autenticado — de propósito, porque exigir sessão para exercer oposição é o desenho que vira reclamação na ANPD. A versão anterior deste texto dizia que a página "ainda não existe"; deixou de ser verdade e a afirmação foi corrigida em vez de mantida por inércia.
• 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 (é a única das três que falta); o link de descadastro funcionando (existe); e coerência entre a saída que a mensagem oferece e a saída que o código atende sozinho (existe: a mensagem oferece só o link, que é o que o código atende). 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á.
• O paciente sabe que é um robô? A resposta honesta é: só se ele perguntar. O robô se apresenta por um nome próprio e conversa como atendente da clínica; ele não anuncia por conta própria que é atendimento automatizado. Perguntado diretamente se é robô, se é inteligência artificial ou se é "uma pessoa de verdade", ele confirma que é atendimento automatizado, oferece transferir para uma pessoa e é instruído a nunca insistir que é humano. Isso está escrito assim porque é o que o código faz, e porque a pergunta é inevitável quando se explica que a conversa vai para um modelo de linguagem no exterior. O dever de informar o paciente é da clínica (§2.1), e o item 2 do Anexo A traz o que ela precisa dizer.

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.

Dito sem rodeio, porque é o maior risco deste documento: a ALVORA IA não firmou nenhum desses mecanismos. Não há cláusulas-padrão assinadas com Anthropic, AssemblyAI ou ElevenLabs, não há cláusulas específicas aprovadas pela ANPD e não há consentimento do art. 33, VIII sendo colhido do paciente. Esta política não afirma que a transferência está regularizada, e a clínica não deve presumir que está.

A transferência é evitável, e essa é a informação prática que falta em políticas parecidas com esta. Tudo o que sai do país está dentro de módulos adicionais contratados à parte — o atendimento por WhatsApp com robô, o prontuário por voz e os recursos de apoio que deles dependem. O gasto com esses provedores é barrado antes da chamada quando o módulo não está contratado; é gate comercial, não boa vontade. Clínica que não contrata esses módulos não tem dado de paciente saindo do Brasil por este Sistema — restam apenas os subprocessadores nacionais e a infraestrutura da Meta, que é inerente ao canal de WhatsApp e independe do Sistema (§3.2.7).

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.

E há uma vedação específica que merece estar escrita, e não apenas cumprida por omissão: a ALVORA IA não comunica nem compartilha dado pessoal sensível referente à saúde com o objetivo de obter vantagem econômica — nem com operadora de plano de saúde, nem com seguradora, nem com instituição financeira, nem com birô de dados, nem com corretora, nem com qualquer terceiro interessado no perfil de saúde de alguém. É o art. 11, §4º da LGPD, e a razão de citá-lo é que é exatamente aqui que empresas de software de saúde monetizam sem contar. A vedação não alcança os subprocessadores necessários à operação (§5), a portabilidade pedida pelo titular, a requisição de autoridade competente e o exercício regular de direitos.

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.

9.5 Prazos, gratuidade e a quem reclamar

Faltava esta parte, e ela é a que o titular usa:

• Prazo. O pedido de confirmação de existência de tratamento e de acesso é atendido imediatamente, em formato simplificado, ou por declaração completa em até 15 (quinze) dias contados do requerimento (LGPD, art. 19, I e II). Quem cumpre esse prazo perante o paciente é a clínica, que é a controladora; a ALVORA IA presta o apoio técnico.
• Gratuidade. O exercício dos direitos do titular é gratuito e não depende de justificativa (art. 18, caput, e §5º).
• Oposição. O titular pode se opor a tratamento fundado em hipótese que dispense consentimento, quando houver descumprimento da lei (art. 18, §2º) — e, no caso do contato comercial da ALVORA IA, a oposição é aceita sem qualquer justificativa e é definitiva (§3.1.1).
• Revogação. Onde a base for consentimento, ele pode ser revogado a qualquer momento, por procedimento gratuito e facilitado (art. 8º, §5º).
• A quem reclamar. Além do canal do §13, o titular pode peticionar à Autoridade Nacional de Proteção de Dados (ANPD) contra o controlador (art. 18, §1º) e recorrer aos órgãos de defesa do consumidor. Esta política não pede, e não poderia pedir, que o titular esgote o canal interno antes disso.

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.

Como pedir revisão, e o que se tem direito de saber. O pedido é dirigido à clínica (§9.1), que é a controladora e é quem decide; a ALVORA IA fornece o registro e o apoio técnico. Além da revisão, o titular tem direito a informação clara e adequada sobre os critérios e procedimentos da decisão automatizada (art. 20, §1º) — e, no ponto 1, os critérios são declaráveis sem mistério: existe um corte numérico de pontuação, definido pela própria clínica, e o resultado abaixo do corte não bloqueia nada por si só, porque a sobreposição pelo profissional está sempre disponível e exige motivo escrito, que fica registrado com autor e data. Falha técnica na consulta não nega crédito: o sistema devolve erro e devolve a decisão ao profissional.

Dois limites declarados, porque o titular precisa deles para saber o que esperar: no ponto 1 a revisão é humana por desenho (a sobreposição existe exatamente para isso); no ponto 2 não há tela de auditoria, então a revisão depende de solicitação atendida por pessoa. Nenhum dos dois é decisão exclusivamente automatizada de efeito irreversível — em ambos, quem decide no fim é gente da clínica.

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. A alteração substantiva da versão 1 foi a coleta do WhatsApp e o tratamento do §3.1.1.

O que a versão 2 mudou, para que a comparação entre as duas seja possível sem diff:

• 1.Declarou a revisão por IA e o risco residual (nota do topo e §17).
• 2.Declarou que o mecanismo de transferência internacional NÃO está firmado e que a transferência é evitável, porque os recursos que enviam dado ao exterior estão todos em módulos contratados à parte (§6).
• 3.Respondeu "o paciente sabe que é um robô?" com o comportamento real do código: não se anuncia, mas confirma se perguntado e nunca insiste que é humano (§4.1).
• 4.Acrescentou prazos, gratuidade, oposição, revogação e o direito de peticionar à ANPD — a parte operacional que faltava aos direitos do titular (§9.5).
• 5.Detalhou os critérios da decisão automatizada e o direito à informação sobre eles (§12).
• 6.Escreveu a vedação do art. 11, §4º (dado de saúde não é ativo comercial) em vez de deixá-la implícita (§7).
• 7.Corrigiu quatro afirmações que o código desmentiu: a versão 1 foi publicada; a estrutura de banco do §3.1.1 foi aplicada; a página de descadastro existe; e duas citações de migration apontavam arquivo inexistente.

17. Quem revisou este documento, e o risco que a revisão não remove

Esta seção existe porque a alternativa era deixar o leitor supor que um advogado escreveu o texto. Não escreveu.

Quem escreveu e quem revisou. A versão 1 foi redigida a partir de auditoria do código-fonte. A versão 2 passou por revisão de conformidade feita por assistente de inteligência artificial, em 26/07/2026, por decisão expressa do responsável pela ALVORA IA, que optou por não contratar advogado nesta etapa e assumir o risco de forma informada. A revisão conferiu cada afirmação factual contra o código e contra o banco de produção, e comparou o texto com a LGPD, o CDC, as Resoluções CD/ANPD nº 15/2024 e nº 19/2024 e os decretos aplicáveis à venda pela internet.

O que essa revisão NÃO é. Não é parecer jurídico. Não foi feita por advogado. Juízo sobre a validade de uma cláusula concreta diante de norma cogente é atividade privativa de advogado, e um ponto deste documento pode estar errado sem que a revisão tenha percebido.

O risco residual, nomeado em vez de diluído. Em ordem de gravidade:

• 1.Transferência internacional de dado sensível de saúde sem mecanismo de adequação firmado (§6). Redação não cria mecanismo. É o pior risco do produto, e ele atinge diretamente o paciente, que não é parte de nada disso.
• 2.O registro de consulta de crédito grava "consentimento dado" como verdadeiro sem consentimento colhido (§3.2.5). É defeito de código, sobre CPF de pessoa natural, e produz um registro que afirma algo que pode não ter acontecido.
• 3.Retenção perpétua por omissão da maior massa de dado pessoal do Sistema — conversas de WhatsApp, mídias recebidas, fotografias clínicas (§8.4). Não existe rotina que apague.
• 4.Não há encarregado nomeado nem canal de contato válido (§13), o que é obrigação do art. 41 e bloqueia a publicação.
• 5.Imagens de paciente identificável em repositório público (§3.2.6) e links de paciente sem validade e sem revogação (§3.3).
• 6.Não existe campo de responsável legal nem registro de consentimento parental para paciente menor de idade (§15).

Nada aqui foi inventado para fechar lacuna. Onde falta fato — CNPJ, sede, encarregado, canal —, o texto mostra [[CONFIRMAR]] em destaque, e é assim de propósito: preencher com número plausível seria falsificar a identificação do fornecedor, que é pior do que a lacuna visível.

Na dúvida sobre o alcance de qualquer parágrafo, prevalece a interpretação mais favorável ao titular e à clínica — que é o que a lei já determina em contrato de adesão (Código Civil, art. 423; CDC, art. 47), e é a consequência coerente de publicar um texto que a própria ALVORA IA declara não revisado por advogado.

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. E há um ponto que só a clínica pode resolver: o robô não avisa por conta própria que é automatizado (§4.1). Ele confirma se perguntado e nunca insiste que é humano, mas quem responde pela informação ao paciente é a clínica — inclusive perante o CDC, que exige informação clara e adequada sobre o serviço. Avisar que o primeiro atendimento é feito por sistema automatizado, e manter caminho para uma pessoa, é decisão e responsabilidade da clínica. O robô também não faz triagem clínica: relato de urgência ou dor aguda exige avaliação de profissional habilitado.
• 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 itens 1 a 5 impedem a publicação do documento — o item 4 já foi respondido e fica registrado para memória da decisão, então quatro seguem abertos.

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 — dois já cumpridos: (a) número de WhatsApp real da ALVORA IA — É O QUE FALTA; (b) link de descadastro sem login funcionando — CUMPRIDO: verificado em 26/07/2026, a página existe e é pública (a versão 1 dizia que não existia, e isso deixou de ser verdade); (c) coerência entre a saída que a mensagem oferece e a saída que o código atende sozinho — CUMPRIDO: o canal da ALVORA IA é só de saída, nenhum código lê resposta, e a mensagem oferece apenas o link. 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. Fato novo, conferido no banco em 26/07/2026: a tabela de aceites está VAZIA (zero linhas). Não existe ninguém que tenha aceitado a versão 0 ou a 1, então a questão do re-aceite é, hoje, teórica — e será real no primeiro cadastro.

Acrescentados pela revisão da versão 2 (26/07/2026):

• 31.Identificação espontânea do robô ao paciente (§4.1). Hoje ele só confirma se perguntado. Anúncio espontâneo na primeira mensagem é a leitura mais segura do dever de informação; a objeção é de conversão, não jurídica. Decisão do dono.
• 32.Prazo interno de apoio a pedido de titular (§9.5), que precisa ser menor que os 15 dias legais da clínica. Depende de existir suporte com fila.
• 33.Relatório de impacto à proteção de dados (RIPD) para o tratamento de dado sensível de saúde com transferência internacional. O art. 38 permite à ANPD exigi-lo do controlador; num tratamento de saúde com envio ao exterior sem mecanismo firmado, é o documento que se pede primeiro. Matéria do advogado, e não existe hoje.
• 34.Campo de responsável legal e registro de consentimento parental (§15), ausentes no cadastro de paciente — é código, não redação.