--- title: "NCSC orienta empresas a manter kill switches para sistemas de IA após incidentes" author: "Gabriela P. Torres" date: "2026-08-23 06:45:00-03" category: "Segurança & Privacidade" url: "http://desbugados.scale.press/portal/desbugados/post/2026/08/23/ncsc-orienta-empresas-a-manter-kill-switches-para-sistemas-de-ia-apos-incidentes/md" --- ## Resumo - O NCSC do Reino Unido publicou orientação prática interina para operadores de sistemas de IA agentiva. - Controladores humanos devem conseguir interromper imediatamente atividades autônomas dos agentes. - O kill switch pode incluir restrição à rede externa e interrupção da comunicação entre agentes. - As empresas devem avaliar o risco e o nível de autonomia necessário, aplicando restrições proporcionais. - Auditoria, registros e monitoramento são recomendados para acompanhar as atividades dos agentes. - Conselhos e executivos devem participar da compreensão dos riscos de IA e aprendizado de máquina. - As diretrizes de desenvolvimento seguro cobrem sistemas criados do zero e soluções baseadas em ferramentas de terceiros. --- O **National Cyber Security Centre (NCSC)** do Reino Unido publicou uma orientação prática interina para organizações que desenvolvem ou operam sistemas de inteligência artificial agentiva, isto é, ferramentas capazes de executar atividades autônomas. A recomendação central é direta: controladores humanos precisam conseguir interromper imediatamente o que esses sistemas estão fazendo. O assunto ganhou peso após incidentes envolvendo atividades não sancionadas ou não intencionais de modelos de IA, mas o NCSC não trata o chamado **kill switch** como uma peça decorativa de governança. A questão real é saber se a empresa consegue parar o agente, isolar seus acessos e reconstruir os passos que levaram ao problema. ## O que o NCSC está realmente pedindo A primeira peça da orientação é a existência de um mecanismo que permita aos **controladores humanos** interromper atividades autônomas imediatamente. Em termos simples, o agente não pode ser colocado para operar sozinho sem que alguém tenha uma forma confiável de encerrar sua atuação. Se a empresa entrega autonomia a um sistema, então precisa conservar autoridade operacional sobre ele; senão, o controle humano vira apenas uma frase em um documento de políticas. A recomendação não define o interruptor como uma promessa abstrata de segurança, mas como uma capacidade que deve estar disponível quando o comportamento do modelo sair do que foi autorizado. Essa distinção muda o significado de um **kill switch**. O NCSC afirma que o controle pode ir além de um simples desligamento, incluindo a restrição do acesso à rede externa da infraestrutura de IA e a interrupção da comunicação entre agentes e arquiteturas de inferência de modelos. A primeira medida limita o contato do sistema com recursos fora de sua infraestrutura; a segunda corta o caminho pelo qual diferentes componentes podem continuar trocando instruções ou resultados. Portanto, se desligar o processo inteiro não for suficiente para conter a atividade, a organização precisa ter alternativas de isolamento que reduzam o alcance do agente sem depender apenas da boa vontade do próprio sistema. ## Por que desligar não basta A necessidade desse controle aparece na própria justificativa do **NCSC**: a orientação responde a incidentes envolvendo atividades não sancionadas ou não intencionais de modelos de IA. A formulação é relevante porque descreve duas formas diferentes de falha. Uma atividade pode ultrapassar aquilo que a organização autorizou ou pode ocorrer sem que tivesse sido planejada, e as duas situações exigem uma resposta operacional rápida. A fonte não apresenta, nesse aconselhamento, uma relação detalhada de cada incidente nem permite atribuir um caso específico à recomendação. O fato documentado é mais preciso: autoridades de segurança passaram a pedir que a autonomia seja acompanhada por uma capacidade humana imediata de interrupção. O ponto seguinte é a **visibilidade operacional**, que neste contexto significa saber o que o agente está fazendo, quais componentes estão envolvidos e quais ações foram registradas. A orientação recomenda auditoria, registro e monitoramento das atividades dos agentes, além das restrições de acesso e comunicação. Se a empresa consegue apertar um botão, mas não sabe qual atividade será interrompida, quais conexões continuarão abertas ou que decisões já foram tomadas, então ela possui um comando de parada sem uma visão confiável do problema. O registro permite reconstruir a sequência de ações, enquanto o monitoramento ajuda a identificar desvios antes que a interrupção se torne a única resposta disponível. ## Autonomia precisa acompanhar o risco Além de pedir uma interrupção imediata, o NCSC orienta as organizações a avaliar o **risco** e o nível de autonomia necessário para cada sistema. A lógica desmonta uma suposição comum nas apresentações sobre IA: mais autonomia não é automaticamente melhor. Se uma tarefa pode ser executada com menos liberdade de ação, então conceder permissões adicionais cria uma exposição que precisa ser justificada; se a autonomia maior for necessária, a empresa deve aplicar restrições proporcionais ao risco identificado. A recomendação transforma a pergunta “o agente consegue fazer isso?” em uma pergunta mais exigente: “ele precisa fazer isso sozinho, com quais acessos e sob quais condições de interrupção?”. A mesma lógica ajuda a separar conveniência de necessidade. Um sistema pode ter capacidade técnica para realizar uma atividade, mas isso não significa que deva receber autonomia irrestrita para executá-la. O NCSC não prescreve um nível único de independência para todos os agentes; ele pede que a organização avalie o grau necessário e aplique controles compatíveis. Na prática, a decisão precisa conectar a autonomia ao risco da operação, mantendo a possibilidade de restringir a rede, interromper comunicações e parar atividades quando o comportamento ultrapassar os limites definidos. Sem essa relação entre permissão e risco, a adoção da IA começa pelo recurso disponível, e não pela responsabilidade que a empresa consegue sustentar. ## Governança: quem responde quando o agente erra? O controle técnico só funciona como política de segurança quando alguém responde por ele. Em seu material sobre IA e cibersegurança, o **NCSC** questiona se as organizações têm clareza sobre a responsabilidade pela segurança de sistemas de inteligência artificial e aprendizado de máquina, também chamado de machine learning. O documento recomenda envolver conselhos e executivos na compreensão dos riscos, integrar os riscos de aprendizado de máquina aos processos de governança existentes, identificar ativos críticos e planejar a resposta a incidentes graves envolvendo essas ferramentas. A conclusão prática é desconfortável, mas necessária: um kill switch sem proprietário definido pode existir no desenho da arquitetura e continuar ausente no momento da crise. Essa atribuição de responsabilidade também impede que a empresa trate o agente como uma caixa-preta isolada. O sistema precisa entrar nos processos que já organizam riscos, ativos e resposta a incidentes, em vez de receber uma exceção por ser apresentado como ferramenta de inteligência artificial. Se os executivos precisam compreender os riscos e a organização precisa identificar seus ativos críticos, então o debate não pertence apenas à equipe que configurou o modelo. Ele alcança quem decide onde a tecnologia será usada, quais recursos poderá acessar e qual resposta será acionada quando uma atividade autônoma se tornar grave. ## Segurança começa antes da implantação O alcance da recomendação também aparece nas **diretrizes de desenvolvimento seguro de IA** do NCSC, que cobrem provedores de sistemas criados do zero e soluções construídas sobre ferramentas de terceiros. Essa abrangência elimina uma possível brecha retórica: a empresa não pode transferir toda a responsabilidade para o fornecedor apenas porque não desenvolveu o modelo original. O guia trata a segurança como uma preocupação do ciclo de vida de desenvolvimento, ou seja, algo que deve ser considerado durante as diferentes etapas de implementação, e não somente depois que o sistema já recebeu acesso a operações reais. Essa abordagem conecta o interruptor de emergência ao processo que vem antes dele. Ao avaliar uma solução, a organização precisa considerar o risco, o nível de autonomia, os acessos de rede, os caminhos de comunicação e a forma de auditar as atividades. Depois, deve manter registros e monitoramento suficientes para verificar o comportamento do agente e planejar a resposta a incidentes. Se a segurança entra apenas no fim, o kill switch pode ser reduzido a um remendo; se entra durante o desenvolvimento e a implantação, ele passa a fazer parte da forma como a empresa controla a tecnologia. ## A caixa de ferramentas antes de liberar um agente Traduzindo a orientação para uma decisão operacional, o primeiro passo é registrar por que o sistema precisa de autonomia e qual risco acompanha essa escolha. Em seguida, a organização deve definir quem são os **controladores humanos**, como eles interromperão atividades autônomas e quais medidas estarão disponíveis caso o desligamento simples não contenha o problema. A avaliação também precisa considerar a restrição do acesso à rede externa, a interrupção da comunicação entre agentes e arquiteturas de inferência, além de auditoria, registro e monitoramento. Não se trata de acumular controles por aparência: cada mecanismo deve responder a um risco identificado. O próximo passo é juntar essa capacidade técnica à governança: envolver conselhos e executivos, integrar os riscos de IA aos processos existentes, identificar ativos críticos e preparar a resposta para incidentes graves. A recomendação do **NCSC** não diz que a autonomia deve desaparecer, mas que ela precisa ser acompanhada por limites verificáveis e por uma autoridade humana capaz de agir imediatamente. Antes de liberar um agente para operar, a pergunta decisiva deixa de ser apenas o que ele consegue fazer. Passa a ser se a organização consegue interrompê-lo, isolá-lo, auditar suas ações e responder pelos efeitos quando a execução fugir do planejado.