No momento em que o gateway loga prompts e completions, ele passa a guardar o que quer que o usuário de um agente de atendimento tenha digitado em uma caixa de chat, o que pode incluir um endereço, um número de conta ou uma reclamação sobre a própria saúde. Toda outra decisão desta série trocou custo por latência ou controle por conveniência. Esta troca a capacidade de debugar por uma obrigação de proteção de dados, e é a última porque é a que precisa de todo o resto já no lugar. A Parte 9 fez a plataforma chegar à produção. Esta parte fecha a série: o que registrar, o que observar, o que a regulação pede, e se os números da Parte 1 de fato se moveram.

Três camadas, e a que você mesmo constrói

A plataforma agora emite de três lugares, e misturá-los é como times acabam com três dashboards que discordam entre si.

  • Gateway telemetry. Métricas de tokens no Application Insights com as dimensões de tenant, alias de modelo e ambiente da Parte 5, mais logs de requisição no Azure Monitor. Esta é a visão autoritativa de quem chamou o quê e quanto custou, e é a única camada que vê toda requisição síncrona.
  • Telemetria de aplicação. Os traces da própria camada de orquestração: quais tools rodaram, quantas iterações de loop, quais documentos recuperados entraram no prompt. Ferramentas específicas de LLM como LangSmith ou Openlayer vivem aqui, e um time de data science que já usa Dataiku vai querer sua própria visão dos mesmos dados. Nenhuma delas vê tráfego que não passa pela aplicação que as emite, o que vale dizer em voz alta sempre que alguém propõe uma delas como fonte de verdade da plataforma.
  • Sinais de modelo e de segurança. Bloqueios de content safety, recusas, categorias de filtro acionadas. Eles vêm da policy do gateway e pertencem à camada do gateway, não à da aplicação, porque o ponto inteiro é que eles se mantêm mesmo quando a aplicação se comporta mal.

A camada que o time de plataforma possui e que ninguém mais vai construir é o join: um correlation ID que segue uma interação de usuário pelas três camadas, de modo que uma única pergunta que disparou quatro tool calls e um bloqueio de content safety seja uma coisa só em uma query, em vez de seis registros sem relação. A Parte 8 colocou esse ID no registro de log. Era para isso que ele servia.

O que logar, e o que não logar

Logar prompts e completions é genuinamente útil: é assim que você debuga uma resposta ruim, constrói o golden set a partir de tráfego real e prova o que o sistema disse quando alguém contesta. Também transforma o log store em um repositório de conteúdo gerado por usuários, de sensibilidade desconhecida, replicado para onde quer que esses logs vão.

A posição viável é por produto em vez de global, e é uma decisão que o time consumidor toma junto com a plataforma, não uma que a plataforma toma por todos:

  • Sempre logue os metadados: tenant, alias, deployment e versão resolvidos, contagens de tokens, latência, status, cache hit, resultado do content safety, correlation ID. Nada disso é conteúdo de usuário e tudo isso responde às perguntas operacionais.
  • Logue conteúdo por exceção, com uma retention mais curta que a dos metadados, restrita aos produtos que optaram por isso, e com a subscription key removida da requisição como a Parte 5 exigiu.
  • Faça sampling em vez de capturar tudo onde o logging de conteúdo está ligado. Uma amostra representativa debuga tão bem quanto uma captura completa para a maioria dos propósitos e reduz a exposição proporcionalmente.

Escreva os períodos de retention e a base legal no mesmo documento do modelo de chargeback. Uma plataforma que consegue dizer precisamente o que guarda, por quanto tempo e por quê, sobrevive a uma revisão de proteção de dados. Uma que não consegue vai ouvir que deve desligar o logging por completo, o que custa muito mais.

Evals em produção, não só no pipeline

O eval gate da Parte 9 responde "esta mudança é segura para enviar". Ele não responde "o sistema continua bom", porque o tráfego de produção não é o golden set e se afasta dele continuamente.

Dois mecanismos, e eles respondem perguntas diferentes. Evals agendados rodam o golden set contra a configuração de produção em um timer, o que pega drift em coisas que ninguém deployou: uma versão de modelo que se moveu apesar do pin, um índice que reindexou diferente, um caminho de retrieval que ficou mais lento. Avaliação online amostrada pontua uma fatia pequena do tráfego real, geralmente com um model-as-judge, e é o único jeito de notar uma classe de falha que o golden set nunca conteve, porque o golden set é, por definição, feito de falhas que você já conhecia.

