Todo discurso de adoção de AI hoje segue o mesmo roteiro: compre licenças, distribua para todo mundo, meça quantas pessoas estão usando.
E os números mostram onde esse roteiro termina. O relatório The GenAI Divide, associado ao MIT NANDA, encontrou que 95% das organizações do estudo não estavam obtendo retorno mensurável em P&L com GenAI. A RAND reporta que mais de 80% dos projetos de AI falham, cerca de duas vezes a taxa de projetos de TI convencionais. A CIO Dive, citando a S&P Global Market Intelligence registrou que 42% das empresas abandonaram a maioria das suas iniciativas de AI, contra 17% no ano anterior.
das organizações estudadas sem retorno mensurável em P&L.
dos projetos de AI falham, por algumas estimativas.
abandonaram a maioria das iniciativas antes de produção ampla.
O detalhe que quase ninguém lê nesses estudos: a falha não foi rastreada à qualidade dos modelos. O problema recorrente é um gap de aprendizado organizacional, integração ruim, dado despreparado, expectativa torta e falta de mecanismo de validação.
Projetos de AI não morrem só por limitação técnica. Morrem por atrito.
E esse atrito tem anatomia conhecida. Na maioria das empresas não existe um departamento de tecnologia estruturado. Quando existe, a implementação vira imposição: a ferramenta é despejada no colo do funcionário com a expectativa de que ele se vire.
Mas nem todo mundo tem os mesmos olhos para AI que uma pessoa de tecnologia. E mesmo dentro da tecnologia, nem todo mundo tem bons olhos para AI. Isso não é defeito a corrigir. É a condição normal de qualquer organização.
Minha proposta vai na direção contrária do roteiro: comece removendo o acesso.
A arquitetura: concentração deliberada
Em vez de distribuir contas para todos, concentre o acesso no time de tecnologia ou, na versão mínima, numa única pessoa.
Esse time precisa entender o mandato: a tecnologia está sendo introduzida de forma gradual, com treinamento, e a primeira função dele é amadurecer a ferramenta no uso diário antes de qualquer expansão.
O fluxo funciona como uma ponte invertida. O time da frente não recebe a ferramenta; ele envia requisições. Descreve o que precisa dentro do escopo dele. O time de tecnologia executa usando AI, valida o resultado contra a realidade e entrega. O time da frente valida a entrega.
Humano no loop dos dois lados, sempre.
Quem opera esse fluxo ganha algo que nenhum plano abstrato de adoção entrega: dados reais do próprio negócio. Quantas contas são necessárias para rodar um time? Na minha experiência, um time de seis engenheiros roda com duas a três contas profissionais. Você só descobre esse número operando, nunca planejando.
Desenvolvimento invisível
Enquanto o time da frente acha que está apenas pedindo e conferindo entregas, ele está definindo casos de uso reais, refinando requisitos e se acostumando com o padrão de resultado. Quando a ferramenta chega, a adoção já aconteceu.
A única mudança, no fim, é o destinatário do pedido. Antes ele pedia para o time de tecnologia. Depois pede para o chatbot, agente ou sistema criado a partir do fluxo real. Mesmo formato, mesma expectativa, menos fricção.
Isso também define o critério de graduação da fase de concentração. Não é uma data. É um produto. A centralização termina quando a requisição vira interface. A ponte humana é temporária por design: o deliverable dela é a própria substituição.
Duas objeções honestas
A primeira é Shadow AI. Remover acesso não faz o funcionário parar de usar AI; pode fazer ele usar uma conta pessoal, sem governança nenhuma. O uso disseminado de ferramentas não sancionadas aparece justamente como uma parte crítica do problema em análises sobre a adoção corporativa.
Shadow AI
Shadow AI é o uso de ferramentas de AI fora do conhecimento ou da aprovação da empresa. O risco não é a curiosidade do funcionário. O risco é dado sensível, decisão crítica e fluxo operacional acontecendo fora de qualquer contrato, log ou política.
A resposta é dupla: comunicação e velocidade. Cabe ao gestor explicar abertamente o consentimento: o que é autorizado, o que não é e por quê. O departamento de tecnologia está construindo a ferramenta correta para o uso adequado, e é questão de tempo.
Isso troca proibição seca por contrato. Mas contrato tem prazo de validade. Se a primeira entrega visível demora seis meses, o acordo quebra e o mercado interno paralelo se instala. Por isso o time começa pelos projetos onde AI entrega o melhor resultado no menor tempo.
A segunda objeção é o gargalo. Concentrar acesso cria um ponto único de falha? Criaria, se fosse permanente. Não é. É uma fase de maturação com critério de saída definido.
A triagem: onde AI entra
A pergunta que o time de tecnologia precisa responder não é "onde aplicar AI". É "onde não tocar".
E a resposta não é simples. São várias alavancas. Deixar passar qualquer uma delas aumenta drasticamente a chance de falha.
Comece pelo risco, não pelo prompt
Que tipo de sistema é esse e que tipo de dado ele carrega? Essa pergunta vem antes de qualquer conversa sobre modelo, agente, automação ou interface.
O dado existe e está pronto? Não basta saber o tipo do dado. Ele precisa existir, ser acessível e ter dono. A ZogoTech, citando a previsão da Gartner prevê que, até 2026, organizações abandonarão 60% dos projetos de AI que não forem apoiados por dados prontos para AI.
AI-ready data
Dado pronto para AI não é só dado armazenado. É dado com dono, acesso definido, qualidade conhecida, governança, semântica clara e caminho técnico para chegar ao sistema que vai usá-lo.
O modelo dá conta? O modelo escolhido consegue lidar com esse tipo de trabalho, esse tipo de dado, esse tipo de sistema e entregar o resultado que você precisa?
Você precisa de resultado determinístico ou tolera variação? Conforme a resposta, você descobre que machine learning clássico, regra explícita ou automação comum talvez resolvam melhor do que um agente.
Determinístico ou probabilístico
Sistema determinístico precisa repetir o mesmo resultado para a mesma entrada. LLMs são probabilísticos: podem variar, interpretar contexto de outro jeito e exigir avaliação contínua. Essa escolha muda arquitetura, teste, custo e risco.
O erro é reversível? Sistema que só lê e resume é um nível de risco. Sistema que escreve em produção ou toca cliente é outro planeta. Isso dimensiona guardrails e posiciona o humano no loop.
Dá para medir se está certo? Sem critério objetivo de validação, você não valida a entrega nem detecta degradação depois. "Parece bom" não é métrica.
Custo por execução versus valor. Frequência e volume cruzados com custo do modelo. Processo de altíssimo volume em modelo frontier estoura orçamento antes do valor aparecer.
Você está resolvendo um problema ou criando o legado de amanhã? Quem mantém isso depois da entrega, sabendo que modelo deprecia, API muda e comportamento deriva a cada versão?
E quando quebrar, o processo manual antigo ainda existe? Se AI virou o único caminho, uma quebra deixa de ser incidente e vira parada de operação.
A gestão: portfólio, não projeto
Prepare o time antes de apresentar a ferramenta. Treinamento adequado e atualizado importa porque o que se estudou quatro anos atrás já está profundamente desatualizado.
E aqui mora um erro sutil que gestores tecnicamente fortes cometem: a realidade que você extrai da LLM é sua. Ela é produto da sua habilidade, não da ferramenta sozinha. Os outros não vão extrair o mesmo no primeiro dia.
A função do gestor é medir onde o time está, identificar gaps, corrigi-los e só então apresentar. E não precisa apresentar distribuindo conta para cada pessoa como se fosse programa de auditório. Comece pequeno, modestamente, verificando.
Observabilidade instrumentada
Observabilidade não é vigiar pessoas. É construir logs, alertas, métricas de qualidade de saída e limites que acordam um humano quando algo desvia. O sistema observa; o humano responde.
Adote a métrica 3 de 10. De cada dez projetos onde se aplica AI, três alcançam o sucesso que o escopo pediu. Essa métrica muda a cabeça do gestor: quem entra esperando acertar oito de dez cancela o programa inteiro no terceiro fracasso; quem entra sabendo que é três de dez aloca orçamento e paciência de acordo.
A assimetria compensa. As falhas são maiores em número, mas o sucesso, quando vem, costuma durar mais. Um projeto bem-sucedido não garante que os outros serão. Analise custos projeto a projeto.
Pausado não é morto. Quando fica claro que AI não toca aquele projeto do jeito necessário, pare. Não quer dizer que AI é ruim. Quer dizer que os modelos deste momento não entregam o que esse escopo exige. Evite gasto desnecessário, devolva para a fila com condição de resgate e provavelmente você vai resgatá-lo no futuro.
Falhe rápido, reponha rápido. Falhas existem, erros existem, todo mundo vai falhar. Saber lidar com elas o mais rápido possível e recomeçar é o jeito mais produtivo de trabalhar com AI que eu conheço.
O fechamento
A ironia é que o mercado mede adoção: assentos ativos, horas de uso, número de prompts. Essas métricas se provaram irrelevantes para a única pergunta que importa: se a AI produziu resultado melhor do que aquilo que ela substituiu.
O modelo que descrevi aqui inverte a medição junto com o acesso. Você não conta quem está usando. Você conta entregas validadas no fluxo real.
Remover acesso no dia um parece contraintuitivo. Mas concentração deliberada, ponte invertida, triagem rigorosa e gestão de portfólio formam o caminho mais coeso que eu conheço, como engenheiro, para uma implementação de AI que sobrevive ao contato com a organização real.
A alternativa está nos números lá de cima.