Checklist de Retenção de Dados da AI API: Logs, Prompts, Saídas e Registros de Faturamento

Uma checklist de retenção de dados da AI API deve responder a uma pergunta simples antes do início do tráfego de produção: quais registros existirão após uma chamada de modelo, quem pode lê-los, por quanto tempo eles permanecem e quais evidências um comprador pode revisar posteriormente?

Essa pergunta se complica rapidamente. Uma única solicitação de IA pode criar registros de prompts, registros de saídas, logs de solicitação do gateway, logs de monitoramento de abuso do provedor, eventos de auditoria, rastreamentos, entradas de cache, linhas de faturamento, tickets de suporte, exportações, capturas de tela e notas de incidentes. Alguns registros ajudam a engenharia a depurar falhas. Alguns ajudam o financeiro a reconciliar gastos. Alguns ajudam o setor de compras a provar que uma configuração do fornecedor foi revisada. Alguns não deveriam existir para cargas de trabalho sensíveis.

Use esta checklist de retenção de dados da AI API para separar esses registros antes de rotear dados reais de clientes por um gateway. O objetivo não é manter menos registros cegamente. O objetivo é manter as evidências corretas para operações, segurança, finanças e compras, sem transformar cada prompt e saída em um armazenamento de dados de longa duração.

Para compradores da Flatkey, esta revisão pertence ao arquivo de aprovação do gateway. O site público atual da Flatkey posiciona o produto como um gateway de AI API e uma plataforma de operações de modelo para acesso a modelos, roteamento, faturamento, análise de uso e controles operacionais. Isso o torna um local natural para centralizar evidências sobre rota, modelo, proprietário, uso e custo. Isso não elimina a necessidade de verificar a retenção específica da conta, os contratos do provedor e o comportamento de armazenamento de payload antes da aprovação.

Checklist de retenção de dados da AI API

Comece com a classe de registro, não com o slogan do fornecedor. “Retenção zero de dados” para um recurso de um provedor não descreve automaticamente seus logs de gateway, rastreamentos de observabilidade, livro-razão de faturamento, exportações ou fluxo de trabalho de suporte.

Esta é a checklist principal de retenção de dados da AI API: defina cada classe de registro, atribua um proprietário de retenção, comprove a configuração com uma leitura datada e defina um gatilho de renovação para cada local onde os dados podem ser copiados.

Separe a retenção do treinamento

A política de treinamento do provedor é apenas uma linha na revisão. As equipes de compras frequentemente perguntam se os dados da API são usados para treinar modelos. Isso importa, mas não responde se os prompts ou saídas são armazenados para monitoramento de abuso, estado da aplicação, recursos do produto, suporte, análise ou faturamento.

Os controles de dados da plataforma da OpenAI distinguem o treinamento de modelos, a retenção para monitoramento de abuso e a retenção de estado da aplicação. A mesma documentação diz que os logs de monitoramento de abuso podem incluir prompts e respostas e são retidos por até 30 dias por padrão, enquanto clientes elegíveis podem solicitar controles como Monitoramento de Abuso Modificado (Modified Abuse Monitoring) ou Retenção Zero de Dados (Zero Data Retention). Ela também lista exceções específicas de endpoint, incluindo estado da aplicação armazenado para algumas APIs e comportamento específico de recurso para arquivos, conversas, vídeos, cache, pesquisa na web, contêineres hospedados e outras capacidades.

A documentação de retenção de dados da API da Anthropic enquadra a Retenção Zero de Dados (Zero Data Retention) como os dados do cliente não sendo armazenados em repouso após o retorno da resposta da API, com exceções para requisitos legais, prevenção de uso indevido e armazenamento específico de recursos. Ela também observa que a elegibilidade dos recursos pode variar de acordo com a capacidade da API.

