SecRespond Descobre que 23 Modelos de IA de Ponta Não Detectam Intrusões Silenciosas

O SecRespond chegou ao Google News com um resultado contundente: nenhum dos 23 modelos de ponta concluiu a detecção e a remediação em qualquer host comprometido testado. Os agentes lidaram muito melhor com alertas visíveis do que com evidências silenciosas, expondo uma lacuna entre a triagem assistida por IA e a resposta autônoma a incidentes.

Pesquisadores do Alibaba Group submeteram o artigo do SecRespond em 29 de julho de 2026. Eles testaram modelos de várias famílias importantes por meio do OpenCode, um ambiente de agentes que permite aos modelos inspecionar arquivos e usar ferramentas de linha de comando.

O teste começa depois que um invasor já foi bem-sucedido. Esse detalhe cria o conflito central do estudo. Agentes de IA conseguem seguir um alerta, mas um centro de operações de segurança precisa de investigadores que também encontrem ameaças que ninguém sinalizou.

Por isso, o SecRespond desafia uma promessa comum da automação. Um modelo que resume alertas pode reduzir a carga de trabalho dos analistas, mas isso não o torna um respondedor de incidentes independente. O benchmark encontrou a diferença em artefatos de disco, mecanismos de persistência, etapas de limpeza incompletas e planos de remediação não verificados.

O Que o Benchmark SecRespond Realmente Mudou

O SecRespond desloca o alvo da avaliação da interpretação de alertas para a investigação de uma máquina já comprometida.

Muitos testes de cibersegurança começam antes do comprometimento. Eles pedem que um modelo identifique uma vulnerabilidade, resolva um desafio capture-the-flag, classifique malware ou raciocine sobre logs de segurança selecionados. Essas tarefas medem capacidades úteis, mas reduzem a incerteza que define uma violação real.

O SecRespond começa mais tarde. Cada agente recebe um snapshot forense congelado do disco de um host em nuvem comprometido. Também recebe resultados sintéticos semelhantes a alertas, varreduras de vulnerabilidades e verificações de linha de base de segurança de um produto de proteção de hosts.

Um snapshot forense de disco é uma cópia preservada dos arquivos e artefatos de um sistema em um momento específico. Ele pode conter evidências nunca mencionadas em alertas, incluindo arquivos de inicialização modificados, contas de backdoor, logs apagados, tarefas agendadas ou binários maliciosos.

O agente precisa inspecionar esse material e reconstruir o que aconteceu. Em seguida, produz relatórios sobre intrusões, vulnerabilidades, riscos de linha de base e remediação. A tarefa também exige um arquivo de progresso, criando um registro da investigação em vez de aceitar uma única resposta final bem elaborada.

O benchmark contém 10 cyber ranges, ou seja, ambientes isolados criados para reproduzir incidentes de segurança. Esses ambientes abrangem quatro tipos de pontos de entrada iniciais, 21 técnicas do catálogo MITRE ATT&CK e cinco sistemas operacionais.

Os pesquisadores traduziram esses ambientes em 52 itens de capacidade e 280 pontos de verificação detalhados. Os pontos de verificação avaliam se um agente encontrou evidências concretas, fez a atribuição correta, recomendou uma ação adequada e incluiu a verificação necessária.

A detecção e o planejamento de remediação recebem pontuações separadas. A detecção tem um máximo de três pontos por ponto de verificação aplicável. O planejamento tem um máximo de dois, enquanto pontos que não se aplicam a uma dimensão são excluídos desse agregado.

Essa separação é importante porque encontrar um arquivo malicioso não responde o que os responsáveis devem fazer em seguida. Uma resposta segura pode exigir isolar um host, preservar evidências, encerrar processos, remover persistência, rotacionar credenciais, bloquear infraestrutura, restaurar serviços e verificar a recuperação.

O conjunto de dados público do SecRespond inclui os prompts das tarefas, materiais de avaliação, listas de verificação, resultados sintéticos de segurança e arquivos forenses. Sua publicação torna a alegação central testável por equipes além dos autores originais.

O SecRespond também define um limite mais rigoroso para a resposta a incidentes por IA. Um agente não recebe crédito total porque provavelmente verificou algo. Seu relatório precisa declarar a descoberta e citar evidências que satisfaçam a lista de verificação relevante.

