Como fazer a IA seguir o método da sua empresa

Por que a IA entrega um trabalho bom que não serve#

A reclamação mais comum de quem começou a usar IA no trabalho não é que ela erra. É que ela acerta uma coisa que não é a sua: o texto está bem escrito, a estrutura é razoável — e não é assim que a sua empresa faz.

O motivo é simples. Um modelo de linguagem devolve algo próximo da média do que foi publicado sobre o assunto, e o seu método não está publicado: ele está na cabeça de duas ou três pessoas, num documento desatualizado e num monte de decisões que ninguém escreveu. Pedir "faça do nosso jeito" a quem nunca viu o nosso jeito devolve o jeito de todo mundo.

Restringir um modelo a uma metodologia é resolver isso — e a resposta não é um prompt melhor. São quatro camadas, em ordem de custo:

1. O método escrito fora do prompt, e lido na hora de usar.
2. O cálculo em código, fora das mãos do modelo.
3. A lista do proibido, com o vocabulário que entra no lugar.
4. Um freio que barra a ação, para o que não pode depender de boa vontade.

Se o método não está escrito, não há o que restringir#

Restringir é comparar contra uma referência. Sem referência escrita, não existe restrição — existe pedido, e o modelo atende o pedido preenchendo o vazio com o que parece certo.

Esse é o degrau que quase todo mundo pula, porque ele não tem nada de tecnológico. Na nossa operação ele tomou a forma de 26 metodologias escritas — escopo, estimativa, planejamento de interface, revisão de código, mapa de notificações, documento legal, e assim por diante — executadas por 28 comandos que não carregam o método dentro de si: eles leem a metodologia correspondente no momento em que rodam (números de agosto de 2026).

Vale a confissão que fecha o argumento: nós projetamos um produto interno e paramos antes de construí-lo, porque a metodologia que ele deveria vigiar ainda não estava validada em campo. Sem ela, o produto seria um chat genérico assistindo a uma reunião — bonito na demonstração, inútil na hora de cobrar rigor. O software era a parte fácil.

O teste, antes de comprar qualquer camada de IA: alguém novo na empresa conseguiria executar esse processo lendo só o que está escrito? Se a resposta é não, o modelo também não vai. Ele só vai errar mais rápido e com mais confiança.

A régua mora fora do prompt, e é lida na hora de usar#

Há duas formas de dar um método a um agente de IA. A primeira é escrever o método dentro do prompt. A segunda é escrever o método num documento e instruir o agente a ler esse documento ao executar a tarefa.

Parece detalhe de implementação, e é uma das decisões mais consequentes da arquitetura. Nós tomamos essa decisão formalmente, e a razão é a duplicação: quando o método vive em dois lugares, um dos dois envelhece. A régua muda no documento, o prompt continua aplicando a versão anterior, e nada avisa — a saída continua parecendo correta, porque está correta em relação a uma regra que já não vale.

Na prática, o agente é só um orquestrador: pergunta, lê os insumos, valida e gera. O método mora no documento — mudou o padrão, muda num lugar só.

O segundo efeito é ainda mais importante: o método continua legível para quem não mexe em prompt. Quem domina o assunto — a psicóloga, o auditor, o vendedor — consegue abrir o documento, discordar, corrigir. Método enterrado dentro de um prompt vira propriedade de quem escreve prompt, e é assim que o processo da empresa passa a depender de uma pessoa de tecnologia para mudar de opinião.

Uma técnica que sai barata dessa arquitetura: fazer o agente gerar e, no mesmo turno, revisar o que gerou contra o checklist do próprio método. Gerar sem revisar produz peça que passa no olho e falha no critério — e o modelo é muito melhor em achar o que falta num texto pronto do que em não esquecer enquanto escreve.

Tire o cálculo das mãos do modelo#

Esta é a camada que separa uso sério de demonstração, e ela se resume a uma frase: se um número errado tem consequência, esse número não pode sair de um modelo de linguagem.

O Sistema Cuidar, que construímos para uma consultoria de saúde e segurança do trabalho, é o exemplo direto. O laudo tem 15 seções; a IA escreve cinco. A matriz de risco, a classificação por fator e os gráficos são calculados do dado coletado, deterministicamente — o modelo não os toca. Ele escreve a interpretação técnica em cima do resultado já calculado. É isso que faz o documento ser assinável por uma responsável técnica: nenhum número do laudo veio de um modelo de linguagem.

