Antes de seus agentes tocarem em motores: um caso de segurança para CTOs em AI‑to‑IO

A Anthropic acaba de pré‑anunciar um padrão de hardware que permite a agentes de IA controlar o mundo físico. É o momento que muitas equipes esperavam — “finalmente, nosso robô do armazém pode apertar o botão de verdade”. Também é o momento em que muitos CTOs estão prestes a se machucar. Aqui, o modo de falha não é uma UI quebrada; é um palete no chão, uma bomba rodando a seco ou um processo judicial.

Se você vai conectar agentes à E/S — relés, motores, válvulas — precisa de um caso de segurança, não de um demo. Este post oferece um framework de decisão para traçar a fronteira entre autonomia e controle, cabear três intertravamentos independentes, orçar a latência corretamente, testar com um gêmeo antes de encostar no metal e entregar uma trilha de auditoria à prova de adulteração. Vamos manter a neutralidade de fornecedor, mas reconhecer a realidade: você fará a ponte entre stacks modernos de agentes (MCP, ROS 2, gRPC) e tecnologia de planta antiga porém confiável (OPC UA, Modbus/TCP, EtherCAT, PLCs de segurança).

A fronteira que salva você: agente vs. controlador

A maioria das equipes erra a arquitetura ao deixar o agente “dirigir” a planta diretamente. Não faça isso. O agente propõe; um controlador certificado dispõe. Essa fronteira é sua linha de segurança legal, operacional e moral.

Desenhe assim:

• Camada de agente (não certificada, adaptativa): Planeja tarefas e propõe intents como “mover a esteira A a 40% por 12 segundos” ou “abrir a válvula de entrada B até o nível atingir 70%”. Ela nunca alterna um GPIO nem escreve diretamente em uma bobina.
• Envelope de comando (determinístico, filtrável): Valida, modela e aplica rate‑limit aos intents. Pense nele como um kernel de atuação: sensível a unidades, com verificação de limites e limitação de jerk. Se o envelope não consegue provar segurança, ele recusa o comando.
• Controlador da planta (certificado, em tempo real): Um PLC/drive/controlador de robô manipula de fato motores e válvulas. Ele impõe intertravamentos e invariantes hard em ciclos de milissegundos e cai para um estado seguro na perda de comunicação.

Os agentes vivem fora da fronteira de segurança. Seu controlador e o sistema de segurança vivem dentro dela. Essa é a linha que seus advogados, auditores e equipe de operações podem defender.

Torne as restrições de segurança executáveis

Políticas pertencem ao código, não a um PDF. Você precisa de invariantes verificáveis por máquina no caminho de comandos — antes que cheguem a um PLC. Exemplos:

• Exclusão mútua: “Os contatores de avanço e de reversão do Motor M nunca devem ser energizados simultaneamente.”
• Limites de taxa/variação: “Mudar a velocidade da esteira em ≤10% por segundo; máximo absoluto 60% em zonas mistas com pessoas.”
• Guardas de estado: “Não abra a Válvula B a menos que Pressão P < 1.2 bar e Temperatura T < 40°C.”
• Limites de energia: “A velocidade do TCP do robô deve permanecer ≤250 mm/s enquanto a zona 2 do scanner de segurança estiver ocupada.”

Represente as restrições como um conjunto de regras de domínio compiladas em verificações em tempo de execução. Você não precisa começar com métodos formais; um envelope seguro pode ser imposto com statecharts e alguns predicados. Mas trate‑o como um controlador: escreva testes de propriedades, faça fuzz em descontinuidades e prove monotonicidade quando possível.

Três intertravamentos, caminhos independentes

Dizer “temos um E‑stop (parada de emergência)” não basta. Você quer defesas sobrepostas e diversas para que uma única classe de bug não derrube tudo.

1) Barreira de política (quem pode fazer o quê)

• Allowlists em vez de prompts: O agente só pode invocar skills nomeadas com argumentos tipados. Nada de strings de atuação em linguagem livre.
• RBAC + janelas de tempo: Certas skills (por exemplo, “abrir válvula cáustica”) exigem papéis elevados e aprovação explicitamente com tempo limitado. Embuta uma regra de duas pessoas para mudanças de política.
• Orçamentos de comandos: Por turno ou por receita, limite a contagem de atuações de alto risco e o duty cycle. Você deve conseguir responder: “Quantas vezes abrimos esta válvula nas últimas 24h?”

2) Barreira física (o envelope)

