,

O que é (e não é) um AI control plane em 2026 — guia de compra CIO/CISO

Para quem é este guia

CIO, CISO, arquitetura de plataforma, privacidade/DPO e compras de tecnologia que precisam decidir se (e como) comprar um AI control plane / AI gateway enterprise: o ponto de enforcement entre apps, agentes e modelos ou ferramentas.

Este texto é um guia de compra de categoria, não um ranking. Não há bake-off hands-on da iab2b.site aqui, nem preços, nem scores inventados. Exemplos de produtos servem como âncoras verificáveis de capacidade; a adequação ao seu caso exige PoC, revisão contratual e checagem da documentação vigente.

Em uma frase

AI control plane é a camada que governa no caminho do tráfego: aplica política antes da chamada ao modelo ou à tool, autentica o agente (não só o humano), registra evidência e limita orçamento e catálogo de ferramentas. Sem enforcement no path, você tem orquestração ou builder. Não tem control plane.

O que é: enforcement no path

Para o comprador enterprise, “control plane de IA” não é sinônimo de “temos um proxy de LLM”. É um conjunto mínimo de camadas que atuam inline no data path:

1. Gateway / data plane

Intercepta tráfego de LLM, MCP e (quando houver) agent-to-agent. Aplica política antes da chamada upstream. Se o produto só observa depois do fato, é analytics. Não é enforcement.

2. Policy runtime

Rate limit, allow/deny de modelo e tool, sanitização/guardrails, quotas e regras por identidade ou grupo. A pergunta de compra é simples: a política bloqueia no path ou só gera dashboard?

3. Audit / telemetria

Quem chamou, o quê (modelo, tool, rota), tokens/custo/latência internos, decisão de política. Retenção configurável para investigação e conformidade. Bodies de prompt/output: on-prem ou sob opt-in. Default que envia payload completo ao SaaS do vendor sem controle é risco de RFP, não detalhe.

4. Identidade de agente

Autenticação e autorização do agent (ou principal equivalente), distinta de credencial humana compartilhada. Least privilege por sessão e por ferramenta; revogação. API key única no time de inovação não é identidade de agente.

5. Budgets e tool ACL

Tetos de gasto por time/agente/modelo e catálogo de ferramentas visíveis ou executáveis por caller. Em MCP, a pergunta fina é: tool não autorizada fica invisível no discovery ou só falha na execução? Os dois não são equivalentes para o CISO.

Essas cinco camadas formam a definição operacional deste guia. Use-as como régua da metodologia de comparativos v1 (adequação, governança, segurança, auditabilidade, integrações/lock-in, TCO, evidência de produção), adaptadas a gateway/control plane.

O que NÃO é control plane

Confundir categorias queima orçamento e atrasa governança.

Não é control plane (sozinho):

  • Orquestração de workflows e multi-agente (planejar passos, memória, handoffs);
  • UI de builder / low-code de agentes;
  • Marketplace ou catálogo de agentes;
  • Runtime que executa o agente sem enforcement centralizado de política, identidade e auditoria;
  • Só DLP/CASB de Shadow AI na suíte de colaboração (útil e complementar; não roteia nem governa multi-modelo/MCP de agentes custom).

Isso é, em geral, agent platform ou capacidade adjacente: a capacidade de fazer. Control plane é a capacidade de governar o que faz, com evidência. As duas podem coexistir. Comprar uma não compra a outra por osmose.

Critério editorial interno: contraste por capacidade (enforcement vs. execução), nunca por autoridade de vendor de agent platform fraca. Neste guia não citamos produtos de contraste de fontes fracas.

Três âncoras verificáveis (com data)

As datas abaixo vêm de anúncios e docs oficiais. Features específicas mudam: valide no SKU e na versão do PoC.

