6 Lições sobre IA que todo líder precisa saber antes de tomar decisões #LideraSamba

Nos últimos dezoito meses, conversei com dezenas de CEOs, CTOs e gestores de TI de empresas que estão em diferentes estágios da adoção de IA. O padrão que vejo é consistente: todos começam com entusiasmo e confiança de que sabem exatamente onde querem chegar, mas descobrem, meses depois, que as decisões iniciais criaram gargalos que agora precisam desmontar.

Quando me deparo com essa situação, pergunto sempre a mesma coisa: como isso foi decidido no princípio? A resposta é reveladora. Normalmente envolve um memo de um fornecedor, uma apresentação animadora, talvez uma consultoria rápida com foco em use cases já prontos. O que falta, quase sempre, é a sequência de pensamento que deveria vir antes de qualquer implementação real.

O tempo que passei ajudando empresas nesse processo ensinou que existem seis decisões fundamentais que, quando tomadas em sequência e com profundidade, determinam se a adoção de IA vai se parecer com um negócio controlado ou com uma corrida contra o tempo em que tudo fica mais confuso enquanto parece que está ficando mais rápido. Nenhuma delas é sexy. Algumas parecem até óbvias. Mas quando executadas superficialmente, cada uma delas explode em custos ocultos, oportunidades perdidas, ou simplesmente projetos que chegam ao final descobrindo que resolvem o problema errado.

1) Letramento: Nivelar conhecimento antes de prometer resultados

Quando digo letramento, não estou falando de assistir um vídeo de 15 minutos no LinkedIn ou uma consultoria de uma hora sobre o que é IA. Estou falando de uma organização onde os líderes que vão tomar decisões sobre IA sabem, concretamente, o que um modelo de linguagem consegue fazer, quais são os limites, quando e por que ele vai falhar, quais dados alimentam o sistema, e o que significa treinar versus usar um modelo existente.

Por que começar aqui? Porque quando a liderança não tem esse entendimento, ela tende a tomar decisões baseadas em narrativa, não em realidade. Promessas que parecem razoáveis numa conversa viram restrições que paralisam quando você tenta implementar. 

Prazos que são definidos como possíveis descobrem-se impossíveis quando você joga na realidade. O problema não é que a liderança é burra. É que liderança sem contexto técnico mínimo tende a supor que todas as promessas têm o mesmo nível de confiabilidade, e IA é uma área onde os prognósticos variam muito de acordo com o que você está tentando fazer.

Conheço uma empresa de 500 pessoas que descobriu, três meses depois de aprovar um projeto de automação inteligente de atendimento ao cliente, que o que o time técnico tinha em mente era bem diferente do que o board tinha compreendido. O board imaginava um sistema que eliminaria 80% das chamadas. O time técnico sabia que o cenário realista era reduzir o tempo médio de atendimento em 25%. Ninguém tinha mentido. O problema foi que ninguém tinha o entendimento compartilhado sobre o que era possível. A conversa sobre letramento teria deixado isso claro em uma hora.

Letramento não é sobre tornar a liderança especialista em IA. É sobre torná-la capaz de fazer perguntas boas e entender as respostas o suficiente para discernir se o que está sendo prometido é realista ou não.

2) Priorização: Começar pelo que pode ser medido

Muitas empresas tratam a seleção de casos de uso como um exercício de brainstorm: senta todo mundo, lista-se tudo que poderia ser automatizado ou potencializado com IA, coloca-se em uma matriz de impacto x esforço, e a partir daí começa a implementação. O método não é ruim. O problema é que na maioria das vezes, ele otimiza para casos que soam bem numa apresentação em vez de casos que resolvem problemas mensuráveis que estão gerando custos reais hoje.

A priorização que funciona passa por duas categorias de casos que têm algo em comum: atividades que são repetitivas e processos que já têm métricas estabelecidas. Se uma área quer automatizar uma tarefa que é feita cem vezes por dia e a automação vai reduzir o tempo em 50%, o business case é claro. Se você quer usar IA para melhorar a qualidade de uma decisão que já está sendo rastreada (taxa de churn, tempo de resolução de ticket, conversão em vendas), o impacto é mensurável antes e depois. 

Onde a priorização costuma falhar é quando uma área chega querendo "aplicar IA" a algo que não é nem bem definido quantitativamente. "Queremos usar IA para melhorar o relacionamento com clientes." Tecnicamente possível, mas como você mede sucesso? O que a IA vai fazer que um CRM bem utilizado não faz? Onde está o gargalo hoje que está deixando dinheiro na mesa?

Uma empresa que conheço gastou seis meses implementando um sistema de IA para priorizar leads de vendas. O sistema funcionava tecnicamente, mas ninguém usava porque os vendedores já tinham seus próprios critérios. O que ninguém tinha perguntado no início era: a equipe de vendas quer isso? A taxa de conversão está sendo limitada por seleção de lead ou por execução? Se fosse por execução (que era o caso), nenhuma melhoria no ranking de leads ia mudar o resultado.

