Uma conversa com o Chief Product Officer da Barracuda, Neal Bradbury, sobre por que os dados proprietários são o verdadeiro fosso quando o cenário de ameaças de cada cliente é único
por Aly McGue
Empresas de cibersegurança enfrentam um paradoxo. Seus clientes continuam adicionando mais ferramentas de segurança, esperando mais proteção. Mas os dados mostram cada vez mais que a proliferação de ferramentas torna as organizações mais lentas para detectar e responder a ameaças. Ao mesmo tempo, a IA está acelerando ambos os lados da equação: dando aos defensores novas capacidades e, ao mesmo tempo, tornando dramaticamente mais fácil para os atacantes operarem em escala.
Por mais de vinte anos, a Barracuda protegeu organizações contra ameaças em evolução com sua plataforma de cibersegurança BarracudaONE, que maximiza a resiliência cibernética unificando a proteção em e-mail, dados, redes, aplicativos e XDR gerenciado. A Barracuda usa Databricks para sua plataforma de dados corporativos, consolidando silos de dados fragmentados para potencializar operações de ML, correlação de ameaças em tempo real e business intelligence. Usando Databricks Genie, a equipe desenvolveu e lançou rapidamente recursos como pesquisa de logs em linguagem natural para sua solução XDR gerenciada, permitindo que os clientes consultem bilhões de eventos de segurança em linguagem natural, mantendo o isolamento rigoroso dos dados.
Neal Bradbury é Chief Product Officer na Barracuda, responsável por gerenciamento de produtos, engenharia, segurança e operações em nuvem. Ele liderou a mudança para o que a Barracuda chama de desenvolvimento de produtos AI-native, no qual a inteligência é incorporada ao núcleo de cada aplicativo, em vez de ser adicionada como uma interface por cima.
O fio condutor de nossa conversa foi consistente: em uma era em que os atacantes operam em escala, os defensores que vencem com IA são aqueles que tratam sua telemetria de segurança proprietária como um ativo estratégico. Eles não estão apenas adicionando ferramentas de IA; eles estão incorporando inteligência diretamente na camada de dados para se manterem à frente das ameaças em evolução.
Aly McGue: Como você define um "aplicativo AI-native" em seu negócio em comparação com um aplicativo tradicional? Qual é a diferença estratégica para a experiência do cliente?
Neal Bradbury: Para nós, AI-native significa que é embutido, não adaptado. O aplicativo deve ser arquitetado com IA em seu núcleo. Em segurança, isso significa observabilidade, governança, controles de acesso e aplicação, tudo embutido desde o primeiro dia. Temos nosso Bailey AI Assistant, mas o núcleo de como nossos aplicativos funcionam, seja nosso WAF ou nossa proteção de e-mail, eles são AI-native em sua fundação.
A outra grande distinção é que os aplicativos AI-native se adaptam continuamente. Um aplicativo tradicional é construído de uma certa maneira e opera dessa forma até que alguém vá e o altere. Um aplicativo AI-native é mais dinâmico. Ele responde a dados de clientes em mudança, necessidades em mudança e metas em mudança. Ele encontra o cliente onde ele está à medida que as coisas evoluem, o que importa muito quando o cenário está se movendo tão rápido quanto agora.
No nosso caso, estamos coletando ameaças e riscos de clientes em toda a plataforma BarracudaONE. Cada cliente tem um perfil de risco diferente. Cada cliente precisa de ameaças diferentes priorizadas. Portanto, não pode ser rígido. Essa é realmente a diferença estratégica: uma solução AI-native se adapta a cada cliente em vez de forçar todos a seguir o mesmo caminho determinístico.
Aly: O que foi necessário para reestruturar seu produto principal e incorporar recursos AI-native como personalização, mecanismos de recomendação ou ferramentas de copiloto?
Neal: Eu voltaria à nossa solução XDR gerenciada como exemplo. Tivemos que questionar realmente o foco e o propósito dessa oferta e, em seguida, trabalhar de trás para frente. Que problema estamos realmente resolvendo? Que resultado estamos entregando para o cliente? Qualquer gerente de produto deve começar por aí, mas torna-se ainda mais crítico quando você está incorporando IA, porque as decisões de arquitetura que você toma no início determinam o que é possível mais tarde.
A peça fundamental foi organizar a camada de dados. Se seus dados estão espalhados ou o esquema não é compartilhado, isso causa problemas a jusante para tudo. Ser capaz de normalizar o esquema permitiu que nossos modelos e agentes de machine learning tivessem contexto completo entre domínios e realmente fizessem o que precisávamos que fizessem.
Também fomos disciplinados em dar pequenas mordidas. Não tentamos migrar tudo de uma vez. Começamos com pequenas partes, iteramos e trabalhamos em direção ao resultado completo. Você pode encontrar uma maneira mais sofisticada de descrever isso, mas foi: entenda qual deve ser a saída e, em seguida, itere para chegar lá.
O que saiu desse processo foi a detecção de streaming em tempo real construída com notebooks, operações de ML executadas através de MLflow e múltiplos modelos de machine learning com mais de 30 recursos que melhoram continuamente. E a parte emocionante é que conseguimos estender esse mesmo padrão de plataforma para outros produtos: nosso WAF-as-a-service, nosso motor de configuração automatizada, segurança de API e proteção avançada contra bots. Assim, o investimento se multiplica.
Aly: Como você alinhou com sucesso as equipes de produto, ciência de dados e engenharia para trabalhar a partir de uma plataforma de dados e IA compartilhada para acelerar o tempo de lançamento no mercado desses recursos?
Neal: Vou parecer um disco arranhado, mas realmente se resumiu a definir resultados compartilhados primeiro. Pegue nosso recurso de proteção contra personificação no Barracuda Email Protection, que protege os clientes contra ataques avançados. O resultado não foi simples, mas foi claro. E essa clareza significou que as equipes puderam impulsionar em direção a um objetivo unificado sem se perder em debates sobre ferramentas. Tínhamos Databricks como plataforma, tínhamos um destino e pudemos simplesmente executar.
A mesma lógica se aplica quando trabalhamos com funções não relacionadas à engenharia. Quando buscamos a redução de churn, precisávamos de informações do cliente, telemetria de produto e dados de vendas. Ser capaz de reunir tudo isso em uma única plataforma de dados corporativos e realmente ver insights interfuncionais foi o que impulsionou o alinhamento. Não foi uma ordem de cima para baixo. Foi um resultado compartilhado que todos puderam ver e medir. É isso que move as pessoas.
Aly: Como a construção de aplicativos AI-native em sua própria camada de dados oferece uma vantagem competitiva mais profunda e defensável em comparação com a dependência exclusiva de modelos SaaS externos?
Neal: Sua própria camada de dados é o diferencial. Ponto final. Agentes de IA são tão fortes quanto os dados proprietários e ricos em contexto aos quais podem acessar. Quando você constrói sobre sua telemetria de segurança unificada, você cria uma vantagem que modelos SaaS genéricos simplesmente não conseguem replicar.
Como construímos sobre nossos próprios dados, podemos personalizar para a telemetria e os insights específicos que obtemos em todo o portfólio de segurança. Isso nos permite fornecer recomendações direcionadas e tomar decisões junto com nossos clientes de maneiras que um modelo externo de tamanho único nunca poderia.
A maneira como penso sobre isso é: um produto AI-native pode usar o contexto de implantação e comportamento específico do cliente para se adaptar e responder de maneiras que uma IA SaaS externa simplesmente não consegue. E essa vantagem se acumula. Quanto mais dados fluem pelo sistema, melhor ele se torna em entender o ambiente exclusivo de cada cliente. Ninguém pode atalhar o caminho para isso.
O que ficou mais claro nesta conversa é que AI-native é um compromisso arquitetônico, não um rótulo de recurso. Neal traça uma linha entre produtos que têm IA projetada em sua fundação e produtos que adicionam uma interface inteligente por cima de um sistema tradicional. A diferença aparece na dinâmica com que o produto se adapta, o quão bem ele usa o contexto proprietário e o quão defensável é o resultado ao longo do tempo.
Para executivos que avaliam suas próprias estratégias de produto, a pergunta que vale a pena considerar é: a inteligência é embutida no núcleo do que você lança, ou é adicionada por cima? A resposta determina não apenas o que seu produto pode fazer hoje, mas quão rápido ele pode evoluir quando o cenário mudar novamente.
Para saber mais sobre como construir um modelo operacional eficaz, baixe o Modelo de Maturidade de IA da Databricks.
(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original
Assine nosso blog e receba os posts mais recentes diretamente na sua caixa de entrada.