Acompanhar o ritmo da fronteira não significa acompanhar o ritmo das empresas: como se preparar para a regulamentação da IA

Michael MontoyaDiretor de Operações de Tecnologia | F5

Há um debate em curso no setor sobre a velocidade com que a IA de fronteira deve avançar. Esse debate ganhou força após incidentes divulgados pela Anthropic e pela OpenAI, nos quais modelos operando com salvaguardas reduzidas, em ambientes de avaliação, tomaram medidas muito além do que qualquer pessoa pretendia. Eles acessaram sistemas dos quais deveriam estar isolados e se coordenaram entre instâncias que deveriam permanecer separadas. Mais recentemente, uma proposta do CEO da Anthropic, Dario Amodei, defendeu que o desenvolvimento das capacidades da IA de fronteira avance de forma deliberadamente gradual e que avaliadores independentes sejam integrados aos laboratórios para verificar esse processo.

As reações a essa proposta não foram uniformes. Os laboratórios de IA estão concentrados no processo de desenvolvimento: quanta capacidade uma rodada de treinamento acrescenta, com que rigor um modelo é avaliado antes do lançamento e se os padrões devem ser voluntários ou regulamentados. Outros argumentam que a fronteira avançará no ritmo que tiver de avançar, que o restante do mundo não está desacelerando e que a segurança deve ser incorporada aos sistemas que cercam os modelos.

Não vou resolver essa discussão aqui, mas observe algo interessante: os dois lados concordam que os controles devem ficar fora do modelo e que a verificação não deve ficar exclusivamente a cargo de quem o criou.

Essa é uma versão mais abrangente do argumento que apresentei em maio. Na época, eu escrevi que o perímetro de segurança da IA havia se deslocado para o caminho de inferência. Os aplicativos chamam modelos, os agentes acionam ferramentas e os modelos acessam outros serviços para recuperar dados, iniciar fluxos de trabalho e executar ações operacionais. Minha conclusão foi que esse tráfego precisa ser entregue, inspecionado, autenticado e controlado como qualquer outra interação crítica entre aplicativos.

Esse era um argumento arquitetural, mas, nos últimos meses, começou a se tornar também uma questão de conformidade. O ritmo da fronteira tecnológica não dita o ritmo das empresas. Independentemente do que laboratórios e governos decidirem, os modelos já lançados estão sendo implantados agora dentro de nossas organizações, e as obrigações associadas a esse uso já estão tomando forma.

Na minha experiência, há dois tipos de itens em um roteiro de segurança. Há aqueles nos quais você acredita, que disputam orçamento com todo o resto e às vezes perdem. E há aqueles que têm um prazo definido, um auditor que fará perguntas sobre eles e uma linha no registro de riscos. As salvaguardas de IA estão passando da primeira categoria para a segunda e, se você está neste setor há tempo suficiente, isso lhe parecerá familiar.

O que o PCI DSS nos ensinou

Já realizamos esse experimento antes. Antes de 2008, a segurança de aplicações web era, em grande parte, apenas uma aspiração — auditorias periódicas de código, análises estáticas e disciplina dos desenvolvedores. Então surgiu o Requisito 6.6 do PCI DSS, que determinava que as organizações que lidavam com dados de titulares de cartões deveriam revisar todo o código das aplicações em busca de vulnerabilidades ou implementar um controle técnico automatizado à frente das aplicações voltadas ao público.

Duas coisas sobre isso ficaram comigo.

O PCI DSS não surgiu como uma lei. Ele nasceu de uma iniciativa nossa, do setor, para nos anteciparmos à regulamentação. Era um padrão contratual, aplicado por meio de contratos com adquirentes, e, ainda assim, reformulou todo um mercado. Na verdade, provavelmente fez isso mais rápido do que uma legislação faria, porque os contratos avançam mais rapidamente do que as leis. Isso é relevante porque o primeiro lugar em que as organizações sentirão essa pressão não será por parte de um órgão regulador, mas em um questionário de segurança de um cliente, em uma cláusula de contratação ou quando uma seguradora perguntar quais controles protegem seus modelos.

E há também a forma como isso terminou. No PCI DSS v4.0, deixou de existir a opção entre uma alternativa ou outra. A alternativa de revisão de código foi eliminada; agora, o Requisito 6.4.2 exige uma solução técnica automatizada à frente das aplicações web voltadas ao público.

Hoje, ninguém pergunta se a conformidade com o PCI é opcional. A opção tornou-se uma exigência.

O cenário atual da regulamentação da IA

