A equipe de uma prestadora de manutenção encerra a ordem de serviço 2481 no sistema interno. O técnico anexou fotos, registrou os materiais e coletou a assinatura do responsável. Para liberar o faturamento, alguém ainda precisa abrir o portal do cliente, localizar a unidade atendida, preencher os mesmos dados, enviar o relatório e guardar o protocolo.
Na terça-feira, o portal demora depois do clique em "Enviar" e volta para a página de login. A analista não sabe se o registro entrou. Ela acessa novamente, preenche tudo pela segunda vez e recebe dois protocolos para a mesma visita. O financeiro descobre a duplicidade quando o cliente recusa a cobrança.
Esse é o ponto em que automação de navegador costuma parecer mais simples do que realmente é. Clicar e digitar são a parte visível. O trabalho difícil é decidir se a ordem estava pronta, usar a fonte correta para cada campo, respeitar o acesso, confirmar o efeito no sistema externo e encaminhar o caso quando a tela não segue o caminho esperado.
A escolha prática é esta: use uma API oficial quando ela oferecer a operação necessária. Use automação determinística de navegador quando não houver API viável e o caminho for estável. Reserve IA para interpretar variações que regras simples não resolvem. Em qualquer canal, a tarefa só termina quando o estado externo foi confirmado e reconciliado com a operação interna.
A tela parece atalho até o primeiro envio sem resposta
Para uma pessoa, copiar a OS 2481 leva poucos minutos. Por isso, o processo costuma ser descrito como "só preencher o portal". A frase esconde decisões que a analista toma quase sem perceber.
Ela confere se a visita foi realmente concluída. Escolhe a unidade correta entre nomes parecidos. Verifica se a foto pertence àquele equipamento. Ajusta o formato da data. Percebe que o portal pede um código que o sistema interno chama por outro nome. Quando falta assinatura, devolve a ordem ao técnico em vez de inventar uma informação.
Uma automação precisa tornar essas decisões explícitas. Caso contrário, ela acelera a digitação e leva os erros junto.
O caso também atravessa duas fronteiras. A primeira é técnica: o sistema da prestadora e o portal do cliente têm dados, estados e ritmos diferentes. A segunda é de responsabilidade: registrar uma evidência pode ser automático, mas aceitar termos, confirmar uma cobrança, assinar uma declaração ou alterar um dado contratual pode exigir uma pessoa autorizada.
A pergunta útil não é se um agente consegue operar o site. Modelos atuais já recebem screenshots e devolvem ações de mouse e teclado. A própria documentação de computer use da OpenAI descreve esse ciclo. Ela também recomenda navegador ou máquina virtual isolada, revisão humana em ações de alto impacto e tratamento do conteúdo da página como entrada não confiável.
Capacidade de clicar não é autorização para agir. Também não é prova de que o efeito aconteceu.
API, RPA e computer use resolvem problemas diferentes
Os três termos aparecem juntos, mas representam contratos bem diferentes.
Uma API é uma interface criada para software conversar com software. Em vez de procurar o campo certo em uma página, a integração envia dados estruturados para uma operação conhecida e recebe uma resposta também estruturada. A tela pode mudar de cor ou reorganizar o menu sem alterar a API.
RPA, sigla de automação robótica de processos, reproduz uma sequência de ações que uma pessoa faria na interface. A automação localiza um elemento, digita, seleciona, anexa e avança. Ferramentas de navegador seguem esse princípio há anos. O WebDriver do W3C define uma interface de controle remoto para inspecionar e operar navegadores, inclusive localizar elementos, clicar, preencher campos e capturar a tela.
Computer use acrescenta percepção e escolha. Um modelo vê a tela, interpreta o que está acontecendo e propõe a próxima ação. Isso ajuda quando o portal muda de posição, apresenta texto variável ou exige leitura que seria cara de codificar em dezenas de condições. Também introduz incerteza. O modelo pode interpretar uma mensagem incorretamente, seguir uma instrução maliciosa da página ou escolher uma ação válida na tela, mas inadequada para o processo.
Na OS 2481, a divisão pode ficar assim:
- regras determinísticas confirmam que fotos, assinatura e materiais estão presentes;
- uma API envia o pacote, se o cliente oferecer essa operação;
- um robô de navegador percorre um formulário estável quando não existe API;
- IA interpreta uma mensagem de rejeição ou identifica uma variação de layout que exige decisão;
- uma pessoa assume quando há consentimento, impacto financeiro, dúvida sobre o dado ou barreira de segurança.
Não há mérito em usar a opção mais sofisticada. Há mérito em usar o canal menos frágil que resolve o caso.
Use API quando existe contrato suportado
Uma API oficial costuma ser a primeira escolha por quatro motivos: os campos têm formato definido, a resposta pode ser tratada por código, a autenticação foi pensada para integração e a mudança de interface não quebra o fluxo.
Isso não significa que toda API seja boa. Ela pode não expor a operação necessária, ter documentação incompleta, impor limites incompatíveis com o volume ou exigir um contrato que a empresa não possui. Ainda assim, vale investigar antes de automatizar a tela. Às vezes existe um conector, webhook, importação de arquivo ou envio por lote que resolve a mesma dor com menos manutenção.
A autenticação também muda. Quando o serviço oferece autorização delegada, a integração recebe acesso limitado, com escopo e prazo, sem precisar guardar a senha pessoal de alguém. O RFC 9700, que reúne práticas atuais de segurança para OAuth 2.0, dedica uma seção à restrição dos privilégios do token e desaconselha fluxos que expõem as credenciais da pessoa à aplicação cliente.
No portal do cliente, uma API poderia receber o identificador da OS, a unidade, os horários, os materiais e o arquivo. O retorno traria um protocolo ou um erro estruturado, como unidade_invalida ou assinatura_ausente. A integração registraria esse resultado na OS 2481 e saberia qual ação abrir.
Com a tela, o mesmo erro pode aparecer como um texto vermelho, um modal, uma troca de rota ou uma página vazia. O robô precisa reconhecer cada forma e ainda distinguir falha de carregamento, sessão expirada e rejeição do dado.
API não elimina regra de negócio. Ela reduz a quantidade de suposições feitas sobre a interface.
Navegador é adaptador, não fonte de verdade
Há portais importantes que não oferecem API, webhook ou importação adequada. Ignorar essa realidade mantém a equipe copiando dados. Automatizar o navegador pode fazer sentido, mas o desenho precisa tratá-lo como um adaptador mantido pela empresa, não como integração garantida pelo fornecedor.
O sistema interno continua sendo a fonte da OS, das evidências e do responsável. O portal externo continua sendo a fonte do protocolo e do estado aceito pelo cliente. O robô transporta informação entre os dois. Ele não deve criar uma terceira verdade dentro de sua própria memória.
Antes de iniciar, o fluxo grava uma versão dos dados que serão enviados. Isso evita que uma edição concorrente altere metade do pacote durante o preenchimento. Depois do envio, o resultado fica ligado à mesma versão. Se o técnico trocar uma foto ou corrigir o horário, nasce uma nova tentativa com motivo registrado.
A automação também precisa de limites claros:
- domínios e páginas permitidos;
- conta ou perfil autorizado para aquele cliente;
- campos que podem ser lidos e escritos;
- anexos aceitos e tamanho máximo;
- ações que exigem aprovação;
- condição objetiva de sucesso;
- tempo máximo e rota de saída.
Esse contrato evita o comportamento mais perigoso de uma automação visual: continuar procurando alguma coisa para clicar depois que o fluxo saiu do caminho conhecido.
A manutenção entra no custo. O WebDriver chama de referência obsoleta o caso em que um elemento encontrado já não está ligado ao documento. Na operação diária, isso aparece quando o portal recarrega uma parte da tela, muda um componente ou abre o formulário em outra estrutura. O robô precisa localizar de novo, reavaliar o estado ou interromper. Repetir o clique anterior pode atingir outro elemento.
IA ajuda na variação, não elimina o contrato do fluxo
A IA é útil quando há uma parte variável que tem valor suficiente para justificar interpretação. Pode ler a mensagem de rejeição, relacionar um rótulo novo ao campo conhecido, identificar que o portal abriu uma tela de manutenção ou preparar um resumo para a pessoa que assumirá a exceção.
Ela não precisa decidir tudo. A OS 2481 pode seguir uma máquina de estados determinada por código:
- aguardando evidências;
- pronta para envio;
- canal escolhido;
- rascunho externo preenchido;
- aguardando aprovação, quando aplicável;
- enviada;
- confirmada e reconciliada;
- em exceção humana;
- encerrada ou devolvida à origem.
O modelo atua dentro desses estados. Ele não inventa um décimo estado porque encontrou um botão diferente. Se a tela apresentar uma mensagem nunca vista, pode classificá-la e sugerir uma ação, mas o sistema decide se a sugestão está dentro das operações permitidas.
A documentação de computer use da Anthropic recomenda ambiente dedicado com privilégio mínimo, acesso limitado a dados e confirmação humana para decisões com consequência real. A página também alerta que instruções encontradas em sites ou imagens podem conflitar com a intenção do usuário.
A diferença em relação a um robô tradicional é a capacidade de interpretar. A diferença em relação a uma pessoa continua sendo responsabilidade, contexto e autorização. O artigo sobre agentes integrados ao CRM, ERP e atendimento aprofunda como ferramentas pequenas, permissões e aprovação mantêm esse limite dentro dos sistemas da empresa. No navegador, o mesmo cuidado precisa lidar com uma interface externa e mais frágil.
Clique não é confirmação
A analista clicou em "Enviar". O portal carregou por alguns segundos e pediu login. Há pelo menos três possibilidades: o envio falhou antes de gravar, o envio foi concluído e a resposta se perdeu, ou o portal criou um rascunho sem protocolo final.
Repetir sem conferir transforma incerteza em duplicidade.
A automação precisa buscar uma evidência externa. Ela pode receber o protocolo na resposta da API, capturar o identificador mostrado pelo portal, consultar a lista de envios ou verificar o estado em uma página de acompanhamento. A evidência deve estar ligada à OS, ao cliente, à versão dos dados e ao horário da tentativa.
Em seguida vem a reconciliação. O sistema compara o que pretendia fazer com o que o ambiente externo diz que aconteceu. Se a OS 2481 já aparece com protocolo 99218, a tentativa anterior teve efeito. Se não aparece e a sessão expirou antes do envio, o fluxo pode retomar. Se aparecem dois registros, o caso vai para uma pessoa com os identificadores e o histórico.
Uma chave de idempotência ajuda quando a API aceita esse recurso ou quando a integração controla o próprio comando. No navegador, nem sempre o portal conhece essa chave. A defesa passa a combinar consulta anterior, busca posterior e bloqueio de tentativas concorrentes. O sistema marca a OS como envio em andamento para impedir que outra execução comece ao mesmo tempo.
O infográfico resume a regra: o caminho termina no estado confirmado, não no botão.
Sessão, MFA, CAPTCHA e mudança de tela viram estados
Esses eventos não são detalhes técnicos. Eles mudam quem deve agir e qual parte do fluxo pode continuar.
Uma sessão expirada pede nova autenticação. O robô não deve preencher o formulário inteiro por cima da página de login nem procurar credenciais em texto livre. Ele interrompe, preserva o estado e informa onde parou.
MFA, a autenticação com um segundo fator, existe para exigir uma prova adicional. CAPTCHA tenta distinguir automação de interação humana. Nenhum dos dois deve ser tratado como obstáculo a contornar. Se o portal exige consentimento ou verificação de uma pessoa, o fluxo abre a etapa humana e retoma depois de uma confirmação válida.
Mudança de tela pede classificação. Pode ser apenas um campo movido, uma manutenção temporária, uma nova pergunta obrigatória ou uma alteração nos termos do serviço. A resposta não é aumentar a autonomia para clicar em qualquer coisa. É comparar o estado observado com os estados conhecidos e escolher entre adaptação segura, aprovação e interrupção.
Uma exceção útil carrega contexto suficiente:
- OS e cliente envolvidos;
- etapa em que a execução parou;
- screenshot ou evidência necessária, com acesso controlado;
- mensagem encontrada;
- dados que já foram enviados;
- protocolo, se houver;
- próxima ação sugerida;
- prazo e pessoa responsável.
Assim, a pessoa não recomeça a investigação do zero. A automação economiza trabalho mesmo quando não consegue concluir sozinha.
Conteúdo da página também pode atacar o agente
Uma página é fonte de dados, não fonte de autorização. Esse limite fica mais importante quando um modelo lê tudo o que aparece na tela.
Um portal comprometido, um campo preenchido por terceiro ou um documento anexado pode conter uma instrução para ignorar regras, abrir outro domínio ou revelar informação. Isso é uma forma de prompt injection. O texto pode parecer parte do processo para o modelo, embora não venha da empresa que configurou a automação.
OpenAI e Anthropic recomendam tratar página, screenshot, PDF, e-mail e outras entradas externas como não confiáveis. Na prática, o agente recebe uma política separada da tela: domínios permitidos, ações disponíveis, dados que nunca podem sair, operações que pedem confirmação e condições de parada.
A allowlist de domínio evita que um link inserido na página leve a execução para outro site. Ferramentas pequenas evitam que a leitura de uma mensagem conceda acesso a arquivos ou sistemas que o fluxo não deveria tocar. O ambiente isolado reduz o dano se a navegação sair do esperado.
O OWASP Top 10 for Agentic Applications de 2026 organiza riscos de agentes que planejam e agem em fluxos complexos. A lista não é um selo e não substitui análise do caso, mas serve como alerta: mais autonomia amplia o efeito de credenciais excessivas, ferramentas abertas e instruções maliciosas.
O que precisa de aprovação humana
A aprovação deve acontecer perto do efeito. Pedir autorização no começo para uma sequência inteira é frágil porque o estado pode mudar antes da ação sensível.
No caso da manutenção, preparar um rascunho com dados já validados pode ser automático. Enviar uma evidência operacional talvez também, se o contrato e o acesso permitirem. Aceitar novos termos, confirmar cobrança, alterar cadastro do cliente, cancelar protocolo, assinar declaração ou enviar dado sensível para outro domínio pedem outra barreira.
Uma boa tela de aprovação mostra o que acontecerá, com quais dados e sobre qual versão. A pessoa não aprova uma frase genérica como "continuar processo". Ela aprova "enviar a OS 2481, versão 3, para a unidade Centro, com relatório e quatro fotos".
Antes de executar, a automação revalida. Se a OS voltou para correção enquanto aguardava aprovação, o envio antigo perde validade. Essa verificação evita que uma decisão correta no momento anterior produza um efeito errado depois.
A estrutura também protege a empresa de aprovações automáticas por costume. Se quase todo caso pede clique humano sem leitura, o fluxo foi desenhado no ponto errado. Talvez uma regra determinística possa liberar os casos simples e encaminhar apenas exceções reais.
A fila de exceções precisa devolver o trabalho à pessoa certa
Uma caixa genérica chamada "erro na automação" só muda o problema de lugar. A fila precisa organizar causa, impacto e próxima ação.
Sessão expirada pode ir para quem administra o acesso. Dado recusado pode voltar ao responsável pela OS. Divergência de unidade pode pedir revisão do cadastro. Mudança no portal pode abrir manutenção para a equipe técnica. Termo novo ou ação com consequência contratual precisa de quem tem autoridade para decidir.
Alguns casos devem permitir retomada. Depois que a pessoa conclui o MFA, a execução volta ao estado "rascunho preenchido" ou "pronta para envio", conforme o que ficou comprovado. Outros casos pedem encerramento. Se o portal proibiu a automação, mudou seu processo ou retirou o acesso, o robô não continua por insistência.
Métricas da fila mostram se a solução merece existir. Uma automação que conclui metade dos casos e cria exceções claras pode ser útil. Outra que conclui oitenta por cento, mas exige investigação longa nos restantes, pode custar mais do que o processo anterior. O guia sobre como medir o ROI da IA ajuda a comparar custo por resultado aceito, tempo de revisão e retrabalho em vez de contar apenas execuções.
Um piloto pequeno mostra se vale manter
O primeiro piloto não precisa operar todos os portais de todos os clientes. Escolha um fluxo recorrente, com volume suficiente para observar, e um portal onde a empresa tenha autorização e consiga verificar o resultado.
Comece em modo assistido. A automação valida a OS, preenche o rascunho e para antes do envio. A analista confere os campos e registra correções. Essa fase revela nomes incompatíveis, evidências ausentes, regras escondidas e situações em que o portal não corresponde ao sistema interno.
Depois, habilite uma saída pequena. Pode ser o envio de casos sem impacto financeiro, com confirmação por protocolo e bloqueio de duplicidade. Mantenha sessão, MFA, CAPTCHA, recusa e tela desconhecida na fila humana.
Registre pelo menos:
- casos elegíveis;
- rascunhos corretos;
- envios confirmados;
- tempo humano antes e depois;
- duplicidades evitadas ou produzidas;
- exceções por causa;
- manutenção após mudança de tela;
- custo por resultado aceito.
Teste situações ruins de propósito. Remova um anexo, expire a sessão, troque a unidade, simule timeout e tente iniciar duas execuções para a mesma OS. O piloto precisa provar o caminho de recuperação, não apenas o caso feliz.
O AI Risk Management Framework do NIST é voluntário e foi criado para incorporar confiabilidade à concepção, ao uso e à avaliação de sistemas de IA. Para uma PME, a aplicação mais concreta é simples: identificar o risco, limitar o piloto, medir resultados e manter uma forma de interromper ou corrigir o fluxo.
Dados pessoais não viram livres porque estão na tela
Portais de clientes podem conter nomes, contatos, endereços, fotos, assinaturas e outros dados pessoais. Automatizar a interface não muda a finalidade do tratamento nem autoriza coletar tudo o que a conta consegue enxergar.
A LGPD inclui o tratamento em meios digitais e estabelece, entre seus princípios, finalidade, necessidade e segurança. O sistema deve usar o mínimo de dados necessário para aquele envio, restringir quem acessa as evidências e definir retenção coerente com o processo.
Isso afeta screenshots e logs. Guardar a tela inteira a cada segundo pode registrar dados sem relação com a OS. Prefira evidência pontual, campos estruturados e mascaramento quando possível. O log precisa explicar o que aconteceu sem virar uma cópia ilimitada do portal.
O software organiza o fluxo. Ele não transforma automação em prova de conformidade jurídica, contratual ou técnica.
Quando software sob medida faz sentido
Uma ferramenta pronta pode resolver o preenchimento de um portal. Outra pode conectar uma API. O projeto sob medida começa a fazer sentido quando a dor está na coordenação entre fontes, clientes e exceções: cada OS vem do sistema interno, cada portal pede dados diferentes, algumas ações exigem aprovação e o financeiro depende do protocolo para seguir.
Nesse cenário, o sistema novo não precisa substituir CRM, ERP, armazenamento e portais. Ele pode ser uma camada estreita de controle:
- recebe a OS pronta e congela a versão do pacote;
- escolhe API, importação ou navegador conforme o cliente;
- distribui acesso com o menor privilégio possível;
- pausa no efeito sensível;
- registra protocolo e reconcilia o estado;
- abre exceção com contexto;
- mede conclusão, manutenção e custo.
Antes de construir, confira se uma configuração nas ferramentas existentes resolve. O artigo sobre quando a planilha vira gargalo vale para esse diagnóstico: a troca se justifica quando versões, conferências e exceções recorrentes começam a esconder o estado real da operação.
No fim da OS 2481, a equipe precisa responder três perguntas sem abrir cinco telas: o que foi enviado, qual efeito o portal confirmou e quem assume a pendência. Se a empresa ainda depende de memória, senha compartilhada e tentativa repetida para chegar a essas respostas, há espaço para desenhar um fluxo melhor.
Fontes e referências
- OpenAI. Computer use.
- Anthropic. Computer use tool.
- W3C. WebDriver, Working Draft de 2 de julho de 2026.
- IETF. RFC 9700: Best Current Practice for OAuth 2.0 Security, janeiro de 2025.
- NIST. AI Risk Management Framework.
- OWASP. Top 10 for Agentic Applications for 2026.
- Brasil. Lei nº 13.709/2018, Lei Geral de Proteção de Dados Pessoais.
Se sua empresa precisa copiar informações entre um sistema interno e portais externos, a Foyth Tech pode ajudar a mapear o fluxo antes de escolher a tecnologia. Converse com a gente sobre um sistema sob medida que use API onde existe, trate o navegador como adaptação controlada e devolva cada exceção para a pessoa certa.
