As salvaguardas para IA empresarial podem ser mais importantes do que a fronteira

Esqueça a fronteira da IA. Os clientes estão pressionando as empresas a adotar mais salvaguardas para a IA já em uso, e a experiência com o PCI DSS oferece um modelo útil.

O período de lua de mel regulatório da IA acabou. Divulgações recentes deram início a discussões sobre desacelerar a fronteira e exigir controles. Um dos poucos pontos de consenso é que os controles devem ficar fora dos modelos, com verificação independente.

O que acontecerá a seguir ainda está em discussão, mas os órgãos reguladores estão avançando. A Lei de Inteligência Artificial da União Europeia está implementando gradualmente obrigações de segurança, incluindo a responsabilidade dos compradores. Nos Estados Unidos, o Referencial de Gestão de Riscos de IA do NIST está sendo adotado como padrão de diligência razoável. No mundo todo, o Top 10 da OWASP para Aplicações com LLM tornou-se uma referência comum nas avaliações de segurança, e a certificação ISO/IEC 42001 está aparecendo em documentos de compras.

Isso significa que os desenvolvedores de modelos não são os únicos responsáveis. As obrigações e os riscos de segurança também recaem sobre as empresas que usam modelos já lançados, sobretudo em casos de uso de alto risco. Respostas incorretas a um questionário de segurança de um cliente ou em uma proposta de solicitação de propostas (RFP) podem emperrar uma negociação B2B.

O PCI DSS aponta o caminho

Felizmente, já vimos esse filme. Há vinte anos, a segurança de aplicações web dependia principalmente de auditorias periódicas de código, análises estáticas e da disciplina dos desenvolvedores. Em seguida, o Requisito 6.6 do PCI DSS, publicado em 2006 e aplicado a partir de 2008, determinou que as organizações que lidam com dados de titulares de cartões revisassem todo o código das aplicações em busca de vulnerabilidades ou instalassem controles técnicos automatizados. Mais tarde, a opção de revisar o código foi eliminada, e os controles técnicos passaram a ser obrigatórios.

Mas o PCI DSS não começou como lei. Tudo começou com um padrão contratual que transformou o mercado, provavelmente mais rápido do que a legislação teria feito, porque os contratos avançam mais depressa do que as leis governamentais.

Da mesma forma, as organizações estão sentindo pressão para adotar salvaguardas para a IA implantada, não por parte dos órgãos reguladores, mas de clientes e parceiros — por meio de questionários de segurança, cláusulas em solicitações de propostas (RFPs) e exigências de apólices de seguro.

Resolva o problema operacional e a conformidade virá em seguida

Pode ser difícil lidar com essa pressão, porque a governança de IA não diz respeito apenas a políticas. Trata-se de evidências técnicas contínuas.

Muitas empresas com as quais converso executam meia dúzia de modelos ou mais em produção, frequentemente encadeando-os ou orquestrando-os para que a saída de um sirva de entrada para outro. Imagine demonstrar que uma política — como impedir que a saída de um modelo contenha informações de identificação pessoal (PII) — é aplicada em todo o sistema nessas condições. Auditar manualmente vários modelos configurados individualmente consumiria o tempo dos desenvolvedores. Além disso, a maioria das organizações tem dificuldade para lidar com o uso de IA não autorizado e de alto risco, como funcionários que colam dados confidenciais em ferramentas de IA para consumidores ou provedores de SaaS que habilitam discretamente novos recursos de IA. Ainda assim, toda a responsabilidade recai sobre a empresa.

Em cenários tão desafiadores, os requisitos podem ser reduzidos a uma tarefa simples: demonstrar que é possível restringir continuamente as entradas e saídas dos modelos, registrando essa atividade para verificação. Quando as aplicações chamam modelos, os agentes acionam ferramentas e os modelos executam ações ou iniciam fluxos de trabalho, o que precisa ser controlado é a ação: a chamada à ferramenta, a solicitação à API, o acionamento do fluxo de trabalho.

Leve a segurança para o caminho de inferência

Essa ação é o ponto de aplicação de controles que especialistas em segurança de aplicações vêm construindo há 20 anos para o tráfego de aplicações. Especialmente quando a inferência é encaminhada por uma infraestrutura compartilhada, esse caminho de inferência se torna o ponto de controle ideal para vários modelos e até mesmo para o uso de IA não autorizado. O tráfego de inferência de IA precisa ser encaminhado, inspecionado, autenticado e governado como qualquer outra interação importante com uma aplicação, com base na origem do tráfego e no que ele pretende fazer. Ao contrário das auditorias manuais, a governança do tráfego de inferência poderá ser ampliada.

Como começar

Diante dos rumos da regulamentação, as organizações precisam começar agora a fazer três coisas:

1. Mapeie sua superfície de responsabilidade, das APIs de SaaS e dos endpoints hospedados à IA paralela.
2. Desvincule as políticas e a aplicação dos controles de segurança dos modelos e leve-as para o caminho de inferência.
3. Garanta que os registros de auditoria sejam gerados fora do controle dos modelos e agentes, que já demonstraram tentar alterar os registros de suas próprias ações.

Ainda está sendo definido o que constitui monitoramento e aplicação de controles adequados, mas suas equipes de operações empresariais e de segurança sabem o que é realmente possível aplicar, quanto cada controle custa em latência e complexidade e em que situações uma regra bem-intencionada pode produzir o resultado errado. Envolva-as desde já. Os riscos de segurança e as obrigações associados ao uso da IA são reais, e seus clientes e executivos certamente se preocupam mais com os riscos que enfrentam hoje do que com as ameaças dos modelos de fronteira de amanhã.