Onde os Padrões de Segurança de IA Param — e a Proteção em Tempo de Execução Deve Começar

Com toda a discussão sobre os riscos de segurança de IA, uma questão que parece ser negligenciada é a seguinte: o fato de que os sistemas de IA só funcionam exposto seus ativos mais valiosos — modelos e dados.

Ao contrário do software tradicional, a IA não simplesmente executa lógica pré-definida. Ela mistura continuamente modelos proprietários com entradas sensíveis para gerar saídas, frequentemente em infraestruturas que não foram projetadas para proteger a computação.

Dessa forma, a segurança tradicional não é suficiente. A criptografia é eficaz quando os dados são armazenados ou transmitidos por uma rede, mas não quando os dados são processados ou operados. Para a IA em particular, o perigo surge quando um modelo é implantado. Seus parâmetros são carregados na memória, inicializados e exercitados em escala – o ponto em que a criptografia para – expondo-o a acesso não autorizado potencial. Durante a inferência, dados sensíveis fluem através desse mesmo espaço exposto. O resultado é uma superfície de risco altamente vulnerável: sistemas de IA que podem parecer seguros – mas estão na verdade desprotegidos nos momentos mais críticos.

Órgãos de padronização, como o Instituto Nacional de Padrões e Tecnologia (NIST), a Agência de Cibersegurança da União Europeia (anteriormente conhecida como Agência de Segurança de Rede e Informação da União Europeia, ou ENISA), e o Projeto de Segurança de Aplicativos Web Abertos (OWASP) começaram a mapear esse território. Eles descrevem os riscos, nomeiam as vulnerabilidades e delineiam princípios de governança. Mas eles param de prescrever como proteger modelos como propriedade intelectual e dados como ativos confidenciais uma vez que a execução começa. Fechar essa lacuna requer repensar a segurança de IA – não como um exercício de conformidade, mas como um problema de computação em si. É aqui que a criptografia em uso, ou criptografia de ponta a ponta, desempenha um papel.

O Ponto Cego na Segurança de IA Moderna

A maioria das conversas sobre segurança de IA ainda orbita o terreno familiar: governança de dados de treinamento, controles de acesso, monitoramento de API e políticas de usuário responsáveis. Essas são necessárias. No entanto, nenhuma delas aborda o que acontece após a implantação, quando um modelo deixa o repositório e se torna um sistema vivo.

Uma vez implantado, os parâmetros de um modelo não são mais artefatos abstratos. Eles são ativos vivos, residentes na memória, continuamente acessados durante a inferência e frequentemente usados por vários locatários ou clientes por meio de serviços de IA compartilhados. Essa exposição ocorre antes de qualquer solicitação de inferência ser feita, compounding o risco ao introduzir entradas sensíveis e comportamento observável externamente.

Tratar a proteção do modelo como uma preocupação pré-implantação e a segurança da inferência como uma preocupação em tempo de execução perde o ponto. Em sistemas reais, esses riscos se sobrepõem. Modelos e dados são expostos durante a inicialização, execução e saída. A segurança que começa e termina com controles de armazenamento falha em abordar essas exposições.

O que o NIST Acerta — e Onde Para

O Quadro de Gerenciamento de Risco de IA do NIST se tornou uma pedra angular para organizações que tentam gerenciar o risco de IA. Sua estrutura — governar, mapear, medir, gerenciar — oferece uma maneira disciplinada de pensar sobre responsabilidade, contexto, impacto e mitigação ao longo do ciclo de vida de IA.

O que o NIST faz particularmente bem é enquadrar o risco de IA como sistêmico, e não acidental. As falhas de IA raramente são eventos de único ponto; elas surgem de interações entre modelos, dados, pessoas e infraestrutura. Esse enquadramento é essencial.

Onde o quadro falha é em não ditar como os ativos de IA de alto valor são protegidos uma vez que os sistemas estão vivos. Os parâmetros do modelo são implicitamente tratados como artefatos de design-time, e não como ativos em tempo de execução. Ambientes de execução são assumidos como confiáveis o suficiente.

Na prática, os parâmetros do modelo são frequentemente os ativos mais valiosos que uma organização possui. Eles são carregados na memória, copiados em nós, armazenados em cache e reutilizados. Se o gerenciamento de risco de IA falha em considerar a confidencialidade dos modelos durante a implantação e execução, um ativo crítico permanece fora do limite de risco, como um pato sentado.

ENISA e a Realidade de Ameaças Específicas de IA

