RFP de Plataforma de IA Empresarial

RFP de Plataforma de IA Empresarial

50 Perguntas para Fazer a Cada Fornecedor em 2026

As avaliações de plataformas de IA empresarial falham de maneiras previsíveis. A demonstração do fornecedor é executada com base em um prompt de teste selecionado. O slide de preços deles usa suposições de 5.000 tokens por chamada que não correspondem à sua carga de trabalho real. O diagrama de arquitetura de segurança que eles mostram é para um modo de implantação sobre o qual você não perguntou. A capacidade de MCP que eles afirmam está disponível “em nossa próxima versão”. Seis semanas depois, você está assinando um contrato para um produto que se encaixa em 70%, e sua equipe de plataforma passa o período do contrato preenchendo os outros 30% com trabalho personalizado.

Uma RFP pontuada muda a dinâmica. Cada fornecedor responde às mesmas perguntas, por escrito, antes de qualquer demonstração. Suas não-respostas (uma pergunta evitada, uma capacidade que “requer nosso parceiro de integração”, uma alegação de conformidade que não resiste a uma pergunta de escopo) vêm à tona no registro escrito, onde não podem ser reformuladas em uma chamada de acompanhamento. O mesmo registro responsabiliza o fornecedor quando a realidade pós-assinatura começa a divergir do discurso pré-assinatura, que é a queixa de aquisição mais comum na renovação do primeiro ano.

Três coisas levam este modelo além do que as estruturas genéricas de aquisição empresarial já cobrem. Governança de MCP, a pilha de protocolos que seus agentes de IA usarão para se comunicar com ferramentas, onde a maioria dos produtos de gateway de IA ainda está adicionando controle de acesso para o qual não foram projetados. Controles de IA Agêntica, a correlação de rastreamento, atribuição de custos e limites de isolamento que transformam uma tarefa de agente de várias etapas em uma unidade depurável, faturável e governável, em vez de uma névoa de chamadas de LLM desconectadas. Conformidade específica de IA, incluindo paridade de campos de log de auditoria entre invocações de LLM e ferramentas, respostas estruturadas de residência de dados que consideram o roteamento do provedor de modelo entre regiões, e os controles arquitetônicos BAA que tornam a aplicação do HIPAA real em vez de burocracia.

Use isto como ponto de partida. Ajuste os pesos ao seu ambiente. Envie o mesmo documento para cada fornecedor em sua lista restrita. A equipe de soluções da TrueFoundry está preparada para responder a todas as 50 perguntas por escrito, com evidências, como parte da avaliação empresarial formal.

Agora, às perguntas em si.

Figura 1. Arquitetura de referência de plano dividido: plano de controle e plano de computação separados por um limite apenas de metadados, com um IdP alimentando a identidade em ambos.

Como Usar Este Modelo de RFP de Forma Eficaz

A ordem das operações importa mais do que as próprias perguntas. A maioria das avaliações falhas pula a primeira etapa: obter respostas escritas para o modelo completo antes que qualquer fornecedor possa fazer uma demonstração. As demonstrações são para verificação de alegações escritas, não para descoberta. Se a primeira comunicação de um recurso por parte de um fornecedor vier de um slide, você entregou a ele o controle da narrativa da avaliação.

Envie o modelo a todos os fornecedores da sua lista restrita simultaneamente, com um prazo de duas semanas para a resposta escrita. Use as respostas para pontuar com base em uma rubrica ponderada. Somente após a pontuação você agenda as demonstrações, e nessas demonstrações o trabalho da sua equipe de plataforma é verificar se o que está por escrito corresponde ao que está em execução. Trate qualquer alegação que surgir na demonstração, mas que não estava na resposta escrita, como uma descoberta a ser investigada, e não como um recurso a ser pontuado positivamente.

Algumas especificidades para executar isso bem:

• Pesos de pontuação sugeridos. Segurança e conformidade em 25 por cento (não negociável na maioria dos ambientes regulamentados). Implantação e infraestrutura em 20 por cento (determina se a plataforma pode ser executada no seu ambiente). Gateway de IA e governança de LLM em 20 por cento. Governança de MCP e IA agentiva em 20 por cento (a capacidade diferenciadora para 2026, e a seção com a qual a maioria dos fornecedores terá dificuldades). Observabilidade e controle de custos em 15 por cento. Ajuste se suas prioridades forem diferentes. Uma equipe vinculada ao FedRAMP provavelmente dará maior peso à segurança; uma equipe de plataforma otimizando FinOps para uma conta anual de LLM de US$ 2 milhões provavelmente dará maior peso aos controles de custos.
• Como lidar com respostas vagas. Exija evidências para cada alegação de conformidade: relatório SOC 2 Tipo II, modelo de BAA HIPAA, resumo recente de teste de penetração. Considere “disponível em uma versão futura” como não disponível, a menos que a data seja contratualmente comprometida. Considere “disponível via integração de terceiros” como não disponível, a menos que a integração seja pré-construída e mantida pelo fornecedor.
• Sinais de alerta em respostas a RFPs. Fique atento a: respostas que apontam para a documentação em vez de responder diretamente. Alegações de “pronto para empresas” sem descrições de controle específicas. Certificações de conformidade mencionadas sem esclarecimento de escopo (o SOC 2 cobre a implantação SaaS multi-tenant, a implantação on-prem, ou ambas?). Perguntas sobre MCP ou governança de agentes respondidas descrevendo a observabilidade de LLM. O último é o indício: se o fornecedor responde à Seção 4 falando sobre a Seção 5, ele não tem um gateway MCP.

Se você já participou de uma revisão de segurança onde o escopo de conformidade do fornecedor cobria apenas a opção SaaS que você não planejava usar, você sabe o custo de pular a etapa da rubrica. Uma RFP pontuada força a revelação desse detalhe antes do contrato.

Seção 1: Segurança e Conformidade (10 Perguntas)

Segurança e conformidade é onde a maioria das avaliações de plataformas de IA desmorona na segunda reunião. Não porque os fornecedores não tenham certificações. A maioria tem SOC 2 Tipo II em algum lugar. O modo de falha é o alinhamento: o escopo da certificação, os controles arquitetônicos que a implementam e o modo de implantação que você realmente está comprando não correspondem. Um SOC 2 cobrindo o portal de marketing do fornecedor não serve para um gateway de IA que processa PHI on-prem. Um BAA que existe em formato de modelo, mas não descreve como o PHI é isolado no plano de dados, é burocracia, não um controle. As perguntas abaixo forçam o alinhamento entre o escopo da certificação e a realidade arquitetônica que impede que as respostas “somos certificados” tenham um peso que não deveriam.

O outro modo de falha que vale a pena mencionar cedo: fornecedores que respondem a perguntas de segurança de forma abstrata porque sua arquitetura concreta é dividida entre dois produtos com diferentes posturas de controle. Sua versão on-premise é limitada em recursos e não é certificada separadamente. Sua versão SaaS possui as certificações, mas não se encaixa no seu ambiente. Identifique isso fazendo a mesma pergunta duas vezes, especificando o modo de implantação em cada vez. Se as respostas forem diferentes, você está diante de dois produtos comercializados como um só.