• Comandos com unidades verificadas e limitação de jerk: Comandos carregam unidades e são automaticamente modelados (por exemplo, perfis em S) para evitar transitórios.
• Checagens de invariantes com corroboração por sensores: O envelope se recusa a prosseguir se os sensores necessários estiverem degradados, obsoletos ou contraditórios.
• Watchdog + horizonte limitado: Os intents do agente precisam ter uma condição de término clara. Se não for satisfeita, o envelope aborta e volta a um estado conhecido.

3) Barreira da planta (PLCs/relés de segurança)

• E‑stops cabeados e scanners de segurança: Circuitos Categoria 3/4 conforme ISO 13849, fiação normalmente fechada e relés de segurança que desenergizam para o seguro.
• Safe Torque Off (STO): Para drives e robôs, use funções IEC 61800‑5‑2 quando disponíveis.
• Watchdog com clock independente: Se o controlador perder um heartbeat (por exemplo, 100 ms) vindo do envelope, ele cai para um estado seguro — sem desculpas.

Esses caminhos devem ser tecnologicamente diversos quando possível: uma camada de política em LLM pode falhar independentemente de um bug de firmware no PLC ou de um relé de segurança soldado fechado.

Orçamentos de latência que não vão machucar ninguém

Atuação não é completar chat. Coloque números nisso — ou não envie para produção.

• Controladores em malha fechada: loops de 1–5 ms para servo‑movimento; 5–20 ms para lógica típica de PLC. Isso não é território de agente.
• Logística em escala humana: Esteiras e pick‑lights: 50–200 ms de round‑trip é aceitável. Seu envelope + PLC devem manter o jitter total abaixo disso.
• Realidades de rede: Round‑trips LAN de OPC UA costumam ser 5–15 ms; RTTs entre regiões na nuvem podem ser 60–120 ms com caudas gordas. Nunca coloque decisões críticas de segurança através de uma WAN.
• Heartbeats e timeouts: 100 ms de heartbeat do envelope para o PLC; timeout de 300–500 ms para fail‑safe. Faça log em ambas as direções.

Regra prática: mantenha o envelope e o controlador da planta co‑localizados na borda (edge). Agentes podem estar em um backoffice ou em um nó de edge próximo, mas os últimos 10 ms de controle não devem cruzar a Internet pública.

“Human in the loop” não é estratégia de segurança

HITL é uma camada de governança, não um laço de controle. Um humano não consegue confirmar de forma confiável, a cada 200 ms, que comandos não violarão um limite de pressão. Use revisão humana para política (por exemplo, “aprovar mudança de receita”) e intent (por exemplo, “agendar após o turno”), não para apertar botões rumo à segurança.

Teste como na aeroespacial: SIL, HIL e gêmeos digitais

Não aprenda na planta real. Use:

• Software‑in‑the‑loop (SIL): Simule lógica de PLC, código do envelope e planos do agente contra um modelo de planta. Para robótica, ROS 2 + Gazebo ou Webots; para PLCs, simuladores do fornecedor (PLCSIM, CODESYS) ou um servidor OPC UA simulado.
• Hardware‑in‑the‑loop (HIL): Controladores reais ligados a uma planta simulada via emuladores de I/O. Valide watchdogs, STO e cadeias de emergência. Prove que o sistema falha para o seguro quando você arranca cabos.
• Gêmeos digitais com injeção de falhas: Script de cenários como “válvula travada” ou “deriva de sensor”. Trate “sensor stale > 200 ms” como falha de primeira classe, não caso de borda.

Torne explícito o critério de saída: “Nenhum comando chega a um atuador real a menos que tenha passado por testes SIL cobrindo 95% do espaço de estados alcançável e por testes HIL para todos os perigos Categoria A.”

SIL, não vibes: para qual padrão você está mirando?

Se você atua em setores regulados, seus auditores falam IEC 61508/61511 (processo), ISO 13849 (máquinas) ou UL 4600 (autonomia). Você não precisa certificar o agente, mas precisa mapear seu envelope e barreiras da planta aos níveis de integridade de segurança (SIL) ou Níveis de Desempenho (PL) requeridos.

• Metas em modo contínuo (IEC 61508 PFHd): SIL 1: 1e‑6–1e‑5 falhas perigosas/hora; SIL 2: 1e‑7–1e‑6; SIL 3: 1e‑8–1e‑7. A maior parte do brownfield de logística mirará SIL 1–2 para funções específicas de segurança.
• Diagnósticos importam: Você eleva PL/SIL não só com hardware mais robusto, mas com melhor cobertura de diagnósticos e intervalos de teste. Os auto‑testes do seu envelope contam.
• Documente o caso de segurança: Análise de perigos (HAZOP/STPA), alocação de requisitos de segurança, matriz de verificação e evidências. Vibes não passam em auditoria.

