Política de privacidade

Sua conta: nome, e-mail e a senha — que guardamos só como um resumo irreversível (um hash scrypt). Nunca guardamos a senha em si, e nem nós conseguimos lê-la. Se você entrar por Google ou Microsoft, guardamos o identificador fixo que o provedor nos dá, o seu nome e o seu e-mail, e registramos como o provedor confirmou você (com ou sem segundo fator). Não recebemos a sua senha lá nem guardamos as chaves de acesso do provedor. No Google, também baixamos uma cópia da sua foto de perfil e a guardamos no nosso servidor, para os seus colegas verem em Membros & Acessos; ela é atualizada a cada entrada com o Google. Se não tivermos a foto da sua conta Google (porque você não entrou com o Google, ou porque a conta não tem foto), o servidor pergunta ao Gravatar se o seu e-mail tem foto, mandando só um resumo (hash) do e-mail, nunca o e-mail em si — uma vez a cada 7 dias.

Convites: o e-mail e o nome de quem você convida ficam guardados, mesmo que a pessoa nunca crie a conta — hoje sem prazo de apagamento automático; a trilha registra o convite por 400 dias.

Seu trabalho: os projetos que você cria, as conversas com o agente, os arquivos que você anexa, o código e os arquivos gerados, as versões publicadas (guardamos as 20 últimas entregas e os 3 últimos retoques de cada projeto), os painéis (boards) que você monta sobre os dados e os dados que os sistemas criados por você armazenam.

Imagens coladas no chat: as imagens que você cola ou anexa na conversa com o agente ficam no nosso servidor, como arquivos do projeto (as de um formato que não guardamos à parte, como BMP ou HEIC, ficam dentro do próprio projeto), e na conversa só quem constrói nele as abre. Ao excluir a conversa em que uma imagem estava, ela sai do projeto: o que dela estava dentro do projeto sai na gravação seguinte, e a cópia que estiver no servidor como arquivo fica separada por 7 dias, para o caso de voltar (de outra aba aberta, por exemplo), e depois é apagada. O botão que apaga as imagens do chat, que aparece quando o projeto fica grande demais, tira as que ainda estão dentro dele, também na gravação seguinte — e se uma delas já estava sendo levada para o servidor naquele instante, a cópia de lá segue o mesmo prazo de 7 dias. Se você pedir ao agente para usar uma imagem no aplicativo (um logo, uma foto), uma cópia dela entra no código do aplicativo: quem usa o aplicativo a vê, e ela fica no código, nas versões guardadas (as 20 últimas entregas e as que você fixar) e nas publicações que a usaram — mesmo depois de você trocá-la, até essas versões saírem do histórico ou você excluir o projeto.

O que a IA do projeto sabe: as diretrizes, o dicionário de dados (o que cada tabela e coluna significa) e os documentos da base que quem constrói o projeto envia em Configurações → IA. Dos documentos, guardamos só o texto extraído — o arquivo original não fica guardado. Quem usa a IA do projeto pode ver, pelas respostas, o que esses documentos dizem.

Registros de acesso: data, hora, endereço IP e navegador de cada entrada (inclusive as que falharam) e de cada mudança de acesso, permissão, segredo, banco, publicação e configuração de IA. Você vê os seus próprios registros; quem administra a pasta vê o que aconteceu nela e as entradas dos membros (sem o IP); quem administra o VoxCorp vê contas e entradas, mas não o que acontece dentro das pastas. Quando quem administra consulta ou exporta esses registros, isso também fica registrado. É a mesma trilha que responde a um incidente. Quem administra a pasta pode nomear um auditor, por até 90 dias: ele vê esses mesmos registros da pasta, sem o IP de ninguém e sem o consumo de IA de cada pessoa, e vê quem tem acesso a cada projeto e o que está configurado nele (os nomes, nunca os valores de segredos, os dados do banco, o código ou as conversas). Cada consulta do auditor também fica registrada, e quem administra a vê.

Num aplicativo publicado: registramos cada vez que alguém o abre e cada Ação que dispara — quem, quando, quanto demorou, se deu certo, os nomes dos campos enviados (não os valores) e as mensagens de registro que a Ação escreveu. Esse registro fica no banco do próprio projeto (as 5.000 execuções mais recentes, sem prazo em dias), onde as telas do aplicativo também podem lê-lo.

Uso: por pessoa e por dia, quantos minutos você usou o editor e cada aplicativo, por projeto; e, na IA, qual modelo foi usado, quanto custou e por qual conta o pedido saiu — é o que alimenta o painel de consumo da sua empresa.

Cookies: usamos cookies só para o produto funcionar. Um no editor, que vale 30 dias e se renova com o uso; outro no endereço de cada aplicativo publicado, que vale 12 horas, fixas, só naquele endereço; quando a empresa conecta um endereço de entrada próprio para os aplicativos dela, um nesse endereço, que vale 30 dias, se renova com o uso e só serve para abrir os aplicativos daquele projeto; cookies curtos, de minutos, durante a entrada com segundo fator, a entrada com Google ou Microsoft e a conexão de uma conta; e, quando você sai, um na tela de entrada que lembra por 14 dias qual empresa usou aquele navegador — e, se você saiu de dentro de um projeto, qual projeto —, para a tela mostrar a marca dela e o nome dele. Ele guarda só essas referências, assinadas pelo servidor, e nada sobre você. Não usamos cookies de anúncio nem de rastreamento.