Pontue esta seção sem piedade.

• A plataforma suporta implantação on-premise ou isolada por VPC onde nenhum dado do cliente, incluindo conteúdo de prompts, respostas de modelos e logs de auditoria, sai da conta de nuvem do cliente? Descreva a arquitetura de implantação, nomeando cada componente que requer conectividade de saída para a infraestrutura do fornecedor (telemetria, licenciamento, busca de atualizações). Explique o que acontece com a funcionalidade da plataforma se a conectividade de saída for interrompida.

O que “isolado por VPC” deve significar arquitetonicamente.

Uma implantação de plano dividido onde o plano de dados (o proxy que lida com prompts, respostas de modelos, embeddings, invocações de ferramentas MCP) é executado inteiramente na VPC do cliente e nunca abre uma conexão de saída para a infraestrutura do fornecedor para cargas úteis de solicitação. O plano de controle (configuração, configurações de RBAC, painéis) pode ser executado na infraestrutura do fornecedor ou na infraestrutura do cliente, dependendo do modo de implantação, mas troca apenas metadados. Logs de auditoria, dados de prompt-resposta e embeddings são armazenados em armazenamento de blob controlado pelo cliente (S3, GCS, Azure Blob), não em bancos de dados gerenciados pelo fornecedor. Se a “implantação VPC” do fornecedor ainda envia prompts para um agregador de logs gerenciado pelo fornecedor, isso é uma implantação SaaS com uma embalagem diferente.

• A plataforma é certificada SOC 2 Tipo II? Forneça o relatório de auditoria mais recente com o escopo dos serviços cobertos claramente identificado. Especifique se a certificação cobre a opção de implantação on-premise ou apenas o produto SaaS. Muitos fornecedores são certificados SOC 2 para um e não para o outro; o relatório mostrará.

Lendo o relatório.

Verifique a seção Descrição do Sistema para a nomeação explícita dos modos de implantação cobertos. Procure por linguagem como “o ambiente SaaS multi-tenant hospedado em [nuvem]” versus “os componentes de gateway e plano de controle implantados pelo cliente”. Se a descrição nomear apenas um, a certificação cobre apenas um. Verifique os Critérios de Serviços de Confiança cobertos. A Segurança é a base, mas Disponibilidade, Confidencialidade e Integridade de Processamento são importantes para cargas de trabalho de IA que lidam com dados regulamentados. Um SOC 2 cobrindo apenas Segurança é apenas metade da história.

• A plataforma suporta implantações compatíveis com HIPAA? Um Acordo de Associado Comercial (BAA) está disponível, e qual documentação de conformidade o fornecedor oferece como parte da avaliação empresarial? Descreva os controles arquitetônicos que impedem a exposição de PHI (limites de isolamento de dados, requisitos de criptografia, tratamento de logs de auditoria), não apenas a existência de um BAA. Um BAA assinado sem controles de aplicação é um passivo. Insista nisso.
• Como são gerenciadas as credenciais de API, chaves de provedores de modelos e tokens de contas de serviço? Elas são armazenadas na infraestrutura do fornecedor, na infraestrutura do cliente ou em um gerenciador de segredos gerenciado pelo cliente, como AWS Secrets Manager, HashiCorp Vault ou Azure Key Vault? Descreva o processo de rotação para credenciais comprometidas e a janela máxima entre a solicitação de rotação e a propagação.

Como é uma boa integração.

A plataforma obtém as chaves do provedor de modelo do Vault ou Secrets Manager do cliente na inicialização do gateway ou sob demanda, usando uma função IAM gerenciada pelo cliente, com referências de chave (não os valores das chaves) armazenadas na configuração da plataforma. A rotação é uma operação do Vault: reescreva a chave no Vault, o gateway obtém o novo valor na próxima leitura ou em um intervalo de atualização configurável. A plataforma nunca persiste chaves de provedor em repouso. Se a resposta do fornecedor for “você carrega as chaves em nossa interface de administração e nós as armazenamos criptografadas”, esse é um modelo de segurança diferente (e mais fraco). As chaves agora estão na infraestrutura do fornecedor, mesmo em uma implantação “VPC”.

• A plataforma produz logs de auditoria estruturados em um formato compatível com SIEMs corporativos (JSON, CEF, Syslog)? Forneça uma entrada de log de exemplo para uma chamada de inferência de LLM com todos os campos rotulados. Forneça um exemplo equivalente para uma invocação de ferramenta MCP. Os dois devem ter paridade na cobertura de campos; se os logs do MCP forem mais esparsos, isso é um sinal de que a governança do MCP é um complemento, e não de primeira classe.

Como a paridade de campos realmente se parece. Uma entrada de log de inferência de LLM razoável contém aproximadamente estes campos:

{
  "event_type": "llm_inference",
  "timestamp": "2026-04-28T14:22:31.482Z",
  "request_id": "req_01H8X2YZ...",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "user": {
    "id": "u_4821",
    "email": "ana@company.com",
    "team": "applied-ml"
  },
  "application": {
    "id": "app_chat_support",
    "env": "prod"
  },
  "model": {
    "provider": "anthropic",
    "id": "claude-sonnet-4-6",
    "version": "20260217"
  },
  "tokens": {
    "input": 1842,
    "output": 619,
    "cached": 1200
  },
  "latency_ms": {
    "ttft": 312,
    "total": 2180
  },
  "cost_usd": 0.01443,
  "policy": {
    "guardrails_evaluated": [
      "pii",
      "content_filter"
    ],
    "decision": "allow"
  },
  "status": "success"
}

O log de invocação da ferramenta MCP deve ter paridade de campos para as dimensões compartilhadas (timestamp, request_id, trace_id, user, application, latency_ms, status, policy decision) além dos campos específicos da ferramenta:

{
  "event_type": "mcp_tool_invocation",
  "timestamp": "2026-04-28T14:22:32.014Z",
  "request_id": "req_01H8X2YZ...",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "user": {
    "id": "u_4821",
    "email": "ana@company.com",
    "team": "applied-ml"
  },
  "application": {
    "id": "app_chat_support",
    "env": "prod"
  },
  "mcp_server": {
    "id": "github-prod",
    "version": "1.4.2"
  },
  "tool": {
    "name": "github.create_issue",
    "schema_version": "v2"
  },
  "parameters_hash": "sha256:7c8b...a31e",
  "response_size_bytes": 412,
  "latency_ms": 528,
  "policy": {
    "rules_evaluated": [
      "repo_allowlist",
      "rate_limit"
    ],
    "decision": "allow"
  },
  "status": "success"
}

Observe o mesmo trace_id em ambos: a chamada LLM e a invocação MCP se correlacionam a uma única solicitação do usuário, o que é a resposta concretizada à pergunta 8 da Seção 4. Faça o hash dos parâmetros em vez de registrá-los em texto puro. O registro completo de parâmetros é um risco de vazamento de dados em ambientes regulamentados. Se o log MCP de exemplo do fornecedor estiver faltando policy.decision, trace_id ou atribuição de usuário, a governança MCP é um relatório post-hoc, não uma aplicação.

