Políticas no payload: preparando-se para arquiteturas de agentes de IA

Os agentes de IA estão mudando a forma como as aplicações interagem com a infraestrutura. Ao contrário dos sistemas tradicionais, os agentes incorporam seus próprios objetivos, contexto e lógica de decisão em cada solicitação — o que fazer, como se recuperar e o que define o sucesso. Essa mudança rompe premissas há muito estabelecidas sobre o gerenciamento de tráfego e exige repensar a infraestrutura empresarial. Roteamento estático, recursos compartilhados e políticas centralizadas já não são suficientes em um mundo com autonomia por solicitação.

As arquiteturas de agentes exigem que a infraestrutura evolua da execução reativa para a interpretação, em tempo real, da intenção incorporada. As empresas que reconhecem essa mudança podem se preparar sem descartar os investimentos existentes, optando por adaptá-los.

Introdução

Os agentes de IA não são apenas aplicações inteligentes. Eles representam uma mudança estrutural na forma como as aplicações operam, tomam decisões e se adaptam. Ao contrário dos sistemas tradicionais, os agentes não apenas respondem às políticas de tráfego — eles trazem as suas próprias. Cada solicitação enviada por eles carrega não apenas dados, mas também uma lógica incorporada: o que deve acontecer, como o mecanismo de contingência deve se comportar e o que caracteriza o sucesso.

Essa mudança transfere a tomada de decisões dos planos de controle estáticos para o próprio ambiente de execução. Ela elimina a separação há muito estabelecida entre os planos de controle e de dados, obrigando a infraestrutura de tráfego — balanceadores de carga, gateways e proxies — a interpretar políticas específicas de cada solicitação, em vez de apenas executar passivamente rotas pré-configuradas.

Este artigo analisa como as arquiteturas de agentes rompem pressupostos fundamentais da engenharia de tráfego, desde verificações de integridade e lógica de fallback até observabilidade e aplicação de políticas de segurança. Ele explica por que estruturas tradicionais, como pools estáticos e métricas de integridade baseadas em médias, já não são suficientes em um mundo no qual a intenção varia a cada solicitação. Também defende que a infraestrutura de Camada 7 precisa evoluir, sob o risco de se tornar um componente básico indiferenciado — confiável, porém estrategicamente invisível. Para se adaptar, as organizações precisam repensar sua pilha de tráfego, tornando-a programável em tempo de execução, sensível ao contexto e alinhada a protocolos nativos para agentes, como o Model Context Protocol (MCP). Isso inclui reformular a lógica de fallback, adotar a observabilidade semântica e viabilizar a aplicação de políticas definidas pelos agentes. Ferramentas emergentes, como a rotulagem de dados em tempo real, oferecem suporte essencial para essa transição.

Em suma, o futuro do gerenciamento de tráfego não se resume apenas a entregar pacotes, mas a executar propósitos.

Arquiteturas de agentes: principais características

As arquiteturas de agentes introduzem um novo modelo operacional no qual componentes autônomos baseados em IA generativa — chamados de agentes — executam tarefas orientadas a objetivos, tomam decisões em tempo real e mantêm o contexto necessário para adaptar sua execução dinamicamente. Esses agentes funcionam de forma semelhante ao encadeamento de serviços atual, mas sem depender de fluxos de trabalho pré-configurados. Em vez disso, determinam o fluxo de execução adequado em tempo de execução com base nos objetivos, no estado do ambiente e nos resultados observados.

Essa mudança representa o abandono dos sistemas tradicionais, orquestrados de forma centralizada e com fluxos de trabalho predeterminados, em favor de sistemas descentralizados e dinâmicos, capazes de criar caminhos de execução em tempo real. Ela substitui a previsibilidade das cadeias estáticas de microsserviços por uma tomada de decisão fluida e ágil, orientada por dados em tempo real e pela intenção.

Os sistemas baseados em agentes são definidos pelas seguintes características:

