> ## Content Index
> Fetch the complete content index at: https://vitaofernandes.com.br/llms.txt
> Use this file to discover other available public pages before exploring further.

# Até onde um agente entra em um Purview Assessment
- URL: https://vitaofernandes.com.br/purview-assessment-agentes/
- Published: 2026-09-14T12:04:13.000Z
- Updated: 2026-09-14T12:04:13.000Z
- Description: Um agente pode gerar scripts, consolidar evidências e propor findings em um Purview Assessment. A fronteira importante é definir o que ele pode produzir — e o que ainda exige validação humana.
- Author: Vitão Fernandes
- Tags: Dados e Acesso na Adoção de IA, Data & AI Security

Colocar um agente dentro de um Purview Assessment exige uma fronteira clara: quais evidências ele pode receber, o que ele pode produzir e quem aprova a conclusão.

Esse é o fluxo que estou montando para Assessment e Health Check de Microsoft Purview.

O trabalho começa pelo escopo. DLP, Endpoint DLP, Sensitivity Labels, Information Protection, Insider Risk ou o recorte definido para aquela avaliação.

A partir daí, o agente prepara os scripts de coleta. Eu reviso antes da execução e faço a coleta no ambiente.

Para esse cenário, prefiro manter essa etapa intermediada pelo engineer. O agente não precisa receber acesso amplo ao tenant para participar de boa parte do trabalho.

As evidências voltam para análise. O agente pode consolidar arquivos, normalizar resultados, cruzar informações e estruturar uma primeira leitura em **Findings, Gaps, Risks e Recommendations**.

Também precisa existir uma saída perfeitamente válida: **evidência insuficiente**.

Ausência de evidência não prova ausência de controle. Uma configuração diferente do esperado também não vira gap automaticamente. A conclusão precisa sobreviver à evidência, ao contexto do cliente e à revisão técnica.

## Onde MCP entra

Quando um finding depende do comportamento atual de um produto Microsoft, eu quero uma fonte primária dentro do fluxo.

O **Microsoft Learn MCP Server** permite que agentes pesquisem a documentação oficial, carreguem artigos completos e procurem exemplos de código.

No desenho desse Assessment, ele tem uma função bem específica: ajudar a validar o comportamento documentado do produto.

Ele não substitui a evidência do tenant.

A configuração do cliente vem da coleta. O MCP ajuda a responder outra pergunta: **o que a Microsoft documenta hoje sobre aquela capacidade?**

Essa separação evita misturar documentação de produto com observação do ambiente.

## Skills colocam método no processo

Na experiência do Copilot Studio baseada no GitHub Copilot harness, **Skills** permitem empacotar instruções, scripts, templates e referências para tarefas específicas.

É aí que eu vejo espaço para uma `Purview Assessment Skill`.

![](https://storage.ghost.io/c/a5/d8/a5d896ca-f523-4f66-ad34-a7ab42e04832/content/images/2026/09/Copilot-Skills-Print-Realjpeg.jpeg)

Skills no Copilot Studio: critérios do Assessment podem virar instruções reutilizáveis pelo agente

💡

****O que entraria nessa Purview Assessment Skill?**  
A ideia não é colocar um prompt gigante dentro do agente. É transformar critérios do Assessment em regras reutilizáveis.  
  
****\- Evidência mínima:** o que precisa existir antes de sustentar um finding.  
\- ****Evidência insuficiente:** condições em que o agente deve parar e assumir que ainda não é possível concluir.  
\- ****Critérios de análise:** como diferenciar Finding, Gap, Risk e Recommendation.  
\- ****Estrutura da saída:** quais campos, contexto e evidências cada análise precisa apresentar.  
\- ****Revisão humana:** quais decisões nunca avançam automaticamente para o relatório final.

Isso não transforma o agente em auditor.

Transforma parte do método em algo explícito, repetível e revisável.

**Tools** cumprem outro papel: conectam o agente a capacidades externas, inclusive MCP servers. **Workflows** entram quando existe um processo de múltiplas etapas que precisa de uma execução mais determinística.

O desenho começa a ficar assim:

![](https://storage.ghost.io/c/a5/d8/a5d896ca-f523-4f66-ad34-a7ab42e04832/content/images/2026/09/Agente-Copilot-dentro-posto-novo.png)

## O ponto de controle continua humano

Eu deixaria o agente preparar, organizar, comparar e propor.

Não deixaria um finding entrar no relatório apenas porque o agente conseguiu produzi-lo.

Antes disso, ainda quero validar: a evidência sustenta a conclusão? O risco é relevante naquele contexto? A recomendação é aplicável? Existe alguma validação manual que falta?

Só depois a análise validada segue para a geração do documento final.

E é aí que esse experimento fica mais interessante para mim.

Estamos falando de usar IA dentro de um processo de proteção de dados. Então a arquitetura precisa deixar explícito **quais dados o agente acessa, quais decisões ele pode propor e qual evidência permite revisar o resultado depois**.

A provocação que fica é:

> **Se o agente consegue produzir um finding em segundos, você consegue explicar por que decidiu aceitá-lo?**

Estou montando esse fluxo agora.

Se eu gravar um vídeo, quero abrir a configuração inteira: Agent, MCP, Skills, scripts de coleta, consolidação das evidências, análise e geração do relatório.

**Vale colocar tudo isso na tela?**