Val Bercovici, Diretor de IA da WEKA – Série de Entrevistas

Val Bercovici, Diretor de IA da WEKA, é um executivo de IA e infraestrutura de dados focado em avançar as tecnologias que sustentam a inteligência artificial de próxima geração. Desde que ingressou na WEKA como Diretor de IA em janeiro de 2025, ele tem se concentrado em construir infraestrutura para agentes de IA, acelerar cargas de treinamento e inferência, e melhorar a economia da computação de IA. Além de sua função na WEKA, Bercovici atua como conselheiro de IA da Home Dock, conselheiro estratégico da FermiHDI e The Hive, e presidente da PencilDATA, onde seu trabalho abrange IA, cibersegurança, blockchain, computação em nuvem e infraestrutura de dados. Sua carreira reflete um foco de longa data no desenvolvimento e consultoria de tecnologias emergentes projetadas para suportar sistemas de IA cada vez mais intensivos em dados.

WEKA é uma empresa de infraestrutura de dados nativa em IA que constrói uma plataforma definida por software projetada para as exigentes necessidades de dados da inteligência artificial, aprendizado de máquina, computação de alto desempenho e outras cargas aceleradas. A Plataforma de Dados WEKA oferece às organizações uma arquitetura unificada que pode operar em ambientes on-premises, nuvem, híbridos e de borda, ajudando a eliminar gargalos de armazenamento, melhorar a utilização de GPUs e acelerar o treinamento e a inferência de modelos de IA. A empresa tem posicionado sua tecnologia cada vez mais em torno da emergente economia de inferência e IA agente, com sua infraestrutura projetada para fornecer acesso de alta taxa de transferência e baixa latência a dados em escala massiva, ao mesmo tempo simplificando pipelines de dados de IA complexos. WEKA atende empresas, provedores de nuvem, organizações de pesquisa e desenvolvedores de IA que operam alguns dos ambientes computacionais mais intensivos em desempenho do mundo.

Sua carreira o levou de moldar a estratégia inicial de nuvem da NetApp e servir no conselho fundador do Kubernetes até construir infraestrutura de IA na WEKA. Como essa evolução moldou sua forma de pensar sobre a preparação da infraestrutura para a próxima fase da IA?

Cada era da minha carreira foi definida pelo mesmo padrão: o gargalo muda, e a indústria leva anos para perceber. Nos primeiros dias da nuvem e do Kubernetes, vimos a computação tornar‑se elástica e a orquestração tornar‑se o novo ponto de estrangulamento. Saindo da NetApp, onde fui CTO após a aquisição da SolidFire, eu achava que sabia como era a velocidade: poucos milissegundos para uma leitura aleatória de primeiro byte em cargas de produção.

O motivo pelo qual entrei na WEKA é genuinamente nerd. Foi uma estatística: a primeira leitura aleatória de byte não armazenada em cache é de 70 microssegundos, o que não é um número de classe de armazenamento. Eu nunca havia considerado a latência em nível de microssegundo para esse tipo de sistema. Foi a lâmpada acesa: essa tecnologia poderia atender a aplicações de memória, aplicações de classe DRAM como Redis e cache KV, não apenas armazenamento. E, como esperado, a inferência começou a superar o treinamento porque a indústria precisava monetizar esses modelos, e os agentes surgiram para tornar a memória o jogo inteiro.

Essa é a perspectiva que trago para a infraestrutura de IA. Já vimos esse filme antes. O Cloud FinOps surgiu porque as empresas criaram infraestrutura sem rigor econômico unitário e depois receberam a conta. A IA está na mesma curva, avançando mais rápido.   À medida que as empresas inevitavelmente reagiram ao excesso de tokens com a chegada de faturas de consumo de API muito acima dos orçamentos de tokens planejados, estamos testemunhando o surgimento do AI FinOps. Este é o ponto em que as organizações deixam de tratar a inferência como uma utilidade barata e começam a gerenciar a eficiência de tokens como uma disciplina financeira. O AI FinOps começa com tokenômica: otimizar cada camada de hardware e software da pilha de inferência que impacta o custo unitário por token. No momento, o maior desperdício nessa pilha são GPUs caras e novos ASICs ociosos, aguardando memória e dados (também chamado de ‘decode’) em vez de FLOPS (também chamado de ‘prefill’). Quem resolver isso possuirá a próxima fase da IA.

