Como Adicionar Recursos de IA ao Seu App

Para adicionar recursos de IA ao seu app, chame uma API de modelo de linguagem (LLM) a partir do seu servidor: envie instruções claras mais os dados relevantes e use o que voltar. A maioria dos recursos úteis segue um de quatro padrões — resumir, conversar, extrair dados estruturados e classificar — e cada um é algumas dezenas de linhas de código que um construtor com IA pode escrever para você. O trabalho que decide se o recurso é bom está ao redor da chamada: manter a chave da API no servidor, controlar o custo por usuário e checar a saída antes de confiar nela.

Os quatro padrões por trás da maioria dos recursos de IA

Extração e classificação costumam ser as mais valiosas e as menos visíveis. Elas economizam discretamente alguns minutos de alguém em cada registro e, como a saída tem formato fixo, você consegue verificá-la automaticamente. O chat é o mais visível, mas o mais difícil de acertar, e tem um guia próprio: como criar um app de chatbot com IA.

Como isso se encaixa no seu app

Todo padrão tem a mesma forma:

1. O usuário age — clica em “Resumir”, envia um arquivo, manda uma mensagem.
2. O seu front end chama o seu próprio servidor, e não o provedor de IA.
3. O seu servidor monta a requisição: instruções do sistema, a entrada do usuário e os dados que o modelo precisa do seu banco — apenas dados que este usuário tem permissão de ver.
4. O seu servidor chama a API do LLM com uma chave guardada em uma variável de ambiente.
5. O seu servidor verifica a resposta — JSON válido, um rótulo conhecido, um tamanho razoável — e então salva ou devolve o resultado.
6. O front end exibe o resultado, transmitindo o texto conforme chega em respostas mais longas.

A chave fica no servidor no passo 4 e nunca chega ao navegador. Se a ideia de API é nova para você, o que é uma API é uma introdução curta, e como usar APIs de LLM explica tokens, modelos e chaves com mais profundidade.

Escolhendo um provedor e um modelo

Os principais provedores — OpenAI, Anthropic, Google e outros — oferecem APIs de texto com formatos bem parecidos. Perguntas úteis na hora de escolher:

• Qualidade na sua tarefa. Teste alguns exemplos reais do seu app em dois ou três modelos. As diferenças costumam ser mais claras nos seus dados do que em benchmarks gerais.
• Tamanho versus custo. Os provedores oferecem modelos maiores e mais capazes e modelos menores, mais baratos e mais rápidos. Classificação e extração simples costumam funcionar bem em um modelo pequeno; raciocínio longo ou escrita mais nuançada podem exigir um maior.
• Saída estruturada. Para extração e classificação, prefira um recurso da API que faça o modelo devolver JSON no formato de um esquema que você fornece, em vez de interpretar texto livre.
• Tratamento de dados. Leia os termos do provedor sobre se as entradas da API são armazenadas ou usadas para treinamento, e se isso combina com os dados que os seus usuários enviam.
• Limites. Contas novas costumam ter limites de taxa mais baixos; confira-os antes do lançamento.

Modelos e preços mudam com frequência, então o código deve ler o nome do modelo a partir de uma configuração, em vez de deixá-lo fixo em vários lugares.

Adicionando um recurso, passo a passo

Vamos a um exemplo concreto: um pequeno CRM em que cada contato tem um longo histórico de notas.

1. Guarde a chave. Crie uma chave no painel do seu provedor e salve-a como segredo do lado do servidor, por exemplo OPENAI_API_KEY ou ANTHROPIC_API_KEY.

2. Peça um recurso bem específico:

Adicione um botão “Resumir” na página do contato. No servidor, envie as últimas 20 notas do contato para [PROVEDOR], usando o segredo [NOME_DA_VARIÁVEL], com instruções para escrever três tópicos: situação atual, perguntas em aberto e próximo passo. Inclua apenas as notas que o usuário logado pode ver. Mostre um estado de carregamento, salve o resumo com data e hora e exiba “Não foi possível resumir agora” se a chamada falhar. Nunca envie a chave ao navegador.

3. Adicione extração onde ela economiza digitação:

Quando o usuário colar uma assinatura de e-mail na caixa “Adição rápida”, chame [PROVEDOR] no servidor e devolva um JSON com nome, empresa, cargo, e-mail e telefone, usando o recurso de saída estruturada do provedor. Valide o JSON no servidor, preencha com ele o formulário de novo contato e deixe o usuário editar antes de salvar. Deixe os campos em branco em vez de adivinhar.

“Deixar o usuário editar antes de salvar” é a parte importante: o modelo propõe, a pessoa decide.

4. Classifique em segundo plano:

Quando um novo chamado de suporte chegar, classifique-o em exatamente uma destas opções: cobrança, bug, solicitação de recurso, acesso à conta, outros. Use um modelo pequeno e de baixo custo. Se a resposta não for um desses rótulos, salve “outros”. Mostre o rótulo como uma tag editável.