A documentação ZDR da API de Desenvolvedor do Gemini do Google diz que os prompts e respostas dos Serviços Pagos não são usados para melhorar os produtos do Google, ao mesmo tempo que descreve o registro limitado de prompts e respostas para monitoramento de abuso e armazenamento específico de recursos para certas capacidades. A página torna o ZDR uma revisão de configuração e seleção de recursos, não uma suposição universal.

A lição para o comprador é prática: mantenha as evidências da política do provedor, mas não deixe que ela substitua sua própria política de retenção de dados da AI API. O provedor pode reter uma coisa, o gateway pode reter outra e sua pilha de observabilidade pode copiar ambas.

Prompts e saídas precisam de suas próprias regras

Prompts e saídas são os registros de maior risco em um checklist de retenção de dados da AI API porque geralmente contêm as evidências de depuração mais úteis e os dados de negócios mais sensíveis.

Trate a retenção de prompts e saídas como um fluxo de trabalho de exceção:

1. Padrão para nenhum armazenamento de payload bruto para rotas de produção, a menos que uma carga de trabalho específica precise.
2. Permitir armazenamento de payload editado somente após os testes provarem que o mascaramento funciona em prompts, saídas, resultados de ferramentas, blocos de recuperação, erros e eventos de streaming.
3. Permitir armazenamento completo de payload apenas para um incidente nomeado, teste de preparação, fluxo de trabalho aprovado pelo cliente ou escalonamento do fornecedor.
4. Definir a expiração antes da coleta para que a janela de depuração não se torne armazenamento permanente.
5. Registrar o acesso aos logs de payload porque o visualizador de logs se torna um sistema sensível.
6. Manter o resumo do incidente limpo após a expiração do payload, não o prompt ou a saída brutos.

O OWASP Logging Cheat Sheet é útil aqui porque trata valores sensíveis em logs como um problema de design, não um problema de formatação. Segredos, tokens de acesso, dados pessoais sensíveis, dados de pagamento, strings de conexão, chaves de criptografia e dados de alta classificação geralmente devem ser removidos, mascarados, higienizados, hasheados ou criptografados antes do registro. Os prompts de IA podem conter todas essas categorias.

Para padrões de edição, os documentos das ferramentas apontam na mesma direção. O mascaramento do Langfuse pode editar dados antes que os dados de rastreamento saiam da aplicação. O Helicone Omit Logs foi projetado para manter métricas operacionais, omitindo os corpos de solicitação e resposta. Os controles de registro de solicitações do Portkey separam o conteúdo de solicitação/resposta do registro orientado a métricas. Mesmo que você use uma pilha diferente, o padrão é o mesmo: edite ou omita antes do armazenamento e da exportação.

Os logs de solicitação devem priorizar os metadados

Os logs de solicitação geralmente são a base das operações da AI API. Eles não precisam conter prompts brutos para serem úteis.

Para a maioria das rotas de produção, um evento que prioriza os metadados é suficiente:

{
  "request_id": "req_01jz4...",
  "timestamp": "2026-07-04T04:00:00Z",
  "environment": "production",
  "owner_key_id": "support_summarizer_prod",
  "route": "support-summary",
  "endpoint_family": "chat_completions",
  "requested_model": "approved-summary-route",
  "served_provider": "selected_by_gateway",
  "prompt_tokens": 1840,
  "output_tokens": 312,
  "status": "success",
  "latency_ms": 1420,
  "cost_usd": "0.0042",
  "payload_storage": "none",
  "retention_class": "ops_metadata_90d"
}

Esse evento suporta revisão de faturamento, correlação de incidentes, revisão de roteamento, revisão de SLO, investigação de abuso e estorno do proprietário sem reter o corpo do prompt ou o corpo da resposta.

O registro do Cloudflare AI Gateway mostra por que as decisões de registro de solicitações precisam ser explícitas. Os logs do gateway podem incluir provedor, modelo, status, uso de tokens, custo, duração, prompts, respostas e ações de política, e os controles por solicitação podem afetar se os corpos de solicitação e resposta são armazenados. Um checklist de retenção deve capturar tanto a configuração padrão do gateway quanto qualquer caminho de substituição por solicitação.

