Início / Databricks

Desvendando o poder do Genie One: quando a pergunta de negócio deixa de virar chamado

Vithor Silva
Vithor Silva
4 set 2026 · 10 min de leitura
Databricks

No dia 4 de setembro de 2026, o ES Databricks User Group se reuniu para discutir uma pergunta que aparece em praticamente toda empresa orientada por dados: como fazer uma pessoa de negócio chegar à resposta sem transformar cada dúvida em um novo chamado para o time de dados?

O tema do encontro foi o Genie One, a experiência simplificada da Databricks para usuários de negócio. Mais do que apresentar uma nova interface, a conversa mostrou uma mudança de perspectiva: o dado deixa de ser apenas algo que o analista consulta e passa a fazer parte do fluxo de trabalho de toda a organização.

Da pergunta à fila

Uma pergunta simples costuma percorrer um caminho longo: nasce em uma reunião, vira chamado, entra na fila do time de dados, espera a construção de um dashboard e, quando finalmente chega, talvez já não responda mais ao problema original.

O gargalo, portanto, nem sempre está no volume ou na qualidade do dado. Muitas vezes, ele está na distância entre quem precisa decidir e quem consegue traduzir a pergunta para uma consulta confiável.

O Genie One tenta encurtar esse caminho. A proposta é oferecer um ponto de entrada único para que usuários de negócio interajam com dados e inteligência artificial sem precisar navegar por conceitos como compute, queries, modelos ou notebooks.

O que é o Genie One?

O Genie One é a interface voltada para usuários de negócio dentro da família Genie. A partir de uma conversa em linguagem natural, a pessoa pode explorar dashboards, queries, Genie Agents, dados governados e fontes externas conectadas.

Na prática, a experiência combina três movimentos:

  • Perguntar: formular uma dúvida com a linguagem do negócio;
  • Confiar: receber uma resposta apoiada pelo contexto e pelas permissões da organização;
  • Agir: transformar o resultado em um documento, uma tarefa, um agente ou uma atualização compartilhável.

Essa evolução é importante porque uma resposta isolada raramente é o fim do trabalho. Normalmente ela é o começo de uma conversa: “qual região cresceu?”, “por que as vendas caíram?” e, em seguida, “o que devemos fazer a respeito?”.

Uma casa para o usuário de negócio

Durante o encontro, a tela inicial foi apresentada como uma espécie de casa para quem precisa trabalhar com dados, mas não quer começar por um catálogo técnico.

O usuário encontra uma caixa de pergunta, sugestões prontas, histórico de conversas, agentes, itens salvos, tarefas agendadas e uma área de descoberta. A navegação parte de contextos de negócio, e não de schemas, tabelas e configurações de infraestrutura.

Essa diferença de experiência é parte central da proposta. A plataforma precisa esconder a complexidade operacional sem esconder a origem da resposta.

Descobrir dados por contexto

O recurso Discover foi mostrado como um marketplace interno de dados e IA. Em vez de depender de uma busca solta por nomes técnicos, a pessoa navega por áreas e domínios de negócio, encontrando recomendações, ativos certificados, itens populares e conteúdos em alta.

Página Discover com recomendações de dados e IA

Uma experiência desse tipo só funciona quando a organização cuida do contexto dos ativos. Um dashboard sem descrição, uma tabela sem dono e uma métrica com várias definições concorrentes continuam sendo difíceis de usar, independentemente da qualidade da interface.

Perguntar à empresa, não apenas ao banco

Outro ponto discutido foi a capacidade de combinar diferentes fontes de contexto. O usuário pode interagir com dados governados na Databricks e, conforme as conexões habilitadas, consultar informações presentes em ferramentas como Google Calendar, Atlassian, Glean, GitHub, Microsoft 365 e Slack, além de anexar arquivos à própria pergunta.

O resultado esperado é ampliar o escopo da conversa. A pergunta deixa de ser apenas “o que está no meu banco de dados?” e passa a ser “o que está acontecendo na minha empresa?”.

