Agentes de IA para equipes de dados: pedidos, definições e documentação

Um agente de IA para uma equipe de analytics funciona melhor como coordenador ao redor dos analistas, não como substituto deles. Ele faz a triagem dos pedidos que chegam, mantém as definições de métricas e o histórico de mudanças em um único lugar revisado, e rascunha documentação a partir do trabalho que a equipe já faz. Os analistas continuam donos de cada número que sai da equipe.

Principais pontos

• Comece pelo trabalho em volta dos números: entrada de pedidos, definições e documentação. A produção dos números fica com os analistas.
• A triagem é o primeiro papel mais claro: estruturar o pedido, checar duplicidade, pedir o contexto que falta e encaminhar para um responsável nomeado.
• Um registro de definições com um dono por métrica dá ao agente algo confiável para citar e dá à equipe um lugar único para resolver divergências.
• Os rascunhos de documentação são revisados por quem é dono do modelo ou do dashboard, e nunca são publicados sozinhos.
• Dê ao agente acesso somente de leitura por padrão, registre o que ele faz e teste-o com regularidade contra um conjunto pequeno de casos conhecidos.

O que um agente de IA faz por uma equipe de dados?

Equipes de dados raramente ficam sem perguntas. O que falta é tempo para descobrir o que está sendo de fato pedido, qual definição se aplica e se a resposta já existe. É exatamente nessa lacuna que o agente é útil. Ele fica nos canais por onde os pedidos chegam, lê o contexto documentado da equipe e faz o trabalho preparatório que hoje cai sobre quem está de plantão.

Três tarefas se encaixam bem. A primeira é a triagem de pedidos: transformar uma mensagem vaga em um registro estruturado, com responsável. A segunda é a manutenção de definições: cuidar de um registro com o significado de cada métrica, quem é o dono e o que mudou. A terceira é a documentação: rascunhar descrições de tabelas, dashboards e consultas para que o analista edite em vez de escrever a partir da página em branco.

O que o agente não faz é decidir o que é verdade. Escolher o join, tratar os outliers, validar um número e apresentá-lo à diretoria continuam sendo trabalho do analista. Essa divisão é o desenho, não uma limitação. O mesmo padrão, em que o agente carrega a coordenação repetitiva e as pessoas ficam com o julgamento, vale para rotinas e relatórios recorrentes de qualquer equipe de operações.

Como o agente deve fazer a triagem de pedidos de dados?

Uma boa triagem faz com que todo pedido saia da entrada com cinco itens: a decisão que ele apoia, a métrica ou entidade envolvida, o período, o prazo e um solicitante que possa responder a dúvidas. O agente consegue exigir isso sem virar porteiro, porque pergunta com educação e na hora, e não três dias depois.

Este é um plano que uma equipe pequena pode implantar, nesta ordem:

• Capture o pedido onde ele chegar (chat, e-mail, formulário) e crie um único registro, para que nada fique só em uma conversa.
• Peça o contexto que falta em uma única mensagem: a decisão, o prazo, o público e a definição que o solicitante tem em mente.
• Busque no registro de definições e nos chamados anteriores a mesma pergunta, e aponte qualquer dashboard ou análise anterior que já possa respondê-la.
• Classifique o pedido como resposta de autoatendimento, consulta rápida, análise nova ou relato de qualidade de dados.
• Proponha um responsável e uma prioridade com regras escritas, e deixe o líder da equipe confirmar o que fugir dessas regras.
• Envie ao solicitante uma nota de status simples e publique uma atualização sempre que o responsável ou o prazo mudar.
• Quando o trabalho for concluído, registre onde está a resposta final, para que o próximo pedido parecido seja encontrado no terceiro passo.

Mantenha as regras de classificação curtas e escritas pelo líder da equipe. Se as regras estiverem só na cabeça das pessoas, o agente vai chutar, e os chutes vão parecer confiantes. Também ajuda tratar o texto de cada pedido como dado, e não como instrução. Um e-mail colado ou uma mensagem encaminhada pode conter linhas que parecem comandos, e as orientações do OWASP sobre prevenção de prompt injection são uma boa referência para manter essa separação.

Como evitar que as definições de métricas se percam?

