Quem do fornecedor de IA acessa os dados da empresa? Regras de acesso

Em geral, alguns funcionários do fornecedor conseguem chegar a alguns dos seus dados. Por isso, a pergunta útil é quais pessoas, sob quais condições e com que registro. Um fornecedor de IA confiável limita o acesso da equipe a funções definidas, concede o acesso por um motivo declarado e por tempo limitado, registra cada uso e permite que você veja esse registro. As perguntas abaixo ajudam a descobrir se o fornecedor trabalha mesmo assim ou apenas diz isso em uma página de política.

Principais pontos

• O acesso da equipe do fornecedor não é um simples sim ou não. Ele muda entre prompts, memória, resultados de ferramentas, logs, backups e anexos de suporte, então pergunte sobre cada lugar separadamente.
• O melhor padrão é não haver acesso permanente ao seu conteúdo: o acesso é concedido por solicitação, com motivo e por tempo limitado.
• O registro de acesso só protege se informar quem, o quê, quando e por quê, não puder ser editado por quem ele registra e puder ser mostrado a você.
• As regras de aprovação importam tanto quanto os controles técnicos. Pergunte quem pode autorizar o acesso, se você precisa consentir antes e o que acontece em uma emergência.
• Obtenha as respostas por escrito e vincule-as ao contrato ou ao escopo de trabalho, não a uma conversa comercial.

O que significa o fornecedor ver os seus dados?

A maioria dos compradores imagina um banco de dados e uma pessoa olhando para dentro dele. Uma operação com agente de IA é mais ampla. Seus dados ficam em vários lugares, e cada um tem um grupo diferente de pessoas que podem tocar neles.

Comece listando os lugares em que o conteúdo da empresa pode aparecer:

• Prompts e respostas trocados com o agente, incluindo documentos colados e anexos.
• Memória que o agente constrói com o tempo, como anotações sobre clientes, preferências ou decisões passadas.
• Documentos que o agente busca nas suas fontes de conhecimento para responder a uma pergunta.
• Resultados de ferramentas conectadas, como e-mail, agenda, CRM ou registros contábeis que o agente lê.
• Logs e rastros que registram o que o agente fez e que muitas vezes contêm o próprio texto processado.
• Backups e exportações, que copiam tudo isso para outro local.
• Conjuntos de avaliação e casos de teste, frequentemente montados a partir de exemplos reais.
• Chamados de suporte, capturas de tela e arquivos que você envia ao fornecedor quando algo dá errado.

Depois, acrescente as partes que ficam por trás do fornecedor: o fabricante do modelo que processa seus prompts, o provedor de nuvem que armazena seus arquivos e qualquer subcontratado que ajude no suporte ou na operação. Os funcionários do próprio fornecedor são um grupo. A equipe dessas outras partes é outro, e você deve perguntar sobre os dois. O local geográfico dos dados também influencia quem consegue alcançá-los, o que vale verificar junto com o tema de residência de dados em IA.

O objetivo desse inventário é a precisão. Um fornecedor que responde "nossa equipe não vê os seus dados" não disse quase nada, porque não disse quais dados. Um fornecedor que responde "engenheiros não leem memória nem prompts por padrão, o suporte vê metadados mas não conteúdo, e qualquer acesso a conteúdo exige aprovação registrada" entregou algo que você pode conferir.

Quais perguntas revelam quem tem acesso e por quê?

Estas perguntas testam se o acesso foi desenhado ou aconteceu por acaso. Faça-as em uma reunião e depois peça as respostas por escrito.

• Quais funções podem ler o conteúdo dos clientes em produção, e aproximadamente quantas pessoas ocupam cada função?
• O padrão é não haver acesso, com concessão somente sob solicitação, ou essas funções têm acesso permanente?
• O direito de operar o sistema (reiniciar um serviço, publicar uma correção) é separado do direito de ler conteúdo? Em uma estrutura bem feita, um engenheiro mantém o agente funcionando sem conseguir ler o que ele está processando.
• Terceirizados, subprocessadores e o fabricante do modelo seguem as mesmas regras dos funcionários? Se não, quais são as regras deles?
• Como o acesso é removido quando alguém muda de equipe ou sai da empresa, e com que rapidez?
• Contas compartilhadas ou credenciais pessoais são usadas alguma vez para chegar aos sistemas dos clientes?
• O conteúdo do cliente é usado em testes, demonstrações, treinamento de modelos ou melhoria de agentes de outros clientes? Em caso afirmativo, sob quais condições?
• A equipe em locais diferentes tem o mesmo acesso, ou a localização muda o que cada pessoa alcança?

Observe como o fornecedor raciocina, e não apenas o que ele diz. Boas respostas citam funções em vez de pessoas ("o engenheiro de operações de plantão"), explicam por que cada função precisa de acesso e admitem onde o acesso é mais amplo do que gostariam. Respostas fracas se apoiam em confiança ("nossa equipe é muito cuidadosa") ou em tamanho ("são poucas pessoas") sem descrever nenhum controle.

