Como fazer perguntas aos dados da empresa usando IA
Um método prático para transformar dúvidas de gestão em respostas verificáveis, com métricas, permissões, fontes, limites e revisão humana.
Por Cesar A. Machado · · 16 min
Comece por uma decisão recorrente, não por uma ferramenta de IA.
Escreva a fórmula, a unidade, o período e a fonte oficial da métrica.
Separe acesso aos dados, capacidade de consultar e autorização para agir.
Compare respostas com casos conhecidos antes de ampliar o uso.
Interrompa o fluxo quando a fonte, o escopo ou a confiança falhar.
A resposta curta: pergunte com contrato, não com improviso
Você pode fazer perguntas aos dados da empresa usando IA, mas a qualidade da resposta dependerá menos do brilho do modelo e mais do contrato ao redor da pergunta. Esse contrato precisa dizer qual decisão será apoiada, qual fonte é oficial, como o indicador é calculado, qual período vale, quem pode consultar, que evidência a resposta deve mostrar e quando um humano precisa revisar. Sem isso, a IA pode produzir uma frase convincente a partir de dados incompletos, duplicados ou fora do escopo.
Para uma empresa de 20 a 100 funcionários, o caminho mais seguro é começar com uma decisão recorrente e de baixo risco: acompanhar vendas recebidas, pedidos em atraso ou margem de uma linha. O gestor descreve a pergunta em linguagem de negócio; a camada de dados aplica filtros e fórmulas determinísticas; a IA organiza a explicação; e uma pessoa confere a evidência antes de decidir. A IA ajuda a consultar e interpretar. Não deve inventar a métrica, ampliar permissões nem executar uma ação irreversível.
Isso muda a forma de escolher a primeira iniciativa. Em vez de comprar uma ferramenta porque ela conversa com uma planilha, escolha uma decisão que hoje consome tempo, acontece com frequência e tem uma consequência limitada se for interrompida. Documente o caminho atual: quem pede, quem extrai, quem confere, quem explica e quem decide. O objetivo do piloto é remover atrito mensurável sem esconder o trabalho que continua humano. Se a equipe não consegue explicar de onde sai o número hoje, a prioridade pode ser organizar a definição, não adicionar um modelo. Também evite confundir três produtos diferentes. Um painel fixo responde perguntas já previstas; uma consulta parametrizada permite variar filtros dentro de limites; um assistente generativo redige explicações e pode pedir esclarecimentos. O terceiro é útil, mas é o menos indicado para decidir sozinho quais fontes e regras usar. Para a maioria das empresas desse porte, uma combinação de catálogo de métricas, consultas autorizadas e explicação assistida oferece previsibilidade suficiente para aprender antes de ampliar.
Converta a dúvida do gestor em uma especificação verificável
Perguntas de gestão costumam chegar curtas: “qual cliente dá mais lucro?”, “por que a venda caiu?” ou “qual equipe está atrasando entregas?”. O problema é que cada expressão pode esconder uma definição. “Lucro” inclui imposto, frete, comissão e custo de atendimento? “Caiu” compara com o mês anterior, com o mesmo mês do ano passado ou com a meta? Antes de conectar qualquer assistente, reescreva a dúvida como uma ficha de indicador: nome, objetivo, fórmula, unidade, fonte, periodicidade, dimensões permitidas, exclusões e responsável.
Link para consulta, filtros aplicados e linhas agregadas.
Essa ficha também define o que a IA deve fazer e o que não deve fazer. Ela pode traduzir “mostre a margem por cliente no último mês” para uma consulta parametrizada e explicar variações. Não deve decidir sozinha que “último mês” significa o mês civil, nem misturar pedidos faturados com pedidos apenas lançados. Se faltar uma dimensão necessária, a saída correta é pedir esclarecimento ou marcar a resposta como incompleta. Uma pergunta adicional é um controle de qualidade, não uma falha de experiência.
O catálogo precisa ter uma rotina de mudança. Toda alteração de fórmula deve registrar versão, data, autor, motivo e efeito esperado sobre históricos. Se a empresa passa a incluir frete na margem, comparar julho com junho sem marcar a mudança pode induzir uma conclusão errada. Mantenha a definição antiga para reproduzir relatórios já apresentados e indique a partir de qual data a nova regra vale. A IA deve receber a versão vigente e, quando perguntada sobre um período anterior, aplicar a regra correspondente ou informar que não há comparabilidade.
Uma boa especificação ainda descreve a linguagem que não pode ser interpretada livremente. “Cliente ativo” pode significar compra nos últimos 90 dias, contrato vigente ou cadastro sem data de encerramento. “Venda do mês” pode ser pedido criado, faturado ou recebido. Registre sinônimos aceitos, termos ambíguos e perguntas que exigem confirmação. Esse trabalho reduz respostas diferentes para a mesma frase e ajuda o time a descobrir onde o processo de negócio ainda não tomou uma decisão.
Prepare a base: fonte oficial, qualidade e escopo de acesso
Uma interface conversacional não corrige uma base sem dono. Liste os sistemas que contêm vendas, custos, clientes, estoque, pessoas e contratos; registre o proprietário de cada conjunto; indique a data da última atualização; e classifique campos pessoais, financeiros e estratégicos. Escolha uma fonte oficial por indicador. Se o ERP é a fonte de vendas e a planilha do comercial é apenas uma conferência, a IA não pode escolher a planilha porque ela está mais fácil de ler. Quando duas fontes divergem, a saída é abrir uma pendência de reconciliação.
Separe três permissões que frequentemente são confundidas. A primeira é poder acessar um dado; a segunda é poder fazer uma consulta; a terceira é poder tomar uma decisão ou alterar um registro. Um gerente comercial pode consultar sua carteira sem enxergar salários ou dados de outras equipes. O financeiro pode revisar a fórmula de margem, mas ainda assim não deveria editar a definição sem aprovação do responsável pelo indicador. Essa separação reduz o raio de um erro e torna a auditoria compreensível.
Na prática, use identificadores de usuário, grupos por função, filtros por empresa ou equipe e registros de consulta. Não envie para um serviço externo mais dados do que a pergunta exige. Para comparar desempenho por região, talvez bastem identificadores agregados e valores; nomes, telefones e documentos podem ficar fora. A LGPD orienta finalidade, adequação e necessidade, e a segurança deve proteger contra acesso não autorizado, perda, alteração e tratamento inadequado. A aplicação concreta depende do contexto, da base legal, do contrato com fornecedores e da avaliação de risco.
Falha observada
Causa provável
Correção antes da IA
Duas margens para o mesmo cliente
Fórmulas ou cortes diferentes
Escolher dono, fórmula e período oficial.
Resposta mistura meses
Datas em fusos ou filtros implícitos
Padronizar data de competência e corte.
Usuário vê carteira alheia
Consulta sem filtro de escopo no servidor
Aplicar autorização antes da consulta.
Número muda sem explicação
Carga atrasada ou fonte não versionada
Exibir atualização, versão e status da carga.
Faça uma amostra de qualidade antes de automatizar. Escolha registros de períodos diferentes e verifique campos obrigatórios, duplicidades, valores negativos, chaves sem correspondência, datas futuras e registros cancelados. Para cada problema, classifique se ele bloqueia o cálculo, apenas reduz a cobertura ou pode ser corrigido automaticamente. Uma contagem de linhas não prova qualidade; é preciso saber se as linhas representam entidades únicas e se o significado dos campos permaneceu estável.
Defina também o comportamento quando uma pessoa muda de função, sai da empresa ou passa a atender outra carteira. A autorização deve ser derivada de uma fonte de identidade atualizada, com revisão periódica e remoção rápida de acessos. Convém testar deliberadamente o caso de um usuário que tenta perguntar por uma empresa que não está em seu escopo. A resposta precisa negar de modo seguro, sem revelar se o registro existe, e o evento deve ficar disponível para investigação sem expor mais dados do que o necessário.
A qualidade deve ser observada no momento em que a pergunta é respondida, não apenas quando a integração foi criada. Mostre a data da carga, o horário do último processamento e a cobertura do período solicitado. Se o usuário pedir julho e a origem só tiver dados até 28 de julho, a resposta deve delimitar a janela real ou bloquear o resultado. Da mesma forma, se uma alteração de cadastro não chegou ao histórico, a consulta precisa expor essa lacuna. Transparência sobre cobertura permite que o gestor ajuste a decisão sem transformar uma ausência em falsa precisão. Para cada métrica, mantenha um exemplo de cálculo manual ou uma consulta de referência que possa ser reproduzida. Esse artefato não precisa ser sofisticado: precisa conter entradas, filtros e resultado esperado. Ele ajuda a investigar regressões quando um conector muda, uma coluna é renomeada ou uma carga passa a incluir cancelamentos. O responsável pelo dado deve aprovar a correção; o modelo não pode “aprender” uma correção informal e alterá-la sem versão, teste e registro.
Cenário hipotético: uma pergunta de margem com limites explícitos
Suponha uma distribuidora fictícia com 42 funcionários, 180 pedidos faturados e uma reunião mensal de carteira. A pergunta é: “qual foi a margem de contribuição por cliente em julho de 2026?”. Premissas: período de 01/07/2026 a 31/07/2026; unidade percentual; somente pedidos faturados; receita líquida já descontada de devoluções e impostos definidos pela empresa; custos variáveis limitados a mercadoria, comissão e frete diretamente atribuídos; clientes com receita líquida igual a zero ficam fora do ranking. O responsável pelo indicador é o financeiro, e o comercial pode consultar apenas sua carteira.
A fórmula é: margem de contribuição (%) = (receita líquida − custos variáveis) ÷ receita líquida × 100. Para um cliente hipotético com R$ 50.000 de receita líquida e R$ 38.000 de custos variáveis no período, o cálculo é (50.000 − 38.000) ÷ 50.000 × 100 = 24%. A unidade monetária é o real; a unidade final é percentual; a janela é um mês civil; e o resultado não representa lucro líquido, porque despesas fixas, impostos não incluídos e custos indiretos ficaram fora.
A resposta útil não é apenas “24%”. Ela deve informar o período, a quantidade de pedidos incluídos, a fonte, a data da última carga, a fórmula, os componentes do custo, eventuais pedidos sem custo e o nível de confiança operacional da base. Se a comissão de três pedidos ainda não foi lançada, o sistema deve mostrar “custo incompleto” e impedir que a margem seja apresentada como definitiva. A IA pode explicar que a margem caiu por frete maior; a consulta determinística precisa mostrar quais registros sustentam essa conclusão.
Limites do cenário: não há previsão de margem futura, causalidade estatística ou recomendação automática de preço. O cálculo não autoriza renegociar com o cliente. Se a empresa usar outra convenção contábil, a fórmula deve ser revisada pelo responsável antes do piloto. O exemplo serve para demonstrar entradas, etapas, saída, exceções e critérios de interrupção; não serve como modelo universal de margem.
Desenhe o fluxo: entrada, processamento, saída e responsável
Um fluxo confiável começa quando o usuário formula a pergunta. A aplicação identifica a pessoa e a empresa, valida o escopo, reconhece a métrica permitida, solicita esclarecimentos quando necessário e transforma a intenção em parâmetros controlados. Depois consulta a camada de dados com filtros aplicados no servidor, registra a consulta e devolve valores, evidências e limitações. Só então a IA redige um resumo em linguagem natural. Essa ordem importa: o modelo não deve escolher livremente tabelas sensíveis nem gerar SQL sem validação e autorização.
Etapa
Responsável principal
Saída verificável
Exceção que interrompe
Definir pergunta
Gestor solicitante
Objetivo, métrica e período
Termo ambíguo ou decisão de alto impacto
Autorizar escopo
Sistema e dono do dado
Usuário, empresa e filtros
Permissão ausente ou escopo vazio
Consultar fonte
Serviço de dados
Linhas agregadas, versão e timestamp
Carga atrasada, duplicidade ou fórmula ausente
Explicar resultado
IA sob contrato
Resumo com evidências e ressalvas
Saída sem suporte ou fora do schema
Decidir
Gestor responsável
Ação registrada ou decisão suspensa
Risco alto ou revisão pendente
Registre um identificador da pergunta, usuário, empresa, momento, versão da definição, parâmetros, fonte consultada, resultado, resposta exibida e decisão tomada. Não é necessário guardar tudo para sempre; é necessário definir retenção, acesso e descarte. Para dados pessoais, a equipe deve saber por que registra cada item e quem pode revisá-lo. Um log que contém a pergunta completa pode vazar nomes e valores; prefira minimizar conteúdo e separar metadados operacionais de dados de negócio.
Para não concentrar toda a responsabilidade em tecnologia, atribua papéis pequenos e claros. O dono do indicador aprova definição e mudanças; o dono da fonte responde por atualização e correção; segurança ou administração revisa acesso; a área usuária confirma se a resposta ajuda uma decisão; e o operador acompanha falhas e custo. Em uma empresa menor, uma mesma pessoa pode acumular papéis, mas a acumulação deve ser registrada. O que não funciona é deixar o sistema sem ninguém capaz de explicar um número contestado.
As exceções também precisam de destino. Dados ausentes podem voltar ao responsável pela carga; ambiguidade pode voltar ao solicitante; falta de permissão deve ir para o administrador do escopo; e uma falha recorrente de fórmula deve abrir revisão do catálogo. Cada estado precisa ter prazo e próximo passo. Se todas as falhas terminam em uma caixa de entrada sem dono, a conversa com a IA apenas acelera a produção de pendências.
Valide com casos conhecidos e meça o que pode falhar
Monte um conjunto de teste com perguntas comuns, variações de linguagem, filtros vazios, períodos inválidos, dados atrasados, usuário sem permissão e um caso em que a fonte oficial diverge da planilha antiga. Para cada caso, registre a resposta esperada, os registros de referência, a pessoa que conferiu e o resultado. A pergunta não é apenas “a IA acertou?”. É “a consulta usou a fonte correta, respeitou o escopo, calculou a métrica certa, revelou sua limitação e encaminhou a exceção?”.
Acompanhe pelo menos cinco métricas: tempo até a primeira resposta; percentual de respostas com evidência; taxa de correções humanas; taxa de perguntas encaminhadas por falta de dados ou permissão; e incidentes de exposição ou uso indevido. Se o objetivo é reduzir trabalho, estime também minutos de revisão por pergunta e custo de operação. Uma resposta rápida que exige conferência completa não economiza tempo. Uma resposta correta em uma única área, mas acessível a usuários errados, é um incidente de segurança, não um ganho de produtividade.
Defina faixas antes do piloto. Por exemplo, exigir evidência em 100% das respostas do conjunto de teste, zero acesso fora do escopo e correção humana em até um dia útil para falhas classificadas como recuperáveis. Esses números são critérios de projeto, não estatísticas universais. O limite adequado depende do impacto da decisão, da sensibilidade do dado e da capacidade da equipe. O NIST AI RMF recomenda testar antes da implantação e continuar medindo durante a operação; a lição prática é transformar qualidade em rotina, não em demonstração.
Se você precisa transformar esse roteiro em um piloto pequeno, descreva a decisão, as fontes e a principal exceção em https://blog.cesarmachado.com/contato. Uma conversa inicial deve esclarecer escopo e risco antes de escolher ferramenta.
Compare pelo menos uma parte do piloto com o processo anterior usando o mesmo período e as mesmas perguntas. Registre tempo de extração, tempo de conferência e tempo para chegar à decisão; não conte apenas os segundos até a resposta na tela. Separe erro de dado, erro de regra, erro de autorização, erro de interpretação e erro de apresentação. Essa taxonomia mostra onde investir: limpeza, governança, engenharia, treinamento ou revisão de linguagem.
A taxa de resposta não é uma métrica de sucesso isolada. Um bom sistema pode recusar mais perguntas no início porque está identificando escopo desconhecido, e isso pode ser melhoria. Observe a proporção de recusas corretas, o tempo para resolver exceções e quantas perguntas voltam por falta de contexto. Peça a usuários diferentes que repitam os testes com vocabulário próprio. Se apenas a pessoa que criou o piloto obtém bons resultados, há dependência de conhecimento tácito. Registre também o motivo de cada correção e se ela altera a regra, o dado de origem ou apenas a explicação. Essa distinção evita “treinar” o modelo para mascarar um problema de cadastro. Revise os resultados em uma reunião curta, com o dono do indicador e o responsável pela fonte, e transforme cada falha recorrente em uma tarefa com prazo, prioridade e critério de encerramento.
Defina riscos, exceções e o botão de parar
Os riscos aparecem em camadas. Na entrada, uma pergunta ambígua pode selecionar a métrica errada. Na consulta, um filtro ausente pode cruzar empresas ou equipes. Nos dados, uma carga atrasada pode produzir um número antigo. Na resposta, o modelo pode preencher uma lacuna com texto plausível. Na decisão, alguém pode tratar uma indicação como fato e agir sem revisão. Para cada camada, classifique impacto, probabilidade, dono, sinal de detecção e resposta. Isso torna o problema operável quando a pressão da reunião chegar.
Interrompa o fluxo quando a identidade não puder ser confirmada; quando o escopo autorizado estiver vazio; quando a fonte estiver fora do prazo de atualização; quando faltarem campos essenciais da fórmula; quando o resultado mudar acima de um limite sem explicação; quando a resposta não tiver evidência; ou quando a ação pretendida for irreversível, financeira, trabalhista ou relacionada a dado sensível sem revisão apropriada. Interromper significa retornar um estado explícito — pendente, bloqueado ou encaminhado — e registrar o motivo.
Escalar apenas quando o caso de uso passar pelos testes, tiver responsável e puder ser revertido. A ampliação pode incluir mais perguntas, áreas ou períodos, mas cada expansão muda fontes, permissões e riscos. Faça uma revisão mensal do catálogo de métricas, usuários autorizados, falhas, custos e decisões suspensas. Uma política simplificada de segurança pode ser adequada a uma empresa menor, desde que reflita custos, estrutura, escala, volume e risco; simplificar documentação não significa abandonar controle.
O fornecedor também entra no mapa de risco. Verifique onde os dados são processados, quais controles de acesso existem, como o serviço registra entradas e saídas, quais subcontratados participam, como incidentes são comunicados e como os dados são eliminados ao encerrar o contrato. Não presuma que uma opção chamada “empresarial” resolve tudo. A decisão deve considerar o dado efetivamente enviado, o uso permitido, a retenção, a localização e a capacidade da empresa de interromper ou substituir o serviço.
Um plano de reversão pode ser simples: desabilitar o assistente, preservar o catálogo e os logs necessários, voltar ao relatório conhecido e comunicar quais decisões ficaram pendentes. Teste essa volta antes de depender do fluxo. Também defina como corrigir uma resposta já compartilhada: localizar perguntas afetadas, avisar os destinatários, registrar a correção e avaliar se houve impacto. Recuperabilidade não é pessimismo; é parte do desenho de uma operação que precisa continuar quando a integração ou o modelo estiver indisponível.
Antes de ampliar, registre também o impacto de uma decisão errada e o custo de manter a revisão humana. Uma resposta de estoque pode exigir correção operacional; uma resposta sobre pessoas pode afetar direitos e relações de trabalho. Quanto maior o impacto, mais conservadores devem ser o escopo, a evidência, a aprovação e o plano de reversão. Se não houver capacidade de revisar no prazo, reduza a pergunta ou adie o uso. Em uma operação pequena, o procedimento pode caber em uma página: motivo da parada, pessoa que aprova a retomada, dados que devem ser preservados, comunicação necessária e teste que confirma a correção. O importante é que a equipe consiga executar o procedimento sob pressão, sem depender da memória de quem configurou a integração. Revise esse roteiro depois de cada falha relevante e retire controles que não protegem nenhuma decisão. Registre também a data da retomada, a versão corrigida e a evidência de que o acesso continua restrito.
Se a sua empresa já tem uma pergunta recorrente, comece pela ficha de indicador: decisão, fórmula, fonte, período, permissão, evidência e critério de parada. Para discutir um diagnóstico ou um piloto com esse escopo, use https://blog.cesarmachado.com/contato.
Uma resposta de IA só entra na reunião quando alguém consegue apontar a fonte, a fórmula, o período e o responsável por contestá-la.
Quer aplicar isso na sua empresa?
Converse comigo sobre o processo que você quer melhorar e os critérios para começar com segurança.
Os projetos são apresentados pelo problema e pela engenharia envolvida, preservando informações internas. O objetivo é mostrar como decisões de produto, arquitetura e operação se conectam.
Um projeto começa com uma pergunta de negócio, avança por uma primeira versão controlada e só cresce quando os dados mostram que a solução cabe na operação.
{{ item.num }}
{{ item.title }}
{{ item.text }}
LIMITES CLAROS
A confiança também está no que o sistema não promete.
Empresas de 20 a 100 pessoas, com um processo real para melhorar.
O ponto de partida é um processo específico, com responsável, volume e impacto identificáveis. A solução precisa caber na capacidade da equipe, produzir evidência e preservar controle sobre decisões importantes.
→{{ item }}
Tecnologias e camadas
A FERRAMENTA SEGUE O PROCESSO
{{ item }}
SE FIZER SENTIDO
Descreva um processo que você gostaria de entender melhor.
Envie o fluxo atual, o volume aproximado e o principal gargalo. A primeira conversa serve para entender o problema e avaliar o próximo passo mais proporcional.
Ferramentas
Clique em uma ferramenta para abrir. Conteúdo de cada uma a definir.
Kit atual
{{ t.num }}
{{ t.title }}
{{ t.desc }}
{{ t.state }}
Portfólio
Projetos de software e ecossistemas construídos com engenharia de IA. Conteúdo de cada caso a definir.
{{ caseCount }}
Projetos
capa do projeto{{ p.num }}
{{ p.kind }} · {{ p.year }}
{{ p.title }}
{{ p.desc }}
{{ tg.label }}
ABRIR CASO
{{ detail.num }}{{ detail.kind }}
{{ detail.title }}
{{ detail.desc }}
{{ m.k }}
{{ m.v }}
imagem principal do caso
{{ bl.title }}
{{ bl.hint }}
Briefing
3 PASSOS · CERCA DE 1 MINUTO
Toque nas opções que descrevem seu projeto. Só o último passo pede digitação.
Briefing recebido
Obrigado. Retorno pelo e-mail informado com as próximas perguntas.