Figura 2. Fluxo de dados do log de auditoria: paridade de campos entre eventos de inferência LLM e eventos de invocação de ferramenta MCP, ambos correlacionados por um trace_id.

• Qual é a política de retenção configurável pelo cliente para logs de auditoria? O cliente pode especificar períodos de retenção por tipo de log (eventos de autenticação, inferência de modelo, chamadas MCP, ações de administração)? Onde os logs são armazenados em implantações isoladas por VPC, e o fornecedor tem algum caminho de acesso a eles?
• Descreva como os dados em repouso são criptografados nos armazenamentos de dados da plataforma: bancos de dados de configuração, armazenamentos de logs de auditoria, dados de observabilidade e rastreamento, artefatos de modelo e quaisquer índices vetoriais. Quais chaves de criptografia estão sob controle do cliente? Em modos implantados pelo cliente (auto-hospedados), o cliente pode usar o serviço nativo de gerenciamento de chaves do provedor de nuvem (AWS KMS, Azure Key Vault, GCP KMS) para as chaves de criptografia que protegem os dados da plataforma? A criptografia com chaves gerenciadas pelo fornecedor é o padrão; chaves controladas pelo cliente são o upgrade.

Por que esta pergunta importa mais do que parece.

“Criptografado em repouso” é universal. De quem é a chave que está criptografando é o controle real. Em uma implantação auto-hospedada, chaves controladas pelo cliente são alcançáveis porque os armazenamentos de dados estão na conta do cliente; em uma implantação SaaS, chaves controladas pelo cliente são uma capacidade do lado do fornecedor que precisa ser projetada. Faça a pergunta com o modo de implantação especificado.

• Descreva a postura de avaliação de segurança de terceiros da plataforma. Quais revisões de segurança independentes a plataforma passou nos últimos 12 meses (testes de penetração, auditorias de código, revisões de arquitetura segura), e quais evidências são fornecidas como parte de uma avaliação empresarial? Descobertas abertas ainda não resolvidas após 90 dias merecem uma explicação por escrito do porquê e um cronograma de remediação.
• Descreva o processo de divulgação de vulnerabilidades e gerenciamento de patches, incluindo o SLA para aplicação de patches de segurança críticos em implantações de clientes. Para implantações auto-hospedadas, descreva como os patches chegam ao ambiente do cliente e quem é responsável por aplicá-los.

Níveis de SLA de patch que vale a pena exigir (típicos da indústria para plataformas empresariais):

Para implantações auto-hospedadas, “disponibilidade de patch” significa uma versão marcada que a equipe de plataforma do cliente pode implantar. “Janela de aplicação pelo cliente” é o SLA que o cliente assume internamente. Se o fornecedor propõe uma janela de 30 dias para o cliente aplicar patches para CVEs críticos, é muito tempo para ficar exposto; recuse.

• Onde os dados do cliente são fisicamente armazenados e processados em cada modo de implantação? Liste as opções de residência de dados disponíveis (EUA, UE, específicas de cada país) e descreva os controles que impedem que os dados do cliente sejam processados fora da região escolhida durante failover ou manutenção. Para implantações SaaS, nomeie os subprocessadores envolvidos (provedores de nuvem, fornecedores de observabilidade, ferramentas de suporte) e forneça a lista mais recente de subprocessadores.

Seção 2: Implantação e Infraestrutura (8 Perguntas)

A maioria das aquisições empresariais falha na implantação. A plataforma parece ótima na demonstração SaaS, então a revisão de segurança revela três coisas que a bloqueiam: conectividade de saída para a infraestrutura do fornecedor para telemetria, um banco de dados de configuração hospedado na nuvem do fornecedor e um plano de controle que está fortemente acoplado a uma região de nuvem específica. Quando essas restrições se tornam visíveis, você já negociou o preço do produto errado, e o caminho a seguir é renegociar a partir de uma posição de custo irrecuperável ou aceitar uma implantação que cria dívida de conformidade.

Esta seção revela as restrições de implantação antecipadamente. Os fornecedores que podem responder a isso claramente são aqueles que já implantaram em ambientes como o seu. Os fornecedores que precisam de uma chamada de descoberta para responder à Seção 2 não o fizeram, e você estará fazendo a engenharia de integração na chamada de descoberta pela qual você está pagando a eles.

Observe as respostas com atenção.

• Quais provedores de nuvem e regiões são suportados para implantação? A plataforma pode ser executada em qualquer região AWS, Azure ou GCP, ou existem restrições geográficas? Qual é o suporte para GovCloud, regiões da China e implantações de nuvem soberana?
• A plataforma pode ser executada simultaneamente em vários provedores de nuvem (AWS e Azure, ou AWS e GCP) com um único plano de controle unificado, atribuição de custos unificada e um único fluxo de log de auditoria? "Multi-cloud" às vezes significa "suportamos todas as três nuvens, mas apenas uma por vez". Isso não é o mesmo que uma carga de trabalho abrangendo duas nuvens com uma única interface de operador.
• Qual é a infraestrutura mínima necessária para executar a plataforma em produção? Forneça diagramas de arquitetura de referência para configurações padrão e de alta disponibilidade, incluindo requisitos de computação, banco de dados, rede e armazenamento. Quantifique em vCPU, GB de RAM e volume de armazenamento persistente.

O que uma arquitetura de referência de HA para um gateway de IA isolado por VPC tipicamente inclui:

┌──────────────────────────────────────────────────────┐
│  Customer VPC (one region, two AZs for HA)           │
│                                                       │
│   [ALB / NLB]                                         │
│       │                                               │
│       ├──> Gateway pods (3+ replicas, HPA enabled)    │
│       │      ↕ reads keys from                        │
│       │      [Secrets Manager / Vault]                │
│       │      ↕ writes audit + metrics to              │
│       │      [S3 / GCS / Azure Blob]                  │
│       │      ↕ reads config from                      │
│       │      [Postgres (HA, multi-AZ)]                │
│       │                                               │
│       └──> egress to: model provider APIs,            │
│                       MCP servers (in-VPC or          │
│                       allowlisted external)           │
│                                                       │
│   [Control plane endpoint]  ──> metadata only,        │
│       (vendor or self-hosted)    no payload data      │
└──────────────────────────────────────────────────────────┘

‍

Dimensionamento de ordem de magnitude para ~500 RPS sustentados: 3 a 4 réplicas de gateway com 2 vCPU / 4 GB de RAM cada, Postgres com 4 vCPU / 16 GB de RAM e 100 GB de SSD, armazenamento de blob escalado com retenção (uma retenção de 90 dias a 10 KB/entrada de log e 500 RPS é de aproximadamente 1,2 TB). O fornecedor deve apresentar números como estes por escrito antes da assinatura, e não "depende da carga de trabalho".

Figura 3. Um plano de controle gerenciando planos de computação em AWS, Azure, GCP e Kubernetes on-premise simultaneamente, cada um com seu próprio limite de residência de dados.