Os dois precisam de um lugar para colocar o resultado, e é o mesmo lugar de todo o resto: um score com as dimensões de tenant e alias, no mesmo dashboard de gasto e latência. Um número de qualidade que vive em uma ferramenta separada é olhado durante incidentes e ignorado o resto do tempo.

Governança, e o que a regulação de fato pede

Sob o EU AI Act, a maior parte do que esta empresa roda é de risco limitado, não de alto risco, e as obrigações que decorrem disso são majoritariamente sobre transparência e rastreabilidade, não sobre certificação. Isso não é motivo para tratar governança como um exercício de documentação, porque as perguntas que um auditor faz mapeiam quase exatamente para coisas que a plataforma registra ou não registra.

  • Quais modelos estão em uso, em quais aplicações, em quais versões? O model catalog e o mapa de aliases respondem isso. Sem eles, vira um levantamento manual.
  • Quais dados foram para qual provedor, e onde foram processados? A configuração do backend pool e os logs de requisição respondem por requisição, o que também é a resposta para uma pergunta de residência de dados sobre uma região específica.
  • Quais controles de segurança estavam em vigor, e eles dispararam? A policy de content safety é versionada no repositório e seus resultados são logados por requisição.
  • Quem podia chamar o quê, e quando isso mudou? A configuração de tenants é Terraform, então a resposta é um histórico de git em vez de uma lembrança.
  • Uma interação específica pode ser reconstruída? Só se o logging de conteúdo estava ligado para aquele produto, que é exatamente por que essa decisão é por produto e escrita, em vez de implícita.

O ponto que vale levar: o gateway é o que torna essas perguntas respondíveis. Cinco aplicações chamando cinco endpoints de modelo diretamente podem produzir cinco respostas diferentes para cada pergunta, e o esforço de reconciliá-las é o custo de compliance que o investimento na plataforma removeu.

O placar

A Parte 1 definiu cinco metas. Pontuação honesta, incluindo a que não fechou limpa.

  • Todo product owner vê seu próprio gasto de tokens em até um dia. Atingida, com as classes de precisão da Parte 3 declaradas no relatório: exato para não-streamed e batch, estimado para streamed, com um residual publicado.
  • Nenhuma aplicação guarda uma credencial de modelo de longa duração. Atingida. As aplicações guardam uma client credential do Entra ID e uma subscription key de produto; nenhuma das duas chega a um endpoint de modelo, e revogação é uma mudança de configuração.
  • Um aviso de aposentadoria produz uma query, não uma investigação. Atingida, e precisou de três decisões anteriores em vez de uma ferramenta: versões fixadas, aliases e o logging por requisição do deployment resolvido.
  • Um tenant não consegue esgotar a quota de outro. Atingida para tráfego síncrono, via counter keys por subscription. Batch é limitado pelo control plane ser o único submissor, o que é um controle de processo em vez de um controle imposto tecnicamente, e essa lacuna deve ser nomeada em vez de suavizada.
  • Latência do gateway abaixo de 60 ms no percentil 95 para chamadas não cacheadas. Esta é a que se mede em vez de assumir, e é o número mais sensível a escolhas feitas por outras razões: o check de content safety adiciona uma chamada antes do modelo, o lookup do cache semântico adiciona uma chamada de embedding, e ambos foram adotados por boas razões que custam milissegundos. Uma plataforma que adicionou tudo isso sem medir de novo mudou silenciosamente o próprio SLO.

O que isso custou, e quando não vale a pena

A série seria desonesta sem esta seção. Um gateway central é um time de plataforma, uma instância de API Management em um tier escolhido por causa de um schema e não da carga, um cache Redis com um módulo que não pode ser adicionado depois, um deployment de embeddings servindo a dois propósitos, e um control plane que é um serviço de verdade com on-call de verdade. Isso é um custo permanente, e ele compra atribuição, governança e uma história de ciclo de vida.

Abaixo de aproximadamente três aplicações consumidoras, não vale a pena. O custo de coordenação que o gateway remove ainda não existe, e a mesma disciplina pode ser obtida com um módulo Terraform compartilhado e uma convenção. O limiar não é um número de tokens, é o ponto em que uma mudança em como os modelos são acessados exige que mais de um time aja. É aí que a segunda porta começa a custar mais do que a primeira custou.

Leia isso a seguir

Para o lado de infraestrutura e plataforma de rodar isso em escala, as notas de campo estão em ercan.cloud, e o hub fica em ercanermis.com.

Referências