Priorização com critérios sérios começa com uma pergunta simples: qual é a métrica que importa hoje? Se ela não existe ainda, cria-se a métrica antes de implementar IA. Não depois.

3) Dados "sujos": O erro que você não consegue consertar depois

Técnicos têm um ditado: "garbage in, garbage out." Se você alimenta um modelo com dados ruins, recebe previsões ruins. A maioria dos líderes entendem isso conceitualmente. Mas quando chega a hora de começar, esse entendimento desaparece debaixo da pressão de implementação rápida. 

O que são “dados limpos”? Não significa perfeitos, significa estruturados, rastreáveis em origem, sem inconsistências óbvias, completos nos pontos críticos, e com documentação que explique por que os dados existem daquela forma. 

Se você tem um banco de dados de clientes onde 30% dos registros têm o campo "data de contato" preenchido e 70% não têm, esse dado é inútil para um modelo de retenção. Se um campo tem valores como "SIM", "sim", "S", "Y" quando deveria ter apenas dois estados, o modelo vai gastar capacidade aprendendo a decodificar o que deveria ser óbvio.  

Aqui está o pior: quando você descobre que seus dados estão ruins, você geralmente está seis meses dentro do projeto, tendo gasto recursos significativos. Nesse ponto, sua opção é uma de duas: ou você para, limpa os dados (e atrasa tudo), ou você continua com dados ruins sabendo que o resultado vai ser medíocre. A melhor escolha é nunca chegar a esse ponto.

Uma empresa de e-commerce que trabalhamos tinha um grande histórico de dados de compra, mas quando começamos a analisá-lo, percebemos que a coluna "categoria de produto" tinha sido alterada três vezes nos últimos cinco anos (motivos de business, restruturação de catálogo, etc.). Ninguém tinha mantido uma tabela de conversão. Isso significava que dados de dois anos atrás não eram comparáveis com dados de agora. Essa descoberta deveria ter acontecido antes do projeto começar, não durante. 

A sequência correta é: define-se o caso de uso, identifica-se que dados serão necessários, auditam-se esses dados e só depois disso se começa a conversa sobre implementação. Isso custa algumas semanas no início, mas economiza meses depois. 

4) Guardrails: O que você permite é tão importante quanto o que bloqueia 

Um dos maiores equívocos que vejo é tratar guardrails como restrições que retardam implementação. Na verdade, é a situação oposta. Um guardrail é uma linha clara que diz: dentro disso, o sistema opera autonomamente; fora disso, precisa de revisão humana ou não opera. Quando você define isso no começo, a implementação fica mais simples porque o escopo fica claro.

Coloquemos em um exemplo concreto. Uma empresa de seguros quer usar IA para analisar documentos de sinistro e fazer recomendações de aprovação ou negação. Sem guardrails, a implementação fica: "o sistema faz tudo e um humano revisa tudo", que não é bem implementação, é um workflow que ainda depende totalmente de humanos mas agora é mais lento porque tem um modelo no meio.

Com guardrails, fica: "para sinistros com confiança acima de 95%, aprove automaticamente; entre 70% e 95%, mande para revisão de um especialista júnior; abaixo de 70%, mande para um sênior." Isso cria um sistema que escala porque define claramente quem faz o quê.

Guardrails também protegem contra decisões ruins. Se você não tiver definido "qual é o pior caso que aceito que o sistema faça sozinho?", a tendência é deixar o sistema fazer coisas que, descrito em palavras, ninguém aceitaria. Uma empresa que conheço deixou um modelo de IA fazer ofertas automáticas para clientes "em risco de churn" sem guardrail de desconto máximo. O modelo, otimizado para retenção, oferecia descontos de 60% para qualquer um que havia levantado uma reclamação. Era tecnicamente correto (retenção subiu), mas economicamente destrutivo.

Guardrails não precisam ser técnicos. Podem ser políticas operacionais: "sistemas de IA nunca têm a palavra final em decisões que afetam pessoas ou dinheiro acima de X", ou "recomendações do sistema sempre trazem confiança e rastreabilidade de reasoning". Mas precisam estar definidas explicitamente, por escrito, antes da implementação.

5) Shadow AI: O risco que cresce enquanto você não está olhando

Enquanto a liderança está debatendo qual IA implementar, os funcionários já estão usando IA sem supervisão. Colam dados da empresa em ChatGPT para resolver um problema rápido. Usam um agente de codificação online para escrever um script. Alimentam um modelo público com informações de clientes para extrair padrões. Tudo sem avisar ninguém, não por malícia, mas porque é mais rápido.

O risco aqui vai além de segurança, embora segurança seja real (exposição de dados corporativos). O risco maior é de governança: quando você não vê o que está acontecendo, não consegue medir o impacto, não consegue auditar decisões, e perde completamente a capacidade de responder perguntas regulatórias sobre "como tomamos essa decisão?"