• Execução orientada a objetivos: Os agentes agem com base em prompts ou missões, e não em fluxos de trabalho estáticos. Eles selecionam APIs, modificam parâmetros e alteram rotas conforme estejam ou não alcançando seu objetivo. Exemplo: Um agente encarregado de “resolver uma reclamação de cliente” pode acionar APIs de faturamento, conta e mensagens de maneiras diferentes, dependendo dos resultados anteriores.
• Contexto portátil: Os agentes carregam sua própria memória, estado e política. Por meio do Model Context Protocol (MCP) ou de metadados estruturados, eles incorporam esse contexto a cada solicitação.
• Adaptação em tempo de execução: Em vez de esperar que a infraestrutura tome uma decisão, os agentes se adaptam dinamicamente, fazendo novas tentativas, redirecionando, escalando ou ajustando os fluxos de execução em tempo real.
• Observabilidade integrada: Cada ação é autodescritiva. Os agentes podem informar por que escolheram determinado caminho, o que foi avaliado e se um objetivo foi alcançado. Isso é observabilidade como comportamento, não apenas logs e métricas.

Juntos, esses elementos transformam o cenário das aplicações, que deixa de ser previsível e passa a ser adaptável e estar em constante evolução.

Impacto no gerenciamento tradicional de tráfego

Os sistemas atuais de gerenciamento de tráfego são estruturados em torno de limites bem definidos:

• O plano de controle define a intenção: quais endpoints são válidos, quais caminhos devem ser priorizados e quais políticas se aplicam.
• O plano de dados executa decisões: roteia solicitações, aplica medidas de segurança e balanceia a carga.

Esse modelo tem funcionado bem há décadas, especialmente em arquiteturas orientadas a serviços e ambientes de microsserviços. Ele pressupõe que os fluxos de tráfego possam ser modelados com antecedência e que as cargas de trabalho sigam padrões previsíveis.

Exemplos:

• Um balanceador de carga encaminha /api/login para um pool e /api/images para outro.
• As verificações de integridade marcam os nós como disponíveis ou inativos.
• Limites estáticos determinam as condições de failover.

Esses sistemas dependem de:

• Forte acoplamento de políticas e configurações a recursos estáticos, como pools e membros específicos
• Estruturas estáticas como pools e membros
• Roteamento determinístico com base no caminho, cabeçalho ou protocolo
• Orquestração centralizada para descoberta de serviços, verificações de integridade e lógica de contingência

Mas os sistemas baseados em agentes introduzem fluidez, autonomia e uma lógica autodirigida que rompem com essas premissas.

Em arquiteturas de agentes, a separação tradicional entre o plano de controle e o plano de dados começa a desaparecer. Os agentes não apenas executam solicitações; eles incorporam a lógica que define o que é a solicitação, quais condições devem acionar alternativas, como o sucesso é medido e até mesmo qual deve ser a rota preferencial. Tradicionalmente, essas são questões do plano de controle, mas os agentes as codificam em cabeçalhos, tokens ou metadados que acompanham a própria solicitação pelo plano de dados.

Essa convergência significa que o plano de dados não pode mais atuar como um executor passivo de decisões centralizadas. Ele precisa interpretar ativamente as políticas em tempo real. A solicitação não é mais apenas um pacote; ela é um artefato de política. Como resultado, balanceadores de carga, gateways e camadas de roteamento precisam deixar de ser componentes reativos e passar a interpretar, em tempo real, as intenções transmitidas pelos agentes.

Essa mudança põe em xeque a premissa arquitetural fundamental de que o plano de controle é estático e centralizado. Em vez disso, a lógica de decisão passa a ser distribuída, portátil e personalizada, acompanhando cada solicitação e sendo executada em tempo de execução. Não se trata apenas de uma mudança na implantação, mas de uma mudança em onde e como as decisões são tomadas.

Isso efetivamente conclui o que o Kubernetes começou ao abstrair a infraestrutura subjacente — rede, armazenamento e até mesmo o roteamento de tráfego de camada 4 (L4) —, transformando tudo em mera "infraestrutura básica" por trás de uma interface de controle declarativa. Ele não eliminou essas camadas, mas as relegou a um papel secundário. Elas se tornaram invisíveis, automatizadas e subordinadas a um novo sistema orientado por intenção.

As arquiteturas de agentes fazem a mesma coisa, mas com toda a stack, não apenas com a infraestrutura.

Interrupções críticas no gerenciamento de tráfego

Para contextualizar essas disrupções com um exemplo real, considere um cenário de entrega local de aplicações:

