Última atualização: setembro de 2026 · Documento informativo com base no código e na infraestrutura atuais.

Retenção de dados e informações LGPD

A entidade prestadora e o canal único de privacidade / DPO estão identificados abaixo. Esta página descreve o que o código faz hoje; onde o produto ainda não automatiza algo, isso está dito de forma explícita em vez de omitido.

Este documento descreve como a plataforma InstantChat trata dados pessoais na qualidade de operadora (processadora), em nome do cliente contratante — em geral clínicas, empresas de vendas ou equipes de suporte — que atua como controladora dos dados de seus pacientes, leads e clientes finais.

Prestadora: AUGUSTO CLARO E CIA SERVIÇOS TECNOLÓGICOS LTDA, CNPJ 20.712.349/0001-63, sede em Avenida São João, 1277, República, São Paulo/SP, CEP 01035-100. Canal de privacidade / DPO: [email protected].

Papéis na LGPD

Controladora: a organização cliente que configura o assistente, define o uso dos dados e responde perante os titulares (ex.: clínica, loja, empresa de suporte).
Operadora: InstantChat, que hospeda a aplicação, executa conversas automatizadas, integrações (WhatsApp, agenda, base de conhecimento) e armazena dados conforme instruções do cliente na plataforma.

Para obrigações contratuais de tratamento em nome do cliente, consulte também o Acordo de Processamento de Dados (DPA).

Categorias de dados processados

Conforme modelos e fluxos implementados no produto:

Conversas (web e widget): sessões de chat, mensagens de usuário e do assistente (chat_sessions, chat_messages), incluindo metadados associados.
WhatsApp: mensagens recebidas e respostas na fila de processamento (whatsapp_inbox) — conteúdo, identificador remoto (JID), telefone do remetente quando disponível e payload bruto da mensagem quando armazenado.
Leads: nome, e-mail, telefone, notas, status e metadados (leads), vinculados a sessão e assistente.
Contatos e identidades de canal: grafo de contato por tenant (telefone, e-mail, nomes canônicos) para unificar conversas entre canais.
Credenciais de conexão: estado de autenticação WhatsApp e tokens de provedores (Cloud API, Evolution etc.) em connections.credentials, com segredos sensíveis cifrados em repouso (formato enc:v1:, AES-256-GCM).
Agenda (quando habilitada): agendamentos, recursos e lembretes (agenda_bookings e tabelas relacionadas), podendo referenciar lead/contato.
Base de conhecimento: documentos enviados ou obtidos por crawl, trechos e índices de busca (Postgres + vetores em OpenSearch em produção; ChromaDB apenas quando OpenSearch não está configurado — ambiente de desenvolvimento).
Tickets de suporte (vertical Sol): nome, e-mail e telefone do usuário final, mensagens do ticket (tickets, ticket_messages).
Conta do cliente (usuários da plataforma): cadastro, autenticação e membros do tenant; tokens de redefinição de senha (uso único, com validade).
Atribuição de marketing (first-touch): no cadastro do tenant podem ser armazenados ctwa_clid e parâmetros UTM sanitizados (tenants.attribution), quando presentes na URL de origem.
Logs de chamadas a modelos de linguagem: métricas de uso e o texto de prompt/resposta em llm_call_logs (pode reproduzir conteúdo de conversas). O registro do texto não é condicional — acontece em toda chamada — e o texto é apagado automaticamente após 30 dias; as métricas de custo e uso da mesma linha permanecem, porque são registro de cobrança.
Cobrança: assinatura e pagamentos processados via Stripe (dados de pagamento ficam no Stripe; a plataforma mantém referências de assinatura e uso). Inclui o extrato da carteira de consumo — um lançamento por recarga e por cobrança de excedente — retido como registro de cobrança e visível ao Cliente no painel.
Chaves de API (MCP/parceiros): armazenamento apenas do hash da chave, não do valor em claro.

Dados que a InstantChat não envia por e-mail aos leads/pacientes/clientes finais em fluxos padrão de captação (comunicação orientada a WhatsApp); exceções documentadas no produto incluem o portal de tickets da vertical Sol.