Essa regra transforma linguagem de segurança vaga em desempenho mensurável. “Investigar atividade suspeita” não equivale a identificar um processo, arquivo, conta, endpoint ou caminho de persistência específico. “Aplicar patches no servidor” não equivale a um plano de recuperação completo, sequenciado e verificado.

A cobertura do Google News concentrou-se na falha principal entre 23 modelos. A mudança mais profunda é metodológica. O SecRespond pergunta se um agente consegue seguir pistas que nunca lhe foram entregues e então conectar essas descobertas a um processo de limpeza defensável.

Por Que a Atenção do Google News Importa para Compradores de Segurança de IA

O benchmark pressiona fornecedores e líderes de segurança a distinguirem assistência a alertas de resposta autônoma a incidentes.

A IA já ajuda centros de operações de segurança a resumir alertas, enriquecer indicadores, pesquisar documentação, redigir consultas e preparar anotações de casos. Esses fluxos de trabalho continuam valiosos porque analistas frequentemente enfrentam evidências fragmentadas e tarefas administrativas repetitivas.

No entanto, o SecRespond mede um nível mais alto de independência. Um respondedor autônomo precisa decidir onde investigar, reconhecer evidências ausentes, testar explicações concorrentes e continuar depois que o alerta mais óbvio tiver sido resolvido.

O resultado central do benchmark mostra por que essa distinção importa. Entre os 23 modelos avaliados, nenhum agente alcançou detecção e remediação completas sequer em um cyber range.

O melhor modelo geral no experimento relatado foi o Claude Opus 4.7. Ele alcançou uma pontuação média de 79,0% nos pontos de verificação em nível de ambiente para detecção e 65,7% para planejamento.

O artigo também relata uma média de 72,4% ao combinar essas dimensões para o modelo líder. Esse desempenho ainda deixou artefatos maliciosos sem tratamento e a remediação incompleta, especialmente em ambientes com cadeias de ataque mais longas e amplas.

Outros resultados de destaque incluíram Claude Opus 4.6, com 78,2% em detecção e 58,0% em planejamento. GLM-5.1 alcançou 76,3% e 59,2%, enquanto Qwen3.7 Plus alcançou 75,6% e 58,8%.

Esses números não devem se tornar um ranking geral dos modelos subjacentes. Eles descrevem um ambiente de agentes, uma versão do benchmark, um desenho de tarefa e um processo de avaliação específicos.

Em vez disso, os resultados expõem um padrão de falha compartilhado. Os modelos encontraram com mais confiabilidade evidências conectadas a alertas existentes do que evidências que exigiam uma busca não solicitada no disco.

Esse padrão pressiona fornecedores de segurança que usam rótulos amplos como “analista de IA” ou “SOC autônomo”. Compradores precisam perguntar quais partes do ciclo de resposta o sistema realmente executa sem uma pista criada por humanos.

Um produto pode resumir com precisão um alerta de endpoint e ainda assim ignorar um segundo mecanismo de persistência. Pode recomendar a exclusão de um binário malicioso sem encerrar seu processo, remover seu carregador, rotacionar credenciais expostas ou verificar a recuperação do serviço.

Cada etapa omitida altera o resultado operacional. Um invasor pode retornar por meio de uma conta, tarefa agendada, webshell, serviço, entrada de registro ou hook de shell que permaneceu intacto. Portanto, uma primeira ação tecnicamente correta pode criar uma falsa sensação de contenção.

Líderes de segurança também precisam separar a qualidade da investigação da qualidade do relatório. Os modelos frequentemente produzem explicações fluentes, mas o SecRespond avalia se essas explicações contêm as evidências e os detalhes de remediação exigidos.

Esse é um problema conhecido em trabalhos intensivos em conhecimento. Uma narrativa confiante pode ocultar uma recuperação incompleta de informações. Equipes que constroem uma base de conhecimento pesquisável enfrentam uma exigência relacionada: as conclusões precisam permanecer rastreáveis ao material de origem.

O benchmark torna essa rastreabilidade concreta para a resposta a incidentes. Um agente precisa mostrar qual artefato sustenta cada conclusão e qual ação aborda cada condição identificada.

A visibilidade no Google News pode levar essa distinção além dos pesquisadores de benchmarks. Equipes de compras, CISOs, provedores de segurança gerenciada e grupos internos de auditoria agora têm um exemplo público de por que “lida com alertas” e “lida com incidentes” não são alegações equivalentes.