A Casa Branca está mantendo os detalhes de seu novo framework de segurança de IA confidenciais. Como as empresas podem se preparar para requisitos regulatórios quando ainda não sabem exatamente o que será testado ou exigido?

As empresas não devem esperar pela lista final de verificação. Os testes específicos mudarão, mas a obrigação subjacente não: será necessário demonstrar o que seu modelo de IA fez, quais dados ele acessou e como se comportou em um ponto específico no tempo. E esperar já não é uma opção globalmente. O AI Act da UE tornou‑se aplicável este mês, e classifica a maioria da orquestração de agentes como de alto risco.

Isso significa que o trabalho de preparação é trabalho de infraestrutura. Linhagem de dados, observabilidade, reproducibilidade e a capacidade de reconstruir o estado do modelo sob demanda são críticos para as empresas acertarem. Por fim, as organizações precisam implementar modelos de guarda‑fronteira antes das saídas, com latência associada e orçamentos de tokens para as camadas de defesa semântica. Se você construir essas capacidades agora, qualquer framework se torna um exercício de formatação. Esperar pelas regras finais fará com que você adapte responsabilidade a sistemas que nunca foram projetados para se explicar. Essa adaptação é sempre mais cara do que incorporá‑la desde o início.

Em última análise, a solução para construir IA segura é mais IA, aplicada de forma otimizada e muito intencional.

Que tipos de novas demandas de infraestrutura os testes de segurança de IA poderiam criar, e como essas cargas de trabalho poderiam diferir do treinamento ou inferência convencional de modelos?

Treinamento é como uma mangueira de incêndio. Você empurra volumes enormes de dados através de um modelo em um padrão sustentado e previsível. Testes de segurança são o oposto: milhares de cenários de avaliação, sondagens repetidas, comparações comportamentais versão‑sobre‑versão e equipes vermelhas adversariais que nunca realmente terminam.

Esse perfil importa. Treinamento e teste de segurança são intermitentes, intensivos em leitura e comparativos. Eles geram e consomem enormes quantidades de estado intermediário. Modelos de guarda‑fronteira precisam ser inerentemente heterogêneos e em camadas, implementados dentro de orçamentos de latência apertados, ampliando avaliações com essa nova dimensão de critérios de segurança. Para modelos tão avançados ou com capacidade cibernética, o perfil de carga de trabalho é persistente 24/7, e não episódico. Você não executa um teste uma única vez e arquiva os resultados. Você está executando cargas de trabalho contínuas de enxames de agentes que competem em produção por computação, memória e largura de banda de dados para proteger aplicativos críticos. Além da qualidade e velocidade, a maioria das infraestruturas hoje não foi projetada para esse terceiro princípio.

Há também um problema de medição por baixo disso. A maioria dos benchmarks de IA hoje executa 8.000 tokens ou menos, um prompt, uma resposta. Brinco que são benchmarks artificiais de inteligência artificial. Em meados de 2026, cargas de trabalho reais de agentes executam de 100.000 a 400.000 tokens de contexto ao longo de milhares de turnos. Se as avaliações de segurança herdarem esses benchmarks de brinquedo, estaremos certificando sistemas para um mundo que não existe. Os reguladores já estão fortalecendo isso: o NIST disponibilizou como código aberto ferramentas de avaliação de segurança de agentes, e os primeiros resultados publicados mostram ataques de sequestro de agentes inovadores tendo sucesso em várias vezes a taxa dos referenciais conhecidos. Esse é exatamente o tipo de teste contínuo, adversarial e caro que espero que os frameworks de segurança converjam.

As organizações deveriam construir capacidade excessiva de computação e dados especificamente para cargas de trabalho futuras de conformidade e segurança, ou há uma forma mais eficiente de projetar para essa incerteza?

Comprar GPUs em excesso e esperar que a utilização se recupere deixa o capital preso em hardware que se deprecia.

