Quando um agente de IA opera uma interface com caixas de seleção, filtros ou tabelas de seleção múltipla, o risco principal não é o clique errado: é agir sobre um conjunto diferente do que você imaginava. A seleção pode sobreviver à troca de página, o botão de selecionar tudo pode incluir itens escondidos pelo filtro, uma linha marcada antes da sessão continua marcada, e o cabeçalho pode mostrar uma contagem que não bate com o que está visível na tela.
A solução prática tem três partes: ler a contagem antes de agir, listar explicitamente os itens afetados e comparar com o esperado. Quando o volume é grande ou a ação é destrutiva, limpe a seleção e remonte o conjunto do zero, prefira agir item por item e exija confirmação humana antes de qualquer operação em lote que não tenha desfazer.
Resumo rápido
- Seleção múltipla vive em algum estado (memória da página, sessão do servidor ou a própria interface), e esse estado pode conter itens que não estão visíveis agora.
- Filtrar normalmente não limpa a seleção: o filtro esconde linhas, mas não desmarca o que já estava marcado.
- “Selecionar tudo” costuma marcar o resultado inteiro da consulta, não apenas as linhas que você está vendo.
- Antes de agir, leia a contagem do cabeçalho, compare com as linhas visíveis e liste os identificadores que serão afetados.
- Em ações destrutivas ou financeiras em lote, limpe a seleção, remonte por identificador e peça confirmação humana.
- Se existe API, prefira a API ao clique: ela recebe a lista exata de identificadores e dispensa a interface.
Por que a seleção diverge do que está na tela
Uma interface de seleção múltipla guarda dois mundos separados. O primeiro é o conjunto de dados que o sistema considera “selecionado”. O segundo é o subconjunto que está renderizado na tela naquele instante, depois do filtro, da busca e da paginação. Um agente que olha apenas para os pixels assume que os dois coincidem. Na maioria dos sistemas, eles não coincidem.
Do ponto de vista do HTML, uma caixa de seleção é um controle com estado próprio: o atributo checked reflete se ela está marcada, e o elemento é acessível por papel e nome através da documentação de input checkbox do MDN. O problema é que esse estado nem sempre é o estado real da seleção. Frameworks modernos renderizam linhas de forma virtual e frequentemente mantêm a lista de selecionados em um objeto de estado à parte, ligado por identificador. A caixa pode aparecer desmarcada porque a linha foi re-renderizada, enquanto o identificador continua na lista de selecionados.
Há ainda o estado do lado do servidor. Em muitos painéis, marcar itens apenas envia identificadores para uma sessão, e o “selecionar tudo” registra uma flag do tipo “todos os itens da consulta atual”. Nesse caso, o conjunto selecionado não está no HTML em momento algum: está no servidor, esperando o filtro ativo no momento do envio.
Os cinco padrões que fazem o agente errar o alvo
1. A seleção sobrevive à troca de página
Você marca três itens na página 1, muda para a página 2 e o cabeçalho continua dizendo “3 selecionados”. Isso é proposital na maioria dos casos, para permitir uma ação em lote sobre várias páginas. Para o agente, é uma armadilha: ele age na página 2 achando que só há o que está na frente dele.
2. “Selecionar tudo” inclui o que o filtro escondeu
É o caso mais comum e o mais perigoso. O cabeçalho oferece “selecionar todos os N resultados”, onde N é maior que as linhas visíveis, porque a paginação ou a rolagem não mostra tudo. O agente vê dez linhas, clica em selecionar tudo e marca duzentas.
3. Uma linha marcada desde antes
O estado de seleção pode persistir entre navegações dentro do mesmo produto. Um clique de um humano minutos antes deixou uma linha marcada, o agente entra, marca mais duas e dispara uma ação sobre três itens, quando ele “só tocou” em dois.
4. Contagem do cabeçalho diferente das linhas visíveis
“5 selecionados” com apenas duas linhas marcadas na tela é sinal de que há três selecionados em outra página ou escondidos pelo filtro. É o sintoma mais fácil de detectar e o mais ignorado.
5. Seleção parcial por checkbox de cabeçalho
A caixa de seleção do cabeçalho tem três estados: vazia, marcada e indeterminada (alguns itens marcados, outros não). Interfaces acessíveis expõem o estado misto pelo atributo aria-checked="mixed", conforme o padrão de caixa de seleção do WAI-ARIA Authoring Practices. Um agente que só entende “marcado ou não” pode tratar o estado misto como vazio e marcar tudo, ou como cheio e desmarcar tudo.
| Sintoma na tela | O que costuma significar | Ação segura do agente |
|---|---|---|
| Cabeçalho diz “5 selecionados”, 2 linhas marcadas | Há seleção em outra página ou sob o filtro | Não agir; listar os identificadores e comparar com o esperado |
| Caixa do cabeçalho em estado misto | Seleção parcial | Ler o estado misto e tratar como incompleto, nunca como “tudo” |
| “Selecionar todos os N” com N maior que linhas visíveis | Seleção alcança resultado não renderizado | Trocar por seleção explícita por identificador |
| Seleção permanece após mudar de filtro | Filtro não limpa a seleção | Limpar a seleção e remontar depois de aplicar o filtro |
| Contagem volta a zero após navegar | Seleção é por página, não global | Confirmar o escopo antes de tratar como lote global |
Como detectar antes de agir
A regra central é: nunca agir com base apenas no que está renderizado. Antes de qualquer clique de ação em lote, o agente deve executar três verificações.
- Ler a contagem do cabeçalho (“N selecionados”) e comparar com o número de linhas que ele consegue ver marcadas. Se os dois números divergem, pare e informe.
- Listar explicitamente os itens afetados, por identificador, e não por posição na tela. Um bom agente devolve uma lista do tipo “serão afetados os itens 1042, 1043 e 1099” antes de clicar em aplicar.
- Comparar com o esperado. Se a tarefa era “aplicar desconto nos itens da categoria X”, a lista de identificadores precisa pertencer toda à categoria X. Qualquer item fora do conjunto esperado cancela a operação.
Em termos de automação de navegador, isso significa preferir seletores que liguem a caixa ao seu identificador de linha, em vez de seletores por posição. Locators baseados em papel, texto ou atributo de teste reduzem o risco de marcar a linha errada; a documentação de locators do Playwright explica por que seletores por papel e por rótulo são mais estáveis que seletores por posição na árvore. O mesmo vale para interações: a documentação de interações do Selenium WebDriver mostra como ler o estado de um elemento antes de clicar, em vez de assumir que o clique terá o efeito desejado.
Como mitigar
Limpar a seleção e remontar
Antes de montar o conjunto, procure o comando de “limpar seleção” e execute-o. Só depois aplique filtros e marque, na ordem que faz sentido. Isso elimina o item fantasma deixado por uma sessão anterior e o resíduo de uma navegação anterior. Se a interface não oferece “limpar seleção”, desmarque todas as linhas visíveis e dispare a ação apenas se a contagem do cabeçalho for zero antes de começar.
Agir por item em vez de em lote
Quando o volume é pequeno ou quando cada item tem efeito destrutivo, a ação item a item é mais lenta e muito mais segura. O agente aplica a operação a cada identificador, confere o resultado e segue. O custo extra em tempo compensa quando um erro em lote não tem desfazer.
Preferir a API ao clique
Se o mesmo sistema oferece API ou endpoint documentado, ele é quase sempre a escolha certa. Uma chamada de API recebe a lista exata de identificadores e devolve um resultado verificável. Não depende de quais linhas estão renderizadas, de paginação ou de estado de sessão. O clique existe para humanos; a API existe para integrações, e um agente é uma integração.
Exigir confirmação humana para ações em lote destrutivas
Descontos, exclusões, reembolsos, envios em massa e alterações de status devem passar por confirmação humana que mostre a lista de identificadores afetados. A confirmação precisa ser sobre a lista, não sobre o clique: um “confirmar” genérico não protege contra uma seleção errada. O tema se conecta ao desenho de permissões de agentes, que limita o que a automação pode fazer sem aprovação; veja o guia de permissões de agentes de IA.
Registrar o que foi afetado
Toda ação em lote deve gerar um registro com a lista de identificadores, o filtro aplicado no momento, o horário e o operador (humano ou agente). Sem esse registro, uma operação equivocada vira um mistério, e não há como reverter com precisão.
Exemplo: o desconto em lote que pegou a categoria errada
Um time de e-commerce em São Paulo trabalhava com um painel administrativo que lista produtos por categoria. O catálogo tinha categorias separadas, entre elas uma linha de acessórios e uma linha de eletrônicos com margem apertada. A tarefa do dia era aplicar um desconto promocional apenas nos acessórios.
O agente foi instruído a filtrar pela categoria de acessórios e aplicar o desconto. Ele aplicou o filtro, conferiu as linhas na tela, todas de acessórios, e clicou na caixa de seleção do cabeçalho, que naquele painel marca “todos os resultados da consulta”, não apenas a página visível. O filtro tinha sido aplicado apenas como filtro de exibição, sobre uma listagem que o agente já tinha carregado sem restrição. O resultado foi que a seleção incluiu produtos de outra categoria que estavam escondidos na mesma consulta paginada. O desconto foi aplicado a itens de eletrônicos, que não deveriam participar da promoção.
O erro não foi de entendimento do texto da tarefa, foi de interface: o agente confiou no que via na tela e no significado implícito de “selecionar tudo”. A correção adotada pelo time foi trocar o fluxo. Em vez de clicar no cabeçalho, o agente passou a montar a lista de identificadores da categoria, confirmar essa lista com uma pessoa antes de aplicar e executar o desconto item a item. O painel tinha uma API interna que aceitava a lista de identificadores, então o time migrou o passo final para lá, mantendo o clique apenas para conferência visual. Nenhuma dessas mudanças mudou o resultado desejado; todas reduziram a chance de a seleção incluir o que não deveria.
Como testar o agente contra esse cenário
Um agente que opera seleção múltipla precisa de testes que reproduzam as divergências de propósito. Monte um ambiente de teste com uma tabela paginada, um filtro e uma caixa de seleção de cabeçalho e cubra pelo menos estes casos.
- Marque itens na página 1, navegue para a página 2 e ordene uma ação; o agente deve detectar seleção herdada.
- Aplique um filtro que reduza a lista visível e clique em selecionar tudo; o agente deve detectar que a contagem do cabeçalho é maior que as linhas visíveis.
- Deixe uma linha marcada antes de o agente começar e verifique se ele limpa a seleção antes de montar a sua.
- Use o estado misto da caixa do cabeçalho e confira se o agente trata como incompleto em vez de “tudo”.
- Simule uma resposta de erro da ação em lote e verifique se o agente lê o que de fato foi aplicado antes de repetir.
Esses testes cabem no mesmo tipo de bateria usada para avaliar agentes em geral, com casos difíceis e resultado esperado explícito; veja como testar um agente de IA e o checklist para conferir respostas de IA. A ideia é a mesma: transformar uma suposição silenciosa (o que está na tela é o que está selecionado) em uma verificação com resposta observável.
Erros comuns
- Confiar na contagem visível. Contar as linhas marcadas na tela em vez de ler a contagem declarada pelo próprio componente.
- Tratar “selecionar tudo” como “selecionar o que vejo”. O nome engana; a maioria dos painéis marca o resultado inteiro.
- Não limpar a seleção antes de começar. Deixa resíduo de uma sessão ou de uma tentativa anterior.
- Selecionar por posição na tela. A posição muda com ordenação, filtro e paginação; o identificador não.
- Agir em lote sem lista de identificadores. Sem a lista, não há como conferir o que será afetado nem registrar o que foi feito.
- Dispensar confirmação humana em ação destrutiva. Um “confirmar” genérico não mostra a seleção real.
- Ignorar o estado misto. Tratar a caixa do cabeçalho como binária inverte o sentido em seleções parciais.
- Preferir o clique quando existe API. O clique depende da interface; a API recebe a lista e responde com um resultado.
Perguntas frequentes
Por que a seleção não é apagada quando aplico um filtro?
Porque filtrar costuma ser uma operação de exibição, não de estado. O componente esconde as linhas que não batem com o filtro, mas mantém a lista de identificadores selecionados intacta. Limpar a seleção é um comando separado, e nem todos os painéis o expõem com clareza.
Um agente consegue ler a contagem de selecionados do cabeçalho?
Sim, desde que a contagem tenha um rótulo estável na página. Se o número vive dentro de um texto do tipo “N selecionados”, o agente lê o texto e extrai o número. Em interfaces acessíveis, o próprio atributo de estado do componente costuma carregar essa informação; a referência de papel de caixa de seleção do MDN mostra os atributos que expõem estado e estado misto.
Qual é a forma mais segura de aplicar uma ação em muitos itens?
Montar a lista de identificadores, confirmar essa lista com uma pessoa quando a ação é destrutiva e executar por API, autenticando o mesmo usuário que faria a operação pela interface. A interface fica para a conferência visual, não para o disparo.
Preciso desativar o “selecionar tudo” do painel?
Não é necessário mudar o produto. Basta o agente não usar esse atalho e montar a seleção por identificador. Mudar o produto para acomodar a automação costuma ser o caminho errado; adaptar o fluxo do agente é mais simples e mais seguro.
Como saber se um item fora do esperado entrou na seleção?
Comparando a lista de identificadores afetados com o critério da tarefa, por exemplo, todos pertencerem à categoria certa. Essa comparação é uma checagem que o próprio agente pode fazer antes de aplicar, e o resultado deve virar registro.
Leia também
Para aprofundar o tema deste artigo, veja tambem:
