O botão “Usar IA” pode ser um sinal de que sua feature ainda não ficou pronta.

Imagine um aplicativo que promete economizar dez minutos do seu trabalho.

Para conseguir isso, você precisa abrir uma área nova, explicar o que está fazendo, dar contexto, escrever um prompt, esperar a resposta, conferir tudo, corrigir duas coisas, copiar o resultado e voltar para a tela anterior.

A IA economizou dez minutos.

E cobrou oito de pedágio.

Ainda dá para colocar um badge escrito “Powered by AI”.

Só não dá para estranhar quando quase ninguém volta.

Kurt Lewin já tinha uma lente interessante para isso

Muito antes de existir software, Kurt Lewin trabalhava com a ideia de campo de forças.

De maneira simples, nosso comportamento é influenciado tanto pelas forças que nos empurram para uma ação quanto pelas forças que nos seguram.

Isso parece óbvio.

Produto frequentemente age como se não fosse.

Quando alguma feature tem pouca adoção, a caixa de ferramentas aparece rápido:

notificação,

badge,

tutorial,

onboarding,

pop-up,

streak,

e-mail,

“experimente agora”.

Tudo tentando aumentar a força que empurra.

Só que existe outra possibilidade.

O usuário já quer o resultado.

Ele só não quer atravessar o produto para chegar até ele.

E IA está criando uma quantidade impressionante desse tipo de experiência.

A gente transformou IA em destino

Abra praticamente qualquer software moderno e existe uma boa chance de encontrar alguma versão de:

Usar IA

Clique.

Agora você entrou no território da inteligência artificial.

Tem uma caixa de texto.

Talvez algumas sugestões de prompt.

Um ícone brilhando em algum lugar.

E uma responsabilidade nova:

descobrir como conversar com aquilo.

Isso faz sentido em produtos cujo próprio trabalho é conversar com um modelo.

Em vários outros, é uma escolha bem estranha.

Pense num CRM.

A pessoa acabou de sair de uma reunião com um cliente.

Existe gravação.

Existe histórico.

Existem negócios abertos.

Existem e-mails anteriores.

Existe estágio da oportunidade.

Existe informação suficiente para preparar o próximo passo.

Mesmo assim, o produto oferece:

“Pergunte à IA.”

Perguntar o quê?

O trabalho já está ali.

Talvez o resumo devesse aparecer sozinho.

Talvez os compromissos assumidos na reunião já devessem estar identificados.

Talvez a próxima ação viesse sugerida.

Talvez o CRM já pudesse preparar uma atualização e perguntar apenas:

Salvar?

A diferença parece pequena.

Para quem usa, não é.

Na primeira experiência, a IA virou mais uma tarefa.

Na segunda, ela removeu uma.

Contexto é uma forma de atrito

Boa parte do uso ruim de IA começa assim:

“Explique seu contexto.”

É compreensível.

O modelo precisa saber com o que está trabalhando.

Só que quem deveria pagar esse custo?

Se a plataforma já conhece o usuário, o documento, o cliente, a conversa, o projeto ou a transação, obrigar a pessoa a reconstruir esse contexto num prompt é quase uma taxa de importação dentro do próprio produto.

É aqui que context engineering começa a importar.

O nome pode parecer mais sofisticado do que a ideia.

Context engineering é decidir qual informação o modelo precisa receber, em qual momento e em qual formato, para conseguir fazer um bom trabalho.

Em vez de pedir:

“Cole aqui o histórico do cliente.”

o sistema busca o histórico.

Em vez de:

“Explique qual política devemos considerar.”

o sistema encontra a política aplicável.

Em vez de:

“Diga o que aconteceu anteriormente.”

a conversa relevante já entra no contexto.

A pessoa não fica melhor em prompt.

O produto fica melhor em produto.

Às vezes entra RAG

Nem todo contexto cabe ou deveria ficar permanentemente disponível para o modelo.

Se a resposta depende de documentos, políticas, contratos, manuais ou uma base grande de conhecimento, pode fazer sentido usar RAG, Retrieval-Augmented Generation.

Em linguagem normal:

antes de responder, o sistema procura a informação relevante e entrega aqueles trechos ao modelo.

Isso permite uma experiência bem diferente.

O usuário pergunta sobre uma regra de reembolso.

Uma implementação preguiçosa devolve uma resposta convincente.

Uma implementação melhor busca a política oficial, encontra a seção relevante e responde com aquela informação disponível para conferência.

Agora não estamos apenas tentando deixar a IA mais inteligente.

Estamos mexendo numa das forças que seguram o uso:

“Será que eu posso confiar nisso?”