Exemplo: Um site regional de comércio eletrônico usa um ADC para gerenciar o tráfego interno de APIs. Um agente de IA é encarregado de otimizar a velocidade de processamento dos pedidos. Ele identifica que um endpoint específico da API, por exemplo, /api/inventory/check, está apresentando queda de desempenho devido ao aumento da complexidade das solicitações e à contenção no banco de dados de backend. Os algoritmos tradicionais de balanceamento de carga, incluindo o de "resposta mais rápida", não conseguem captar as nuances dessa lentidão, pois calculam o desempenho como uma média geral de todas as respostas de um determinado membro do pool, e não por tarefa ou por chamada.

Para cumprir seu SLA, o agente redireciona essas solicitações de verificação de estoque para um grupo de nós alternativo otimizado para consultas transacionais. Para isso, ele adiciona a cada solicitação um cabeçalho de contexto, como X-Task-Profile: inventory-sensitive. Se estiver configurado corretamente, o balanceador de carga poderá interpretar esse cabeçalho e direcionar o tráfego de acordo. No entanto, como esses nós não foram previamente atribuídos ao pool estático associado a /api/inventory, os serviços de direcionamento de tráfego devem ser capazes de seguir as diretivas transmitidas pelo agente e determinar dinamicamente o roteamento, sem depender de estruturas estáticas.

Esse cenário destaca as limitações de estruturas estáticas, como pools, e a necessidade de uma execução de tráfego sensível ao contexto e programável dinamicamente.

Sistemas baseados em agentes rompem com várias premissas fundamentais da engenharia de tráfego:

Convergência dos planos de controle e de dados: Antes, as decisões de roteamento eram baseadas em regras estáticas; agora, elas vêm da própria solicitação. Isso inviabiliza a lógica tradicional de aplicação de políticas.

Roteamento baseado em intenção: Os agentes roteiam o tráfego com base em objetivos, não apenas em endpoints. Um único endpoint, como /api/process pode processar centenas de fluxos de tarefas diferentes, dependendo das instruções dos agentes.

Pools estáticos tornam-se obsoletos: Os pools tradicionais pressupõem funções fixas. No entanto, os agentes podem precisar de acesso à GPU em um momento e de otimização de CPU no momento seguinte, tornando a associação a pools rígida demais.

Alternativas e failover tornam-se estratégicos: Antes, failover significava “tentar o próximo servidor”. Agora, os agentes avaliam o desempenho em tempo real e os resultados anteriores para decidir estrategicamente como proceder.

Os padrões de tráfego surgem, não se repetem: Os agentes criam fluxos de trabalho sob demanda. Não é possível predefinir todos os caminhos; eles se formam de acordo com as necessidades.

Essas disrupções exigem que balanceadores de carga, gateways e stacks de observabilidade se adaptem a uma lógica de tráfego dinâmica e em tempo real.

Repensando as métricas de integridade e desempenho

As métricas de integridade e desempenho sempre foram fundamentais para o gerenciamento de tráfego. As decisões de balanceamento de carga dependem de saber se um servidor está disponível, com que rapidez ele responde e qual é o seu nível de carga. Porém, em sistemas orientados por agentes, a integridade não é binária, e o desempenho não pode ser calculado pela média de categorias amplas. As métricas devem refletir se um destino é adequado para uma tarefa específica, e não apenas se está ativo.

Por que isso é importante: As métricas de integridade influenciam diretamente o direcionamento do tráfego, as decisões de failover e a otimização do desempenho. Em um ambiente nativo de agentes, cada solicitação tem uma intenção diferente e pode exigir um caminho ou uma garantia de resposta diferente. As abordagens tradicionais não conseguem atender a essa necessidade porque:

• Elas se baseiam em métricas agregadas superficiais (por exemplo, o tempo médio de resposta), que ocultam variações específicas de cada tarefa.
• Eles avaliam a integridade apenas sob a perspectiva do servidor, sem nenhuma visibilidade sobre o sucesso ou a satisfação no nível do agente.
• Eles pressupõem homogeneidade do tráfego, o que não se sustenta quando as solicitações são moldadas por decisões tomadas em tempo de execução.

Exemplo: Um conjunto de servidores de API pode ser considerado totalmente "saudável" pelas verificações de integridade, mas um deles pode falhar sistematicamente em fornecer respostas em menos de 100 ms para consultas com X-Task-Profile: inventory-sensitive. Um agente que espera esse perfil de latência perceberá uma falha, mesmo que a infraestrutura considere tudo normal.

