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

Com todo o falatório sobre os riscos de segurança de IA, uma questão que parece ser negligenciada é esta: o fato de que os sistemas de IA só funcionam expondo 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 across 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 atualmente desprotegidos nos momentos mais críticos.

Órgãos de padronização como o National Institute of Standards and Technology (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 Europa, ou ENISA), e o Open Web Application Security Project (OWASP) começaram a mapear esse território. Eles descrevem os riscos, nomeiam as vulnerabilidades e delineiam princípios de governança. Mas 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 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, aumentando assim o risco ao introduzir entradas sensíveis e comportamento externamente observável.

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

A Estrutura de Gerenciamento de Risco de IA do NIST se tornou uma pedra angular para as organizações que tentam gerenciar o risco de IA. Sua estrutura — governar, mapear, medir, gerenciar — oferece uma forma 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 como acidental. As falhas de IA raramente são eventos de um único ponto; elas surgem das interações entre modelos, dados, pessoas e infraestrutura. Esse enquadramento é essencial.

Onde a estrutura falha é em não ditar como os ativos de IA de alto valor são protegidos uma vez que os sistemas estão ao vivo. Os parâmetros do modelo são implicitamente tratados como artefatos de tempo de design 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 a propriedade intelectual mais valiosa 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. Sua estrutura 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 forma diferente — e falham de forma diferente — do que o software convencional.

Por que isso é importante? A IA introduz ameaças que não se encaixam perfeitamente nos controles existentes: extração de modelo, vazamento de parâmetros, exposição de co-tenância 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.

A estrutura da ENISA implicitamente reconhece que garantir a segurança de IA significa garantir o comportamento, não apenas o código. Mas como a maioria dos padrões, ela 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

OWASP’s Top 10 para Aplicativos de Modelo 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. São os subprodutos de implantar modelos poderosos sem restringir o que eles revelam.

Embora essas questões sejam frequentemente enquadradas como problemas de aplicação, 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 um caminho para a replicação do modelo.

A taxonomia do OWASP deixa claro uma coisa: proteger a IA não é apenas sobre parar entradas ruins. É sobre 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 essas estruturas 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 elas deixam uma lacuna crítica — que cresce à medida que os sistemas de IA se expandem.

Criptografia em Uso Muda a Equação

A criptografia em uso altera o modelo de segurança. Em vez de supor que os dados e 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 aplicação — opera-os. 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: Garantindo a Computação de IA

A segurança de IA se desintegra 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 estruturas 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, responsabilidade e mau uso. Mas sua orientação trata principalmente os modelos como artefatos de tempo de design 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 forma viável de manter os modelos de IA e as entradas sensíveis seguras em todas as etapas do ciclo de vida de IA.