A resposta eficiente é uma infraestrutura que alterna entre cargas de produção e avaliação sem uma pilha separada. Isso é fundamentalmente um problema de dados. Se você puder mover e reutilizar dados de forma eficiente, preservar o contexto entre cargas de trabalho e manter seus aceleradores ocupados com trabalho real, a conformidade torna‑se um custo incremental em vez de uma construção paralela. A economia da IA cada vez mais se resume a quanto valor você extrai de cada token, byte e watt. Acertando isso, você pode gerar de 3 a 4 vezes mais valor com a mesma infraestrutura, ou reduzir sua pegada de rack em até 75%. A conformidade deve ser mantida ao mesmo padrão.

O framework atual, segundo relatos, foca em modelos fechados avançados enquanto exclui modelos de peso aberto. Que desafios de infraestrutura ou segurança poderiam surgir ao tratar essas duas categorias de forma diferente?

Se você tratar modelos fechados e modelos de peso aberto de maneira diferente, acabará com dois frameworks de conformidade para tecnologias que fazem as mesmas coisas, e a lacuna entre eles é onde o risco reside.

Um modelo de peso aberto pode ser ajustado e implantado em ambientes onde o provedor original não tem nenhuma visibilidade. Regular o provedor não resolve nada ali. E a divisão já é visível: controles de exportação recairam nos mais recentes modelos de fronteira fechados este ano, enquanto modelos de peso aberto cruzam fronteiras livremente e agora estão perto do topo dos rankings de capacidade pública. No entanto, a administração acaba definindo modelos de fronteira, a governança não pode parar no modelo em si. É necessário visibilidade sobre onde os modelos estão sendo executados, quais dados eles acessam, quais prompts, respostas e metadados são retidos, como foram modificados e se a infraestrutura subjacente pode realmente suportar IA governada em escala. Novas atualizações ao ISO27001 e SOC2 serão necessárias.

Minha resposta é confiança, mas verificação. Se sua infraestrutura lhe oferece a capacidade de tokens, você pode executar guarda‑fronteiras heterogêneas contra qualquer modelo antes que sua saída seja enviada: doméstico ou estrangeiro, aberto ou fechado. A verificação objetiva supera a confiança cega ou a desconfiança cega baseada na origem do modelo. À medida que modelos abertos proliferam, essa capacidade de verificação reside na camada de infraestrutura, e é aí que as empresas se diferenciarão. A política pode decidir quais modelos são permitidos. A infraestrutura decide se esses modelos podem ser implantados de forma responsável e econômica.

À medida que os agentes de IA se tornam mais autônomos e operam em contextos mais longos, como isso altera a quantidade de dados, memória e computação que as organizações precisam alocar para monitoramento e segurança?

Um chatbot é um prompt e uma resposta. Um agente autônomo é um processo em execução. Ele interage com dezenas de sistemas, recupera informações, toma decisões intermediárias e acumula estado ao longo de horas ou dias antes de concluir uma tarefa.

Você não pode monitorar isso amostrando tokens ou respostas individuais. É preciso capturar a sequência completa: o que o agente sabia, quando soube e o que fez a seguir. Cada hora que um agente roda, seu estado cresce, assim como a memória, o movimento de dados e a infraestrutura necessária para capturá‑los e analisá‑los. O monitoramento deixa de ser um recurso de registro e torna‑se uma carga de trabalho de primeira classe com seu próprio orçamento de recursos.