O Verdadeiro Ponto Cego É a Investigação Sem Direcionamento

O comportamento mais fraco dos modelos aparece quando um incidente não deixa um alerta óbvio apontando para o próximo artefato.

O SecRespond agrupa o desempenho em cinco áreas de capacidade. Elas abrangem entidades de intrusão, mecanismos de persistência, riscos de linha de base, riscos de vulnerabilidade e qualidade geral de investigação e resposta.

Uma entidade de intrusão é um objeto malicioso concreto, como um processo, arquivo, endpoint de rede ou artefato adulterado. Os modelos tiveram melhor desempenho nessa categoria porque esses objetos frequentemente estavam alinhados a sinais de segurança visíveis.

Entre os modelos, a detecção média chegou a 75,4% para entidades de intrusão. Vários sistemas líderes tiveram desempenho substancialmente melhor, incluindo Qwen3.7 Plus, com 88,4%, e Claude Opus 4.6, com 86,0%.

Os mecanismos de persistência produziram um resultado diferente. Persistência refere-se a alterações que permitem que o acesso de um invasor sobreviva a uma reinicialização ou a uma limpeza inicial. Exemplos incluem tarefas agendadas, serviços, hooks de inicialização do shell, webshells, backdoors de contas e assinaturas do Windows Management Instrumentation.

A detecção média caiu para 58,8% em persistência. A queda importa porque a persistência é precisamente o que os responsáveis precisam encontrar antes de declarar um host limpo.

O benchmark não mostra que os modelos não possuam qualquer raciocínio forense. Eles conseguem conectar um alerta a um processo ou arquivo relevante e frequentemente descrever corretamente a ameaça imediata. A falha surge quando a investigação precisa se expandir além desse ponto de partida.

Considere um servidor web comprometido. Um alerta pode identificar um processo malicioso ou uma conexão de saída. Seguir esse sinal pode revelar um executável, mas uma investigação completa precisa perguntar como o invasor entrou, quais credenciais foram expostas e o que sobrevive ao encerramento.

O responsável também pode precisar inspecionar scripts de inicialização, definições de serviços, entradas de cron, contas de usuários, históricos de comandos, diretórios de aplicações e logs alterados. Nenhum alerta isolado necessariamente identifica esses locais.

Isso cria um problema de busca com limites incertos. O agente precisa decidir quais hipóteses merecem ser testadas e por quanto tempo continuar. Ele precisa reconhecer que a ausência de um artefato não elimina outras rotas de persistência.

Agentes atuais baseados em modelos de linguagem frequentemente otimizam em torno das evidências já presentes no contexto. Alertas criam âncoras de alta saliência, de modo que o agente pode gastar seu orçamento explicando essas âncoras em vez de procurar evidências não mencionadas.

Cadeias de ataque mais longas amplificam essa fraqueza. Cada técnica adicional introduz outro ramo, tipo de artefato, carimbo de data e hora, conta ou serviço que o modelo precisa correlacionar.

O artigo constatou que o desempenho diminuiu à medida que os ataques se tornaram mais longos e amplos. Esse resultado condiz com o desafio operacional: resposta a incidentes não é uma única decisão de classificação, mas uma sequência de julgamentos interligados sob informações incompletas.

Um benchmark de threat hunting separado, de 2026, relatou um problema relacionado. Cinco modelos de ponta pesquisaram logs brutos de eventos do Windows de 26 campanhas de ataque, e o melhor modelo encontrou apenas uma pequena fração dos eventos maliciosos.

Os dois estudos testam fluxos de trabalho diferentes, portanto suas pontuações não são diretamente comparáveis. No entanto, ambos sugerem que a busca sem direcionamento continua mais difícil do que raciocinar sobre evidências pré-selecionadas.

Esta é a reversão central do benchmark. Os agentes parecem mais capazes onde as ferramentas convencionais de segurança já reduziram a incerteza. Eles se tornam menos confiáveis onde os investigadores humanos agregam mais valor ao questionar o que o alerta não revelou.

Uma equipe de segurança ainda pode usar IA de forma produtiva dentro desse limite. O modelo pode resumir evidências, propor hipóteses, redigir consultas, comparar artefatos e manter uma linha do tempo da investigação.

