Segurança da IA ​​e governança da IA ​​não são o mesmo problema.

A maioria das organizações está resolvendo o problema errado. Veja como diferenciá-los — e por que isso é importante antes da sua próxima implementação de IA.

Por que a segurança da IA ​​e a governança da IA ​​não são o mesmo problema?

A maioria das organizações de TI trata a segurança da IA ​​e a governança da IA ​​como um único fluxo de trabalho. Ambos os tópicos chegam à mesma reunião, são encaminhados para a mesma equipe e seguem as mesmas estruturas. Mas são dois problemas diferentes. A segurança da IA ​​impede a entrada de ameaças. A governança da IA ​​controla o que a sua própria IA faz internamente.

Ignorar essa diferença tem um custo. Você pode passar por uma auditoria de segurança e falhar em uma auditoria regulatória. Pode não reportar nenhuma violação de segurança e ainda assim não ter governança alguma. Ambas as situações podem ocorrer no mesmo dia.

Os riscos aumentam à medida que os agentes de IA passam de responder perguntas a executar ações em sistemas de produção. Sua equipe de segurança pode proteger um agente contra ataques e ainda assim não ter como comprovar o que esse agente tinha permissão para fazer. Este artigo explica como separar os dois problemas, quem deve ser o responsável por cada um e o que perguntar aos fornecedores antes da sua próxima implementação.

O que é segurança da IA?

A segurança de IA protege seu sistema de IA e os dados que ele manipula contra ameaças externas. Ela responde a uma pergunta: alguém pode invadir, manipular o sistema ou roubar seus dados?

Abrange três áreas:

• O modelo protege o modelo de entradas adversárias, injeção de código e manipulação que o levem a produzir resultados prejudiciais.
• Os dados. Isso impede a exposição ou exfiltração não autorizada de registros sensíveis que a IA pode acessar.
• A infraestrutura. Ela reforça a capacidade computacional, a rede e as integrações em que a IA é executada, impedindo que invasores as comprometam.

A segurança com IA amplia a postura de segurança que você já adota. Você mantém as mesmas equipes e as mesmas disciplinas, adicionando uma nova superfície de ataque. Uma organização de segurança madura está bem preparada para lidar com isso. Essa é uma boa notícia, e é também onde a confusão começa.
 

O que é governança de IA e por que ela é diferente?

A governança de IA controla o que sua IA faz quando está funcionando exatamente como projetado, sem a intervenção de um invasor. Ela responde a uma pergunta diferente: o que nossa IA está autorizada a fazer e podemos provar isso?

A governança se baseia em três componentes:

• Autorização. Isso define o que a IA pode fazer, sob quais condições e com qual abrangência.
• Responsabilidade. Isso estabelece quem aprovou cada ação e se existe algum registro que vincule a ação a essa pessoa.
• Auditabilidade. Isso determina se você pode demonstrar a um órgão regulador o que a IA fez, quando e por quê, sem precisar reconstruir eventos a partir de registros dispersos.

A área de segurança pergunta: "Alguém consegue invadir?". A área de governança pergunta: "O que minha IA tem permissão para fazer e onde estão as provas?".

Um agente perfeitamente protegido ainda pode reiniciar a tarefa errada, ler dados que nunca precisou ou agir sem a aprovação de ninguém. Nada disso é registrado como um incidente de segurança. Tudo isso vem à tona em uma auditoria.
 

Por que a segurança da IA ​​e a governança da IA ​​precisam de equipes e estruturas diferentes?

Elas precisam de proprietários diferentes porque as estruturas que as sustentam medem coisas diferentes. Estruturas de segurança como SOC 2, ISO 27001 e a Estrutura de Segurança Cibernética do NIST focam em ameaças externas e na proteção de sistemas e dados. Elas são essenciais, mas não abordam questões de governança.

As estruturas de governança são voltadas para dentro. O NIST AI Risk Management Framework, a Lei de IA da UE, as diretrizes de gestão de riscos do OCC e a Lei de Resiliência Operacional Digital da UE (DORA) apontam para as mesmas expectativas: autorização clara, supervisão humana e decisões rastreáveis. Essas estruturas não avaliam o seu perímetro.

Se você entregar a governança à equipe de segurança e pedir que ela utilize frameworks de segurança, você obterá exatamente o que esses frameworks produzem: uma auditoria de segurança. Você não obterá uma arquitetura de governança.

O melhor modelo divide a propriedade:

• A segurança detém o perímetro. Ela protege o modelo, os dados e a infraestrutura.
• As áreas de compliance, gestão de riscos e operações de TI compartilham a governança. Essas equipes entendem quais ações acarretam riscos comerciais e regulatórios.