Use este checklist de log de solicitação:

É aqui que a retenção de dados da AI API se torna operacional em vez de teórica: os engenheiros ainda obtêm os registros de que precisam, enquanto os proprietários de privacidade e segurança podem ver o que é omitido intencionalmente.

Logs de auditoria não são logs de payload

Os logs de auditoria respondem quem mudou algo, quando mudou e se o caminho de controle funcionou. Eles geralmente devem sobreviver por mais tempo do que os payloads de depuração, mas não devem se tornar um armazenamento de payload de backdoor.

Um checklist de retenção de dados da AI API deve incluir eventos de auditoria para:

• Criação, rotação, desativação e exclusão de chaves de API.
• Alterações de workspace, projeto, rota, provedor e política de modelo.
• Alterações de cota, orçamento e controle de faturamento.
• Ativação, desativação e aprovações de exceção de registro de payload.
• Eventos de acesso a logs e exportações confidenciais.
• Alterações de função de administrador e concessões de permissão.
• Eventos de exportação de dados, exclusão e escalonamento de suporte.

Os logs de auditoria devem nomear o ator, o alvo, a ação, o carimbo de data/hora, o sistema de origem, a referência de aprovação e o estado antes/depois. Eles devem evitar armazenar prompts brutos, saídas brutas, chaves de API brutas, tokens de portador, dados de cartão de pagamento e dados de clientes não redigidos.

Conecte este artigo ao guia da Flatkey sobre logs de auditoria para uso da AI API quando o setor de compras precisar de um modelo de evento durável para operações de gateway. O log de auditoria deve provar que uma política de retenção foi aplicada; ele não precisa preservar o payload confidencial que acionou a política.

Registros de faturamento têm necessidades de retenção diferentes

Os registros de faturamento são fáceis de serem ignorados em um checklist de retenção de dados da AI API porque não se parecem com dados de prompt. Eles ainda são importantes.

Os registros de faturamento e financeiros podem incluir:

• IDs de chave de API, workspace, equipe, projeto, cliente ou ambiente.
• Modelo, provedor, família de endpoint e rota.
• Tokens de prompt, tokens de saída, tokens em cache, unidades de imagem/vídeo, duração ou contagem de solicitações.
• Preço unitário, preço efetivo, margem de lucro, créditos, impostos, linha da fatura, registro de recarga, reembolso e movimentação de saldo.
• Carimbo de data/hora, período de faturamento, ID da fatura, ID do provedor de pagamento e referência do livro-razão.

Esses registros geralmente precisam sobreviver por mais tempo do que os payloads de depuração, porque as equipes de finanças, impostos, suporte ao cliente e compras precisam de evidências de reconciliação. Eles ainda precisam de minimização. Um livro-razão de faturamento não deve precisar de prompts ou saídas brutas para comprovar os gastos.

Use esta tabela de retenção de faturamento:

A página de preços atual da Flatkey descreve preços de modelo transparentes, uso pré-pago, limites de cota, análise de uso, controles de custo e caminhos de revisão de faturamento. Trate-os como alegações públicas úteis de triagem e, em seguida, verifique o painel ao vivo, os termos da conta, as faturas e as exportações para seu próprio registro de comprador.

Crie um arquivo de evidências de propriedade do comprador

As páginas de confiança são úteis, mas o artefato durável deve ser de propriedade do comprador. Um revisor daqui a seis meses deve ser capaz de ver o que foi verificado na data de aprovação e o que mudou depois.

Crie uma pasta ou registro de governança com esta estrutura:

Este arquivo de evidências transforma a retenção de dados da AI API de uma alegação do fornecedor em um processo de revisão repetível. Ele também facilita as renovações, pois o revisor pode comparar o estado atual com o estado anterior em vez de recomeçar do texto de marketing.