A versão mais barata dessa camada é a restrição por ausência, e ela vale ser copiada: não dê ao modelo o dado que ele não pode usar. A Nicky, o agente de atendimento que colocamos no WhatsApp da Agência OKSE, não fala preço — não porque exista uma instrução dizendo "não fale de preço", mas porque a agência não tem serviço com preço tabelado e, portanto, não há preço nenhum no material que ela lê. O conteúdo dela foi refeito a partir do material oficial da agência: posicionamento, serviços, perguntas frequentes e os cases reais. O que não está lá, ela não tem como dizer.

Instrução proibindo reduz a chance. Ausência do dado elimina a possibilidade. Sempre que der para escolher a segunda, escolha a segunda.

A lista do proibido — e o vocabulário que entra no lugar#

Proibir sem substituir não funciona. Um modelo instruído a "não usar linguagem vaga" produz outra linguagem vaga, porque ele não tem o que colocar no lugar. A lista que funciona tem duas colunas: o que é proibido e o que é obrigatório.

No laudo do Cuidar, o vocabulário superficial de recursos humanos está vetado — "clima ruim", "liderança tóxica", "falta de resiliência" — e a terminologia ocupacional auditável está imposta: "baixa previsibilidade das demandas", "ambiguidade de papéis", "desequilíbrio entre demandas e recursos". A mesma lista proíbe citar autor ou referência que não esteja no material fornecido, que é a forma mais comum de um texto técnico gerado por IA se desmontar na primeira conferência.

O ganho não é só de estilo. Uma lista assim é verificável: dá para procurar o termo proibido no texto e saber, em segundos, se a régua foi cumprida. Instrução subjetiva ("escreva com rigor técnico") não se verifica, e o que não se verifica não se cobra.

O que a instrução não garante, o código garante#

Aqui está a camada que quase ninguém monta, e a mais barata de todas.

Toda regra dentro de um prompt é um pedido. Um pedido bem escrito é atendido quase sempre — e "quase sempre" é uma palavra que não serve quando a ação é irreversível. Prosa não é enforcement. O que não pode acontecer nunca precisa de algo que barre, não de algo que peça.

Não é só uma questão de o modelo falhar por conta própria. O OWASP Top 10 for Large Language Model Applications tem como primeira entrada LLM01: Prompt Injection — texto vindo de fora pode redirecionar o comportamento do modelo. Ou seja: a instrução dentro do prompt é superfície de ataque, não garantia. Se a regra importa de verdade, ela não pode viver no mesmo lugar onde o conteúdo do usuário entra.

Na nossa operação, essa camada é uma política com uma régua de uma linha — interno e reversível é livre; externo ou irreversível pede aval — e um freio em código que a aplica: ele intercepta a ação antes de ela acontecer e pede aprovação, em vez de negar em silêncio. Duas escolhas de desenho merecem nota, porque são o que faz o freio sobreviver ao dia a dia: pedir aprovação em vez de bloquear mantém o trabalho fluindo, e o freio é tolerante à própria falha — se ele quebrar, o trabalho continua, porque um freio que trava a operação é desligado na primeira semana e nunca volta.

No lado do cliente, a mesma lógica aparece em decisões banais. A Nicky nunca inicia conversa — não é instrução de bom comportamento, é uma operação desenhada para ser só receptiva. Cada contato tem fila própria, para que duas mensagens seguidas não gerem duas respostas. E ela se identifica como assistente virtual quando perguntam — essa é a parte honesta da história: o protótipo mandava desconversar, e isso saiu antes de o agente entrar no ar. Descobrimos lendo o prompt, não pela reclamação de um cliente.

A pergunta que resume a camada, e que vale fazer para cada "nunca" da sua lista: se o modelo fizer isso mesmo assim, como eu descubro? Se a resposta é "pelo cliente", a regra precisa de código.

Quando não vale restringir#

Restringir custa escrever o método, e há casos em que esse custo não se paga:

• Quando a tarefa não tem forma fixa. Rascunho, exploração, primeira versão de uma ideia, resumo de reunião para consumo próprio. Aí a variedade da resposta é a utilidade dela, e impor régua é burocracia.
• Quando errar não tem consequência. Se o pior desfecho é alguém refazer, montar quatro camadas é caro demais para o risco.
• Quando o processo vai mudar mês que vem. Escrever método sobre chão instável produz documento que ninguém segue — nem pessoa, nem modelo.