1) Prisma AIRS AI Gateway (Palo Alto Networks / Portkey)

  • Aquisição Portkey concluída: 29/05/2026 (press release oficial). Narrativa: AI Gateway como control plane para monitorar, orquestrar e governar agentes; integração nativa citada com Prisma AIRS (runtime security), Idira (agent identity) e observability via Chronosphere.
  • GA do Prisma AIRS AI Gateway: a partir de 16/07/2026 (FAQ da página de produto).
  • Capacidades declaradas na página de produto (verificar no PoC): observability (apps/modelos/agentes, usage, tokens, custo); governance (rate limits, spending rules, access controls); universal API (LLMs, MCP servers e tools); operational controls (limits/policy checks em tempo de interação); identity verification (qual agente, o que acessa, quem autorizou); runtime security (bloqueio de prompt attacks, data exposure, outputs inseguros).
  • FAQ oficial reforça: “inline policy enforcement” e “full auditability”; identidade verificada por agente com purpose/owner; permissões por sessão; bridge multi-provider; caching e quotas.

GA vs roadmap (obrigatório no RFP): o GA do gateway (16/07/2026) não autoriza tratar como GA automático tudo que o blog de integração (29/05/2026) descreve na plataforma ampliada (agent registry, semantic routing, Agent Artifact scanning, Red Teaming, Runtime Security integrado). Peça ao fornecedor a matriz GA hoje vs roadmap para Idira, Chronosphere e red teaming/artifact scanning. Roadmap não pontua como evidência de produção.

Lacuna típica a validar: Shadow AI de usuário colando dado em ChatGPT pessoal (fora do path do gateway) depende do restante do stack (Prisma/AIRS, CASB/DLP), não do gateway sozinho.

Fontes: press release Palo Alto (29/05/2026); página de produto AI Gateway; blog de integração (29/05/2026).

2) Kong AI Gateway 2.0

  • GA: anúncio oficial 01/09/2026 (blog Kong).
  • Modelo de entidades (docs): AI Model Provider, AI Model, AI Agent, AI MCP Server, AI Policy, AI Consumer / Consumer Group, AI Vault, AI Auth Strategy (API key / OIDC), certificados mTLS do data plane.
  • Arquitetura (docs): control plane Konnect-managed + data plane self-managed; CP fora do data path por default (payloads LLM/MCP/A2A não vão ao Konnect salvo opt-in); telemetria padrão = usage/cost/latency (bodies só com flags explícitas).
  • Highlights GA verificáveis (blog + docs): MCP Server Bundling + integração com MCP ACL (catálogo de tools por caller; tool não autorizada invisível no discovery); pricing catalog modality-aware (text/audio/image/video + cache); coverage expandida (ex.: Kimi, Microsoft Foundry, Amazon SageMaker); Kong Identity Principals em políticas de AI; AWS SigV4/IAM nativo para Bedrock AgentCore (proxies A2A/MCP). Tráfego first-class: LLM + MCP + A2A no mesmo data plane e nas mesmas políticas.

Lock-in a negociar: docs indicam control plane das entidades AI Konnect-managed (sem CP self-hosted para esse entity model, no estado documentado na data deste guia). Hybrid no data plane é forte; CP só cloud-managed é pergunta Must no RFP.

Lacuna típica: Shadow AI fora do tráfego roteado pelo Kong não é job do gateway.

Fontes: blog GA Kong AI Gateway 2.0 (01/09/2026); docs de entities e architecture.

3) AWS API Gateway MCP proxy (caveat de data)

  • Anúncio oficial: 02/12/2025. Não é novidade da Semana 1/2026. Entra só como âncora de capacidade MCP/tool exposure no ecossistema AWS.
  • O que faz (What’s New): transforma REST APIs existentes em endpoints MCP-compatible via integração com Amazon Bedrock AgentCore Gateway; tradução de protocolo sem mudar o app; dual authentication (identidade do agente inbound + conexão segura outbound à REST API); discovery semântico de tools; disponibilidade nas regiões onde AgentCore está listado.