• Qual é o SLA de tempo de atividade documentado? É contratual ou aspiracional? Descreva a configuração de alta disponibilidade necessária para atingir o SLA declarado e se o cliente é responsável por essa configuração ou o fornecedor.
• Como as atualizações e upgrades da plataforma são entregues às implantações dos clientes? Os clientes podem controlar o cronograma de upgrade, manter versões específicas para testes e reverter se um lançamento introduzir problemas? Qual é o atraso típico entre um lançamento SaaS e o lançamento on-prem equivalente?
• A plataforma suporta implantações com conectividade de saída restrita ou controlada? Em ambientes onde o tráfego de saída é permitido apenas para destinos específicos (proxy de saída corporativo, apenas endpoints de provedores de modelo), descreva o que a plataforma exige para funcionar e quais recursos se comportam de forma diferente quando a saída é restrita. Seja específico sobre o que não funciona, não apenas o que funciona.
• Qual é a postura documentada de recuperação de desastres? Forneça os números de RTO e RPO para cada modo de implantação (SaaS, auto-hospedado de região única, auto-hospedado de múltiplas regiões). Descreva o processo de failover, se o failover é automático ou iniciado pelo operador, e o limite de perda de dados em cada cenário. Uma plataforma com um RTO de 4 horas parece bom até que sua aplicação fique inoperante por 4 horas.

Metas de DR de ordem de magnitude a serem esperadas de uma plataforma de nível empresarial:

‍

Qualquer coisa pior do que isso para uma configuração de produção multi-região deve vir com uma explicação por escrito. "Não suportamos multi-região" é aceitável de um pequeno fornecedor; "suportamos, mas não nos comprometemos com o RTO" não é.

• Os clientes podem exportar todos os seus dados, incluindo logs de auditoria, pares de prompt-resposta, configuração e dados de observabilidade, em um formato estruturado? Descreva o mecanismo de exportação, os formatos suportados (parquet, JSON, CSV) e quaisquer dados que o cliente não possa extrair da plataforma. O aprisionamento por inacessibilidade de dados é real.

Seção 3: Gateway de IA e Governança de LLM (9 Perguntas)

Toda página de produto de gateway de IA é igual: API unificada, roteamento inteligente, controle de custos, observabilidade. Os detalhes por trás dessas palavras são o que separa um gateway que você pode executar em produção de um proxy simples com um site de marketing. "Roteamento inteligente" pode significar desde um round-robin estático entre dois modelos até uma política de cascata real com tetos de custo, correspondência de capacidade e cadeias de fallback. "Controle de custos" pode significar um painel que mostra a fatura de ontem, ou pode significar orçamentos de tokens rígidos que realmente retornam um 429 para a aplicação quando uma equipe atinge seu limite.

As perguntas nesta seção forçam a obtenção dos detalhes. Rejeite respostas que apenas repetem o material de marketing. O fornecedor que diz "suportamos roteamento inteligente" sem descrever a linguagem das regras, o comportamento em cascata, o tratamento de falhas e a integração orçamentária não tem roteamento. Eles têm um sinalizador de configuração.

Faça-os provar que a arquitetura existe.

• Quais provedores de LLM e versões de modelo a plataforma suporta? Forneça a lista completa. Com que frequência a lista de provedores é atualizada quando novos modelos são lançados? Qual é o atraso típico entre a disponibilidade pública de um novo modelo (GPT-5.5, Claude Opus 4.7, Gemini 3.1 Pro, Llama 4 Maverick) e o suporte na plataforma? Dias, semanas ou "próximo trimestre" são respostas muito diferentes. Pergunte claramente.
• Descreva a capacidade de roteamento inteligente em detalhes. Quais critérios de roteamento são suportados (custo, latência, capacidade, regras personalizadas)? As regras de roteamento podem ser configuradas por equipe, aplicação ou caso de uso sem modificar o código da aplicação? As regras de roteamento podem ser em cascata (tente o Modelo A primeiro, se o custo exceder o limite tente o Modelo B, se o Modelo B falhar tente o Modelo C)?

Como uma regra de roteamento real se parece na configuração:

route: chat-support
match:
  application: app_chat_support
  team: applied-ml
strategy: cascade
cascade:
  - model: claude-sonnet-4-6
    provider: anthropic
    conditions: { max_input_tokens: 1000000 }
  - model: gpt-5.5
    provider: openai
    conditions: { fallback_on: ["rate_limit", "5xx"] }
  - model: claude-haiku-4-5
    provider: anthropic
    conditions: { fallback_on: ["all_above_failed"] }
guardrails: [pii, content_filter]
budget_ref: budget_applied_ml_q2

A aplicação envia uma requisição padrão compatível com OpenAI. O gateway seleciona o provedor com base na regra, segue a cascata em caso de falha, anexa a referência orçamentária para atribuição de custos e aplica guardrails diretamente. Nenhuma alteração no código da aplicação é necessária quando a rota é reconfigurada. Se o “roteamento inteligente” do fornecedor exige alterações no nível da aplicação para cada variante, isso não é roteamento no nível do gateway. É um wrapper.

• Como são aplicados os orçamentos de tokens e os limites de taxa? Eles são aplicados simultaneamente nos níveis de usuário, equipe, aplicação e modelo? Os orçamentos podem ser configurados como flexíveis (alerta) ou rígidos (bloqueio)? Quando um orçamento rígido é excedido, qual resposta a aplicação recebe? Um 429 limpo com metadados de erro estruturados é a resposta correta. Um 500 ou um estrangulamento silencioso não é.
• O gateway retorna respostas de streaming nativas (eventos enviados pelo servidor, respostas em blocos compatíveis com OpenAI) sem armazenar em buffer a resposta completa? Muitos produtos de “gateway” interrompem o streaming silenciosamente porque armazenam em buffer para inspeção. Confirme o streaming com latência em nível de token sob carga, não apenas com uma caixa de seleção de recurso.
• Descreva a arquitetura de guardrail e aplicação de políticas. Os guardrails são aplicados pré-chamada (bloqueio antes que o modelo veja a entrada), em linha (durante a chamada) ou pós-chamada (após a resposta ser gerada)? Os guardrails podem ser apenas de Validação (bloqueio em caso de violação de política) ou de Mutação (reescrever ou redigir)? Guardrails personalizados podem ser desenvolvidos pelo cliente usando um SDK ou modelo documentado, e qual é o limite de suporte?
• A plataforma suporta cache semântico com limites de similaridade configuráveis, com escopo por usuário ou por conta virtual? Acertos de cache devem retornar com custo zero de modelo. Qual é o modelo de embedding usado para pontuação de similaridade, e ele é configurável pelo cliente ou fixo pelo fornecedor?
• Os prompts, modelos de prompt e mensagens de sistema são gerenciados como ativos versionados e governados na plataforma, separados do código da aplicação? As versões de prompt podem ser testadas A/B em produção sem a necessidade de reimplantar as aplicações? Prompt-como-configuração é a diferença entre iterar no comportamento de um modelo em minutos versus em semanas.
• Descreva o suporte da plataforma a MCP na camada do AI Gateway. Especificamente, o gateway invoca chamadas de ferramenta MCP quando a resposta de um agente inclui marcadores de uso de ferramenta, registra a invocação com contexto completo e retorna o resultado da ferramenta para a conversa do modelo, tudo sem que a aplicação implemente o loop de chamada de ferramenta? Este é o subconjunto da governança de MCP mais diretamente ligado ao AI gateway. A Seção 4 aborda especificamente o gateway MCP.
• Como o gateway é testado para throughput de nível de produção? Forneça números de sobrecarga de latência (apenas do gateway, excluindo a latência do modelo) em níveis de throughput sustentados relevantes para escala empresarial: 100 RPS, 500 RPS, 2.000 RPS. “Abaixo de 10ms” é um slogan. Os números P99 sob carga sustentada são o sinal real.