No nosso servidor: as contas que você conecta com “Entrar com…” (Google Sheets, Gmail, Google Agenda, Microsoft OneDrive, Outlook, GitHub, Figma, Salesforce); as assinaturas Claude e ChatGPT que você conecta; a chave de IA da sua empresa, cadastrada por quem administra a pasta e guardada cifrada no banco de contas (a chave da cifra fica no mesmo disco: ela protege uma cópia isolada do banco, não o disco inteiro); as conexões de IA de um projeto (Configurações → IA) — uma chave de API, guardada num arquivo do projeto, ou uma assinatura Claude que alguém do projeto conectar — a que estiver marcada como padrão responde aos pedidos de IA de todos que trabalham naquele projeto, na construção, no plano, no Design, no Converse com seus dados e nas perguntas que as Ações dos sistemas do projeto fazem à IA, no lugar da assinatura ou chave de cada pessoa (numa pasta em que a empresa cadastrou a chave de IA, é essa chave que responde a tudo, no lugar da conexão do projeto e da assinatura de cada pessoa), mostra o e-mail dela a quem constrói nele e só sai quando alguém a desconecta ali ou exclui o projeto; a IA do sistema de um projeto (o cartão do chat da construção, ou Configurações → IA), que responde só às Ações e ao Converse do app publicado — nunca à construção: o vínculo com a assinatura Claude de quem a ligou, que só a própria pessoa liga e que guarda apenas a referência (a credencial continua onde já estava), ou uma chave de API guardada cifrada no banco de contas; ela sai quando alguém a tira, quando o projeto é excluído ou quando a pessoa sai, e tirá-la não desconecta a assinatura de ninguém; os valores que você preenche em Integrações (inclusive o service token de um sistema interno via túnel) e as chaves que o agente pede pela caixinha da conversa — que são os segredos que as Ações usam (as da caixinha não voltam ao navegador); as credenciais dos bancos de dados externos que a sua empresa cadastrar em Fonte de dados (usuário e senha do banco) e, numa Ponte VoxCorp, o token de acesso ao túnel (não a senha do banco); e a chave do Sistema de IA que você colar ao importar um sistema de lá. Ficam em arquivos do projeto, na sua pasta de credenciais ou no banco de contas, no disco do servidor, e entram na cópia de segurança diária. Os valores de Integrações, as chaves da caixinha, os tokens das contas conectadas por “Entrar com…”, as credenciais da Fonte de dados e a chave de uma conexão de IA do projeto ficam cifrados nesses arquivos, com a mesma chave que cifra a chave de IA da empresa, e com o mesmo limite: a cifra protege o arquivo copiado sozinho, não o disco inteiro. As assinaturas Claude e ChatGPT ficam como o programa de cada provedor as lê, sem essa cifra. As Ações rodam no servidor, e é lá que essas chaves são usadas; nenhuma vai para o aplicativo que você publica.

Chaves públicas do app: há serviço que só funciona com uma chave no navegador de quem usa o sistema — o token público de um mapa (Mapbox), a chave do Google Maps restrita ao endereço do app. Essas, quem constrói o projeto cadastra em Integrações → Chaves públicas (ou na caixinha da conversa marcada como pública), e elas ficam no banco de contas sem cifra, porque o sistema publicado as entrega ao navegador de cada pessoa que o abre. Recusamos o que tem cara de chave secreta e o que for igual a um segredo do projeto; tirar a chave em Integrações a apaga do servidor na hora, e ela sai junto quando o projeto é excluído. O serviço de fora (o mapa, por exemplo) recebe o endereço de quem usa o sistema quando o navegador busca o que ele mostra — é uma escolha de quem constrói.

O que passa pelo seu navegador: a chave de IA pessoal que você digita nos Ajustes fica só no seu navegador — não a gravamos no servidor — e é enviada a cada pedido, para repassarmos ao provedor de IA. Os valores de Integrações fazem parte do documento do projeto, então ficam também no navegador de cada pessoa que constrói nele; quem só usa o aplicativo não os recebe. E, quando você escolhe planilhas do Google, um token de acesso temporário da conexão vai ao seu navegador naquele momento, para a janela do Google abrir; ele não fica guardado.

Também no seu navegador: para a tela abrir na hora, o navegador guarda uma cópia dos projetos em que você constrói — as conversas com o agente (e as imagens delas que a tela já mostrou), o código, o plano, a lista de membros (com e-mail) e as últimas respostas do Converse (até 60 linhas de dados reais por resposta, inclusive de um banco da sua empresa). Sair da conta não apaga essa cópia: num computador compartilhado, limpe os dados do site no navegador.

No aplicativo publicado: nenhuma senha, chave ou token. Quem o abre passa pela conta do VoxCorp — ou, quando a empresa conecta um endereço de entrada próprio, pela tela de entrada dela, nesse endereço, com a mesma conta — e recebe um cookie próprio daquele aplicativo, conferido a cada pedido — a sua conta precisa continuar ativa e com acesso. Dentro do aplicativo, a lista de pessoas mostra só o nome, nunca o e-mail. No preview dentro do editor vai um crachá temporário, de 2 horas, que só dá acesso aos dados daquele projeto.

Perguntar aos dados, dentro do aplicativo: só existe quando quem administra o projeto liga e escolhe quem pode usar — e é o mesmo que quem só usa o aplicativo encontra dentro do projeto, com as mesmas regras. A pergunta e as consultas de leitura vão à IA do próprio projeto (a chave da empresa ou a conexão de IA dele), com o esquema e linhas reais do banco. Cada pessoa vê só as próprias conversas, e elas ficam no servidor: as 30 mais recentes de cada pessoa, com até 60 linhas do resultado por resposta. Apagar uma conversa a tira na hora; elas saem com o projeto e quando a pessoa é desligada.

Quando você conecta o Google Sheets, o VoxCorp pede três permissões: drive.file — o acesso mais estreito que existe para esse fim — e openid e email, para sabermos de qual conta é a conexão. O drive.file dá acesso apenas às planilhas que você escolher, uma a uma, mais as que o próprio sistema criar. Não pedimos, e não temos, acesso ao resto do seu Drive nem às suas outras planilhas. O e-mail da conta aparece no card da conexão e é informado ao agente de IA enquanto ele constrói.

Guardamos a credencial de acesso no nosso servidor, num arquivo que é só do seu projeto: duplicar o projeto não a copia, e quem não tem acesso ao projeto não a vê nem a usa. Ela entra na cópia de segurança diária, cifrada, descrita abaixo.

A credencial não é enviada para o aplicativo que você publica nem para o navegador de quem o usa. Mas o aplicativo usa a sua planilha: quando alguém o usa, uma Ação roda no nosso servidor com a credencial e lê ou grava na planilha. O mesmo acontece com Ações agendadas e com Ações públicas que outro sistema seu chama.