E o limite honesto, que vale dizer com clareza: restringir não faz a saída ficar certa. Faz a saída ficar auditável. A revisão humana continua, e em contexto técnico continua sendo de quem assina. O que muda é onde essa pessoa gasta o tempo — no Cuidar, a responsável técnica passou a revisar e assinar em vez de compilar planilha e digitar texto. É uma mudança grande, e não é a mesma coisa que ausência de revisão.

E vale dizer onde nós mesmos estamos devendo. O NIST AI Risk Management Framework, publicado pelo instituto americano de padrões em janeiro de 2023, organiza a gestão de risco de IA em quatro funções: Govern, Map, Measure e Manage. As quatro camadas descritas aqui cobrem bem Govern e Manage — a régua está escrita e o freio existe. Measure é a que falta: medir sistematicamente o quanto o que o modelo produz adere ao método é trabalho que ainda não fizemos, e não conhecemos ninguém no nosso mercado que tenha feito. Quem estiver montando isso agora deveria montar a medição junto, não depois.

Por fim, o que essas camadas não são: elas não exigem treinar um modelo próprio. Fine-tuning ajusta estilo e formato; não resolve conta errada nem ação indevida, que são os dois problemas que tiram uma IA de um processo sério.

Perguntas frequentes#

Preciso treinar um modelo próprio para ele seguir o meu processo?#

Na maioria dos casos, não. Treinar ajusta o estilo e o formato da resposta, mas não garante que o cálculo esteja certo nem que a ação proibida não aconteça — e custa dado, tempo e manutenção a cada mudança de processo. As quatro camadas que resolvem de verdade são de arquitetura: método escrito fora do prompt, cálculo em código, lista do proibido e freio que barra a ação. Nós operamos assim todos os dias, em produto interno e de cliente, sem treinar modelo nenhum.

Um prompt bem escrito não resolve?#

Resolve na primeira semana. O que quebra depois é a duplicação: quando o método está escrito dentro do prompt, ele passa a existir em dois lugares, e o dia em que a regra muda no documento o prompt continua aplicando a versão antiga — em silêncio, com aparência de acerto. Por isso a régua fica fora do prompt, num documento único, e o agente é instruído a ler esse documento na hora de executar.

Como eu impeço a IA de inventar número?#

Tirando o número das mãos dela. Cálculo é código: a conta, a classificação e o gráfico saem do dado, deterministicamente, e o modelo escreve a interpretação em cima do resultado. Instruir o modelo a "não inventar dados" reduz o problema, mas não o elimina — enquanto ele puder escrever um número, um número errado é uma possibilidade. Quando não pode, deixa de ser.

Dá para usar IA em documento técnico que alguém vai assinar?#

Dá, com três condições: nenhum número do documento vindo do modelo, fundamentação restrita a um material de referência nomeado (sem citar autor que não esteja nele) e revisão humana de quem assina. O que muda não é a responsabilidade — ela continua inteira com quem assina — é onde essa pessoa gasta o tempo: revisando em vez de digitando.

Quanto tempo leva para restringir a IA ao meu método?#

O gargalo não é técnico. Quem já tem o processo escrito — de verdade, no nível em que alguém novo conseguiria executá-lo lendo — monta as camadas em dias. Quem não tem leva o tempo de escrever o método, e esse é o trabalho de fato. É por isso que a pergunta certa antes de contratar qualquer camada de IA é: o nosso jeito de fazer isso está escrito em algum lugar?

Fontes#

• OWASP — "Top 10 for Large Language Model Applications", cuja primeira entrada é LLM01: Prompt Injection — https://owasp.org/www-project-top-10-for-large-language-model-applications/
• NIST — "AI Risk Management Framework" (AI RMF), publicado em janeiro de 2023, com as funções Govern, Map, Measure e Manage — https://www.nist.gov/itl/ai-risk-management-framework

Próximo passo#

Se você está avaliando pôr IA num processo que tem consequência, o primeiro movimento não é escolher ferramenta: é olhar se o método está escrito no nível em que dá para cobrá-lo. É esse trabalho que sustenta as quatro camadas, e é o que fazemos em IA e automação — do laudo técnico do Sistema Cuidar ao agente de atendimento da Agência OKSE. E se o que você tem hoje é um produto que já foi construído por IA sem nenhuma dessas camadas, o assunto é outro: o que dá para salvar de um código gerado por IA.