As definições se desviam em silêncio. Um analista exclui contas internas, outro não. Um filtro do dashboard muda depois de um lançamento e ninguém atualiza a descrição. Duas semanas depois, dois líderes citam números diferentes para o que ambos chamam de mesma coisa.

A solução começa por um registro, que é um documento ou tabela simples com uma entrada por métrica. Os campos úteis são:

• Nome e uma definição em linguagem simples que quem não é analista consiga ler.
• As tabelas de origem e o cálculo, com link em vez de cópia.
• Um dono nomeado e um substituto.
• Exclusões conhecidas e casos de borda.
• Onde a métrica é usada: dashboards, relatórios, material de diretoria.
• Um histórico de mudanças com data, motivo e quem aprovou.

Com o registro pronto, o agente tem quatro tarefas. Ele responde a perguntas como o que conta como conta ativa citando a entrada e indicando o dono, e diz com clareza quando não existe entrada. Ele sinaliza pedidos que usam um termo com duas definições, antes de qualquer análise começar. Ele percebe quando uma consulta ou dashboard muda a lógica e rascunha uma proposta de atualização do registro para o dono. E ele lembra os donos de revisar suas entradas no ritmo que a equipe definir.

A regra é que o agente propõe e o dono aprova. O agente nunca edita uma definição diretamente. Responder a partir de um registro curado, e não do que o modelo lembra, é a lógica dos desenhos baseados em recuperação, e a documentação da AWS que compara recuperação com ajuste fino (fine-tuning) explica por que isso combina com conhecimento que muda com frequência. Se as suas métricas também alimentam indicadores de saúde de contas, o mesmo registro importa para as equipes de suporte e relacionamento com o cliente, que muitas vezes herdam definições que não escreveram.

Onde o agente pode rascunhar documentação com segurança?

Documentação é um bom ponto de partida porque um rascunho é barato de revisar e caro de escrever do zero. A maioria das equipes de dados tem bastante matéria-prima: esquemas, arquivos de consulta, configurações de dashboards, chamados fechados e comentários de revisão. O agente lê esse material e produz primeiras versões de:

• Descrições de tabelas e colunas.
• Um guia curto para cada dashboard: o que mostra, o que deixa de fora e quem é o dono.
• Runbooks de relatórios recorrentes, incluindo onde olhar quando uma atualização falha.
• Um resumo de cada análise concluída: pergunta, método, ressalvas e onde o resultado está guardado.
• Um changelog de mudanças de definições e de pipelines, no estilo das notas de versão escritas para equipes de produto.

Três hábitos mantêm isso seguro. Todo rascunho é identificado como rascunho e cita as fontes em que foi baseado. O dono do modelo ou do dashboard revisa e publica. E, quando o agente não consegue saber o que uma coluna significa, ele escreve uma pergunta explícita para o dono em vez de inventar uma descrição plausível. Uma descrição de coluna confiante e errada é pior do que nenhuma.

O agente também pode checar a desatualização, comparando a documentação publicada com o esquema atual e listando as divergências. É uma tarefa pequena e maçante, que as pessoas raramente conseguem fazer, e compensa na primeira vez que um novo analista entra e confia na documentação. Manter o material que o agente lê enxuto e atual faz diferença aqui, e as notas da Anthropic sobre engenharia de contexto eficaz para agentes são uma leitura prática sobre o assunto.

O que deve continuar com os analistas?

O limite é mais fácil de sustentar se estiver escrito como um guia de decisão, e não deixado ao julgamento do momento.

• O agente age sozinho quando a ação é reversível e interna: criar o registro de um chamado, fazer uma pergunta de esclarecimento, apontar uma análise anterior, enviar uma nota de status, sinalizar um documento desatualizado.
• O agente rascunha e uma pessoa aprova quando o resultado será lido como posição da equipe: uma mudança no registro, um documento publicado, uma resposta que assume um prazo, uma prioridade que contraria as regras escritas.
• Só uma pessoa cuida de tudo o que produz ou interpreta um número para quem decide: rodar a análise, escolher métodos, validar números e tratar pedidos que envolvam dados pessoais ou financeiros sensíveis.