Lemos e gravamos nas planilhas escolhidas quando um sistema seu roda — pelo aplicativo, por agendamento ou por chamada de outro sistema seu — e quando o agente de IA testa uma Ação enquanto constrói o que você pediu. Nunca por conta própria.

Não guardamos uma cópia das suas planilhas e não vendemos nem compartilhamos o conteúdo delas. O que o seu sistema lê pode ficar no banco do seu projeto, se ele for feito para isso. Enquanto o agente constrói ou testa, trechos do que a planilha devolve, o nome das planilhas e o e-mail da conta Google vão para o provedor de IA que você conectou — só para atender ao seu pedido. Nós não treinamos modelo com nada disso. O que o provedor faz com o que recebe segue os termos e a configuração da conta que você ou a sua empresa usa nele: numa assinatura pessoal (Claude ou ChatGPT), vale a configuração de treinamento da sua própria conta — confira-a antes de conectar planilhas.

O uso e a transferência de informações recebidas das APIs do Google seguem a Política de Dados do Usuário dos Serviços de API do Google, inclusive os requisitos de Uso Limitado.

Quando você conecta o Outlook (Integrações → Outlook, “Continuar com Microsoft”), o VoxCorp pede à Microsoft quatro permissões: Mail.Send, para mandar e-mail pela sua conta; Calendars.ReadWrite, para ver, criar e mudar eventos da sua agenda; User.Read, para sabermos de qual conta é a conexão; e offline_access, para o acesso continuar sem você entrar de novo. Não pedimos, e não temos, permissão para ler os seus e-mails. O aplicativo na Microsoft é só do Outlook, separado do “Entrar com Microsoft” e do OneDrive.

Mandamos e-mail e criamos evento só quando um sistema seu pede — uma Ação dele, pelo aplicativo, por agendamento ou por chamada de outro sistema seu. O e-mail sai do seu endereço e fica nos seus Itens Enviados; o evento nasce na sua agenda, e cada participante recebe o convite. Enquanto o agente de IA constrói e testa, nenhum e-mail é enviado e nenhum evento é criado; mas a sua agenda é lida quando uma Ação que lista eventos é testada, e o que ela devolve — títulos, horários, locais e participantes — vai para o provedor de IA que você conectou, como qualquer trecho da construção.

A credencial fica só no nosso servidor, cifrada, num arquivo do projeto, e entra na cópia de segurança diária. Ela não vai às Ações nem ao agente: a Ação pede ao servidor, e é o servidor que fala com a Microsoft. O aplicativo é separado do OneDrive de propósito: a Microsoft dá ao token tudo o que você autorizou ao aplicativo, e o token do OneDrive vai às Ações. Num aplicativo só, o OneDrive de quem conectasse os dois passaria a poder mandar e-mail; com dois, o que você autoriza ao Outlook nunca chega ao token do OneDrive. Mesmo assim, se o token do OneDrive chegar com permissão de e-mail ou de agenda — dada ao “Entrar com Microsoft” por você ou pela sua empresa —, o servidor não o entrega às Ações, e a tela de Integrações diz isso.

Guardamos, sem conteúdo nenhum — sem destinatário, assunto nem título —, um registro de cada pedido à conta: a operação, quantos destinatários, de onde veio, quem disparou (quando foi uma pessoa, no app ou testando a Ação) e como terminou, por 30 dias. Cada conta manda no máximo 200 e-mails e cria no máximo 100 eventos a cada 24 horas, para um sistema com defeito não fazer a Microsoft bloquear a sua caixa. Quem administra a pasta pode bloquear ou desligar o Outlook em Configurações → Integrações.

Para cortar: “Desconectar”, em Integrações, apaga a credencial do nosso servidor. A Microsoft não oferece um jeito de cancelarmos por aplicativo; você tira o acesso em myapps.microsoft.com (conta de trabalho ou escola) ou em account.microsoft.com → Privacidade (conta pessoal). Lá o Outlook aparece como um aplicativo à parte: cortá-lo não corta o OneDrive nem o “Entrar com Microsoft”.

Quando você conecta o Gmail (Integrações → Gmail, “Continuar com Google”), o VoxCorp pede ao Google gmail.send, para mandar e-mail pela sua conta, e openid e email, para sabermos de qual conta é a conexão. Não pedimos, e não temos, permissão para ler, apagar ou organizar os seus e-mails — com o gmail.send, nem a sua caixa de entrada é alcançável. Quando você conecta o Google Agenda (Integrações → Google Agenda), pedimos calendar.events, para ver os eventos das suas agendas e criar eventos nelas, e os mesmos openid e email. São dois cartões, cada um com a sua permissão: conectar a agenda não dá permissão de e-mail, e o contrário também. O aplicativo no Google é o mesmo do “Entrar com Google” e do Google Sheets.

Mandamos e-mail e criamos evento só quando um sistema seu pede — uma Ação dele, pelo aplicativo, por agendamento ou por chamada de outro sistema seu. O e-mail sai do seu endereço e fica nos seus Enviados; o evento nasce na sua agenda principal, e cada participante recebe o convite do Google, em seu nome; a reunião do Google Meet só é criada quando o sistema pede. Lemos a sua agenda só quando uma Ação lista os eventos de um período, e o que ela recebe são título, horários, local, organizador, participantes com a resposta de cada um e os links do evento — a descrição dos eventos não é entregue à Ação. Enquanto o agente de IA constrói e testa, nenhum e-mail é enviado e nenhum evento é criado; mas a sua agenda é lida quando uma Ação que lista eventos é testada, e o que ela devolve vai para o provedor de IA que você conectou, como qualquer trecho da construção — só para atender ao seu pedido.

