IA como camada, não como fundação

O modelo não deve controlar o que precisa ser verdadeiro

Modelos de linguagem são excelentes para interpretar texto, extrair intenção, resumir contexto e lidar com entradas que variam demais para um formulário tradicional. Eles não são a melhor ferramenta para decidir se um usuário pode acessar um registro, calcular um total financeiro ou confirmar que uma operação foi concluída.

Essa separação parece óbvia no papel, mas desaparece quando a primeira demonstração funciona. O protótipo recebe uma frase, retorna uma resposta convincente e cria a sensação de que toda a arquitetura pode ficar ao redor do prompt. Em produção, a pergunta muda. Não basta responder bem. É preciso saber de onde veio o dado, o que acontece quando o modelo falha e qual regra continua válida sem ele.

No FalaFit, por exemplo, a IA interpreta a refeição descrita por voz. A autenticação, o limite de uso, a persistência, o vínculo com o usuário e o cálculo sobre uma porção estruturada continuam fora do modelo. No Dossiê de Empresa, a camada pública de cadastro e sinais objetivos funciona sem IA. A análise inteligente acrescenta leitura, mas não controla o acesso aos fatos.

A fronteira boa é pequena e explícita

Quanto maior a responsabilidade entregue ao modelo, mais difícil fica explicar um erro. Prefiro uma fronteira estreita: a aplicação prepara um contexto conhecido, pede uma transformação específica e valida a forma da resposta antes de aceitá-la.

Isso também melhora a evolução. É possível trocar o modelo, ajustar um prompt ou introduzir cache sem reescrever o domínio inteiro. O produto conhece alimentos, refeições, empresas, campanhas ou transcrições. O modelo conhece uma tarefa temporária dentro desse produto.

Estruturas tipadas ajudam. O retorno esperado deve ser um objeto verificável, não um parágrafo que outra parte do sistema tenta interpretar depois. Se um campo obrigatório falta, a aplicação sabe que não recebeu uma resposta válida. Se o modelo estiver indisponível, a falha ganha um estado compreensível.

Falhar bem faz parte da experiência

Todo recurso de IA precisa de uma resposta para três situações: demora, indisponibilidade e resultado insuficiente. A interface não deveria fingir que essas situações são iguais. Uma transcrição ainda pode ser útil mesmo quando a formatação falha. Um dossiê público continua relevante sem a análise opcional. Uma refeição em fila pode ser processada quando a conexão voltar.

Esse desenho reduz a sensação de aleatoriedade. O usuário entende o que foi preservado, o que ainda está em processamento e o que precisa de uma nova tentativa. A equipe também ganha sinais melhores para depurar o problema.

A degradação graciosa não é um remendo. É uma decisão de produto que define qual valor permanece disponível quando a camada mais sofisticada não responde.

Qualidade precisa de critérios fora do prompt

Avaliar uma funcionalidade de IA apenas pela impressão de uma resposta é insuficiente. Eu procuro critérios que a aplicação consiga observar: o objeto passou pela validação, os campos essenciais existem, a origem está registrada, o usuário corrigiu o resultado, a etapa precisou de nova tentativa.

Nem toda métrica precisa nascer como um sistema complexo. Uma amostra de entradas reais, erros classificados e correções frequentes já mostra onde o pipeline está frágil. O importante é não tratar fluência como sinônimo de precisão.

Quando a arquitetura separa interpretação de verdade operacional, a inteligência artificial pode evoluir rapidamente sem tornar o restante do produto instável.

Perguntas que faço antes de adicionar IA

• A tarefa realmente exige interpretação ou uma regra resolveria melhor?
• Qual valor continua disponível se o modelo não responder?
• A saída possui estrutura e validação explícitas?
• O usuário consegue corrigir ou contestar o resultado?
• Existe registro suficiente para entender erros e custo?