Guardrails de IA

Guardrails de IA são mecanismos técnicos e processuais que limitam o que entra no modelo, quais dados ele recebe, quais ferramentas pode solicitar, o que pode sair e quais efeitos são permitidos. Eles podem operar antes, durante e depois da inferência. Exemplos incluem classificação de risco, remoção de dados sensíveis, filtro de conteúdo, políticas de autorização, JSON Schema, validação de argumentos, allowlist de ferramentas, sandbox, confirmação humana e monitoramento. O termo não indica uma norma única nem uma solução infalível. Em casa inteligente, o objetivo é impedir que erro, alucinação ou prompt injection se transforme em ação física indevida ou vazamento. A proteção mais forte fica fora do modelo, perto dos dados e atuadores, com menor privilégio e estados seguros.

• Guardrails de entrada avaliam pedido, identidade, contexto e dados antes do modelo. Podem detectar PII, segredos, conteúdo fora de escopo, tentativa de prompt injection ou comando de alto risco. A detecção não deve bloquear linguagem legítima apenas por palavras. Regras simples são explicáveis, mas contornáveis. Classificadores capturam padrões, mas geram falso positivo. Uma combinação usa. O sistema pode redigir número de documento, reduzir histórico e classificar ação. Para “abra o portão”, o guardrail não precisa recusar; marca risco alto e exige fluxo. Para uma criança, políticas adicionais. A entrada externa de RAG é escaneada e marcada como não confiável. Nenhum filtro recebe credencial de execução.
• Guardrails de contexto controlam quais informações o modelo vê. Autorização é aplicada antes da recuperação. Um visitante não recebe câmeras. Fontes são delimitadas e têm proveniência. Segredos ficam fora. O prompt de sistema estabelece regras, mas não é barreira suficiente. A memória é filtrada por usuário e escopo. Documentos com instruções não podem alterar política. O catálogo de ferramentas é reduzido por tarefa e identidade. Um modelo de suporte somente leitura não recebe funções de escrita. Esse desenho diminui superfície. Se a ferramenta não está disponível, o modelo não pode acioná-la. A aplicação evita uma ferramenta genérica que acessa qualquer URL, arquivo ou comando.
• Guardrails de saída validam forma e conteúdo. Structured outputs e JSON Schema garantem sintaxe em algumas plataformas, mas a semântica precisa de código. Verifique IDs, tipos, enums, unidades, limites, referências e autorização. Um brilho 150% é rejeitado. Uma URL interna é bloqueada. Texto pode ser verificado contra fontes, moderação e políticas. Dados sensíveis são redigidos. Citações são checadas. Uma resposta que afirma estado sem tool result é marcada. Para valores, a UI renderiza dados diretos. O modelo não decide sua própria conformidade. Um segundo modelo pode revisar, mas compartilha falhas e aumenta custo. Regras determinísticas são preferidas quando possíveis.
• Guardrails de ação estão entre modelo e mundo. Um policy engine avalia RBAC/ABAC, autenticação, risco, horário, presença, consentimento e estado. Ações físicas exigem confirmação proporcional. Portas, portões, alarmes, forno e carga elétrica recebem políticas. Idempotência evita repetição. Rate limits impedem ciclos. Transações e compensação tratam falha. Sandboxes isolam código. A rede da ferramenta é restrita. Credenciais têm menor privilégio. Um agente possui orçamento de etapas. Um kill switch coloca modo somente leitura. O atuador mantém interlocks locais. Uma IA não pode desativar proteção térmica por texto. A segurança funcional permanece no dispositivo.
• Monitoramento e resposta completam. Traces registram modelo, prompt versionado, tool calls, decisões de política, erros e resultado, com dados minimizados. Alertas detectam tentativas repetidas, ação negada, saída inválida e custo anormal. Amostras são revisadas. Red teaming usa ataques. Avaliações de regressão rodam a cada troca de modelo, prompt ou ferramenta. Falsos positivos são medidos porque bloqueios excessivos levam usuários a contornar. Falsos negativos têm impacto. A política tem responsável e processo de exceção. Incidentes alimentam novos testes. Um guardrail desatualizado pode falhar. Não existe configuração “instalar e esquecer”.
• A defesa deve ser proporcional e transparente. Um comando de luz não precisa de cinco confirmações; uma abertura remota pode. O usuário deve entender por que uma ação foi bloqueada e como corrigir, sem revelar detalhes exploráveis. Guardrails não devem fingir certeza. Se a IA não sabe qual dispositivo, pede. Se o dado não foi encontrado, informa. O sistema oferece controle manual. A indisponibilidade do guardrail cloud não deve derrubar automações locais críticas; políticas essenciais ficam locais. A segurança também inclui acessibilidade: confirmação por voz pode não servir a todos. Métodos alternativos. A meta é limitar dano e manter utilidade, não tornar o sistema inutilizável.