Orca Security Discovery AI Reduz o Custo de Consultas de Segurança em Linguagem Natural

O Orca Security Discovery AI agora converte perguntas de segurança em linguagem natural em consultas Sonar, usando 93% menos tokens de entrada do que seu design inicial. A Orca também relata custos de consulta 90% menores e latência 75% menor após reconstruir o sistema no Amazon Bedrock.

Esses números representam mais do que uma atualização rotineira de modelo. A Orca substituiu um enorme prompt por um pipeline de nove estágios que decide quando regras, recuperação, modelos menores ou raciocínio mais aprofundado devem processar cada solicitação.

O resultado pressiona uma estratégia comum de IA empresarial: colocar cada esquema, exemplo e instrução em uma única grande janela de contexto. A experiência da Orca sugere que mais contexto pode elevar custos, enfraquecer a relevância e tornar o aplicativo mais lento.

A alternativa trata o modelo de linguagem como um componente dentro de um compilador de consultas controlado. A correspondência determinística lida com entradas evidentes, a recuperação fornece exemplos comprovados e a validação verifica filtros gerados antes de retorná-los.

Esse design é importante porque consultas de segurança em linguagem natural operam sobre informações sensíveis e altamente estruturadas. Uma resposta fluente tem pouco valor quando o filtro gerado aponta para o ativo errado, atravessa um limite de autorização ou omite uma condição crítica.

Orca Substituiu Um Prompt Gigante Por Um Pipeline de Produção

A mudança central foi arquitetural: a Orca deixou de pedir que um único modelo entendesse todo o seu esquema de segurança em cada solicitação.

O sistema de consultas Sonar da Orca abrange mais de 900 modelos de infraestrutura de nuvem e aplicações. Esses modelos representam recursos como instâncias de computação, buckets de armazenamento, identidades, vulnerabilidades e os relacionamentos que os conectam.

Antes do Discovery AI, os usuários precisavam construir filtros JSON precisos. Também precisavam conhecer nomes exatos de modelos, navegar por relacionamentos aninhados e escolher entre 18 operadores de filtragem.

Essa exigência criava uma barreira de usabilidade para analistas que entendiam a questão de segurança, mas não o esquema completo do Sonar. Por isso, a Orca criou uma interface de linguagem natural que traduz a solicitação de um analista em um filtro válido.

A primeira prova de conceito utilizou a abordagem mais direta de IA generativa. A Orca carregou mais de 900 definições de modelos, tipos de relacionamento e consultas de exemplo em um único prompt para um modelo grande.

Segundo a empresa, parceiros de design e usuários internos aprovaram a qualidade das respostas. No entanto, o design consumia cerca de 2 milhões de tokens de entrada para uma carga de trabalho comparável e levava aproximadamente 60 segundos.

Solicitações complexas também expuseram limites de precisão. Perguntas envolvendo vários modelos de recursos, relacionamentos aninhados ou múltiplas condições frequentemente exigiam refinamento adicional.

A Orca e a AWS desenvolveram então o pipeline de nove estágios de produção. Segundo relatos, ele processa milhares de consultas diárias desde março de 2026, com tempos de resposta próximos de 15 segundos.

O pipeline começa combinando a solicitação com o contexto organizacional. Esse contexto pode incluir provedores de nuvem conectados, metadados da solicitação e detalhes necessários para interpretar o ambiente do usuário.

Em seguida, um mecanismo de correspondência determinística procura identificadores estruturados. Eles incluem endereços IP, identificadores CVE, hashes de arquivos, nomes de recursos, URLs e IDs de alertas.

Um identificador correspondente pode acionar um filtro predefinido sem uma chamada dispendiosa ao modelo. Esse caminho rápido mantém trabalhos previsíveis longe de um sistema probabilístico.

Solicitações que precisam de interpretação passam por uma barreira de proteção. A Orca afirma que esse estágio bloqueia tentativas de injeção de prompt, perguntas irrelevantes e entradas não compatíveis antes que alcancem a geração de consultas.