Pesquisas mostram que 74% dos funcionários usam contas pessoais para acessar ferramentas de IA no trabalho, fora do alcance de qualquer controle corporativo. Quando uma violação de dados acontece mais tarde, a empresa é responsável independentemente de o uso ter sido autorizado ou não. O dano regulatório não é pequeno: violações relacionadas a shadow AI custam, em média, 670 mil dólares a mais que violações convencionais.

A resposta não é banir IA. Fazer isso é como proibir telefones pessoais no trabalho: funciona por cinco minutos. A resposta é oferecer uma alternativa segura que seja tão fácil e rápida quanto o que as pessoas já encontraram sozinhas. Quando você oferece uma solução corporativa, com dados limpos, conectado aos dados da empresa de forma controlada, e com auditoria, o que acontece é que o shadow diminui porque a alternativa oficial é melhor. 

Mas isso só funciona se existir alguém na organização responsável por manter visibilidade sobre essas ferramentas. Se não existir, o shadow AI continua crescendo e você continua usando a lógica de "se não vejo, não acontece", que é exatamente a lógica que produz os piores incidentes.

6) Economia de Tokens: Controle de custo que revela quando algo está errado 

Tokens são a unidade de medida de como você é cobrado por usar um modelo de linguagem. Cada word piece do texto é aproximadamente um token (a proporção varia). Uma conversa típica de cinco turns pode ser 2 mil tokens. Um documento de 20 páginas é 5 mil tokens. Um modelo que processa bilhões de tokens pode ficar caro rápido, especialmente quando a implementação não é eficiente.

O que a Meta descobriu com seu famoso "Claudeonomics" — um ranking de qual funcionário mais consumia tokens — foi iluminador: quando você cria uma métrica de "consumo de tokens é bom", as pessoas otimizam a métrica, não o resultado. Criaram agentes paralelos só para inflar seus números. O consumo de tokens disparou sem nenhuma correlação com produtividade real.

Mas a lição errada que algumas empresas tiram é: "economia de tokens é um jogo de números, não importa." Isso não é verdade. A lição certa é: economia de tokens, quando bem-feita, é na verdade um indicador de eficiência. Se você está gastando 10 vezes mais tokens para obter o mesmo resultado que ontem, isso é sinal de que algo na implementação quebrou. Pode ser que o prompt ficou pior. Pode ser que o modelo está sendo chamado desnecessariamente. Pode ser que a filtragem de dados antes de enviar para o modelo desapareceu.

Economia de tokens também força conversas sobre "precisamos realmente desse modelo para essa tarefa?" A resposta frequente é não. Para ordenação simples de uma lista, um modelo de linguagem é overkill e caro. Para categorização binária (é ou não é), às vezes uma regra ou um modelo menor é mais apropriado. Quando você tem orçamento ilimitado de tokens, não precisa fazer essas perguntas. Quando você tem limite, descobre que 40% do que você está tentando fazer poderia ser feito de forma mais simples. 

O que funciona é monitorar consumo de tokens por use case, entender qual é o baseline esperado, e estabelecer alertas quando um caso de uso começa a consumir muito acima do previsto.

Uma palavra final 

Se você juntar essas seis lições, o que vê é que todas elas falam sobre a mesma coisa vista de ângulos diferentes: a diferença entre adoção de IA como um projeto de negócio versus adoção de IA como resposta ao barulho de mercado.

Quando você começa pelo letramento, você está dizendo que a liderança vai entender o que está acontecendo. Quando você prioriza casos com métricas, você está dizendo que o que você faz vai gerar resultado mensurável. Quando você limpa dados antes de começar, você está dizendo que a qualidade importa mais que a velocidade de início. Quando você define guardrails, você está dizendo que há algo pior que ir lentamente: ir rápido para a direção errada. Quando você cuida de shadow AI, você está dizendo que visibilidade é um requisito não negociável. E quando você monitora tokens, você está dizendo que eficiência é uma assinatura de que o sistema está operando como esperado.

A maioria das empresas que vejo em dificuldade em suas adoções de IA pulou uma ou mais dessas etapas. O que acontece é previsível: seis meses depois, a empresa tem um projeto de IA que não gera o retorno prometido, custos que ninguém sabe de onde vêm, decisões que não podem ser auditadas, riscos de compliance que ninguém estava rastreando, e liderança que está tão confusa quanto estava no início.

Dica final do Gus: na adoção de IA, respeite a sequência. O tempo que você investe em clareza no início é o tempo que não vai perder corrigindo erros lá na frente.

Gustavo Caetano

CEO & Founder

Gustavo Caetano é fundador e CEO da Sambatech, empreendedor e autor dos livros Pense Simples e Faça Simples. Há mais de 20 anos atua na interseção entre tecnologia, inovação e negócios, liderando iniciativas de transformação digital e Inteligência Artificial. Também integra conselhos de grandes empresas, contribuindo para discussões estratégicas sobre inovação, tecnologia e crescimento. É ainda co-host do SambaTalks, onde recebe grandes lideranças para discutir os desafios e as transformações do mundo dos negócios.