Agentes de IA em dispositivos físicos: como controlar

Quando a saída do agente deixa de ser uma tela

Um agente que resume documentos pode produzir retrabalho. Um agente que envia uma mensagem pode criar uma comunicação indevida. Quando o mesmo sistema altera temperatura, move um braço robótico, aciona um instrumento ou muda o estado de uma máquina, o erro alcança o mundo físico.

Isso muda a arquitetura necessária.

Os agentes de IA em dispositivos físicos podem reunir leituras, sequenciar instrumentos, ajustar parâmetros dentro de limites e reagir a condições operacionais. A capacidade abre espaço para laboratórios, manufatura, inspeção, manutenção, logística e outros ambientes com equipamentos programáveis.

A conexão técnica, sozinha, não autoriza operação autônoma. Cada comando precisa de identidade, pré-condição, limite, confirmação e resposta de segurança. O modelo pode interpretar e planejar. Controles determinísticos e profissionais habilitados preservam as fronteiras que não deveriam depender de interpretação probabilística.

O que mudou no acesso da IA ao hardware

Equipamentos industriais e científicos costumam ter interfaces próprias, protocolos diferentes e documentação espalhada. Integrar várias máquinas exige conectores específicos, conhecimento de especialistas e testes cuidadosos.

Em agosto de 2026, a Anthropic anunciou uma prévia de pesquisa do Model Hardware Standard, ou MHS. A especificação propõe drivers padronizados para descrever dispositivos, expor comandos de leitura e escrita e permitir acesso por mecanismos como MCP, linha de comando e APIs.

Segundo o anúncio, os primeiros testes envolveram microscópios, manipuladores de líquidos, braços robóticos e sistemas a laser. Os resultados apresentados pertencem a provas de conceito e projetos iniciais de parceiros. A própria Anthropic registra limitações de raciocínio espacial e físico dos modelos e a necessidade de supervisão especializada.

O sinal de mercado é relevante: a camada de agentes começa a alcançar instrumentos e máquinas por interfaces mais padronizadas. Para uma empresa, a pergunta prática passa a ser como governar a passagem entre intenção digital e consequência física.

O que é um agente que opera dispositivos físicos

É um sistema que recebe um objetivo delimitado, consulta estado e contexto, escolhe ações permitidas e usa ferramentas para ler ou comandar equipamentos programáveis.

Uma execução pode incluir:

1. identificar o dispositivo;
2. verificar estado, versão e disponibilidade;
3. ler sensores;
4. consultar procedimento e limites;
5. preparar uma sequência;
6. validar pré-condições;
7. pedir aprovação quando necessária;
8. executar comandos restritos;
9. confirmar o efeito por leitura independente;
10. registrar resultado, desvio e próximo estado.

O agente pode operar em níveis diferentes. Em uma implantação inicial, ele apenas reúne leituras e prepara uma recomendação. Em uma fase posterior, pode executar sequências determinísticas previamente aprovadas. Autonomia adaptativa sobre comandos físicos exige uma base muito mais forte de segurança, avaliação e resposta.

A diferença entre operar telas e operar máquinas

O guia sobre agentes de IA que usam computador trata de navegador e desktop. Nessa abordagem, o agente interpreta elementos visuais e interage com sistemas desenhados para usuários.

Dispositivos físicos acrescentam outras dimensões:

• movimento;
• força;
• temperatura;
• pressão;
• energia;
• material;
• calibração;
• desgaste;
• ambiente;
• interação com pessoas;
• dano difícil ou impossível de reverter.

Uma tela alterada pode quebrar o fluxo. Um limite físico incorreto pode danificar equipamento, amostra, produto ou ambiente. A arquitetura precisa considerar tempo real, intertravamentos, estado local do controlador e modos seguros que continuam funcionando mesmo quando o agente perde conexão.

O agente não deveria substituir PLCs, sistemas instrumentados de segurança, proteções mecânicas, procedimentos de bloqueio ou autoridade técnica. Ele ocupa uma camada de supervisão e orquestração dentro das fronteiras aprovadas.

