Guardrails e segurança em IA: controles fora do prompt

O que são guardrails

São os controles em volta do modelo, na entrada e na saída: o que ele pode receber, o que pode chamar e o que se permite que devolva. Pedir no prompt que o modelo se comporte ajuda, mas não basta. O que não pode dar errado convém ser garantido por algo que o modelo não controla.

AgendaGo: as camadas que estão em produção

• Lista de ferramentas permitidas e um filtro por papel.
• O negócio vem do JWT, nunca do modelo. Os parâmetros proibidos (ids de negócio, tokens, flags de admin) são descartados antes de executar.
• O texto de clientes e de arquivos é envolvido como dado, não como instrução.
• Um detector de entidades inventadas e a proveniência de cada afirmação.
• O texto de recusa é montado pelo código, não pelo modelo.
• Limite de taxa na borda, e um único controle no banco para o orçamento mensal por negócio.
• RLS do Postgres habilitado em todo o esquema, e RPCs SECURITY DEFINER com search_path fixo.

Onde vive cada controle

Os controles críticos estão no banco e não no prompt. Aplicar uma mudança proposta pelo assistente exige uma função SECURITY DEFINER só para o papel admin; o overbooking é bloqueado por um trigger; e o estoque só se move quando uma pessoa confirma o que o modelo leu.

O custo é código e migrações para cada regra. Em troca, nenhuma dessas garantias depende de o modelo dar ouvidos.

A plataforma e o Nux: em construção

A plataforma de agentes de IA para empresas está em construção, na fase 0, e é um design: prevê um guardrail de entrada contra prompt injection e um de saída que valida e cita, uma SQL Tool somente leitura com lista permitida, SQL validado, timeout e limite de linhas, e RLS por tenant_id.

No Nux, o assistente do Bonuxo, as escritas exigem confirmação humana, algumas com confirmação forte, e respeitam as permissões do usuário. A camada de LLM dele está construída, mas desligada em produção.