Em seguida, o sistema pesquisa uma biblioteca de exemplos validados. Embeddings Amazon Titan recuperam 20 candidatos semanticamente semelhantes, e o Cohere Rerank 3.5 reduz esse conjunto para cinco.

Um seletor de modelos reduz os mais de 900 modelos Sonar àqueles relevantes para a solicitação atual. O gerador recebe esquemas detalhados apenas desse grupo menor e de seus relacionamentos.

O Anthropic Claude Haiku 4.5 alimenta os estágios de seleção e geração. O Amazon Nova 2 Lite executa tarefas de barreira de proteção e validação, nas quais a Orca prioriza uma inferência mais rápida e de menor custo.

O filtro gerado ainda não se torna automaticamente o resultado final. Verificações estáticas resolvem cada modelo, campo e operador em relação aos esquemas selecionados.

A Orca também verifica o filtro na API Sonar. Quando a validação falha, o erro identifica o elemento problemático e o retorna ao gerador para correção.

Esse ciclo transforma a geração em um processo restrito. O modelo pode propor um filtro, mas sistemas determinísticos decidem se essa proposta está em conformidade com o esquema disponível.

Orca Security Discovery AI Reduz o Contexto de Propósito

O Orca Security Discovery AI melhorou sua economia relatada ao selecionar contexto, e não ao expandi-lo.

O protótipo inicial tratava o esquema completo do Sonar como contexto obrigatório. Essa escolha parecia razoável porque o modelo precisava entender centenas de tipos de recursos e seus relacionamentos.

O problema era que a maioria das perguntas abrangia apenas uma pequena parte desse esquema. Enviar cada definição em cada solicitação aumentava o uso de tokens sem tornar cada definição útil.

O seletor de modelos da Orca agora trabalha com descrições compactas dos modelos disponíveis. Cada descrição resume o nome, a finalidade, os campos importantes e os relacionamentos importantes de um modelo.

O seletor identifica quais modelos uma pergunta exige. O gerador então recebe o esquema completo apenas para essas seleções, além dos relacionamentos necessários para conectá-las.

Essa mudança reduziu o uso de entrada relatado de cerca de 2 milhões de tokens para 140.000 por carga de trabalho comparável. Isso representa a redução declarada de 93%.

A Orca atribui a redução de 90% nos custos ao menor volume de tokens e à alocação de modelos por estágio. Tarefas diferentes não usam mais, por padrão, o maior modelo disponível.

A latência teria caído de cerca de 60 segundos para 15 segundos, uma redução de 75%. O caminho mais rápido ainda contém vários estágios, mostrando que a contagem de estágios por si só não determina o tempo de resposta.

Uma inferência única e longa pode ser mais lenta do que diversas operações restritas. Regras e recuperação também podem ignorar a geração quando o sistema reconhece um padrão conhecido.

Esse é o mecanismo central por trás dos ganhos relatados. A Orca reduziu a quantidade de material que exige raciocínio aprofundado e reservou o trabalho generativo para partes não resolvidas da solicitação.

O design de recuperação segue o mesmo princípio. A busca semântica pura top-K era rápida, mas a Orca constatou que frequentemente retornava exemplos quase duplicados.

Essas duplicatas ocupavam contexto sem adicionar muita cobertura. A Relevância Marginal Máxima aumentou a diversidade, mas às vezes afastava o exemplo mais relevante do topo.

A Orca optou por recuperar 20 exemplos próximos e reclassificá-los para cinco. A primeira passagem maior enfatiza a recuperação, enquanto a reclassificação concentra o contexto final em correspondências mais fortes.

Uma correspondência de alta confiança pode reutilizar diretamente um filtro já comprovado. Caso contrário, os cinco exemplos mostram ao gerador como perguntas validadas foram traduzidas anteriormente.

Essa abordagem se assemelha mais ao raciocínio baseado em casos do que à geração irrestrita. O modelo trabalha a partir de um esquema compacto e de exemplos extraídos de comportamentos históricos bem-sucedidos.

