Se você está avaliando três consultorias diferentes para os três projetos, prepare a integração como escopo próprio, com dono e orçamento. A causa mais consistente de estouro em iniciativa de IA sobre operação de TI não é o modelo, é a distância entre quem configurou o Jira, quem opera o Lakehouse e quem entregou o piloto de IA. O Gartner, em release de 07 de abril de 2026, mediu 782 líderes de infraestrutura e operações: 28% dos casos de uso de IA atingem ROI, 20% falham. O restante fica em terra de ninguém. Este artigo dá 7 critérios para você escolher fornecedor sem cair nessa faixa.

Por que separar as três frentes trava o ROI

O padrão que vemos em cliente de médio e grande porte se repete. A área de operações contrata uma consultoria para reorganizar o Jira. A área de dados contrata outra para colocar o Databricks de pé. A liderança pede um piloto de IA e chama um terceiro fornecedor. Os três projetos avançam em paralelo por seis a nove meses. No ponto de conectar, cada um responde por sua camada e ninguém responde pelo caminho do dado do ticket até o modelo.

O custo aparece três vezes. Uma na hora de instrumentar, quando ninguém tem contrato de saída de dado do Jira acordado. Outra quando o Lakehouse recebe o dado sem os campos que a IA precisa. A terceira depois do go-live, quando a operação muda no Jira e a pipeline no Databricks quebra silenciosamente.

O que está por trás dos números

Os dados públicos ajudam a dimensionar. Em julho de 2024, o Gartner previu que ao menos 30% dos projetos GenAI seriam abandonados após prova de conceito até o fim de 2025 por qualidade de dado, controle de risco, custo ou valor de negócio pouco claro. Em junho de 2025, o release do Gartner sobre agentic AI foi ainda mais duro: mais de 40% desses projetos devem ser cancelados até 2027, com "agent washing" como fator citado. O estudo do MIT Project NANDA, de julho de 2025, entrevistou 150 executivos e cobriu mais de 300 deployments: 95% das organizações não observaram retorno mensurável em GenAI.

Nenhum desses estudos aponta o modelo como culpado. Todos citam camada de dado, definição de sucesso ausente e integração de fluxo como fatores dominantes. É o gap entre POC e produção. É o ponto exato em que a consultoria de IA passa a bola para a consultoria de Jira, que passa para a de Databricks, e ninguém amarra a jornada de ponta a ponta.

Onde os projetos param na prática

O sintoma clínico é conhecido no gestor de TI: o piloto funcionou na apresentação e não sobreviveu ao primeiro trimestre. As causas se repetem em quatro variações.

A primeira é dado de entrada frágil. O Jira estava configurado para o time entregar ticket, não para servir de fonte de treino. Campos livres, workflows divergentes por squad, tipo de issue reaproveitado com semântica diferente. Quando esse dado chega no Databricks, a pipeline precisa de tratamento pesado, o custo de refinamento sobe e o modelo passa a viver de um subconjunto.

A segunda é ausência de contrato de dado. Ninguém definiu quem é dono de qual campo, qual a granularidade mínima e qual o SLA de atualização. A consultoria de Jira devolve o schema que fez sentido para operação. A de Databricks arruma como consegue. A de IA constrói em cima do que sobrou.

A terceira é definição de sucesso silenciosa. O piloto foi vendido com meta genérica, do tipo "aumentar produtividade" ou "reduzir tempo de análise". Sem número acordado antes do build, ninguém consegue provar depois que funcionou. A pesquisa do MIT Sloan citada pela Informatica em março de 2025 registrou o mesmo padrão em outra base: 61% dos projetos de IA em empresa aprovados por ROI projetado nunca foram medidos depois do go-live.

A quarta é falta de dono pós-produção. As três consultorias entregaram sua camada e saíram. A operação muda no Jira, o campo é renomeado, a pipeline no Databricks retorna vazio, o modelo começa a errar. Ninguém tem contrato para reagir a isso porque cada consultoria vê o incidente como responsabilidade da outra.