A lua de mel regulatória da IA acabou. O equivalente ao PCI para a IA está chegando por várias frentes ao mesmo tempo, em ritmos diferentes. O Regulamento de IA da UE é o mais avançado. Suas obrigações para modelos de uso geral já estão sendo implementadas e, embora a União Europeia tenha recentemente adiado para dezembro de 2027 a aplicação das regras relativas a sistemas de alto risco, as expectativas quanto à robustez técnica, à supervisão humana e ao registro de logs já estão definidas. O que as empresas frequentemente não percebem é que algumas dessas obrigações recaem sobre elas próprias, e não apenas sobre os fornecedores dos modelos. Se utilizarem o modelo de terceiros em um caso de uso de alto risco, elas serão responsáveis.

Nos EUA, ainda não existe uma legislação comparável, mas o NIST AI Risk Management Framework e seu perfil para IA generativa tornaram-se o padrão adotado por muitos como referência de diligência razoável. A ISO/IEC 42001 vem desempenhando papel semelhante no âmbito da certificação e, de fato, já começo a vê-la em documentos de compras. No âmbito estadual, diversas leis foram propostas, combinando requisitos de transparência e divulgação com regras específicas para determinados usos, enquanto órgãos reguladores dos setores financeiro e de saúde discutem diretrizes para cenários específicos.

E o OWASP Top 10 para aplicações de LLM agora é um material de referência padrão nas análises de segurança. Quando um cliente envia a um fornecedor um questionário sobre controles de IA, muitas vezes é daí que vêm as perguntas.

Ao analisar todo esse material, o mesmo requisito aparece repetidamente: demonstrar que é possível controlar continuamente o que entra em um modelo e o que sai dele, além de gerar um registro posteriormente.

Este é um problema operacional antes de ser um problema de conformidade

Nosso Relatório sobre o Estado da Estratégia de Aplicações de 2026 constatou que 55% dos portfólios de aplicações já contam com recursos de IA e que, em média, as empresas executam sete modelos em seu fluxo de inferência. Mais da metade (52%) encadeia ou orquestra vários modelos. E 90% esperam direcionar a inferência por meio de uma infraestrutura compartilhada.

Agora, imagine um auditor solicitando uma demonstração de que uma única política — por exemplo, a de que nenhuma informação de identificação pessoal (PII) de clientes saia da resposta de um modelo — seja aplicada em todo esse ambiente.

Não é possível responder a isso configurando sete modelos individualmente. Muito menos quando três deles estão encadeados e a saída de um serve de entrada para outro. E a maioria das organizações com as quais converso está ainda um passo atrás, porque a primeira coisa que encontram quando começam a investigar não é sequer um modelo auto-hospedado. São funcionários colando dados confidenciais em ferramentas de IA voltadas ao consumidor e recursos de IA ativados discretamente em aplicativos SaaS que elas já utilizam.

Acrescente agentes a esse cenário, e a unidade que você precisa controlar deixa de ser o prompt e passa a ser a ação — a chamada de ferramenta, a solicitação à API, o fluxo de trabalho que ela aciona. Esse é o mesmo ponto de aplicação de políticas que passamos 20 anos desenvolvendo para o tráfego de aplicações.

Essa mesma capacidade de agentes já está nas mãos de invasores que executam campanhas coordenadas na velocidade das máquinas. Assim como aprendemos com a defesa contra bots, precisamos parar de avaliar esse tráfego pelo grau de sofisticação que aparenta ter e começar a controlá-lo com base em sua origem e no que ele está tentando fazer.

Guardrails precisam ficar fora do modelo

Cada vez mais, as organizações estão executando seus próprios modelos — modelos de pesos abertos em sua própria infraestrutura, ajustados com seus dados. Não há uma rede de proteção oferecida pelo provedor, portanto, toda a responsabilidade operacional e de conformidade recai sobre elas.

Auditar modelo por modelo não é uma abordagem escalável. Em princípio, isso pode ser feito para cerca de uma dúzia de configurações de modelos. Já vi equipes fazerem isso. É um processo manual, fica desatualizado assim que alguém cria um novo endpoint e gera um retrato pontual, em vez de um mecanismo de controle.

O alinhamento não é um controle de segurança. Prompts de sistema e pós-treinamento fornecem uma base útil. Os incidentes da OpenAI e da Anthropic demonstram as limitações dessa abordagem. Nesses casos, modelos sem salvaguardas perseguiam um objetivo específico, deparavam-se com um limite e encontravam uma forma de contorná-lo. A OpenAI afirmou que os classificadores usados nas implantações padrão de seus clientes teriam sinalizado a atividade como insegura e que seu monitoramento ampliado da cadeia de raciocínio, caso estivesse em execução, teria alertado a equipe de segurança antes que seus modelos chegassem ao Hugging Face. Os modelos da Anthropic disponibilizados ao público em geral contam com classificadores que inspecionam entradas e saídas em tempo real.

