IA só entra na operação quando o controle vem junto.

IA funciona na operação quando existe uma tarefa adequada, dados permitidos, limites claros, avaliação repetível e uma saída segura para o humano. Sem esses controles, uma demonstração convincente pode apenas acelerar erro e dificultar auditoria.

O primeiro diagnóstico não é “qual modelo usar?”. É “qual decisão estamos tentando apoiar, qual consequência existe se a resposta estiver errada e como saberemos que o comportamento continua aceitável?”.

Comece separando quatro tipos de tarefa

1. Transformação de linguagem

Resumir, classificar, extrair campos ou adaptar tom são tarefas em que o modelo transforma informação já disponível. Ainda pode haver erro, mas a decisão principal pode permanecer em regras ou revisão humana.

Exemplo: organizar uma mensagem recebida em categoria, urgência e campos sugeridos para um atendente confirmar.

2. Recuperação de informação

O modelo localiza e apresenta conteúdo de uma base autorizada. A qualidade depende de fonte, atualização, permissão e capacidade de admitir que não encontrou resposta.

Exemplo: responder uma dúvida de procedimento usando documentos aprovados e apontar a fonte.

3. Recomendação

O sistema propõe uma ação, mas outra camada decide. Aqui entram critérios de confiança, alternativas e explicação suficiente para revisão.

Exemplo: sugerir a próxima pergunta de atendimento com base no estado do fluxo, sem enviar automaticamente.

4. Ação

O agente altera estado, envia mensagem, cria pedido, agenda, cancela ou movimenta dinheiro. Esse é o nível de maior exigência porque uma saída textual vira consequência no mundo real.

Quanto maior a autonomia, mais fortes precisam ser autorização, idempotência, observabilidade, limites e reversão.

Nem toda tarefa precisa de IA

Se a regra é estável e expressável, código determinístico costuma ser mais barato de testar e explicar. Use IA onde existe variação de linguagem, ambiguidade tolerável ou volume que justifica classificação e assistência.

Uma arquitetura responsável pode combinar:

• regras para elegibilidade e limites;
• busca para contexto autorizado;
• modelo para linguagem ou classificação;
• validação estrutural da saída;
• humano para exceção ou decisão crítica.

Isso evita transformar o modelo em árbitro universal.

Defina o contrato antes do prompt

Um caso de uso operacional precisa de um contrato explícito:

• entradas permitidas;
• fontes que podem ser consultadas;
• saída esperada;
• decisões proibidas;
• condição para pedir mais contexto;
• condição para escalar;
• tempo máximo;
• registro necessário;
• dados que não podem entrar no modelo ou nos logs.

O prompt é uma implementação parcial desse contrato. Ele não substitui validação, permissão ou regra de negócio.

Estruture a saída

Texto livre é difícil de integrar. Quando o resultado alimenta outro sistema, peça um formato estruturado e valide antes de agir.

Uma classificação pode retornar:

categoria
confianca
campos_encontrados
campos_ausentes
acao_sugerida
motivo_de_escalacao

A aplicação deve rejeitar campos desconhecidos, valores fora do domínio e ações não autorizadas. Confiança declarada pelo próprio modelo não é prova de correção; é apenas um sinal que pode participar da política.

Crie cenários antes de colocar no fluxo

Uma avaliação útil representa o que pode acontecer:

• solicitação comum;
• informação incompleta;
• contradição;
• usuário insistente;
• dado inexistente;
• tentativa de obter informação proibida;
• mudança de assunto;
• linguagem informal;
• dependência indisponível;
• necessidade de handoff.

Cada cenário precisa de rubrica: o que é obrigatório, aceitável e proibido. “A resposta parece boa” não é uma métrica reproduzível.

Meça falhas por categoria

Uma taxa média esconde riscos diferentes. Separe:

• erro factual;
• instrução não seguida;
• ação indevida;
• omissão de aviso;
• exposição de dado;
• falha de ferramenta;
• loop;
• escalonamento tardio;
• tom inadequado;
• resposta inconsistente entre execuções.

O peso de cada categoria depende do contexto. Uma pequena variação de estilo pode ser irrelevante; inventar preço, prazo ou política pode bloquear o uso.