Essa ampliação não significa liberar tudo para todos. O alcance continua condicionado às conexões, permissões e políticas de governança configuradas pela organização.

Genie Ontology: o contexto que dá significado

A parte mais importante para entender por que o Genie One não é simplesmente “um chatbot conectado ao banco” é a Genie Ontology.

Ela funciona como uma camada de contexto que reúne o vocabulário, as entidades, os relacionamentos e os indicadores do negócio. Parte desse conhecimento é inferida automaticamente a partir dos dados e dos ativos existentes; outra parte é definida, curada e governada pela equipe.

Essa combinação cria um ciclo de melhoria:

  1. O sistema infere padrões e termos a partir do ambiente;
  2. O time responsável pelo domínio corrige ambiguidades e certifica definições;
  3. As respostas passam a usar um contexto mais próximo da linguagem real da organização;
  4. O aprendizado pode beneficiar diferentes experiências, como Genie One, Genie Agents e Genie Code.

O princípio apresentado no evento pode ser resumido assim: modele a cabeça e deixe a ontologia inferir a cauda. Em outras palavras, vale a pena investir primeiro nos conceitos críticos, nos KPIs importantes e nos termos que geram mais confusão. Não é necessário descrever manualmente cada detalhe antes de começar.

Domains e Unity Catalog Semantics

Os Domains ajudam a organizar esse contexto por áreas de negócio, unidades ou geografias. Dentro deles, a equipe pode estruturar subdomínios, criar páginas, orientar a descoberta e certificar o que deve ser tratado como fonte confiável.

Criação de domínios e subdomínios no Unity Catalog

Esse trabalho vive no ecossistema do Unity Catalog Semantics, que concentra definições e relações que precisam ser compartilhadas por pessoas e agentes. Uma definição de receita, por exemplo, não deveria existir apenas na cabeça de uma pessoa ou em uma instrução escondida em um prompt.

A organização do dado para seres humanos também melhora a capacidade de interpretação dos agentes. Quando a empresa define seus termos, métricas, relações e ativos confiáveis, ela reduz a ambiguidade disponível para a IA.

Confiança não é fé

Uma das preocupações mais comuns ao usar IA para análise é direta: e se o sistema inventar?

O caminho apresentado no encontro foi tratar confiança como uma propriedade do sistema, e não como uma promessa do modelo. Alguns elementos são fundamentais:

  • Contexto de negócio: a ontologia ancora a resposta em definições conhecidas;
  • Escopo: Genie Agents podem ser criados para domínios e casos específicos;
  • Governança: o Unity Catalog e as permissões das fontes continuam valendo;
  • Verificação: o SQL gerado e as fontes usadas podem ser inspecionados;
  • Avaliação: perguntas reais e respostas esperadas permitem medir a qualidade.

Isso não elimina todos os erros. Uma pergunta ambígua em um domínio mal modelado ainda pode produzir uma resposta ruim. A diferença é que o erro deixa de ser um mistério: ele pode apontar para uma definição, uma métrica, um ativo ou um agente que precisa ser corrigido.

Onde corrigir quando a resposta falha?

Uma recomendação prática discutida no evento foi evitar corrigir tudo no prompt. A pergunta pode ter revelado um problema em outra camada:

  • definição de negócio ou sinônimo incorreto: revisar uma Page;
  • medida, dimensão, relacionamento ou cálculo: revisar uma Metric View;
  • ativo obsoleto, aberto demais ou sem contexto: revisar o Unity Catalog;
  • problema restrito a um caso de uso: ajustar o Genie Agent.

Essa abordagem é importante porque a correção feita no lugar certo beneficia as próximas perguntas e todos os usuários daquele domínio, em vez de funcionar apenas para uma conversa específica.

Da conversa ao agente

Uma conversa que funcionou bem não precisa morrer no histórico. Ela pode virar uma skill ou um agente reutilizável pela equipe.

Uma conversa sendo transformada em um Genie Agent