Para o comprador: peça de tool exposure + auth no mundo AWS. Complementa um control plane multi-modelo/multi-agente. Não é equivalente, sozinho, a um Prisma AIRS AI Gateway ou Kong AI Gateway 2.0 como stack completa de governance.

Fonte: AWS What’s New (02/12/2025).

Matriz rápida: control plane vs peça adjacente

Necessidade O que procurar O que não basta
Bloquear modelo/tool/payload antes do upstream Gateway com policy inline Dashboard de custo pós-fato
Evidência para incidente e auditoria Audit trail (caller, política, modelo/tool) com retenção Screenshot de demo
Least privilege de agentes Identidade de agente / principal + revogação API key do time no CI
MCP seguro ACL no discovery e na execução “Temos conector MCP” sem ACL
Multi-provider Universal API / entity model SDK hardcode por app
Shadow AI (usuário → SaaS consumer) CASB/DLP/Purview (ou equivalente) + política Só gateway de agentes custom
Builder de agentes Agent platform / orquestração Chamar isso de control plane

Oito perguntas de RFP (use sem números inventados)

  1. A política é inline no data path (bloqueia antes do upstream) ou só analytics/pós-fato?
  2. identidade de agente distinta de identidade humana, com least privilege por tool/sessão e revogação?
  3. O audit trail cobre modelo, tool MCP, decisão de política e caller, e os bodies ficam on-prem / sob opt-in?
  4. Como funciona ACL de tools no discovery MCP (invisível vs só bloqueio na execução)?
  5. budgets/quotas por time/agente/modelo, com pricing realista (modalidade, cache)? Exija cotação. Não aceite slide.
  6. Qual o lock-in: control plane self-hostável, hybrid, ou só SaaS do vendor? Há export de políticas/config?
  7. Como o produto sobrepõe ou integra Shadow AI discovery (DLP/CASB/Purview ou equivalente): mesmo stack ou handoff documentado?
  8. Há suporte multi-model/multi-region e caminho de migração a partir de plugins/proxies legados (ex.: plugins Kong → entidades 2.0)?

Mapeie as respostas aos critérios A–G da metodologia v1. Sem evidência (doc, PoC, contrato), não pontue alto em evidência de produção (G).

Nota BR: LGPD, ANPD e por que não esperar o PL 2338

Control plane bem desenhado é artefato de accountability, não substituto de base legal nem de RIPD.

  • Sob LGPD vigente, quando agentes tratam dados pessoais e/ou tomam decisões com efeito sobre titulares, inventário, Art. 20 (revisão de decisões automatizadas), RIPD quando o risco pedir, e logs auditáveis entram no dever de cuidado. Gateway com policy inline + audit + identidade de agente + tool ACL ajuda a demonstrar governança técnica.
  • A ANPD já priorizou IA no Mapa de Temas 2026–2027 (Tema 4) e trabalha parâmetros do Art. 20 via agenda regulatória e insumos (ex.: NT 12/2025, consolidação de contribuições, não norma final). Fiscalização não depende de você esperar um marco futuro.
  • O PL 2338 (calendário legislativo paralelo) não é pré-requisito para começar inventário, RFP de control plane, Art. 20 operacional e Shadow AI. Trate calendário como risco de planejamento político; trate LGPD/ANPD como obrigação presente.

Detalhe de backlog Q4 (inventário, RIPD, canais Art. 20, vendors, Shadow AI) fica para o brief ANPD da série Semana 1. Aqui o ponto de compra é: control plane fortalece evidência; não dispensa privacidade/jurídico.

Como encaixar na arquitetura (sem teatro)

  1. Defina o path obrigatório: o que não passa pelo gateway não é governado por ele.
  2. Separe camadas: agent platform (execução) ≠ control plane (enforcement) ≠ CASB/DLP (Shadow AI de suíte).
  3. PoC com deny real: teste bloqueio de modelo/tool e ACL MCP no discovery, não só happy path.
  4. Exija matriz GA vs roadmap por módulo (identity, observability, red team, A2A).
  5. Negocie bodies e topologia: onde ficam prompts; CP cloud-only vs DP hybrid.
  6. Amarre ao inventário de agentes e ao checklist de go-live (âncoras 01–02 da iab2b.site).