A credencial fica só no nosso servidor, cifrada, num arquivo do projeto, e entra na cópia de segurança diária. Ela não vai às Ações nem ao agente: a Ação pede ao servidor, e é o servidor que fala com o Google. Não guardamos o conteúdo dos e-mails que saem nem dos eventos que lemos; o que o seu sistema fizer com o que leu pode ficar no banco do seu projeto, se ele for feito para isso. A mesma conta conectada ao Google Sheets não ganha, no Sheets, a permissão de e-mail ou de agenda: cada conexão pede ao Google só a permissão dela — e se o Google algum dia entregar ao token do Sheets uma permissão de e-mail ou de agenda, o servidor deixa de entregá-lo às Ações e o cartão dele diz isso.

Guardamos, sem conteúdo nenhum — sem destinatário, assunto nem título —, um registro de cada pedido à conta: a operação, quantos destinatários, de onde veio, quem disparou (quando foi uma pessoa, no app ou testando a Ação) e como terminou, por 30 dias. Cada conta manda no máximo 200 e-mails e cria no máximo 100 eventos a cada 24 horas, para um sistema com defeito não fazer o Google bloquear a sua conta. Quem administra a pasta pode bloquear ou desligar o Gmail e o Google Agenda, cada um por si, em Configurações → Integrações. Nós não treinamos modelo com nada disso, e não vendemos nem compartilhamos o que recebemos do Google.

Para cortar: “Desconectar”, em Integrações, apaga a credencial do nosso servidor e pede ao Google o cancelamento — mas, como no Google Sheets, só quando nenhuma outra conexão da mesma conta Google (o Sheets, o Gmail ou o Google Agenda, em qualquer projeto) depende dela: no Google, cancelar uma cancela todas. Quando outra depende, a permissão continua registrada na sua conta Google até você cancelar em myaccount.google.com/permissions — o que corta, de uma vez, o Sheets, o Gmail e o Google Agenda dessa conta no VoxCorp. Trocar a senha da conta Google também cancela o acesso ao Gmail, pela regra do próprio Google.

O uso e a transferência de informações recebidas das APIs do Google seguem a Política de Dados do Usuário dos Serviços de API do Google, inclusive os requisitos de Uso Limitado.

Dentro do VoxCorp, em Integrações: o × ao lado de uma planilha a tira da lista que o agente usa ao construir — Ações novas não a usam mais. Uma Ação já criada que aponte para essa planilha continua alcançando-a até você a apagar ou desconectar.

“Desconectar” apaga a credencial do nosso servidor (a cópia de segurança ainda a guarda por cerca de 70 dias) e, no Salesforce, pede na hora que a autorização seja cancelada lá. No Google, cancelar uma credencial cancela a autorização inteira da sua conta: todas as conexões dela no VoxCorp, em qualquer projeto, param juntas. Por isso pedimos o cancelamento ao Google só quando nenhuma outra conexão da mesma conta depende dele; quando outra depende (ou quando não dá para descartar que uma delas seja da mesma conta), a credencial sai só do nosso servidor, e quem quiser cortar a conta inteira cancela em myaccount.google.com/permissions. A exceção, rara, é a conexão de que não sabemos a conta (o Google nunca nos disse de quem ela é, ou o registro dela no servidor não abre): ela não segura o cancelamento das outras e, se for da mesma conta, para junto e pede para ser reconectada. Se um pedido de cancelamento falhar (o provedor fora do ar, por exemplo), a autorização pode continuar registrada na sua conta — a trilha de auditoria registra que o provedor não confirmou, e você cancela na sua conta, pelos endereços abaixo. Na Microsoft e no Figma não cancelamos lá: faça isso na sua conta deles. Se você reconectar ou excluir o projeto sem desconectar antes, valem as mesmas regras — e reconectar a mesma conta Google não cancela a credencial anterior, porque isso cancelaria a nova junto —, mas, nesses dois casos, uma falha do provedor não fica registrada na trilha: confira na sua conta.

Pelo Google, a qualquer momento e sem passar por nós: myaccount.google.com/permissions. Depois disso a conexão passa a falhar — o card em Integrações avisa na próxima vez que ela for usada ou testada; clique em Desconectar para apagar o registro daqui.

No Salesforce, a sua conta lista os aplicativos conectados em Configurações → Detalhes avançados do usuário → Aplicativos conectados OAuth (em inglês, Advanced User Details → OAuth Connected Apps), e quem administra a org também vê e revoga em Uso de OAuth de aplicativos conectados.

Com ninguém, para fins comerciais. Não vendemos nem cedemos seus dados. Para o produto funcionar, eles passam por:

• Fly.io — os servidores e o disco, em São Paulo. A Fly também guarda um instantâneo automático do disco por 30 dias.
• Amazon Web Services — todo dia fazemos uma cópia de segurança de todo o disco (bancos dos projetos, contas, segredos, anexos, imagens do chat, aplicativos publicados e as credenciais de IA de cada pessoa) e a guardamos, cifrada, num bucket em São Paulo, numa conta separada da hospedagem. A chave que abre a cópia não fica na máquina que a faz nem em nenhum servidor nosso: só a nossa equipe a tem, fora do produto. Cada cópia fica lá por cerca de 70 dias — 35 como versão atual e mais 35 como versão antiga, antes de a AWS a apagar de vez (ela arredonda cada prazo para o dia seguinte e apaga sem hora marcada).
• Resend — por onde saem os e-mails: convites, link para criar ou redefinir senha, aviso de vencimento da assinatura de IA, e os e-mails que os sistemas criados por você mandam, a quem eles mandarem. De cada e-mail mandado por um sistema seu, de cada convite para um projeto e de cada link de "esqueci a senha" pedido no endereço de entrada da empresa, guardamos destinatário, assunto, remetente e se saiu — não o conteúdo — sem prazo de apagamento automático; quem desenvolve o projeto vê essa lista em Configurações → E-mails, e o endereço de quem foi convidado ou pediu o link só quem administra o projeto vê. Quando o sistema manda e-mail por um serviço de e-mail próprio (a chave dele, não o nosso Resend), anotamos só qual serviço e se ele aceitou o pedido — sem destinatário nem assunto. Se você cadastrar um domínio próprio para esses envios, ele é registrado na nossa conta do Resend, e aqui anotamos de qual pasta o domínio é (ou de qual projeto, se ele não está numa pasta), sem nome nem e-mail de ninguém. Essa anotação não sai com o remetente nem com o projeto, de propósito: o domínio continua na conta do Resend, e soltá-lo junto deixaria outra pasta mandar e-mail em nome dele.
• Microsoft, nos avisos do Teams — desde 25 de outubro de 2026 não se cadastra canal novo do Teams, e o que segue vale para os canais cadastrados antes disso. Quando um projeto tem um deles, cada aviso que um sistema seu posta vai à Microsoft pelo fluxo que a própria empresa criou no Teams (o app Workflows), e é esse fluxo que o põe no canal. A URL do fluxo, que vale como a senha do canal, fica guardada cifrada no nosso servidor e entra na cópia de segurança diária; nenhum sistema seu a recebe. A tela onde se removia o canal saiu junto com o cadastro: para remover um, escreva para contato@voxcorp.io. Quem administra a pasta pode parar todos os avisos de uma vez, desligando o Teams em Configurações → Integrações. Remover o canal apaga a URL do nosso servidor na hora (a cópia de segurança ainda a guarda por cerca de 70 dias), e os avisos desse canal que ainda esperavam para sair são cancelados e perdem o conteúdo — como os escritos para o nome antigo, quando o canal é renomeado. O conteúdo de cada aviso — título, texto, campos e link — fica aqui só até sair, no máximo 24 horas: o que não sai nesse prazo vence e perde o conteúdo. Depois fica o registro — o canal, de onde o aviso partiu, os horários e o resultado, sem o conteúdo — por 120 dias. O registro, e o que ainda esperava para sair, saem na hora em que o projeto é excluído, e não vão para a lixeira. A cópia de segurança diária pode guardar o conteúdo de um aviso que ainda esperava, e o registro, por cerca de 70 dias, e o instantâneo do disco, por 30 dias.
• O provedor de IA em uso no seu projeto — Anthropic (Claude), OpenAI (ChatGPT e Codex), GitHub (o GitHub Copilot, que leva o pedido ao modelo que a sua licença dele libera), Google (Gemini) ou OpenRouter (que repassa o pedido a uma empresa que ele escolhe, a cada chamada, entre as que hospedam o modelo — não necessariamente quem o criou: a lista de cada modelo está em openrouter.ai), pela assinatura ou chave que você conectou, pela chave da sua empresa ou por uma conexão do projeto. Para ele vai o que ele precisa para trabalhar: o seu pedido e a conversa, o plano, o código do aplicativo, a estrutura das tabelas do projeto e dos bancos da sua empresa que você conectar como fonte de dados (nomes das tabelas e colunas, tipos e quantidade aproximada de linhas), os anexos que você enviou (de planilhas, as colunas com alguns valores de exemplo), o texto de sites que você indicar e, no Converse com os seus dados, as diretrizes e o dicionário de dados do projeto, com trechos dos documentos da base que tocam na pergunta. Enquanto constrói, o agente também pesquisa na web e lê páginas que ele mesmo escolhe (a documentação de uma API, por exemplo): a pesquisa é feita pelo provedor de IA com um texto que o modelo escreve a partir do seu pedido; com o Claude, as páginas que ele escolhe são lidas a partir do nosso servidor e enviadas ao provedor como qualquer outro trecho da construção; com o ChatGPT (Codex), a busca usa um índice da própria OpenAI. Quando o agente consulta o banco, roda ou testa uma Ação, ou você usa o Converse com os seus dados, vão também linhas reais — do banco do projeto ou do banco da sua empresa. E quando uma Ação de um sistema pergunta à IA do projeto (para resumir, classificar ou sugerir), vai o texto que essa Ação montar a partir dos dados do sistema: o agente é orientado a mandar números agregados, nunca linhas com dado pessoal, mas quem decide é o código da Ação, que fica à vista em Server Functions. Os valores dos segredos não vão. Nós não treinamos modelo com nada disso; o que cada provedor faz com o que recebe está nos termos dele e na configuração da conta usada.
• Google e Microsoft — se você entrar com uma dessas contas, o provedor nos diz quem você é (identificador, e-mail, nome e, no Google, a foto).
• Gravatar (Automattic) — recebe um resumo (hash) do seu e-mail para dizermos se há uma foto para você; nunca o e-mail em si, e só quando não temos a foto da sua conta Google.
• GitHub — quando você importa um sistema de um repositório. Recebe o pedido de autorização se você ligar a sua conta, e os pedidos de leitura e download do repositório que você escolher. Não é mais uma integração de projeto: desde 21/09/2026 o GitHub existe só na importação, e o agente de IA não o consulta enquanto constrói. Desconectar a sua conta do GitHub apaga o token aqui e pede ao GitHub que o cancele; se esse pedido falhar, não insistimos nem registramos — confira em github.com/settings/applications. No desligamento a conta do GitHub é desconectada do mesmo jeito, e ali a trilha de auditoria registra se o GitHub confirmou o cancelamento. Se você usa o GitHub Copilot como IA (Ajustes de IA), a conta que você liga lá é outra autorização: a de um aplicativo sem permissão nenhuma sobre os seus repositórios, que serve só para falar com o Copilot em seu nome. Desconectá-la apaga o token daqui na hora; no GitHub ele vale até vencer (8 horas) ou até você revogar o VoxCorp em github.com/settings/apps/authorizations. No desligamento ela sai junto com as outras credenciais de IA.
• As integrações que você conectar — Google Sheets, Gmail, Google Agenda, OneDrive, Outlook, Figma, Salesforce, Databricks, Jira, o Sistema de IA de onde você importar um sistema, os sistemas internos da sua empresa e bancos de dados externos recebem dados quando um sistema seu as usa e quando o agente de IA as consulta ou testa enquanto constrói o que você pediu (no Databricks, por ferramentas do próprio agente; nas demais, testando chamadas com a credencial do projeto). O que elas devolvem nessas consultas vai para o provedor de IA, como qualquer outro trecho da construção. Se a sua empresa ligar a Ponte VoxCorp a um banco interno, as consultas e os resultados passam por um túnel da Cloudflare na conta da sua empresa; a senha do banco fica na sua rede e o VoxCorp não a conhece. Um sistema interno ligado em Integrações → Sistema interno via túnel faz o mesmo caminho: cada pedido, com o service token que a sua empresa emitiu, e cada resposta passam pelo túnel da Cloudflare na conta dela.
• Qualquer outro serviço que um sistema seu chame — inclusive as fontes públicas do catálogo (PNCP, BrasilAPI, ViaCEP, IBGE) e serviços que o agente escolher para atender ao seu pedido. Um sistema criado por você envia a esses serviços o que o código dele mandar, como o CEP ou o CNPJ que alguém digitou; a lista de quem ele chama está no código do próprio sistema, em Ações.

