Quando (não) usar IA: a decisão de arquitetura
Maturidade é saber quando IA é a ferramenta certa — e quando um if/else resolve melhor.
6 min de leitura
Escolha como aprender
— combine como quiserDica: o vídeo é um resumo visual rápido — o áudio e o texto trazem a aula completa.
A habilidade mais valiosa de um arquiteto de IA não é saber construir agentes — é saber quando não construir. IA resolve problemas reais, mas também cria complexidade, custo e risco desnecessários quando aplicada no lugar errado. Esta aula é sobre julgamento: o critério que separa um sistema bem projetado de um projeto caro que falha silenciosamente.
Onde IA realmente brilha
IA — especialmente LLMs — é extraordinária em problemas onde a resposta correta não cabe em uma regra explícita. Pense em classificar a intenção de uma mensagem de suporte com linguagem ambígua, extrair campos estruturados de um contrato em PDF escaneado, sumarizar 40 páginas de logs de incidente em três parágrafos acionáveis, ou responder perguntas sobre uma base de conhecimento que muda toda semana.
O denominador comum: ambiguidade, linguagem natural, variação de forma com sentido estável. Nesses casos, escrever regras manuais é frágil — você passa semanas cobrindo casos extremos e ainda erra nos novos. Um modelo treinado em linguagem humana generaliza naturalmente.
Outros casos fortes: geração de rascunhos (onde humano revisa), busca semântica (lição 04), classificação difusa com muitas categorias, e síntese de informação distribuída. O padrão é sempre o mesmo: entrada variável, saída tolerável a pequenos erros, e humano ou sistema downstream capaz de absorver imperfeições.
Se o seu problema tem essas características, IA não é hype — é a ferramenta certa.
Onde IA é a escolha errada
Existem três situações em que eu recomendo ativamente não usar IA, e aprendi cada uma delas da forma difícil.
Regra determinística existe e é estável. Se a lógica é if status == 'APPROVED' and amount < 1000: auto_release(), um LLM só adiciona latência, custo e não-determinismo. if/else é mais rápido, testável, auditável e não alucina.
Exatidão crítica sem mecanismo de verificação. Cálculo de imposto, dose de medicamento, transferência financeira — qualquer domínio onde erro custa caro e não há humano ou sistema checando a saída. LLMs erram em aritmética, confundem datas, inventam referências. Se você não tem evals robustos (lição 09) e um guardrail (lição 10) cobrindo o caminho crítico, não coloque IA nesse fluxo.
Custo ou latência não fecham. Um endpoint que precisa responder em 80ms com custo de $0.0001 por chamada não é candidato a um LLM de 70B parâmetros. Faça a conta antes de prototipar. Às vezes um modelo menor, um classificador tradicional, ou simplesmente um índice de busca resolve com 1/100 do custo.
O erro mais comum que vejo: times usando LLM para parsear um JSON que já vem estruturado da API, ou para validar um campo que tem regex de três linhas. Isso é complexidade sem benefício.
Fluxo de decisão: usar IA ou não?
Percorra o fluxo para qualquer requisito antes de escolher a abordagem. Cada nó é uma pergunta real de arquitetura.
- Requisito · chega
- Existe regra · determinística?
- Use if/else · ou regex
- Entrada é ambígua · ou linguagem natural?
- Sistema tolera · erro ocasional?
- Custo/latência · fecham?
- Não use IA · (revisar requisito)
- Padrão híbrido · IA + regra + humano
- IA como · componente principal
- Adicionar evals · e guardrails
Usar IA vs. não usar: análise comparativa
IA como componente principal
- Lida com linguagem natural e ambiguidade sem regras manuais
- Generaliza para casos não previstos no design
- Escala de capacidade sem escalar engenharia de regras
- Não-determinístico: mesma entrada pode gerar saídas diferentes
- Custo por token acumula em volume alto
- Requer evals, guardrails e monitoramento contínuo
Certo para: classificação difusa, extração de texto, síntese, busca semântica, geração com revisão
Lógica determinística (if/else, regex, regras)
- Comportamento 100% previsível e auditável
- Custo marginal próximo de zero em escala
- Testável com testes unitários simples
- Frágil a variações de forma não previstas (linguagem livre)
- Manutenção cresce com a complexidade das regras
- Não escala para domínios abertos
Certo para: validação de campos, roteamento por status, cálculos financeiros, parsing de formatos fixos
Padrão híbrido (IA + regra + humano)
- IA lida com a maioria dos casos; regra cobre os críticos
- Humano entra apenas nos casos de baixa confiança
- Reduz risco sem abrir mão de automação
- Mais componentes = mais superfície de falha para gerenciar
- Requer definir thresholds de confiança e SLAs de revisão humana
Certo para: moderação de conteúdo, triagem médica, aprovação de crédito, qualquer fluxo de alto impacto
O framework de decisão em quatro perguntas
Antes de qualquer linha de código, responda estas quatro perguntas em ordem. Elas funcionam como um filtro — cada resposta negativa encurta o caminho.
1. O problema precisa de não-determinismo? Se a resposta correta é sempre a mesma dado o mesmo input, você não precisa de IA. Um parser, uma query SQL, uma função pura resolvem melhor.
2. O sistema tolera erro ocasional? LLMs erram. Se um erro causa dano financeiro, legal ou de saúde sem mecanismo de contenção, o risco não está justificado — a menos que você adicione verificação obrigatória na saída (evals + humano no loop).
3. Existe fonte de verdade para fundamentar a resposta? Se sim, RAG (lição 06) ou grounding (lição 19) reduzem alucinação. Se não existe fonte e a precisão é crítica, repense a abordagem.
4. O custo por chamada e a latência cabem no SLA e no orçamento? Calcule: volume mensal × tokens médios × preço por token. Compare com o valor gerado. Se a conta não fecha nem com o modelo mais barato do Bedrock (lição 16), o problema pode não ser de IA — ou precisa de uma arquitetura diferente (cache, modelo menor, pré-computação).
Essas quatro perguntas não eliminam a criatividade — elas direcionam energia para onde IA realmente entrega valor.
Na prática, a maioria dos sistemas de produção que funciona bem usa o padrão híbrido: IA processa o caso geral (80-90% do volume), regra determinística bloqueia ou redireciona os casos críticos, e humano revisa os de baixa confiança. Esse padrão não é fraqueza — é engenharia madura. Nunca coloco IA em um caminho crítico sem pelo menos uma camada de verificação determinística depois dela. O modelo pode errar; o sistema não pode.
Como avaliar um requisito novo
- 1
Descreva o problema em uma frase sem mencionar IA
Se a descrição já implica uma regra clara, provavelmente não é caso de IA. Ex.: 'rejeitar pedido se CPF inválido' → regex.
- 2
Liste os casos de falha e seu impacto
Falso positivo custa quanto? Falso negativo? Se ambos custam caro, você precisa de verificação — e talvez IA não seja o componente certo para a decisão final.
- 3
Estime o custo antes de prototipar
Volume × tokens × preço. Adicione latência de rede e cold start se for serverless. Compare com o custo da solução determinística equivalente.
- 4
Defina o critério de sucesso antes do primeiro prompt
Sem métrica de avaliação (lição 09), você não saberá quando parar de iterar. Defina: precisão mínima aceitável, latência máxima, custo por transação.
- 5
Projete o fallback antes do happy path
O que acontece quando o modelo retorna baixa confiança, timeout, ou resposta inválida? Defina isso antes de construir o fluxo principal.
Perguntas frequentes de arquitetura
E se eu não souber o volume antes de produção?
Use o modelo mais barato que atenda à qualidade mínima, adicione cache para entradas repetidas (lição 19), e instrumente tudo desde o dia um. Custo surpresa em IA quase sempre vem de falta de observabilidade, não de volume imprevisto.
Posso usar IA para lógica de negócio crítica se tiver humano revisando?
Sim — esse é o padrão híbrido. A condição é que a revisão humana seja real, com SLA definido, e não um checkbox que ninguém lê. Se o humano aprova tudo sem ler, você não tem revisão — tem teatro de segurança.
Classificador tradicional (ML clássico) vs. LLM: quando usar cada um?
Classificador treinado: quando você tem dados rotulados suficientes, latência < 50ms é requisito, e as categorias são estáveis. LLM: quando as categorias mudam, os dados rotulados são escassos, ou a classificação exige raciocínio sobre contexto amplo. LLM é mais flexível; classificador é mais previsível e barato.
Abrindo o módulo final: do protótipo à produção
Esta aula fecha o ciclo de fundamentos e abre o último módulo da trilha. Você agora tem o mapa completo: entende como modelos aprendem (lições 01-03), como representar e buscar conhecimento (04-06), como conectar IA ao mundo (07-08), como avaliar e proteger sistemas (09-10), como construir agentes (11-15), e como usar a infraestrutura AWS para tudo isso (16-19).
O que falta é a transição do protótipo para um sistema que funciona em produção com usuários reais — e o projeto guiado que consolida tudo isso em prática.
Na lição 21, vamos cobrir o que muda quando você sai do notebook: observabilidade, versionamento de prompts, CI/CD para sistemas de IA, gestão de custos em escala, e os padrões de deployment que funcionam no Bedrock AgentCore. Não é teoria — são as decisões que você vai tomar nas primeiras semanas de cada projeto real.
A lição 22 é o projeto guiado: você vai projetar um sistema RAG + agente do zero, tomando cada decisão de arquitetura com os critérios que aprendeu aqui. Inclui um exame final que testa julgamento, não memorização.
Maturidade em IA não é saber usar todos os recursos — é saber escolher os certos para o problema certo, com os trade-offs explícitos. Você chegou lá.
Checagem rápida
1. Qual caso é o MENOS indicado para IA generativa?
Veredicto do arquiteto
IA é uma ferramenta poderosa com um perfil de risco específico: não-determinística, cara em escala, e silenciosamente errada quando falha. Use-a onde a ambiguidade e a linguagem natural tornam regras manuais impraticáveis. Evite-a onde a exatidão é crítica sem verificação, onde a regra já existe, ou onde o custo não fecha. O padrão híbrido — IA para o caso geral, regra para o crítico, humano para o incerto — é a arquitetura mais madura que conheço para sistemas de produção. Julgamento é o que diferencia um arquiteto de alguém que só sabe usar a API.