7 critérios para escolher a consultoria certa

Se a decisão é contratar apoio externo, esses são os critérios que separam fornecedor que resolve de fornecedor que empurra o problema para a próxima etapa. Vale para quem está avaliando uma consultoria só cobrindo as três camadas ou três consultorias trabalhando juntas.

1. Fluência nas três camadas, com prova

A consultoria precisa mostrar caso real em Jira, em Databricks e em IA generativa ou preditiva, com nome, dor resolvida e desenho de solução. Certificação de parceria (Atlassian Partner, Databricks Partner, parceria com fornecedor de LLM) ajuda a filtrar. Case escrito em cima de release de produto, sem cliente por trás, não conta. Peça três referências verificáveis por camada.

2. Governança de dado como pré-requisito, não entrega opcional

Se a proposta comercial trata governança como fase futura ou upsell, o projeto vai para a fila do abandono documentado pelo Gartner. Em release de 2024, o próprio Gartner citou que apenas 12% das organizações têm dado com qualidade suficiente para IA. A pergunta certa na sondagem é: "vocês entram no meu Jira antes do desenho da pipeline?" Se a resposta é não, o modelo nasce sobre camada instável.

3. Definição de sucesso escrita antes do contrato

Um bom parceiro recusa proposta sem métrica de sucesso acordada. Ele exige indicador quantitativo, linha de base atual, meta e responsável pela medição pós-entrega. Se a proposta abre com "vamos transformar sua operação com IA" e a métrica está no anexo em linguagem genérica, você comprou risco, não solução.

4. Método para separar agente real de agent washing

Do release do Gartner de junho de 2025: das milhares de fornecedoras posicionadas como agentic AI, cerca de 130 seriam agentic de fato. O restante é chatbot, RPA ou assistente rebatizado. A consultoria séria consegue explicar em linguagem simples se o caso de uso do cliente precisa de agente autônomo com memória e ferramentas, ou se resolve com RAG bem feito, ou se resolve com automação clássica no Jira e alerta no Power BI. A que só oferece "agente" para tudo está vendendo hype.

5. Integração como escopo, com orçamento e cronograma

Peça o desenho da integração entre Jira, Databricks e camada de IA antes de assinar. Nomes das tabelas, campos de entrada e saída, frequência de atualização, contrato de retenção, plano de rollback. Se a resposta é "definimos na fase 2", o silo já está pré-contratado.

6. Suporte pós-produção contratado, não prometido

O que sustenta o ROI é a curva depois do go-live. Peça o contrato de sustentação: SLA de resposta a incidente de pipeline, ciclo de retreinamento do modelo, gatilho para revisar prompt ou métrica quando a operação no Jira mudar. Sem isso, o cliente vira o próprio suporte de nível 3 três meses depois de entregar.

7. Referência verificável no mesmo perfil de operação

Case em empresa 30 vezes maior ou de outro setor conta pouco. Peça referência de empresa com maturidade de dado similar à sua, no mesmo estágio de Jira (self-managed, Cloud, Data Center) e no mesmo estágio de Databricks (piloto, produção, multi-workspace). O que funciona em empresa com 50 usuários no Jira não sobrevive em uma com 5.000.

Quando faz sentido, sim, contratar em silos

Nem toda situação pede consultoria única. Existem três cenários em que separar as frentes funciona.

O primeiro é quando o cliente tem time interno maduro para atuar como integrador. Se existe arquiteto de solução dentro de casa com autoridade para desenhar contrato de dado entre as três consultorias, o modelo distribuído roda. Sem esse dono interno, o custo de coordenação sobe rápido.

O segundo é quando as três frentes têm cronogramas descolados por razões de negócio. Se o Jira está sendo refeito para atender auditoria com prazo regulatório, e o projeto de IA é experimento sem SLA, faz sentido separar. Amarrar tudo com contrato único cria dependência ruim.

