Equipes de segurança da Databricks e do Google enfrentam uma nova escolha na defesa com IA

A Databricks lançou um novo guia de segurança estruturado em torno de um conflito: a IA pode acelerar a defesa, mas apenas quando as equipes confiam nos dados e na automação que a sustentam. Para organizações que avaliam implementações da Databricks no Google, a proposta vai além da análise de dados. A Databricks quer que o lakehouse se torne uma camada operacional para dados de segurança, investigações, engenharia de detecção e resposta assistida por IA.

O guia surge no momento em que as equipes de segurança reavaliam o sistema de gerenciamento de informações e eventos de segurança, ou SIEM, que tradicionalmente centraliza logs e alertas. A Databricks argumenta que telemetria fragmentada, retenção cara e fluxos de trabalho desconectados impedem os defensores de usar a IA de forma eficaz. Sua resposta proposta coloca os dados empresariais governados no centro e permite que analistas e agentes de IA trabalhem nesse contexto compartilhado.

Essa posição coloca a Databricks em disputa com mais do que fornecedores estabelecidos de SIEM. Ela questiona a ideia de que os dados de segurança precisam permanecer dentro de uma plataforma especializada. Google Security Operations, Microsoft Sentinel, Splunk, CrowdStrike e outros fornecedores também estão adicionando investigação e resposta orientadas por IA. A disputa está se tornando uma escolha entre uma suíte de segurança integrada e uma plataforma de dados mais ampla adaptada para a defesa.

O que a Databricks realmente colocou em pauta

O anúncio é um plano estratégico para operações de segurança, não uma referência de produto validada de forma independente.

A Databricks publicou seu ebook sobre liderança em segurança em 2 de setembro de 2026. O guia apresenta uma arquitetura de dados unificada como base para a defesa cibernética moderna. Seu argumento central é que as organizações não podem implementar agentes de segurança confiáveis enquanto seus logs, identidades, alertas e contexto de negócios permanecerem separados.

A empresa descreve três mudanças conectadas. As equipes de segurança devem consolidar mais telemetria, tornar a análise acessível além dos grupos especializados de engenharia e introduzir agentes de IA em fluxos de trabalho governados. Essa abordagem transforma o lakehouse em mais do que armazenamento de longo prazo. Ele passa a ser um local para detecção, investigação, enriquecimento e atividades selecionadas de resposta.

O guia de liderança em segurança destaca diversos números de clientes e do setor. A Databricks afirma que 72% dos executivos de segurança entrevistados têm dificuldades com dados em silos. Ela também menciona a Arctic Wolf, que processa oito trilhões de eventos de segurança por semana.

O guia afirma que a Rivian reduziu em 60% os custos relacionados a SIEM após modernizar sua arquitetura de dados de segurança. Outro exemplo diz que as equipes implementaram regras de detecção de cinco a seis vezes mais rápido. Esses números ilustram o argumento da empresa, mas exigem interpretação cuidadosa.

A Databricks não apresenta todos os números como uma comparação controlada entre ambientes de segurança equivalentes. A composição das cargas de trabalho, as políticas de retenção, o quadro de pessoal, o volume de dados e os contratos vigentes podem afetar substancialmente o resultado. Uma implementação bem-sucedida para um cliente não estabelece uma taxa universal de economia.

O sinal mais útil é o padrão por trás dos exemplos. As equipes de segurança querem retenção mais longa, telemetria mais ampla e acesso mais rápido a dados contextuais. A economia tradicional de SIEM pode pressioná-las a filtrar informações antes da ingestão ou transferir logs mais antigos para armazenamento separado.

Essa divisão cria atrito operacional. Um analista que investiga um acesso suspeito pode precisar de alertas de endpoint, histórico de identidade, registros de auditoria em nuvem, propriedade de ativos e atividade de aplicações. Se esses registros estiverem distribuídos por diversos sistemas, uma investigação automatizada herdará as mesmas lacunas.