Política de e-mails ao titular da conta. São transacionais, e por isso enviados sem necessidade de descadastro, os avisos operacionais configurados pelo próprio Cliente (novo lead, pergunta sem resposta, desconexão de WhatsApp e demais eventos da página de preferências), a redefinição de senha e os e-mails de ticket da vertical Sol. É marketing a sequência de nutrição do teste gratuito — seis mensagens, nos dias 0, 1, 3, 7, 12 e 14 do período de teste —, que por isso traz link de descadastro em todas as mensagens e pode ser desligada a qualquer momento pelo próprio Cliente, na página de preferências de avisos da plataforma. O descadastro da nutrição não desliga os e-mails transacionais, que são necessários à execução do contrato.

Prazos e exclusão automática

A tabela abaixo reflete comportamentos encontrados no código. Não constitui promessa jurídica além do que está implementado. Há uma rotina automática de retenção com prazo máximo para as conversas: são apagadas 730 dias após a última mensagem, por varredura diária (primeira linha da tabela). Não há fluxo automatizado de exportação completa (portabilidade) nem de exclusão/anonimização em massa pós-rescisão — esses mecanismos ainda não estão implementados no produto. Após o término do contrato, a remoção dos demais dados do Cliente depende de solicitação ao canal de privacidade e de ações manuais na plataforma (quando existirem).

Prazos comerciais que afetam retenção. Alteração de preço: aviso prévio de 30 dias. Inadimplência: 15 dias de aviso antes da suspensão (Termos de Uso, Seções 3 e 8). A inadimplência não dispara exclusão de dados — a suspensão restringe o acesso e não apaga o histórico; a única exclusão automática é a janela de retenção de conversas da tabela abaixo, que corre da mesma forma com a conta ativa ou suspensa. O consumo excedente (cobrança acima da cota, teto de acúmulo de 3× o valor mensal, cobrança do cartão salvo fora de checkout e mudança de plano pro rata) está descrito na Seção 3 dos Termos de Uso; aqui ele aparece apenas como o registro de cobrança retido — o extrato da carteira, na categoria “Cobrança” listada acima.

Categoria	Retenção no sistema
Conversas: sessões e mensagens de chat (`chat_sessions`, `chat_messages`), filas de entrada (`whatsapp_inbox`, `web_inbox`, `instagram_inbox`), anotações internas, rascunhos de resposta, estado de atendimento humano e proveniência das respostas	Apagadas automaticamente 730 dias (cerca de 24 meses) após a última mensagem da conversa, por varredura diária (`CONVERSATION_RETENTION_DAYS`). A rotina apaga a conversa e tudo o que a compõe; o que a conversa gerou e pertence ao registro do cliente fica — ver a linha seguinte. A linha de custo em `llm_call_logs` e o alerta operacional que apontavam para a conversa perdem essa referência e permanecem.
Leads, contatos, agenda, tickets, perguntas sem resposta, KB	Sem rotina automática de purge — são registros do cliente, com dono próprio, e permanecem até exclusão manual pelo cliente (ex.: apagar lead, conteúdo, assistente) ou encerramento da conta. Divulgado tal como está: exclusão e portabilidade do art. 18 dependem hoje de ação manual; a automação está planejada como requisito de produto, sem data assumida.
Rascunhos de resposta pendentes (moderação humana)	Expiração automática após 30 minutos por padrão (`DEFAULT_DRAFT_EXPIRY_MINUTES`), com job agendado a cada minuto.
Texto de prompt/resposta em `llm_call_logs`	Apagado automaticamente após 30 dias, por varredura diária (`LLM_TEXT_RETENTION_DAYS`). A linha permanece — ela é o registro de custo e uso por modelo, lido pelas telas de cobrança — apenas as duas colunas de texto livre são limpas.
Token de redefinição de senha (usuários da plataforma)	Validade de 2 horas; uso único.
QR / código de pareamento WhatsApp (Redis)	~60 s (QR) e ~160 s (pareamento) — cache operacional, não arquivo de conversa.
Fluxo OAuth / consentimento MCP (Redis)	Pendência ~5 min; código de autorização ~60 s.
Cache de embeddings (Redis)	TTL de 30 dias para reutilização de vetores de texto idêntico.
Demo pública no site (contadores Redis)	Contadores de sessão/dia com TTL de 24 h (limites de uso, não histórico de conversa da demo em Postgres).
Tickets Sol em status “resolvido”	Podem passar a “fechado” após 7 dias de inatividade (padrão configurável via `TICKET_AUTO_CLOSE_IDLE_DAYS`) — alteração de status, não exclusão de dados.
Stripe, provedores de LLM, e-mail (Resend), CDN	Retenção definida por cada suboperador, nos termos que ele próprio publica — não os reproduzimos aqui porque podem mudar sem aviso à InstantChat, e uma cópia desatualizada seria pior que um link. Consultados em 12/08/2026: OpenAI, OpenRouter, Stripe, Resend, Cloudflare. Ver também o DPA.
LangSmith / rastreamento de prompts	Ativo em produção (`LANGCHAIN_TRACING_V2`): traces com conteúdo de prompts e respostas são enviados ao LangSmith para observabilidade. Retenção na conta LangSmith segue a política do suboperador.