Figura 4. Fluxo da cascata de roteamento: verificação de orçamento, guardrails pré-chamada, tentativa de modelo primário, cadeia de fallback e um caminho de resposta unificado com auditoria, custo e cache.

Seção 4: Gateway MCP e Governança de IA Agente (9 Perguntas)

Esta seção é onde a maioria dos produtos de gateway de IA terá dificuldades, porque a maioria deles foi projetada para a era das chamadas de LLM e antecede o momento em que o MCP começou a aparecer em ambientes empresariais reais. MCP não é “mais observabilidade para chamadas de ferramenta”. É um plano de governança separado: um registro de servidores aprovados, um ponto de aplicação para quais ferramentas cada função pode invocar, logs de auditoria que correspondem aos logs de chamadas de LLM em cobertura de campo, e um motor de políticas que é executado no momento da invocação, em vez de como um relatório post-hoc. Fornecedores que não possuem este plano tentarão responder às perguntas da Seção 4 com descrições de observabilidade de LLM. Fique atento à substituição. Quanto mais direta a resposta, mais real a capacidade.

O padrão a esperar: um fornecedor robusto de gateway de IA descreverá o gateway MCP como uma superfície de produto separada, com seu próprio registro, seu próprio mapeamento RBAC, seu próprio esquema de log de auditoria e sua própria linguagem de política. Um fornecedor mais fraco o descreverá como “observabilidade estendida” sobre sua pilha de observabilidade de LLM existente, o que é um indício de que a governança é escassa. Avalie a Seção 4 especificamente; não a inclua na Seção 3.

Leia cada resposta em busca de linguagem de aplicação direta.

• A plataforma oferece um gateway MCP para governar o acesso a servidores MCP por agentes de IA e ferramentas de desenvolvedor? Esta é uma capacidade de produção hoje ou um item de roadmap? Se for de produção, forneça uma referência de cliente e a data em que a capacidade foi lançada (GA).
• A plataforma pode manter um catálogo centralizado de servidores MCP aprovados com um fluxo de trabalho de verificação e aprovação? Quem controla as entradas do catálogo, qual é o processo de revisão para adicionar um novo servidor MCP, e o catálogo pode ser distribuído para configurações de IDE de desenvolvedor (Cursor, Claude Code, Continue, outros) automaticamente, em vez de cada desenvolvedor configurar suas próprias conexões?
• Como os servidores MCP são distribuídos para ambientes de desenvolvedor? A distribuição é automatizada através do catálogo, ou cada desenvolvedor configura as conexões manualmente? A configuração manual cria o mesmo problema de shadow-tooling que impulsionou a iniciativa original de SSO há cinco anos. A centralização é importante.
• A plataforma impõe SSO e RBAC para acesso a servidores MCP, separadamente das políticas de acesso a LLM? As políticas de acesso em nível de ferramenta podem ser configuradas em nível de equipe e função? Elas são aplicadas no momento da invocação (o gateway bloqueia a chamada), ou apenas registradas post-hoc (a chamada é realizada e aparece em um relatório amanhã)?
• As invocações de ferramentas MCP são registradas com a identidade do chamador (usuário ou agente), nome da ferramenta, parâmetros passados, resposta recebida e decisão da política? Esses logs são estruturados e consultáveis? Eles são produzidos com a mesma cobertura de campo que os logs de chamadas de inferência de LLM? A paridade é importante: se você pode responder “quem chamou este LLM”, mas não “quem invocou esta ferramenta”, sua história de auditoria tem uma lacuna. Vale a pena sinalizar isso cedo.
• A plataforma pode bloquear chamadas de ferramentas MCP específicas com base em regras de política no momento da invocação, antes que a chamada da ferramenta chegue ao servidor MCP? Descreva a linguagem das regras de política. As políticas podem ser atualizadas sem reimplantar o próprio servidor MCP? O caminho de atualização da política determina a rapidez com que você pode responder a uma ameaça emergente.

Exemplo de regra de política que bloqueia uma chamada de ferramenta antes que ela chegue ao servidor MCP:

policy: github-write-restriction
applies_to:
  mcp_server: github-prod
  tool_pattern: "github.*"
rules:
  - match:
      tool: github.delete_repo
    action: deny
    reason: "Destructive operations require change-management ticket"
  - match:
      tool: github.create_pr
      user.team: ["junior-engineers"]
      parameters.target_branch: "main"
    action: deny
    reason: "Direct-to-main PRs require senior-engineer approval"
  - match: {tool: "github.*"}
    action: allow
    log_level: full

As atualizações para esta regra devem se propagar para o gateway em segundos (push de configuração, não redeploy). Se a resposta do fornecedor for "as políticas são avaliadas pelo próprio servidor MCP", isso não é uma política imposta pelo gateway. É uma política imposta pelo servidor, e você precisará manter a paridade de políticas em todos os servidores MCP no catálogo. Outro problema.

• Como a plataforma protege contra a contaminação da descrição da ferramenta MCP, onde uma descrição maliciosa do servidor MCP incorpora instruções destinadas a redirecionar o comportamento do agente? Quais etapas de revisão ou validação ocorrem antes que um novo servidor MCP seja aprovado para o catálogo, e as descrições das ferramentas são imutáveis uma vez aprovadas ou são buscadas novamente a cada invocação?
• A plataforma pode rastrear uma única solicitação de usuário através de múltiplas chamadas LLM, invocações de ferramentas MCP e chamadas de sub-agentes em uma transação correlacionada? Descreva o mecanismo de propagação do identificador de rastreamento (contexto de rastreamento W3C, cabeçalhos personalizados) e as ferramentas de observabilidade onde o rastreamento correlacionado aparece. Sem rastreamento correlacionado, depurar uma falha de agente de várias etapas é ler linhas de log isoladas e adivinhar a ordem.

Como a propagação do contexto de rastreamento W3C funciona de ponta a ponta. O aplicativo recebe uma solicitação de entrada e gera ou encaminha um cabeçalho traceparent de acordo com a especificação W3C:

traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
                └─ trace-id (32 hex)             └─ span-id (16 hex)