Podemos divulgar dados se a lei exigir, e nesse caso avisamos você salvo quando a própria ordem proibir.

O código pode ir para um repositório seu no GitHub. Em Configurações → Geral, quem criou o projeto ou administra a pasta liga o “Espelho no GitHub”, escolhe o repositório e o ramo, e cada clique manda o código de hoje — os arquivos do aplicativo e as Ações — num commit novo, tendo o commit atual do ramo como pai. O envio é manual e usa a conta do GitHub de quem clica (o token fica na conta dessa pessoa, cifrado; nós não guardamos segredo nenhum do seu repositório). Por ali vai somente código: nenhum dado das tabelas, nenhum anexo e nenhum valor de credencial. A partir do momento em que o código está no seu GitHub, quem responde por ele é você — inclusive se o repositório for público. Ligar, desligar e cada envio ficam registrados na trilha de auditoria, com o repositório e o commit. Excluir o projeto apaga aqui o destino do espelho; o que já foi enviado continua no seu repositório, porque é seu.

O código também pode ficar sincronizado com um repositório seu, nas duas vias. Em Integrações → Código no GitHub, quem criou o projeto ou administra a pasta liga o projeto a um repositório e a um ramo. A partir daí, cada versão nova do projeto — uma construção, uma restauração, um tema, uma edição, uma Ação gravada — manda para lá, sozinha, o que mudou aqui (os arquivos do aplicativo e as Ações) num commit em nome da conta do GitHub de quem ligou, inclusive quando quem pede é outra pessoa do projeto — menos quem tem o acesso Desenvolvedor Lite: o que ele muda não vai sozinho, e segue no próximo envio de quem tem o acesso Desenvolvedor Full. A mensagem do commit diz só o número e o tipo da versão (uma construção, um tema, uma restauração) e o nome de quem pediu, nunca o e-mail — o que se escreve no chat não vai para lá; ela fica no histórico do repositório. E o que outra pessoa ou outra IA commitou lá vem para cá ao abrir o projeto e antes de cada construção. O que vem do GitHub entra como uma edição do projeto, numa versão nova do histórico; o aplicativo publicado só muda quando alguém publica — as telas e também as Ações. Na ida vale a regra do espelho: somente código, e nenhum valor de credencial (um valor escrito no código vai como ***). Junto do código, para outra pessoa ou outra IA entender o projeto, vão um guia (VOXCORP.md) e o esquema do banco — os nomes e os tipos das tabelas e das colunas, sem nenhuma linha — em .voxcorp/esquema.json; os dados do banco não vão. Na volta nunca entram o banco, arquivos de credencial (como .env), binários nem imagens: eles ficam só no seu GitHub. O token continua só na conta de quem ligou, cifrado; da ligação guardamos o repositório, o ramo, quem ligou e, de cada arquivo, o caminho e um resumo (hash) do conteúdo — nunca o conteúdo. Ligar, desligar, cada envio, cada leva trazida e cada parada ficam na trilha de auditoria, com o repositório e o commit. Desligar, ou excluir o projeto, apaga aqui a ligação; o que já foi para o seu repositório continua lá.

Seus projetos e dados ficam guardados até você apagá-los. O botão “Excluir projeto” (em Configurações, para quem criou o projeto ou administra a pasta dele, com a confirmação pelo nome) tira o projeto de circulação na mesma hora: o identificador fica marcado como excluído para que nenhuma cópia num navegador o traga de volta, o aplicativo publicado deixa de abrir no endereço dele, as chaves de API e os agendamentos param, as sessões de quem estava usando o aplicativo são encerradas, e nós pedimos o cancelamento das conexões com o Salesforce e com o Google (Sheets, Gmail e Google Agenda) — no Google, pela mesma regra do “Desconectar”: só quando nenhuma conexão da mesma conta, em outro projeto, depende dele — e desconectamos as conexões de IA; esses cancelamentos são feitos no provedor e não têm volta. Uma construção em andamento precisa ser parada antes.

O banco, os arquivos, as versões, os segredos, os anexos, as imagens coladas no chat, as Ações, os painéis, o que a IA do projeto sabe (diretrizes, dicionário e documentos), o ícone enviado para o aplicativo publicado (com a cópia que cada publicação guarda dele, para “Voltar para a publicação” trazê-lo de novo — “Usar o padrão”, em Publicar, tira só o da próxima publicação) e o aplicativo publicado vão para uma lixeira e ficam 7 dias. Nesse prazo, quem criou o projeto, quem o excluiu ou quem administra a pasta pode trazê-lo de volta pela página do projeto — e o que volta é tudo isso, menos as conexões, que precisam ser refeitas. Passados os 7 dias, o servidor apaga de vez, sem aviso e sem botão: aí o projeto só existe nas cópias de segurança, pelos prazos delas. O pacote de origem de uma importação (GitHub, .zip ou Sistema de IA) segue o projeto quando é seu e nenhum outro projeto o usa. Se alguma parte não puder ser apagada na hora, o servidor volta para apagá-la sozinho, de hora em hora, até terminar. A exclusão e a restauração ficam na trilha de auditoria (quem, quando, qual projeto, e o que ficou pendente).

A trilha de auditoria — quem fez o quê, com data, hora, IP e navegador — e os registros de uso são mantidos por 400 dias e depois apagados automaticamente.

