O modelo é a menor parte do sistema

Quando uma aplicação de IA falha, trocar o modelo é uma resposta tentadora. A troca é visível, cabe em uma comparação de versões e parece resolver o problema no centro. Mas a falha pode ter começado antes da geração da resposta: uma definição ausente, uma consulta incompleta, uma permissão mal desenhada. Pode também ter surgido depois, quando uma sugestão foi tratada como autorização para agir.

Dizer que o modelo é a menor parte do sistema é uma provocação sobre responsabilidade. Sua capacidade importa e precisa ser avaliada. Ela não substitui as decisões que ligam uma pergunta ao trabalho da empresa. Um produto útil precisa saber o que consultar, o que pode fazer, quando parar e como tornar uma resposta examinável por outra pessoa.

O pedido e o que acompanha o pedido

A primeira camada é a instrução. Se o problema desaparece quando a tarefa é descrita com clareza, talvez não seja necessário acrescentar uma nova ferramenta. O pedido deve dizer qual saída é esperada, que critérios importam e como lidar com informação ausente. Instruções vagas deixam decisões importantes implícitas.

A segunda camada é o contexto. Uma boa pergunta não corrige uma fonte errada. Precisamos escolher quais documentos, registros e definições acompanham a tarefa, em que ordem são usados e como reconhecer conflitos. Mais informação pode ajudar ou apenas acrescentar versões incompatíveis. O contexto deve ter uma função no raciocínio, não ocupar espaço por estar disponível.

Em um trabalho de apoio ao atendimento, a ordem de consulta foi parte central da solução: primeiro o procedimento aplicável, depois os precedentes, por fim o contexto específico do solicitante. A resposta vinha preparada para revisão, com a referência que a sustentava. A arquitetura preservava a responsabilidade humana pelas decisões; não dependia de o texto final soar prudente.

Permissão é uma propriedade do sistema

A terceira camada é o ambiente de execução: ferramentas disponíveis, acessos, validações e comportamento diante de falhas. Uma instrução para não alterar dados é insuficiente se a aplicação entrega, sem necessidade, uma credencial capaz de alterá-los. A permissão deve existir no serviço que executa a ação. O mesmo vale para limites de uso e para a obrigação de obter uma aprovação.

Essa camada também precisa distinguir uma resposta vazia de uma resposta válida. Em um projeto que conciliava registros entre sistemas, um campo solicitado com o nome errado retornava vazio sem interromper a integração. Parte do trabalho projetado desaparecia do cálculo. Um texto bem escrito sobre o resultado não teria corrigido a ausência. Foi necessário rastrear a origem, reparar a leitura e conferir novamente os registros.

Por isso, quando uma resposta depende de uma métrica certificada, separamos o cálculo da explicação. A regra de negócio é explícita e testável; o modelo pode ajudar a localizar a visão adequada e explicar o resultado. Essa escolha não garante qualidade sozinha. A consulta, os filtros, o período e a definição da métrica continuam precisando de verificação.

Repetir e coordenar têm um custo

A quarta camada aparece quando a tarefa exige tentar, observar e corrigir. Um ciclo desses precisa de um sinal de conclusão, limite de tentativas e destino para a falha. Repetir até a resposta parecer convincente não é um critério de sucesso. Em alguns trabalhos, a saída correta será interromper a execução e pedir esclarecimento.

A quinta camada coordena caminhos diferentes: etapas em paralelo, aprovações obrigatórias e resultados que alimentam outras etapas. Nem toda etapa precisa de um modelo. Uma regra conhecida pode permanecer uma regra; uma conta pode permanecer uma conta. Essa coordenação é útil quando representa a estrutura real do trabalho. Acrescentá-la para compensar um contexto mal definido apenas distribui a mesma ambiguidade por mais componentes.

A fronteira precisa aparecer na avaliação

Em uma avaliação conduzida pela equipe, configurações alternativas foram comparadas em tarefas reais, com critérios definidos antes dos testes. O que interessava era a possibilidade de usar a resposta e o esforço de edição necessário. Uma boa posição naquele conjunto não seria licença para generalizar a todos os trabalhos. O resultado precisava acompanhar suas fontes, instruções e condições de uso.

É esse cuidado que orienta nossa sequência de diagnóstico: esclarecer o pedido, conferir o contexto, limitar a execução e só então acrescentar ciclos ou coordenação. A solução pode terminar simples. Também pode exigir uma arquitetura extensa, desde que cada parte responda a uma necessidade observável.

O modelo participa da resposta. A empresa continua responsável por definir o que essa resposta autoriza, como será conferida e quem assume a decisão seguinte.