O caminho da inferência é o caminho do tráfego: onde a segurança de IA precisa estar

Abbas KudratiCISO de Campo para a APCJ | F5

Em um artigo anterior, argumentei que, diante de um modelo da classe Mythos, o local onde um ataque é interceptado importa mais do que sua detecção, e que o caminho do tráfego é o único ponto de controle que um adversário capaz de raciocinar não consegue contornar. Este artigo leva essa discussão para dentro da empresa: o que de fato percorre esse caminho quando uma organização coloca a IA em prática e por que a resposta muda a forma como projetamos a segurança.

Há alguns meses, participei de uma discussão sobre IA empresarial que começou como a maioria delas. Qual modelo devemos usar? Devemos executá-lo por conta própria ou recorrer a um modelo público? Como podemos aumentar a precisão e reduzir as alucinações? Todas são boas perguntas. Mas ninguém perguntou o que acontece depois que o modelo é escolhido.

Eis o que acontece. Um usuário envia um prompt. Um aplicativo o recebe, verifica quem é o usuário, obtém o contexto de um repositório de documentos ou de um banco de dados e aciona algumas APIs internas. Um agente pode decidir que uma ferramenta é necessária. A solicitação montada chega ao modelo, que gera tokens. Esses tokens podem ser uma resposta. Mas também podem ser a instrução que aciona a próxima chamada de API, o próximo fluxo de trabalho ou uma alteração em um sistema de registro.

Visto dessa forma, o modelo é apenas um componente de uma cadeia muito mais longa. É a essa cadeia que me refiro como caminho de inferência, e a observação na qual este artigo se baseia é simples: O caminho de inferência é o caminho do tráfego.

O que realmente é o caminho de inferência

O treinamento ensina um modelo. A inferência é o momento em que o modelo treinado é colocado em ação. Quando um funcionário pede a um assistente corporativo para “resumir os resultados mais recentes e redigir um e-mail para a equipe de liderança”, a solicitação percorre um caminho mais ou menos assim:

Usuário → Aplicativo → Identidade → Contexto e recuperação → APIs → Agente → Modelo → Ferramentas → Modelo → Resposta → Usuário

Cada etapa dessa jornada envolve tráfego de rede e de aplicações. Ela tem endpoints, latência, decisões de roteamento e uma identidade associada. Ela transporta dados, consome orçamento e, cada vez mais, carrega consigo a autoridade para realizar alguma ação.

Minha colega Lori MacVittie levantou uma questão relacionada no início deste ano: a inferência é um comportamento de execução em produção e funciona como uma camada de aplicação, com usuários, padrões de tráfego, sensibilidade à latência, modos de falha, restrições de custo e riscos de segurança. Kunal Anand, diretor de produtos da F5, descreve essa mesma jornada como uma nova cadeia de geração de valor, desde o prompt até a entrada, passando por fluxos de trabalho e inferência, e retornando ao usuário. Quando se adota essa perspectiva, a discussão sobre segurança também precisa acompanhá-la. Mani Ganesan, vice-presidente de gerenciamento de produtos de segurança de IA da F5, analisa o que essa mudança representa para a superfície de ataque em seu blog recente, “Sua IA agora é uma superfície de ataque. Você está preparado para protegê-la?”

Quatro premissas que vale a pena abandonar

À medida que os CISOs reforçam a segurança da IA, estas são quatro suposições que todos precisamos abandonar:

• “O modelo é tudo.” O modelo recebe toda a atenção porque é a parte visível. Mas o prompt pode conter dados confidenciais, a etapa de recuperação pode acessar registros sigilosos, o agente pode armazenar credenciais de API e a ferramenta acionada por ele pode ter permissão para gravar em um banco de dados. Proteger apenas o modelo é como reforçar a segurança de um banco de dados e ignorar a aplicação e as APIs que se comunicam com ele. A superfície de ataque abrange todo o caminho.
• “Passar do piloto para a produção é um exercício de escalabilidade.” Um projeto piloto normalmente tem um modelo, poucos usuários, uma aplicação e acesso aprovado manualmente. A produção é completamente diferente. Relatório sobre o Estado da Estratégia de Aplicações de 2026 da F5 constatou que as organizações coordenam, em média, sete modelos de IA, sendo que 77% afirmam que a inferência, e não o treinamento, é agora sua principal atividade de IA, e 52% encadeiam ou orquestram vários modelos. Não se trata da mesma arquitetura com mais usuários. É uma arquitetura diferente, e o modelo de segurança precisa mudar com ela.
• “Velocidade, segurança e governança são camadas separadas.” Considere um prompt que contenha informações pessoais. Em algum ponto entre o usuário e o modelo, essa solicitação precisa ser inspecionada, ter dados ocultados quando exigido pela política, ser encaminhada a um modelo aprovado, monitorada e registrada para fins de auditoria — tudo isso enquanto está em trânsito. O mesmo ponto de decisão que pergunta “Para onde vai esta solicitação?” agora também precisa responder: “Ela deve mesmo ir para lá?”. Trata-se de uma única decisão de processamento de tráfego, e não de três funções acopladas.
• “Podemos integrar ferramentas pontuais.” Uma organização certamente pode montar esse conjunto de soluções: gateway de API, WAF, DLP, IAM, mecanismos de proteção para IA, gateway de modelos, observabilidade, SIEM, controles de agentes e segurança de MCP. Nenhuma dessas ferramentas é ruim. O problema está nas lacunas entre elas. Imagine uma solicitação passando por seis pontos de controle, cada um com seu próprio mecanismo de políticas e contexto de identidade. Quem sabe se o usuário que digitou o prompt é a mesma identidade que agora está acionando a ferramenta? Quem consegue identificar que a chamada de API, a chamada do modelo e a chamada da ferramenta fazem parte de uma única transação? Quem consegue aplicar uma política consistente ao longo de todo o percurso e comprovar posteriormente o que aconteceu?