E essa força costuma ser pesada.

O custo de verificar pode matar uma ótima feature

Imagine que a IA escreva uma análise em dois minutos.

Sem ela, você levaria dez.

Excelente.

Só que você passa outros seis minutos verificando cada informação porque não sabe de onde saiu nada.

Economia real:

dois minutos.

Agora imagine que a resposta venha com os dados usados, as fontes relevantes e uma forma simples de revisar os pontos de maior risco.

A capacidade do modelo pode ser exatamente a mesma.

Mas o produto ficou muito mais valioso porque caiu o custo de verificação.

Isso é importante porque uma feature de IA não compete apenas por qualidade.

Ela compete contra o jeito que a pessoa já faz o trabalho.

E o jeito antigo tem algumas vantagens injustas.

A pessoa já conhece.

Já confia.

Já sabe onde costuma dar errado.

Já criou suas gambiarras.

Você pode aparecer com um modelo espetacular e ainda perder para um Excel horroroso aberto há quatro anos.

Nem todo caso deveria ter o mesmo caminho

Agora imagine que a IA consiga executar alguma coisa.

Cancelar.

Alterar.

Publicar.

Enviar.

Aprovar.

Comprar.

De repente, reduzir atrito pode virar uma péssima ideia se significar reduzir controle junto.

É aqui que entram guardrails.

Guardrails são os limites técnicos e de negócio que definem até onde a IA pode ir sozinha.

Gerar uma sugestão de texto?

Pouco risco.

Enviar esse texto automaticamente para 80 mil pessoas?

Conversa diferente.

Consultar uma fatura?

Tudo bem.

Alterar uma condição financeira?

Talvez exista uma regra no meio.

O ponto interessante é que segurança também interfere no campo de forças.

Se o usuário sente que qualquer clique pode gerar uma ação irreversível, ele vai conferir mais, hesitar mais e usar menos.

Então guardrail não serve apenas para proteger a plataforma.

Pode servir para tornar a experiência mais confiável o suficiente para ser usada.

E nem toda incerteza precisa chegar ao usuário

Outro erro comum é tratar todas as respostas da IA da mesma maneira.

Só que modelos trabalham com incerteza.

Em alguns casos, o sistema está diante de algo simples e muito parecido com milhares de exemplos anteriores.

Em outros, a entrada é ambígua, incompleta ou fora do padrão.

Esses dois casos não precisam percorrer o mesmo caminho.

Podemos usar thresholds de confiança, limites que ajudam a decidir quando uma saída pode seguir normalmente e quando precisa de outro tratamento.

Um caso simples pode avançar.

Um caso duvidoso pode pedir confirmação.

Um caso sensível pode ir para revisão.

Um caso completamente fora do escopo pode receber a resposta mais subestimada da inteligência artificial:

“Não sei.”

Isso também reduz atrito.

Porque o usuário para de tratar toda interação como uma pequena auditoria.

Talvez o botão seja o último estágio, não o primeiro

Eu não tenho nada contra botões de IA.

Tenho contra colocar um botão porque ainda não descobrimos como a IA participa do trabalho.

Existe uma diferença entre:

“Clique aqui para usar IA.”

e:

“Seu trabalho já está preparado.”

Pensa num aplicativo de reunião.

A reunião termina.

A gravação já existe.

O sistema poderia transcrever, separar decisões, identificar tarefas e montar um resumo.

O usuário entra e decide o que aceita, corrige ou descarta.

Em nenhum momento ele precisou formular:

“Por favor, resuma esta reunião destacando os principais pontos, action items...”

Ele estava presente.

O software também.

Já chega de apresentação formal entre os dois.

Lewin provavelmente olharia para a fricção

Se uma feature de IA não está sendo usada, aumentar divulgação pode funcionar.

Treinar melhor pode funcionar.

Explicar melhor também.

Mas eu não começaria por aí.

Eu olharia para as forças contrárias.

Quanto contexto a pessoa precisa fornecer?

Quantas vezes precisa trocar de tela?

Quanto tempo espera?

Quanto precisa verificar?

Quanto risco percebe?

Quantas decisões novas o produto criou?

Quanto trabalho sobra depois da resposta?

E a pergunta que eu gosto mais:

Se tirarmos o botão “Usar IA”, existe alguma forma de entregar o mesmo valor dentro do fluxo que já acontece?

Às vezes não.

Tudo bem.

Mas quando a resposta é sim, provavelmente existe uma versão melhor daquela feature esperando para ser construída.

Porque quando o usuário já quer chegar ao resultado, motivação extra começa a parecer decoração.

O produto pode simplesmente sair do caminho.