Um lakehouse altera a fronteira entre armazenamento e análise. Ele pode reter registros estruturados junto a informações menos padronizadas, ao mesmo tempo em que oferece suporte a SQL, Python, aprendizado de máquina e compartilhamento de dados governado. A Databricks chama essa arquitetura de uma plataforma unificada para dados, análises e IA.

A empresa também promove o Agent Bricks, seu ambiente para criar agentes de IA específicos para domínios. Em operações de segurança, um agente pode resumir alertas relacionados, recuperar atividades históricas ou ajudar a redigir lógica de detecção. O agente ainda depende de permissões, contexto confiável e um caminho de aprovação definido.

Essa distinção é importante. O guia não demonstra que agentes de IA podem substituir analistas de segurança com segurança. Ele mostra como a Databricks quer que as organizações preparem seus dados e sua governança para maior automação.

Essa é uma afirmação mais limitada, mas também mais consequente. Se as empresas aceitarem a premissa, as decisões de arquitetura de segurança se aproximam da equipe responsável pela plataforma de dados. A aquisição de SIEM passa a ser, em parte, uma questão de formatos de armazenamento, catálogos, acesso a modelos e contexto empresarial reutilizável.

Por que as implementações da Databricks no Google são importantes agora

A história da Databricks no Google importa porque a defesa com IA agora abrange a plataforma de dados, os controles de nuvem, os sistemas de identidade e os provedores externos de modelos.

A Databricks opera no Google Cloud desde que as empresas anunciaram sua parceria em 2021. A parceria de nuvem original enfatizava análises integradas, aprendizado de máquina, faturamento unificado, suporte a identidades do Google e acesso mais fácil aos dados.

Desde então, as implicações para a segurança se ampliaram. Um workspace da Databricks pode usar armazenamento, rede, identidade, criptografia e serviços de auditoria do Google Cloud. As equipes de segurança também podem analisar telemetria dentro da Databricks sem tratar a própria plataforma como a única fonte de proteção.

As atuais orientações do Google Cloud descrevem a segurança como uma responsabilidade compartilhada entre a Databricks, o cliente e o provedor de nuvem. Esse limite é essencial quando uma organização transfere mais dados de segurança para o lakehouse.

O Google Cloud protege sua infraestrutura subjacente e fornece controles para identidades, redes, armazenamento e criptografia. A Databricks protege sua plataforma gerenciada e oferece recursos no nível do workspace. Os clientes continuam responsáveis por permissões, classificação de dados, isolamento de cargas de trabalho, comportamento de aplicações e muitas escolhas de configuração.

Um conjunto de dados de segurança unificado não elimina esses limites. Ele os torna mais visíveis. As investigações podem correlacionar ações entre sistemas, mas os administradores ainda precisam entender qual controle pertence a qual operador.

Por exemplo, a Databricks no Google Cloud oferece suporte a federação de identidades, login único, conectividade privada, chaves gerenciadas pelo cliente e registro de auditoria em nuvem. Esses controles podem reduzir a exposição quando configurados corretamente. Eles também podem criar pontos cegos quando as equipes presumem que outra parte cobriu o requisito.

A expressão databricks google pode, portanto, descrever várias decisões de compra diferentes. Uma organização pode usar a Databricks para análises e manter o Google Security Operations como seu SIEM principal. Outra pode transferir telemetria histórica para a Databricks. Uma terceira pode criar detecções diretamente sobre dados do lakehouse.

Esses projetos envolvem riscos diferentes. Um repositório secundário de análise não precisa de todos os fluxos de trabalho encontrados em um console de segurança principal. Um sistema que lida com triagem em tempo real, contenção automatizada e evidências regulatórias exige garantias operacionais mais rigorosas.

O Google também está avançando sua própria pilha de segurança e controle de agentes. Seu framework de identidade de agentes de 2026 inclui identidade, gerenciamento de acesso, gateways, proteções e defesa em tempo de execução para software autônomo. Isso se sobrepõe ao problema de governança que a Databricks aborda a partir da camada de dados.

A sobreposição cria tanto cooperação quanto concorrência. A Databricks se beneficia da infraestrutura do Google Cloud e pode atender clientes que já investiram em identidades e armazenamento do Google. No entanto, o Google também vende uma plataforma de operações de segurança que disputa telemetria, atenção de analistas e cargas de trabalho de automação.