No meu blog anterior, destaquei que as brechas entre as ferramentas são o primeiro lugar onde um adversário capaz de raciocinar procura explorar. O mesmo vale para um agente bem-intencionado que simplesmente acaba agindo fora das políticas estabelecidas.

Quando a inferência passa a ser tratada como tráfego, o próprio caminho se torna o lugar natural para aplicar controles de identidade, políticas, proteção de dados e controle de agentes, tanto na entrada quanto na saída.

Quando o tráfego passa a carregar intenção

A IA acrescenta novas etapas à conhecida sequência solicitação-roteamento-política-resposta: contexto, recuperação, orquestração e invocação de ferramentas. Mas a mudança mais profunda está no que o tráfego transporta. O tráfego convencional transporta dados. O tráfego de inferência transporta intenção, contexto e decisões.

Isso é ainda mais importante quando se trata de agentes. Um assistente que responde a uma pergunta é uma coisa. Já um agente capaz de ler registros de clientes, abrir chamados, enviar e-mails, executar código, alterar a infraestrutura ou emitir uma ordem de pagamento é algo completamente diferente. O caminho de inferência se transforma em um caminho de ação, e o impacto de uma decisão equivocada deixa de se limitar ao âmbito informacional.

A transação de inferência é a nova unidade de segurança

A segurança tradicional considera usuários, dispositivos, aplicações, APIs, cargas de trabalho e dados. O modelo de confiança zero nos ensinou a perguntar não apenas “Quem é você?”, mas também “O que você está tentando acessar?”. Os sistemas de IA exigem uma terceira pergunta: “O que você está pedindo à IA para fazer, com quais dados, por meio de qual modelo e quais ações essa interação pode desencadear?”

Responder a isso exige um contexto que nenhum controle existente detém isoladamente. Considere um usuário autenticado de um copiloto financeiro cuja solicitação envia dados financeiros confidenciais para um modelo externo, é encaminhada a um agente financeiro e termina em uma chamada à API do ERP para criar uma instrução de pagamento. A identidade do usuário, por si só, não é suficiente para embasar essa decisão. É preciso considerar a transação como um todo.

É por isso que identidade, segurança de aplicações, segurança de APIs, segurança de IA e gerenciamento de tráfego estão convergindo. O ponto de convergência é a transação de inferência: identidade mais prompt mais contexto mais modelo mais dados mais ferramentas mais saída mais ação. Trata-se de um objeto muito mais rico do que uma requisição HTTP.

Quando você passa a pensar em termos de transações, a segurança deixa de ser um ponto de verificação e se torna um ciclo. Antes da inferência, é preciso saber quem está fazendo a solicitação, quais dados estão sendo fornecidos, se o prompt é malicioso e qual modelo deve recebê-lo.

Durante a inferência, as questões são se a solicitação está em conformidade com as políticas e dentro do orçamento, e se um agente está tentando chamar uma ferramenta para a qual nunca recebeu autorização. Após a inferência, as questões são se é seguro retornar a resposta, se ela acionou alguma ação e o que precisa ser registrado. Cada decisão deve ser tomada por onde o tráfego passa, pois esse é o único lugar em que todo o contexto está disponível ao mesmo tempo.

O que isso significa para os CISOs

Já vimos esse padrão antes. Os monólitos se transformaram em aplicações distribuídas, o modelo cliente-servidor evoluiu para APIs e microsserviços, e a segurança de perímetro deu lugar a controles baseados em identidade e sensíveis às aplicações. Em cada uma dessas transições, a infraestrutura responsável por entregar e proteger o tráfego ganhou importância estratégica. A inferência é a próxima etapa desse ciclo.

Portanto, a pergunta a ser feita à sua equipe de arquitetura não é apenas onde seus modelos estão hospedados. Pergunte por onde flui o tráfego de inferência, o que ele transporta, o que pode acessar, quais decisões toma e quais ações pode desencadear. Em seguida, faça a pergunta mais difícil: onde podemos aplicar políticas a tudo isso sem comprometer o desempenho da aplicação?

Porque, na era da IA, o perímetro de segurança mais importante talvez não esteja mais ao redor do modelo, mas no caminho de ida e volta até ele.

Para saber mais sobre como a F5 aborda essa questão, acesse a página do F5 AI Gateway. Não deixe também de ler meu post anterior no blog: “Detendo a IA de fronteira na rede: por que o controle inline é uma vantagem essencial contra modelos da classe Mythos.”

Sobre o autor

Abbas KudratiCISO de Campo para a APCJ | F5

Mais publicações de Abbas Kudrati