O princípio por trás dessas perguntas é o do menor privilégio: cada pessoa ou sistema recebe apenas o acesso que a tarefa exige. O guia de autorização da OWASP é uma referência simples do que isso significa na prática, e um fornecedor competente deve saber descrever a sua própria versão.

Quais perguntas mostram se o acesso é registrado e revisado?

O registro é o que transforma uma promessa em algo verificável. Mas um log pode falhar de várias formas discretas, então as perguntas precisam ir além de "vocês registram o acesso?"

• Todo acesso da equipe ao conteúdo do cliente é registrado com quem acessou, o que foi acessado, quando e por qual motivo declarado?
• As pessoas cujas ações são registradas podem editar ou apagar esses registros? O ideal é que não possam.
• Podemos ver o registro de acesso da nossa própria conta, sob demanda ou em intervalos definidos?
• Por quanto tempo os logs de acesso são guardados, e esse prazo cobre o tempo de que você precisaria para investigar algo?
• Quem revisa os logs, com que frequência e o que procura? Um log que ninguém lê é um arquivo, não um controle.
• Os próprios logs operacionais contêm conteúdo do cliente, como prompts e respostas completos? Se sim, quem pode lê-los e os campos sensíveis são mascarados?
• Se um acesso parecer indevido, qual é o processo para questioná-lo e quem decide fora da equipe que o solicitou?

O penúltimo ponto surpreende muitos compradores. Sistemas com agentes são monitorados por rastros e logs, e eles costumam capturar o texto que o agente tratou. O material introdutório do OpenTelemetry explica por que essa telemetria é valiosa para operar software, e esse mesmo valor é o que a torna sensível. Um fornecedor pode manter um agente bem monitorado e, ao mesmo tempo, mascarar o conteúdo nos rastros. Pergunte se ele faz isso.

Um fornecedor que consegue mostrar um exemplo de registro de acesso, com nomes ou identificadores da equipe tratados de forma adequada, convence muito mais do que um que apenas descreve o recurso. Se você quer um método estruturado para testar essas afirmações, veja a avaliação de segurança de fornecedor de IA, passo a passo.

Quais perguntas cobrem aprovação, consentimento e emergências?

Os controles técnicos definem o que é possível. As regras de aprovação definem o que é permitido. Você precisa dos dois, e o segundo costuma não estar documentado.

• Um funcionário do fornecedor precisa de aprovação de outra pessoa, e não de si mesmo, antes de ler o seu conteúdo? Quem é essa pessoa?
• Nós aprovamos o acesso antes que ele aconteça, ou apenas somos avisados depois? Existem categorias em que cada caso se aplica?
• Existe um caminho de emergência (às vezes chamado de acesso break-glass) para incidentes urgentes, e que registro e revisão ele dispara depois?
• O acesso tem prazo, de modo que expire sozinho, ou alguém precisa lembrar de removê-lo?
• O que acontece se um órgão do governo ou outro terceiro solicitar os nossos dados ao fornecedor? Seremos avisados, quando a lei permitir?
• Se a equipe acessar conteúdo por engano, ou uma credencial for usada de forma indevida, como e quando ficaremos sabendo?
• Esses limites podem ser escritos no nosso contrato ou escopo de trabalho, para obrigar o fornecedor e não ser apenas a prática atual? Veja o que incluir no escopo de trabalho de um agente de IA.

Vale manter uma distinção com firmeza. A aprovação dada por você é mais forte do que a aprovação do gerente do próprio fornecedor, porque esta só demonstra disciplina interna. Para operações de rotina, a aprovação interna com registro completo pode ser razoável. Para ler o conteúdo das conversas dos seus clientes ou os seus registros financeiros, muitas empresas vão querer aprovar cada caso ou cada classe de caso.

Como distinguir respostas fortes de respostas fracas?

Use isto como guia de decisão enquanto lê as respostas do fornecedor. Cada linha associa um padrão de resposta à forma de tratá-lo.

• O acesso ao conteúdo vem desligado por padrão e é concedido por solicitação, com motivo e prazo de validade: forte. Siga para as perguntas sobre registro.
• O acesso é permanente para um grupo definido, mas registrado e revisado em intervalos fixos: aceitável para dados operacionais, questionável para conteúdo sensível. Pergunte se esse grupo pode ser reduzido.
• O fornecedor não sabe dizer quantas pessoas têm acesso nem quais funções: trate como lacuna. Peça uma resposta por escrito antes de avançar.
• Os logs existem, mas o fornecedor não consegue mostrar os seus: peça uma forma de recebê-los ou uma atestação periódica de que alguém independente os revisou.
• As políticas são descritas apenas de forma verbal: peça que constem no contrato, no escopo de trabalho ou em um anexo de segurança.
• A resposta é "precisamos verificar", seguida de um retorno escrito rápido: bom sinal. Franqueza e rapidez diante de uma pergunta incômoda dizem algo sobre como os incidentes serão conduzidos.
• A resposta é uma garantia genérica, sem mecanismo: fraca. Pergunte o que mostraria que ela é verdadeira.

