O conector gerenciado do Lakeflow Connect resolve a ingestão: issues, comentários e worklogs do Jira chegam ao Databricks como tabelas Delta. Mas ingerido não é pronto. Na arquitetura medalhão, que a própria Databricks documenta como padrão do Lakehouse, o conector entrega a camada bronze: dado bruto, no formato original da fonte. A IA consome a camada ouro: dado validado, reconciliado e enriquecido com as features que o caso de uso exige. Entre as duas existe a camada prata, onde o dado do Jira é limpo, deduplicado e unificado numa visão de empresa. Esse percurso bronze-prata-ouro é o trabalho real de uma consultoria de dados para IA, e é a parte do orçamento que a maioria dos projetos descobre depois que o piloto respondeu errado com confiança.

A ilusão do conector: por que o piloto de IA responde errado

A sequência é sedutora. O conector oficial existe, a ingestão roda em dias, as tabelas aparecem no catálogo. O time aponta um modelo para o dado e monta o piloto: um agente que responde sobre projetos, uma previsão de atraso, um resumo executivo automático. E o piloto responde. Errado, mas com fluência. Diz que o projeto X está em dia usando um status que aquele time abandonou há dois anos.

Soma horas de worklogs duplicados. Trata “Concluído”, “Done” e “Finalizado” como três coisas diferentes, porque na origem são três status diferentes.

Nada disso é defeito do modelo nem do conector. É a consequência de apontar IA para dado bronze. O conector é fiel por design: ele traz o Jira como o Jira é, com dez anos de decisões de configuração, vocabulários divergentes entre times e campos preenchidos por obrigação. A fidelidade que torna o bronze valioso como arquivo histórico é exatamente o que o torna perigoso como fonte direta de IA.

A tese deste guia: o conector encurta a ingestão, não a preparação. Entre o dado bruto do Jira e o dado que um agente pode consumir com segurança existe um trabalho de curadoria com nome, método e camadas definidas: a arquitetura medalhão. Orçar projeto de IA sem orçar essa curadoria é orçar a ponte sem o vão central.

A arquitetura medalhão aplicada ao dado do Jira

A Databricks documenta o medalhão como o padrão de organização do Lakehouse: bronze é o dado bruto como chegou da fonte, preservado para linhagem, auditoria e reprocessamento; prata é o dado validado, deduplicado e conformado numa visão de empresa; ouro é o dado enriquecido, com agregados e features prontos para analytics e machine learning. Aplicado ao Jira, cada camada tem cara e trabalho específicos:

A camada prata é onde o projeto ganha ou perde

O bronze é barato e o ouro é consequência. A prata é onde mora a dificuldade, porque é onde decisões de negócio se disfarçam de tarefas técnicas. Três exemplos concretos do dado do Jira:

•     Reconciliação de vocabulário. Dez times, dez workflows, trinta nomes de status. A prata precisa de um mapa único (o que conta como “em andamento”, o que conta como “concluído”), e esse mapa não é decisão de engenheiro de dados: é decisão de operação, que alguém com autoridade precisa assinar.

•     Reconstrução de linha do tempo. A análise de fluxo e a previsão dependem de quanto tempo cada item passou em cada estado, e isso se reconstrói do changelog, transição a transição. Itens que pularam etapas, voltaram de estado ou foram movidos entre projetos criam casos de borda que a regra precisa tratar explicitamente.

•     Quarentena do dado preenchido por obrigação. Campo obrigatório preenchido com lixo parece válido para o pipeline. A prata precisa de regras que detectem o padrão (valores repetidos, texto genérico, datas impossíveis) e separem o registro para revisão em vez de deixá-lo contaminar o ouro.

É por isso que a curadoria não é tarefa que se delega ao estagiário do pipeline. Cada regra da prata é uma decisão sobre o que a empresa considera verdade, e errar essas decisões produz um ouro consistente, governado e errado.

O que a IA consome de cada camada (e por que agente lê ouro)

Na definição da Databricks, a camada ouro contém os agregados de nível de negócio e as features prontas para analytics e machine learning. Para IA generativa e agentes, isso se traduz em dois tipos de ativo: tabelas de features com métricas de definição única (o cycle time que o agente cita é o mesmo que o dashboard mostra), e conjuntos de contexto curados, em que descrições e comentários relevantes foram selecionados, limpos de ruído e associados às entidades certas. Tudo governado pelo Unity Catalog, que garante que o agente só acessa o que suas permissões permitem, com linhagem do dado bruto até a resposta.

Apontar o agente para o bronze economiza semanas de curadoria e cobra o preço em cada resposta: o modelo não distingue o status abandonado do vigente, nem o comentário de decisão do comentário de ruído. A fluência do modelo esconde a fragilidade do dado, e é exatamente essa combinação que faz o piloto errado parecer pronto.

O que a origem bem configurada economiza (a ponta Jira da conta)