Separe leitura, preparação e comando

Uma política inicial pode usar quatro níveis.

Nível 1: observação

O agente lê sensores, estado, alarmes, logs e documentação. Ele organiza uma visão operacional sem emitir comando.

Exemplos:

• reunir temperatura e vibração de um ativo;
• comparar calibração com a data prevista;
• consolidar estado de instrumentos;
• detectar dado ausente;
• preparar relatório de turno.

Nível 2: recomendação

O agente interpreta sinais e sugere uma ação. Um profissional revisa o contexto e decide.

Exemplos:

• recomendar inspeção;
• propor sequência de testes;
• sugerir redução de faixa;
• preparar ordem de serviço;
• apontar necessidade de interromper o experimento.

Nível 3: execução determinística aprovada

O agente chama uma rotina fechada depois de validar pré-condições. O código ou controlador executa a sequência com limites próprios.

Exemplos:

• iniciar rotina de calibração autorizada;
• coletar uma série de leituras;
• mover equipamento para posição segura;
• executar checklist automatizado;
• pausar uma fila de novas tarefas.

Nível 4: adaptação restrita

O agente altera parâmetros dentro de um envelope testado, observa o resultado e escolhe o próximo passo permitido.

Essa faixa exige evidência forte, limites independentes, supervisão e capacidade de interrupção. A empresa deve concedê-la por dispositivo, tarefa, condição e versão. “Acesso ao laboratório” ou “controle da linha” são permissões amplas demais.

Modele o dispositivo como um contrato operacional

O agente precisa conhecer o que pode medir, ajustar e confirmar. Uma descrição útil inclui:

| Campo | Conteúdo | |---|---| | identidade | fabricante, modelo, número, localização e controlador | | capacidade | leituras e comandos disponíveis | | unidade | unidade física de cada parâmetro | | faixa | valores válidos e limites operacionais | | precisão | resolução, tolerância e incerteza conhecida | | estado | desligado, pronto, ocupado, falha, manutenção ou outro | | pré-condição | situação exigida antes do comando | | pós-condição | estado verificável esperado depois da ação | | latência | tempo normal para resposta e estabilização | | segurança | intertravamentos, limites e parada local | | dependências | energia, rede, material, ambiente e outros equipamentos | | manutenção | calibração, inspeção e versão | | autoridade | papel que pode ler, preparar, aprovar ou comandar | | evidência | telemetria e registro usados para confirmar o efeito |

Texto livre ajuda a explicar características. Campos críticos precisam ser estruturados e validados. O peso de um braço, a unidade de pressão e a temperatura máxima não deveriam depender de interpretação a cada execução.

Mantenha limites físicos fora do modelo

O sistema precisa impor limites mesmo quando o agente pede uma ação inadequada.

Use mecanismos independentes para:

• faixa mínima e máxima;
• velocidade;
• força;
• posição;
• corrente e potência;
• temperatura;
• pressão;
• volume;
• sequência obrigatória;
• zona de exclusão;
• presença humana;
• intertravamento;
• tempo máximo;
• frequência de comandos;
• número de tentativas;
• estado seguro em falha.

O agente consulta esses limites, mas não é a autoridade que os define nem o único componente que os aplica.

Quando uma ação sai do envelope, a resposta deve ser bloquear, registrar e encaminhar. Pedir ao modelo para “ter cuidado” não constitui barreira técnica.

O artigo sobre guardrails para agentes de IA mostra como distribuir controles entre entrada, contexto, ferramenta, confirmação e saída.

Pré-condições precisam ser verificadas no momento da ação

Um plano pode estar correto e ficar inválido segundos depois.

Antes de executar, confirme:

• dispositivo certo;
• estado atual;
• versão de firmware ou controlador quando relevante;
• modo de operação;
• calibração;
• área livre;
• material correto;
• consumível suficiente;
• temperatura e pressão compatíveis;
• nenhum alarme impeditivo;
• ausência de manutenção ativa;
• autoridade vigente;
• comando dentro da janela;
• dependências disponíveis;
• plano ainda válido.