O gateway preserva o trace-id em cada chamada downstream (provedor LLM, servidor MCP, salto secundário do gateway) injetando-o nos cabeçalhos de saída e emite cada chamada como um span sob o mesmo trace-id. No Datadog, Grafana Tempo ou Jaeger, o resultado é uma cascata única mostrando: solicitação do usuário → chamada LLM (claude-sonnet-4-6, 2.1s) → chamada de ferramenta (github.create_issue, 528ms) → chamada LLM (formatador de saída, 380ms) → resposta. Sem isso, o mesmo fluxo aparece como quatro entradas não relacionadas e a análise da causa raiz se torna um palpite.

• Como a comunicação entre agentes é governada quando um agente invoca as ferramentas MCP de outro ou compartilha contexto com outro agente? Existem limites de isolamento que impedem a escalada de privilégios entre agentes? Um agente com acesso a uma ferramenta somente leitura que delega a um agente com acesso de gravação é a versão de IA do "delegado confuso", e a mitigação precisa ser arquitetural, não consultiva. Fácil de ignorar. Difícil de implementar posteriormente.

Figura 5. Arquitetura do Gateway MCP: um único endpoint para ferramentas e agentes de desenvolvedor, com camadas de autenticação, registro, política e log entre clientes e servidores MCP.

‍

Seção 5: Observabilidade e Controle de Custos (7 Perguntas)

A diferença entre uma plataforma de IA que monitora bem e uma que observa bem se manifesta nas perguntas que sua equipe financeira faz no final do mês. O monitoramento informa que a fatura aumentou 40 por cento. A observabilidade informa que o chatbot da equipe de marketing começou a entrar em loop devido a um caso de borda na janela de contexto três semanas atrás, que 70 por cento do aumento é de uma única aplicação, e que as solicitações descontroladas têm uma assinatura específica que você pode direcionar para um modelo mais barato. A primeira resposta deixa o financeiro irritado. A segunda resposta torna o financeiro um aliado.

A mesma distinção aparece na depuração de agentes. O monitoramento informa que uma tarefa de agente falhou. A observabilidade informa qual chamada LLM retornou uma resposta malformada, qual invocação de ferramenta downstream expirou como resultado e a qual solicitação de usuário a falha estava associada. Sem rastreamento correlacionado entre os planos LLM e MCP (Seção 4, pergunta 8), cada falha de agente é um exercício forense. As perguntas abaixo forçam o fornecedor a descrever o que é realmente capturado por chamada, como pode ser consultado e como os dados saem da plataforma quando seu sistema financeiro precisa deles.

Os detalhes importam aqui.

• Quais dados de observabilidade são capturados para cada chamada LLM? Forneça a lista completa de campos registrados, incluindo: modelo, provedor, contagem de tokens (entrada, saída, em cache), custo, latência (tempo para o primeiro token, total), atribuição de equipe e aplicação, identificador de solicitação e quaisquer metadados personalizados que o cliente possa anexar. Campos ausentes aqui são lacunas na sua capacidade forense.
• A plataforma oferece dashboards de custo em tempo real detalhados por equipe, aplicação, modelo e período? Esses dashboards podem ser compartilhados com líderes de equipe sem conceder-lhes acesso à interface completa de gerenciamento da plataforma? Dashboards somente leitura são uma permissão RBAC diferente do acesso de administrador; ambos devem ser possíveis.
• Alertas de custo e orçamento podem ser configurados em múltiplos limites (70 por cento do orçamento aciona um aviso, 100 por cento aciona um bloqueio, 120 por cento aciona uma escalada)? Quem recebe os alertas e por quais canais (e-mail, Slack, PagerDuty, webhook)? Alertas que vão para uma única caixa de entrada são frágeis; o roteamento multicanal é a diferença entre "nós pegamos" e "nós perdemos". Grande diferença às 3 da manhã.
• Como os custos de execução do agente são rastreados quando uma única solicitação de usuário gera múltiplas chamadas LLM, invocações de ferramentas e chamadas de sub-agentes? A plataforma pode atribuir o custo total de uma tarefa de agente de várias etapas a uma única solicitação inicial e a um único usuário? Sem isso, a atribuição de custos do agente é insolúvel e você fica com totais em nível de modelo que não se traduzem em nada acionável.

O que a atribuição agregada deve produzir. Para uma única tarefa de agente iniciada por um usuário, a plataforma deve produzir um resumo consultável, indexado pelo trace_id do contexto de rastreamento W3C discutido na Seção 4:

agent_task: trace_id 4bf92f35...
  user: ana@company.com (team: applied-ml)
  initiating_request: app_chat_support, 2026-04-28 14:22:31
  duration: 4.8s
  components:
    - llm: claude-sonnet-4-6    | tokens 1842 in / 619 out  | $0.0144
    - tool: github.create_issue | latency 528ms             | n/a
    - llm: claude-haiku-4-5     | tokens 412 in / 87 out    | $0.0011
  total_cost_usd: $0.0155
  total_tokens: 2960

Isso é o que torna a "atribuição de custos do agente" um sinal de nível financeiro, em vez de uma curiosidade técnica.

Figura 6. Vista em cascata de rastreamento de uma única tarefa de agente: chamada LLM, chamada de ferramenta MCP e segunda chamada LLM, todas sob um único trace_id com o custo agregado em todos os spans.

• A plataforma suporta a exportação de dados de uso e custo para sistemas externos de BI ou finanças para alocação de custos e processamento de chargeback? Quais formatos de exportação e mecanismos de integração estão disponíveis (entrega via S3, sincronização com BigQuery, API REST, CSV agendado)? Com que frequência a exportação é atualizada?
• Quais integrações de alerta são suportadas e com que nível de fidelidade? Os alertas são entregues por e-mail, Slack ou destinos de webhook, e o roteamento de webhook pode direcionar diferentes tipos de alerta para diferentes sistemas downstream (alertas de custo para finanças, alertas de segurança para operações de segurança, alertas de latência para o engenheiro de plantão)? Webhook é a válvula de escape universal; se a plataforma suporta webhook com formato de payload personalizado, ela se integra a qualquer backend de alerta que o cliente já utilize.
• Por quanto tempo os dados de observabilidade e auditoria são retidos por padrão, e a retenção é configurável por tipo de dado? O que acontece ao expirar o período de retenção: exclusão automática, arquivamento em armazenamento frio ou escolha do cliente? Descreva os controles de retenção em implantações isoladas (air-gapped) onde o cliente gerencia sua própria infraestrutura de logs de ponta a ponta.

Seção 6: Integrações Empresariais, SLAs e Suporte (7 Perguntas)

O custo de uma lacuna de integração raramente é visível na aquisição. Ele se manifesta seis meses depois, quando o acesso de um funcionário desligado leva 48 horas para ser revogado porque o SCIM não é real, quando uma interrupção P1 às 2h da manhã recebe uma resposta automática “responderemos durante o horário comercial” porque o SLA é aspiracional, quando uma renomeação de grupo no Okta quebra as atribuições de função porque a integração SSO da plataforma nunca foi testada com eventos de ciclo de vida de grupo. Cada um desses é um custo de engenharia finito, mas eles se acumulam no imposto operacional que faz com que as equipes de plataforma migrem silenciosamente de produtos, de outra forma capazes, na renovação do terceiro ano.