Essa tensão não é incomum em software de nuvem. As plataformas frequentemente se integram na camada de infraestrutura enquanto competem mais acima, na pilha de aplicações. Os compradores devem avaliar qual sistema se torna a autoridade para detecções, casos, aprovações de resposta e retenção de evidências.

A arquitetura também afeta a portabilidade. A Databricks enfatiza formatos de dados abertos e operação multicloud. O Google Cloud enfatiza serviços integrados e controles nativos da nuvem. As empresas podem valorizar ambos, mas esses objetivos nem sempre levam ao mesmo projeto.

Um formato de armazenamento aberto pode facilitar a reutilização de registros de segurança. Ele não torna automaticamente portáteis as regras de detecção, os fluxos de incidentes ou os playbooks de automação. Esses ativos de nível mais alto frequentemente dependem de esquemas e APIs proprietários.

Isso deixa os líderes de segurança com uma pergunta mais precisa. Eles não estão escolhendo entre abertura e integração em abstrato. Estão decidindo onde aceitar especialização, onde exigir portabilidade e onde a governança deve permanecer consistente.

A disputa real é a camada de dados versus a suíte de SIEM

A Databricks aposta que o controle dos dados de segurança terá mais importância do que a propriedade do console tradicional do analista.

Um SIEM convencional combina ingestão, normalização, busca, detecção, alertas, investigação e relatórios. Seu valor vem da integração dessas funções em um único fluxo de trabalho voltado à segurança. Sua fragilidade aparece quando o volume de dados cresce mais rápido do que os orçamentos ou a capacidade operacional.

A Databricks aborda o problema pela direção oposta. Ela começa com armazenamento de dados escalável, ferramentas abertas de processamento, governança centralizada e aprendizado de máquina. As funções de segurança são então construídas sobre essa base.

Esse modelo pode ajudar as equipes a preservar a telemetria bruta para investigação posterior. Também oferece suporte a junções entre registros de segurança e contexto de negócios. Um login incomum se torna mais útil quando os analistas conseguem conectá-lo a uma função de funcionário, dispositivo gerenciado, responsável pela aplicação e mudanças recentes de acesso.

A defesa orientada por IA se beneficia desse contexto. Um modelo que recebe apenas o título de um alerta e alguns campos de evento tem evidências limitadas. Um agente governado que pode recuperar histórico autorizado tem maior chance de produzir um resumo útil.

Mais dados não garantem uma resposta melhor. Uma normalização ruim pode gerar identidades contraditórias, eventos duplicados e cronogramas enganosos. As equipes de segurança ainda precisam manter esquemas, verificações de qualidade, linhagem e lógica de detecção.

É aqui que os fornecedores de SIEM mantêm uma vantagem. Eles oferecem conteúdo específico de segurança, interfaces de investigação consolidadas, conectores, gestão de casos e integrações de resposta. Muitos clientes preferem esses recursos prontos em vez de montá-los em uma plataforma de dados de uso geral.

O Google Security Operations oferece análises de segurança em escala de nuvem e inteligência de ameaças em um ambiente operacional dedicado. A Microsoft conecta o Sentinel aos seus produtos de identidade, endpoint, produtividade e nuvem. A CrowdStrike está expandindo dados de endpoint e ameaças para uma plataforma de segurança baseada em agentes.

A Splunk traz uma grande base instalada, amplas integrações e anos de conteúdo de detecção. A Palo Alto Networks e outros fornecedores de segurança também estão consolidando dados e automação. A Databricks entra em um mercado no qual os compradores já enfrentam alegações sobrepostas de plataforma.

A posição mais forte da Databricks não é a substituição imediata. É a vantagem arquitetural. As organizações podem usar o lakehouse para reduzir a duplicação de telemetria, reter mais histórico, enriquecer investigações e testar fluxos de trabalho assistidos por IA sem migrar todos os processos operacionais de uma só vez.