A arquitetura também mantém as escolhas de modelos substituíveis. O Amazon Bedrock oferece acesso a várias famílias de modelos por meio de uma camada de serviço compartilhada, reduzindo o trabalho de integração separado.

Essa flexibilidade importa porque o modelo mais rápido ou mais preciso para um estágio pode mudar. Segundo relatos, a Orca pode substituir o modelo de um estágio sem redesenhar todo o aplicativo.

A lição mais ampla não é que todo sistema precisa de nove etapas. É que o contexto deve justificar seu lugar em um prompt de produção.

Esquemas, exemplos e histórico de conversa impõem custos mesmo quando um modelo suporta uma grande janela de contexto. Material irrelevante também pode competir com as evidências que importam.

Consultas de Segurança em Linguagem Natural Ainda Precisam de Limites Rígidos

Uma interface conversacional reduz a fricção da linguagem de consulta, mas não pode substituir autorização, validação ou conhecimento especializado em segurança.

Consultas de segurança em linguagem natural podem ajudar um analista a passar de uma ideia de investigação para um filtro estruturado. Elas não garantem que a própria pergunta seja autorizada ou completa.

O pipeline da Orca inclui contexto da solicitação, triagem por barreiras de proteção, geração restrita e duas formas de validação. Essa sequência reconhece o risco de tratar a saída do modelo como verdade executável.

A avaliação de barreiras de proteção do Amazon Bedrock pode inspecionar prompts e respostas em relação a políticas configuradas. Os controles disponíveis incluem filtros de conteúdo, tópicos negados, filtros de informações sensíveis e detecção de ataques a prompts.

No entanto, uma barreira de proteção não é um sistema de autorização. Ela pode classificar uma entrada sem ter a identidade do usuário e as permissões de recursos necessárias para uma decisão de acesso.

A orientação de segurança da AWS torna essa distinção explícita. Seus controles de autorização recomendam impor o acesso aos dados fora do modelo de linguagem e propagar a identidade do usuário pelos sistemas conectados.

Essa separação é especialmente importante para dados de segurança na nuvem. Uma consulta pode expor nomes de ativos, vulnerabilidades, relacionamentos entre contas, caminhos de rede ou detalhes de configuração interna.

Um assistente com amplo acesso ao backend pode se tornar um intermediário confuso. Isso ocorre quando um usuário com menos privilégios obtém informações por meio de um intermediário com mais privilégios.

A arquitetura segura deve restringir quais dados chegam ao modelo. Também deve garantir que a consulta Sonar resultante seja executada com permissões adequadas ao usuário solicitante.

A arquitetura publicada afirma que a Orca combina solicitações com contexto organizacional e de provedores de nuvem. A publicação não fornece uma descrição detalhada do isolamento entre locatários ou da aplicação de autorização em nível de usuário.

Essa omissão não estabelece uma vulnerabilidade. Ela simplesmente significa que os resultados de desempenho relatados não devem ser interpretados como uma avaliação de segurança completa.

A validação cria outro limite importante. A Orca verifica primeiro a sintaxe e depois valida o filtro gerado por meio de sua API Sonar.

O gerador recebe erros estruturados quando uma verificação falha. Ele pode revisar o campo, operador ou relacionamento específico, em vez de iniciar outra tentativa irrestrita.

Essa abordagem reduz uma classe de alucinação: referências a elementos de esquema que não existem. Ela não estabelece que toda consulta válida capture com precisão a intenção do analista.

Um filtro pode ser sintaticamente válido e semanticamente incompleto. Ele pode selecionar o modelo correto, mas omitir uma exceção, relacionamento, limite temporal ou condição ambiental.

Esse problema se torna mais grave quando uma solicitação concisa esconde ambiguidade. “Mostre bancos de dados expostos” pode depender de definições de exposição, tipo de banco de dados, acessibilidade de rede e risco aceito.

Uma interface robusta deve revelar premissas ou mostrar o filtro gerado para revisão. A publicação da AWS se concentra na geração e validação de filtros, não na experiência completa de revisão.

