Uma checklist de DPA para AI gateway deve fazer mais do que confirmar que um fornecedor tem uma página jurídica. Para compradores de model routing, a verdadeira questão é se o acordo de processamento de dados assinado corresponde à rota que sua aplicação realmente usará: logs do gateway, provedores de modelo upstream, acesso do suporte, roteamento regional, controles de retenção, direitos de exclusão e aviso de incidente.
Use esta checklist de DPA para AI gateway antes de aprovar uma camada unificada de acesso a modelos, um DPA de LLM gateway ou um acordo de processamento de dados de API de IA. Isto não é aconselhamento jurídico. É uma lista prática de evidências para equipes de plataforma, segurança, compras e jurídica que precisam que o DPA esteja alinhado ao comportamento técnico de roteamento.
A Flatkey se encaixa nesta revisão porque o site público atual posiciona flatkey.ai em torno de uma chave de API, uma base URL compatível com OpenAI em https://router.flatkey.ai/v1, visibilidade de uso e custos, logs de requisições, roteamento de modelos e acesso a provedores por meio de um único painel. Trate essas páginas de produto como evidências de triagem datadas. Para aprovação, anexe seu formulário de pedido assinado, DPA, configurações da conta e qualquer confirmação do suporte que controle sua carga de trabalho real.
Se você estiver construindo o conjunto mais amplo de controles, combine esta revisão com a checklist de gateway de API de IA para GDPR, a checklist de gateway de API de IA empresarial, a checklist de retenção de dados de API de IA e os atuais preços da Flatkey.
Checklist de AI Gateway DPA: Comece Pela Rota
O primeiro erro é avaliar o fornecedor de forma genérica. O DPA precisa corresponder a uma rota específica. Um chatbot de suporte, um classificador de documentos em lote, um assistente de programação e um fluxo de trabalho multimodal de mídia podem ter diferentes classes de dados, endpoints, termos de provedor, comportamento de armazenamento e acesso do suporte.
Antes da revisão jurídica, congele estes fatos da rota:
| Campo da rota | Pergunta a responder | Evidência a salvar |
|---|---|---|
| Proprietário da carga de trabalho | Quem é o responsável pelo recurso e pelos dados enviados por ele? | Proprietário do produto, proprietário da plataforma, revisor de segurança |
| Ambiente | Isso é desenvolvimento, staging, produção ou específico do cliente? | Configuração da rota, nome do projeto, tag de ambiente |
| Família de endpoint | A chamada é chat, responses, messages, image, video, embeddings, files ou um fluxo de trabalho com ferramenta? | Endpoint do gateway e endpoint do provedor upstream |
| Classe de dados | Prompts, arquivos, imagens, áudio, conteúdo do cliente, credenciais ou dados regulados passarão por ali? | Nota de classificação de dados e payload de amostra redigido |
| Caminho do provedor | Quais provedores de modelo podem receber a solicitação sob roteamento normal e fallback? | Política de rota, lista de provedores, ordem de fallback |
| Caminho de logs | Quais sistemas podem armazenar metadados de requisição, prompts, saídas, erros, tickets de suporte ou exportações? | Configurações do gateway, documentação do provedor, configuração de observabilidade |
| Caminho de retenção | O que é retido pelo gateway, pelo provedor upstream, pelas ferramentas de suporte e pelos backups? | DPA, documentação de privacidade, configurações de retenção, procedimento de exclusão |
| Escopo de aprovação | O que está aprovado e o que exigiria uma nova revisão? | Registro de decisão e data de expiração da revisão |
A checklist de DPA para AI gateway deve terminar com um registro de aprovação específico da rota, e não com uma declaração ampla de que "IA está aprovada".
As Dez Perguntas de Processamento de Dados que os Compradores Devem Fazer
Use estas perguntas como a checklist central de DPA de fornecedor de IA para qualquer compra de model routing.
| # | Pergunta de DPA | Por que isso importa para o roteamento de modelos | Evidência aceitável |
|---|---|---|---|
| 1 | Quem é o controlador, operador e suboperador para cada rota? | Um gateway pode processar dados diretamente e também passá-los para provedores de modelos upstream. | DPA assinado, lista de suboperadores, mapa de rota/provedor |
| 2 | Quais categorias de dados estão no escopo? | "Dados de API" podem incluir prompts, saídas, arquivos enviados, imagens, logs, metadados, dados de cobrança e tickets de suporte. | Programa de categorias de dados, exemplos de payload, configurações de conta |
| 3 | Quais provedores podem receber a solicitação? | O roteamento dinâmico e o fallback podem alterar a cadeia de processamento. | Política de rota, lista de provedores permitidos, regras de fallback |
| 4 | Prompts e saídas são armazenados? | Logs do gateway e logs de monitoramento de abuso do provedor podem ter comportamentos de retenção diferentes. | Configuração de retenção do gateway, controles de dados do provedor, prova de ZDR/MAM quando aplicável |
| 5 | Quais metadados são retidos? | Mesmo que o conteúdo não seja armazenado, os metadados podem revelar usuários, workloads, custos, horários, IPs ou IDs de clientes. | Esquema de logs, campos de analytics, amostra de exportação de cobrança |
| 6 | Qual acesso de suporte é permitido? | Investigações de suporte podem expor registros de solicitação, capturas de tela, logs ou metadados da conta. | Política de acesso de suporte, registros de transparência de acesso, processo de redação de tickets |
| 7 | Quais suboperadores são usados? | Um DPA é incompleto se não divulgar os serviços que processam dados de clientes. | Lista atual de suboperadores e processo de aviso |
| 8 | Que processo de exclusão ou devolução existe? | A área de compras precisa saber como conteúdos retidos, logs, arquivos e registros da conta são excluídos ou exportados. | SLA de exclusão, etapas da API/painel, observação sobre exceção de backup |
| 9 | Onde os dados são processados e armazenados? | Roteamento regional, regiões dos provedores, equipes de suporte e logs podem não compartilhar a mesma localidade. | Termos de residência de dados, configuração de região da rota, documentação da região do provedor |
| 10 | Quais notificações de incidente e evidências de auditoria estarão disponíveis? | Os compradores precisam de um cronograma para notificação de incidente, comunicação do incidente e evidências após um problema de roteamento. | Termos de aviso do DPA, SLA, contato de segurança, relatório de auditoria, fluxo de trabalho de incidente |
Se a resposta mudar por endpoint, recurso, provedor ou nível de conta, registre essa exceção na checklist de DPA do AI gateway em vez de suavizá-la.
Combine a Linguagem do DPA com o Processamento Técnico
Contratos de operador no estilo do Artigo 28 focam em objeto, duração, natureza, finalidade, categorias de dados, direitos do controlador, instruções do operador, confidencialidade, segurança, suboperadores, exclusão ou devolução e assistência com direitos dos titulares. Esses são termos jurídicos. Um comprador de gateway ainda precisa traduzi-los em fatos de engenharia.
Use este mapeamento:
| Termo do DPA | Tradução técnica para um AI gateway |
|---|---|
| Objeto | Inferência de modelos, roteamento, medição, logging, cobrança, suporte e administração da conta |
| Duração | Por quanto tempo o contrato vigora, além de quanto tempo logs, arquivos, tickets de suporte e backups permanecem |
| Natureza e finalidade | Encaminhar solicitações para provedores de modelos, retornar saídas, medir uso, detectar abuso, dar suporte a incidentes |
| Categorias de dados pessoais | Conteúdo do prompt, conteúdo da saída, arquivos enviados, identificadores de usuário, endereços IP, metadados da conta, contatos de cobrança |
| Instruções do operador | Rotas permitidas, classes de dados bloqueadas, provedores aprovados, compromissos de não treinamento, configurações de retenção |
| Suboperadores | Provedores de modelos upstream, hospedagem em nuvem, pagamento, analytics, suporte, monitoramento, e-mail e fornecedores de segurança |
| Medidas de segurança | Criptografia, controles de acesso, logging, gerenciamento de chaves, segmentação, processo de vulnerabilidades, evidência de auditoria |
| Exclusão ou devolução | Exclusão de conteúdo, exclusão de arquivos, expiração de logs, redação de tickets de suporte, formato de exportação, exceções de backup |
É aqui que muitas revisões de contratos de processamento de dados de API de IA quebram. O DPA pode dizer que um operador age sob instruções, enquanto a rota do produto discretamente permite fallback para vários provedores. O registro de aprovação deve dizer quais provedores são permitidos, quais são bloqueados e quem pode alterar essa política.
Verifique a Retenção por Endpoint e Recurso
Os controles de dados do provedor costumam ser específicos por recurso. Os controles de dados da plataforma da OpenAI descrevem restrições de treinamento da API, retenção padrão de monitoramento de abuso, controles aprovados de Zero Data Retention ou Modified Abuse Monitoring e comportamento do estado do aplicativo específico por endpoint. A documentação de retenção de dados da API da Anthropic separa o processamento da Claude API do processamento em marketplace de nuvem e explica a elegibilidade para ZDR por recurso. A documentação de ZDR da Gemini Developer API do Google explica restrições de treinamento para serviços pagos e casos em nível de recurso em que prompts, respostas, arquivos, grounding, state ou comportamento de cache ainda podem importar.
Isso significa que "temos ZDR" não é suficiente para um DPA de gateway de LLM. Pergunte:
- O endpoint exato é elegível para o controle de retenção?
- O projeto, organização ou conta exatos estão aprovados?
- O fallback encaminha para um provedor ou recurso que não está coberto?
- Arquivos, imagens, áudio, vídeo, ferramentas, pesquisa na web, execução de código, cache de contexto, jobs em lote ou conversas com estado alteram a retenção?
- Logs de monitoramento de abuso, estado da aplicação, logs do gateway, registros de suporte, registros de faturamento e backups são tratados separadamente?
Para uma rota de produção, salve uma matriz de retenção de uma linha:
| Sistema | Conteúdo armazenado? | Metadados armazenados? | Período de retenção | Fluxo de exclusão | Evidência |
|---|---|---|---|---|---|
| Aplicação | Sim ou não | Sim ou não | Política interna | Processo de exclusão do app | Mapa interno de dados |
| Gateway | Sim ou não | Sim ou não | Configuração da conta ou termo do fornecedor | Painel/API/suporte | Evidência do gateway |
| Provedor A | Sim ou não | Sim ou não | Controle do provedor | Política do provedor | Documentos do provedor |
| Fallback do Provedor B | Sim ou não | Sim ou não | Controle do provedor | Política do provedor | Documentos do provedor |
| Ferramenta de suporte | Sim ou não | Sim ou não | Política de tickets | Redação/exclusão de tickets | Evidência de suporte |
A checklist de DPA do AI gateway só está completa quando cada cópia retida tem um responsável, um motivo e um fluxo de exclusão ou expiração.
Revise os Logs do Gateway Separadamente dos Termos do Provedor
Os logs do gateway são úteis para confiabilidade, controle de custos, depuração e revisão de auditoria. Eles também são uma superfície separada de processamento de dados. A documentação pública de gateways de provedores de infraestrutura mostra por que os compradores devem perguntar isso explicitamente: os logs de requisição podem incluir prompts do usuário, respostas do modelo, provedor, carimbo de data e hora, status, uso de tokens, custo, duração e metadados do cliente, e os limites de retenção de logs persistentes podem variar conforme o plano.
Faça estas perguntas sobre logging antes de assinar:
- O gateway pode armazenar prompts ou saídas completos, ou apenas metadados?
- O registro de prompts e respostas pode ser desativado por rota, ambiente, workspace ou cliente?
- Campos sensíveis podem ser omitidos, mascarados, hashados ou redigidos antes do logging?
- Os logs são copiados para analytics, data warehouses, alertas, tickets de suporte ou exports?
- Quem pode visualizar os logs, e todo acesso é registrado?
- Os logs podem ser excluídos antecipadamente, exportados para auditoria ou excluídos dos fluxos de trabalho de suporte?
- O DPA cobre os logs como dados do cliente, dados do sistema, ou ambos?
Essa é a diferença entre uma revisão jurídica de DPA e uma checklist operacional de DPA para AI gateway. Se sua política de segurança diz que prompts não devem ser armazenados, a rota deve provar que o gateway, o provedor e os fluxos de suporte seguem a mesma regra.
Verifique Suboperadores e a Troca de Provedor
Uma conta direta com o provedor normalmente tem uma cadeia principal de processamento. Um roteador de modelos pode ter uma cadeia maior porque uma rota de aplicação pode tocar um gateway, um provedor upstream, ferramentas de observabilidade, infraestrutura de pagamento, ferramentas de suporte e hospedagem em nuvem. Se o fallback estiver habilitado, uma requisição pode ir para um segundo provedor quando o primeiro falha.
O pacote de DPA deve responder:
| Pergunta sobre suboperador | O que inspecionar |
|---|---|
| Suboperadores atuais | Há uma lista publicada, e ela inclui hospedagem, provedores de modelos, suporte, analytics e fornecedores de faturamento? |
| Aviso de mudanças | Como o comprador receberá aviso sobre novos suboperadores? |
| Direitos de objeção | O comprador pode se opor, rescindir, desativar uma rota ou restringir um provedor? |
| Allowlist de provedores | O procurement pode aprovar um conjunto limitado de provedores para uma carga de trabalho específica? |
| Comportamento de fallback | O fallback pode ser desativado para rotas sensíveis? |
| Cobertura regional | Os suboperadores e as regiões dos provedores estão alinhados com os requisitos de residência de dados do comprador? |
| Fluxo contratual | Os compromissos dos suboperadores cobrem confidencialidade, segurança, exclusão e suporte a incidentes? |
Para compradores do Flatkey, combine a evidência pública da rota e de preços com controles específicos da conta. Se sua rota usa uma chave única em vários modelos, a evidência do DPA ainda precisa indicar quais provedores upstream podem processar cada classe de dados aprovada.
Peça Evidências de Suporte, Incidentes e Auditoria
O acesso ao suporte é fácil de ignorar porque geralmente acontece depois que algo quebra. Para uma revisão de DPA de gateway, o suporte faz parte do processamento.
Solicite:
- O contato de suporte e o fluxo de escalonamento para incidentes de segurança ou privacidade.
- Se a equipe de suporte pode visualizar prompts, saídas, logs, arquivos enviados, capturas de tela ou metadados do cliente.
- Se o acesso do suporte é limitado por tempo, aprovado e registrado.
- Se registros de transparência de acesso estão disponíveis para contas elegíveis.
- Como os tickets de suporte são redigidos quando contêm exemplos de prompt ou de saída.
- Qual prazo de notificação de incidentes se aplica sob o DPA, os termos, o SLA ou o adendo de segurança.
- Se o fornecedor ajudará com solicitações de titulares de dados, exclusão, exportação e consultas de reguladores.
O AI Risk Management Framework do NIST é útil aqui como referência de governança porque incentiva as organizações a governar, mapear, medir e gerenciar riscos de IA, em vez de aprovar um encaminhamento uma vez e esquecê-lo. Para um roteador de modelos, isso significa que a revisão do DPA deve ser renovável. Defina uma data de revisão, atribua responsáveis pelas evidências e reavalie os termos do provedor antes de grandes mudanças de rota.
Monte o Pacote de Evidências
O resultado prático é um pequeno pacote de evidências que as equipes jurídica, de segurança, de compras e de plataforma possam ler.
| Item do pacote | Arquivo ou registro a salvar |
|---|---|
| Resumo da rota | Carga de trabalho, proprietário, endpoint, classe de dados, provedores aprovados, comportamento de fallback |
| DPA | Acordo de processamento de dados assinado e qualquer adendo de segurança ou regional |
| Mapa de dados | Fluxo de prompt/saída da aplicação para o gateway para o provedor para logs/suporte |
| Matriz de retenção | Retenção do gateway, provedor, aplicação, suporte, cobrança e backups |
| Evidência de subprocessadores | Lista atual de subprocessadores e processo de notificação de mudanças |
| Controles de conta | Aprovação ZDR/MAM, residência de dados, configurações de logging, allowlist de rotas, configurações de redaction |
| Amostra de log | Exemplo redigido mostrando os campos armazenados, não segredos |
| Fluxo de exclusão | Como conteúdo, arquivos, logs, tickets e registros da conta são excluídos ou devolvidos |
| Fluxo de incidentes | Prazo de notificação, contato, escalonamento e evidências disponíveis após um evento |
| Decisão de aprovação | Revisores, exceções, data de expiração e gatilhos de mudança de rota |
Para a Flatkey, adicione evidências públicas atuais da página inicial, política de privacidade, página de preços, termos, SLA e do painel da conta. As páginas públicas podem ajudar compradores a avaliar o serviço, mas evidências específicas da conta devem orientar a decisão final.
Sinais de alerta que devem pausar a aprovação
Pare a revisão da rota quando qualquer um destes pontos não estiver resolvido:
- O DPA nomeia o fornecedor do gateway, mas não o caminho do provedor de modelo a montante.
- O fallback pode enviar dados sensíveis para um provedor não aprovado.
- Os logs de prompt ou de saída estão ativados, mas o DPA ou a revisão de segurança não os cobre.
- O fornecedor diz "sem treinamento", mas não consegue responder sobre retenção, acesso do suporte, exclusão ou subprocessadores.
- O ZDR é prometido de forma ampla, mas o endpoint, recurso ou conta selecionados não são elegíveis.
- Tickets de suporte podem incluir prompts brutos sem um processo de redaction.
- Mudanças de subprocessadores não têm caminho de notificação.
- O roteamento regional é assumido, mas não comprovado por contrato, configuração da conta ou evidência de uso.
- Preços, logs e exportações de uso contêm identificadores de clientes que não foram incluídos no mapa de dados.
- A aprovação não tem proprietário nem data de revisão.
Esses sinais de alerta nem sempre significam que o fornecedor é inutilizável. Eles significam que a checklist de DPA do AI gateway não está concluída.
Como é uma boa aprovação
Um registro de aprovação forte é curto e testável:
| Campo de aprovação | Exemplo de redação |
|---|---|
| Escopo | "Rota de triagem de suporte em produção, prompts apenas de texto, sem upload de arquivo, apenas provedores aprovados A e B." |
| Classe de dados | "Texto de suporte ao cliente após redaction de segredos e dados de pagamento no nível da aplicação." |
| Logging | "O gateway armazena apenas metadados. A aplicação armazena transcrição redigida por 30 dias. A retenção do provedor segue o controle de conta aprovado." |
| Restrições | "Sem busca na web, upload de arquivos, entrada de imagem, upload em lote ou fallback fora da allowlist." |
| Evidências | "DPA assinado, lista de subprocessadores salva, matriz de retenção anexada, configuração de rota exportada." |
| Renovação | "Revisar novamente antes de adicionar provedores, बदलando famílias de endpoint, ativando logs completos de prompt ou enviando dados regulados." |
Esse formato torna o DPA operacional. Os desenvolvedores sabem o que podem encaminhar. As compras sabem o que foi aprovado. A segurança sabe o que monitorar. A área jurídica tem evidências em vez de promessas dispersas.
Checklist final de DPA para AI Gateway
Antes de comprar ou expandir um roteador de modelos, confirme estes itens:
- A checklist de DPA do AI gateway nomeia a rota exata, o endpoint, a lista de provedores, a política de fallback e a classe de dados.
- O acordo de processamento de dados da API de IA cobre prompts, saídas, arquivos, logs, metadados, tickets de suporte, registros de cobrança e subprocessadores, quando aplicável.
- O logging do gateway e a retenção do provedor são revisados como sistemas separados.
- As alegações de ZDR, sem treinamento ou retenção modificada estão vinculadas à conta, projeto, endpoint e recurso exatos.
- A troca de provedores tem uma allowlist, um responsável e um gatilho de revisão.
- Exclusão, exportação, acesso do suporte, notificação de incidente e notificação de mudança de subprocessador estão documentados.
- As páginas públicas do fornecedor são tratadas como evidência de triagem datada, não como substituto do DPA assinado.
- A aprovação tem um responsável, uma data de expiração e uma regra para mudanças de rota.
Se a sua equipe quiser uma chave de API e um painel para acesso a vários modelos, comece com a Flatkey e mantenha esta checklist de DPA do AI gateway ao lado da revisão técnica da rota. Obtenha uma chave, confirme os controles atuais da conta e aprove cada rota com a mesma disciplina que você usa para qualquer outro processador de dados em produção.
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
- Orientação do ICO sobre contratos
- Controles de dados da OpenAI
- Adendo de Processamento de Dados da OpenAI
- API da Anthropic e retenção de dados
- retenção zero de dados da API para desenvolvedores do Gemini
- Registro de logs do Cloudflare AI Gateway
- Preços e logs persistentes do Cloudflare AI Gateway
- Estrutura de Gestão de Riscos de IA do NIST