Uma abordagem em fases também facilita a medição do desempenho. As equipes podem começar pela otimização de custos de logs ou pela investigação retrospectiva de ameaças. Elas podem comparar velocidade de consulta, cobertura de detecção, esforço de engenharia e custo operacional total com o sistema existente.

A etapa seguinte pode transferir detecções selecionadas para a Databricks. Engenheiros de segurança podem gerenciar a lógica por meio de práticas de desenvolvimento conhecidas, incluindo controle de versão e testes. Os alertas ainda podem fluir para um sistema já estabelecido de gerenciamento de casos.

A substituição completa exige mais evidências. Um SIEM principal precisa oferecer ingestão confiável, detecção de baixa latência, continuidade de investigação, requisitos de auditoria e coordenação de resposta. Ele também deve permanecer utilizável durante incidentes que afetem outros sistemas corporativos.

A Databricks promove o Lakewatch como um SIEM aberto e agêntico, construído sobre a plataforma da empresa. A direção do produto deixa a intenção competitiva mais clara. A Databricks quer passar de apoiar análises de segurança para assumir uma parcela maior do fluxo de trabalho operacional.

Essa mudança pressiona fornecedores tradicionais em relação à economia de retenção e ao acesso a dados. Também pressiona a Databricks a atender expectativas específicas de segurança. A confiabilidade da plataforma de dados é necessária, mas um sistema de defesa operacional traz responsabilidades adicionais.

A vantagem do comprador vem de separar as alegações em camadas testáveis. A economia de armazenamento pode ser avaliada independentemente da qualidade de detecção. A produtividade dos agentes pode ser avaliada separadamente da segurança da resposta. A portabilidade pode ser testada nos níveis de dados, consultas, regras e fluxos de trabalho.

Os líderes de segurança também devem acompanhar o trabalho oculto. Uma plataforma pode reduzir a pressão sobre licenças enquanto aumenta o trabalho de engenharia. Manutenção de esquemas, desenvolvimento de conectores, ajuste de detecções, permissões e suporte de plantão devem fazer parte da comparação.

É por isso que a proposta da Databricks é mais significativa do que outro anúncio de recurso de IA. Ela reabre a fronteira entre a infraestrutura de dados corporativos e o centro de operações de segurança. Essa fronteira molda orçamentos e fluxos de trabalho de segurança há anos.

A Defesa Orientada por IA Herda um Problema de Governança de IA

Os mesmos agentes que comprimem investigações também podem acelerar erros, acessos não autorizados e respostas mal supervisionadas.

A Databricks apresenta a governança como parte da arquitetura, e não como uma etapa separada de conformidade. O Unity Catalog controla o acesso a dados e ativos de IA. O Unity AI Gateway gerencia o tráfego para modelos e serviços de ferramentas.

O guia de governança de IA da empresa afirma que o gateway pode encaminhar solicitações a modelos e ao Model Context Protocol. Ele também pode impor limites, aplicar políticas e registrar o uso entre provedores.

O Model Context Protocol, ou MCP, é um padrão que permite que aplicações de IA se conectem a ferramentas e fontes de dados. Em um ambiente de segurança, um serviço MCP pode expor inteligência de ameaças, funções de tickets, registros de ativos ou ferramentas aprovadas de resposta.

O controle centralizado oferece um benefício prático. Uma organização pode governar um modelo externo, agente de programação ou serviço MCP por meio da mesma camada de acesso usada para outros ativos de dados. A Databricks afirma que isso pode incluir modelos do Google, Anthropic e OpenAI.

Alguns recursos ainda permanecem em beta. A Databricks descreve políticas de serviço que podem permitir, negar ou exigir aprovação para solicitações com base no conteúdo. O status de prévia é importante quando se espera que essas políticas impeçam a exposição de dados sensíveis ou o uso perigoso de ferramentas.

Nenhum líder de segurança deve tratar uma proteção beta como a única barreira que protege uma ação de resposta em produção. A defesa exige controles sobrepostos. Restrições de identidade, ferramentas com escopo limitado, etapas de aprovação, registros, limites de taxa e ações reversíveis devem reforçar uns aos outros.