A Seção 6 revela as realidades operacionais. Dois padrões de diagnóstico: qualquer resposta “sim” a uma pergunta de suporte a protocolo merece um acompanhamento sobre quais clientes utilizam esse protocolo em produção hoje versus quais clientes serão os primeiros a experimentá-lo. E qualquer compromisso de SLA sem créditos explícitos anexados deve ser tratado como uma meta de marketing. SLAs contratuais vêm com créditos porque os fornecedores precificam o risco de não cumpri-los; SLAs aspiracionais são escritos pelo marketing e não vêm.

Obtenha os créditos por escrito.

• Quais provedores de identidade são suportados para SSO empresarial? Liste explicitamente: Okta, Azure AD (Entra ID), PingFederate, ADFS, Google Workspace, SAML 2.0 genérico, OIDC genérico. A integração SSO está disponível em todos os modos de implantação (SaaS e on-premise) ou apenas em níveis específicos? Pergunta bônus: quais dessas integrações possuem implantações em produção validadas por clientes versus “nós suportamos o protocolo, você será o primeiro a experimentá-lo.”

Mapeamento de atributos SAML padrão que a plataforma deve aceitar. Provedores de identidade enviam nomes de atributos específicos do fornecedor (o ADFS, em particular, emite claims longos no estilo URI), portanto, a plataforma deve permitir que você os mapeie para um pequeno conjunto padrão:

‍

Se a plataforma só pode consumir um formato de claim fixo, a integração com qualquer coisa que não seja Okta/Azure AD torna-se dolorosa. A flexibilidade acima é um custo de configuração único; sem ela, cada integração de IdP torna-se um engajamento personalizado.

• A plataforma suporta SCIM 2.0 para provisionamento e desprovisionamento automatizado de usuários e grupos? Quando um usuário é removido do provedor de identidade, seu acesso à plataforma é automaticamente revogado, ou isso requer uma etapa manual de desprovisionamento? O desprovisionamento manual é uma não conformidade esperando para acontecer. Sempre aparece na auditoria.

Como o provisionamento SCIM se parece na rede. Okta ou Azure AD envia POSTs para o endpoint SCIM da plataforma quando um usuário é adicionado ao aplicativo SSO:

POST /scim/v2/Users
Authorization: Bearer <scim-token>
Content-Type: application/scim+json
 
{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "userName": "ana@company.com",
  "name": {"givenName": "Ana", "familyName": "Ruiz"},
  "emails": [{"value": "ana@company.com", "primary": true}],
  "groups": [{"value": "applied-ml"}, {"value": "ai-platform-developer"}],
  "active": true
}

Quando o usuário é desprovisionado no IdP, o mesmo endpoint recebe um PATCH que altera 'active' para 'false', e a plataforma deve revogar o acesso do usuário prontamente, em vez de apenas na próxima tentativa de login. Teste isso na prova de conceito: desprovisione um usuário de teste no IdP, então tente usar um token de plataforma ainda válido e confirme que o ciclo de vida de desprovisionamento funciona de ponta a ponta. Se a plataforma só honra o desprovisionamento no próximo login do usuário, isso é uma lacuna de conformidade que vale a pena registrar por escrito.

Figura 7. Fluxo de Identidade e RBAC: IdP alimenta a identidade, a plataforma mapeia grupos para equipes e Contas Virtuais, com aplicação no AI Gateway, MCP Gateway, painel e Agent Gateway.

• Qual é o SLA de suporte empresarial? Forneça os compromissos de tempo de resposta por nível de gravidade: P1 (interrupção de produção), P2 (degradação significativa), P3 (problema não crítico), P4 (solicitação de informação). São compromissos contratuais com créditos anexados, ou metas aspiracionais em um documento de marketing?

Níveis de SLA empresarial que valem a pena assinar, como linha de base:

Cuidado com “tempo de resposta” definido como “um e-mail automático dizendo que recebemos seu ticket.” Isso não é resposta. Resposta real é um engenheiro se envolvendo na questão. E a cláusula de crédito é o teste: SLAs contratuais vêm com créditos, SLAs de marketing não.

• Qual é o modelo de integração (onboarding) e suporte contínuo empresarial? Descreva o processo de implantação assistida, a documentação e os playbooks fornecidos para a configuração do plano de controle e do plano de computação, o modelo de engajamento contínuo com a equipe de soluções do fornecedor (caminho de escalonamento, notificações de gerenciamento de mudanças, revisões regulares), e quais elementos estão incluídos nas taxas de licença versus escopo como engajamentos separados. Lacunas na integração se manifestam como atrasos no tempo de produção. Pergunte antes de assinar.
• Quão extensível é a plataforma? Os clientes podem contribuir com guardrails personalizados, regras de roteamento personalizadas ou integrações personalizadas de servidor MCP sem depender do roadmap do fornecedor? Descreva o mecanismo de extensão (SDK, template FastAPI, modelo de plugin) e o limite de suporte entre extensões fornecidas pelo fornecedor e construídas pelo cliente.
• Descreva o processo contratual de exclusão de dados quando um cliente rescinde o contrato. Qual é o SLA para exclusão de dados e um certificado de exclusão é fornecido? Para implantações on-premise, descreva a revogação da chave de licença e o processo de desativação do software. A rescisão inverte a posição de negociação. Entenda o processo antes de assinar.
• Quais serviços profissionais são oferecidos como parte da integração empresarial? Descreva o escopo do envolvimento da equipe de plataforma na implantação inicial, integração com sistemas de identidade e observabilidade existentes, desenvolvimento de integração personalizada e suporte operacional contínuo. Especifique se estes estão incluídos nas taxas de licença, definidos como projetos separados ou disponíveis apenas em níveis premium. Custos de serviços ocultos são uma reclamação recorrente na renovação do primeiro ano.

Como a TrueFoundry Resolve a Avaliação de RFP

A equipe de soluções da TrueFoundry trata esta RFP como a avaliação formal, não como um artefato de vendas. Cada pergunta recebe uma resposta por escrito com evidências: relatórios SOC 2 Tipo II, documentação BAA para implantações na área da saúde, resumos de testes de penetração, arquiteturas de referência, logs de auditoria de exemplo, referências de clientes. O resultado é um documento que suas equipes de segurança, compras e plataforma usam para tomar uma decisão sem a necessidade de uma chamada de descoberta para preencher as lacunas.

A arquitetura subjacente às respostas mapeia diretamente para a estrutura de seções deste modelo, razão pela qual a maioria das perguntas é resolvida de forma clara. Analisando:

O modelo de implantação é de plano dividido. O plano de controle é o cérebro da orquestração, hospedando configuração, RBAC e painéis. Os planos de computação se conectam de volta através de um agente e hospedam as cargas de trabalho reais, incluindo o Gateway de IA, o Gateway MCP e quaisquer aplicações implantadas ou modelos auto-hospedados. Os planos de computação podem ser executados em contas de nuvem do cliente (AWS, GCP, Azure) ou em Kubernetes on-premise, e múltiplos planos de computação se conectam a um plano de controle para permitir operações multiambiente sob uma única superfície de controle. O Gateway de IA pode ser auto-hospedado dentro da infraestrutura do cliente (as opções de implantação são documentadas separadamente) para controles de residência e soberania de dados. Logs de auditoria e dados de rastreamento são armazenados usando projetos de log de requisições e rastreamento do Gateway, com RBAC governando o acesso a rastreamentos e logs. A arquitetura de plano dividido é o que torna a mesma postura de residência de dados disponível em implantações SaaS, single-cloud, multi-cloud e auto-hospedadas, em vez de tratar cada uma como um produto separado com posturas de controle separadas.

Soberania de dados é a arquitetura, não uma linha de marketing.

A autenticação usa SSO empresarial via OIDC ou SAML 2.0 com validação opcional de token IdP diretamente no Gateway de IA para controle de acesso à API. IdPs comuns (Microsoft Entra ID, Okta, Keycloak, Google) são suportados, com reivindicações de identidade e associações de grupo mapeadas do IdP para as equipes TrueFoundry para impulsionar o RBAC em escala. O provisionamento SCIM é suportado em todas as configurações de SSO — tanto OIDC quanto SAML — de modo que o desprovisionamento no IdP se propaga em vez de esperar pelo próximo login do usuário. O RBAC opera no nível do Tenant (funções de Admin/Membro) mais funções personalizadas com permissões delimitadas para usuários, equipes, clusters, workspaces, implantações, contas de provedor do Gateway de IA, servidores MCP e projetos de rastreamento. Identidades não-humanas (aplicações, agentes) recebem Contas Virtuais com tokens estilo conta de serviço, e a autorização por requisição nos limites do Gateway de IA (modelos, agentes, servidores e ferramentas MCP) suporta padrões de menor privilégio. Chaves de provedor se integram com armazenamentos de segredos gerenciados pelo cliente; a autenticação do gateway é sobreposta ao IdP em vez de substituí-lo, de modo que MFA e acesso condicional permanecem impostos pelo IdP do cliente.

O gateway de IA roteia mais de 1.000 LLMs através de um único endpoint compatível com OpenAI: OpenAI, Anthropic (direto e via AWS Bedrock), Azure OpenAI, GCP Vertex AI, Groq, Mistral e modelos auto-hospedados servidos via vLLM, TGI ou Triton. O roteamento é configurado através de Modelos Virtuais, que expõem uma interface de modelo e fazem balanceamento de carga ou failover entre múltiplos provedores e modelos subjacentes. O TrueFailover adiciona roteamento consciente de interrupções e degradações, com resiliência multi-região e multi-nuvem integrada. Limites rígidos de token e requisições por usuário, equipe ou Conta Virtual retornam uma rejeição estruturada quando uma equipe atinge seu orçamento, em vez de um alerta suave com a requisição ainda sendo processada. O fallback do provedor é automático e a penalidade de latência é capturada como uma métrica separada na chamada, em vez de estar oculta na latência total. O cache semântico usa embeddings e similaridade de cosseno com limite e TTL configuráveis; a documentação cita uma melhoria de latência de até ~20x para consultas repetidas ou semelhantes. Guardrails são baseados em regras (alvo por modelo, usuário ou metadados), cada um pode Validar (bloquear) ou Mutar (reescrever/redigir), e o Bring-Your-Own Guardrail é suportado através de um servidor de guardrail personalizado usando um modelo FastAPI.

O roteamento aqui é o produto, não uma flag de configuração.

A pilha MCP e de agentes é o diferencial. A TrueFoundry executa um Gateway MCP nativo e um Registro MCP que registram, descobrem e conectam com segurança servidores e ferramentas MCP centralmente através de controles de acesso governados e fluxos de autenticação empresariais. Transportes MCP modernos, incluindo HTTP streamable para conexões proxy, são suportados, e a camada de protocolo usa mensagens JSON-RPC padrão conforme a especificação MCP. A autenticação é em camadas: autenticação de gateway, controle de acesso a servidores MCP e autenticação por servidor ou por ferramenta (incluindo padrões baseados em OAuth documentados para servidores MCP empresariais). A configuração centralizada significa que as ferramentas de desenvolvedor se comunicam com um único endpoint de gateway, em vez de cada desenvolvedor configurar suas próprias conexões MCP, que é o padrão de "shadow-tooling" que o registro foi projetado para prevenir. O Agent Hub fornece catalogação organizacional e orquestração para agentes complexos e agentes pré-existentes, e o Agent Gateway fornece a camada de governança empresarial (acesso seguro a ferramentas, observabilidade, controles de custo) para executar esses agentes em produção. A mesma identidade que governa o acesso a LLMs governa o acesso a ferramentas, então a autorização para ambos reside em uma única configuração de IdP. E o mesmo contexto de rastreamento que une uma tarefa de agente LLM de várias etapas une as invocações MCP sob ela, o que torna a consolidação de custos por tarefa e a depuração de ponta a ponta tratáveis em vez de teóricas.

A observabilidade usa o registro de requisições do Gateway com rastreamentos. Contagens de tokens, custos, latência (TTFT e total), decisões de guardrail, decisões de política e atribuição de equipe e aplicação são capturados por chamada, armazenados como rastreamentos e acessíveis através de projetos de rastreamento com seu próprio RBAC. A exportação de telemetria é baseada em padrões: exportação de dados OpenTelemetry mais exportação de logs e rastreamentos para sistemas externos, incluindo Grafana, Datadog e Prometheus, para que os clientes se integrem com pilhas de observabilidade existentes em vez de aprender uma proprietária. Painéis de custo são em tempo real e compartilháveis com líderes de equipe através de RBAC somente leitura. O mesmo armazenamento de logs/rastreamentos é o que cria o conjunto de dados auditável de tentativas de injeção de prompt, acertos de política e padrões de abuso que os clientes podem explorar para ajustar os guardrails ao longo do tempo.

Sua pilha de observabilidade existente permanece sua pilha de observabilidade existente.

A evidência de throughput por trás de tudo isso: 10 bilhões de requisições por mês processadas em toda a base de clientes, mais de 1.000 clusters Kubernetes gerenciados pela plataforma, sobrecarga do lado do gateway abaixo de 10ms p95 (TTFT) e mais de 350 RPS sustentados em uma única vCPU. Clientes em produção incluem Resmed, Siemens Healthineers, Automation Anywhere, Zscaler e Nvidia. A Série A foi liderada pela Intel Capital em fevereiro de 2025, elevando o financiamento total para aproximadamente US$ 21 milhões com a participação de Peak XV Partners (Surge), Eniac Ventures e Jump Capital.

Escala de produção, não escala piloto.

Figura 8. Arquitetura de referência ponta a ponta da TrueFoundry: plano de controle, plano de computação (com Gateway de IA, Gateway MCP, Gateway de Agente e Aplicativos do Cliente), IdP do cliente e alvos de observabilidade.