Se a instalação ligar o rastro da IA (vem desligado), cada construção, edição pelo Design e plano feitos pela IA guardam também um registro assinado pelo servidor: o texto do pedido (sem valor de credencial), o modelo, de onde veio a credencial e os passos da IA. Ele fica cifrado no servidor pelos mesmos 400 dias, só quem administra a pasta o abre, e a exclusão definitiva do projeto apaga o conteúdo dele (fica só o hash na trilha).

Um dado apagado ainda existe nas cópias de segurança por cerca de 70 dias (AWS) e nos instantâneos do disco por até 30 dias (Fly). Depois disso, some de lá também.

Para encerrar a sua conta, escreva para contato@voxcorp.io. O que o produto faz é o desligamento: a conta é desativada, as sessões são encerradas, os acessos são retirados, os projetos passam a outra pessoa da empresa, as suas credenciais de IA pessoais saem do servidor (uma assinatura que você conectou a um projeto fica até alguém a desconectar lá ou excluir o projeto) e a sua conta do GitHub é desconectada — o token sai daqui e pedimos ao GitHub que o cancele. Nome, e-mail e foto continuam no registro desativado, porque a trilha de auditoria — que guarda o seu e-mail por 400 dias — aponta para ele. Os projetos você apaga pelo botão, antes; a foto e o que mais estiver no registro da conta podem ser apagados a seu pedido: hoje isso é feito à mão por uma pessoa da nossa equipe, não por um botão, e respondemos quando estiver feito.

O acesso a cada projeto é decidido no servidor. A verificação em duas etapas (código num aplicativo autenticador) está disponível para todos, é obrigatória para quem administra o VoxCorp, e quem administra uma pasta pode exigi-la de todos que trabalham nela — inclusive para abrir os aplicativos publicados daquela pasta.

Nenhum sistema é perfeito. Se você encontrar uma falha, escreva para contato@voxcorp.io — respondemos e corrigimos.

A data no topo diz qual é a versão vigente. Se esta política mudar no que guardamos ou com quem compartilhamos, avisamos por e-mail as contas ativas antes de a mudança valer.

A versão de 20 de setembro de 2026 passou a descrever o que entrou no produto desde então — a cópia de segurança diária na AWS, os bancos da sua empresa como fonte de dados e a Ponte pela Cloudflare, os e-mails que os sistemas mandam pelo Resend e o registro deles, o registro de cada Ação disparada num aplicativo publicado, a chave do Sistema de IA de uma importação e a chave de IA da empresa, a foto da conta Google e a consulta ao Gravatar, o cookie próprio do aplicativo publicado e o aviso de vencimento por e-mail — e corrigiu quatro descrições: a senha é guardada como hash, não cifrada; “Desconectar” pede o cancelamento da autorização no provedor só no Google e no Salesforce; a chave de IA pessoal e os valores de Integrações ficam também no navegador; e “Excluir projeto”, que até então só tirava o projeto da lista, passou a apagar o que o projeto tinha no servidor.

A versão de 21 de setembro de 2026 mudou o quando desse apagar, e só isso: “Excluir projeto” continua tirando o projeto de circulação na mesma hora — o identificador morre, o aplicativo publicado sai do ar, as chaves param e as conexões são canceladas no provedor —, mas o banco, os arquivos, as versões e os segredos passaram a esperar 7 dias numa lixeira, com um botão para trazer o projeto de volta, antes de serem apagados. Nada passou a ser guardado por mais tempo depois desse prazo, e nada novo passou a ser coletado.

A versão de 22 de setembro de 2026 acrescentou duas coisas. A primeira foi a exportação: um botão que baixava o projeto inteiro num arquivo, sem nenhum valor de credencial dentro. Ela não mudava o que guardamos nem com quem compartilhamos — dava a você uma cópia do que já era seu. A segunda muda um prazo, e para mais: o histórico de versões do aplicativo, que guardava as 5 últimas entregas, passou a guardar as 20 últimas. É mais do seu trabalho guardado por mais tempo, no mesmo lugar, com as mesmas regras de acesso e apagado junto com o projeto como sempre foi.

A versão de 4 de outubro de 2026 tirou a exportação: o botão que baixava o projeto inteiro num arquivo .zip saiu do produto. Isso não muda o que guardamos nem com quem compartilhamos. O código continua podendo ir para um repositório seu pelo Espelho no GitHub, descrito acima.

A versão de 5 de outubro de 2026 traz duas mudanças. A conexão de IA do projeto marcada como padrão, que respondia só no Converse com seus dados, passou a responder também na construção, no plano e no Design: os pedidos de quem trabalha no projeto vão ao provedor pela conta que quem administra o projeto escolheu, e não pela de cada pessoa. E o Ollama saiu da lista de provedores — com ele, o único destino de IA cujo endereço vinha da tela. Os provedores continuam sendo os mesmos da lista acima, então isso não muda o que guardamos nem com quem compartilhamos.

A versão de 6 de outubro de 2026 descreveu uma proteção a mais: os valores de Integrações, as credenciais da Fonte de dados e as outras credenciais dos projetos passaram a ficar cifrados no disco. Guardamos as mesmas coisas, no mesmo lugar, pelo mesmo tempo, então isso não muda o que guardamos nem com quem compartilhamos.

A versão de 11 de outubro de 2026 acrescentou um cookie: a tela de entrada passou a mostrar a marca da empresa — a logo, a cor e o nome da pasta —, e, quando você sai, um cookie lembra por 14 dias qual empresa usou aquele navegador e, se você saiu de dentro de um projeto, qual projeto. Ele guarda só essas referências, e nenhum dado seu.

A versão de 15 de outubro de 2026 diz que esta política vale também nos endereços dedicados a uma empresa cliente: são o mesmo serviço, nos mesmos servidores, então isso não muda o que guardamos nem com quem compartilhamos.

A versão de 16 de outubro de 2026 conta que as Ações dos sistemas passaram a poder perguntar à IA do projeto — a chave de IA da empresa, a assinatura Claude da pasta, a conexão de IA do projeto ou a IA do sistema (a assinatura de quem constrói, quando ela mesma a liga, ou uma chave de API), nunca a assinatura pessoal de quem usa o sistema. O pedido vai a um dos provedores da lista acima, então isso não muda com quem compartilhamos; muda o que pode ir para ele, e o parágrafo do provedor de IA diz o quê.