As equipes de segurança devem, portanto, distinguir a validade da consulta da correção investigativa. A primeira pode ser verificada por máquinas em relação a esquemas, enquanto a segunda frequentemente exige julgamento de domínio.

As saídas determinísticas do sistema também merecem atenção. Reutilizar um exemplo validado pode reduzir a latência, mas o limiar de correspondência deve impedir que perguntas superficialmente semelhantes compartilhem um filtro inadequado.

A Orca afirma encaminhar consultas de baixa confiança a especialistas do domínio. Esse processo de feedback ajuda, embora sua eficácia dependa da amostragem, da cobertura de revisão e da qualidade das correções.

O acesso em linguagem natural pode ampliar a participação em investigações de segurança. Também transfere a responsabilidade dos autores de consultas para os projetistas da plataforma que codificam essas salvaguardas.

O Verdadeiro Adversário É o Design de Um Modelo, Um Prompt

A comparação mais relevante da Orca não é com outro fornecedor, mas com o protótipo monolítico que ela substituiu.

Produtos de IA generativa frequentemente começam como um prompt conectado a um modelo capaz. Essa estrutura funciona bem para comprovar se um modelo entende a tarefa.

Ela se torna mais difícil de defender quando a aplicação enfrenta tráfego real, esquemas em mudança, requisitos rígidos de latência e dados organizacionais sensíveis.

A linha de base da Orca expôs essa transição. O protótipo produzia respostas promissoras, mas enviava um vasto esquema em cada solicitação e ainda tinha dificuldades com relacionamentos complexos.

O sistema de produção transfere várias responsabilidades para fora do gerador. Expressões regulares reconhecem identificadores exatos, a recuperação encontra exemplos, o reranking reduz o ruído e validadores rejeitam filtros malformados.

Essa divisão produz uma inversão importante. Adicionar componentes reduziu o custo e a latência totais porque esses componentes evitaram trabalho generativo desnecessário.

O pipeline também desafia a aquisição centrada em modelos. Escolher o maior modelo não resolveu sozinho o problema de produção.

Em vez disso, a Orca atribuiu modelos conforme os requisitos da tarefa. As etapas que exigiam mais raciocínio receberam Claude Haiku 4.5, enquanto etapas mais restritas de triagem e validação receberam Nova 2 Lite.

Amazon Titan criou embeddings para a busca semântica. Cohere Rerank 3.5 pontuou os exemplos recuperados antes da geração.

Essa combinação cria complexidade operacional. As equipes precisam monitorar vários modelos, o comportamento de recuperação, loops de validação e dependências, em vez de uma única chamada de API.

Ainda assim, uma arquitetura de chamada única esconde a complexidade dentro de um prompt grande. Ela não elimina o gerenciamento de esquemas, a avaliação, a autorização ou o tratamento de erros.

Trabalhos anteriores da AWS sobre investigações em linguagem natural mostraram um padrão relacionado para o Amazon Security Lake. Um agente traduziu perguntas de analistas em SQL e deu suporte a análises de acompanhamento sobre logs de segurança.

A implementação da Orca tem como alvo seu próprio grafo de dados Sonar e filtros específicos do domínio. Seu diferencial é a redução agressiva de esquemas e exemplos antes da geração.

Esse padrão pode ser aplicado além da segurança em nuvem. Sistemas empresariais frequentemente expõem centenas de objetos, campos, relacionamentos e operações permitidas.

Plataformas de suporte ao cliente, ferramentas de análise, portais para desenvolvedores e sistemas de conhecimento enfrentam a mesma tentação de colocar todas as definições no prompt. Essa abordagem pode funcionar em demonstrações e falhar sob a economia de produção.

A alternativa se assemelha a um pipeline de compilador. O sistema analisa a solicitação, identifica estruturas relevantes, recupera precedentes, gera uma representação intermediária e a valida.

O modelo de linguagem lida com ambiguidade e tradução. Componentes determinísticos lidam com regras aplicáveis.