O trabalho da ENISA sobre a cibersegurança de IA impulsiona a conversa mais adiante. Seu quadro multilayer distingue entre a segurança de infraestrutura tradicional e os riscos específicos de IA, reconhecendo que os sistemas de IA se comportam de maneira diferente — e falham de maneira diferente — do que o software convencional.

Por que isso é importante? A IA introduz ameaças que não se encaixam bem nos controles existentes: extração de modelo, vazamento de parâmetros, exposição de co-tenancy e manipulação durante a execução. Esses riscos não exigem atacantes exóticos. Eles surgem naturalmente quando modelos de alto valor são executados em ambientes compartilhados ou gerenciados externamente.

O quadro da ENISA implicitamente reconhece que proteger a IA significa proteger o comportamento, e não apenas o código. Mas, como a maioria dos padrões, ele se concentra no que deve ser considerado, e não em como as proteções são tecnicamente aplicadas uma vez que os modelos estão em execução.

OWASP e o Custo da Inteligência Observável

A OWASP Top 10 para Aplicações de Modelos de Linguagem Grande oferece uma visão mais concreta de como os sistemas de IA quebram no mundo real. Injeção de prompt, divulgação de informações sensíveis, vazamento de incorporação, transparência excessiva de saída — essas não são preocupações teóricas. Elas são os subprodutos de implantar modelos poderosos sem restringir o que eles revelam.

Embora essas questões sejam frequentemente enquadradas como problemas de camada de aplicativo, suas consequências são mais profundas. A exposição repetida do comportamento do modelo pode levar a clonagem eficaz; incorporações mal isoladas podem revelar estrutura; e o abuso de inferência se torna uma via para a replicação do modelo.

A taxonomia da OWASP deixa claro uma coisa: proteger a IA não é apenas parar entradas ruins. É limitar o que os modelos expõem — interna e externamente — uma vez que estão operacionais.

Uma Conclusão Compartilhada, um Trabalho Inacabado

Ao longo do NIST, ENISA e OWASP, há um amplo acordo sobre os fundamentos:

• O risco de IA abrange o ciclo de vida
• Os sistemas de IA introduzem novas categorias de ameaças
• Modelos e dados são ativos de alto valor
• A exposição em tempo de execução é inevitável

O que esses quadros carecem, no entanto, é um mecanismo para aplicar confidencialidade uma vez que os modelos são implantados e a computação começa. Essa omissão não é um defeito, pois os padrões definem intenção e escopo. A implementação é normalmente deixada ao designer do sistema.

Mas eles deixam uma lacuna crítica — uma que cresce mais ampla à medida que os sistemas de IA escalonam.

A Criptografia em Uso Muda a Equação

A criptografia em uso altera o modelo de segurança. Em vez de assumir que os dados e os modelos devem ser expostos para serem úteis, ela trata a computação como algo que pode ser protegido.

Em termos práticos, isso significa:

• Modelos permanecem criptografados durante a implantação, inicialização e execução
• Entradas nunca são visíveis em texto puro para o ambiente de execução
• Estados intermediários não podem ser inspecionados ou modificados
• A infraestrutura não precisa mais ser implicitamente confiável

Isso não substitui os quadros de governança ou os controles de camada de aplicativo — ele os torna operacionais. Ele transforma princípios de risco em garantias aplicáveis exatamente quando os sistemas de IA estão mais vulneráveis.

Em outras palavras, a criptografia em uso é a camada ausente entre a política de IA e a realidade de IA.

Quando a Governança Termina e a Execução Começa: Protegendo a Computação de IA

A segurança de IA quebra em tempo de execução. Uma vez implantados, os modelos de IA e os dados sensíveis devem ser expostos na memória para funcionar, criando uma superfície de risco que os controles tradicionais — criptografia em repouso, criptografia em trânsito e quadros de governança — nunca foram projetados para proteger.

Órgãos de padronização, como o NIST, ENISA e OWASP, fizeram progresso crítico em definir o risco de IA, a responsabilidade e o mau uso. Mas sua orientação trata os modelos principalmente como artefatos de design-time e assume que os ambientes de execução podem ser confiáveis. Na prática, os parâmetros do modelo e as entradas sensíveis são continuamente acessados, reutilizados e frequentemente processados em ambientes compartilhados ou gerenciados externamente.

Fechar essa lacuna requer repensar a segurança de IA não como um exercício de conformidade, mas como um problema de proteger a computação em si — quando os modelos estão vivos, os dados estão em uso e a exposição é inevitável. A criptografia em uso oferece uma maneira viável de manter os modelos de IA e as entradas sensíveis seguros em todas as etapas do ciclo de vida de IA.