Residência de dados em IA para empresas: onde ficam seus dados

Residência de dados em IA para empresas significa saber, para cada parte da sua operação de IA, onde os dados da empresa são armazenados, onde são processados e quem consegue acessá-los, e de qual localização. O provedor do modelo é apenas um desses lugares. Prompts, memória, índices de busca, logs, caches, backups e o acesso do suporte do fornecedor têm, cada um, sua própria localização e seu próprio prazo de retenção, e cada um exige uma resposta específica.

Principais pontos

• A residência tem três partes: onde os dados são armazenados, onde são processados e quem acessa, de qual localização. Escolher uma região em um componente não responde às outras duas.
• A chamada ao modelo é só uma parada. Memória, índices de busca, logs, caches, backups e ferramentas de suporte muitas vezes guardam mais dados da empresa do que o provedor do modelo.
• Faça as mesmas quatro perguntas a cada componente: onde está, por quanto tempo fica, quem pode ler e como é apagado.
• Registre as respostas em um único mapa de dados, com responsável nomeado e calendário de revisão, porque fornecedores, regiões e subprocessadores mudam com o tempo.
• Decida por classe de dado, não por ferramenta. Alguns conteúdos podem circular livremente, outros precisam ficar em uma região, e outros nunca deveriam chegar ao agente.

O que significa residência de dados quando há IA envolvida?

Em um aplicativo tradicional, a residência costuma ser uma única pergunta: em qual região fica o banco de dados. Uma operação de IA divide essa pergunta em várias. Uma única solicitação pode passar por um aplicativo de mensagens, um ambiente de execução do agente, um provedor de modelo, um repositório de documentos e um serviço de logs, e cada um pode estar em um país diferente ou ser operado por outra empresa.

Vale separar três ideias que costumam ser misturadas.

• Armazenamento: onde os dados ficam guardados, incluindo cópias que ninguém planejou, como caches e backups.
• Processamento: onde os dados são lidos e computados, por exemplo o local em que o modelo roda quando um prompt é enviado.
• Acesso: quem pode ver os dados e de qual localização, incluindo a equipe de suporte do fornecedor e seus subprocessadores.

Um provedor pode armazenar dados em uma região e ainda permitir processamento ou acesso de suporte a partir de outra. Por isso, uma frase como "seus dados ficam na região" precisa de perguntas de acompanhamento antes de valer como resposta.

As regras importam aqui. Dependendo de onde estão a sua empresa e os seus clientes, leis como a LGPD (fiscalizada pela ANPD), o GDPR e o AI Act da União Europeia, além de normas setoriais e contratos com clientes, podem restringir transferências ou exigir salvaguardas específicas. Este artigo não é aconselhamento jurídico. O objetivo é entregar um mapa completo, para que, quando o jurídico ou um cliente perguntar para onde os dados vão, você responda com evidências e não com suposições.

Onde os dados da empresa podem ficar ou trafegar em uma operação de IA?

A lista abaixo acompanha uma solicitação desde a pessoa até o modelo e de volta. Cada lugar vem com a pergunta mais importante para ele. Em todos, as quatro perguntas básicas continuam valendo: onde, por quanto tempo, quem lê e como se apaga. Se quiser entender a arquitetura por trás desses componentes, as sete camadas da infraestrutura de IA empresarial trazem um passeio em linguagem simples.