Essa distribuição também torna as falhas mais fáceis de localizar. Uma equipe pode determinar se a recuperação deixou de encontrar um exemplo relevante, a seleção omitiu um esquema ou a validação rejeitou um operador.

Um único prompt frequentemente produz um sinal de falha menos útil. A resposta está simplesmente errada, é cara, lenta ou alguma combinação dos três.

A Orca afirma que seu mecanismo de avaliação mede correção, completude e equivalência semântica em relação a consultas de referência. Também divide os resultados em segmentos com base em categorias de perguntas e modelos.

Isso é mais informativo do que uma única pontuação agregada. Um sistema pode ter bom desempenho geral e, ainda assim, falhar em relacionamentos multicloud raros ou condições complexas de vulnerabilidade.

O design pressiona outras equipes de IA empresarial a reportar resultados em nível de sistema. Pontuações de benchmarks de modelos, por si só, não conseguem explicar a latência da aplicação, a qualidade da recuperação, as taxas de validação ou as cargas de trabalho de correção.

Os Números São Fortes, mas as Evidências de Precisão São Incompletas

As melhorias de custo e latência são específicas, enquanto a alegação pública de precisão não apresenta o mesmo nível de detalhamento de medição.

AWS e Orca fornecem números claros de antes e depois para tokens, custo e tempo de resposta. Elas não publicam o conjunto de dados de avaliação, o tamanho da amostra, a taxa de aprovação ou a melhoria exata de precisão.

A publicação afirma que a precisão melhorou para consultas complexas e multimodelo. Também descreve um sistema de LLM como juiz que avalia correção, completude e equivalência semântica.

Um LLM como juiz usa outro modelo para avaliar resultados gerados. Ele pode apoiar iterações rápidas, mas suas conclusões dependem da rubrica, das respostas de referência e da confiabilidade do avaliador.

A Orca complementa a pontuação automatizada com especialistas internos e feedback de clientes. Gerentes de produto, engenheiros de suporte e pesquisadores de segurança podem sinalizar resultados e adicionar exemplos corrigidos.

Consultas de produção de baixa confiança supostamente entram em uma fila diária de rotulagem. As correções ficam disponíveis para execuções subsequentes de recuperação sem exigir uma implantação de software.

O diretor de IA da Orca, Or Gabay, chamou essa interface de rotulagem de seu investimento mais importante de longo prazo em qualidade. A declaração destaca um processo humano, em vez de outra atualização de modelo.

Esse processo é crível como mecanismo de melhoria. Ainda deixa várias perguntas sem resposta para compradores externos e equipes de engenharia.

A publicação pública não divulga com que frequência a geração atinge o limite de tentativas. Também não informa quantas solicitações seguem caminhos determinísticos ou de reutilização de exemplos.

Ela tampouco separa a latência mediana da latência de cauda. Um valor de 15 segundos pode descrever uma carga de trabalho típica enquanto oculta solicitações complexas mais lentas.

A expressão “carga de trabalho comparável” precisa de mais definição. As reduções de tokens e custos dependem da combinação de solicitações, dos modelos selecionados, do comportamento de cache, do tamanho da saída e do número de tentativas.

A redução de custo reportada também compara o pipeline de produção com a linha de base inicial da própria Orca. Não se trata de um benchmark em relação a outros produtos de segurança em nuvem ou sistemas de geração de consultas.

Os leitores devem tratar as porcentagens como resultados operacionais reportados pela empresa. O estudo de caso da AWS, elaborado em coautoria, fornece detalhes técnicos, mas não é uma auditoria independente.

A data de produção em março de 2026 e milhares de consultas diárias fornecem um sinal útil de adoção. Não revelam usuários únicos, taxas de aceitação, abandono ou tempo economizado por analistas.

Essas métricas ajudariam a determinar se a linguagem natural muda o comportamento investigativo. Custos de inferência menores importam, mas o valor para o usuário depende, em última análise, de decisões de segurança melhores e mais rápidas.

O loop de feedback do sistema introduz outra troca. Exemplos de produção melhoram a cobertura, mas as correções podem codificar interpretações inconsistentes, a menos que especialistas sigam uma política compartilhada.

