Para o produto que você vende
Como adicionar recursos de IA a um produto que já existe
Você tem usuários, dados, permissões e um roteiro. “Adicionar IA” é o pedido do conselho. Esta é a versão prática: quais recursos encaixam em um produto que já existe, o que os faz funcionar, e como entregar um deles em semanas sem quebrar a confiança que você construiu.
Comece pelo trabalho, não pelo modelo
A forma mais rápida de adicionar IA a um produto e fazer isso mal é começar pelo modelo. Um chatbot aparece no canto, responde perguntas que ninguém fez, e é fechado. Entra em produção, demonstra bem, e seis meses depois ninguém consegue apontar um número que ele tenha movido.
Os recursos que ficam começam por algo que os seus usuários já fazem: repetidamente, a contragosto, ou devagar. Três perguntas encontram esses recursos:
Onde os usuários produzem um primeiro rascunho?
Relatórios, respostas, resumos, configurações, descrições. Qualquer coisa digitada do zero que poderia ser digitada a partir de uma sugestão.
Onde eles esperam?
Em uma busca, em uma revisão, na aprovação de outra pessoa, em um relatório que roda de madrugada.
Onde eles buscam em vez de perguntar?
Artigos de ajuda, registros antigos, arquivos de outras pessoas. Cada caixa de busca é uma pergunta que o seu produto poderia responder diretamente.
Cada resposta é um recurso candidato com uma métrica anexada: rascunhos aceitos, minutos não esperados, buscas que viraram respostas.
As quatro formas que os recursos de IA assumem dentro de um produto que já existe
Quase todo recurso de IA que funciona dentro de um produto é uma de quatro formas. Nomear a forma cedo decide a arquitetura, o risco e a métrica.
Assistir
Um rascunho ou uma sugestão dentro do fluxo de trabalho em que o usuário já está: a resposta, o resumo, o próximo campo, a categoria provável. O usuário mantém o controle; o modelo economiza os primeiros noventa segundos. O menor risco, o mais fácil de medir (aceito ou editado), e o primeiro recurso certo para a maioria dos produtos.
Recuperar
Respostas sobre os dados do próprio cliente: os documentos dele, os registros dele, o histórico dele, com a fonte à vista. É aqui que perguntar ao produto se torna real, e é aqui que as permissões decidem tudo: a resposta nunca pode incluir o que o usuário não conseguiria abrir à mão.
Extrair e classificar
Transformar o que chega — documentos, tickets, e-mails, imagens — em campos estruturados sobre os quais o seu produto possa agir. Invisível para o usuário quando funciona, e muitas vezes o recurso com o retorno operacional mais claro.
Automatizar, com uma comporta
Um agente que executa ações dentro do produto em nome do usuário — arquiva, atualiza, agenda, notifica — com uma pessoa aprovando até que aquele tipo de ação tenha conquistado autonomia. Maior valor, maior risco; nunca o primeiro recurso.
A maioria dos produtos vai entregar um recurso de assistência, descobrir um recurso de recuperação por baixo dele, e só então estar pronta para um agente.
O que o seu produto já tem — e o que não tem
Um produto que já existe traz três coisas que um projeto de IA do zero nunca tem: uma UX que os usuários já conhecem, um modelo de permissões e um modelo de dados com histórico dentro. O recurso deveria viver dentro dos três. Essa é toda a vantagem sobre uma ferramenta colada por fora — e é onde estão as armadilhas.
Permissões
Uma recuperação que ignora o tenant é um vazamento de dados com uma interface simpática. O modelo vê apenas o que o usuário que pergunta pode ver, imposto no momento da consulta e não por prompt.
Latência
Uma espera de três segundos é aceitável para um rascunho que o usuário pediu e inaceitável em um campo que autocompleta. Decida por recurso se o modelo roda no caminho da requisição, em segundo plano, ou antes.
Custo por chamada
Um recurso que chama um modelo grande a cada tecla pode custar mais que o plano em que ele vive. Projete para isso: modelos menores onde bastam, cache, processamento em lote, e um orçamento por tenant que o produto respeite.
Avaliação
Você não pode entregar o que não pode medir. Antes do lançamento, um conjunto de teste tirado do uso real — rascunhos reais, perguntas reais, documentos reais — com respostas corretas conhecidas, executado toda vez que o prompt, o modelo ou os dados mudam. É a única forma de saber se uma mudança melhorou o recurso ou apenas moveu as falhas.
Preparação dos dados
“Temos os dados” e “um modelo consegue usá-los” são estados diferentes. Qualidade, estrutura, acesso e recuperação: cada um precisa ser verificado contra o recurso que você realmente quer; a lacuna costuma ser a primeira coisa a corrigir, e raramente é glamourosa. Dados prontos para IA é esse trabalho.
Escolha do modelo, em resumo
Esta é a decisão em que as equipes de produto passam mais tempo e que menos importa no começo.
Os modelos comerciais via API levam você mais rápido a um recurso que funciona. Comece por aí para recursos de assistência e de recuperação, a menos que uma restrição dura diga o contrário.
Os modelos de pesos abertos na sua própria infraestrutura ganham quando os dados não podem sair do seu ambiente, quando o volume torna o preço por chamada insustentável, ou quando a latência precisa ser controlada. Custam mais para operar e menos para rodar.
O machine learning clássico — que não é um modelo de linguagem de forma alguma — é a resposta certa quando a entrada é uma tabela e a saída é uma previsão ou uma pontuação. Mais barato, mais rápido e explicável.
O fine-tuning ensina a um modelo um formato ou uma tarefa estreita, não o seu negócio. Isso é o que a ancoragem nos seus dados faz. Recorra ao fine-tuning tarde, por custo ou por latência, não primeiro.
Qualquer que seja a escolha, o modelo é um componente atrás de uma interface que o seu produto controla. Trocá-lo deveria ser uma mudança de configuração, e o conjunto de avaliação é o que torna isso seguro.
Entregar sem quebrar a confiança
Usuários que já estão lá têm expectativas que um produto novo não tem. Um recurso que erra com confiança uma única vez custa mais do que um que nunca existiu.
Entregue a um grupo atrás de uma flag
Dez clientes que escolheram participar, depois cem. O recurso conquista a saída.
Mostre a fonte, permita a edição
As respostas recuperadas citam; os rascunhos são editáveis; o usuário consegue ver por que o produto sugeriu o que sugeriu.
Mantenha uma comporta sobre as ações
Tudo o que muda dados espera por uma pessoa até que aquele tipo de ação tenha um histórico. Autonomia é algo que um recurso conquista, uma ação por vez. Agentes e assistentes de IA é construído exatamente em torno disso.
Meça adoção, não uso
Não “quantos clicaram” — quantos continuaram usando na quarta semana, quantos rascunhos foram aceitos, quantas respostas foram corrigidas. A taxa de correção é a saúde do recurso.
Instrumente como qualquer outro recurso
Logs, rastreamento de erros, e um rastro de cada saída de volta até o modelo, o prompt e os dados que a produziram.
Diga o que ele é
Não chame de “com IA”. Diga o que ele faz: “redige a sua resposta”, “responde a partir dos seus documentos”, “sinaliza as faturas que não batem”. Usuários confiam em funções, não em adjetivos.
Quanto tempo leva e quanto custa
Um primeiro recurso de assistência ou de extração, limitado a um fluxo de trabalho, são semanas de trabalho e não trimestres — se os dados estiverem prontos e o conjunto de avaliação existir. A recuperação sobre dados de clientes soma o trabalho de permissões. Um agente que age soma a comporta, a trilha de auditoria e o tempo que leva para conquistar autonomia.
Quanto custa depende de qual desses você está construindo e do que os seus dados sustentam hoje, e é por isso que não publicamos uma tabela. O que publicamos é como descobrir: um Sprint de AI Discovery de duas semanas com os engenheiros que construiriam, que termina com os dois ou três recursos que vale a pena construir primeiro, a viabilidade deles contra os seus sistemas reais, e um piloto dimensionado com um orçamento que você pode levar ao conselho.
Onde os produtos erram
O chatbot colado por fora. Genérico, desconectado do modelo de dados, fechado em uma semana.
A demo que nunca entra em produção. Impressionante em entradas curadas, nunca medida nas reais.
A recuperação que ignora as permissões. Descoberta por um cliente, não pelo QA.
Nenhum conjunto de avaliação. Cada mudança de prompt é um palpite; cada atualização de modelo é um risco.
“IA” como nome do recurso. Um rótulo em vez de um trabalho; os usuários não sabem quando usar, então não usam.
Começar pelo agente. A forma com mais em jogo como a primeira, antes de o produto ter conquistado qualquer confiança para ela.
Perguntas que as equipes de produto fazem
Precisamos do nosso próprio modelo?
Quase nunca no começo. Você precisa dos seus dados, das suas permissões e de um recurso limitado a um trabalho. O modelo é um componente.
Os dados dos nossos clientes vão treinar o modelo de outra empresa?
Não deveriam, e não precisam. Fornecedores comerciais oferecem termos que excluem os seus dados do treinamento; modelos de pesos abertos na sua infraestrutura eliminam a pergunta por completo. Decida isso na arquitetura, e diga com clareza no produto.
E as alucinações?
Ancoragem nos seus dados, citação das fontes, dizer “não sei” quando a recuperação volta vazia, e um conjunto de avaliação que mede a taxa. Reduzidas, não eliminadas — e é por isso que o usuário mantém a edição e a ação mantém a comporta. IA responsável é como projetamos isso.
A nossa própria equipe pode construir?
Muitas vezes sim, uma vez que o escopo esteja certo. As partes difíceis são definir o escopo, a preparação dos dados e a avaliação — as partes que um sprint produz, e que um roteiro escrito para ser executado com a gente ou sem a gente entrega à sua equipe.
Como sabemos se funcionou?
Pela métrica que você anexou ao trabalho na primeira seção. Se você não consegue nomeá-la, o recurso não está pronto para ser construído.
Descubra o recurso que compensa primeiro.
Duas semanas com os engenheiros que construiriam: um mapa de oportunidades do seu produto, os dois ou três recursos que vale a pena entregar primeiro, viabilidade contra os seus dados e permissões reais, e um piloto dimensionado para entrar em produção.