A revisão humana também precisa de uma definição precisa. Exigir que um analista aprove cada sugestão pode preservar o controle, mas pode recriar a fila que a automação deveria reduzir. Permitir ampla autonomia pode aumentar a velocidade, ao mesmo tempo em que eleva o impacto de uma decisão errada.

Um projeto prático divide as ações por consequência. A recuperação somente para leitura traz menos risco do que desativar uma conta. Elaborar uma regra de detecção é diferente de implantá-la. Colocar um único endpoint em quarentena é diferente de alterar uma política em toda a rede.

Cada categoria precisa de seu próprio limite de autorização. Ações reversíveis e de alta confiança podem receber mais automação. Ações ambíguas ou de alto impacto devem exigir evidências adicionais e aprovação explícita.

A exposição de dados cria outra preocupação. Um agente de investigação frequentemente precisa de atividade de usuários, detalhes de dispositivos, logs de aplicações e contexto organizacional. Essa combinação pode revelar informações pessoais ou empresariais sensíveis, mesmo quando cada fonte parece inofensiva isoladamente.

A Databricks afirma em sua documentação de confiança em IA que provedores parceiros de modelos não armazenam prompts nem respostas. A empresa também afirma que as permissões do Unity Catalog governam quais dados seus recursos de IA podem enviar.

A documentação reconhece que os modelos podem alucinar ou produzir respostas incorretas. Esse aviso é especialmente importante em segurança, onde um resumo fluente, mas impreciso, pode desviar uma investigação ou implicar indevidamente um usuário.

A recuperação com reconhecimento de permissões reduz o acesso não autorizado. Ela não comprova a precisão factual. As equipes precisam de avaliações baseadas em padrões reais de incidentes, entradas adversariais, telemetria incompleta e evidências conflitantes.

A injeção de prompt acrescenta outro risco. Um invasor poderia inserir texto malicioso em um ticket, campo de log, repositório ou documento que um agente recupera posteriormente. Se o sistema tratar esse conteúdo como instrução, o fluxo de investigação poderá ser manipulado.

Políticas de governança podem filtrar alguns ataques, mas uma defesa confiável também depende de separação arquitetural. Dados recuperados devem permanecer não confiáveis. As ferramentas devem aplicar autorização fora do modelo. Ações sensíveis não devem depender apenas de uma decisão gerada.

A auditabilidade se torna o teste final. As equipes precisam de registros que mostrem quais dados um agente acessou, qual modelo os processou, quais ferramentas foram chamadas e quem aprovou o resultado. Sem essa cadeia, a revisão de incidentes e as evidências regulatórias se tornam difíceis.

Isso também é relevante para o trabalho de conhecimento fora do centro de operações de segurança. Equipes que usam uma base de conhecimento com IA enfrentam questões semelhantes sobre permissões, qualidade das fontes e rastreabilidade. A segurança eleva as consequências, mas o princípio de governança permanece o mesmo.

A Databricks reuniu componentes confiáveis para esse problema. A empresa não estabeleceu que todos os clientes conseguem combiná-los em uma defesa autônoma segura. Esse resultado depende de disciplina de implementação, medição e responsabilidade operacional.

Três Sinais Mostrarão se a Estratégia Funciona

O próximo teste não é outra demonstração de IA; são evidências de que a Databricks pode melhorar a defesa sem transferir custos e riscos para outro lugar.

O primeiro sinal é um desempenho de clientes que possa ser compreendido de forma independente. A Databricks precisa de mais estudos de caso que definam a linha de base, a carga de trabalho, o escopo de implantação e o período de medição. Uma porcentagem sem esses detalhes chama atenção, mas oferece orientação limitada.

Os líderes de segurança devem buscar cobertura de detecção, tempo médio de investigação, taxas de falsos positivos, profundidade de retenção e esforço total de engenharia. As alegações de custo devem incluir trabalho de migração, manutenção de conectores, infraestrutura e equipe.