A versão de 19 de outubro de 2026 tira o Groq da lista de provedores de IA: ele deixou de ser oferecido para conectar, então nenhum pedido seu vai mais para ele. Isso só encurta a lista de com quem compartilhamos; não muda o que guardamos.

A versão de 24 de outubro de 2026 (a anterior era de 19 de outubro de 2026) conta onde ficam as imagens coladas no chat: elas iam dentro do próprio projeto e passaram a ficar no mesmo servidor como arquivos separados — as que já estavam dentro de um projeto são levadas aos poucos, pelo editor —, com as mesmas regras de acesso, indo para a lixeira e voltando com o projeto. Isso não muda com quem compartilhamos, e muda um prazo: antes, as imagens de uma conversa excluída continuavam guardadas até o projeto ser excluído; agora saem do projeto junto com a conversa — a que é arquivo fica separada por 7 dias e depois é apagada.

A mesma versão corrige o que dizemos sobre desconectar uma planilha do Google: a anterior prometia pedir o cancelamento ao Google sempre, e fazer isso derrubava as outras conexões da mesma conta, porque o Google cancela a autorização da conta inteira. Agora o pedido só vai quando nenhuma outra conexão da mesma conta depende dele, e a página diz onde cancelar o resto. Essa correção não muda o que guardamos nem com quem compartilhamos. A mesma versão passa a contar uma coisa que guardamos: quando você cadastra um domínio próprio para os e-mails dos sistemas, anotamos de qual pasta ele é, e a anotação não sai com o projeto — ela nasceu agora, para uma pasta não mandar e-mail pelo domínio que outra verificou.

A versão de 25 de outubro de 2026 (a anterior era de 24 de outubro de 2026) acrescenta o Outlook, o Gmail e o Google Agenda: com eles, um sistema seu manda e-mail e usa a agenda pela sua conta Microsoft ou Google. Ela diz o que pedimos a cada um (mandar e-mail e a agenda, nunca ler e-mail), o que vai à Microsoft, ao Google e ao provedor de IA, o registro sem conteúdo de cada pedido e quanto ele fica, por que o Outlook tem um aplicativo separado do OneDrive (e o que acontece quando o token do OneDrive traz e-mail mesmo assim), e como o cancelamento no Google trata o Sheets, o Gmail e o Google Agenda da mesma conta. Ela passa a contar uma coisa que guardamos e que nasceu com eles — o registro, sem conteúdo, de cada pedido à conta — e não muda o resto do que já guardávamos.

A mesma versão conta que o cadastro de canais do Teams saiu: não se cadastra canal novo, e a tela onde se removia um canal saiu junto — a remoção passa a ser pedida pelo contato, e quem administra a pasta pode parar todos os avisos. Os canais cadastrados antes continuam guardados e recebendo os avisos dos sistemas que já os usam, então isso não muda o que guardamos nem com quem compartilhamos.

A versão de 26 de outubro de 2026 (a anterior era de 25 de outubro de 2026) conta a sincronização do código com o GitHub nas duas vias, descrita acima. Ela abre um caminho por onde o código entra no projeto, e não muda com quem compartilhamos: o GitHub já recebia o código pelo espelho, e passa a receber também o guia do projeto e o esquema do banco (nomes e tipos de tabelas e colunas, nenhuma linha). Ela passa a guardar, enquanto estiver ligada, o repositório, o ramo, quem ligou e o caminho e o resumo de cada arquivo que os dois lados conhecem.

A mesma versão conta quem é o auditor da pasta: alguém que quem administra a pasta nomeia por até 90 dias para ver a trilha dela (sem IP e sem o consumo de IA de cada pessoa), quem tem acesso a cada projeto e o que está configurado nele, sem os dados do banco, o código, as conversas nem o valor de um segredo. Isso não muda com quem compartilhamos: o auditor é alguém que quem administra a pasta escolhe e convida — quem decide dar esse acesso é o cliente, não nós —, com conta e verificação em duas etapas obrigatória, e cada consulta dele fica na trilha. E conta que o que muda quem tem o acesso Desenvolvedor Lite não vai sozinho para o repositório ligado no GitHub: segue no próximo envio de quem tem o acesso Desenvolvedor Full — vai menos coisa, e mais tarde, para o GitHub, e mais nada muda.

A versão de 29 de outubro de 2026 (a anterior era de 26 de outubro de 2026) conta que a lista de e-mails de um projeto, em Configurações → E-mails, passou a mostrar tudo o que ele manda, e isso muda o que guardamos em dois pontos. De cada convite para um projeto passamos a guardar, nessa lista, o endereço de quem foi convidado, o assunto e se o e-mail saiu, sem prazo de apagamento automático, como os outros e-mails dos sistemas; o endereço, só quem administra o projeto vê, e o assunto fica sem o link do convite e sem o endereço, mesmo quando o modelo do convite os usa. E quando um sistema seu manda e-mail pela API de um serviço de e-mail próprio, anotamos qual serviço e se ele aceitou o pedido, sem destinatário nem assunto. Os e-mails e convites de reunião pelas contas Microsoft e Google conectadas aparecem na mesma lista com o que o registro delas já guardava — quantos destinatários, sem endereço nem assunto — e pelo mesmo prazo de 30 dias. Com quem compartilhamos não muda.

A mesma versão conta o endereço de entrada da empresa: um segundo nome do domínio dela onde as pessoas criam a senha do convite, entram e confirmam o segundo fator, com a marca dela, antes de abrir o aplicativo. Ele acrescenta o cookie da sessão daquele endereço, descrito acima, e um registro: o link de "esqueci a senha" pedido nele sai com o remetente do projeto e entra na lista de e-mails dele, como os convites — o endereço de quem pediu, que só quem administra o projeto vê, o assunto, sem o link, e se o e-mail saiu, sem prazo de apagamento automático. Com quem compartilhamos não muda: a conta, a senha e o segundo fator são os mesmos, guardados do mesmo jeito.