A defesa é onde isso se torna urgente. O problema de memória da IA está se tornando um problema de segurança. Um agente de codificação pode ser iniciado, entregue e encerrado. Um agente de cibersegurança não pode. Ele precisa manter o contexto durante as mudanças de turno diárias em um centro de operações de segurança, atualizações frequentes de modelo e campanhas de ataque sofisticadas de múltiplas etapas que antes se estendiam por semanas, mas hoje também operam em velocidades de máquina coordenadas. Quando essa memória de trabalho da IA é expulsada e recomputada do zero a cada poucos minutos, um agente que detectou comportamento anômalo na primeira hora de um incidente não tem memória disso na segunda hora. Os invasores não têm esse problema. Seus agentes identificam e perseguem vulnerabilidades de forma persistente, e as cadeias de destruição agora se completam em velocidades de máquina otimizadas por tokenômica, de modo que a defesa cibernética alimentada por IA precisa operar autonomamente 24 horas por dia. E isso não é teórico. Os fornecedores de segurança estão se preparando para agentes cibernéticos persistentes 24/7 agora, e a primeira coisa que descobrem é que a economia não se parece em nada com cargas de trabalho de chat. Algumas organizações precisam desses agentes funcionando na borda, em instalações onde você não pode enviar um rack de GPU ou mesmo um chiller este ano. O verdadeiro teste para IA empresarial é a retenção de contexto sustentada, não a inferência pontual. Isso se torna uma batalha de atrito de tokens, e quem resolver a memória de contexto persistente em escala alimentará o primeiro aplicativo horizontal de sucesso em IA empresarial: enxames de agentes azuis sempre ativos.

Você falou sobre a crescente importância da “memória de contexto” à medida que as cargas de IA avançam além do chat simples para agentes persistentes. A memória de contexto também poderia se tornar importante para auditoria, reprodução ou investigação do comportamento da IA?

Absolutamente, e é um caso de uso importante. Por anos, a memória foi uma questão de desempenho: quão rápido você podia alimentar a GPU, quanto contexto podia manter. Quando os agentes começam a agir autonomamente, essa mesma memória torna‑se a evidência. Se um agente toma uma decisão baseada em contexto que acumulou ao longo de dias, o prompt final e a saída dizem quase nada sobre o motivo da ação. A explicação reside no estado acumulado.

Em termos técnicos, a maior parte desse estado reside no cache KV, e a indústria ainda o trata como espaço descartável em vez de dados duráveis. Se você preservar esse estado e puder recuperá‑lo eficientemente, poderá reconstruir o que o sistema sabia no momento da ação. As equipes usarão isso primeiro para depuração, depois para avaliações de segurança e, eventualmente, alguém precisará disso em uma investigação. Descartar a memória de contexto significa descartar o único registro que explica por que sua IA fez o que fez.

A regulação de IA poderia, em última instância, obrigar as empresas a reter significativamente mais informações sobre entradas de modelo, saídas, checkpoints, linhagem de dados e atividade de agentes? O que isso significaria para a arquitetura de infraestrutura de IA?

De forma geral, sim. À medida que os sistemas de IA se tornam mais relevantes, os requisitos de visibilidade se expandirão para cobrir cada etapa do pipeline. Já é possível ver os primeiros sinais: equipes estão planejando reter memória de contexto obsoleta em camadas de armazenamento de objetos mais baratas apenas para fins de auditoria, antes que qualquer regulação exija isso.

A autenticação do monitoramento com imutabilidade é essencial. A adulteração de logs e outros artefatos forenses por agentes maliciosos tornou‑se rotineira, exigindo sistemas elaborados de verificação criptográfica que não sejam vulneráveis a alvos de integridade concentrados e centralizados. Logs de transparência simples ou cadeias de hash não são suficientes para defender contra as habilidades de colusão de enxames de agentes coordenados. Arquiteturas de blockchain públicas altamente descentralizadas são idealmente adequadas para isso, destacando o valor de Integridade, muitas vezes negligenciado, no meio da tríade C‑I‑A da cibersegurança.

A retenção não é apenas um problema assustador e imutável de armazenamento em escala. A parte difícil é manter essa informação confiável, organizada, indexada e recuperável rapidamente o suficiente para ser útil dentro de um prazo, seja esse prazo imposto por um regulador, uma resposta a incidente ou um tribunal. Um petabyte de atividade de agente que você não pode consultar é uma responsabilidade, não um registro. A mudança arquitetônica passa de “mais armazenamento” para uma infraestrutura projetada em torno de dados de IA objetivamente verificáveis, persistentes e consultáveis como carga de trabalho central.

Muitas organizações focam em comprar mais GPUs, mas onde você vê os gargalos de infraestrutura menos óbvios surgindo à medida que as cargas de IA escalam e os requisitos de segurança se tornam mais exigentes?

