{"id":14356,"date":"2026-05-27T15:09:28","date_gmt":"2026-05-27T15:09:28","guid":{"rendered":"https:\/\/cheesecakelabs.com\/blog\/como-escalar-ia-na-empresa\/"},"modified":"2026-08-15T06:58:52","modified_gmt":"2026-08-15T06:58:52","slug":"como-escalar-ia-na-empresa","status":"publish","type":"post","link":"https:\/\/cheesecakelabs.com\/blog\/br\/como-escalar-ia-na-empresa\/","title":{"rendered":"Escalando IA: um caminho de 6 meses dos champions at\u00e9 a empresa inteira"},"content":{"rendered":"\n

A cada dois meses eu recebo uma vers\u00e3o da mesma liga\u00e7\u00e3o. Um CTO liberou o Claude Code ou o Cursor para o time de engenharia, pagou as licen\u00e7as, rodou um treinamento e, tr\u00eas meses depois, ningu\u00e9m consegue apontar um n\u00famero que mostre que o investimento se pagou. A pergunta \u00e9 sempre a mesma: o que deu errado?<\/strong><\/p>\n\n\n\n

O que deu errado \u00e9 a premissa embutida no rollout. “Adotar IA” est\u00e1 sendo tratado como uma decis\u00e3o de compra: escolher um fornecedor, comprar assentos, mandar o e-mail e ver a produtividade subir. Os fornecedores incentivam essa leitura porque vendem licen\u00e7as, n\u00e3o redesenho organizacional. O CTO comprou o que estava \u00e0 venda.<\/p>\n\n\n\n

O trabalho de verdade \u00e9 organizacional. Leva no m\u00ednimo seis meses, tem fases que precisam acontecer em ordem e se parece muito mais com implantar um novo modelo operacional do que uma nova ferramenta. Os times que est\u00e3o saindo na frente em 2026 n\u00e3o s\u00e3o os que t\u00eam mais licen\u00e7as: s\u00e3o os que fizeram isso mais devagar, em escala menor e na sequ\u00eancia certa.<\/p>\n\n\n\n

Os n\u00fameros n\u00e3o mentem, e a maioria das empresas est\u00e1 lendo errado<\/h2>\n\n\n\n

Tr\u00eas pesquisas p\u00fablicas chegam \u00e0 mesma conclus\u00e3o por caminhos diferentes.<\/p>\n\n\n\n

A Writer’s 2026 Enterprise AI Adoption Survey<\/a> entrevistou 1.200 executivos de C-level e 1.200 profissionais de \u00e1reas n\u00e3o t\u00e9cnicas. 97% dos executivos afirmam que a empresa colocou agentes de IA para rodar nos \u00faltimos 12 meses. 29% enxergam ROI significativo com IA generativa, e 23% com agentes especificamente. A frase mais forte do relat\u00f3rio: 54% dos l\u00edderes de C-level dizem que adotar IA est\u00e1 “despeda\u00e7ando a empresa”.<\/p>\n\n\n\n

O relat\u00f3rio de novembro da McKinsey, 2025 State of AI<\/a>, chega ao mesmo desenho pelo lado operacional. 88% das organiza\u00e7\u00f5es j\u00e1 usam IA em pelo menos uma fun\u00e7\u00e3o de neg\u00f3cio, contra 78% em 2024. 39% atribuem algum n\u00edvel de impacto no EBIT \u00e0 IA.<\/p>\n\n\n\n

Cerca de 6% se qualificam como high performers<\/strong>, ou seja, impacto no EBIT acima de 5%.<\/strong> A vari\u00e1vel que mais se correlaciona com esse status \u00e9 o redesenho de workflows, e apenas 21% das organiza\u00e7\u00f5es fizeram isso.<\/p>\n\n\n\n

O DORA 2025 Accelerate State of DevOps Report<\/a> acrescenta um terceiro \u00e2ngulo. 90% dos profissionais de software usam IA no dia a dia, com mediana de duas horas di\u00e1rias em ferramentas de IA<\/a>, e 80% relatam ganhos de produtividade. Mas a conclus\u00e3o principal \u00e9 esta: a IA amplifica o que j\u00e1 existe. Pr\u00e1ticas maduras de DevOps convertem os ganhos de IA em performance de entrega. Pr\u00e1ticas fracas s\u00e3o amplificadas na dire\u00e7\u00e3o oposta, \u00e0s vezes com resultados mensuravelmente piores depois da ado\u00e7\u00e3o.<\/p>\n\n\n\n

Tr\u00eas lentes, uma conclus\u00e3o: o modelo n\u00e3o \u00e9 o gargalo, as licen\u00e7as n\u00e3o s\u00e3o a alavanca, e o trabalho est\u00e1 em tudo o que cerca o modelo.<\/p>\n\n\n\n

\n

Para um ponto de partida pr\u00e1tico, nosso AI Readiness Assessment<\/a> ajuda a mapear onde a sua organiza\u00e7\u00e3o realmente est\u00e1 antes de voc\u00ea se comprometer com um caminho de rollout.<\/p>\n<\/blockquote>\n\n\n\n

Redefinindo o ponto de partida<\/h2>\n\n\n\n

Antes do playbook, a defini\u00e7\u00e3o, porque todo rollout que eu vi desandar desandou justamente por pular essa etapa.<\/p>\n\n\n\n

Cultura de IA n\u00e3o \u00e9 comprar licen\u00e7a para todo mundo, rodar um treinamento de uma hora ou tratar IA como uma ferramenta isolada de produtividade para engenharia. Tamb\u00e9m n\u00e3o \u00e9 substituir engenheiros por agentes, nem velocidade a qualquer custo.<\/p>\n\n\n\n

O que ela \u00e9: <\/strong>engenheiros e builders trabalhando mais perto uns dos outros, com uma dist\u00e2ncia menor entre a inten\u00e7\u00e3o e o c\u00f3digo entregue. Investimento no harness como pr\u00e1tica cont\u00ednua, n\u00e3o como projeto pontual. Engenheiros subindo uma camada, de digitar c\u00f3digo para orquestrar agentes. Velocidade com qualidade, porque os gates e os judges mant\u00eam o piso alto. Decis\u00f5es tomadas com dados de produ\u00e7\u00e3o consultados por agentes via MCPs, em vez de chutadas no sprint planning.<\/p>\n\n\n\n

A vers\u00e3o honesta de “temos uma cultura de IA” \u00e9 o engenheiro que roda cinco agentes em paralelo antes do almo\u00e7o, consulta dados de produ\u00e7\u00e3o enquanto decide o que entregar, conversa direto com o PM e o designer \u00e0 tarde e, na manh\u00e3 seguinte, escreve uma spec que um agente implementa durante outra reuni\u00e3o. <\/p>\n\n\n\n

Esse \u00e9 outro modelo operacional, e ele n\u00e3o aparece porque algu\u00e9m comprou licen\u00e7as. Ele aparece porque o harness, o desenho dos pap\u00e9is, o organograma e as m\u00e9tricas foram todos reconstru\u00eddos em torno da nova camada.<\/p>\n\n\n\n

Fase 1: os champions (meses 1 e 2)<\/h3>\n\n\n\n

De duas a quatro pessoas, e n\u00e3o “todo mundo que tiver interesse”. Especificamente: um product manager j\u00e1 curioso sobre IA, um tech lead receptivo, um engenheiro que j\u00e1 tem o instinto de Product Engineer ou Forward Deployed Engineer, e algu\u00e9m de plataforma ou infraestrutura capaz de construir o harness inicial. Os champions s\u00e3o recompensados com tempo, autonomia e voz, nessa ordem.<\/p>\n\n\n\n

Ao longo desses dois meses, os champions fazem tr\u00eas coisas: constroem o pr\u00f3prio setup at\u00e9 ele ficar s\u00f3lido, escrevem as duas ou tr\u00eas primeiras skills compartilhadas e identificam qual squad (ou quais dois) deve ser o piloto. O output deles n\u00e3o s\u00e3o features: s\u00e3o os trilhos que o resto da organiza\u00e7\u00e3o vai usar.<\/p>\n\n\n\n

Fase 2: o piloto (meses 3 e 4)<\/h3>\n\n\n\n

Um ou dois squads. Escolha com crit\u00e9rio: um com projeto novo e sem d\u00edvida de legado, outro com refatora\u00e7\u00e3o j\u00e1 planejada. N\u00e3o escolha o squad que est\u00e1 apagando inc\u00eandio em produ\u00e7\u00e3o neste trimestre, nem o squad com o tech lead resistente a mudan\u00e7a, nem o squad que se voluntariou s\u00f3 para brincar com ferramenta nova. Escolha os squads<\/strong> em que o trabalho encaixa no novo modelo operacional e em que as pessoas ser\u00e3o honestas sobre o que funciona e o que n\u00e3o funciona.<\/p>\n\n\n\n

Os squads piloto usam o que os champions constru\u00edram, escrevem mais skills e criam os templates de spec que o resto da organiza\u00e7\u00e3o vai herdar. As medi\u00e7\u00f5es que importam aqui s\u00e3o cycle time por feature, taxa de retrabalho e eNPS dos desenvolvedores, n\u00e3o tokens consumidos. Gasto de token \u00e9 m\u00e9trica de vaidade.<\/strong> A pergunta real \u00e9 se voc\u00ea entregou mais r\u00e1pido, com menos retrabalho, e se os engenheiros gostaram mais do processo.<\/p>\n\n\n\n

Vale ter em mente a regra 10-20-70 do BCG<\/strong> nessa fase: 10% do valor vem da tecnologia, 20% de dados e processo, 70% de pessoas e processo. As fases de champions e de piloto existem justamente porque os 70% n\u00e3o acontecem comprando tecnologia.<\/p>\n\n\n\n

Fase 3: o harness (meses 5 e 6)<\/h3>\n\n\n\n

\u00c9 aqui que o trabalho dos champions e dos squads piloto vira infraestrutura para toda a engenharia, e tamb\u00e9m onde a maioria dos times desiste, porque \u00e9 um trabalho pouco glamouroso. S\u00e3o cinco pe\u00e7as que valem investimento, e voc\u00ea n\u00e3o vai terminar as cinco em dois meses. Escolha uma ou duas.<\/p>\n\n\n\n

Code review automatizado, por t-shirt size.<\/em> PRs pequenos s\u00e3o aprovados automaticamente depois da pr\u00e9-an\u00e1lise do agente. PRs m\u00e9dios v\u00e3o para review humano com os achados do agente anexados. PRs grandes exigem par mais agente. O roteamento \u00e9 o que resolve: sem t-shirt sizing, todo PR passa pelo mesmo port\u00e3o e voc\u00ea cria um gargalo no review dos seniores.<\/p>\n\n\n\n

Templates de spec padronizados.<\/em> A forma como o seu time registra features vira o input padr\u00e3o de todo agente. As specs ficam no reposit\u00f3rio em docs\/specs\/, versionadas como c\u00f3digo, com o mesmo template em toda a organiza\u00e7\u00e3o. A varia\u00e7\u00e3o que voc\u00ea elimina padronizando vale mais do que a flexibilidade que voc\u00ea preserva deixando tudo solto. Veja nossa vis\u00e3o pr\u00e1tica de IA para desenvolvimento de software<\/a> para entender como isso se encaixa em um workflow mais amplo.<\/p>\n\n\n\n

MCP central com governan\u00e7a.<\/em> Um servidor MCP auditado para acesso ao banco de produ\u00e7\u00e3o, um para o Datadog, um para o Sentry, com acesso controlado, logs auditados e secrets escaneados. Sem isso, cada engenheiro monta o seu e voc\u00ea tem um problema de seguran\u00e7a e compliance esperando para aparecer.<\/p>\n\n\n\n

Loops de auto-recupera\u00e7\u00e3o.<\/em> Um agente que abre o pr\u00f3prio PR para corrigir um bug detectado. O Sentry dispara, um MCP roteia o erro para um agente de triagem, esse agente cria a issue, um agente worker pega a issue e abre um PR com a corre\u00e7\u00e3o e os testes. Isso \u00e9 avan\u00e7ado (n\u00e3o comece por aqui), mas \u00e9 onde o harness mais acumula ganho ao longo do tempo.<\/p>\n\n\n\n

Skills do time versionadas.<\/em> Todas as skills compartilhadas commitadas em um \u00fanico reposit\u00f3rio, revisadas em code review e tagueadas. Essa \u00e9 a camada de conhecimento institucional: quando algu\u00e9m sai, a skill fica; quando algu\u00e9m entra, as skills s\u00e3o o onboarding.<\/p>\n\n\n\n

Duas dessas pe\u00e7as bem feitas rendem mais do que cinco malfeitas. Escolha as duas de maior alavancagem para o seu time e trabalhe nelas de forma aberta.<\/p>\n\n\n\n

\n

Leia mais: <\/strong>Plan Mode \u00e9 decisivo: por que codar em modo direto com agentes desperdi\u00e7a tokens<\/a><\/p>\n<\/blockquote>\n\n\n\n

Antes de escalar: a governan\u00e7a que realmente importa<\/h2>\n\n\n\n

Governan\u00e7a \u00e9 onde a maioria dos rollouts que acompanhei falhou, ent\u00e3o aqui vai o que travar antes de abrir para a empresa inteira.<\/p>\n\n\n\n

CLAUDE.md Enterprise como gate de pol\u00edtica.<\/em> A Anthropic suporta quatro n\u00edveis de hierarquia no CLAUDE.md: Enterprise, User, Project e Directory. O n\u00edvel Enterprise \u00e9 onde entram as pol\u00edticas v\u00e1lidas para toda a empresa: o que \u00e9 permitido nos prompts, o que \u00e9 proibido e o que passa por scan. Trave isso antes de escalar.<\/p>\n\n\n\n

Controles de ferramentas e de or\u00e7amento no CI.<\/em> O –allowedTools restringe quais ferramentas os agentes podem invocar em execu\u00e7\u00f5es automatizadas. O –max-budget-usd limita o gasto por execu\u00e7\u00e3o. Nenhum dos dois \u00e9 ex\u00f3tico, e os dois s\u00e3o f\u00e1ceis de esquecer at\u00e9 a conta do seu CI triplicar em um m\u00eas.<\/p>\n\n\n\n

Allow-lists de MCP e logs de auditoria.<\/em> Todo servidor MCP conectado a algo sens\u00edvel deve estar em uma allow-list revisada, com cada chamada auditada. Se o seu MCP central de banco de produ\u00e7\u00e3o n\u00e3o consegue responder “o que o agente X leu da tabela de usu\u00e1rios na ter\u00e7a passada”, voc\u00ea n\u00e3o est\u00e1 pronto para escalar.<\/p>\n\n\n\n

Defesa contra prompt injection.<\/em> Se um MCP devolve dados que um atacante consegue influenciar (uma nota de CRM, um ticket de suporte, uma p\u00e1gina p\u00fablica na web), esses dados podem conter payloads de prompt injection. A defesa \u00e9 em camadas: sanitizar a entrada, restringir as ferramentas que o agente pode chamar depois de ler dados n\u00e3o confi\u00e1veis e rodar o agente em sandbox nas opera\u00e7\u00f5es n\u00e3o confi\u00e1veis. N\u00e3o pule a modelagem de amea\u00e7as.<\/p>\n\n\n\n

Resid\u00eancia de dados e BAA, com precis\u00e3o.<\/em> A Anthropic oferece Business Associate Agreement na API direta via time comercial. O Zero Data Retention est\u00e1 dispon\u00edvel para clientes enterprise eleg\u00edveis mediante aprova\u00e7\u00e3o, com exce\u00e7\u00f5es: Batch API, Files API, Skills API, execu\u00e7\u00e3o de c\u00f3digo e chamadas de conectores MCP ficam fora do escopo. Resid\u00eancia de dados na Uni\u00e3o Europeia n\u00e3o vem por padr\u00e3o no Claude Enterprise; processamento estritamente europeu passa pelo AWS Bedrock em Frankfurt ou pelas regi\u00f5es europeias do Google Vertex AI. Conte a vers\u00e3o precisa para o seu time de compliance antes de assinar, n\u00e3o depois.<\/p>\n\n\n\n

A pergunta sobre contrata\u00e7\u00e3o que todo CTO acaba fazendo<\/h2>\n\n\n\n

A pir\u00e2mide achata. Menos juniores puros escrevendo boilerplate, mais generalistas plenos e s\u00eaniores que assumem resultados de ponta a ponta. A escada do “j\u00fanior implementa, s\u00eanior revisa” \u00e9 comprimida porque a etapa de implementa\u00e7\u00e3o agora \u00e9 majoritariamente ag\u00eantica. Os pap\u00e9is que sobrevivem e crescem s\u00e3o os que exigem julgamento em cen\u00e1rios amb\u00edguos.<\/p>\n\n\n\n

A entrevista muda junto: <\/strong>menos LeetCode, mais taste, escrita de spec, julgamento e capacidade de arquitetar workflows ag\u00eanticos. Boris Cherny, da Anthropic, descreveu o filtro de contrata\u00e7\u00e3o da empresa como “side quests”: engenheiros com projetos de fim de semana, repert\u00f3rio em produto, design e infraestrutura, evid\u00eancia de que constroem coisas fora do trabalho.<\/p>\n\n\n\n

Esse filtro est\u00e1 se espalhando. O engenheiro com uma \u00fanica stack e dez anos de f\u00e1brica de features \u00e9 o perfil sob maior press\u00e3o. O engenheiro com um side project, opini\u00e3o sobre produto e conforto para atuar em toda a stack \u00e9 o perfil que comp\u00f5e valor ao longo do tempo.<\/p>\n\n\n\n

Leia mais: <\/strong>Harness Engineering: por que “pronto” n\u00e3o \u00e9 o agente dizer que est\u00e1 pronto<\/a><\/p>\n\n\n\n

A sequ\u00eancia de seis meses no calend\u00e1rio<\/h2>\n\n\n\n