Tarefas longas exigem revalidação. Uma aprovação recebida no início não cobre automaticamente toda mudança de estado. O agente precisa interromper ou pedir nova decisão quando cruza um limite material.

Confirme o efeito por uma leitura independente

Enviar comando não prova execução. Receber “sucesso” da interface também pode ser insuficiente.

A confirmação pode combinar:

• estado retornado pelo controlador;
• sensor independente;
• leitura posterior;
• câmera;
• posição medida;
• registro do equipamento;
• amostra de controle;
• sinal de outro sistema;
• verificação humana.

Defina três resultados possíveis:

• confirmado: o efeito esperado apareceu com evidência suficiente;
• não executado: a ação falhou antes do efeito;
• incerto: o comando foi enviado, mas o estado final não pôde ser comprovado.

Estado incerto merece tratamento próprio. Repetir o comando pode duplicar movimento, dosagem, coleta ou alteração. O sistema deve consultar o estado antes de qualquer nova tentativa.

O guia de idempotência para agentes ajuda a controlar repetição de efeitos. Em hardware, a possibilidade de tornar uma ação idempotente depende da natureza física do comando e precisa ser avaliada por especialistas.

Use código determinístico para sequências rápidas ou críticas

Modelos são úteis para interpretar contexto, escolher entre rotas autorizadas e lidar com variação. Eles não precisam raciocinar sobre cada passo de uma sequência estável.

Quando uma tarefa exige resposta rápida, temporização precisa ou repetição consistente, transforme a sequência aprovada em código ou rotina do controlador.

O agente pode:

1. selecionar a rotina correta;
2. preencher parâmetros dentro da faixa;
3. validar pré-condições;
4. pedir aprovação;
5. iniciar;
6. acompanhar telemetria;
7. interromper conforme política;
8. interpretar o resultado depois.

O controlador local preserva temporização e limites. Essa arquitetura reduz dependência de rede, latência do modelo e variação entre execuções.

Identidade precisa alcançar dispositivo e comando

O log deve mostrar quem ou o que iniciou cada consequência.

Separe:

• identidade do usuário;
• identidade do agente;
• identidade da aplicação;
• identidade do driver;
• identidade do dispositivo;
• identidade da rotina executada;
• versão do modelo e da política;
• aprovador;
• credencial usada;
• sessão e execução.

Credenciais compartilhadas apagam responsabilidade. Um agente autorizado a ler dez equipamentos não precisa comandar todos. O guia de identidade e credenciais para agentes detalha escopo, rotação, atribuição e revogação.

Use acesso curto e específico quando possível. A autorização pode expirar por tempo, conclusão, troca de turno, mudança de estado ou encerramento da tarefa.

Proteja a rede e a cadeia de controle

Conectar um agente a hardware amplia a superfície de ataque e falha.

Considere:

• segmentação de rede;
• lista explícita de destinos;
• autenticação mútua;
• assinatura ou verificação de comandos;
• atualização controlada de drivers;
• proveniência de bibliotecas;
• inventário de dispositivos;
• bloqueio de descoberta indevida;
• telemetria de política;
• acesso administrativo separado;
• proteção contra instruções vindas de conteúdo não confiável;
• modo local seguro durante perda de conexão.

Manuais, arquivos, câmeras e interfaces externas podem conter conteúdo que o modelo interpreta como instrução. Dados observados pelo agente não recebem automaticamente autoridade para alterar política ou comandar ferramentas.

Human in the loop precisa ter ação real

Uma tela de aprovação que não mostra consequência, estado e alternativa cria responsabilidade decorativa.

O aprovador precisa receber:

• objetivo;
• dispositivo;
• estado atual;
• comando ou rotina;
• parâmetros;
• motivo;
• evidência;
• limites;
• impacto possível;
• condição de interrupção;
• plano de recuperação;
• prazo de validade da aprovação.

Também precisa conseguir rejeitar, alterar dentro da própria autoridade e interromper. O guia de aprovação humana em agentes ajuda a posicionar a decisão antes do ponto de consequência.

