Revisão do gateway de API de IA SOC 2 deve começar antes de o comprador pedir um pacote de segurança. A pergunta de procurement não é “você tem um selo?” É se o gateway, as rotas do modelo, os logs, as chaves, os registros de faturamento, o processo de suporte e os provedores downstream podem ser vinculados a evidências que um revisor de segurança realmente possa inspecionar.
Este guia é para equipes de procurement, segurança, plataforma, conformidade e risco de fornecedores que avaliam um gateway de API de IA antes do tráfego em produção. Não é aconselhamento jurídico nem de auditoria. Use-o como uma lista prática de verificação de evidências: o que solicitar, o que verificar no relatório SOC 2, o que testar no gateway e o que manter no seu próprio arquivo do lado do comprador.
A Flatkey é relevante porque a flatkey.ai posiciona publicamente o produto como um gateway de API único para equipes de IA em produção, com acesso a modelos, roteamento, faturamento, análises de uso, controles operacionais, um painel e uma chave para múltiplos provedores. O rodapé público da Flatkey também inclui links para páginas de consulta de certificados da VOC AI Inc., mostrando uma entrada SOC 2 Type II e uma entrada ISO 27001:2022, e o snapshot atual da API de preços verificado em 19 de junho de 2026 retornou 638 linhas de modelos em 23 fornecedores. Trate isso como evidência pública datada, não como substituto do relatório SOC 2 privado, do contrato assinado, do DPA, das configurações da conta ou da validação dos logs de produção.
Resposta rápida: o que a evidência do gateway de API de IA SOC 2 deve provar
Uma revisão de gateway de API de IA SOC 2 deve provar três coisas: o relatório de controles do fornecedor cobre o serviço relevante, o gateway consegue produzir evidência operacional para o seu tráfego de IA e a sua própria equipe tem controles para as responsabilidades que o relatório do fornecedor deixa para os clientes.
| Área de revisão | Evidência a solicitar | O que verificar |
|---|---|---|
| Escopo do relatório SOC 2 | Relatório SOC 2 Type II atual, período do relatório, auditor, descrição do sistema e carta de ponte, se o período do relatório estiver desatualizado. | O gateway de IA, o roteamento de API, o registro de logs, o suporte, o faturamento e a infraestrutura relevante estão dentro do limite do sistema. |
| Critérios de Serviços de Confiança | Categorias cobertas pelo relatório, normalmente segurança, além de quaisquer critérios de disponibilidade, confidencialidade, integridade de processamento ou privacidade. | As categorias cobertas correspondem ao risco do comprador. Não presuma que privacidade ou disponibilidade estejam cobertas, a menos que o relatório diga isso. |
| Controles complementares do usuário | CUECs e responsabilidades do comprador listadas no relatório SOC 2. | Sua equipe consegue atender às responsabilidades de gerenciamento de chaves, aprovação de rotas, classificação de dados, acesso de usuários, retenção e incidentes. |
| Organizações de subserviço | Descrição de organização de subserviço com carve-out ou inclusiva, lista de provedores e controles de monitoramento. | Provedores de modelos downstream, serviços de nuvem, ferramentas de suporte, observabilidade e fornecedores de faturamento são tratados de forma consistente com o modelo do relatório. |
| Operações do gateway de IA | Logs de exemplo, campos de propriedade de chave, histórico de mudanças de rota, inventário de rotas de provedores de modelo e processo de exportação de incidentes. | O gateway consegue mostrar quem enviou o tráfego, qual modelo/provedor o recebeu, o que mudou e qual evidência é retida. |
| Dados e privacidade | Política de privacidade, caminho do DPA, locais de processamento de dados, política de retenção, política de registro de payload e termos de uso de dados do provedor. | Prompts, outputs, metadados, materiais de suporte e registros de faturamento têm regras claras de tratamento. |
| Evidência do lado do comprador | Seu próprio registro de implantação, casos de uso aprovados, taxonomia de chaves, política de rotas, modo de logging e cadência de revisão. | A evidência do fornecedor está vinculada à forma como sua equipe realmente usará o gateway. |
Comece pelo Escopo do SOC 2, não pelo selo
Um selo público pode ser útil para a triagem inicial, mas a equipe de compras ainda deve solicitar o relatório SOC 2 real por meio do processo de confiança do fornecedor. A AICPA descreve a divulgação SOC 2 como uma avaliação dos controles em uma organização de serviços relevantes para segurança, disponibilidade, integridade de processamento, confidencialidade ou privacidade. Isso significa que a pergunta útil para compras é o escopo: qual sistema, serviço, intervalo de datas, critérios, controles, exceções e afirmações da administração estão cobertos?
Para um SOC 2 AI API gateway, a revisão do escopo deve responder:
| Campo de Escopo | Pergunta do Comprador | Por que Isso Importa para o Tráfego da API de IA |
|---|---|---|
| Entidade jurídica | Qual entidade está nomeada no relatório e no contrato? | A busca pública de certificado da Flatkey se refere à VOC AI Inc.; seu arquivo de compras deve corresponder à entidade contratante e à proprietária do serviço. |
| Perímetro do sistema | O relatório cobre o gateway de IA, o roteamento de API, o painel, as chaves, o faturamento, os registros de uso e o processo de suporte? | Um relatório para uma plataforma mais ampla de dados ou análise pode não comprovar o fluxo específico do gateway que você planeja usar. |
| Período do relatório | Qual intervalo de datas o relatório Type II testou, e é necessária uma carta de ponte? | Normalmente, a equipe de compras quer evidências operacionais atuais, não apenas uma declaração histórica de um ponto no tempo. |
| Categorias de confiança | Quais Trust Services Criteria estão cobertos? | Cobertura de segurança não significa automaticamente cobertura de disponibilidade, confidencialidade, integridade de processamento ou privacidade. |
| Exceções | Algum controle foi qualificado, excetuado ou corrigido? | Exceções podem afetar gerenciamento de chaves, registros, controle de mudanças, resposta a incidentes ou monitoramento de fornecedores. |
| Organizações de subserviço | Quais serviços de nuvem, provedor, suporte, observabilidade e pagamento estão excluídos ou incluídos? | O risco do gateway de IA muitas vezes depende de provedores downstream de modelos e infraestrutura. |
A regra prática é simples: se um comprador não conseguir vincular o relatório SOC 2 ao serviço exato do gateway e ao caminho do tráfego, o relatório é uma evidência de triagem, não uma evidência final de compra.
Mapeie os Critérios SOC 2 aos Controles do Gateway de IA
Os Critérios de Serviços de Confiança da AICPA abrangem segurança, disponibilidade, integridade de processamento, confidencialidade e privacidade. Um pacote de evidências de gateway de API de IA SOC 2 deve traduzir essas categorias amplas em verificações concretas do gateway.
| Tópico de Controle | Evidência a Verificar | Preocupação SOC 2 Relacionada |
|---|---|---|
| Propriedade da chave de API | As chaves estão vinculadas a proprietários, ambientes, aplicativos e fluxos de trabalho; a criação e a revogação de chaves são auditáveis. | Acesso lógico, responsabilidade, controle de mudanças e contenção de incidentes. |
| Aprovação de rota e modelo | Provedores aprovados, famílias de endpoints, linhas de modelos, regras de fallback e registros de ცვლილação são revisáveis. | Gestão de mudanças, monitoramento de fornecedores, integridade de processamento e confidencialidade. |
| Registros de auditoria | Os registros mostram timestamp, chave ou projeto, rota, provedor, modelo, família de endpoint, status, classe de erro, unidades de uso e alterações administrativas. | Monitoramento, resposta a incidentes, revisão de acesso e evidências operacionais. |
| Tratamento de payload | O modo de logging de prompt/saída, a redação, a restrição de acesso, o período de retenção e o caminho de exclusão estão documentados. | Confidencialidade, privacidade e minimização de dados. |
| Uso e faturamento | Os registros de uso e os registros de faturamento são separados dos payloads brutos e vinculados ao proprietário, modelo, rota e centro de custo. | Integridade de processamento, responsabilidade e suporte à revisão financeira. |
| Revisão de incidentes | Eventos de segurança, falhas de provedor, uso suspeito, chaves vazadas, loops de fallback e eventos acima do limite têm um runbook e um caminho de exportação. | Monitoramento de segurança, resposta e correção. |
| Alterações de fornecedor e provedor | Adições, remoções, alterações regionais e mudanças na política de uso de dados dos provedores acionam nova revisão. | Monitoramento da organização subserviço e avaliação de risco. |
É aqui que os gateways de IA diferem dos gateways de API genéricos. A rota não é apenas uma decisão de host/caminho. Ela pode determinar qual provedor de modelo vê os prompts, qual política de dados se aplica, qual regra de retenção se aplica, qual caminho de fallback é permitido e qual unidade de uso é cobrada.
Evidências da Flatkey a Verificar Antes da Aquisição
A Flatkey tem evidências públicas úteis para uma análise inicial de gateway de API de IA SOC 2. O site público informa que a Flatkey unifica acesso a modelos, roteamento, faturamento, análise de uso e controles operacionais para equipes que lançam produtos de IA. O rodapé vincula a uma consulta Cert Assure SOC 2 Type II para VOC AI Inc., certificado `USA-SOC2-220513`, com período informado de 15 de julho de 2025 a 14 de julho de 2026 e status ativo no momento verificado. O mesmo rodapé vincula a uma consulta ISO 27001:2022 para VOC AI Inc., certificado `USA-I-270513`, com período informado de 1º de maio de 2024 a 30 de abril de 2027 e status ativo no momento verificado.
Use essas páginas públicas como ponto de partida do arquivo e, em seguida, verifique estes detalhes diretamente com a Flatkey antes da aquisição:
| Verificação da Flatkey | O Que Capturar | Diretriz |
|---|---|---|
| Solicitação do relatório SOC 2 | Relatório atual, auditor, período, escopo, critérios cobertos, exceções, organizações subcontratadas e carta de ponte, se necessário. | Não confie apenas no selo público ou na consulta do certificado. |
| Verificação cruzada ISO 27001:2022 | Entidade do certificado, escopo da atividade, datas e qualquer declaração de aplicabilidade ou visão geral de segurança disponível na análise de confiança. | A certificação ISO dá suporte a uma análise de SGSI, mas não substitui o relatório SOC 2 ou a validação do roteamento de IA. |
| Suporte ao catálogo e ao endpoint | Linha de modelo atual, provedor, família do endpoint, status de disponibilidade e unidade de preço em preços da Flatkey. | Contagens de modelos, contagens de fornecedores e disponibilidade podem mudar; verifique no dia em que aprovar o roteamento. |
| Evidência do painel | Proprietário principal, rota, modelo, provedor, status, unidade de uso, registro de cobrança e qualquer caminho de exportação no painel da Flatkey atual. | Não presuma os rótulos exatos do painel com base apenas no texto de marketing público. |
| Logs e retenção | Campos de metadados, comportamento de registro de payload, período de retenção, permissões de visualização, tratamento de dados de suporte e processo de exclusão/exportação. | A política de privacidade pública da Flatkey menciona metadados de solicitação, registros de erro, registros de uso, logs necessários e materiais de suporte, mas um comprador precisa de termos específicos da conta. |
| Política de rota do provedor | Provedores aprovados, restrições de fallback, termos de uso de dados do provedor e quem pode alterar rotas. | O fallback de confiabilidade pode se tornar uma mudança de risco de fornecedor se o provedor downstream mudar. |
Como Testar o Gateway Antes da Aprovação de Segurança
Não espere o tráfego real de clientes para descobrir se a evidência do seu gateway de API de IA SOC 2 está completa. Execute um smoke test controlado por rota e salve o pacote de revisão.
- Crie identificadores de rota não secretos: use chaves ou projetos separados para staging, produção, lote, tráfego voltado ao cliente e tráfego de avaliação.
- Escolha uma rota de modelo de baixo risco: registre fornecedor, linha do modelo, família do endpoint, unidade de preço e classe de dados esperada.
- Envie uma solicitação de teste inofensiva: evite dados reais de clientes, dados pessoais, segredos ou conteúdo regulamentado.
- Revise o registro de log: confirme carimbo de data e hora, chave/projeto, proprietário, rota, fornecedor, modelo, status, unidades de uso, classe de erro e visibilidade de custo.
- Revise a evidência administrativa: confirme quem criou a chave, quem aprovou a rota, quem pode alterar o fallback e onde as alterações são registradas.
- Teste um caminho de negação: tente um modelo não permitido, classe de dados bloqueada, chave expirada ou limite de cota e salve o resultado.
- Documente a retenção: identifique onde metadados, cargas úteis, se houver, tickets de suporte, registros de faturamento e logs de segurança são retidos.
- Anexe documentos de procurement: relatório SOC 2, carta de ponte, evidência ISO, política de privacidade, termos, caminho do DPA, revisão do fornecedor e sua nota de implantação.
- Repita em caso de mudanças: refaça o pacote quando fornecedor, modelo, família do endpoint, fallback, classe de dados, modo de logging ou termos contratuais mudarem.
- Separe evidências públicas e privadas: páginas públicas ajudam na triagem; relatório privado e validação específica da conta concluem o procurement.
A SOC 2 é Apenas Uma Camada Da Revisão de AI Gateway
Uma revisão de SOC 2 AI API gateway deve ficar ao lado de ISO 27001, GDPR, segurança de aplicações e verificações de risco de fornecedores. Esses frameworks estão relacionados, mas respondem a perguntas diferentes.
| Framework Or Source | What It Helps Verify | What It Does Not Prove By Itself |
|---|---|---|
| SOC 2 | Exame independente dos controles para o sistema descrito e dos Trust Services Criteria abrangidos durante o período do relatório. | Não prova que cada recurso do Flatkey, configuração de conta do cliente, rota de modelo downstream ou fluxo de trabalho do comprador esteja abrangido. |
| ISO/IEC 27001:2022 | Escopo do sistema de gestão de segurança da informação, gestão de riscos e status de certificação. | Não substitui um relatório SOC 2 nem prova um esquema específico de log de solicitações de IA. |
| GDPR | Revisão do processador, segurança do processamento, minimização de dados, retenção, salvaguardas de transferência e mapeamento de funções para dados pessoais. | Não é atendido apenas porque um gateway foi revisado em SOC 2. |
| OWASP logging guidance | Design prático de logs, atributos de eventos, dados a excluir, proteção de logs e preocupações de monitoramento. | Não define a política de retenção do seu fornecedor nem prova que o tratamento de prompt/output é aceitável. |
| Buyer controls | Sua taxonomia de chaves, acesso de usuários, aprovação de rotas, classificação de dados, fallback de modelo, retenção e revisão de incidentes. | Não substituem os controles do fornecedor; eles tornam a evidência do fornecedor utilizável no seu ambiente. |
Use o enterprise AI API gateway checklist adjacente da Flatkey para a pilha mais ampla de procurement e audit logs for AI API usage para os campos de evidência que as equipes de segurança normalmente solicitam.
Modelo de Pacote de Evidências de Compras
A saída mais útil de uma revisão de um gateway de API de IA SOC 2 é um pacote compacto que as equipes de engenharia de vendas, segurança, jurídico e plataforma possam ler.
| Seção do Pacote | Campos a Incluir | Responsável |
|---|---|---|
| Identidade do fornecedor | Entidade legal, entidade contratante, contato de suporte, caminho do portal de confiança, links de consulta de certificados e status atual. | Compras |
| Arquivo SOC 2 | Tipo de relatório, período, auditor, limite do sistema, Critérios de Serviços de Confiança, exceções, organizações de subserviço, CUECs e carta de ponte. | Segurança |
| Arquivo de rotas do gateway | Provedores aprovados, modelos, famílias de endpoints, regras de fallback, classes de dados, responsável pela rota e aprovador da alteração. | Engenharia de plataforma |
| Arquivo de logs e evidências | Campos de metadados da solicitação, logs administrativos, política de payload, classe de retenção, método de exportação e lista de acesso dos visualizadores. | Operações de segurança |
| Arquivo de proteção de dados | Caminho do DPA, política de privacidade, termos, revisão do uso de dados pelo provedor, locais de processamento, lista de subprocessadores e notas sobre a função no GDPR. | Jurídico e privacidade |
| Controles do lado do comprador | Taxonomia de chaves, cadência de revisão de acesso, processo de alteração de rotas, política de cotas, runbook de incidentes e gatilhos de nova revisão. | Plataforma e governança |
| Aprovação de lançamento | Aprovador final, casos de uso aprovados, classes de dados bloqueadas, data de lançamento, data de revisão e riscos residuais. | Segurança e produto |
Bandeiras Vermelhas Durante a Revisão
Pare a aquisição se a evidência do SOC 2 AI API gateway deixar estas lacunas sem समाधान:
- Resposta baseada apenas em selo: o fornecedor aponta para um selo, mas não consegue fornecer o relatório SOC 2 atual sob NDA ou acesso de confiança.
- Incompatibilidade de escopo: o relatório cobre um produto, entidade, limite de infraestrutura ou período diferente do gateway que está sendo adquirido.
- Sem plano de CUEC: o relatório lista responsabilidades do cliente, mas o comprador não as atribuiu internamente.
- Organizações de subserviço opacas: provedores de modelos downstream, ferramentas de suporte, ferramentas de logging ou provedores de nuvem não são tratados de forma clara.
- Sem evidência de mudança de rota: a equipe não consegue mostrar quem adicionou um provedor, alterou um modelo ou habilitou fallback.
- Ambiguidade no logging de payload: prompts e outputs podem ser armazenados, mas retenção, acesso e exclusão não estão claros.
- Prova apenas no dashboard: há capturas de tela, mas não existe um arquivo de evidência exportável ou revisável para a análise de segurança.
- Sem gatilho de reavaliação: novos modelos, regiões, famílias de endpoints e mudanças na política do provedor podem acontecer sem revisão de compras/segurança.
Perguntas frequentes
O que é evidência de gateway de API de IA SOC 2?
A evidência de gateway de API de IA SOC 2 é o conjunto de documentos, logs, registros de rotas, mapeamentos de controles e notas do lado do comprador que mostram como os controles de um gateway de IA apoiam a revisão de procurement. Inclui o relatório SOC 2 do fornecedor, revisão de escopo, tratamento de organizações de subserviço, logs de auditoria, propriedade de chaves, aprovações de rotas, política de retenção e responsabilidades do cliente.
Um selo SOC 2 é suficiente para aprovar um gateway de API de IA?
Não. Um selo pode ajudar na triagem inicial, mas procurement deve verificar o relatório SOC 2 atual, o sistema abrangido, o período do relatório, os critérios, as exceções, as organizações de subserviço e os controles complementares da entidade usuária. O relatório privado e o teste de rota do comprador importam mais do que o selo sozinho.
O SOC 2 deve cobrir todos os provedores de modelos por trás de um gateway?
Não necessariamente. Os relatórios SOC 2 descrevem o sistema da organização de serviços e como as organizações de subserviço são tratadas, muitas vezes por meio de métodos carve-out ou inclusive. Os compradores devem verificar como provedores de modelos, serviços de nuvem, ferramentas de suporte e serviços de observabilidade são representados e, em seguida, revisar os próprios dados e termos de segurança de cada provedor.
Como SOC 2 e GDPR se conectam para um gateway de API de IA?
SOC 2 pode apoiar evidências de controle de segurança, enquanto a revisão de GDPR foca em funções de processamento, base legal, minimização de dados, termos de operador, transferências, retenção e direitos dos titulares dos dados. Um gateway de API de IA SOC 2 pode centralizar evidências úteis, mas não resolve automaticamente as obrigações do GDPR.
O que devo verificar na Flatkey antes de comprar?
Verifique o relatório SOC 2 atual da Flatkey, os detalhes do certificado ISO 27001, a entidade jurídica, os termos assinados, o caminho do DPA, a rota do modelo/provedor, a família do endpoint, os campos de evidência do painel, a retenção de logs, o tratamento de payload, o tratamento de dados de suporte e o comportamento de fallback. Confirme também a linha do modelo atual e a unidade de preço no dia em que você aprovar o uso em produção.
Etapa Final de Aquisição
Antes de aprovar um gateway de API de IA SOC 2, monte o pacote de evidências da mesma forma que um auditor ou comprador corporativo o inspecionará: entidade, escopo do relatório, critérios, período, exceções, organizações de serviços terceirizados, logs, controles de acesso, alterações de rota, tratamento de dados e responsabilidades do cliente. A Flatkey pode centralizar o acesso ao modelo, o roteamento, a visibilidade de uso e os controles operacionais, mas seu dossiê de aquisição ainda deve verificar o relatório atual e a rota exata que você irá executar.
Obtenha uma chave quando estiver pronto para centralizar o acesso ao modelo, o roteamento, a visibilidade de uso e as evidências para revisão do comprador em um único gateway de API de IA.