Defina classes de retenção antes do lançamento

Não deixe que cada sistema invente seu próprio período de retenção. Defina classes de retenção e mapeie cada registro para uma delas.

retention_classes:
  ops_metadata_90d:
    stores_payload: false
    records:
      - request_id
      - route
      - provider
      - model
      - status
      - latency
      - token_usage
      - cost
    access: engineering_ops_finance_security
  debug_payload_72h:
    stores_payload: true
    approval_required: true
    redaction_required: true
    expiration_required_before_collection: true
    access: named_incident_responders
  audit_control_1y:
    stores_payload: false
    records:
      - actor
      - action
      - target
      - before_after_state
      - approval_reference
    access: security_procurement_admins
  finance_ledger_contract_term:
    stores_payload: false
    records:
      - usage
      - pricing_snapshot
      - invoice
      - recharge
      - balance_movement
    access: finance_procurement

Os períodos exatos devem vir de seus contratos, política de segurança, requisitos fiscais e compromissos com o cliente. A parte importante é que a classe exista antes do início do tráfego e que o armazenamento de payload seja visível como uma propriedade separada.

Como isso se encaixa com o Flatkey

O Flatkey pode suportar o modelo operacional porque a superfície pública do produto se concentra em um gateway de API, roteamento de modelo, visibilidade de uso, faturamento, controles de cota e revisão operacional. A verificação da API de preços em tempo real de 4 de julho de 2026 retornou success=true, 45 linhas de modelo, 48 registros de fornecedor, versão de preços a42d372ccf0b5dd13ecf71203521f9d2 e caminhos de endpoint suportados, incluindo /v1/chat/completions, /v1/messages, Gemini generateContent, geração de imagem e endpoints de vídeo.

Use o Flatkey como a superfície de evidência do gateway e, em seguida, verifique os detalhes específicos da conta que as páginas públicas não podem provar:

• Quais metadados de solicitação o Flatkey armazena.
• Se os corpos brutos de prompt e resposta são armazenados.
• Se o armazenamento de payload pode ser desativado, ter escopo definido, ser redigido ou ter tempo limitado.
• Quais eventos de auditoria estão disponíveis para chaves, rotas, cota, faturamento e acesso a logs.
• Quais exportações de faturamento estão disponíveis para reconciliação financeira.
• Quais configurações de retenção do provedor se aplicam por trás de cada rota.
• Quais caminhos de suporte, exportação e observabilidade podem copiar dados de solicitação.

Essa distinção é importante. Um gateway pode simplificar as operações e a coleta de evidências, mas o comprador ainda é o proprietário do checklist final de retenção de dados da AI API.

Execute um teste de retenção de pré-produção

Antes de aprovar uma rota de produção, execute o checklist em uma carga de trabalho de teste.

1. Envie uma solicitação normal e confirme se o log de metadados aparece sem o corpo do prompt ou da saída.
2. Envie uma solicitação contendo dados de teste sensíveis pré-definidos, como e-mails, strings com formato de token de acesso, IDs de conta, valores semelhantes a pagamentos e marcadores de código proprietário.
3. Confirme se esses dados de teste não aparecem em logs, rastreamentos, alertas, exportações de suporte ou registros de faturamento, a menos que a rota tenha entrado explicitamente em uma via de depuração aprovada.
4. Habilite uma exceção de payload de depuração com escopo definido em um ambiente de não produção e verifique a aprovação, o registro de acesso, a redação e a expiração.
5. Expurgue ou aguarde o período de retenção de depuração e confirme se a releitura não retorna mais o payload.
6. Obtenha um evento de auditoria para a alteração da política de registro e o expurgo.
7. Obtenha uma linha de faturamento ou uso e confirme se ela é reconciliada sem o conteúdo do payload.
8. Registre capturas de tela, leituras de API, carimbos de data/hora, IDs de conta e nomes de revisores no arquivo de evidências.

