A Microsoft confirma com seus próprios números (30 milhões de assentos Copilot): não é mais a adoção que separa as empresas que avançam — é a adaptação setor por setor, o que a AppManager já faz por construção
Num post de 30 de julho assinado por sua CMO «AI at Work», a Microsoft publica seus próprios dados de telemetria do Copilot: 30 milhões de assentos pagos, um uso que dobra a cada ano — e uma confissão rara vinda de uma fornecedora: dar a mesma ferramenta a todo mundo é o padrão errado. O que a Microsoft não diz, porque não é seu papel: a maioria das PMEs não tem nem nove engenheiros nem um framework de ajuste próprio para fazer essa adaptação sozinha.
Em seu post de 30 de julho «The next measure of AI momentum is work transformed», Jared Spataro (Chief Marketing Officer, AI at Work na Microsoft) publica números extraídos diretamente da última publicação trimestral do grupo: o Microsoft 365 Copilot ultrapassa 30 milhões de assentos pagos, com um ritmo de adição de assentos que mais que dobrou de um trimestre para outro, e um engajamento semanal agora comparável ao do Outlook ou do Teams. O post também documenta o Copilot Cowork, um agente capaz de completar sozinho um ciclo inteiro (planejar, executar, testar, corrigir), construído por uma equipe que nunca passou de nove engenheiros e, ainda assim, já usado pela metade da Fortune 500 seis meses após seu lançamento. Mas a frase mais importante do post não é um número: «a diferença entre as empresas que veem esse tipo de mudança e as que ainda esperam não é a amplitude da implantação — é a qualidade da adaptação ao trabalho real». Em outras palavras: o padrão de implantação mais comum (dar a mesma ferramenta a todo mundo) é explicitamente apresentado como o padrão errado, pela própria fornecedora que vende essa ferramenta genérica.
O post também cita dois casos concretos em que a automação permanece sob controle humano explícito em grande escala: o Autonomous Sourcing Agent da EY negocia com fornecedores em mais de 200 transações reais «mantendo os humanos no circuito para validação e escalonamento»; o agente de qualidade da Eaton analisou cerca de 5.000 relatórios de produção «mantendo a equipe de especialistas da Eaton no centro de cada decisão». São exatamente as palavras que nós mesmos usamos desde o primeiro módulo da AppManager, não um achado recente de comunicação — só que esses dois casos operam num volume (milhares de transações, milhares de relatórios) que uma PME cliente da AppH nunca vai ver, e não precisa ver para que o princípio se aplique.
A favor da AppH
- A constatação da Microsoft — se adaptar setor por setor em vez de implantar uma ferramenta genérica — descreve exatamente a arquitetura que a AppManager tem desde o primeiro módulo: Odontologia, Ótica, Fisioterapia, Hospital, Frota, Spa, Turismo, Escola não compartilham um mesmo assistente reciclado, cada um tem sua própria lógica de status e ações.
- A aprovação humana explícita antes que um agente aja — o mesmo princípio que EY e Eaton aplicam em sua escala — não é uma caixa adicionada depois na AppH: é a condição padrão de cada módulo desde sua concepção, registrada no DECISIONS.md/na trilha de auditoria, nunca uma opção que precisa ser ativada.
Contra / o que não se aplica
- Os números citados (30 milhões de assentos, nove engenheiros, Frontier Tuning) descrevem uma capacidade de engenharia interna que a quase totalidade das PMEs não tem — isso não é prova de que uma transformação equivalente é simples de obter sem uma plataforma que faça esse trabalho de adaptação no lugar do cliente.
- A AppH não constrói um equivalente ao Microsoft Scout, o agente «piloto automático» que permanece ativo em segundo plano com sua própria identidade e suas próprias permissões — cada ação da AppManager espera uma validação humana explícita antes de ser executada, uma escolha de design assumida, não uma funcionalidade que ainda falta.
O que nos chama atenção neste post é uma honestidade rara vinda de uma fornecedora que vende justamente a ferramenta genérica sobre a qual ela mesma diz que não basta: a Microsoft admite que «dar a mesma ferramenta a todo mundo» é o padrão que não funciona, e que o que cria valor real é a adaptação setor por setor. Concordamos — é literalmente por isso que a AppManager existe em módulos separados em vez de um único assistente genérico. O que o post não diz, porque não é papel da Microsoft dizer: essa adaptação exigiu uma equipe de engenheiros dedicada, um framework de ajuste proprietário (Frontier Tuning) e um sistema de contexto interno (Work IQ) que nenhuma PME constrói sozinha num fim de semana. É exatamente essa a lacuna que a AppH deve preencher — não prometendo a mesma escala que a Microsoft, mas entregando a adaptação setor por setor sem exigir a equipe de engenheiros para obtê-la. E sobre o controle humano: notamos, com uma honestidade equivalente, que manter um humano no circuito em 200 transações de fornecedores (EY) ou 5.000 relatórios de qualidade (Eaton) é um feito de engenharia nessa escala — num cliente da AppH, o mesmo princípio se aplica a um punhado de decisões por semana, não por necessidade de recuperar a complexidade depois, mas porque esse é o tamanho real do problema desde o início.
Revisado por um humano da AppH