O que é necessário:

• Telemetria em tempo real, por solicitação, que reflita a intenção e os resultados observados.
• Pontuação de integridade específica por tarefa, que identifica quando um nó apresenta degradação em algumas tarefas, mesmo que esteja íntegro para outras.
• Ciclos de feedback que incorporam o sucesso ou a falha relatados pelo agente à lógica de roteamento e priorização.

As ferramentas de rotulagem de dados podem desempenhar um papel fundamental nesse contexto, rotulando o tráfego em movimento e registrando o desempenho e o alinhamento ao contexto. Isso permite que os sistemas avaliem não apenas o que aconteceu, mas também se o objetivo do agente que iniciou a ação foi alcançado.

Fallback, circuit breakers e recursos de repetição de tentativas em arquiteturas de agentes

Em infraestruturas tradicionais, comportamentos de contingência, como novas tentativas, redirecionamento para nós de backup ou acionamento de circuit breakers, são implementados na camada de infraestrutura. Balanceadores de carga, proxies e gateways usam limites predefinidos (por exemplo, tempos limite e taxas de erro) para determinar quando interromper o roteamento do tráfego para um destino e tentar uma alternativa.

As arquiteturas de agentes invertem essa lógica.

Os agentes trazem suas próprias estratégias de contingência. Eles incluem políticas de repetição, lógica de escalonamento e prioridades centradas em objetivos na própria solicitação. Isso introduz complexidade e possíveis conflitos com os mecanismos de failover no nível da infraestrutura.

Por que isso é importante:

• A infraestrutura pode interpretar uma falha como recuperável, enquanto o agente a considera inaceitável (ou vice-versa).
• Tanto o agente quanto a infraestrutura podem tentar acionar mecanismos de contingência simultaneamente, resultando em novas tentativas redundantes, aumento da latência ou loops de tráfego.
• Disjuntores projetados para tráfego em condições médias podem bloquear o acesso a serviços que um agente ainda considera ideais.

Principais riscos:

• Fallback duplicado: Tanto o agente quanto a infraestrutura fazem novas tentativas, gerando carga desnecessária.
• Condições de corrida: O agente recorre a uma opção mais cara ou menos segura, embora o sistema pudesse resolver o problema em questão de milissegundos.
• Falha no failover determinístico: Políticas estáticas não conseguem lidar com as nuances dos agentes.
• Corrupção: Os metadados do agente estão malformados, ausentes ou ilegíveis.

Orientações para adaptação:

• A infraestrutura deve evoluir para reconhecer as prioridades de contingência especificadas pelo agente (por exemplo, por meio de X-Fallback-Order, X-Timeout-Preference).
• Os circuit breakers devem ser capazes de considerar a intenção para oferecer suporte a lógicas específicas por tarefa ou por agente, em vez de usar limites globais.
• Considere introduzir uma lógica de failover sensível à negociação, na qual os agentes propõem estratégias preferenciais e os gateways decidem com base na integridade do sistema, na carga e nas políticas.
• Os sistemas de tráfego devem oferecer suporte à lógica de execução padrão quando os metadados do agente estiverem ausentes, incompletos ou não forem aprovados na validação do esquema, garantindo uma degradação gradual.
• A infraestrutura deve detectar e impedir delegações recursivas ou novas tentativas conflitantes de agentes que possam gerar loops ou aumentar o tráfego durante a degradação do sistema.

Exemplo: Um agente encarregado de realizar uma verificação de fraude em tempo real solicita uma resposta em até 50 ms. Sua lógica de contingência prioriza um resultado parcial armazenado em cache em vez de uma consulta completa e demorada. Uma infraestrutura que não esteja ciente disso ainda pode encaminhar a solicitação ao backend de serviço completo, causando uma latência perceptível para o usuário. Um modelo mais cooperativo respeitaria a prioridade de contingência do agente e forneceria a resposta degradada mais rapidamente.

À medida que a tomada de decisões avança para as camadas superiores da pilha, as estratégias de contingência devem acompanhar essa evolução. Os disjuntores e a lógica de repetição de tentativas não podem permanecer estáticos ou opacos; eles devem se adaptar às preferências expressas pelo agente, preservando ao mesmo tempo a segurança e a equidade do sistema.

