TL;DR: Este artigo mostra como o Microsoft Purview pode ser usado como mecanismo central de políticas de segurança e conformidade para agents de IA que rodam em AWS Bedrock, mesmo sem estar no Azure. A conclusão principal é que é possível separar o local de execução do agente (multi-cloud) da camada de governança, mantendo políticas DLP consistentes e auditáveis, sem fragmentar a proteção de dados.
As organizações estão avançando rapidamente com IA, e muitos workloads não ficam em uma única nuvem. Uma equipe pode usar Microsoft 365 e Microsoft Purview para governança e, além do Microsoft Foundry, optar por executar um AI agent no AWS Bedrock ou no Google Cloud Platform. O desafio técnico é direto: como manter um conjunto consistente de controles de segurança, governança e compliance quando o agent roda fora do Microsoft Azure?
É aqui que o Microsoft Purview se torna o motor central de políticas para seu patrimônio de dados. Neste artigo, mostramos por que isso é relevante e percorremos um exemplo prático: um agent de aprovação de despesas rodando no Amazon Bedrock, protegido por políticas de Data Loss Prevention (DLP) do Microsoft Purview.
Por que o Microsoft Purview deve ser o mecanismo central de políticas?
A maioria das organizações não quer pilhas de políticas separadas para cada nuvem, cada endpoint de modelo e cada time de aplicação. Isso leva a controles duplicados, aplicação inconsistente e lacunas de auditoria. O modelo melhor é separar onde os workloads rodam de onde as decisões de política são tomadas.
Essa é a proposta de valor do Microsoft Purview em cenários de IA entre nuvens.
O Purview oferece:
- Uma camada de política consistente para tipos de informações sensíveis, como números de cartão de crédito, CPF, dados financeiros e outros conteúdos regulados.
- Um plano de governança que pode se estender além dos workloads hospedados pela Microsoft para ambientes multi-cloud.
- Um framework de compliance com auditabilidade, rastreabilidade de políticas e um modelo operacional familiar para times de segurança e compliance.
- Uma forma de aplicar controles orientados a dados em interações de IA, não apenas em locais de armazenamento.
Na prática, isso significa que a mesma organização que já confia no Purview para governar Exchange, SharePoint, Teams e Copilot pode usá-lo para governar prompts e respostas em um agent baseado no Bedrock.
A mudança arquitetural fundamental é esta: sua aplicação não precisa inventar seu próprio motor de políticas de dados. Ela pode chamar o Purview nos pontos onde o risco existe.
O que este agent no Bedrock demonstra?
A solução de exemplo neste artigo é um padrão de IA entre nuvens:
- O frontend é um chat single-page baseado em navegador.
- Usuários autenticam com Microsoft Entra ID via MSAL.
- O backend roda em AWS Lambda.
- O modelo é Amazon Bedrock usando Nova 2 Lite.
- O Microsoft Purview avalia prompts e respostas do modelo para violações de políticas DLP.
Isso importa porque prova um ponto mais amplo: o Microsoft Purview pode governar interações de IA mesmo quando o modelo e o compute não estão rodando no Azure.
Como funciona a arquitetura?
O fluxo ponta a ponta segue este padrão:
- Um usuário faz login via Microsoft Entra ID a partir do frontend.
- O frontend envia o token de acesso e o prompt para um endpoint de API no AWS.
- A função Lambda troca esse token usando o fluxo On-Behalf-Of para que o Purview avalie sob a identidade do usuário autenticado.
- O Purview escaneia o prompt completo em busca de informações sensíveis antes de chamar o modelo.
- Se o prompt for permitido, a função Lambda envia a requisição para o Amazon Bedrock.
- O Purview escaneia a resposta do modelo antes de retorná-la ao usuário.
- O frontend exibe o resultado junto com um badge de avaliação do Purview.
Isso oferece dois fortes controles de governança:
- Prevenção de perda de dados em linha: pode bloquear requisições arriscadas antes que cheguem ao modelo.
- Imposição no momento da resposta: pode impedir que dados sensíveis retornem mesmo que o modelo os gere.
A implementação também usa a identidade do usuário para avaliação de políticas. Isso é importante porque as decisões de governança devem refletir quem está perguntando, não apenas qual aplicação está rodando.
Por que esse padrão é útil para times de segurança e compliance?
Existem três razões pelas quais esse padrão merece atenção.
- Primeiro: alinha política com risco, e não com local de hospedagem. O compute pode rodar em Lambda e o modelo no Bedrock, mas o Purview continua sendo o ponto de decisão de políticas.
- Segundo: melhora a clareza operacional. Times de segurança não precisam aprender uma toolchain de governança diferente para cada stack de IA. Eles podem continuar usando os conceitos, modelos de política e workflows de auditoria do Purview.
- Terceiro: suporta a adoção no mundo real. A maioria das grandes empresas já são híbridas e multi-cloud. Um padrão de governança que funciona apenas para o runtime de um único fornecedor não é suficiente.
Como definir as políticas no Purview?
Duas políticas são necessárias para aplicar DLP: uma política de coleção para Enterprise AI Apps e uma política DLP.
1. Política de coleção
2. Política DLP
Siga os passos descritos aqui para criar a política DLP para Enterprise AI Apps. A amostra está disponível em: purview-api-samples/DLPforCustomAIApps
Para replicar este cenário, acesse o repositório oficial no GitHub: purview-api-samples/AWSBedrock
Uma vez implantado, você terá:
- Uma função AWS Lambda que chama o Amazon Bedrock.
- Um frontend de navegador que autentica com Microsoft Entra ID.
- Microsoft Purview avaliando tanto prompts quanto respostas.
- Um fluxo de demonstração onde prompts seguros são bem-sucedidos e prompts sensíveis são bloqueados.
Com o app e o agent implantados, chega o momento em que o valor arquitetural fica claro. O runtime do modelo é AWS Bedrock, mas a decisão de política ainda vem do Microsoft Purview. A captura de tela abaixo mostra um prompt contendo informações sensíveis sendo bloqueado com base na avaliação de política do Purview.
Integração mínima via SDK
Abaixo está o código necessário para realizar a integração entre Purview e Bedrock, realizando a inspeção de entrada e saída do conteúdo destinado ao modelo e vindo dele.
Resultados do veredito do Purview apresentados ao usuário na interface do app
Revisão de evidências de governança no Purview Data Security Posture Management
Resumo
A história maior aqui não é apenas que o Microsoft Purview pode proteger um agent do Amazon Bedrock. É que as organizações podem centralizar políticas de segurança, governança e compliance de dados mesmo enquanto sua arquitetura de IA se torna mais distribuída entre múltiplas nuvens.
Essa é a vitória operacional. Desenvolvedores mantêm a liberdade de escolher o melhor runtime e plataforma de modelo. Times de segurança e compliance mantêm um motor de políticas central que já conhecem e no qual confiam. Aplicações de IA podem ser multi-cloud, mas seu modelo de proteção de dados não precisa ser fragmentado.
Recursos adicionais
- Configure Microsoft Purview - purview-sdk | Microsoft Learn
- Microsoft Purview Developer Platform Documentation - purview-sdk | Microsoft Learn
Perguntas Frequentes
-
Como o Microsoft Purview consegue avaliar prompts de um agent que roda fora do Azure?
O Purview expõe uma API que pode ser chamada a partir de qualquer runtime (como AWS Lambda). O agent envia o prompt e a resposta do modelo para avaliação via SDK antes e depois da chamada ao modelo, sem precisar mover os dados para o Azure. -
Preciso instalar algum componente no AWS para usar essa integração?
Não. A integração é feita via SDK do Purview dentro da função Lambda que orquestra o agent. Nenhum agente ou conector precisa ser instalado no ambiente AWS. O fluxo de autenticação usa o fluxo On-Behalf-Of com Microsoft Entra ID. -
Quais tipos de dados sensíveis o Purview pode detectar nesse cenário?
O Purview mantém uma camada consistente de políticas para tipos de informações sensíveis como números de cartão de crédito, CPF, dados financeiros e outros conteúdos regulados. Essas mesmas políticas são aplicadas a prompts e respostas do modelo. -
Esse padrão funciona apenas com AWS Bedrock ou com outros provedores?
O exemplo usa AWS Bedrock, mas a arquitetura é genérica. O Purview pode ser chamado a partir de qualquer endpoint, independentemente do provedor de nuvem ou modelo. A lógica de avaliação é desacoplada do runtime do agent. -
O fluxo de autorização considera a identidade do usuário ou apenas da aplicação?
O fluxo On-Behalf-Of permite que o Purview avalie as políticas usando a identidade do usuário autenticado, não apenas da aplicação. Isso é crucial para decisões de governança baseadas em quem está fazendo a pergunta.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