A GPU ganha as manchetes porque não é um item de orçamento insignificante. Mas GPUs e, especialmente, novos aceleradores otimizados para decodificação (ASIC+SRAM) raramente são a restrição real. A largura de banda de memória, a gravidade e o movimento de dados, o desempenho de armazenamento e a rede determinam se esses aceleradores estão realizando trabalho produtivo ou aguardando subutilizados.

À medida que a IA se torna mais pesada em contexto, a parede de memória torna‑se a restrição definidora. Você pode continuar adicionando GPUs, mas se elas gastam seus ciclos recomputando tokens ou trocando contexto entre sistemas, está pagando por trabalho desperdiçado, repetidamente. Escalar a parede de memória significa fazer a camada de dados se comportar como armazenamento compartilhado, mas operar em velocidades reais de memória. Essa barra de velocidade adjacente ao HBM importa para a onda de centros de lucro das soluções de descarregamento de cache KV que chegam agora: qualquer uma delas precisa oferecer desempenho de classe de memória real para que a tokenômica faça sentido. O valor de retenção para o cache KV é uma discussão de centro de custo, secundária ao centro de lucro. E se a leitura de contexto em cache for mais lenta que simplesmente recomputá‑lo, o cache se torna inútil para a equação de negócios. O que importa não é quantas GPUs você possui, mas quão produtiva cada uma é. A economia da IA se resume ao valor que você extrai de cada token, byte e watt, e os requisitos de segurança só aumentarão as apostas nessa matemática.

Olhando para o futuro, você espera que a segurança e a conformidade de IA se tornem uma carga de trabalho de infraestrutura distinta, semelhante ao modo como a cibersegurança evoluiu para uma camada dedicada da tecnologia empresarial?

Veremos a segurança e a conformidade de IA se tornarem uma carga de trabalho distinta, e o paralelo com a cibersegurança funciona nos dois sentidos. A segurança tornou‑se sua própria camada quando a indústria reconheceu que não poderia ser um exercício ocasional. A indústria de seguros cibernéticos tornou isso obrigatório. A segurança de IA está na mesma trajetória mandatória à medida que os modelos se tornam mais capazes e mais autônomos.

Mas devemos aprender de onde a segurança errou. Ela se tornou um acréscimo: uma pilha separada, um orçamento separado, uma equipe separada que descobria problemas depois do fato. A infraestrutura de segurança não deve repetir esse erro. Monitoramento, avaliação, auditabilidade e retenção imutável pertencem à própria infraestrutura de IA, co‑projetados desde o início.

Esta é a parte que a maioria das pessoas perde: IA segura requer mais IA. Modelos de guarda‑fronteira não são gratuitos. Eles precisam ser continuamente treinados, ajustados e inferidos em cada etapa da execução do agente. Orçamentos de latência de token tornam isso concreto: cada resposta tem uma janela fixa, e quanto mais tokens você puder processar dentro dessa janela, mais verificações poderá executar antes que a saída seja liberada. E a verdadeira ameaça dos modelos de fronteira é sua aplicação agente. Os agentes operam como loops de inferência de alto volume, fazendo chamadas repetidas aos modelos ao longo de longos horizontes. Cada loop é observar, orientar, decidir, agir, e cada passo consome tokens. Isso transforma a segurança de IA em uma guerra de atrito de tokens. Invasores lançam enxames de agentes vermelhos, defensores lançam enxames de agentes azuis, e o lado que puder gerar mais tokens por dólar e por watt vence. A tokenômica está no caminho crítico tanto do ataque quanto da defesa. Isso deixou de ser um experimento mental neste verão, quando um ataque de enxame de agentes vermelhos contra um grande repositório de modelos assustou a indústria, e uma aliança de IA segura dedicada se formou em dias. Enquanto isso, os volumes continuam a se multiplicar: o processamento de tokens da indústria passou de trilhões para quadrilhões.

Quando a segurança se tornar um requisito sempre ativo, seus custos de computação, memória e dados deixam de ser sobrecarga. Eles passam a fazer parte da economia unitária fundamental de operar IA. As empresas que internalizarem isso cedo tratarão a segurança como um insumo de design. Todos os demais a tratarão como um imposto.

Obrigado pela ótima entrevista, leitores que desejam saber mais devem visitar WEKA.