Armadilhas clássicas de compra

  • Renomear orquestrador de agentes como “control plane” no RFP interno;
  • Aceitar policy só em modo monitor na primeira fase “para não atritar” e nunca ligar deny;
  • API key compartilhada como “identidade”;
  • Ignorar MCP ACL no discovery;
  • Pontuar roadmap de red team como se fosse GA do gateway;
  • Achar que gateway resolve Shadow AI de browser/SaaS consumer;
  • Esquecer BSP/canal e CRM quando o caso é atendimento (outra peça da casa);
  • Pedir “compliance LGPD” no slide sem Art. 20/RIPD/logs no dossiê.

FAQ

Preciso de control plane se só uso Copilot da suíte?
Depende do escopo. Copilot de produtividade vive sob identidade e DLP da suíte. Assim que houver agentes custom, multi-modelo, MCP ou tools em sistemas internos, a pergunta de enforcement no path volta. Comprar copiloto não resolve inventário nem Shadow AI de tudo.

Agent platform com “guardrails” já não basta?
Só se os guardrails forem inline, com identidade, audit e ACL de tools no path. Muitos “guardrails” são prompt policy ou filtro pós-resposta sem identidade de agente nem tool ACL. Peça demonstração de deny.

Kong e Prisma AIRS AI Gateway são a mesma categoria?
Ambos se posicionam em AI gateway / control plane com policy e identidade. Diferenças de topologia (ex.: CP Konnect-managed), profundidade de runtime security e ecossistema (cyber vs API gateway) importam no PoC. Este guia não declara vencedor.

Por que a AWS MCP (dez/2025) aparece aqui?
Como âncora de superfície MCP + dual auth no ecossistema AWS, com caveat explícito de data. Não como lançamento da semana nem como control plane completo multi-modelo.

Control plane substitui Purview / CASB?
Não. Purview (e equivalentes) atacam descoberta e vazamento para Shadow AI no ecossistema Microsoft. Gateway governa path de LLM/MCP/agentes. No RFP, peça o handoff entre os dois.

Preciso esperar o PL 2338 para comprar?
Não. LGPD e supervisão ANPD (Tema 4 / Art. 20) já sustentam inventário, RIPD quando cabível e evidência de governança. Calendário do PL é paralelo, não gate de compra.

Quando self-host / hybrid importa?
Quando política de dados exige DP na sua infra, controle de bodies e menor dependência do plano de controle cloud do vendor. Valide o que é self-managed de fato (DP vs CP).

Fontes (verificação editorial)

  1. Palo Alto Networks — press release conclusão aquisição Portkey (29/05/2026)
  2. Palo Alto Networks — página de produto AI Gateway / Prisma AIRS AI Gateway
  3. Palo Alto Networks — blog integração gateway / agentes (29/05/2026)
  4. Kong — blog Kong AI Gateway 2.0 GA (01/09/2026)
  5. Kong — docs AI Gateway entities
  6. Kong — docs AI Gateway architecture
  7. AWS — What’s New: API Gateway MCP proxy support (02/12/2025)
  8. Metodologia de comparativos iab2b.site v1 (05/09/2026)

URLs oficiais e docs podem mudar; confira na data do RFP/PoC.

Disclaimer editorial

Guia informativo da iab2b.site. Não é ranking, endosso, aconselhamento jurídico ou resultado de bake-off hands-on completo. Nomes de produtos e datas de GA/aquisição refletem fontes oficiais na data de atualização deste texto e podem mudar. Preços, cláusulas contratuais, certificações e escopo GA vs roadmap devem ser verificados no SKU cotado e na documentação vigente antes de decisão de compra. Não utiliza Market Guides sob paywall nem métricas de marketing de vendor não checadas.