Contratos de comando: intents, acks e efeitos medidos

Cada atuação deve ser rastreável do intent ao efeito medido, com confirmações explícitas ao longo do caminho:

1. Intent criado: Agente propõe Actuate(ConveyorA, speed=0.4, duration=12s)
2. Envelope aceita/recusa: Validado, moldado para um perfil seguro ou rejeitado com motivo
3. Ack do controlador: PLC aceitou ou recusou; faça log do caminho de código
4. Fechamento por telemetria: Sensores confirmam o estado desejado (por exemplo, sensor de velocidade ~0.4 dentro da tolerância). Se não for atingido em T segundos, abra um incidente e volte ao seguro

Comandos que não resultam em um efeito mensurável e oportuno não estão “concluídos”. Eles são anomalias e entram nas suas métricas de MTTR e incidentes.

Auditoria que você pode levar ao tribunal

Quando algo dá errado, você não vai discutir com um engenheiro; vai discutir com um segurador ou regulador. Seus logs precisam ser à prova de adulteração e completos:

• Armazenamento append‑only: buckets WORM ou um log encadeado por Merkle por nó de edge. Faça hash de snapshots para um sistema separado a cada N minutos.
• Telemetria de alta resolução: 50–100 Hz de captura para sensores/atuadores relevantes durante jobs ativos. Mais grosseira em idle para controlar custos.
• Reprodutibilidade: Dado um segmento de log, você consegue reconstruir a decisão do envelope, o caminho do programa no PLC e o estado resultante da planta.
• Atribuição: Assine os binários do agente e do envelope, registre o hash da versão/pesos do modelo, a versão do catálogo de skills e o checksum do firmware do PLC para cada execução.

Integração brownfield sem ilusões

Sua planta provavelmente fala OPC UA, Modbus/TCP, Profinet, EtherNet/IP ou EtherCAT. Seu stack de agente provavelmente fala gRPC ou ROS 2 (DDS). Não force uma re‑fiação só para ser “moderno”.

• Faça ponte (bridge), não reescreva: Construa um gateway fino e testável que traduza intents tipados em chamadas ao controlador. Limite sua responsabilidade a serialização, sincronização de tempo e retries.
• Disciplina de clock: Use PTP ou ao menos NTP com monitoramento; seu envelope e PLC devem concordar dentro de alguns milissegundos.
• Degrade de forma controlada: Em partição de rede, o controlador continua executando a última receita segura ou cai para um idle seguro. O agente não tem poder de veto.

Design organizacional: separe curiosidade de controle

A Lei de Conway é um risco de segurança. Se a mesma equipe que ajusta prompts pode subir código do lado da planta, você vai colocar um demo em produção. Estabeleça fronteiras:

• Responsável por segurança: Um único dono responsável pelo envelope e pelas barreiras da planta. Trate isso como “SRE para física”.
• Controle de mudanças: Regra de duas pessoas para mudanças de política de segurança; simuladores de produção para dry‑runs; toda mudança recebe um diff de perigos.
• Exercícios de red team: Exercícios trimestrais em que você derruba links de rede, falha sensores e injeta intents ruins. Meça tempos de detecção e recuperação.

Se você precisa de expertise de domínio rapidamente, pods nearshore de mecatrônica podem mover a agulha. Brazil sozinho forma milhares de engenheiros de controle e elétricos todos os anos e tem um banco profundo de integradores de PLCs graças à sua base manufatureira. Com 6–8 horas de sobreposição, um pod nearshore em Brazil pode construir gateways OPC UA, montar a biblioteca de invariantes do seu envelope e entregar rigs de teste HIL 20–30% mais baratos do que onshore nos EUA — sem dor de fuso horário.

Comprar vs. construir: onde está a alavancagem

Construa o envelope; compre o resto quando fizer sentido.

• Comprar: PLCs/relés de segurança e drives com STO; cortinas/scanners de luz; adaptadores de fieldbus; servidores OPC UA com suporte do fornecedor; gateways de acesso remoto seguro.
• Construir: Envelope de comandos específico do domínio com invariantes; modelos de simulação e harnesses HIL; barreira de política e pipeline de auditoria; catálogo de skills tipado com assinaturas.
• Reutilizar: ROS 2 como middleware de robótica; OPC UA para modelos de informação; protobuf/gRPC para definições de skills; programas existentes da planta com lógica bem testada.