Alta disponibilidade e failover continuam sendo importantes

Embora as arquiteturas de agentes transfiram a tomada de decisões e a coordenação para a camada de requisições, a infraestrutura subjacente ainda é responsável por garantir a confiabilidade dos principais componentes do sistema. Isso significa que os mecanismos de alta disponibilidade (HA) e failover na camada de infraestrutura continuam sendo essenciais. Na verdade, eles se tornam ainda mais críticos à medida que os sistemas adotam comportamentos mais dinâmicos e autônomos.

Os agentes podem direcionar o tráfego com base em objetivos e no contexto, mas ainda dependem da rede para garantir que os serviços permaneçam acessíveis e resilientes quando algo dá errado. Os balanceadores de carga devem detectar nós inacessíveis, serviços com falha ou ambientes degradados e redirecionar o tráfego em tempo real, independentemente da estratégia de contingência do agente.

Principais responsabilidades que não mudam:

• Monitore os membros do pool e a integridade dos serviços de backend
• Detectar partições de rede ou falhas de roteamento
• Redirecionar o tráfego com base na integridade, disponibilidade ou degradação no nível do sistema
• Mantenha a alta disponibilidade para serviços com estado ou sessões quando necessário

Os agentes podem conter a lógica para determinar “o que deve acontecer em seguida”, mas o balanceador de carga ainda é responsável por definir “com que rapidez nos recuperamos quando um nó fica inativo”.

É essencial que uma lógica de roteamento adaptativa e ciente dos agentes não comprometa a estabilidade operacional. Uma infraestrutura com boa instrumentação deve manter:

• Failover instantâneo e rebalanceamento de tráfego quando os nós ficam indisponíveis
• Topologias resilientes de alta disponibilidade que protegem agentes e serviços contra falhas em componentes upstream
• Recuperação rápida e automatizada que complementa a lógica de fallback do agente, em vez de entrar em conflito com ela

Em resumo, as arquiteturas orientadas por agentes não eliminam a necessidade de failover — elas aumentam o que está em jogo. Agora, a infraestrutura precisa responder mais rapidamente, com maior sensibilidade ao contexto e sem se tornar um gargalo para o comportamento autônomo.

Implicações para o gerenciamento de tráfego empresarial

A transição para arquiteturas baseadas em agentes introduz uma mudança fundamental na forma como sistemas de gerenciamento de tráfego, como balanceadores de carga e gateways, devem operar. Enquanto os sistemas tradicionais de gerenciamento de tráfego tomavam decisões com base em políticas pré-configuradas — muitas vezes externas à solicitação —, os sistemas orientados por agentes incorporam essas políticas à própria solicitação. Essa é a base do que o Model Context Protocol (MCP) possibilita: a execução, a cada solicitação, de políticas incorporadas.

Chamaremos esse modelo de "política na carga útil". Em vez de sistemas centralizados analisarem todos os casos excepcionais, o agente incorpora a cada solicitação as decisões de política relevantes (como estratégia de contingência, preferência de nó, tolerância a erros ou requisitos de privacidade). A infraestrutura deve então ler, interpretar e agir de acordo com essas instruções de política em tempo real.

Esse novo modelo de execução transforma o papel dos componentes de gerenciamento de tráfego:

• De tomadores de decisão a executores: A infraestrutura não determina mais para onde o tráfego vai; ela executa a decisão transmitida pelo agente.Exemplo: Um balanceador de carga que lê X-Route-Preference: gpu-optimized deve encaminhar o tráfego de acordo com essa preferência, mesmo que esse nó não fizesse parte do pool original.
• Programável em tempo de execução: as iRules e as políticas devem avaliar cabeçalhos como X-Intent, X-Context ou X-Goal. Isso transfere a lógica de caminhos pré-configurados para uma interpretação dinâmica e em tempo real.
• Roteamento sensível ao contexto: ADCs e serviços semelhantes precisam rotear com base em identidade, intenção e contexto, não apenas no host ou no caminho.
• Observabilidade semântica: Os logs devem mostrar não apenas o que aconteceu, mas também o motivo: “O agente redirecionou o tráfego devido à violação do limite de latência” é mais útil do que apenas “direcionado para o Pool B.”

Tecnologias de rotulagem de dados e ferramentas semelhantes podem apoiar essa mudança ao marcar e classificar o contexto das solicitações em tempo real, viabilizando o roteamento semântico e a observabilidade.