Esse é um caminho interessante para adoção: o próprio usuário de negócio ajuda a revelar quais perguntas importam, quais termos são ambíguos e quais fluxos se repetem. O time técnico entra para governar, refinar e publicar uma experiência consistente.

O agente passa a ter escopo, instruções e guardrails próprios, sem perder a possibilidade de consultar fontes autorizadas e apresentar o caminho percorrido até a resposta.

Da resposta ao documento

O terceiro movimento é transformar a conversa em um artefato que circule pela empresa. O Genie One pode gerar documentos editáveis a partir do chat, incluindo tabelas, gráficos e as fontes citadas.

Documento editável gerado a partir de uma conversa no Genie One

Isso aproxima a análise do trabalho cotidiano. Em vez de copiar uma resposta para um e-mail ou começar um documento do zero, o usuário pode partir da investigação já realizada, revisar o resultado e compartilhar o material com outras pessoas.

As respostas também podem alimentar tarefas agendadas e chegar a canais que a equipe já utiliza, como Slack, Teams e dispositivos móveis, conforme a configuração disponível no ambiente.

Um caminho de maturidade

O Genie pode funcionar desde o primeiro dia com uma base simples, mas a qualidade tende a aumentar à medida que a organização estrutura seu contexto. O caminho apresentado no encontro pode ser organizado em seis camadas:

  1. Fundação de dados: modelos coerentes, entidades bem definidas e uma camada gold orientada ao negócio;
  2. Metadados: descrições de tabelas e colunas, tags e documentação no Unity Catalog;
  3. Semântica: relacionamentos, Metric Views, Domains e Pages;
  4. Ativos com contexto: dashboards, queries e agentes documentados e certificados;
  5. Governança: Unity Catalog, RLS/CLS, políticas por tag e Unity AI Gateway;
  6. Avaliação: perguntas de referência, benchmarks e monitoramento contínuo.

Essas camadas não precisam ser tratadas como pré-requisitos para começar. Elas formam uma trajetória de melhoria contínua. O piloto pode nascer pequeno e evoluir conforme a empresa aprende quais perguntas são mais frequentes e quais conceitos exigem curadoria.

Como começar um primeiro piloto

Em vez de começar pelo conjunto de dados mais extenso, a recomendação é começar por um domínio com dono claro e perguntas reais.

Uma receita inicial pode incluir:

  • um domínio de negócio bem delimitado;
  • poucas tabelas, mas com modelagem consistente;
  • 20 a 30 perguntas coletadas antes da construção;
  • um glossário com os termos mais ambíguos;
  • um conjunto de respostas esperadas para avaliar o agente;
  • uma rotina de revisão com as pessoas que realmente usam aquelas informações.

O ponto de partida não é o dado que a empresa tem disponível. É a pergunta que alguém já fez e que ainda demora demais para ser respondida.

Medir o resultado em 30 dias

O valor do piloto precisa aparecer em indicadores simples. Três métricas são suficientes para a primeira revisão:

  1. taxa de acerto nas perguntas-piloto;
  2. número de chamados que deixaram de existir;
  3. tempo médio entre a pergunta e a resposta.

Esses números ajudam a evitar uma avaliação baseada apenas em entusiasmo. O objetivo não é provar que a IA é impressionante, mas verificar se ela encurta o caminho entre informação e decisão sem comprometer a confiança.

O que fica do encontro

O Genie One representa uma mudança de interface, mas seu impacto depende de algo mais profundo: contexto, governança e participação das áreas de negócio.

Os três recados principais do evento foram:

  • a fila entre pergunta e resposta é opcional;
  • a qualidade vem da curadoria, não apenas do modelo;
  • o melhor caminho é começar por um domínio, medir e expandir.

Quando esses elementos estão presentes, a IA deixa de ser uma demonstração isolada e passa a funcionar como uma colega de trabalho: alguém que ajuda a encontrar o dado, explicar o resultado, produzir um artefato e levar a análise para o próximo passo.

Referências

Esta página foi útil?
Comentários
Buscar