Copilot Credits: como controlar o custo dos agentes de IA

A licença deixou de ser um teto fixo de gasto

Durante muito tempo, comprar Microsoft 365 Copilot era uma decisão simples de orçamento: um valor fixo por usuário, por mês, sem surpresa na fatura. Esse modelo ainda existe, mas parou de cobrir tudo o que a organização faz com IA generativa dentro do tenant. Agentes de Copilot Studio que passam da cota incluída, execuções do Copilot Cowork e chamadas às Work IQ APIs consomem um recurso separado, medido e cobrado à parte: os Copilot Credits.

Isso muda a natureza da conversa. Licenciamento de Copilot deixou de ser uma linha fixa de TI e virou uma linha variável, sensível a comportamento de uso. Quem trata isso como detalhe de contrato vai ser pego de surpresa na primeira fatura de um mês com picos de adoção de agentes. Quem entende o mecanismo de consumo consegue prever custo, negociar o plano certo e evitar que um agente mal desenhado drene orçamento sem gerar valor proporcional.

O que exatamente consome Copilot Credits

Antes de discutir plano de compra, é preciso mapear onde o consumo realmente acontece. Não é o Copilot Chat dentro do Word ou do Outlook que pesa aqui, essa experiência continua coberta pela licença por usuário. O consumo de Credits aparece em três frentes.

Copilot Studio: agentes que ultrapassam a cota incluída

A licença de Microsoft 365 Copilot traz uma cota mensal de mensagens de Copilot Studio por usuário licenciado. Enquanto o uso fica dentro dessa cota, não há cobrança adicional. O problema começa quando um agente vira sucesso interno, passa a ser usado por gente que não tem a licença Copilot, ou simplesmente ultrapassa o volume previsto. A partir daí, cada mensagem processada pelo agente debita Credits, e o valor debitado varia conforme o tipo de resposta gerada, não é um custo fixo por interação.

Copilot Cowork: agentes autônomos de múltiplas etapas

Diferente de um agente conversacional que responde a uma pergunta e encerra, o Cowork foi desenhado para conduzir tarefas de múltiplas etapas em nome de um usuário, orquestrando chamadas a ferramentas, conectores e modelos ao longo de uma execução. Cada etapa da tarefa consome Credits proporcionalmente ao esforço computacional envolvido. Uma tarefa que pesquisa, cruza dados de duas fontes e produz um documento final custa mais do que uma consulta simples, porque o motor de orquestração faz várias chamadas de modelo internamente antes de entregar o resultado.

Work IQ APIs: grounding fora do Copilot Chat

As Work IQ APIs expõem, via Microsoft Graph, o mesmo mecanismo de grounding que alimenta o Copilot Chat, o índice semântico que cruza e-mails, arquivos, conversas e conteúdo do usuário. Quando uma aplicação personalizada, um agente de Copilot Studio ou uma automação em Power Automate chama essas APIs para enriquecer uma resposta com contexto organizacional, essa chamada também consome Credits. Isso importa especialmente para quem está construindo soluções próprias sobre a plataforma: o custo de grounding precisa entrar na equação de arquitetura desde o desenho, não ser descoberto depois em produção.

Por que o custo de cada interação varia

Um erro comum é assumir que existe um preço fixo por “mensagem” ou por “execução de agente”. Não existe. O débito de Credits reflete a complexidade real do processamento: quantidade de chamadas ao modelo de linguagem, uso de orquestração generativa versus tópicos determinísticos, acionamento de conectores premium, volume de contexto recuperado no grounding e número de etapas que o agente percorre até concluir a tarefa.

Na prática, dois agentes que parecem fazer a mesma coisa do ponto de vista do usuário final podem ter custos muito diferentes dependendo de como foram construídos. Um agente com tópicos clássicos, fluxo determinístico e poucas chamadas externas custa uma fração de um agente equivalente montado com orquestração generativa aberta, mesmo que a experiência percebida seja parecida. Essa diferença de arquitetura é o primeiro lugar onde dá para economizar sem cortar funcionalidade.

Como dimensionar o consumo antes de aprovar orçamento

Dimensionar Copilot Credits antes de comprometer orçamento evita dois erros simétricos: comprar prepago demais e deixar crédito expirar sem uso, ou ficar exposto ao preço cheio de pay-as-you-go em um mês de pico. O caminho é tratar isso como qualquer exercício de capacity planning.

• Inventarie os agentes ativos. Levante todos os agentes publicados em Copilot Studio, classifique cada um por tipo de orquestração (clássica ou generativa) e por dependência de conectores premium ou Work IQ APIs.
• Meça o consumo real, não o estimado. Use os relatórios de analytics do Copilot Studio para ver sessões, mensagens e custo médio por conversa nos últimos ciclos. Estimativa feita antes do agente entrar em produção quase sempre erra para baixo.
• Identifique sazonalidade e picos. Agentes de atendimento interno tendem a ter picos previsíveis (fechamento de mês, período de matrícula, safra de vendas). Um plano dimensionado pela média mensal quebra exatamente no dia em que o agente é mais necessário.
• Calcule um buffer, não um valor exato. Dimensione a compra prepaga para cobrir a carga previsível e deixe o excedente de pico para pay-as-you-go. Isso evita comprar um plano grande demais para cobrir um pico que só acontece três vezes por ano.