• Canais e dispositivos: aplicativos de chat, e-mail, formulários web e celulares pelos quais as pessoas escrevem ao agente. Pergunte: o canal guarda uma cópia própria de cada mensagem, e em qual região essa cópia fica?
• O ambiente de execução do agente: o sistema que monta as instruções, executa etapas e chama ferramentas. Pergunte: em qual região de nuvem ele roda, e grava arquivos temporários ou filas em disco?
• A chamada ao modelo: o prompt e os documentos incluídos nele, enviados a um provedor para processamento. Pergunte: em qual região a solicitação é processada, essa região pode ser escolhida, e o conteúdo é usado para treinamento ou retido para monitoramento de abuso, e por quanto tempo?
• Cache do lado do provedor: alguns provedores guardam partes de um prompt por pouco tempo para acelerar solicitações repetidas (o cache de prompts é um exemplo documentado). Pergunte: o que fica em cache, por quanto tempo, e o cache segue as mesmas regras de região e retenção da chamada principal?
• O repositório de memória: fatos, preferências e decisões passadas que o agente mantém entre conversas. Pergunte: onde está hospedado, quem pode navegar por ele, e uma entrada pode ser corrigida ou removida sob solicitação?
• O índice de busca e os embeddings: a cópia pesquisável dos seus documentos. Pergunte: onde o índice fica, e a etapa de embeddings envia o texto bruto dos documentos a outro provedor em outra região?
• Ferramentas de negócio conectadas: CRM, agenda, sistema de chamados ou contabilidade que o agente lê e escreve. Pergunte: o agente puxa os dados para um armazenamento próprio ou lê sob demanda e descarta?
• Logs, rastros e análises: registros do que o agente viu e fez. Pergunte: eles contêm prompts e respostas completos ou só metadados, e onde o serviço de logs está hospedado?
• Backups e exportações: cópias agendadas, snapshots e transcrições baixadas. Pergunte: os backups ficam na mesma região do ambiente principal, e quanto tempo leva até um item apagado sumir deles?
• Conjuntos de avaliação e telas de revisão: exemplos salvos para testar o agente e telas em que pessoas revisam o trabalho dele. Pergunte: registros reais de clientes foram copiados para os conjuntos de teste, e quem tem acesso a eles?
• Acesso de fornecedores e subprocessadores: engenheiros de suporte, terceirizados e os fornecedores por trás dos seus fornecedores. Pergunte: quais pessoas podem ver dados de produção, de quais países, e com qual aprovação?

Quais lugares as equipes esquecem de verificar?

A maioria das equipes pergunta primeiro sobre a chamada ao modelo, o que é razoável, e para por aí. Os lugares menos visíveis costumam ser onde aparecem as surpresas.

Os logs são o caso mais comum. Ferramentas de observabilidade existem para registrar o que um sistema fez, e as convenções para telemetria de IA generativa (como o trabalho do OpenTelemetry sobre o tema) permitem capturar prompts e respostas como parte de um rastro. Isso é útil para depurar e arriscado para a residência. Decida de forma deliberada se os logs registram conteúdo ou apenas identificadores, tempos e resultados, e coloque o serviço de logs sob a mesma política de região de todo o resto.

Os dados derivados são o segundo caso. Um embedding não é uma frase legível, mas é calculado a partir do seu documento e pode ser associado a ele. Um resumo guardado na memória pode conter a linha mais sensível de um contrato. Trate dado derivado como da mesma classe da sua origem. Quando alguém pedir exclusão, a fonte, a entrada do índice, a entrada de memória e qualquer resumo em cache precisam sair, tema que aparece em memória de IA ou histórico de chat: o que guardar.

Backups e exportações são o terceiro. Um sistema pode atender a um pedido de exclusão no banco ativo enquanto um snapshot mantém o registro por mais um período. Peça por escrito o prazo de retenção dos backups, e não presuma que ele seja igual ao do ambiente ativo.

O quarto são as pessoas. Um banco travado em uma região não ajuda se a equipe de suporte em outro país consegue abri-lo com uma credencial compartilhada. Caminhos de acesso, aprovações e trilhas de auditoria entram na mesma conversa que o armazenamento. Uma avaliação de segurança do fornecedor de IA estruturada é um bom lugar para reunir essas respostas de forma consistente.

Como mapear a sua própria operação, passo a passo?

Comece por um exemplo. O que segue é um cenário ilustrativo, não uma empresa real.

Cenário ilustrativo: uma transportadora com escritórios em dois países dá a um agente a tarefa de redigir respostas a e-mails de clientes sobre entregas atrasadas. Um cliente escreve e anexa um comprovante de entrega. O e-mail fica na região do provedor de correio. O ambiente do agente o recebe e busca no índice de documentos o contrato de frete, que está em uma terceira região. O prompt, com o texto do e-mail e as cláusulas do contrato, vai a um provedor de modelo que o processa em uma região definida por configuração. O agente redige a resposta e guarda na memória uma nota de que esse cliente prefere ligações telefônicas. A troca completa é gravada em um log, e o log é copiado toda noite para um bucket de backup. Nessa única solicitação, os dados passaram por pelo menos seis sistemas. Só um deles era o modelo.

Para montar o mesmo retrato do seu agente, siga estes passos.

