Cenários com IA em produção

O problema

Muita feature com IA nasce de um jeito meio infantil:

• alguém vê uma demo boa
• o time escolhe um modelo
• sobe uma integração
• e chama isso de estratégia

Enquanto o caso feliz funciona, parece ótimo.

O problema aparece quando o sistema encontra o mundo real:

• o modelo demora mais do que a interface aguenta
• a resposta vem em formato diferente
• a qualidade cai em um tipo de caso importante
• o custo dispara
• o modelo erra com muita confiança

É nessa hora que fica claro que “colocar IA” não era o trabalho principal.

O trabalho principal era desenhar um produto que continua confiável mesmo quando a IA se comporta como IA.

Modelo mental

O jeito mais útil de pensar nesse cenário é este:

feature com IA é um componente probabilístico dentro de um sistema que o usuário ainda espera que seja confiável.

Essa frase limpa boa parte da confusão.

Seu backend continua precisando de contrato.

Sua interface continua precisando de resposta em tempo razoável.

Seu produto continua precisando proteger confiança do usuário.

Então a pergunta central deixa de ser:

• qual modelo é mais impressionante?

E vira:

• qual tipo de erro eu aceito?
• qual erro é inaceitável?
• o que acontece quando a IA falha, atrasa ou responde algo ruim?

Quebrando o problema

Primeiro defina o papel da IA

Nem toda feature com IA tem o mesmo risco.

Compare estes casos:

• resumir um ticket longo
• sugerir texto para e-mail
• classificar prioridade de incidente
• responder automaticamente para cliente

Nos dois primeiros, o usuário ainda pode revisar fácil.

Nos dois últimos, o erro pode virar dano operacional ou perda de confiança mais rápido.

Então a primeira decisão não é técnica. É de produto:

• a IA está assistindo, recomendando ou decidindo?

Quanto mais irreversível a ação, menos espaço existe para deixar o modelo operar sozinho.

Depois defina o erro perigoso

Esse passo quase sempre separa time maduro de time empolgado demais.

Você precisa saber:

• qual erro é só chato
• qual erro é caro
• qual erro destrói confiança

Se a feature resume tickets, talvez o erro perigoso seja omitir uma ação pendente importante.

Se a feature classifica fraude, talvez o erro perigoso seja liberar o caso errado sem revisão.

Sem essa clareza, o restante da arquitetura fica genérico demais.

Contrato de saída importa

Muita gente trata saída de modelo como texto livre e torce para dar certo.

Em produção, isso é frágil.

O sistema precisa de alguma combinação de:

• schema esperado
• validação da resposta
• tratamento quando o formato vier errado
• fallback quando a saída for inutilizável

Isso vale até quando a resposta final é texto. Porque a interface, o analytics e os fluxos internos ainda dependem de previsibilidade mínima.

Fallback não é detalhe

Se o modelo:

• der timeout
• devolver resposta ruim
• ultrapassar custo
• ou falhar por indisponibilidade

o produto precisa continuar respirando.

Fallback pode ser:

• esconder o recurso
• mostrar conteúdo parcial
• voltar para fluxo manual
• pedir revisão humana
• usar regra determinística mais simples

O ponto é simples: o usuário não pode ficar preso ao humor do modelo.

Avaliação e observabilidade entram cedo

Feature com IA sem medição vira discussão de opinião.

Você precisa observar pelo menos:

• qualidade percebida
• taxa de fallback
• latência
• custo
• taxa de erro por tipo de caso
• versão de prompt, contexto ou modelo que gerou a resposta

Isso é o que permite saber se a feature realmente ajuda ou só parece moderna em demo.

Se a qualidade piora depois de trocar modelo, prompt ou contexto, você precisa conseguir localizar essa mudança.

Senão toda discussão vira impressão.

Exemplo simples

Imagine uma feature para resumir conversas longas de suporte para o atendente.

A resposta fraca seria:

“Eu mando todo o texto para um LLM, recebo o resumo e mostro na tela.”

A resposta madura seria:

“Eu trataria a IA como assistente, não como fonte única da verdade. O sistema recebe a conversa, prepara contexto relevante e pede um resumo estruturado. Eu valido formato, monitoro latência e limito custo. Se a resposta vier ruim, atrasar demais ou falhar, a interface esconde o resumo e mantém o fluxo original disponível. Eu também avalio qualidade com casos de referência para garantir que o resumo não omita ações pendentes nem invente tom que não existia.”

Essa segunda resposta é melhor porque ela:

• define o papel da IA
• reconhece erro perigoso
• coloca fallback
• fala de avaliação e operação

Erros comuns

• Falar só de prompt e não falar de produto.
• Escolher modelo antes de definir erro tolerável.
• Tratar fallback como detalhe de UX para depois.
• Ignorar custo e latência como se fossem problema de infraestrutura isolado.
• Confiar em resposta bonita sem schema, validação ou medição.

Como um senior pensa

Quem já viu feature com IA em produção costuma ser menos deslumbrado e mais defensivo.

A conversa não gira em torno de “o modelo é inteligente”.

Ela gira em torno de:

• onde ele ajuda de verdade
• onde ele não pode operar sozinho
• como o sistema absorve falha
• como o time percebe regressão antes do usuário perceber

Isso parece menos glamouroso.

Mas é exatamente o que faz a feature sobreviver fora da demo.

O que o entrevistador quer ver

Nesse cenário, o entrevistador quer ver se você:

• entende IA como dependência probabilística
• sabe ligar qualidade de saída a risco de negócio
• fala de fallback, validação e observabilidade com naturalidade
• reconhece custo e latência como parte do design
• evita a postura ingênua de “é só colocar um modelo”

Feature com IA em produção não é a que parece mágica. É a que continua útil quando o modelo atrasa, falha ou responde mal.

Quando você projeta controle antes de projetar brilho, a arquitetura começa a parecer real.