Para aplicar isso antes de assinar, um plano curto ajuda:

• Anote os lugares de dados que importam para o seu caso de uso, usando o inventário acima.
• Envie por escrito as perguntas sobre acesso, registro e aprovação, com uma data para as respostas.
• Classifique cada resposta como forte, aceitável ou lacuna, usando o guia acima.
• Peça que as lacunas sejam fechadas no contrato ou no escopo, ou aceite-as de forma consciente, com um responsável nomeado do seu lado.
• Agende uma nova revisão quando o agente ganhar novas ferramentas ou fontes de dados, porque novas conexões mudam quem pode ver o quê.

Como isso aparece em um cenário ilustrativo?

Este é um cenário ilustrativo, não a descrição de um cliente real.

Uma distribuidora usa um agente de IA para redigir respostas a e-mails de fornecedores e consultar o status de pedidos no sistema interno. Certa manhã, o agente começa a informar datas de entrega erradas. O responsável por operações da empresa avisa o fornecedor de IA.

Um fornecedor com regras de acesso fracas deixaria um engenheiro abrir a memória de produção e as conversas recentes para achar a falha, sem registro e sem aviso. O responsável por operações nunca saberia que e-mails de fornecedores e informações de preços foram lidos.

Um fornecedor com regras fortes age de outro modo. O engenheiro trabalha primeiro com metadados e rastros mascarados, que mostram que a ferramenta de status de pedidos está devolvendo datas desatualizadas. Isso basta para encontrar a causa. Se o conteúdo fosse necessário, o engenheiro faria uma solicitação com o motivo e o menor conjunto de dados possível, uma segunda pessoa do fornecedor aprovaria, e o responsável por operações da empresa seria avisado e teria a chance de concordar. O acesso expiraria após a correção, e o registro apareceria no log de acesso que a empresa pode consultar.

A falha é a mesma nos dois casos. O que muda é quanto das informações da empresa ficou exposto para encontrá-la e se a empresa teria alguma chance de saber.

Como a Be Human trata o acesso da equipe na operação gerenciada?

A Be Human projeta, implanta e opera agentes de IA cuja identidade, memória, canais, ferramentas e permissões ficam sob controle humano. Em um primeiro projeto, definimos a função do agente, a memória e as ferramentas de que ele precisa e os limites de aprovação, e o acesso da equipe aos seus dados faz parte dessa definição, não é um detalhe deixado para depois. A operação gerenciada inclui monitoramento, revisão de permissões e resposta a incidentes, então as perguntas deste artigo são o que esperamos que os clientes façam e vejam por escrito. A revisão periódica é o momento em que o acesso é verificado de novo conforme as ferramentas e responsabilidades do agente mudam.

Perguntas frequentes

É normal que a equipe de um fornecedor de IA consiga ver dados de clientes? É comum que alguns funcionários alcancem alguns dados, porque alguém precisa operar e consertar o sistema. O que importa é se esse acesso se limita a funções específicas, exige motivo, expira e é registrado. Um fornecedor que afirma que ninguém jamais vê nada deve explicar exatamente como dá suporte e corrige o sistema.

Devemos exigir que nenhum funcionário do fornecedor tenha acesso em nenhuma hipótese? Para muitas empresas isso não é prático e pode tornar a correção de falhas mais lenta. Uma meta melhor é não ter acesso permanente ao conteúdo, ter acesso restrito e por tempo limitado quando um caso exigir e ter a sua aprovação para as categorias mais sensíveis. Se os seus dados são altamente regulados, uma infraestrutura de IA personalizada pode permitir limites mais rígidos.

Usar um fabricante de modelo de grande porte muda quem pode ver os nossos dados? Sim, porque o fabricante passa a ser mais uma parte que processa os seus prompts. Pergunte ao fornecedor quais fabricantes estão envolvidos, quais são os termos de retenção e de acesso da equipe de cada um e se o seu conteúdo é usado para treinamento. Depois, confira se esses termos coincidem com o que o fornecedor prometeu a você.

Que evidências devemos pedir além de um documento de política? Peça um exemplo de registro de acesso, a descrição do processo de aprovação com um exemplo, a lista de funções que têm acesso e as cláusulas contratuais que as obrigam. Você também pode pedir uma demonstração curta de como um incidente seria tratado. Evidências que vêm do sistema em funcionamento são mais confiáveis do que qualquer descrição dele.

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