Guardrails que não estragam o produto

Já usei produtos em que a feature de IA recusa tanto que as pessoas aprendem a contornar, e produtos em que ela nunca recusa e um dia diz algo que acaba em um print. Os dois são falhas de guardrail. O primeiro time colocou um filtro no final e calibrou por medo. O segundo não colocou filtro em lugar nenhum. O trabalho interessante está no meio: guardrails que moldam tão bem o que o modelo faz que o usuário raramente vê uma parede, e quando vê, a parede diz algo útil.

Restrinja a tarefa, não o usuário

O guardrail mais barato é uma tarefa estreita. Um modelo que recebe "ajude com qualquer coisa" precisa de uma superfície de segurança enorme. Um modelo que recebe "resuma este ticket em três campos" mal tem espaço para se comportar mal. Eu projeto features de IA como tarefas específicas com entradas e saídas estruturadas, porque schema é guardrail: se a saída precisa ser uma de cinco categorias, o modelo não consegue opinar. A maior parte do orçamento de guardrail que os times gastam em filtros de saída é sintoma de ter dado liberdade demais ao modelo desde o início.

Camadas, em ordem de custo

Validação de entrada primeiro, que é engenharia normal: rejeite entradas vazias, grandes demais ou malformadas antes de gastar um token. Depois o prompt em si, com escopo claro e instruções explícitas sobre o que fazer quando o pedido está fora de escopo, que deve ser um sinal estruturado, não um sermão. Depois validação da saída contra o schema, com retry em caso de falha. Depois, só para as saídas que chegam a uma pessoa, um classificador ou um modelo pequeno checando os riscos específicos que importam neste produto. Cada camada pega o que a anterior deixou passar e custa mais do que ela. Colocar a camada cara primeiro é como você consegue uma feature lenta que ainda vaza.

Recuse bem

Quando um guardrail dispara, o que o usuário vê é o produto. Um "não posso ajudar com isso" genérico ensina ao usuário que a feature não é confiável. Uma mensagem específica que diz o que a feature consegue fazer e oferece a ação válida mais próxima mantém a pessoa dentro do produto. O modelo não deve escrever essa mensagem. A aplicação deve, a partir de um motivo tipado que o guardrail devolveu: fora de escopo, informação faltando, conteúdo sensível, baixa confiança. Cada motivo ganha seu próprio texto, seu próprio próximo passo e sua própria métrica, porque um pico em um motivo é sinal sobre o produto e um pico em outro é sinal sobre abuso.

Meça os falsos positivos

Todo guardrail tem duas taxas de erro e os times só acompanham uma. Contam as saídas ruins que passaram. Não contam os pedidos bons que foram bloqueados, que é o número que o usuário sente. Eu amostro os pedidos bloqueados e reviso, do mesmo jeito que amostro as saídas aprovadas, e defino meta para os dois. Um guardrail com taxa de falso positivo que ninguém mede vai derivar para bloquear tudo, porque todo incidente aperta e nada nunca afrouxa.

O caminho humano

Para os casos que nem o modelo nem as regras conseguem resolver, deve existir um caminho até uma pessoa, com o contexto anexado. Não como último recurso, mas como parte projetada do fluxo. O trabalho do guardrail é separar: cuidar automaticamente da maioria segura, bloquear o claramente ruim, e encaminhar o ambíguo para alguém que possa decidir. Um sistema que só sabe permitir ou negar não tem onde colocar a ambiguidade, então coloca em um dos dois baldes e erra.