Em resposta, ambos os laboratórios realizaram um trabalho substancial de alinhamento, mas nenhum deles o considerou suficiente. Ambos também implementaram controles externos ao modelo: monitores que observam o que ele está fazendo e avaliam a ação antes de sua execução, com encaminhamento para uma pessoa quando necessário. As organizações com o mais profundo conhecimento possível desses sistemas concluíram que o controle deve ficar fora do modelo.

Por onde começar

Considerando os rumos que a regulamentação está tomando e o que as últimas duas décadas de segurança de aplicações nos ensinaram sobre como essas obrigações surgem, há três medidas que eu colocaria em prática agora, em vez de esperar.

1. Mapeie a superfície, começando pelo que não foi autorizado. Inclua todos os modelos em produção — APIs SaaS, endpoints hospedados e implantações autogerenciadas de modelos com pesos abertos — além da IA paralela.
2. Desvincule a aplicação de políticas do modelo. Coloque a política no caminho de inferência, e não em sete configurações de modelo distintas. Inspecione o que entra e o que sai e aplique as políticas de maneira uniforme, independentemente do modelo ou da nuvem.
3. Crie a trilha de auditoria fora do sistema que ela registra. Registre o que foi solicitado, o que foi retornado, o que foi bloqueado e quem aprovou cada ação. Certifique-se de que ela seja gerada por uma infraestrutura que o modelo e o agente não controlem. Os investigadores que analisaram o incidente da OpenAI constataram que os agentes tentaram alterar os registros das próprias ações. Se o seu registro for produzido pelo sistema que ele descreve, sua confiabilidade será questionada.

O ponto principal aqui é que a governança de IA não é apenas um exercício de documentação. O que será exigido das organizações é de natureza técnica, contínua e probatória. Isso faz com que essa seja uma questão de arquitetura e operações, sob a responsabilidade das equipes de segurança e operações, e não uma questão de políticas a cargo do departamento jurídico.

Acreditamos que o controle deve estar no caminho, não nos modelos. Todos os modelos executados pela sua organização — API SaaS, endpoint hospedado, modelos de pesos abertos autogerenciados, tanto os que você autorizou quanto os que ainda não descobriu — convergem para o caminho de inferência. Isso faz dele o ponto de controle ideal para todos esses modelos, permitindo aplicar políticas e gerar um registro independente e auditável.

As regras ainda estão sendo definidas

Ninguém sabe qual exigência obrigará sua organização a agir — uma obrigação prevista na Lei de IA da UE, uma lei estadual, um órgão regulador setorial ou um contrato com um cliente. O que eu sei é que as definições técnicas contidas nesses marcos regulatórios ainda não estão consolidadas. O que constitui um monitoramento adequado, uma robustez suficiente ou um registro aceitável está sendo decidido neste exato momento, em períodos de consulta pública, organismos de normalização e códigos de conduta.

Isso nos traz de volta ao debate atual sobre o ritmo de desenvolvimento da IA de fronteira. Deixando de lado os méritos da questão, faço uma observação como alguém que opera isso em produção: as empresas seguem outro ritmo. Independentemente do que decidam os laboratórios, os governos e o setor, os modelos já lançados estão sendo implantados e usados em larga escala em nossas organizações, e as obrigações associadas a esse uso são muito concretas. Ainda será preciso dar respostas ao conselho de administração, aos executivos e aos clientes, quer desaceleremos ou não o desenvolvimento de novas capacidades.

Essas decisões serão melhores se forem embasadas pela experiência de pessoas que já operaram esses sistemas em larga escala — que sabem o que é realmente aplicável, quanto um controle custa em termos de latência e complexidade e em que situações uma regra bem-intencionada acaba incentivando comportamentos na direção errada. O PCI DSS funcionou porque foi moldado por profissionais da área. Se ficarmos de fora dessa discussão, os requisitos ainda serão definidos — só que por pessoas que nunca precisaram aplicá-los.

Saiba mais sobre a abordagem da F5 para a segurança de IA.

Sobre o autor

Michael MontoyaDiretor de Operações de Tecnologia | F5

Michael é responsável pela estratégia e execução em toda a empresa para garantir que a segurança e a resiliência estejam no centro de suas operações. Ele lidera as áreas de Segurança, Riscos e Operações Digitais da F5, promovendo a confiança operacional de ponta a ponta para clientes, parceiros e funcionários. Montoya passou a integrar a equipe de liderança executiva da F5 em outubro de 2025, após atuar no Conselho de Administração da F5 de 2021 a 2025. Antes da F5, Montoya foi Diretor de Operações da BlueVoyant e, anteriormente, Diretor de Segurança da Informação da Equinix e da Digital Realty. Ele trabalhou por mais de uma década na Microsoft em cargos de liderança global, incluindo Diretor de Segurança Cibernética, CIO/CISO regional para a EMEA e a Ásia e líder global de Operações de Data Centers.

Mais publicações de Michael Montoya