• Passo um: nomeie o papel do agente e liste as classes de dados que ele vai tocar, como texto público de marketing, dados de contato de clientes, contratos, registros de funcionários e dados financeiros.
• Passo dois: desenhe o caminho de uma solicitação real, da primeira mensagem ao último registro de log, e anote todos os sistemas no trajeto.
• Passo três: para cada sistema, registre região, retenção, quem pode ler e como funciona a exclusão, usando as quatro perguntas básicas.
• Passo quatro: marque cada ponto em que os dados cruzam uma fronteira, o limite de uma empresa ou um subprocessador.
• Passo cinco: compare o mapa com suas obrigações legais e contratuais e liste as lacunas.
• Passo seis: feche cada lacuna trocando a região, tirando o dado do caminho, anonimizando antes de sair ou aceitando o risco com um responsável nomeado.
• Passo sete: defina um responsável e uma data de revisão, e refaça o mapa sempre que um fornecedor, uma região ou uma integração mudar.

Depois que o mapa existir, use um guia simples de decisão por classe de dado.

• Dados que já são públicos: podem circular por qualquer componente em que você confie, sujeitos às verificações normais de qualidade.
• Dados internos de baixo risco: permitidos onde região, retenção e termos de treinamento do provedor estejam documentados e sejam aceitáveis.
• Dados pessoais ou regulados: permitidos apenas em componentes com região confirmada, retenção limitada, acesso restrito e caminho de exclusão.
• Dados que contratos ou normas proíbem de sair de uma região: processados somente por componentes que permaneçam nela, ou mantidos totalmente fora do alcance do agente.
• Segredos como senhas e chaves: nunca colocados em prompts, memória ou logs. Ficam em um cofre de segredos dedicado, que o agente usa sem ler.

O último item também é uma questão de permissões. Um agente que não consegue ler uma classe de dado não consegue vazá-la, e por isso o acesso com escopo definido, tratado em quando seu agente de IA deve parar e perguntar, faz parte da residência e não é um tema separado.

Como uma abordagem gerenciada trata a localização dos dados?

A Be Human trata a localização dos dados como parte do desenho do papel do agente, e não como uma cláusula acrescentada no fim. Em um primeiro projeto, as classes de dados que o papel vai tocar são listadas, os sistemas no caminho da solicitação são mapeados, e região, retenção e acesso são registrados para cada um, junto com os limites de aprovação sobre o que o agente pode ler ou alterar. Memória, ferramentas e canais são configurados sob o controle da empresa, e os logs são ajustados para capturar o necessário ao monitoramento sem guardar mais conteúdo do que o preciso. Na operação gerenciada, o mapa é revisado como parte do trabalho recorrente, como revisão de permissões, manutenção de integrações e mudanças controladas, de modo que uma nova região de fornecedor ou uma nova ferramenta conectada seja verificada antes de carregar dados da empresa. O que cada configuração consegue oferecer depende dos provedores de modelo e das ferramentas escolhidas, por isso as respostas são documentadas por componente e não presumidas. Para ver o trabalho recorrente em mais detalhe, leia serviços gerenciados de IA para empresas: o que está incluso.

Perguntas frequentes

Residência de dados é a mesma coisa que privacidade de dados? Não. A privacidade trata de como os dados pessoais são coletados, usados e protegidos, enquanto a residência trata do local em que os dados são armazenados, processados e acessados. As duas se sobrepõem, porque algumas regras de privacidade restringem transferências entre fronteiras, mas uma operação pode estar na região certa e ainda tratar mal os dados pessoais, ou o contrário.

Escolher um provedor de modelo com opção regional resolve o problema? Resolve uma parte. Um endpoint regional do modelo define onde o prompt é processado, mas memória, índices, logs, backups e acesso de suporte continuam precisando de respostas próprias. Confirme também o que a opção regional cobre, já que alguns recursos, como certos caches ou o monitoramento, podem ser tratados separadamente.

Devemos evitar enviar qualquer dado da empresa a um modelo de IA? Em geral isso não é necessário nem prático. Uma abordagem mais útil é classificar os dados, decidir quais classes podem chegar a quais componentes e remover ou anonimizar as classes que não devem circular. Conteúdo público e de baixo risco muitas vezes pode ser usado livremente, enquanto dados regulados ou restritos por contrato exigem regiões confirmadas, retenção limitada e acesso controlado.

Com que frequência devemos revisar o mapa de dados? Revise sempre que adicionar uma ferramenta, trocar de modelo ou provedor, abrir um novo canal ou souber de uma mudança de subprocessador, e também em intervalos regulares, mesmo que nada pareça ter mudado. Fornecedores ajustam regiões, retenção e subprocessadores ao longo do tempo, e um mapa que estava correto no lançamento pode ficar defasado sem que ninguém perceba.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.