As permissões devem seguir o mesmo desenho. Dê ao agente acesso de leitura aos metadados (esquemas, histórico de consultas, configurações de dashboards) e ao sistema de chamados, não às tabelas sensíveis brutas, a menos que uma tarefa específica exija. Conceda acesso de escrita apenas aos lugares onde os rascunhos ficam. As orientações de autorização do OWASP sobre privilégio mínimo e negação por padrão se aplicam diretamente. Revise essas permissões periodicamente, porque ferramentas e equipes mudam e o acesso tende a se acumular.

Como isso funciona na prática?

Cenário ilustrativo: um diretor comercial regional escreve no canal da equipe pedindo o churn por região para uma apresentação ao conselho, com prazo na sexta-feira. O agente responde na própria conversa. Ele observa que o registro tem duas entradas, churn de clientes e churn de receita, com donos diferentes, e pergunta qual delas o conselho usa. Também aponta uma análise de um trimestre anterior que cobria as mesmas regiões com o mapeamento antigo de regiões.

O diretor escolhe churn de receita. O agente cria o registro, classifica como análise nova porque o mapeamento de regiões mudou, propõe o dono dessa métrica e avisa o diretor de que o dono vai confirmar o prazo. O líder da equipe aprova o encaminhamento com um clique.

O analista roda os números, confere com a visão financeira e envia o resultado. Depois, o agente rascunha uma nota curta de método: a definição usada, o mapeamento de regiões e a única exclusão aplicada pelo analista. O analista edita duas frases, aprova, e a nota é anexada à entrada do registro. Na próxima vez que alguém perguntar sobre churn por região, a resposta, a ressalva e o responsável estarão disponíveis já no primeiro passo.

Nada nesse fluxo exigiu que o agente produzisse um número. Ele eliminou as idas e vindas, o retrabalho e a decisão sem registro.

Como a Be Human opera um agente assim?

Um primeiro projeto define um papel útil, por exemplo a triagem de pedidos, junto com a memória de que ele precisa (o registro de definições, chamados anteriores, documentação), as ferramentas que ele pode acionar (chat, sistema de chamados, acesso somente leitura aos metadados do data warehouse), os limites de aprovação e um critério de sucesso observável, como quantos pedidos chegam ao responsável com o contexto completo. Identidade, memória, canais e permissões continuam sob o seu controle. A operação gerenciada pode incluir monitoramento, avaliações recorrentes contra casos conhecidos, manutenção de integrações, revisão de permissões, resposta a incidentes e melhorias controladas. O serviço é remoto e está disponível em inglês e português. Equipes que querem ver como isso se estende a outras áreas de apoio podem olhar agentes de IA para help desk de TI, que seguem o mesmo padrão de entrada de pedidos.

Perguntas frequentes

Um agente de IA pode escrever o SQL e produzir os números? Tecnicamente, ele pode rascunhar consultas, e um analista pode usar esses rascunhos como ponto de partida. Nós não deixaríamos o agente entregar números a stakeholders sem que um analista rode, confira e valide o resultado. O valor do agente está no trabalho em volta do número, e a responsabilidade pelo número continua com uma pessoa.

A quais ferramentas o agente precisa ter acesso? No mínimo, ao canal onde os pedidos chegam, ao sistema de chamados ou de acompanhamento e ao lugar onde ficam o registro e a documentação. Acesso somente leitura a esquemas e ao histórico de consultas ajuda a rascunhar a documentação. Qualquer coisa além disso deve ser adicionada uma tarefa por vez, com um motivo nomeado.

Como saber se o agente continua se comportando bem ao longo do tempo? Monte um conjunto pequeno de casos conhecidos: pedidos com um encaminhamento correto evidente, perguntas com resposta documentada e armadilhas, como termos ambíguos ou instruções escondidas em uma mensagem. Rode esses casos periodicamente e após qualquer mudança, e revise os registros das ações reais. O material da Anthropic sobre avaliações (evals) de agentes de IA mostra como estruturar isso.

Precisamos de um catálogo de dados completo para começar? Não. Um documento compartilhado com um punhado das métricas mais disputadas, cada uma com seu dono, já basta para começar. O agente vai expor as lacunas rapidamente, e o registro pode crescer conforme os pedidos reais mostrarem quais definições importam.

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