O fim do dashboard como destino final da ciência de dados
Durante muitos anos, a entrega típica de um projeto de ciência de dados foi o dashboard. O modelo era desenvolvido, validado, transformado em indicadores e disponibilizado em uma interface visual.
Essa lógica ajudou muitas empresas a organizar dados, reduzir dependência de planilhas e criar uma camada comum de acompanhamento. O problema é que muitos modelos analíticos não foram construídos apenas para acompanhamento. Foram construídos para apoiar decisões.
Essa diferença muda o desenho da solução.
Um dashboard responde bem a perguntas recorrentes: o que aconteceu, onde ocorreu, qual indicador mudou, qual segmento performou melhor. Mas decisões empresariais relevantes costumam exigir perguntas condicionais, restrições operacionais, simulações e avaliação de incerteza.
Em um modelo de Marketing Mix Modeling, por exemplo, a área de marketing não quer apenas ver o ROAS histórico por canal. Ela quer saber o que acontece se o orçamento cair 20%, se TV não puder ser alterada por contrato ou se paid search já estiver próximo da saturação.
Em previsão de demanda, a área de planejamento não quer apenas uma previsão pontual. Ela precisa entender o intervalo provável de demanda, o risco de ruptura, o impacto de um cenário promocional e a decisão ótima de compra considerando custo de estoque.
Em manutenção preditiva, a operação não quer apenas um score de falha. Precisa decidir se antecipa uma intervenção, se espera a próxima janela operacional ou se redistribui o risco entre ativos.
Essas perguntas raramente cabem em filtros predefinidos.
Quando elas aparecem, o fluxo tradicional volta para a equipe de dados. O cientista de dados reabre o notebook, ajusta premissas, roda simulações, gera gráficos, interpreta os resultados e prepara uma nova devolutiva.
Esse processo funciona, mas escala mal.
O problema não é visualização
Dashboards continuam sendo úteis. A crítica não é ao dashboard como artefato de visualização. A crítica é à expectativa de que ele seja suficiente para operacionalizar modelos estatísticos, preditivos ou prescritivos.
Há uma diferença entre disponibilizar informação e estruturar uma decisão.
Disponibilizar informação significa apresentar indicadores, séries, cortes, rankings e alertas.
Estruturar uma decisão exige transformar uma pergunta de negócio em uma consulta analítica válida, executar modelos ou simulações, respeitar restrições, explicitar incerteza, registrar premissas e indicar quando a evidência não sustenta uma recomendação.
É nesse ponto que agentes analíticos passam a ser relevantes.
Agentes analíticos não deveriam ser apenas chats sobre dados.
A primeira aplicação evidente de IA generativa em analytics foi adicionar uma interface conversacional aos dados. O usuário pergunta em linguagem natural, o sistema consulta tabelas, gera gráficos e escreve uma explicação.
Isso melhora o acesso. Mas não resolve, por si só, o problema de validade analítica.
Um agente pode produzir uma resposta sintaticamente correta e estatisticamente frágil. Pode gerar um gráfico adequado, mas usar uma métrica inadequada. Pode explicar uma correlação como se fosse efeito causal. Pode otimizar uma função objetivo sem considerar restrições operacionais. Pode responder uma pergunta que deveria ser recusada por falta de evidência.
Em ciência de dados aplicada, o risco não está apenas na alucinação textual. Está também na inferência mal especificada.
Por isso, a arquitetura de agentes analíticos precisa ser diferente da arquitetura de um chatbot genérico. O agente não deve ser a fonte dos números. Ele deve atuar como camada de interpretação, orquestração e controle de execução.
As estimativas precisam vir dos modelos.
As simulações precisam vir de código executado.
As recomendações precisam respeitar restrições explícitas.
As respostas precisam carregar incerteza.
As decisões precisam deixar rastros.
A incerteza precisa aparecer na decisão
Grande parte dos sistemas corporativos ainda comunica modelos como se eles entregassem certezas. A previsão aparece como um número. O score aparece como ranking. A recomendação aparece como ação sugerida.
Essa simplificação facilita o consumo, mas pode distorcer a decisão.
Em problemas reais, a incerteza não é um detalhe técnico. Ela altera a decisão. Uma ação com maior valor esperado pode ser inadequada se tiver variância alta. Uma diferença entre alternativas pode não ser material quando os intervalos de incerteza se sobrepõem. Uma previsão pontual pode ser insuficiente para dimensionar estoque, caixa, equipe ou risco operacional.
Sistemas analíticos mais maduros deveriam comunicar, no mínimo:
- estimativa central;
- intervalo de incerteza;
- premissas utilizadas;
- sensibilidade a cenários;
- limites de validade do modelo;
- critérios para revisão humana.
Isso se torna ainda mais importante quando agentes passam a intermediar o uso dos modelos. Um agente que apenas entrega uma resposta final pode ocultar a incerteza. Um agente bem desenhado deve conseguir explicar quando a recomendação é estável, quando é sensível e quando não deve ser automatizada.
O sistema também precisa saber quando não responder
Um ponto pouco discutido é que a capacidade de bloquear uma resposta faz parte da qualidade de um sistema analítico.
Em muitos contextos, a resposta correta não é uma recomendação. É uma restrição:
- o modelo não foi treinado para esse tipo de cenário;
- a pergunta exige inferência causal, mas os dados disponíveis só sustentam associação;
- há poucas observações históricas para estimar o efeito;
- os diagnósticos do modelo não são satisfatórios;
- a previsão está fora da região observada nos dados;
- a conclusão muda muito com pequenas alterações nas premissas.
Essa lógica é comum na prática estatística, mas pouco comum em sistemas corporativos orientados a “entregar respostas”. Agentes analíticos tornam esse ponto mais importante, porque reduzem o atrito entre pergunta e resposta.
Quando o custo de perguntar cai, o risco de perguntas mal formuladas aumenta.
Uma arquitetura mais adequada
Na Murabei, temos trabalhado com a premissa de que modelos analíticos devem ser tratados como componentes de sistemas de decisão, não como entregáveis isolados.
Essa arquitetura combina algumas camadas:
- Dados com rastreabilidade, qualidade, versionamento e integração com fontes internas e externas.
- Modelos estatísticos, machine learning, modelos bayesianos, otimização, simulação, regras de negócio ou modelos causais, conforme o problema.
- Validação com diagnósticos, backtesting, calibração, análise de sensibilidade, testes de robustez e critérios mínimos de aceitação.
- Camada agentic para interpretar perguntas, selecionar rotinas analíticas, executar simulações, comparar cenários e organizar explicações.
- Governança para registrar dados usados, versão do modelo, parâmetros, premissas, código executado, usuário, cenário e resposta produzida.
Essa arquitetura não elimina dashboards. Ela muda o papel deles. O dashboard passa a ser uma das interfaces possíveis, não necessariamente o núcleo da solução.
O papel do cientista de dados muda
A adoção de agentes analíticos não elimina o trabalho técnico. Em muitos casos, aumenta a exigência sobre ele.
O cientista de dados deixa de ser apenas responsável por produzir análises sob demanda e passa a desenhar o ambiente dentro do qual o agente pode operar. Isso inclui definir quais perguntas o sistema pode responder, quais modelos podem ser acionados, quais diagnósticos são obrigatórios, quais respostas devem ser bloqueadas e quais situações exigem revisão humana.
O trabalho se desloca da produção manual de análises para a engenharia de um ambiente analítico controlado.
Conclusão
A evolução natural dos projetos de ciência de dados não deveria ser apenas construir dashboards mais interativos. O passo relevante é construir sistemas que ajudem usuários a formular perguntas, executar modelos, comparar cenários, avaliar incerteza e registrar decisões.
Isso exige integração entre modelagem, engenharia de dados, agentes, validação estatística e governança.
O dashboard continua útil para acompanhamento e comunicação. Mas modelos analíticos usados em decisões recorrentes precisam de uma camada operacional mais rica.
Em decisões empresariais, a pergunta raramente é apenas “qual é o número?”. A pergunta costuma ser: o que devemos fazer, sob quais premissas, com qual incerteza e com qual risco?
Responder a isso exige mais do que visualização. Exige sistemas analíticos desenhados para decisão.