Cada lado realiza suas próprias reuniões, define seus próprios critérios de sucesso e faz suas próprias perguntas aos fornecedores. Para as equipes de mainframe, a participação da equipe de operações de TI na governança é crucial. A equipe de operações sabe quais jobs em lote não podem ser reiniciados às 8h e quais subsistemas dependem uns dos outros.
 

Que questões diferenciam a segurança da IA ​​da governança da IA?

A maneira mais rápida de diferenciar os dois é comparar as perguntas que cada um faz ao fornecedor. Use ambos os conjuntos em todas as avaliações de IA.

Perguntas de segurança a fazer:

• Como proteger o modelo de entradas adversárias?
• Como controlar e registrar o acesso aos dados para detecção de violações?
• Qual é o seu processo de resposta a incidentes caso um invasor comprometa o modelo?

Questões de governança a serem consideradas:

• O que o agente de IA está autorizado a fazer e como você garante o cumprimento desse escopo?
• Quem aprovou cada ação tomada pelo agente e onde está esse registro?
• É possível gerar um registro de auditoria imutável da atividade do agente para uma revisão regulatória?

Um fornecedor que responde bem à primeira lista, mas tropeça na segunda, não possui uma arquitetura de governança. Esse fornecedor oferece um agente bem protegido que ninguém consegue controlar completamente.

O que acontece quando você trata a segurança e a governança da IA ​​como a mesma coisa?

Você acaba com falhas de governança que suas ferramentas de segurança nunca detectam. Aqui estão três exemplos que ocorrem em operações reais.

A interrupção não foi autorizada por ninguém. Um agente de IA reinicia um processo em lote de produção durante o horário de pico, e os tempos de resposta despencam. A equipe de segurança verifica seus registros e não encontra nenhuma violação, nenhuma intrusão e nenhuma anomalia. Mas ninguém consegue dizer quem autorizou a reinicialização, porque não havia nenhuma etapa de aprovação. Isso é uma falha de governança.

A auditoria que responde à pergunta errada. Um órgão regulador solicita um registro de todas as ações do agente de IA nos últimos 90 dias, incluindo quem aprovou cada uma delas. A equipe de segurança produz um registro de perímetro limpo. O registro comprova que ninguém invadiu o sistema, mas não diz nada sobre o que o agente fez. Isso é uma falha de governança.

O agente com acesso irrestrito a tudo. Um agente de IA opera com as credenciais completas de um operador sênior. Nenhuma violação de segurança ocorreu e ninguém fez mau uso de nada até o momento. Mas nada limita o escopo do agente, permitindo que ele leia, altere ou exclua tudo o que o operador pode. Isso é uma falha de governança prestes a ser desencadeada.

Em todos os casos, sua postura de segurança se manteve. Sua postura de governança, porém, nunca existiu.

Como construir segurança de IA e governança de IA sem confundi-las?

Execute-as como dois fluxos de trabalho paralelos, com responsáveis ​​e critérios de avaliação distintos. Não as combine em um único programa. Continue investindo em segurança e, em seguida, construa a camada de governança que sua infraestrutura de segurança nunca foi projetada para fornecer.

Essa camada precisa de quatro capacidades:

• Identidade do agente: Cada agente atua com suas próprias credenciais, separadas das do operador humano.
• Autorização com escopo definido: os agentes acessam apenas o que cada tarefa exige.
• Controles de aprovação humana: ações de alto risco são pausadas até que uma pessoa as autorize.
• Rastreamento de auditoria imutável: Cada ação, seu raciocínio e seu aprovador ficam registrados de forma que ninguém pode editar posteriormente.

Foguete^® EVA^™ é construída com base nesse tipo de arquitetura de governança. A Rocket EVA atribui a cada agente sua própria credencial de curta duração e com escopo definido. Ela aplica regras operacionais por meio de políticas como código e submete ações de alto risco à aprovação humana. Além disso, registra cada etapa em uma trilha de auditoria imutável, vinculada tanto ao agente quanto ao aprovador humano.

O Rocket EVA se integra à sua infraestrutura de segurança existente, em vez de substituí-la. Essa infraestrutura inclui gerenciamento de identidade e acesso, gerenciamento de serviços de TI e ferramentas de observabilidade. Sua equipe de segurança mantém o perímetro. Suas equipes de conformidade, risco e operações obtêm um registro que podem defender. Seus operadores obtêm operações controladas por agentes que aceleram o diagnóstico em ambientes mainframe, distribuídos e em nuvem, sem adicionar novos riscos.

Você não precisa escolher entre agir com rapidez e manter a responsabilidade. Ao construir ambas as frentes de trabalho agora, sua próxima implementação de IA começará sobre uma base que os órgãos reguladores reconhecerão.

Veja como a arquitetura do Rocket EVA aborda a governança da IA ​​— e não apenas a segurança.

Rocket é uma marca registrada da Rocket Software, Inc. e suas afiliadas.