Direitos dos titulares

Pedidos de acesso, correção, exclusão, portabilidade ou oposição relativos a dados tratados em nome do cliente devem ser direcionados, em primeira instância, à controladora (organização que usa o InstantChat). Na plataforma, o Cliente pode hoje apagar ou editar alguns registros pontuais (por exemplo, leads ou conteúdo de base de conhecimento), conforme permissões do usuário — não há exportação completa da conta; a exclusão automática limita-se à janela de retenção de conversas descrita acima (leads, agenda e tickets não são apagados automaticamente). A operadora auxilia a controladora, nos limites técnicos atuais, mediante solicitação ao canal de privacidade: [email protected]; resposta no prazo legal de 15 dias previsto no art. 19, § 1º, da LGPD (não se trata de SLA discricionário).

Segurança (resumo técnico)

Credenciais sensíveis de WhatsApp e tokens de provedores cifrados em repouso (AES-256-GCM).
Autenticação de usuários da plataforma via JWT e controle de sessão.
Hospedagem: Hostinger International Limited, servidor em Boston, Massachusetts, Estados Unidos.
Backups: procedimento documentado de dump semanal do PostgreSQL, com retenção das 4 cópias mais recentes por banco, gravadas no próprio servidor. Não há cópia off-site nem replicação; por isso não assumimos compromisso de RPO/RTO e a perda do servidor não é coberta pelos backups locais. Redis (estado de filas) e índices de busca não são copiados — o primeiro persiste por AOF entre reinícios, os segundos são reconstruíveis a partir do PostgreSQL. Não detemos certificações de segurança de infraestrutura (por exemplo ISO 27001 ou SOC 2) e não as declaramos.

Versão em inglês: use o seletor de idioma no rodapé da página inicial, ou ?lang=en nesta URL. A versão em inglês é uma tradução integral desta página, não um resumo; em caso de divergência, o texto em português prevalece.

Last updated: September 2026 · Informational document based on current code and infrastructure.

Data retention and LGPD information

The provider entity and the single privacy / DPO channel are identified below. This page describes what the code does today; where the product does not yet automate something, that is stated explicitly rather than omitted.

This document describes how the InstantChat platform processes personal data in the capacity of operator (processor), on behalf of the contracting customer — generally clinics, sales companies or support teams — which acts as the controller of the data of its patients, leads and end customers.

Provider: AUGUSTO CLARO E CIA SERVIÇOS TECNOLÓGICOS LTDA, CNPJ 20.712.349/0001-63, registered office at Avenida São João, 1277, República, São Paulo/SP, CEP 01035-100. Privacy / DPO channel: [email protected].

Roles under the LGPD

Controller: the customer organization that configures the assistant, defines how the data is used and answers to data subjects (e.g. a clinic, a shop, a support company).
Operator: InstantChat, which hosts the application, runs automated conversations, integrations (WhatsApp, scheduling, knowledge base) and stores data according to the customer's instructions given in the platform.