Em operações reguladas ou de segurança crítica, os papéis e registros devem seguir normas, procedimentos e responsabilidades específicas do setor. Um guia geral de arquitetura não substitui engenharia, validação, segurança do trabalho, qualidade ou exigência regulatória aplicável.

Kill switch e estado seguro

Interromper um agente envolve camadas diferentes:

• impedir novos objetivos;
• pausar agendadores;
• bloquear novos comandos;
• cancelar tarefas em fila;
• revogar credenciais;
• interromper rotinas quando isso for fisicamente seguro;
• manter controladores locais em estado conhecido;
• impedir retentativas automáticas;
• preservar evidência;
• reconciliar o que ficou em curso.

Parada abrupta pode ser perigosa. Alguns equipamentos precisam concluir uma etapa, reduzir energia em sequência ou mover para uma posição segura. O procedimento deve ser desenhado com quem conhece o dispositivo.

O artigo sobre kill switch para agentes de IA detalha interrupção por camada e confirmação observável.

Teste o mecanismo periodicamente. Um botão documentado e nunca exercitado é uma hipótese de segurança.

Como escolher o primeiro caso

Procure uma tarefa com:

• dispositivo programável;
• documentação suficiente;
• estado observável;
• comandos estreitos;
• limites conhecidos;
• resultado confirmável;
• baixo impacto inicial;
• ambiente isolável;
• especialista disponível;
• caminho manual preservado;
• volume ou atrito que justifique o piloto.

Boas primeiras aplicações tendem a concentrar leitura e preparação:

• consolidar telemetria;
• verificar prontidão;
• preparar sequência;
• detectar campo ou leitura ausente;
• acompanhar calibração;
• montar relatório;
• sugerir inspeção;
• iniciar rotina de diagnóstico sem consequência material.

Evite começar pelo comando mais impressionante. O primeiro piloto precisa comprar evidência sobre integração, estado, controle e resposta a falhas.

Um roteiro de implementação em cinco fases

Fase 1: inventário e observação

Mapeie dispositivos, interfaces, comandos, limites, responsáveis, manuais, rede e registros. O agente somente lê.

Fase 2: gêmeo, simulador ou ambiente isolado

Reproduza estados e falhas sem equipamento produtivo ou consequência física relevante. Teste comandos inválidos, latência, perda de rede, leitura impossível e transição inesperada.

O ambiente de teste para agentes de IA ajuda a separar identidades, dados, ferramentas e promoção entre versões.

Fase 3: modo sombra

O agente observa casos reais e prepara a sequência que executaria. Especialistas comparam decisão, parâmetros, bloqueios e tempo.

Fase 4: execução assistida

Rotinas determinísticas de baixo risco podem ser iniciadas após aprovação. Todos os casos recebem revisão e confirmação independente.

Fase 5: autonomia restrita

Somente tarefas com desempenho estável, limites independentes, contingência e valor comprovado avançam. A ampliação ocorre por dispositivo, comando e condição.

Cada fase termina com uma decisão: encerrar, corrigir, manter ou ampliar. Calendário não concede autonomia.

Testes que o piloto precisa enfrentar

Inclua casos normais e situações adversas:

• dispositivo errado;
• unidade trocada;
• sensor sem calibração;
• leitura fora da faixa;
• estado mudou depois da aprovação;
• comando duplicado;
• confirmação perdida;
• rede interrompida;
• driver reiniciado;
• equipamento ocupado;
• obstáculo ou presença humana;
• limite local acionado;
• versão de manual divergente;
• rotina incompatível com firmware;
• material insuficiente;
• câmera obstruída;
• relógios fora de sincronização;
• agente recebe instrução maliciosa em um documento;
• kill switch acionado durante execução;
• retomada depois de parada parcial.

Avalie se o sistema bloqueia, preserva estado e produz um pacote útil para intervenção. Taxa de conclusão alta em casos fáceis não demonstra segurança sob variação.

Métricas para decidir se a arquitetura funciona

Integração

• dispositivos descobertos e identificados corretamente;
• comandos com contrato versionado;
• leituras com unidade e horário;
• falhas de driver;
• tempo para integrar um novo dispositivo;
• divergências entre documentação e comportamento.

Qualidade da decisão

• recomendações aceitas;
• parâmetros corrigidos;
• pré-condições ausentes detectadas;
• bloqueios corretos;
• ações inseguras propostas;
• intervenções humanas por causa.

Execução

• comandos confirmados;
• estados incertos;
• duplicidades evitadas;
• sequências interrompidas;
• tempo até estado seguro;
• recuperações bem-sucedidas;
• tarefas reabertas.

Operação

• tempo humano de preparação;
• utilização do equipamento;
• espera entre dispositivos;
• ciclos concluídos com qualidade;
• retrabalho;
• indisponibilidade;
• custo por unidade válida.

Segurança

• violações de limite bloqueadas;
• quase incidentes;
• comandos fora de autoridade;
• tempo de revogação;
• exercícios de parada;
• falhas de segregação;
• incidentes e causa confirmada.

Não use uma única taxa de sucesso para resumir o sistema. Uma execução pode concluir e ainda usar parâmetro errado, produzir resultado inválido ou depender de intervenção não registrada.

Erros comuns

Conectar primeiro e governar depois

O driver amplia capacidade. Sem política e limites, também amplia a superfície de consequência.

Descrever segurança somente no prompt

Instruções orientam o modelo. Intertravamentos, controladores, regras e permissões impedem ações.

Tratar retorno da API como efeito confirmado

A interface pode aceitar o comando antes de a máquina executar. Confirme o estado físico relevante.

Permitir raciocínio online em sequência crítica

Temporização e controle rápido devem permanecer em código ou controladores adequados.

Compartilhar uma credencial de operação

Sem identidade por componente e comando, investigação e revogação ficam frágeis.

Automatizar recuperação sem limite

Tentar novamente pode repetir efeito ou agravar uma condição física. Estado incerto exige consulta e política específica.

Aprovar uma tarefa inteira de uma vez

Mudanças de estado podem invalidar a autorização. Revalide fronteiras materiais.

Confundir piloto com autorização ampla

Uma prova de conceito demonstra capacidade em determinado cenário. Produção exige variação real, manutenção, resposta a falhas e dono operacional.

Checklist antes de emitir o primeiro comando

• O dispositivo possui identidade estável?
• Leitura e escrita usam permissões separadas?
• Comandos e parâmetros estão versionados?
• Unidades e faixas são validadas fora do modelo?
• Pré-condições são verificadas no momento da ação?
• Existe controlador local com limites independentes?
• O efeito pode ser confirmado por outra leitura?
• Estado incerto possui tratamento específico?
• Tarefas rápidas usam rotina determinística?
• Aprovação mostra consequência e validade?
• Rede e credenciais estão segmentadas?
• Conteúdo observado não altera a política?
• Existe parada segura por dispositivo?
• Retentativas ficam bloqueadas após incerteza?
• Logs ligam usuário, agente, driver e equipamento?
• O ambiente de teste reproduz falhas relevantes?
• Especialistas participam da avaliação?
• O caminho manual continua disponível?
• A autonomia cresce por comando e condição?
• Cada fase termina em uma decisão explícita?

O dispositivo precisa continuar governado quando a IA falha

Agentes podem reduzir integração artesanal, organizar contexto e coordenar equipamentos. O valor cresce quando conseguem observar mais, preparar melhor e executar rotinas delimitadas sem retirar dos sistemas físicos suas barreiras próprias.

Comece por leitura. Modele cada dispositivo como um contrato. Mantenha limites, temporização e estado seguro em componentes independentes. Confirme o efeito no mundo físico e trate qualquer incerteza como motivo para parar.

A capacidade decisiva não está em fazer o agente mover uma máquina durante uma demonstração. Está em saber exatamente quais comandos ele pode emitir, como cada efeito será comprovado e quem consegue interromper a operação quando a realidade sair do previsto.