Preparando a infraestrutura empresarial para arquiteturas de agentes

Os agentes de IA não operarão de forma isolada. Eles interagirão com sistemas legados, acessarão APIs tradicionais, manipularão a lógica de negócios em bancos de dados corporativos e chamarão funções hospedadas tanto em back-ends monolíticos quanto em microsserviços. Para as empresas, isso significa que não é possível começar do zero — é preciso evoluir.

A realidade: os agentes se comunicarão com tudo

As stacks empresariais são uma combinação de:

• APIs SOAP com décadas de existência ainda usadas na área financeira
• Serviços RESTful por trás de aplicações web
• Filas de mensagens para sistemas assíncronos de inventário
• Microsserviços nativos da nuvem
• APIs SaaS com limites de requisições e autenticação complexa
• LLMs e agentes com ajuste fino

Os agentes precisam aprender a operar em todos esses ambientes. E sua infraestrutura precisa aprender a intermediar essa interação em tempo real, aplicando políticas de acordo com o contexto.

O que as equipes empresariais precisam preparar

1. Exponha os sistemas internos por meio de interfaces orientadas à intenção

Os agentes não querem cinco endpoints; eles querem um único objetivo. Disponibilize funcionalidades de negócio (por exemplo, “consultar o status do pedido”) por meio de camadas de abstração ou composições de APIs que os agentes possam consumir por um único ponto de entrada semântico.

Etapa de preparação: Use gateways de API ou malhas de serviço para consolidar endpoints orientados a tarefas, com contratos claros de entrada e saída.

2. Instrumente para obter contexto, não apenas métricas

O registro de logs tradicional se concentra no método, no caminho e no tempo de resposta. Mas os agentes se importam com:

• Qual era a tarefa
• Qual alternativa foi tentada
• Se o objetivo foi alcançado

Etapa preparatória: Adote ferramentas de observabilidade semântica que classifiquem o tráfego com rótulos como X-Intent, X-Task-Type e X-Agent-Outcome.

3. Ofereça suporte à avaliação em tempo de execução de políticas incorporadas

Os agentes incluem na solicitação instruções de contingência, preferências de tempo limite e requisitos de segurança. A infraestrutura existente descarta esses dados.

Etapa de preparação: Amplie as políticas de tráfego para interpretar e agir com base nos metadados do agente (por exemplo, X-Route-Preference, X-Fallback-Order, X-Data-Class). Comece com iRules ou scripts de tempo de execução semelhantes.

4. Reformule o controle de acesso e a governança

Os agentes são autônomos. Você precisa saber:

• Qual agente está agindo em nome de quem
• Quais ferramentas ele pode acessar
• Quais escopos de dados ele tem permissão para acessar

Etapa de preparação: Integre controles de acesso baseados em identidade e controles de políticas baseados em atributos (ABAC), em vez de depender apenas de listas de permissões de IP ou de RBAC estático.

5. Desacople a lógica de fallback e de novas tentativas

A infraestrutura e os agentes não podem competir entre si para realizar a recuperação. Deixe que um cuide dos objetivos de execução e que o outro aplique as salvaguardas sistêmicas.

Etapa de preparação: Separe claramente o escopo de fallback dos agentes (o que eles controlam) do failover da infraestrutura (o que está sob sua responsabilidade). Defina regras de negociação e condições de substituição.

Conclusão

À medida que a IA evolui de modelos isolados para agentes autônomos, as empresas chegam a um ponto de inflexão estratégico. Esses agentes não operarão em ambientes criados do zero — eles se integrarão a aplicações existentes, acionarão APIs legadas e orientarão decisões em sistemas empresariais críticos. Isso significa que as empresas precisam se preparar desde já para dar suporte a esses agentes, não apenas com novas ferramentas, mas também repensando como sua arquitetura lida com intenção, execução e governança.

Este não é o momento de descartar e substituir tudo. É um momento de convergência, em que os sistemas tradicionais e os comportamentos emergentes dos agentes precisam interoperar com precisão e intencionalidade.

As arquiteturas de agentes estão chegando. As empresas que se prepararem agora não apenas acompanharão essa evolução — elas estarão na liderança.

LORI MACVITTIE

PUBLICADO EM 1º DE JULHO DE 2025