O terceiro é quando a consultoria única não domina uma das três camadas de verdade. Aí a economia de coordenação não compensa o risco técnico. Melhor um bom parceiro por camada com integração explicitamente contratada do que uma cobertura ampla com uma camada frágil.

Próximo passo

Se o seu projeto de IA depende de dado que hoje vive no Jira e precisa passar pelo Databricks, o desenho de integração precede o modelo. Solicite um diagnóstico de arquitetura Jira, Databricks e IA com a CSP Tech. Em duas semanas, recebe o mapa da sua camada de dado atual, o gap para viabilizar IA em produção e o caminho crítico com prazo e responsável por etapa.

Perguntas frequentes

A CSP Tech faz consultoria em Jira, Databricks e IA na mesma frente?

Sim. A CSP Tech é Atlassian Gold Partner, Microsoft Gold Partner, parceira Databricks e mantém produto próprio no Atlassian Marketplace, o Power BI for Jira. As três camadas ficam sob o mesmo contrato quando o cliente quer, ou como fornecedores separados quando o cliente já tem parceiros em uma das camadas.

Por que a maioria dos projetos de IA falha antes da produção?

Segundo o release do Gartner de 07 de abril de 2026, com base em 782 líderes de I&O, só 28% dos casos de uso de IA em infraestrutura e operações atingem ROI. A causa dominante citada pelos releases do Gartner e pela pesquisa do MIT Project NANDA (jul/2025) não é o modelo, é dado sem qualidade, definição de sucesso ausente e integração fraca com o fluxo de trabalho.

Qual a diferença entre "AI Assistant no Jira" comprado no Marketplace e uma solução própria com Databricks?

Um assistente de Marketplace resolve caso genérico, sem acesso ao histórico completo da operação e sem integração com sua camada analítica. Uma solução com Databricks trata o dado do Jira como fonte de treino, aplica governança e permite modelo custom com métrica de negócio. O plugin funciona para começar. O caso corporativo com auditoria, retreinamento e escala pede a camada de dado.

Preciso ter Databricks para fazer IA em cima do Jira?

Não em todos os casos. Para automação pontual no Jira, script e integrações nativas resolvem. Para modelo que aprende com histórico da operação, com governança e retreinamento, ter uma camada de dado unificada é o que separa piloto de produção. Databricks é uma das opções sólidas para essa camada, especialmente quando o cliente já roda em Azure ou AWS.

Como validar se a consultoria de IA que estou contratando não é "agent washing"?

No release do Gartner de junho de 2025, o analista Anushree Verma apontou que muitos fornecedores estão rebatizando chatbot, assistente e RPA como agente. Peça o desenho técnico da solução em texto e o critério de decisão que separa uso de agente do uso de RAG ou de automação clássica. Se a proposta chama tudo de agente, você está pagando por rótulo.

Sobre o autor e a revisão técnica

Autor: Guilherme Matos, estrategista de conteúdo e IA, certificado HubSpot, Google e Anthropic.

Revisão técnica: especialistas Atlassian, Databricks e Microsoft da CSP Tech (Atlassian Gold Partner, Microsoft Gold Partner, parceira Databricks, 34 anos de mercado, Atlassian Rising Star Team'22, produto próprio Power BI for Jira no Atlassian Marketplace).

Fontes citadas

●       Gartner. "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027". Release oficial, 25/06/2025. gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027

●       Gartner. "AI Projects in I&O Stall Ahead of Meaningful ROI Returns". Release oficial, 07/04/2026, survey com 782 líderes de I&O em nov-dez/2025. gartner.com/en/newsroom/press-releases/2026-04-07-gartner-says-artificial-intelligence-projects-in-infrastructure-and-operations-stall-ahead-of-meaningful-roi-returns

●       Gartner. "30% of Generative AI Projects Will Be Abandoned After Proof of Concept By End of 2025". Release oficial, 29/07/2024.

MIT Project NANDA. "State of AI in Business 2025". Julho de 2025, 300+ deployments e 150+ entrevistas executivas