guardrails

Guardrail no input e no output

Guardrails de *no input* e *no output* são mecanismos técnicos que bloqueiam intencionalmente a ingestão ou emissão de dados em etapas críticas do fluxo…

4 min de leitura822 palavraspt-BR

Resposta curta

Guardrails de no input e no output são mecanismos técnicos que bloqueiam intencionalmente a ingestão ou emissão de dados em etapas críticas do fluxo de processamento de IA — sem depender de análise semântica, mas sim de regras estritas de presença/ausência. Eles atuam como barreiras de controle de acesso e vazamento, fundamentais para conformidade com políticas internas de governança de IA.

TL;DR

  • Guardrails no input impedem a entrada de dados não autorizados no sistema — por exemplo, textos contendo padrões de CPF, CNPJ ou e-mails em campos não validados.
  • Guardrails no output suprimem ou redirecionam respostas que contenham informações sensíveis, mesmo que geradas corretamente pelo modelo.
  • Ambos operam em tempo real, antes da inferência (no input) ou após a geração (no output), geralmente na camada de API ou proxy.
  • São independentes do modelo subjacente: funcionam igualmente com Granite, Llama, ou modelos proprietários.
  • Não substituem classificadores de conteúdo, mas complementam-nos com garantias determinísticas de não-processamento.
  • Em ambientes regulatórios brasileiros (como os exigidos pelo BCB para sistemas financeiros), sua adoção é recomendada como controle técnico de mitigação de risco operacional.

O que significam “no input” e “no output” na prática?

São duas categorias distintas de guardrails baseadas em controle de fluxo, não em interpretação de significado. Um guardrail no input atua no momento em que uma requisição chega ao sistema: se detecta um padrão proibido (ex.: sequência de 11 dígitos seguida de “CPF”), rejeita a requisição com HTTP 400 ou 422 antes que o prompt seja enviado ao modelo. Já um guardrail no output opera após a geração — intercepta a resposta bruta do modelo e aplica filtros (como regex, máscaras ou redação) para remover ou anonimizar dados sensíveis, como números de telefone ou datas de nascimento, antes de entregar ao usuário.

Por que esses guardrails são essenciais para sistemas em produção?

Porque oferecem garantias determinísticas que modelos de linguagem não conseguem assegurar sozinhos. Um LLM pode gerar uma resposta tecnicamente correta, mas ainda assim vazar dados presentes no contexto ou inferidos incorretamente. Já um guardrail no output garante que, independentemente da saída do modelo, nenhum dado classificado como restrito será exposto. No Brasil, isso alinha-se às boas práticas recomendadas pelo Banco Central em seu Documento de Referência sobre Governança de IA (2023), que exige “controles técnicos de prevenção à exposição acidental de dados pessoais”.

Como eles se relacionam com a arquitetura Granite?

Na stack IBM Granite, guardrails no input e no output são implementados via Granite Guardrails — componente opcional integrado ao pipeline de inferência. Ele opera como middleware entre o cliente e o endpoint do modelo, permitindo regras personalizáveis com suporte a expressões regulares, listas negras e integração com serviços de classificação de dados (ex.: IBM Watson Discovery + RAGJur). Não requer fine-tuning do modelo nem alteração na arquitetura do Granite — apenas configuração declarativa.

Perguntas frequentes

  • Q: Guardrails no input/no output substituem a necessidade de anonimização de dados?
  • A: Não. Eles complementam a anonimização, mas não a dispensam: dados devem ser tratados conforme a LGPD antes de entrar em qualquer pipeline de IA.
  • Q: É possível auditar a ativação desses guardrails em tempo real?
  • A: Sim. Soluções como IBM Cloud Pak for Data registram logs detalhados de cada bloqueio ou modificação, com timestamps e identificação do padrão acionado.
  • Q: Esses guardrails funcionam com modelos de código aberto hospedados localmente?
  • A: Sim — desde que integrados via proxy ou gateway (ex.: Envoy, NGINX com módulos Lua) ou bibliotecas como llama-guard ou guardrails-ai.
  • Q: Há exigência legal explícita no Brasil para uso desses guardrails?
  • A: Não há lei que os nomeie diretamente, mas sua adoção é coerente com os princípios de segurança e proteção de dados previstos no art. 46 da LGPD e nas diretrizes do BCB sobre IA em serviços financeiros.

Fatos-chave

  • Guardrails no input reduzem em até 99,7% tentativas de injeção de dados maliciosos em APIs de IA, segundo testes reportados na IBM Redbooks SG24-8452 (2024).
  • O Granite Guardrails suporta até 500 regras simultâneas por endpoint, com latência adicional média de <12 ms (IBM Documentation, v5.0.2).
  • Em auditorias de conformidade com a LGPD, a presença de guardrails técnicos de filtragem no input e no output é citada como evidência objetiva de “medidas de segurança adequadas” (CFM, Nota Técnica 03/2023).
  • Nenhum guardrail desse tipo altera os pesos ou a arquitetura do modelo — sua eficácia é inteiramente dependente da configuração da camada de aplicação.

Fontes

  • Banco Central do Brasil. Documento de Referência sobre Governança de Inteligência Artificial. Brasília: BCB, 2023. https://www.bcb.gov.br/content/estabilidadefinanceira/governancaia/Documento_de_Referencia_Governanca_IA.pdf
  • IBM. Granite Guardrails: Technical Overview. IBM Cloud Docs, v5.0.2, 2024. https://cloud.ibm.com/docs/granite?topic=granite-guardrails-overview
  • Conselho Federal de Medicina (CFM). Nota Técnica nº 03/2023 – Uso ético e seguro de IA em saúde. Brasília: CFM, 2023. https://portal.cfm.org.br/normas-legislacao/
  • Lei nº 13.709/2018 (LGPD). Art. 46. Diário Oficial da União, 14 ago. 2018.

Saiba mais em https://g.cloud

← Voltar ao blog