Se os clientes mantiverem uma telemetria mais ampla enquanto reduzem tanto o tempo de investigação quanto as despesas operacionais, a Databricks ganha um argumento mais forte. Se as economias dependerem de engenharia personalizada substancial, o argumento se torna menos persuasivo para equipes menores.

O segundo sinal é a maturidade das operações de agentes governados. Políticas de serviço, controles de aprovação, restrições de ferramentas e registros de auditoria precisam ir além das demonstrações. Os compradores precisam de comportamento documentado em situações de falha, ataque e evidências ambíguas.

Uma validação útil mostraria um agente encontrando conteúdo malicioso recuperado sem segui-lo. Outra mostraria uma ação de resposta bloqueada porque a identidade solicitante não tinha permissão. As equipes também precisam de procedimentos claros de reversão e revisão de incidentes.

Se esses controles se tornarem amplamente disponíveis e resistirem a testes adversariais, a tese de defesa orientada por IA se fortalece. Se proteções críticas permanecerem em prévia ou exigirem amplo trabalho personalizado, a autonomia deve continuar rigidamente limitada.

O terceiro sinal é a resposta competitiva. Google, Microsoft, Splunk, CrowdStrike e Palo Alto Networks já controlam fluxos de trabalho importantes de segurança. Eles podem ajustar modelos de retenção, abrir o acesso a dados, expandir a governança de agentes ou aprofundar integrações com a nuvem.

O Google merece atenção especial porque é ao mesmo tempo parceiro de infraestrutura e concorrente em plataformas de segurança. Um cliente Databricks Google pode combinar seus serviços, mas planos de controle sobrepostos podem criar responsabilidade pouco clara.

Uma interoperabilidade mais estreita daria suporte à Databricks. Dados de segurança poderiam permanecer portáteis, enquanto alertas, casos, inteligência de ameaças e ações de resposta transitariam por interfaces definidas. Os compradores ganhariam escolha arquitetural sem reconstruir todos os fluxos de trabalho.

Um agrupamento mais rígido de plataformas poderia enfraquecer o argumento. Se fornecedores estabelecidos combinarem economia de armazenamento aceitável com agentes de segurança maduros, os clientes poderão preferir um conjunto operacional único. Conveniência e responsabilização frequentemente importam mais durante incidentes do que elegância arquitetural.

Os líderes de segurança não precisam escolher uma arquitetura final imediatamente. Eles podem testar o modelo da Databricks em relação a uma carga de trabalho cara ou fragmentada. Investigação retrospectiva de ameaças, análise de auditoria na nuvem e desenvolvimento de detecções oferecem pontos de partida delimitados.

O piloto deve preservar o fluxo de trabalho existente e, ao mesmo tempo, produzir medições comparáveis. As equipes devem definir o sucesso antes de mover dados. Elas também devem registrar o trabalho necessário para normalizar a telemetria e manter as detecções confiáveis.

Uma revisão útil faz cinco perguntas. O novo sistema preservou mais dados relevantes? Os analistas investigaram mais rapidamente? As detecções melhoraram? O esforço operacional total caiu? A governança permaneceu compreensível?

As respostas mostrarão se o lakehouse está se tornando uma camada operacional de segurança ou apenas outro destino para logs. Elas também separarão o valor da IA do valor do armazenamento, que os fornecedores frequentemente apresentam juntos.

A Databricks identificou uma limitação real. Agentes não podem compensar dados de segurança fragmentados, inacessíveis ou mal governados. Seu guia dá aos líderes de segurança um motivo para reconsiderar onde esses dados residem e quem os controla.

A questão não resolvida é a confiança operacional. Uma empresa de plataforma de dados consegue oferecer a confiabilidade, o conteúdo de segurança, os controles de resposta e a responsabilização esperados de um sistema de defesa de linha de frente?

Para equipes que avaliam a arquitetura Databricks Google, o próximo passo é uma comparação criteriosa, não uma substituição imediata. Escolha um fluxo de investigação, defina suas permissões e registre os resultados de referência. Em seguida, teste se o contexto unificado melhora as decisões sem ampliar o acesso ou aumentar o trabalho oculto. Essas evidências importarão mais do que o número de agentes em uma demonstração de produto.