Adicionar um modelo de linguagem a um produto parece, no começo, um problema de prompt. Define-se uma instrução, envia-se contexto, recebe-se texto e a demonstração ganha vida. O salto entre uma demonstração convincente e um sistema confiável começa quando a resposta deixa de ser o produto inteiro e passa a ser apenas uma parte dele.
Modelos são probabilísticos. Regras de negócio, saldos, permissões, progressão de jogo e transições de estado não deveriam ser. A arquitetura precisa reconhecer essa diferença antes que um prompt muito bem escrito esconda uma fronteira mal desenhada.
O modelo é um componente, não o sistema
Uma integração saudável trata a IA como uma capacidade especializada: interpretar uma intenção, sugerir uma resposta, resumir contexto, classificar uma mensagem ou produzir uma possibilidade narrativa. Ao redor dela continuam existindo identidade, autorização, estado, políticas, telemetria e mecanismos de recuperação.
Essa separação muda a pergunta. Em vez de “como fazer o modelo obedecer sempre?”, a equipe passa a perguntar:
- qual contexto o modelo realmente precisa receber;
- quais ações ele pode apenas sugerir;
- quais ações exigem validação determinística;
- quando a resposta deve ser bloqueada ou encaminhada;
- como reconstruir o que aconteceu depois de uma falha;
- como uma pessoa assume o fluxo sem perder contexto.
O prompt continua importante, mas deixa de carregar responsabilidades que pertencem ao restante do software.
1. Mantenha o estado autoritativo fora da IA
No AI_VTT, o mestre pode narrar uma porta secreta, interpretar um personagem e reagir a uma escolha inesperada. Ele não deve decidir sozinho quantos pontos de vida restaram, se o movimento alcança uma casa ou qual resultado saiu no dado. Essas informações pertencem ao motor de regras e ao estado persistido da campanha.
O padrão serve fora dos jogos. Um assistente comercial pode sugerir que um lead está qualificado, mas a mudança de etapa no CRM deve passar por uma ação conhecida e auditável. Um agente financeiro pode explicar uma intenção de ordem, mas jamais substituir gates de risco e autorização.
Linguagem pode ser probabilística. Consequências críticas precisam de uma fronteira determinística.
Uma resposta da IA pode virar um comando proposto. O sistema valida identidade, estado atual, regras e limites; somente então a transição é aplicada. Se a validação falhar, a proposta é descartada sem corromper o fluxo principal.
2. Trate contexto como contrato
Enviar “tudo o que sabemos” parece conveniente, mas aumenta custo, latência e risco. Contexto deve ser montado para uma tarefa específica, com origem e validade conhecidas.
Um contrato útil distingue pelo menos quatro grupos:
- identidade: quem está pedindo e quais permissões possui;
- estado: fatos atuais necessários para a decisão;
- política: o que a capacidade pode ou não pode fazer;
- histórico: somente a janela relevante para manter continuidade.
Essa estrutura reduz contradições e facilita testes. Se a resposta ficou ruim, é possível investigar se o problema veio da instrução, de um fato ausente, de uma política ambígua ou do comportamento do modelo.
Também evita que texto produzido anteriormente ganhe autoridade por acidente. Uma descrição narrativa pode entrar no histórico como conteúdo; uma alteração real de inventário só entra no estado quando o motor responsável confirma.
3. Coloque política antes e depois do modelo
Guardrail não é uma frase no fim do prompt. É uma sequência de decisões ao redor da chamada.
Antes do modelo, o sistema pode limitar ferramentas disponíveis, remover dados desnecessários, verificar permissões e escolher uma rota especializada. Depois da resposta, pode validar formato, referências, comandos propostos e condições de negócio.
Há uma diferença importante entre validação sintática e validação de domínio. Confirmar que uma resposta possui um campo “horário” não prova que o horário está disponível, pertence à unidade correta ou respeita a duração do serviço. O modelo pode estruturar a intenção; o domínio continua responsável pela verdade operacional.
No Auto Whats, isso significa que uma conversa pode produzir uma sugestão de agendamento ou qualificação. A aplicação ainda precisa consultar os dados corretos, aplicar políticas e registrar a mudança por um caminho explícito.
4. Faça o handoff humano nascer junto do fluxo
Transferir para uma pessoa não deveria ser o botão de pânico adicionado depois do lançamento. Em muitos produtos com IA, é uma rota normal.
Um bom handoff entrega ao operador:
- o objetivo que a pessoa tentou alcançar;
- os fatos usados pela automação;
- as ações já executadas;
- o ponto de incerteza ou bloqueio;
- um resumo curto da conversa;
- a capacidade de continuar sem pedir tudo novamente.
Também precisa interromper a automação de maneira inequívoca. Dois agentes respondendo ao mesmo tempo destroem confiança rapidamente. Por isso o Auto Whats trata o controle da IA por conversa e a passagem ao humano como parte central da experiência.
5. Observe decisões, não apenas respostas
Avaliar somente se um texto “parece bom” é insuficiente. O sistema precisa registrar entradas relevantes, versão de política, modelo utilizado, ferramentas chamadas, validações, latência, custo e desfecho.
Isso não significa guardar conteúdo sensível indiscriminadamente. Telemetria também precisa de minimização e retenção consciente. O objetivo é reconstruir decisões e encontrar padrões de falha sem transformar observabilidade em coleta sem limite.
Alguns sinais úteis dependem do produto:
- taxa de handoff e motivo da transferência;
- respostas bloqueadas por política;
- comandos propostos que falharam na validação;
- correções feitas pelo operador;
- latência até a primeira ação útil;
- continuidade depois de uma retomada de sessão;
- custo por fluxo concluído, não apenas por chamada.
Uma arquitetura mínima para IA aplicada
Uma vertical pequena já pode preservar as fronteiras certas:
- a interface registra uma intenção;
- o serviço autentica e monta contexto mínimo;
- a camada de política escolhe capacidade e ferramentas;
- o modelo produz texto ou uma proposta estruturada;
- validadores determinísticos verificam formato e domínio;
- o sistema aplica a ação, pede confirmação ou transfere ao humano;
- a telemetria registra o caminho e o resultado.
Nem todo fluxo precisa das sete etapas com a mesma complexidade. O valor está em saber onde cada responsabilidade mora. Essa clareza permite trocar modelo, provedor ou estratégia de prompt sem reescrever o domínio inteiro.
Três projetos, o mesmo princípio
Os experimentos da TestaAí usam o princípio de formas diferentes.
No AI_VTT, a IA controla narração e interpretação; regras e campanha permanecem autoritativas. No Auto Whats, a IA acelera atendimento; o operador mantém visibilidade e pode assumir. No Project Renaissance, o componente inteligente pode apoiar pesquisa, mas execução continua atrás de OMS, risco e habilitação explícita.
As tecnologias mudam. A decisão permanece: capacidades probabilísticas não recebem autoridade silenciosa sobre consequências críticas.
Checklist antes de integrar um modelo
Antes de escrever o primeiro prompt de produção, vale responder:
- qual é a tarefa estreita do modelo;
- quais dados são necessários e quais devem ficar de fora;
- onde vive o estado verdadeiro;
- quais ferramentas podem ser chamadas;
- quem valida uma ação proposta;
- como o fluxo falha com segurança;
- quando e como uma pessoa assume;
- o que será observado para melhorar qualidade;
- como trocar modelo ou provedor sem quebrar o domínio.
Se essas respostas ainda estão misturadas dentro do prompt, o risco não é apenas uma resposta ruim. É um sistema sem fronteiras.
IA aplicada fica mais interessante quando deixa de ser truque central e passa a operar como uma parte bem desenhada do produto. O modelo amplia a experiência. A arquitetura preserva confiança.
Veja o mapa técnico dos experimentos e conheça o perfil de engenharia por trás do laboratório.