Handoff humano é parte do produto

Escalar não é exibir “fale com um atendente” e encerrar. O handoff precisa transportar:

• motivo do escalonamento;
• resumo do que aconteceu;
• dados já confirmados;
• campos ainda ausentes;
• ações executadas;
• fontes consultadas;
• nível de urgência;
• próximo passo sugerido.

Também deve existir um caminho quando nenhum humano está disponível. A automação precisa informar expectativa real e evitar continuar tomando decisões fora do limite.

WhatsApp exige controles adicionais

Um agente de WhatsApp atua em canal imediato, informal e associado a uma pessoa. Isso amplia riscos de privacidade, consentimento, duplicidade e expectativa.

Antes de automatizar:

• confirme a origem e a finalidade do contato;
• limite dados persistidos;
• não envie texto livre para analytics;
• trate reenvio e webhook repetido;
• respeite janela e política do canal;
• permita interrupção e saída;
• deixe claro quando existe automação;
• registre handoff sem expor conversa bruta desnecessariamente.

Se o agente consulta catálogo, preço ou disponibilidade, a fonte precisa ser autorizada e atual. Quando a fonte não responde, o modelo não deve preencher a lacuna.

Execute em shadow antes de conceder ação

No modo shadow, a automação recebe entradas semelhantes às reais e produz decisões, mas não executa a ação final. A equipe compara saída, política e decisão humana.

Esse estágio ajuda a descobrir:

• casos não representados;
• dependência instável;
• regra ambígua;
• rubrica insuficiente;
• latência;
• custo;
• dados indevidos no contexto.

Shadow não é produção e não prova impacto comercial. É uma etapa de avaliação controlada.

Trate cada mudança como possível regressão

Modelo, prompt, ferramenta, base de conhecimento e regra podem mudar o comportamento. Registre versão e execute novamente o conjunto de cenários.

Uma atualização só avança quando:

1. os cenários críticos continuam aprovados;
2. nenhuma categoria bloqueadora piorou;
3. diferenças relevantes foram revisadas;
4. o rollback está disponível;
5. limitações conhecidas foram atualizadas.

Avaliar apenas exemplos novos cria um viés: corrige o último problema e pode reabrir os anteriores.

Evidência publicável: um laboratório, não produção

O Agent Reliability Lab é um laboratório de confiabilidade para agentes conversacionais, com cenários estruturados, execução shadow, rubricas, taxonomia de falhas e relatórios de regressão antes de qualquer uso real.

Esse é o limite da evidência. O laboratório não é um case de cliente, um agente em produção, uma garantia de confiabilidade ou prova de impacto em vendas.

A utilidade do case está no método: tratar conversa como comportamento testável, registrar falhas e impedir que uma impressão positiva substitua avaliação.

Checklist de entrada

Antes de integrar IA à operação, responda:

• Existe uma tarefa específica?
• A consequência de erro está classificada?
• As fontes são autorizadas e atualizáveis?
• Entradas e saídas têm contrato?
• Ações críticas permanecem limitadas?
• Há cenários e rubricas?
• Existe handoff útil?
• Dados sensíveis ficam fora de logs e analytics?
• Mudanças podem ser comparadas?
• É possível desligar ou reverter?

Se várias respostas forem “não”, o próximo passo não é publicar o agente. É reduzir o caso de uso e construir os controles.

Fontes oficiais para aprofundar

• Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — NIST AI 600-1, publicado em 26 de julho de 2024 e atualizado em 8 de abril de 2026. A referência organiza governança, avaliação e monitoramento de riscos ao longo do ciclo da solução.
• LLM06:2025 Excessive Agency — OWASP GenAI Security Project, edição 2025. A orientação reforça mínimo privilégio, ferramentas limitadas, autorização no sistema de destino e aprovação humana para ações de impacto.

Resumo

IA operacional não começa por personalidade, prompt ou autonomia. Começa por tarefa, fonte, contrato, limite, avaliação e handoff.

Quando esses elementos existem, o modelo pode assumir partes variáveis e repetitivas sem controlar sozinho decisões críticas. Quando não existem, uma automação convencional ou um fluxo humano melhor definido pode ser a solução mais confiável.