Uma revisão do escopo do gateway de API de IA SOC 2 não deve começar pelo selo. Deve começar com uma pergunta simples: qual sistema, período, controles, dependências e responsabilidades assumidas pelo comprador o relatório realmente cobriu?
Essa distinção importa para o roteamento de modelos. Um gateway de API de IA pode ficar entre sua aplicação e vários provedores de modelos, famílias de endpoints, logs, fluxos de suporte, registros de faturamento e caminhos de fallback. Um relatório SOC 2 Type 2 pode ser uma evidência útil para o sistema descrito pelo fornecedor do gateway e para os critérios de serviços de confiança cobertos. Não deve ser tratado como prova de que todo provedor de modelo upstream, toda rota, toda configuração de retenção de prompts, toda configuração de conta do comprador ou toda mudança futura de modelo está aprovada.
Use esta lista de verificação do escopo do gateway de API de IA SOC 2 quando compras, segurança, jurídico e engenharia de plataforma precisarem decidir o que o relatório deve comprovar, o que ele não deve comprovar e que evidências complementares devem constar no pacote de aprovação.
A Flatkey é relevante para esta revisão porque o site público atual posiciona flatkey.ai como um gateway de API de IA e plataforma de operações de modelos para rotear tráfego oficial de GPT, Claude, Gemini e outros modelos por meio de uma única chave, com painéis de controle, faturamento, roteamento, uso e superfícies de evidência operacional. As páginas públicas da Flatkey e as páginas de consulta de certificado são apenas evidências de triagem datadas. Para aprovação em produção, solicite o relatório SOC 2 privado, o contrato/DPA assinado quando aplicável, as configurações da conta, a configuração da rota e a confirmação do suporte para a carga de trabalho que você executará.
Para um contexto mais amplo de compras, combine este artigo com a lista de verificação de evidências do gateway de API de IA SOC 2, o pacote de evidências de compras para gateway de IA e a avaliação de risco de fornecedores de API de IA.
Escopo do Gateway de API de IA SOC 2: Tabela Rápida de Decisão
A primeira página da revisão deve separar as evidências do relatório das evidências complementares do comprador.
| Área de revisão | O que o relatório SOC 2 deve ajudar a comprovar | O que ele não deve comprovar por si só |
|---|---|---|
| Entidade jurídica | Qual organização de serviços foi examinada | Que toda afiliada, revendedora ou provedor de modelo upstream está coberto |
| Limite do sistema | Quais plataforma, serviços, locais, infraestrutura, pessoas e processos estão no sistema descrito | Que todos os recursos do painel, famílias de endpoints, rotas do cliente ou integrações futuras estão no escopo |
| Período do relatório | O período coberto pela avaliação Type 2 | Que os controles atuais permanecem inalterados após o fim do período |
| Categorias de serviços de confiança | Quais critérios foram cobertos, como segurança, disponibilidade, confidencialidade, integridade de processamento ou privacidade | Que categorias não selecionadas foram examinadas |
| Controles testados | Quais controles o auditor testou e os resultados no período | Que a configuração do comprador, a política de rota ou a classe de dados da carga de trabalho foram testadas |
| Exceções | Se foram registradas exceções de controle e como a administração respondeu | Que as exceções são imateriais para sua carga de trabalho específica |
| Organizações subserviços | Se dependências importantes estão incluídas, excluídas ou tratadas por outros relatórios | Que a retenção, o treinamento, o registro ou o comportamento regional do provedor de modelo upstream estão cobertos |
| CUECs | Quais controles complementares da entidade usuária o comprador deve operar | Que o fornecedor é responsável pelo armazenamento de chaves do comprador, redação, listas de permissão de provedores ou classificação de dados no nível do aplicativo |
Esta é a regra central do escopo do gateway de API de IA SOC 2: o relatório é uma evidência sobre um sistema de organização de serviços descrito durante um período definido. Não é uma aprovação geral para toda rota de IA que sua equipe possa criar.
Trave os cinco campos de escopo antes de ler os controles
Não comece procurando uma opinião limpa. Comece com cinco campos.
| Campo | Pergunta do comprador | Evidência a salvar |
|---|---|---|
| Entidade | Qual é a organização de serviços auditada? | Página de capa do relatório, entidade jurídica, contraparte contratual, consulta de certificado se pública |
| Sistema | Quais serviços, infraestrutura, equipes, processos e fluxos de dados estão incluídos? | Descrição do sistema, lista de produtos/serviços, diagrama de limite do sistema |
| Período | Qual período Type 2 o relatório cobriu? | Data de início, data de término, carta de transição se necessário |
| Critérios | Quais categorias de serviços de confiança foram incluídas? | Escopo de segurança, disponibilidade, integridade de processamento, confidencialidade, privacidade |
| Dependências | Quais organizações subserviços e CUECs afetam a opinião? | Método inclusivo/excluído, lista de subserviços, lista de controles do comprador |
Para um gateway de IA, o campo do sistema merece a maior atenção. "Gateway de API" pode significar apenas roteamento de URL base, ou também pode incluir acesso ao painel, catálogo de modelos, saldo da conta, medição de uso, logs de solicitações, alertas, fluxos de suporte, resposta a incidentes e gerenciamento de chaves. O relatório privado deve informar o que estava na descrição do sistema. Se não informar, peça ao fornecedor que mapeie o escopo do relatório para a rota exata que você pretende usar.
O que um relatório SOC 2 deve comprovar para um gateway de IA
Um relatório SOC 2 Type 2 com escopo definido deve ajudar um comprador a responder a estas perguntas.
| Área de prova | Evidência útil de SOC 2 | Tradução para gateway de IA |
|---|---|---|
| Design e operação de controles | Controles testados durante o período do relatório | Se os controles de acesso, gestão de mudanças, monitoramento, resposta a incidentes, gestão de fornecedores e controles relacionados operaram para o sistema de gateway descrito |
| Escopo de disponibilidade | Critérios de disponibilidade, monitoramento adjacente a SLA, processos de incidentes, se incluídos | Se o serviço coberto tinha monitoramento e controles de resposta definidos, não se cada provedor de modelo permanecerá disponível |
| Escopo de confidencialidade e privacidade | Critérios e controles, se essas categorias estiverem incluídas | Se os controles de tratamento de dados de clientes foram examinados para o sistema descrito, não se cada recurso do provedor tem a mesma configuração de retenção |
| Gestão de mudanças | Lançamento, aprovação e controles de mudança testados | Se as mudanças de código/configuração do gateway foram controladas, não se um caminho aprovado pelo comprador não pode ser alterado pelo comprador posteriormente |
| Controles de acesso | Acesso da força de trabalho, acesso privilegiado, revisão administrativa, controles de gestão de contas | Se o acesso do lado do fornecedor foi controlado, não se o comprador armazenou chaves de API com segurança |
| Segurança lógica | Controles de autenticação, autorização, registro, vulnerabilidade e monitoramento | Se os controles de segurança descritos do gateway existiam, não se os apps do comprador mascaram segredos antes de enviar prompts |
| Gestão de fornecedores | Controles de organização de subserviço e monitoramento de fornecedores | Se as dependências de fornecedores foram gerenciadas, não se o SOC 2, DPA ou configuração de retenção de cada provedor upstream cobre sua rota |
É aqui que o escopo do gateway de API de IA SOC 2 se torna prático. O relatório pode dar suporte à triagem de risco de fornecedores. Ainda assim, ele precisa ser traduzido em fatos da rota: família do endpoint, classe de dados, allowlist de provedores, política de fallback, registro de prompts/saídas, retenção de metadados, acesso de suporte e caminho de exclusão.
O Que O Relatório Não Deve Comprovar
O erro mais comum em procurement é usar um relatório SOC 2 no lugar de decisões que ele não foi projetado para tomar.
Não use o relatório sozinho para comprovar:
| Afirmação | Por que precisa de acompanhamento |
|---|---|
| "Todos os provedores de modelo estão cobertos." | Provedores upstream podem ser organizações de subserviço, estar excluídos ou fora do relatório do gateway. Peça o mapa de provedores e as evidências aplicáveis de cada provedor. |
| "Nenhum prompt ou saída é armazenado em lugar nenhum." | Logs do gateway, logs de monitoramento de abuso do provedor, estado do aplicativo, tickets de suporte e backups podem ter comportamentos de retenção diferentes. |
| "Nenhum treinamento se aplica a todas as rotas." | Compromissos de treinamento e retenção costumam ser específicos de provedor, conta, endpoint e recurso. Guarde a comprovação em nível de conta. |
| "O fallback está aprovado." | Uma rota de fallback pode enviar dados para um provedor ou região diferente. O registro de aprovação deve nomear os provedores de fallback permitidos. |
| "O app do comprador está em conformidade." | SOC 2 trata dos controles da organização de serviços. Redação do comprador, armazenamento de chaves, classificação de dados e controles de acesso do app são responsabilidades do comprador. |
| "A revisão de privacidade ou DPA foi feita." | SOC 2 não é um DPA assinado, avaliação de transferência de dados, aviso de privacidade, BAA ou compromisso de processamento regional. |
| "O estado atual é idêntico ao período do relatório." | O período do relatório pode ter terminado há meses. Peça cartas de ponte, políticas atuais, configuração atual da rota e evidências recentes. |
| "Preços, disponibilidade de modelos e resultados de SLA são garantidos." | Catálogos de modelos, preços, limites de taxa do provedor e disponibilidade de terceiros podem mudar fora do relatório SOC 2. |
Se um fornecedor disser "o SOC 2 cobre isso", peça que ele aponte a seção exata, a linguagem do limite do sistema, o critério coberto, o controle, o resultado do teste e qualquer observação de CUEC ou organização de subserviço.
Leia as Organizações de Subserviço Antes de Aprovar Provedores
Um gateway de IA pode depender de hospedagem em nuvem, sistemas de pagamento, analytics, ferramentas de suporte, provedores de observabilidade, ferramentas de segurança e provedores de modelos upstream. O relatório SOC 2 deve explicar como as organizações de subserviço são tratadas. Os compradores normalmente veem uma de duas abordagens:
| Método | O que isso significa para o comprador |
|---|---|
| Método inclusivo | Os controles relevantes da organização de subserviço estão incluídos no escopo do relatório. Revise quais controles estão incluídos. |
| Método carve-out | A organização de subserviço é excluída do escopo do relatório. Revise evidências separadas e os controles complementares da organização de subserviço. |
Para roteamento de modelos, os carve-outs importam. O relatório SOC 2 de um gateway pode cobrir os controles de gestão de fornecedores do gateway enquanto deixa OpenAI, Anthropic, Google ou outro provedor upstream fora do sistema auditado. Isso não torna o relatório inútil. Significa que a revisão do escopo do gateway de API de IA SOC 2 deve incluir uma linha de evidência do provedor para cada rota aprovada.
A documentação do provedor mostra por que isso não pode ser inferido. A documentação de dados da API da OpenAI separa logs de monitoramento de abuso, estado da aplicação, Zero Data Retention, Modified Abuse Monitoring e comportamento específico do endpoint. A documentação de retenção de dados da API da Anthropic explica que diferentes APIs e recursos têm diferentes necessidades de armazenamento e que o ZDR é um arranjo que os clientes solicitam para casos de uso elegíveis. A documentação de logging do AI Gateway da Cloudflare mostra como um gateway pode expor prompts, respostas, provedor, timestamp, uso de tokens, custo, duração, ações de DLP e controles de logging em nível de payload. Esses são exemplos de superfícies de controle que um comprador deve inspecionar para qualquer rota do gateway, não alegações sobre o relatório privado da Flatkey.
Trate os CUECs como trabalho do comprador, não como texto padrão
Controles complementares da entidade usuária não são enfeite. Eles são os controles que o comprador deve operar para que os controles da organização prestadora de serviço façam sentido.
Para um gateway de API de IA, o trabalho comum de CUEC do lado do comprador inclui:
| Controle de propriedade do comprador | Evidência a ser mantida |
|---|---|
| Armazenamento e rotação de chaves | Caminho do gerenciador de segredos, proprietário, data de rotação, runbook de rotação emergencial |
| Aprovação de rota | Famílias de endpoints aprovadas, allowlist de provedores, política de fallback, classes de dados |
| Redação de prompts | Regras de redação em nível de aplicação, transcript de teste, exemplos de campos bloqueados |
| Revisão de acesso | Lista de administradores, proprietários de chaves, registro de desligamento, revisão de acesso ao painel |
| Política de logging | Se prompts e saídas são armazenados, regra de apenas metadados, cronograma de retenção |
| Monitoramento de uso | Proprietário do orçamento, configurações de cota, limiares de alerta, cadência de revisão financeira |
| Fluxo de incidentes | IDs de solicitação, caminho de escalonamento para suporte, pacote de evidências, responsáveis por notificações |
| Gatilho de renovação | Data de revisão e gatilhos para novos provedores, famílias de endpoints, classes de dados ou alterações de logging |
Um bom memorando de escopo do gateway de API de IA SOC 2 deve anexar a lista de CUECs ao trabalho de engenharia. Se o comprador precisar redigir segredos antes de enviar prompts, a aprovação deve apontar para o teste de redação. Se o comprador precisar aprovar provedores de modelos, a configuração da rota deve mostrar a allowlist.
Evidências de triagem específicas da Flatkey a solicitar e salvar
As páginas públicas atuais da Flatkey, verificadas em 11 de julho de 2026, dão suporte ao uso da Flatkey nesse fluxo de aquisição, mas não substituem evidências específicas da conta.
| Evidência | O que a verificação pública mostrou | Como usar |
|---|---|---|
| Página inicial | A Flatkey se posiciona publicamente em torno das APIs oficiais do GPT, Claude e Gemini por meio de uma única chave, roteamento de modelos, revisão no painel, visibilidade de uso, custo, roteamento e erros. | Usar como evidência datada de triagem do produto. Não tratar como escopo privado do relatório SOC 2. |
| Página de preços e API de preços | As superfícies públicas de preços/catálogo retornaram uma página de preços ativa e uma resposta da API de preços com 158 linhas de modelos e famílias de endpoints incluindo openai, openai-response, anthropic, image-generation e openai-video. |
Usar apenas como um instantâneo datado do catálogo. A disponibilidade de modelos e endpoints pode mudar. |
| Página de SLA | O SLA diz que se aplica ao painel hospedado operado pela Flatkey, ao gateway de API, ao roteamento, à medição e aos serviços de conta, e exclui provedores terceiros de modelos de IA e outros sistemas externos. | Usar para enquadrar o que a Flatkey opera diretamente versus dependências de terceiros. |
| Páginas de privacidade e termos | As páginas públicas de políticas tratam de acesso à API, roteamento de modelos, registros de uso, cobrança, suporte, provedores terceiros de modelos e regras alteráveis de modelos/provedores. | Usar como evidência de triagem; a aprovação final ainda precisa de termos assinados e prova de tratamento de dados específica da rota. |
| Consulta de certificado | A consulta pública da CAI mostrou o certificado da VOC AI Inc. USA-SOC2-220513, SOC 2 Tipo II, ativo, período de 15 de julho de 2025 a 14 de julho de 2026. |
Usar apenas como consulta pública. Solicitar o relatório SOC 2 real e confirmar sistema coberto, critérios, período, exceções, CUECs e tratamento de subprestadores. |
Para a Flatkey ou qualquer gateway de API de IA, a aprovação deve dizer: "Páginas públicas verificadas; relatório privado solicitado; evidências da rota anexadas; suposições não suportadas listadas."
Monte um pacote de evidências do escopo à rota
O resultado desta revisão deve ser um pequeno pacote de evidências, não uma aprovação vaga.
| Item do pacote | Arquivo a salvar | Responsável |
|---|---|---|
| Relatório SOC 2 | Relatório privado, período do relatório, critérios, opinião, exceções, carta de ponte, se necessário | Compras/segurança |
| Mapa de escopo | Fronteira do sistema do relatório mapeada para dashboard, gateway, API, medição, logs, suporte e configuração de rota | Engenharia de plataforma |
| Mapa de provedor | Provedores aprovados, ordem de fallback, tratamento de subserviço, evidência separada do provedor | Segurança/plataforma |
| Mapa de dados | Prompts, saídas, arquivos, metadados, registros de cobrança, logs, tickets de suporte, backups | Segurança/jurídico |
| Matriz de retenção | Retenção de gateway, provedor, aplicação, suporte e backup por família de endpoint | Segurança/jurídico |
| Registro de CUEC | Controles do comprador e comprovação de que cada um foi implementado | Plataforma/segurança |
| Evidência de teste | Uma solicitação de baixo risco bem-sucedida e uma falha esperada com IDs de solicitação e logs redigidos | Engenharia de plataforma |
| Memorando de aprovação | Escopo, restrições, riscos abertos, nomes dos revisores, gatilho de renovação | Responsável de negócio/compras |
Este pacote também é a ponte entre a revisão SOC 2 e as operações de engenharia. Quando um novo provedor, classe de modelo, modo de logging ou classe de dados é adicionado, a equipe deve saber quais arquivos precisam ser atualizados.
Sinais de alerta que devem pausar a aprovação
Pare a aprovação se algum destes itens não estiver resolvido:
- O relatório SOC 2 não está disponível e apenas um badge ou consulta de certificado é fornecido.
- O período do relatório terminou e nenhuma carta de ponte ou evidência atual está disponível.
- A descrição do sistema não inclui claramente o caminho do gateway que você planeja usar.
- O relatório exclui organizações de subserviço relevantes e nenhuma evidência separada do provedor está anexada.
- As categorias de trust services selecionadas não correspondem ao risco declarado pelo comprador, como privacidade ou confidencialidade.
- Os CUECs exigem controles do comprador que não foram implementados.
- Assume-se que o logging de prompts/saídas está desativado, mas nenhuma evidência da conta ou da rota comprova isso.
- O fallback pode enviar dados para um provedor não aprovado.
- O suporte pode inspecionar o conteúdo da solicitação, mas o acesso do suporte, a retenção de tickets e a redação não estão documentados.
- A aprovação não tem responsável, data de expiração ou gatilho de mudança de rota.
Esses sinais de alerta nem sempre significam que o fornecedor falhou. Eles significam que a revisão do escopo do gateway de API de IA SOC 2 não foi concluída.
Uma declaração prática de aprovação
Uma declaração de aprovação útil é curta, específica e verificável:
| Campo | Exemplo de redação |
|---|---|
| Evidência do relatório | "Relatório SOC 2 Tipo 2 revisado para o Fornecedor X, período A a B, critérios de segurança e disponibilidade, sem exceções não aceitas para esta rota." |
| Escopo aprovado | "Fluxo de trabalho de suporte em produção apenas com texto por meio da URL base do gateway e do endpoint de chat aprovados." |
| Provedores | "Fornecedor A primário, Fornecedor B em fallback; sem endpoint de imagem, vídeo, arquivo, busca na web ou em lote." |
| Classe de dados | "Texto de suporte ao cliente após redação no nível da aplicação; sem dados de pagamento, segredos, PHI ou registros regulamentados." |
| Logging | "Logs de metadados do gateway permitidos; logging bruto de prompts/saídas desativado ou aprovado separadamente; evidência de retenção do provedor anexada." |
| Controles do comprador | "Chaves armazenadas no gerenciador de segredos, revisão trimestral de acesso, allowlist de rotas, revisão mensal de uso, responsável por incidentes designado." |
| Gatilho de renovação | "Atualizar antes de adicionar provedores, habilitar novas famílias de endpoint, alterar logging, rotear dados regulamentados ou após o período SOC 2 expirar." |
É isso que "aprovado" deve significar. Os desenvolvedores sabem qual rota podem usar. As compras sabem quais evidências foram revisadas. A segurança sabe o que monitorar. O jurídico sabe quais pressupostos ainda exigem redação contratual.
Conclusão
Uma revisão do escopo do gateway de API de IA SOC 2 é valiosa quando permanece precisa. O relatório deve ajudar a comprovar o sistema descrito da organização de serviços auditada, os critérios abrangidos, a operação dos controles, o período do relatório, as exceções, o tratamento de subserviços e as responsabilidades do comprador. Ele não deve ser estendido para provar cada rota, provedor, configuração de retenção, comportamento de fallback, cláusula de DPA, alegação de residência de dados ou configuração do comprador.
Para a Flatkey, comece com a evidência pública atual e depois solicite o relatório SOC 2 privado e mapeie-o para a rota que sua equipe realmente executará. Se você quer uma chave de API e um painel para acesso multimodelo, obtenha uma chave, anexe a lista de verificação de escopo do gateway de API de IA SOC 2 ao pacote de compras e aprove cada rota de produção com evidência explícita de provedor, logging, retenção e CUEC.
Perguntas frequentes
O que é o escopo do gateway de API de IA SOC 2?
O escopo do gateway de API de IA SOC 2 é a fronteira do relatório SOC 2 conforme se aplica a um gateway de API de IA. Ele inclui a entidade auditada, o sistema descrito, o período do relatório, as categorias de trust services, os controles testados, as organizações de subserviço, os carve-outs e os CUECs de propriedade do comprador.
O SOC 2 prova que todo provedor de modelo de IA está coberto?
Não. A SOC 2 pode mostrar como o fornecedor do gateway gerencia o sistema descrito e suas dependências, mas os provedores de modelos upstream podem ser incluídos, excluídos ou cobertos por evidências separadas. Os compradores devem guardar um mapa de provedores para cada rota aprovada.
Um relatório SOC 2 Type 2 comprova que não há retenção de prompts?
Não por si só. A retenção de prompts e outputs pode diferir entre o gateway, os provedores upstream, o estado da aplicação, os tickets de suporte, os logs e os backups. O comprador deve verificar evidências de retenção específicas do endpoint, da conta e da rota.
O que a área de compras deve solicitar após ver um selo SOC 2?
Solicite o relatório SOC 2 privado, o período do relatório, os critérios cobertos, a descrição do sistema, exceções, tratamento de organizações de subserviço, CUECs, carta de ponte, se necessário, mapa de provedores, configuração da rota, configurações de logging, matriz de retenção e evidências assinadas de contrato/DPA, quando aplicável.
Com que frequência a revisão de escopo deve ser atualizada?
Atualize a revisão de escopo do gateway de API de IA SOC 2 quando o período do relatório expirar, quando o fornecedor fornecer um novo relatório, antes de adicionar um provedor ou família de endpoints, antes de rotear uma nova classe de dados, quando o logging ou a retenção mudarem e após incidentes materiais.
Fontes para revisar
- Página inicial da Flatkey
- Preços da Flatkey
- Política de Privacidade da Flatkey
- Termos de Serviço da Flatkey
- Acordo de Nível de Serviço da Flatkey
- Consulta de certificado SOC 2 da CAI para USA-SOC2-220513
- Suíte de serviços SOC da AICPA
- Critérios de Serviços de Confiança da AICPA de 2017 com pontos de foco revisados
- Critérios de descrição SOC 2 da AICPA de 2018
- Controles de dados da API da OpenAI
- API da Anthropic e retenção de dados
- Logging do Cloudflare AI Gateway