Pay-as-you-go ou plano prepago: como decidir

A Microsoft oferece duas formas de pagar por Copilot Credits além da cota incluída na licença: consumo sob demanda, faturado por uso real e vinculado a uma assinatura do Azure no tenant, ou compra antecipada de blocos de créditos em planos de pré-compra, com tiers de compromisso que costumam ser referenciados como P1, P2 e P3 conforme o volume contratado. Cada modelo tem um perfil de risco diferente.

Quando pay-as-you-go faz sentido

Faz sentido em qualquer cenário onde o padrão de consumo ainda não está estável: um agente de Copilot Studio recém-lançado, um piloto de Cowork em uma área específica, ou uma integração via Work IQ APIs que ainda está em fase de validação de valor. Pagar por uso real, mesmo a um preço unitário mais alto, é mais barato do que comprometer um volume prepago baseado em uma estimativa que ainda não foi testada em produção.

Quando vale comprometer um plano prepago

Depois que o consumo se estabiliza e os relatórios de analytics mostram um padrão recorrente de uso mês a mês, migrar para um plano prepago no tier adequado (P1 para volumes menores, subindo até P3 para operações com muitos agentes ou uso intenso de Cowork) reduz o custo por crédito de forma consistente. A pegadinha aqui é o horizonte de expiração: créditos prepagos costumam ter validade dentro do ciclo contratado, e o excedente não usado não acumula indefinidamente. Comprar um tier maior do que o consumo real justifica é dinheiro parado, não economia.

Governança de gasto no admin center

Comprar o plano certo resolve metade do problema. A outra metade é impedir que o consumo saia do controle depois que os agentes já estão em produção e sendo usados por dezenas ou centenas de pessoas.

Segregação por ambiente

Ambientes de desenvolvimento e teste no Power Platform não deveriam competir pelo mesmo saldo de Credits que sustenta agentes de produção. No Power Platform admin center, em Recursos, Capacidade e Add-ons, é possível visualizar o consumo por ambiente e, com a estrutura certa de capacity add-ons, isolar o orçamento de testes do orçamento de produção. Sem essa segregação, um teste de carga esquecido em ambiente de desenvolvimento pode consumir o saldo que deveria durar o mês inteiro em produção.

Alertas e limites de gasto

No Microsoft 365 admin center, na seção de Billing, o saldo e o histórico de consumo de Copilot Credits ficam visíveis para quem tem papel de Billing Administrator ou Global Administrator. Configurar alertas de limiar de consumo é o equivalente a um orçamento com trava: em vez de descobrir o estouro na fatura do mês seguinte, o time de TI recebe aviso quando o consumo atinge um percentual definido do saldo disponível, com tempo hábil para investigar qual agente está puxando o gasto para cima.

Separação de papéis entre orçamento e criação de agentes

Quem compra Credits normalmente não é quem constrói agentes, e essa separação de papéis precisa ser deliberada, não acidental. Makers no Power Platform têm liberdade para publicar agentes e habilitar orquestração generativa sem necessariamente enxergar o impacto financeiro dessa escolha de arquitetura. Um processo de governança maduro exige aprovação de um responsável por FinOps antes de um agente com alto potencial de consumo (orquestração generativa aberta, uso intensivo de Work IQ APIs, execuções longas de Cowork) ir para produção com acesso amplo na organização.

O erro mais caro: orquestração generativa habilitada por padrão

Boa parte do estouro de Credits que aparece em auditorias de consumo não vem de má-fé nem de uso malicioso. Vem de agentes configurados com orquestração generativa porque essa é a opção mais fácil de montar no Copilot Studio, mesmo quando o caso de uso seria perfeitamente atendido por tópicos clássicos e determinísticos, muito mais baratos por interação. Antes de publicar um agente para uso amplo, vale perguntar se a flexibilidade da orquestração generativa é realmente necessária para aquele fluxo, ou se um desenho mais estruturado entrega o mesmo resultado a um custo previsível e menor.

Tratando Copilot Credits como linha de FinOps

O ponto central de tudo isso é reconhecer que Copilot Credits não é mais um detalhe de licenciamento, é uma linha de custo operacional variável, que precisa de dono, de relatório periódico e de revisão de arquitetura como qualquer outro gasto de nuvem. Atribuir consumo a centro de custo por ambiente, revisar agentes órfãos que ninguém mais usa mas continuam publicados, e reavaliar trimestralmente se o tier de plano prepago ainda corresponde ao padrão real de uso são práticas de FinOps aplicadas à Power Platform, não burocracia extra.

Organizações que chegam a esse nível de maturidade tratam o dimensionamento de Credits com a mesma disciplina que já aplicam a reservas de instância no Azure ou a licenciamento por consumo em outras plataformas. As que não chegam tendem a descobrir o problema tarde, geralmente na forma de uma fatura que não bate com a expectativa e de um agente que ninguém sabe direito por que está consumindo tanto.

Mapear consumo, escolher o mix certo entre pay-as-you-go e plano prepago, e estruturar governança no admin center são decisões de arquitetura, não apenas de compras. É o tipo de definição que vale revisar com quem já desenhou esse tipo de operação antes de escalar o uso de agentes de IA para o resto da organização.