O salto inseguro é tratar essas capacidades como prova de que o modelo investigou todo o incidente. O SecRespond mostra que uma resposta articulada pode coexistir com persistência não descoberta e uma descrição incompleta da atividade do invasor.

As Pontuações de Detecção Escondem uma Lacuna Maior de Remediação

Encontrar mais evidências não se traduziu em planos de limpeza igualmente completos, tornando a remediação a segunda grande falha do benchmark.

Todos os modelos avaliados obtiveram pontuações mais altas em detecção do que em planejamento. Para o GPT-5.5, a lacuna relatada chegou a 34,7 pontos percentuais.

Os pesquisadores atribuem esse padrão à aplicação, pelos agentes, de uma primeira correção óbvia enquanto omitem ações restantes. Esse comportamento se assemelha ao truncamento de checklist: assim que o objeto malicioso central recebe uma resposta, o modelo se comporta como se o incidente estivesse resolvido.

A remediação real raramente termina com uma exclusão ou alteração de configuração. Um responsável pela resposta deve considerar dependências, preservação de evidências, impacto nos negócios, continuidade de serviço, exposição de credenciais e caminhos alternativos de acesso do invasor.

A pontuação de planejamento do SecRespond avalia se uma ação é correta e completa. Ela também examina a verificação e os efeitos colaterais quando o ponto de controle relevante os exige.

A verificação não é meramente protocolar. Um plano para remover uma tarefa agendada deve confirmar que a tarefa não existe mais e que sua carga útil não pode ser iniciada por outro mecanismo.

Um plano para bloquear o endereço de um invasor deve tratar tanto o tráfego de entrada quanto o de saída, quando apropriado. Ele também deve evitar sugerir que um bloqueio de endereço elimina malware, credenciais roubadas ou persistência já presente no host.

Problemas padronizados de configuração se mostraram mais fáceis. Claude Opus 4.7 alcançou 74,8% em planejamento para riscos de linha de base e 72,6% para riscos de vulnerabilidade.

Essas tarefas frequentemente correspondem a ações conhecidas, como reforçar uma configuração ou atualizar software afetado. O agente pode recuperar um padrão de remediação reconhecível e aplicá-lo à descoberta.

A qualidade de investigação e resposta permaneceu muito mais fraca. O desempenho médio de planejamento nessa categoria alcançou apenas 31,8%.

Essa categoria abrange trabalhos que dependem de síntese, e não de uma única correção conhecida. Ela inclui reconstrução da cadeia de ataque, qualidade das evidências, honestidade sobre a incerteza, completude, verificação e consciência do impacto operacional.

O resultado de detecção mais forte nessa categoria alcançou 75,5%. Quase todos os modelos permaneceram abaixo de 50% em planejamento, segundo o artigo.

Esses resultados enfraquecem uma estratégia simples de ampliação de escala. Dar mais alertas a um modelo não cria automaticamente um plano de resposta completo. Descobertas mais visíveis podem, em vez disso, produzir mais recomendações desconectadas.

Um plano confiável precisa de ordenação. As equipes podem isolar uma máquina antes de modificá-la, preservar evidências voláteis antes de encerrar processos e rotacionar credenciais após determinar o escopo da exposição.

Elas também precisam considerar reversão e serviços. Remover um componente comprometido sem compreender suas dependências pode interromper a produção ou destruir evidências necessárias para atribuição.

O SecRespond avalia planos escritos, e não remediação ao vivo em sistemas de produção. Isso limita o que o benchmark pode estabelecer, mas também mantém visível a questão de segurança.

Se um modelo não consegue descrever de forma consistente uma remediação completa e verificada em um ambiente controlado, as organizações têm pouca base para conceder-lhe autoridade irrestrita em um host ativo.

Portanto, o benchmark sustenta um modelo operacional mais restrito. A IA pode sugerir ações, organizar evidências e destacar campos ausentes, enquanto os responsáveis humanos mantêm a aprovação para etapas de contenção e recuperação.

Esse arranjo não é uma rejeição da automação de SOC. É uma resposta à assimetria específica dos dados. Os sistemas foram melhores em identificar objetos conhecidos do que em garantir que cada consequência recebesse tratamento seguro.

As equipes de segurança devem refletir essa assimetria nos controles de acesso. O acesso forense somente leitura apresenta um risco diferente da permissão para encerrar processos, excluir arquivos, desativar contas ou alterar políticas de rede.

