É preciso separar dois momentos que a palavra «dados» acaba por confundir. Durante a geração, o que você ESCREVE, a sua descrição e o texto dos ficheiros que anexa, é transmitido a um fornecedor de modelos para produzir a especificação e o código; os fornecedores estão identificados na política de privacidade. Depois, quando a aplicação está em execução, nada mais é enviado: o código entregue não contém nenhum cliente de inteligência artificial nas suas dependências, e o ficheiro de configuração colocado no servidor não inclui nenhuma chave de API. Ou seja, os seus clientes, as suas intervenções, os seus associados, tudo o que introduzir posteriormente, não pode, por estrutura, alcançar qualquer modelo. A única informação que sai é aquela que redigiu para descrever a sua necessidade.
O que é enviado para um modelo, e quando
A geração precisa de compreender o seu negócio: é a sua descrição que lho explica, sendo por isso transmitida a um fornecedor de modelos, juntamente com o texto dos ficheiros que anexa. A política de privacidade nomeia-os, Anthropic, OpenAI, xAI e Google, e esclarece que estes tratamentos podem ocorrer fora da União Europeia, enquadrados pelas cláusulas contratuais-tipo da Comissão Europeia. Isto não é um pormenor a ler entre linhas: é a matéria-prima da geração, e não existe nenhuma versão do produto em que a sua descrição ficasse consigo *e*, simultaneamente, se produzisse uma aplicação que lhe corresponda.
Esse envio tem um fim definido. Ocorre exclusivamente durante a geração, para produzir a especificação e, depois, o código, e só se repete na próxima geração, quando reinicia o processo ou pede uma alteração. Entre duas gerações, não acontece nada. Não há sincronização contínua, nem envio de dados de utilização para um modelo, nem análise em segundo plano do conteúdo da sua aplicação.
O que nunca é enviado: os dados que introduzir depois
A aplicação implementada é um software comum, e isso pode ser verificado em três pontos do código entregue. A sua lista de dependências não inclui nenhum cliente de inteligência artificial, apenas Next.js, React, Prisma e bibliotecas de apresentação. O ficheiro de configuração escrito no servidor aquando da implementação ocupa apenas quatro linhas: o endereço da base de dados, dois segredos técnicos e um número de build; nenhuma chave de API nele figura. E os valores do seu painel de controlo são calculados por consultas determinísticas à sua base de dados, nunca por um modelo a quem se peça para ler as suas linhas.
A consequência é a que mais importa para a inquietação mais premente, a do treino dos modelos. Mesmo partindo da hipótese mais desfavorável, a única informação potencialmente envolvida seria a sua descrição inicial: a frase em que explica que gere um ateliê, intervenções e clientes. Nunca o conteúdo dos seus registos de clientes, o histórico das suas intervenções ou a lista dos seus associados, pois essas linhas não têm, em momento algum, qualquer caminho que as conduza a um modelo.
Ficheiros anexados: dois percursos, apenas um passa por um modelo
Um ficheiro anexado nem sempre segue o mesmo percurso, e essa distinção é clara no código. Uma folha de cálculo, um ficheiro CSV, um PDF ou um documento de texto são lidos NO SERVIDOR, por extratores convencionais: nenhum modelo analisa diretamente o ficheiro. Já uma fotografia ou uma captura de ecrã é, de facto, enviada a um modelo de visão, cuja função específica é descrevê-la, é a única forma de interpretar um formulário em papel ou uma tabela fotografada.
Há, contudo, um ponto que deve ser dito com clareza, porque afeta uma decisão prática: o texto extraído de um ficheiro junta-se ao contexto enviado ao modelo, até um máximo de doze mil caracteres por ficheiro. Assim, uma folha de cálculo anexada para ilustrar a estrutura dos seus dados é enviada, sob a forma de texto, juntamente com a sua descrição. Se esse ficheiro contiver dados pessoais que utiliza na sua atividade, a boa prática resume-se a uma frase: anexe apenas a linha de cabeçalhos e algumas linhas de exemplo anonimizadas. O gerador precisa da FORMA das suas colunas, não dos nomes dos seus clientes.
O que é garantido, e o que não é
Uma garantia concreta, em primeiro lugar, e está escrita no próprio código: quando anexa um ficheiro CSV para começar com as suas linhas reais, essas linhas são inseridas na sua base de dados através de um processo determinístico, deteção do separador, correspondência entre os seus cabeçalhos e os campos, conversão tipificada, e nenhum modelo intervém nesta etapa. A razão está expressa de forma inequívoca neste ponto do código: os dados do utilizador não são reimaginados. Um modelo que «completasse» uma tabela de associados produziria linhas plausíveis, mas falsas, o único resultado verdadeiramente inaceitável.
O que esta página não pretende garantir, em seguida: a política interna de cada fornecedor de modelos quanto à reutilização do que lhes é transmitido. Isso depende dos seus compromissos contratuais, não do comportamento deste produto; a política de privacidade nomeia-os e descreve o enquadramento dos envios, sendo esse o local onde deve procurar essa informação. O que o produto garante, efetivamente, é o PÉRIMETRO, o que sai, quando sai e, sobretudo, o que nunca sai. É precisamente porque esse perímetro é tão restrito que a questão do treino dos modelos não incide sobre o seu ficheiro de clientes.