Este teste detecta a falha comum: uma equipe desativa o armazenamento de payload no gateway, mas ainda vaza o texto do prompt por meio de um exportador de rastreamento, mensagem de alerta, tíquete de suporte ou captura de tela de depuração.

Onde isso se encaixa na revisão de confiança

A retenção de dados da AI API é uma parte de uma revisão mais ampla do gateway. Use o checklist de gateway de AI API empresarial para cobrir acesso, roteamento, faturamento, cotas e propriedade operacional. Use a avaliação de risco de fornecedor de AI API para comparar contratos de provedores upstream e processadores de terceiros. Use o guia de logs de auditoria para uso de AI API quando o setor de compras perguntar como um gateway prova quem alterou chaves, rotas, cotas e política de registro.

Essas revisões devem se conectar. O checklist do gateway mostra a superfície de controle. A avaliação de risco do fornecedor mostra o contrato upstream e o limite de dados. O guia de log de auditoria mostra evidências administrativas duráveis. Este checklist de retenção de dados da AI API mostra o que fica para trás após cada solicitação.

FAQ

O que é retenção de dados da AI API?

Retenção de dados da AI API é a política e o comportamento do sistema que determinam por quanto tempo prompts, saídas, logs de metadados, eventos de auditoria, rastreamentos, linhas de faturamento, registros de suporte e registros do lado do provedor são armazenados após uma solicitação de AI API.

Retenção zero de dados é o mesmo que ausência de logs?

Não. A retenção zero de dados geralmente descreve um controle específico do provedor ou do recurso para o conteúdo do cliente. Pode não cobrir metadados de gateway, logs de auditoria, registros de faturamento, exportações de observabilidade, tíquetes de suporte ou todos os recursos do provedor. Sempre verifique o escopo e as exceções.

Prompts e saídas devem ser armazenados para depuração?

Apenas por exceção. Os logs de metadados devem ser o padrão para o tráfego de produção. Armazene payloads redigidos ou completos apenas para fluxos de trabalho aprovados, incidentes com escopo definido, testes de preparação ou vias aprovadas pelo cliente, e defina a expiração antes da coleta.

Por quanto tempo os logs de solicitação da AI API devem ser mantidos?

Não há um período universal. Os logs de metadados geralmente precisam de tempo suficiente para revisão de incidentes, reconciliação de faturamento e investigação de abuso. Payloads brutos de prompt e saída geralmente devem ter uma retenção muito mais curta do que metadados, logs de auditoria ou registros de faturamento.

Que registros de faturamento são importantes para a retenção da AI API?

Mantenha linhas de uso, contagens de tokens, identificadores de modelo/provedor, instantâneos de preços, faturas, registros de recarga, reembolsos e mapeamentos de proprietários como evidência financeira. Esses registros não devem exigir os corpos brutos dos prompts ou das saídas.

O que o setor de compras deve perguntar a um fornecedor de gateway?

Peça evidências datadas de metadados de solicitação, comportamento de armazenamento de payload, redação, exclusão, logs de auditoria, controles de acesso, exportações de faturamento, configurações de retenção do provedor e destinos de exportação de terceiros. Em seguida, compare essa evidência com sua própria política de classificação de dados e resposta a incidentes.

Conclusão

Uma checklist de retenção de dados da AI API transforma alegações vagas de confiança em um arquivo operacional revisável. Separe prompts de saídas, logs de solicitação de logs de auditoria e registros de faturamento de payloads de depuração. Mantenha metadados por padrão, armazene payloads brutos apenas em casos excepcionais, teste a redação antes do armazenamento e preserve evidências datadas para renovações. Quando estiver pronto para centralizar o acesso, uso, faturamento e roteamento de modelos por meio de uma única superfície de gateway, revise o atual catálogo de preços e modelos da Flatkey e, em seguida, obtenha uma chave.