Há um limite para o que a prata conserta: ela reconcilia o que foi registrado de formas diferentes, mas não inventa o que nunca foi registrado. Se o time não aponta worklog, nenhuma camada cria as horas. Se o workflow não distingue “em fila” de “em trabalho”, a linha do tempo reconstruída mistura espera com execução, e a previsão herda a mistura.

O padrão que fecha a conta: cada problema resolvido na origem (workflow que reflete o processo, campos com dado real, vocabulário minimamente convergente entre times) é uma regra a menos na prata e um risco a menos no ouro. A consultoria Jira e a consultoria de dados para IA não são serviços vizinhos: são as duas pontas do mesmo custo. A CSP Tech, parceira Atlassian Gold e parceira Databricks, dimensiona as duas pontas juntas, o que costuma reduzir o total, porque arrumar na origem é mais barato do que compensar na curadoria.

Quando essa curadoria completa é exagero

•     POC de escopo fechado. Um experimento com dois projetos e um caso de uso pode rodar com curadoria mínima e disclaimer explícito. O erro não é o atalho, é promover o atalho a produção sem pagar a conta da prata.

•     Caso de uso só descritivo. Se a necessidade é dashboard executivo, o caminho Jira para Power BI com modelo semântico resolve com menos camadas e menos custo. Medalhão completo é para quando cruzamento, previsão ou agente estão no plano.

•     Origem em estado crítico. Se o Jira está caótico, começar pela curadoria no destino é enxugar gelo. A ordem que reduz custo total é higiene na origem primeiro, curadoria depois.

Perguntas frequentes

O conector do Lakeflow Connect não entrega o dado pronto?

Ele entrega o dado ingerido, o que na arquitetura medalhão corresponde à camada bronze: o Jira como ele é, preservado com fidelidade. Pronto para IA é a camada ouro, que exige validação, reconciliação e enriquecimento nas camadas intermediárias, conforme a documentação da própria Databricks sobre o padrão medalhão.

O que é a arquitetura medalhão?

É o padrão de organização de dados do Lakehouse documentado pela Databricks: bronze guarda o dado bruto como chegou da fonte, prata guarda o dado validado, deduplicado e conformado numa visão de empresa, e ouro guarda o dado enriquecido com agregados e features prontos para analytics e machine learning. O dado melhora de qualidade a cada camada que atravessa.

Por que o agente de IA não pode ler o dado bruto do Jira?

Porque o bruto carrega as inconsistências da origem: status abandonados, vocabulários divergentes entre times, worklogs duplicados, campos preenchidos por obrigação. O modelo não distingue o vigente do obsoleto e responde com fluência sobre dado frágil, o que produz erro com aparência de certeza. Agente confiável consome dado curado e governado, com definição única de métrica e permissões via Unity Catalog.

Quanto do trabalho é curadoria e quanto é ingestão?

A ingestão, com o conector gerenciado, é a parte curta do projeto. A curadoria (prata e ouro) domina o esforço porque envolve decisões de negócio disfarçadas de tarefas técnicas: o mapa de vocabulário, as regras de qualidade, a definição única de cada métrica. A proporção exata depende do estado da origem, e é o que um diagnóstico de prontidão mede antes de orçar.

Próximo passo

Se o seu plano de IA sobre dados do Jira tem orçamento para o conector e para o modelo, mas não tem linha para a curadoria, o plano está sem o vão central da ponte. Solicite um diagnóstico de prontidão de dados para IA com a CSP Tech e receba o mapa das duas pontas: o que arrumar na origem Jira e o que construir nas camadas prata e ouro antes de o primeiro agente responder.

Autor: Guilherme Matos, estrategista de conteúdo e IA, certificado HubSpot, Google e Anthropic. Revisão técnica por especialistas Atlassian e de dados da CSP Tech (Atlassian Gold Partner, parceira Databricks, Microsoft Gold Partner, 34 anos de mercado, produto próprio Power BI for Jira no Atlassian Marketplace, participante do Anthropic Partner Network).

Fontes (oficiais, acesso jul/2026): Databricks Documentation, “What is the medallion lakehouse architecture?” (docs.databricks.com/lakehouse/medallion); Databricks, glossário “What is Medallion Architecture?” (databricks.com); Databricks Documentation, conector Jira do Lakeflow Connect e Unity Catalog (docs.databricks.com/ingestion/lakeflow-connect, verificados na peça-irmã deste cluster); Atlassian Developer, REST API e changelog (developer.atlassian.com).

Links internos sugeridos: spokes “Dados do Jira no Databricks” (quando levar e como ingerir), “Databricks Lakehouse e IA generativa” (a arquitetura de modelo), “Governança de dados antes da IA” (a ordem conceitual), “Jira mal implementado” (a ponta da origem), “Consultoria Jira, BI e Databricks” (o modelo de contratação).