Um plano prático de 90 dias

Dias 0–30: trace a fronteira e simule

• Faça o inventário de atuadores e perigos; escreva um resumo de uma página de perigos (top 10 modos de falha).
• Defina 10–20 invariantes como código em um envelope de stub; conecte a um simulador (Gazebo/Webots/PLCSIM/OPC UA simulado).
• Suba logging append‑only com atestação de modelo/versão.
• Decida o posicionamento no edge; provisione um PC industrial com NICs duplas e sincronização de tempo via PTP.

Dias 31–60: conecte controladores e intertravamentos reais

• Integre com um PLC real em bancada (HIL). Prove watchdogs e o comportamento de STO puxando cabos.
• Implemente a barreira de política: skills em allowlist, RBAC, aprovações com janela de tempo.
• Escreva 20–30 testes SIL e 10 cenários de injeção de falhas HIL. Ainda não toque no hardware de produção.

Dias 61–90: pilote em uma célula isolada

• Implante em uma única célula cercada, com E‑stops físicos e scanners de segurança.
• Rode turnos supervisionados com agentes propondo intents; o envelope executa sob orçamentos estritos.
• Colete 2–4 semanas de logs, ajuste invariantes e publique um caso de segurança v1 cobrindo o escopo do piloto.

O que a movimentação da Anthropic realmente muda

O “padrão de hardware para agentes” da Anthropic é um sinal positivo: o ecossistema está reconhecendo a necessidade de um plano de controle comum entre IA e E/S. Aproveite isso — mas não relaxe suas fronteiras. Uma API de skills padronizada ou um hub de GPIO não eliminam a necessidade do seu envelope, de seus intertravamentos ou de sua trilha de auditoria. Se algo, isso torna seu trabalho mais fácil: você pode focar o esforço de engenharia no caso de segurança, não na cola de drivers.

Histórias de falhas que você pode evitar

• O watchdog otimista: Uma startup deixou o PLC assumir que o envelope estava vivo a menos que fosse informado do contrário; um processo travado deixou uma bomba funcionando. Inverta isso: padrão é seguro em heartbeats perdidos.
• A restrição invisível: Uma equipe “sabia” que duas válvulas não deveriam ser abertas juntas, mas nunca codificou isso; um agente “otimizou” o tempo de ciclo e misturou reagentes. Se importa, é um invariante.
• O reflexo da nuvem: Um robô de logística dependia de uma etapa de aprovação de plano entre regiões; uma queda de 40 segundos parou uma linha e confundiu operadores. Mantenha decisões de segurança e de curto horizonte localmente.

O caminho entediante é o caminho mais rápido

CTOs se complicam perseguindo controle “inovador” quando o controle “entediante” — com engenharia de segurança de verdade — teria sido implantado mais rápido e mantido a planta rodando. Seu agente não precisa ser um virtuose de bobinas Modbus. Ele precisa ser um bom cidadão que propõe intents claros, aceita recusas com graça e deixa a parte difícil — segurança em tempo real — para os sistemas feitos para isso.

Principais lições

• Trace uma fronteira rígida: agentes propõem intents; controladores certificados executam dentro de um envelope de segurança codificado.
• Implemente três intertravamentos independentes: barreira de política, barreira física (envelope) e barreira da planta (PLCs/E‑stops/STO).
• Orce a latência de forma realista: mantenha envelope e controladores no edge; nunca coloque decisões de segurança sobre uma WAN.
• Teste antes de tocar no metal: SIL para cobertura de lógica, HIL para watchdogs/intertravamentos reais e gêmeos com injeção de falhas.
• Torne executáveis as restrições de segurança: codifique invariantes (exclusão mútua, limites de taxa, guardas de estado) e recuse comandos não verificáveis.
• Entregue uma trilha de auditoria defensável: logs append‑only, telemetria de alta taxa durante jobs, atribuição completa de modelos e firmware.
• Organize‑se para a segurança: equipes separadas para agentes e controle da planta; regra de duas pessoas para mudanças de política; faça red team da sua física.
• Construa o envelope, compre o hardware de segurança e faça ponte para padrões brownfield como OPC UA e ROS 2.
• Pods nearshore de mecatrônica em Brazil podem acelerar gateways OPC UA, invariantes e rigs HIL com 6–8 horas de sobreposição e 20–30% menor custo.