5. Teste com dados reais e bagunçados — notas longas, notas vazias, outros idiomas, uma assinatura sem telefone — e compare vinte saídas lado a lado antes de lançar.

Escrevendo instruções que funcionam

As instruções que você envia em cada requisição (muitas vezes chamadas de prompt do sistema) são de onde vem a qualidade.

• Diga para quem é e o que é um bom resultado. “Os resumos são lidos por um vendedor em 10 segundos antes de uma ligação” dá ao modelo um alvo.
• Fixe o formato. Número exato de tópicos, limite de tamanho, campos, rótulos.
• Diga o que fazer quando não souber. “Se as notas não mencionarem um próximo passo, escreva ‘Nenhum próximo passo registrado’.” Isso reduz respostas inventadas.
• Dê dois ou três exemplos de boa entrada e boa saída para extração e classificação.
• Mantenha as instruções separadas do conteúdo do usuário e rotule claramente o conteúdo do usuário, para que o modelo consiga diferenciá-los.

Guarde os prompts em arquivos no seu código, para que sejam versionados e revisáveis como qualquer outro código.

Mantendo os custos sob controle

As APIs de LLM cobram por tokens — pequenos trechos de texto — tanto pelo que você envia quanto pelo que volta. O custo cresce com a quantidade de contexto por requisição multiplicada pela frequência com que ela roda. Controles práticos:

• Envie apenas o necessário. As últimas 20 notas, e não o histórico inteiro. Corte documentos longos ou divida-os.
• Use o menor modelo que faz o trabalho. Teste antes de partir para o maior.
• Limite o tamanho da saída com a configuração de máximo de tokens da API.
• Use cache de resultados. Guarde um resumo e só o gere de novo quando a origem mudar, em vez de gerá-lo a cada visualização de página.
• Limite por usuário. Um teto diário por conta ou por plano impede que um usuário pesado, ou um script, aumente a conta.
• Aplique limite de taxa no endpoint, como em qualquer rota cara.
• Defina um orçamento ou alerta no painel do provedor e confira o uso semanalmente após o lançamento.
• Registre o uso de tokens por recurso para saber quanto cada um custa.

Se os recursos de IA são centrais no seu produto, inclua o custo de execução deles no seu preço em vez de absorvê-lo.

Segurança e confiança

A saída da IA é probabilística. Ela pode estar errada mesmo soando confiante, e pode ser manipulada pelo texto que lê. Construa levando isso em conta:

• Trate a saída como entrada não confiável. Valide a estrutura, escape-a antes de renderizar como HTML e nunca a execute como código ou consulta ao banco.
• Mantenha uma pessoa no circuito em qualquer coisa com consequências — enviar um e-mail, alterar um registro, reembolsar um pagamento. O modelo rascunha; uma pessoa confirma.
• Proteja-se contra prompt injection. Um documento ou mensagem pode conter texto como “ignore suas instruções”. Limite o que o modelo pode ver ao que o usuário atual pode ver, e não dê a ele ferramentas que executem ações sensíveis sem que o seu código verifique as permissões antes.
• Identifique o conteúdo de IA para que os usuários saibam que um resumo ou sugestão foi gerado e possam conferi-lo.
• Trate as falhas com elegância. Provedores têm instabilidades e limites de taxa. Defina tempo limite, mostre uma mensagem clara e deixe o restante do app funcionando.
• Observe o que os usuários enviam. Para campos de texto livre, considere uma etapa de moderação e deixe claro na sua política de privacidade que o conteúdo é processado por um provedor terceiro de IA.

A lista mais ampla de verificações está na lista de verificação de segurança para apps criados com IA.

Erros comuns

• Começar com um chatbot geral quando um único botão “Resumir” ou “Categorizar” ajudaria mais pessoas.
• Colocar a chave no código do front end ou em um repositório público.
• Enviar o banco de dados inteiro como contexto, o que é lento, caro e arrisca expor dados de outros usuários.
• Confiar em saídas de texto livre quando um esquema ou um conjunto fixo de rótulos tornaria a saída verificável.
• Não ter limites por usuário, descobertos quando chega a primeira fatura.

Adicionando recursos de IA com o Mythex

No Mythex, você adiciona IA dentro do próprio app pedindo no chat, usando a sua chave do provedor. Guarde a chave como segredo do projeto — quando o agente precisar dela, o Mythex mostra um cartão de segredos no chat para que você não cole a chave na conversa — e o agente escreve a rota do servidor, os prompts e a interface. O uso de IA do seu app é cobrado pelo seu provedor, separado dos créditos do Mythex que você gasta na criação. A documentação tem um prompt inicial em adicione recursos de IA com suas próprias chaves de API.

Perguntas