Um banco crescente de exemplos também exige governança. As equipes precisam de versionamento, revisão de qualidade, procedimentos de remoção e proteção contra a entrada de informações sensíveis em exemplos recuperados.

As orientações da AWS para aplicações de IA generativa recomendam limitar os dados recuperados antes que cheguem a um modelo. Seus controles de segurança enfatizam a propagação de identidade e a aplicação de acesso na camada de dados.

Essas preocupações não anulam os resultados da Orca. Elas definem as evidências necessárias antes que outra organização trate a arquitetura como um modelo reutilizável.

A conclusão pública mais sólida é limitada, mas útil. A Orca relata que a seleção de contexto, a especialização de modelos, a recuperação e a validação melhoraram drasticamente seu design original.

As evidências não estabelecem uma redução universal para todo agente com muitos esquemas. As equipes devem medir o padrão em relação às próprias cargas de trabalho e requisitos de autorização.

O Que Observar Após a Implantação da Orca no Amazon Bedrock

O próximo teste é verificar se a Orca consegue preservar a qualidade à medida que esquemas, comportamento dos usuários e versões de modelos continuam mudando.

O primeiro sinal é a publicação de detalhes sobre precisão. Um futuro relatório técnico deveria divulgar o tamanho do conjunto de dados, as categorias de consultas, os limites de aprovação e a concordância da revisão humana.

Resultados em nível de segmento seriam particularmente valiosos. Consultas de relacionamento multimodelo parecem ser a categoria mais difícil e o teste mais rigoroso da arquitetura da Orca.

Uma avaliação mais transparente fortaleceria a alegação de que o novo design melhorou a precisão, e não apenas a eficiência. Taxas crescentes de correção ou de novas tentativas enfraqueceriam essa conclusão.

O segundo sinal é a adoção sustentada em produção. A Orca afirma que o Discovery AI processa milhares de consultas diárias, mas os padrões de uso no longo prazo mostrarão se os analistas confiam na interface.

Indicadores úteis incluem uso recorrente, filtros aceitos, edições manuais, tempo economizado e a parcela de perguntas resolvidas sem escalonamento. Essas medidas conectam o comportamento do modelo às operações de segurança.

O terceiro sinal é como o pipeline lida com mudanças. Os esquemas do Sonar evoluirão, os clientes farão perguntas desconhecidas e os modelos fundamentais receberão novas versões.

O design independente de modelo da Orca deve facilitar substituições. No entanto, cada mudança ainda exige testes de regressão em recuperação, geração, validação e limites de autorização.

O mecanismo de avaliação contínua é, portanto, tão importante quanto a arquitetura inicial. Cada prompt, modelo, configuração de recuperação e exemplo pode alterar o comportamento em segmentos inesperados.

O sistema também precisa permanecer útil diante da mudança no comportamento de ameaças. Analistas podem mapear investigações para a estrutura de ameaças em nuvem enquanto atacantes adotam novos caminhos e combinações de recursos.

Uma biblioteca estática de exemplos se degradaria nessas condições. O loop de rotulagem por especialistas da Orca busca manter o banco de recuperação alinhado a questões emergentes.

Para equipes de engenharia, a ação imediata é examinar onde prompts grandes contêm material que a maioria das solicitações nunca usa. Esse material pode pertencer a uma camada de seleção, recuperação ou roteamento determinístico.

As equipes também devem separar três testes: se uma consulta é válida, se representa a intenção do usuário e se o usuário pode acessar seus resultados.

O Orca Security Discovery AI oferece um caso de produção notável para essa abordagem em camadas. Seus ganhos de eficiência reportados são substanciais, mas sua contribuição mais profunda é uma mudança no design de sistemas.

A questão agora é se a Orca publicará evidências operacionais suficientes para mostrar que essa eficiência resiste à evolução dos esquemas e ao uso adversarial. Essas evidências determinarão se o padrão se tornará um padrão mais amplo para agentes empresariais.