For the contractual obligations governing processing on the customer's behalf, see also the Data Processing Agreement (DPA).

Categories of data processed

As implemented in the product's models and flows:

Conversations (web and widget): chat sessions, user and assistant messages (chat_sessions, chat_messages), including associated metadata.
WhatsApp: inbound messages and replies in the processing queue (whatsapp_inbox) — content, remote identifier (JID), the sender's phone number when available and the raw message payload when stored.
Leads: name, email, phone, notes, status and metadata (leads), linked to a session and an assistant.
Contacts and channel identities: a per-tenant contact graph (phone, email, canonical names) used to unify conversations across channels.
Connection credentials: WhatsApp authentication state and provider tokens (Cloud API, Evolution and others) in connections.credentials, with sensitive secrets encrypted at rest (enc:v1: format, AES-256-GCM).
Scheduling (when enabled): bookings, resources and reminders (agenda_bookings and related tables), which may reference a lead or contact.
Knowledge base: documents uploaded or obtained by crawling, chunks and search indexes (Postgres + vectors in OpenSearch in production; ChromaDB only when OpenSearch is not configured — development environment).
Support tickets (Sol vertical): the end user's name, email and phone number, and the ticket messages (tickets, ticket_messages).
Customer account (platform users): registration, authentication and tenant members; password-reset tokens (single use, with an expiry).
Marketing attribution (first-touch): at tenant sign-up, ctwa_clid and sanitized UTM parameters may be stored (tenants.attribution) when present in the originating URL.
Language-model call logs: usage metrics and the prompt/response text in llm_call_logs (which may reproduce conversation content). Recording the text is not conditional — it happens on every call — and the text is deleted automatically after 30 days; the cost and usage metrics on the same row remain, because they are a billing record.
Billing: subscription and payments processed via Stripe (payment data stays with Stripe; the platform keeps subscription and usage references). Includes the usage-wallet statement — one entry per top-up and per overage charge — retained as a billing record and visible to the Customer in the dashboard.
API keys (MCP/partners): only the hash of the key is stored, not the plaintext value.

Data that InstantChat does not email to leads/patients/end customers in standard capture flows (communication is WhatsApp-oriented); exceptions documented in the product include the Sol vertical's ticket portal.

Email policy for the account holder. The operational alerts configured by the Customer themselves (new lead, unanswered question, WhatsApp disconnection and the other events on the preferences page), password reset and the Sol vertical's ticket emails are transactional, and are therefore sent without any need for an unsubscribe. The free-trial nurture sequence — six messages, on days 0, 1, 3, 7, 12 and 14 of the trial period — is marketing, and therefore carries an unsubscribe link in every message and can be switched off at any time by the Customer, on the platform's notification-preferences page. Unsubscribing from the nurture sequence does not switch off the transactional emails, which are necessary for performance of the contract.

Periods and automatic deletion

The table below reflects behaviours found in the code. It is not a legal promise beyond what is implemented. There is an automatic retention routine with a maximum period for conversations: they are deleted 730 days after the last message, by a daily sweep (first row of the table). There is no automated full-export (portability) flow and no bulk post-termination erasure/anonymisation flow — those mechanisms are not yet implemented in the product. After the contract ends, removal of the Customer's remaining data depends on a request to the privacy channel and on manual actions in the platform (where these exist).

Commercial periods that affect retention. Price change: 30 days of prior notice. Non-payment: 15 days of notice before suspension (Terms of Use, Sections 3 and 8). Non-payment does not trigger data deletion — suspension restricts access and does not erase the history; the only automatic deletion is the conversation retention window in the table below, which runs the same way whether the account is active or suspended. Overage (charging above the quota, an accrual cap of 3× the monthly amount, charging the card on file outside checkout, and pro-rata plan changes) is described in Section 3 of the Terms of Use; here it appears only as the billing record retained — the wallet statement, under the “Billing” category listed above.