Um agente que deixa de identificar um artefato oculto produz um relatório incompleto. Um agente que age com base nesse relatório incompleto pode interromper a recuperação enquanto deixa intacta a rota alternativa do invasor.

O Que os Números Não Comprovam

O SecRespond é uma forte evidência de uma limitação compartilhada, mas não é um veredito final sobre todos os modelos ou configurações de SOC em produção.

O artigo é um preprint no arXiv, e não o resultado de uma revisão por pares concluída. Seus autores incluem pesquisadores do Tongyi Lab e do Alibaba Cloud, e o benchmark avalia modelos por meio de um ambiente de teste representativo.

A escolha do OpenCode ajuda a padronizar o uso de ferramentas entre os sistemas. Isso também significa que os resultados medem uma combinação de modelo e ambiente de teste, e não uma capacidade abstrata do modelo separada de prompting, ferramentas, gestão de contexto e política de execução.

Diferentes estruturas de suporte podem alterar o desempenho. Um agente de resposta a incidentes poderia usar um checklist obrigatório de investigação, utilitários forenses especializados, recuperação de procedimentos internos, múltiplos agentes cooperantes ou scripts determinísticos de validação.

O SecRespond continua útil porque essas melhorias podem ser testadas nas mesmas faixas. No entanto, os números publicados não devem ser tratados como limites permanentes para cada família de modelos.

A avaliação também utiliza um processo de LLM como juiz, ou seja, modelos de linguagem avaliam relatórios gerados com base em checklists detalhados. Três juízes proprietários foram usados de forma independente para reduzir a dependência de um único avaliador.

Esses juízes foram Claude Opus 4.7, Gemini 3.1 Pro e GPT-5.4 Pro. Vários juízes reduzem o viés individual, mas não eliminam todos os problemas de calibração.

Um avaliador pode interpretar uma formulação incompleta de maneira diferente de um especialista humano em perícia forense. Ele também pode premiar linguagem explícita no relatório sem resolver plenamente se o processo de investigação subjacente foi sólido.

As instruções de pontuação tentam controlar esse risco. Os juízes devem citar evidências e conceder crédito apenas por conteúdo explicitamente presente nos relatórios.

Os 280 pontos de controle do benchmark fornecem estrutura adicional. Ainda assim, todo checklist incorpora escolhas sobre quais artefatos, etapas de resposta e qualidades merecem peso.

As 10 faixas são suficientemente diversas para revelar comportamentos recorrentes. Elas não abrangem todos os sistemas operacionais, arquiteturas de nuvem, plataformas de identidade, produtos de endpoint ou técnicas de invasores.

Os ambientes também são controlados. Os pesquisadores provisionaram e comprometeram os hosts para o benchmark e, depois, sanitizaram credenciais e dados pessoais.

Esse desenho permite reprodutibilidade e evita a exposição de informações de produção. Ele não consegue reproduzir integralmente o ruído, a telemetria incompleta, as restrições organizacionais e as dependências de negócio de um incidente empresarial real.

Um resultado também ilustra como o comportamento de segurança pode afetar a cobertura do benchmark. Claude Opus 4.7 recusou a tarefa do npm-worm, por isso o artigo omitiu esse modelo da tabela detalhada de pontos de controle da faixa.

Uma recusa pode reduzir a utilidade operacional durante uma investigação defensiva legítima. Ela também pode refletir o esforço de um provedor para impedir que assistência de uso dual derive para orientações prejudiciais.

O SecRespond não resolve esse dilema de política. Ele mostra que uma implantação segura precisa de definições de tarefa que diferenciem trabalho forense autorizado de instruções ofensivas.

Os autores do benchmark afirmam que as evidências divulgadas vêm de ambientes isolados e não contêm cadeias de exploração executáveis. Os materiais públicos destinam-se à pesquisa defensiva.

Essa restrição importa ao interpretar alegações sobre resposta no “mundo real”. As faixas recriam comprometimentos de ponta a ponta por protocolos de rede reais, mas o pacote divulgado contém evidências forenses sanitizadas, e não ferramentas ativas de ataque.

Também não há um estudo de campo independente mostrando como as pontuações do SecRespond se traduzem em tempo economizado pelos analistas, redução da gravidade de incidentes ou maior velocidade de contenção. Esses resultados exigem avaliações dentro de equipes operacionais.

