Responsible AI como arquitetura de produção: política não governa runtime

Muita empresa trata Responsible AI como documento. Comitê, política, planilha de risco, PDF aprovado. Isso pode ser necessário, mas não governa runtime. Responsible AI como arquitetura de produção começa quando a política vira mecanismo: permissão, auditoria, fallback, limites de ação e capacidade real de desligar um fluxo.

Se o sistema erra e ninguém consegue reconstruir o caminho da decisão, a governança ainda não chegou à produção.

Governança precisa virar execução

O NIST AI Risk Management Framework descreve risco de IA como prática contínua de governança, mapeamento, medição e gestão. A ISO/IEC 23894 também trata risco de IA como disciplina de ciclo de vida. O EU AI Act, no Artigo 9, fala de gestão de risco como processo contínuo para sistemas de alto risco.

Essas referências apontam para uma ideia operacional: intenção não basta. O sistema precisa deixar evidência, impor limite e permitir intervenção.

A pergunta prática é desconfortável. Quando uma resposta errada sair, você consegue saber quem chamou o fluxo, qual contexto entrou, qual modelo respondeu, quais ferramentas foram acionadas, qual dado foi usado, qual decisão saiu e como reverter? Se a resposta depende de procurar em três times diferentes, o risco está sendo administrado no discurso, não no sistema.

LLMs e agentes ampliam a superfície de risco

Quando um modelo ganha contexto, dados internos e ferramentas, ele deixa de ser apenas uma interface de texto. Ele passa a participar de um fluxo operacional. Isso muda o threat model.

O OWASP Top 10 para aplicações com LLM lista riscos como prompt injection, exposição de informação sensível, agência excessiva e dependências de supply chain. O NIST também publicou uma taxonomia de ataques e mitigações para sistemas de IA. Esses documentos reforçam um ponto que aparece rápido em produção: prompt, dado externo, resposta do modelo e resultado de ferramenta precisam ser tratados como entradas não confiáveis.

O caso da DPD, em janeiro de 2024, é um exemplo público simples. A empresa desabilitou parte do chatbot depois que um usuário conseguiu induzir respostas fora do comportamento esperado. O aprendizado não é que chatbot não presta. O aprendizado é que qualquer limite exposto ao público será testado.

Prompt injection não se resolve só com um system prompt mais rígido. A defesa precisa aparecer na arquitetura: validação de ferramenta, escopo de permissão, saída restrita, logging e fallback.

O preço de não ter evidência

Quando algo dá errado, três perguntas aparecem: o que aconteceu, por que aconteceu e como evitar repetição. Sem evidência, essas perguntas viram narrativa.

O EU AI Act aponta nessa direção em sistemas de alto risco ao tratar de registros e monitoramento pós-mercado. Isso não significa aplicar o regulamento inteiro a qualquer feature com IA. Significa reconhecer que sistemas com impacto relevante precisam ser observáveis e auditáveis.

O caso Moffatt versus Air Canada também é útil. Um chatbot forneceu informação incorreta sobre tarifa de luto, e o tribunal responsabilizou a companhia. Para arquitetura, a mensagem é direta: quando a automação fala em nome da empresa, “foi o chatbot” não encerra responsabilidade.

Logging, porém, não é guardar tudo. Registrar prompt completo e resposta completa pode criar risco de privacidade, retenção indevida e exposição de dado sensível. Microsoft/Azure e Vertex AI mostram que logging e retenção dependem de serviço, configuração e contrato. A decisão precisa ser explícita.

Responsible AI em produção

Um fluxo de IA responsável começa com classificação. Que decisão o sistema influencia? Sobre quem? É reversível? Qual é o blast radius se errar?

Depois vêm as fronteiras de dados. O que pode entrar no prompt, o que precisa ser mascarado, o que nunca deve ir para o modelo e por quanto tempo a evidência pode ficar armazenada.

Ferramentas também precisam de escopo separado. Consultar status não é alterar cadastro. Sugerir ação não é executar transação. Operações que movem dinheiro, mudam permissão ou afetam cliente precisam de validação forte e, em muitos casos, confirmação humana.

O mínimo de evidência costuma incluir correlation ID, template de prompt, versão do modelo, tool calls, resultado, decisão e entidade impactada. O objetivo é auditar o suficiente, não coletar o máximo possível.

Por fim, fallback e kill switch não são detalhes de operação. São parte da arquitetura. Se não dá para desligar o fluxo de IA sem derrubar o produto, o acoplamento já passou do ponto.

Referências

Assista ao vídeo completo no YouTube →

Leia também