Category	Retention in the system
Conversations: chat sessions and messages (`chat_sessions`, `chat_messages`), inbound queues (`whatsapp_inbox`, `web_inbox`, `instagram_inbox`), internal notes, reply drafts, human-takeover state and reply provenance	Deleted automatically 730 days (about 24 months) after the conversation's last message, by a daily sweep (`CONVERSATION_RETENTION_DAYS`). The routine deletes the conversation and everything that composes it; what the conversation generated and belongs to the customer's records stays — see the next row. The cost row in `llm_call_logs` and the operational alert that pointed at the conversation lose that reference and remain.
Leads, contacts, scheduling, tickets, unanswered questions, KB	No automatic purge routine — they are the customer's records, with an owner of their own, and they remain until manual deletion by the customer (e.g. deleting a lead, content, an assistant) or closure of the account. Disclosed as it stands: erasure and portability under art. 18 of the LGPD today depend on manual action; automation is planned as a product requirement, with no date committed.
Pending reply drafts (human moderation)	Automatic expiry after 30 minutes by default (`DEFAULT_DRAFT_EXPIRY_MINUTES`), with a job scheduled every minute.
Prompt/response text in `llm_call_logs`	Deleted automatically after 30 days, by a daily sweep (`LLM_TEXT_RETENTION_DAYS`). The row remains — it is the per-model cost and usage record, read by the billing screens — only the two free-text columns are cleared.
Password-reset token (platform users)	Valid for 2 hours; single use.
WhatsApp QR / pairing code (Redis)	~60 s (QR) and ~160 s (pairing) — operational cache, not a conversation archive.
OAuth flow / MCP consent (Redis)	Pending request ~5 min; authorization code ~60 s.
Embedding cache (Redis)	TTL of 30 days for reuse of vectors of identical text.
Public demo on the site (Redis counters)	Per-session/per-day counters with a TTL of 24 h (usage limits, not the demo's conversation history in Postgres).
Sol tickets in “resolved” status	May move to “closed” after 7 days of inactivity (default configurable via `TICKET_AUTO_CLOSE_IDLE_DAYS`) — a status change, not deletion of data.
Stripe, LLM providers, email (Resend), CDN	Retention set by each subprocessor, on the terms it publishes itself — we do not reproduce them here because they can change without notice to InstantChat, and an out-of-date copy would be worse than a link. Consulted on 12 August 2026: OpenAI, OpenRouter, Stripe, Resend, Cloudflare. See also the DPA.
LangSmith / prompt tracing	Active in production (`LANGCHAIN_TRACING_V2`): traces with prompt and response content are sent to LangSmith for observability. Retention in the LangSmith account follows the subprocessor's policy.

Data subject rights

Requests for access, correction, erasure, portability or objection concerning data processed on the customer's behalf must be addressed, in the first instance, to the controller (the organization that uses InstantChat). In the platform, the Customer can today delete or edit some individual records (for example, leads or knowledge-base content), subject to the user's permissions — there is no full export of the account; automatic deletion is limited to the conversation retention window described above (leads, scheduling and tickets are not deleted automatically). The operator assists the controller, within current technical limits, upon a request to the privacy channel: [email protected]; response within the statutory period of 15 days set out in art. 19, § 1º, of the LGPD (this is not a discretionary SLA).

Security (technical summary)

Sensitive WhatsApp credentials and provider tokens encrypted at rest (AES-256-GCM).
Platform user authentication via JWT and session control.
Hosting: Hostinger International Limited, server in Boston, Massachusetts, United States.
Backups: documented procedure of a weekly PostgreSQL dump, retaining the 4 most recent copies per database, written to the server itself. There is no off-site copy and no replication; for that reason we make no RPO/RTO commitment and loss of the server is not covered by the local backups. Redis (queue state) and the search indexes are not backed up — the former persists via AOF across restarts, the latter are rebuildable from PostgreSQL. We hold no infrastructure security certifications (for example ISO 27001 or SOC 2) and do not claim them.

Portuguese version: use the language selector in the footer of the home page, remove ?lang=en from this URL, or read the Portuguese text above on this page.