Para compradores, portanto, a leitura correta deve ser ponderada. O benchmark questiona fortemente alegações sem sustentação sobre resposta autônoma a incidentes. Ele não mostra que a assistência de IA não tenha valor dentro de um SOC liderado por humanos.

Ele também não estabelece que um modelo nomeado permanecerá à frente em versões futuras. A série Claude relatada melhorou entre lançamentos, enquanto o progresso em outras famílias não foi universal.

A unidade significativa de avaliação é o sistema implantado. Isso inclui o modelo, ferramentas, prompts, permissões, fontes de recuperação, etapas de revisão, registros e procedimentos de recuperação.

Três Sinais para Acompanhar Após o Ciclo de Notícias do Google sobre o SecRespond

O próximo teste é se os fornecedores melhoram a descoberta sem orientação, a verificação de remediação e a avaliação reprodutível em produção.

O primeiro sinal é a reprodução independente. Pesquisadores e fornecedores de segurança podem executar o repositório público do benchmark com outros ambientes de teste, prompts, ferramentas e versões de modelos.

A reprodução mostrará se a lacuna de intrusão silenciosa persiste diante de mudanças na estrutura de suporte. Se agentes forenses especializados ainda deixarem de identificar persistência sem alerta, o julgamento central do artigo se fortalece.

Se procedimentos determinísticos de busca produzirem grandes ganhos, a lição muda ligeiramente. O gargalo estaria menos no conhecimento do modelo e mais no desenho da investigação, no roteamento de ferramentas e na cobertura obrigatória.

Isso ainda enfraqueceria alegações sobre agentes autônomos de uso geral. Também forneceria um caminho de engenharia mais claro para sistemas mais seguros.

O segundo sinal é se os fornecedores publicam resultados separados de detecção e remediação. Um único número de “precisão de resposta a incidentes” pode ocultar a lacuna de planejamento que o SecRespond revelou.

Avaliações úteis devem indicar o que o sistema encontrou, o que deixou de identificar, qual ação propôs e como verificou a conclusão. Elas também devem relatar recusas, falhas de ferramentas e casos que exigiram intervenção humana.

Acompanhe testes sobre mecanismos de persistência especificamente. Melhorias em malware vinculado a alertas são importantes, mas não tratam do principal ponto cego do benchmark.

Observe também se os planos abrangem a extensão da limpeza. Um agente mais forte deve lidar, quando aplicável, com processos, arquivos, contas, execução agendada, controles de rede, rotação de credenciais, recuperação de serviço e validação pós-remediação.

O terceiro sinal são evidências de implantações supervisionadas em SOCs. Os fornecedores precisam mostrar como seus agentes se comportam com telemetria real, procedimentos internos, controles de acesso e etapas de aprovação por analistas.

A evidência operacional mais forte não será apenas um estudo de caso bem produzido. Ela incluirá taxas de falha, taxas de escalonamento, alegações sem sustentação, frequência de correções e o percentual de recomendações que os analistas aprovam sem alterações.

Uma implantação confiável deve preservar uma trilha de auditoria. Os revisores precisam rastrear conclusões até os artefatos e determinar quais buscas o agente concluiu antes de parar.

As organizações também devem testar os limites de permissão. Investigação somente leitura, ações recomendadas e execução autônoma representam três níveis de risco distintos.

O SecRespond apoia a adoção nos dois primeiros níveis, enquanto impõe um pesado ônus de prova ao terceiro. Seus resultados não justificam entregar amplos poderes de contenção a um modelo que não demonstrou descoberta abrangente.

A manchete do Google News vai desaparecer, mas o benchmark deixa as equipes de segurança com uma questão duradoura de aquisição: o que o agente encontra quando nenhum alerta lhe diz onde procurar?

Peça aos fornecedores que respondam a essa pergunta com evidências reproduzíveis. Em seguida, pergunte como o sistema verifica cada etapa de limpeza e sinaliza incerteza a um responsável humano pela resposta.

Essas respostas revelarão se os produtos de AI SOC estão se tornando investigadores ou permanecendo assistentes rápidos em torno das detecções existentes. Por enquanto, o SecRespond coloca todos os 23 modelos testados no lado dos assistentes dessa linha.