Forem: Angelo Matias

Fabric em 2026: menos ETL, mais “data estate pronto para agentes”

Angelo Matias — Tue, 13 Jan 2026 18:45:33 +0000

Se 2025 foi o ano em que muita gente entendeu o Fabric como “plataforma unificada”, 2026 tende a ser o ano em que ele vira, de fato, o hub operacional de dados para IA: menos pipelines tradicionais, mais zero-ETL, catálogo/governança, e uma camada cada vez mais forte para servir contexto confiável para Copilots e agentes.

Para acompanhar o que vem por aí, a fonte mais objetiva é o Microsoft Fabric Roadmap, com previsões por trimestre e status (Planned/Preview/Released). ([roadmap.fabric.microsoft.com][1])

1) OneLake: unificação “zero-ETL” ficando mais prática (e mais perto do usuário)

O OneLake continua sendo a peça central para conectar dados sem cópia: shortcuts e mirroring reduzem a necessidade de ETL clássico e centralizam credenciais/permissões no próprio OneLake. ([learn.microsoft.com][2])

Duas coisas que importam muito para cenário real de empresa:

Shortcuts para OneDrive/SharePoint (preview): isso traz dados não estruturados do mundo de produtividade para dentro do lakehouse sem precisar copiar arquivos ou inventar pipeline. ([learn.microsoft.com][3])
Shortcuts com mais controle de ingestão (Planned, Public Preview Q1 2026): o Roadmap já aponta “Shortcut Transformations”, permitindo customizar ingestão (formatos, dedupe, parsing, erros, etc.). Isso reduz o atrito de “eu até consigo usar shortcut, mas preciso de controle fino”. ([roadmap.fabric.microsoft.com][1])

Leitura de arquiteto: 2026 é sobre tornar “zero-ETL” operável no dia a dia, sem virar gambiarra.

2) Mirroring em GA para bancos: do dado operacional para o analytics/AI sem pipeline pesado

Mirroring está sendo tratado como a via rápida para “trazer o operacional para o OneLake” em near real-time. Há anúncios de GA relevantes:

Mirroring para SQL Server (2016–2022) e SQL Server 2025 em Fabric: GA ([blog.fabric.microsoft.com][4])
O próprio blog “What’s new in OneLake…” cita novas fontes e GA para mirroring (incluindo PostgreSQL, Cosmos DB e SQL Server 2016–2022 e 2025). ([blog.fabric.microsoft.com][5])

O impacto arquitetural é direto:

menos ETL e menos “staging” para analytics
dados mais frescos para BI e cenários de IA
governança centralizada no lake (permissões/linhagem/descoberta) em vez de espalhada em pipelines

3) Governança e catálogo: Fabric deixando de ser “só stack de dados” e virando plataforma gerenciável

Quando a adoção escala, a conversa vira: “onde está o inventário?”, “quem é dono?”, “qual linhagem?”, “quem acessou?”, “qual risco?”. O Roadmap de Administration, Governance and Security destaca evolução de catálogo com experiências de Explore/Govern, filtros por domínio, item type, owner, endorsement, tags e acesso a linhagem/permissões/atividade. ([roadmap.fabric.microsoft.com][6])

Ou seja: 2026 não é só capacidade técnica; é operabilidade e controle.

Checklist do arquiteto para 2026 (curto e pragmático)

Se você quer preparar seu ambiente para IA com dados confiáveis no Fabric:

OneLake como “hub”: reduzir cópias e consolidar credenciais/permissões via shortcuts ([learn.microsoft.com][2])
Mirroring para operacional: priorize fontes críticas (SQL/PG/Cosmos) para reduzir ETL e acelerar time-to-insight ([blog.fabric.microsoft.com][4])
Produtividade como dado: avalie shortcuts de SharePoint/OneDrive para habilitar RAG/agents com documentos do trabalho ([learn.microsoft.com][3])
Governança desde o início: catálogo, ownership, tags e linhagem como parte do rollout, não “fase 2” ([roadmap.fabric.microsoft.com][6])
Prepare o “controle fino”: acompanhe Shortcut Transformations (Q1 2026) para reduzir fricção operacional ([roadmap.fabric.microsoft.com][1])

Obrigado pela sua leitura até aqui!

Purview em 2026: do “compliance portal” para o control plane de dados na era de IA e agentes

Angelo Matias — Tue, 06 Jan 2026 13:19:04 +0000

Se você está olhando para Copilot/agents como “feature de produtividade”, você vai bater num muro em 2026: dados.
Prompt é canal de extração, RAG é “busca com consequência”, e agentes viram identidades que executam ações. Nesse cenário, o Microsoft Purview está evoluindo para ser menos “visibilidade” e mais postura + ação, um plano de controle para proteger e governar dados e interações com IA.

A referência mais útil para acompanhar a trilha oficial é o What’s new in Microsoft Purview (Microsoft Learn), que aponta também para os roadmaps do que está planejado.

1) DSPM: de dashboard para workflows guiados (e postura contínua)

O Purview está consolidando o Data Security Posture Management (DSPM) como ponto central para “secure data for AI” e monitorar uso de IA (Copilots, agents e apps com LLMs).

Um detalhe importante: a documentação deixa claro que o DSPM for AI “clássico” está sendo substituído por uma nova versão com guided workflows para gestão proativa de risco e operação mais simples, o que é um indicativo forte de direção para 2026: postura como processo contínuo, não auditoria pontual.

O que isso habilita (na prática):

priorização por objetivo (reduzir oversharing, fechar gaps de proteção, etc.)
remediação orientada por recomendação
uma operação mais “business speed” sem perder governança

2) Agentes viram escopo de política: Purview para AI agents

O Purview já tem orientação específica para gerenciar segurança e compliance para AI agents.
Isso é mudança de paradigma: em vez de governar apenas usuários e arquivos, você passa a governar também interações e entidades agentic.

Para arquitetos, o impacto é direto:

políticas precisam considerar identidade/escopo do agente
accountability exige trilha de auditoria e evidência sobre ações executadas “em nome de”

3) O prompt entrou oficialmente no perímetro: DLP para Copilot (prompts e grounding)

O ponto mais “pé no chão” para 2026 é este: DLP direcionado ao Microsoft 365 Copilot e Copilot Chat pode ser configurado para:

bloquear prompts que contenham Sensitive Information Types
impedir resposta do Copilot quando o prompt viola política
impedir que o dado sensível seja usado em buscas internas/externas (incluindo web).

Além disso, também existe a possibilidade de excluir arquivos/e-mails com sensitivity labels de serem usados como grounding (proteção já em GA, segundo a própria doc).

Tradução de negócio: dá para acelerar adoção de IA com risco controlado, desde que você tenha taxonomia de labels e política DLP bem desenhada.

4) “Security Copilot Agents” dentro do Purview: reduzir fila manual de alertas

O Purview também passa a incorporar agentes do Security Copilot voltados para tarefas específicas, como triagem e priorização de alertas em DLP e Insider Risk, com explicabilidade da categorização (útil para operação e auditoria).

Leitura de arquiteto: isso é um passo para transformar segurança em closed-loop operations (detectar, priorizar, agir e evidenciar), sem aumentar _headcount _na mesma proporção.

Checklist do arquiteto para entrar em 2026 “pronto para agentes”

Se você quer rodar Copilot e agentes com segurança de verdade, eu começaria por:

Labels primeiro: taxonomia simples, aplicada em escala
DLP para Copilot: prompts + grounding (com exceções bem governadas)
DSPM como cockpit: postura, recomendações e workflows guiados
Modelo de governança de agentes: identidade, escopo, auditoria, evidência
Operação: triagem, resposta e métricas (reduzir dwell time de violação)

Obrigado pela sua leitura até aqui!

Microsoft 365 + Copilot em 2026: a virada do “chat” para agentes no fluxo do trabalho

Angelo Matias — Mon, 05 Jan 2026 14:29:42 +0000

Em 2024/2025, muita empresa tratou Copilot como “chat corporativo com IA”. Em 2026, a conversa muda: o Copilot deixa de ser só interface e vira camada operacional... com agentes atuando dentro do Teams, Outlook e do conjunto Microsoft 365, exigindo arquitetura de adoção (governança, segurança, telemetria e rollout) no mesmo nível que a gente já faz para identity e device management.

A melhor forma de acompanhar isso é o Microsoft 365 Roadmap, porque ali você enxerga o que está “in development”, “rolling out” e os marcos de entrega por recurso.

Microsoft

1) O sinal mais forte de 2026: agentes “interativos” dentro de reuniões e chamadas do Teams

No Roadmap aparece um item bem representativo: Interactive Agents para reuniões e 1:1 no Teams, com rollout previsto para 2026 (o próprio item tem histórico e pode sofrer ajustes). A ideia é permitir interação com agentes no contexto da reunião, inclusive com suporte a histórico/estado da conversa.
Microsoft

Por que isso importa para arquitetos?

Reunião vira runtime de agente: a conversa deixa de ser “documentar” e vira “operar”.

Você precisa definir quem pode invocar agentes, em quais reuniões, com quais permissões e quais fontes.

A superfície de risco cresce: o que entra na reunião pode virar contexto para ações e outputs.

2) Pequenas mudanças de UX costumam indicar mudanças grandes de adoção

Um exemplo simples, mas com impacto real em produtividade: um ajuste do Teams para permitir configurar o comportamento do Enter (enviar vs quebrar linha), com previsão de rollout em 2026 segundo referências associadas ao Roadmap.
Windows Central
+1

Parece detalhe, mas para quem gerencia adoção em escala, isso é o tipo de melhoria que:

reduz atrito,
diminui “frustração do usuário”,
e melhora aceitação do produto… abrindo espaço para features maiores (como agentes) ganharem tração.

3) O que muda no desenho de arquitetura: de “feature” para “capability”

Quando Copilot/agents entram no fluxo do Microsoft 365, o arquiteto precisa parar de pensar em “habilitar licença” e começar a pensar em capability end-to-end:

(a) Governança de dados e acesso

Sem um bom modelo de permissões e higiene de conteúdo (SharePoint/Teams), agentes amplificam oversharing.

O “dado certo para a pessoa certa” deixa de ser frase bonita e vira requisito operacional.

(b) Guardrails de uso

Quais cenários são permitidos no chat? Quais exigem workflow aprovado?

Onde entra o humano no loop (aprovação de envio, criação de artefato, ações em nome do usuário)?

“O que o agente fez, quando, com qual fonte e por qual motivo?”

Sem telemetria e trilha de auditoria, você não escala com segurança.

(d) Estratégia de rollout

Começar por personas (ex.: pré-vendas, PMO, operação) costuma ser mais efetivo do que por área.

Feature flagging e pilotos controlados são indispensáveis quando agentes começam a atuar.

4) Um checklist rápido (arquitetura de adoção para 2026)

Se eu tivesse que resumir o que preparar antes de “agentes em todo lugar”:
Conteúdo e permissão: reduzir oversharing em Teams/SharePoint
Políticas de uso: o que pode/pode não pode; quem aprova o quê
Modelo de risco: classificação de cenários por criticidade (baixo/médio/alto)
Telemetria e auditoria: trilha mínima para investigação e evidência
Plano de rollout: piloto por persona + métricas de sucesso
Treinamento pragmático: “o que fazer” e “o que não fazer” com exemplos reais

Por fim...

O recado do Roadmap é que 2026 tende a ser o ano em que o Microsoft 365 se consolida como plataforma de trabalho agentic e isso puxa arquitetura junto. Quem tratar como “mais uma feature” vai sofrer no pós: incidentes de oversharing, baixa governança e pouca previsibilidade operacional.

Ótimo ano para você! Obrigado pela sua leitura!

ROI de agentes: hype ou realidade? (último do ano de 2025)

Angelo Matias — Wed, 31 Dec 2025 20:27:54 +0000

Todo CIO precisa mostrar: agentes de IA não são só brinquedo caro, eles entregam valor real!

Como medir ROI de agentes?

Custos reduzidos (menos horas manuais)
Decisões mais rápidas
Melhor experiência do usuário interno
Clientes mais satisfeitos

Exemplos práticos

Redução de 20% em tickets de suporte com agente de helpdesk
Aceleração de 30% em relatórios financeiros
NPS mais alto em atendimento digital

Segurança e governança

Revisar agentes inativos e desativar
Relacionar custos de uso ao benefício percebido

Links úteis:

https://learn.microsoft.com/pt-br/?utm_source=chatgpt.com

Se um bot não traz ROI, você teria coragem de “demiti-lo”?

Obrigado por sua leitura! Obrigado por esse ano!

Sales Development Agent no Ignite 2025: quando vendas vira “sistema de ação” (e não só CRM)

Angelo Matias — Mon, 29 Dec 2025 12:42:36 +0000

Se você trabalha com arquitetura e ainda enxerga CRM como “sistema de registro” (System of Record), o Ignite 2025 está empurrando um novo paradigma: System of Action.

A diferença é simples de explicar e difícil de implementar bem:

System of Record armazena dados (contatos, oportunidades, atividades).

System of Action executa trabalho com base nesses dados (pesquisa, abordagem, follow-up, qualificação, handoff) — com agentes operando no fluxo.

O anúncio central aqui é o Microsoft Sales Development Agent, disponível via Frontier Program em dezembro de 2025, com uma proposta direta: crescer pipeline e receita sem crescer headcount na mesma proporção.

1) O problema que todo líder de vendas vive (e TI sente depois)

Times comerciais estão sob pressão para entregar mais receita com menos recursos. A consequência é quase sempre a mesma:
leads “esfriam” porque o follow-up não escala
cadências viram planilha e dependem de disciplina humana
personalização vira promessa, não prática
vendedor passa mais tempo em tarefa operacional do que em relacionamento e closing
O Sales Development Agent entra exatamente nesse gap: ele assume a camada repetitiva e contínua do processo de SDR, e entrega o lead para o humano quando faz sentido.

2) O que o agente faz (e por que isso é mais do que automação)

A Microsoft descreve três blocos de valor bem claros:

Crescimento de receita e pipeline

O agente pesquisa prospects continuamente, cria abordagens personalizadas e faz follow-up automático para não deixar lead “morrer no funil”.
Aqui, o salto não é “mandar e-mail automático”. É operar com contexto, ajustando a mensagem e o timing baseado em sinais do negócio.

Escalabilidade com colaboração

Ele trabalha de forma independente, mas atua como “teammate”: quando precisa, faz handoff para o vendedor humano.
Para arquitetura, isso é importante: o design não é “substituir o vendedor”, é construir um fluxo human-in-the-loop com critérios claros de escalonamento.

Segurança e governança

Baseado na fundação de segurança/compliance da Microsoft e, quando habilitado com Agent 365, segue políticas robustas e controle de acesso para proteger dados e workflows.
Em outras palavras: não é “um bot externo conectando no CRM”. É uma abordagem mais corporativa, com trilha de governança.

3) Integração: onde isso realmente ganha tração

O Sales Development Agent conecta com:

CRMs líderes como Salesforce e Dynamics 365

ferramentas do dia a dia como Outlook e Teams

Isso importa porque o “sistema de ação” precisa operar no fluxo: o vendedor vive em e-mail e reunião. Se o agente não estiver ali, vira mais uma tela.

4) Resultado concreto: o que a Microsoft reportou internamente

A própria Microsoft afirmou que foi uma das primeiras a usar o agente para reinventar o processo de engagement e reportou:

+15,1% de aumento na taxa de conversão de lead para oportunidade (lead-to-opportunity conversion rate)

Independentente do número exato variar por contexto, a mensagem é: quando você automatiza pesquisa + abordagem + follow-up com consistência, você melhora o “meio do funil” — e isso costuma destravar o resto.

5) O pedaço que arquitetos precisam olhar com lupa: MCP e interoperabilidade

O post também avança em algo ainda mais estrutural: Model Context Protocol (MCP) dentro do ecossistema Dynamics 365 e Power Platform.

MCP servers são descritos como “pontes configuráveis” entre:

dados nas aplicações LOB (CRM/ERP/Dataverse/Power Apps)

e os agentes construídos (ex.: Copilot Studio)

Leitura de arquitetura:

MCP é um caminho para padronizar “como o agente acessa dados e executa ações”

reduz integrações ponto-a-ponto

cria uma base para governança e interoperabilidade

Destaques citados:

Preview (nov/2025) para simplificar integração de agentes do Dynamics 365 com fluxos complementares (pesquisa, engajamento, qualificação etc.)

MCP server para ERP em preview, expondo muitas funções em tempo real

MCP server do Power Apps em preview, permitindo agentes acionarem aprovações, submissões, recuperação de dados

Dataverse MCP server já em GA, com interações em linguagem natural e ferramentas para makers/admins

Se você quer ser arquiteto, esse é o ponto de atenção: agentes não são só “chat com IA”. Eles são consumidores de APIs com capacidade de ação. MCP tende a virar padrão para conectar esse mundo com menos fricção.

6) Como eu desenharia isso em arquitetura (sem romantizar)

Para colocar um Sales Development Agent em produção com segurança e ROI, eu estruturaria em pilares:

Pilar A — Dados e contexto (qualidade manda)

fonte de verdade no CRM (campos obrigatórios, deduplicação, governança de contas/contatos)

enriquecimento permitido (o que pode pesquisar? o que é proibido?)

regras de segmentação (ICP, territórios, indústria, tamanho)

Pilar B — Guardrails e políticas

políticas de DLP/labels para evitar vazamento em prompts e mensagens

controle de acesso (least privilege) do agente ao CRM e aos dados

regras do que o agente pode executar (enviar, agendar, atualizar CRM, criar tarefa)

Pilar C — Human-in-the-loop

critérios de handoff (ex.: lead score, intenção detectada, resposta do prospect)

playbook de “próximo passo” para o vendedor

SLAs internos para não perder timing na transição

Pilar D — Observabilidade e governança

logs de ação (o que o agente fez, quando, por quê)

métricas de funil impactadas (reply rate, meeting rate, lead-to-opportunity)

testes e rollout controlado (piloto por segmento/time)

Sem esses pilares, você tem automação. Com esses pilares, você tem sistema de ação.

Conclusão: SDR infinito não é “mágica”, é plataforma

O Sales Development Agent aponta para um futuro em que:

o agente executa a cadência com consistência e contexto

o humano foca em relacionamento, negociação e fechamento

o CRM deixa de ser só histórico e vira motor de execução

Para quem está evoluindo de dev para arquiteto, o takeaway é: a arquitetura de vendas agora precisa incluir agentes, protocolos de contexto (MCP) e governança (Agent 365) — ou a empresa vai escalar risco junto com pipeline.

Pergunta para discussão

Se você fosse pilotar um Sales Development Agent amanhã, por onde começaria?

Segmento (SMB, mid, enterprise)?

Tipo de lead (inbound vs outbound)?

Produto específico?

Ou primeiro “arrumaria a casa” no CRM (dados, dedupe, playbooks)?

Eu tendo a começar com um recorte pequeno e altamente mensurável (um produto + um segmento), e só depois escalar. E você?

Obrigado pela sua leitura até aqui!

Microsoft Fabric no Ignite 2025: dados como vantagem competitiva, arquitetura como acelerador

Angelo Matias — Fri, 19 Dec 2025 18:29:35 +0000

Se IA está virando o motor de todos os setores, existe uma constante: sem um data estate unificado, a IA vira promessa cara. A Microsoft bateu nessa tecla no Ignite 2025 ao reforçar o Fabric como o “hub” para simplificar arquitetura, acelerar insights e reduzir fricção para iterar com segurança rumo a uma organização AI-led.

E o Fabric está ganhando tração rápido: em dois anos, já soma 28 mil clientes (incluindo 80% da Fortune 500). O recado é claro: unificar dados e analytics deixou de ser “projeto de dados” e virou estratégia de negócio.

1) O salto: Fabric como ponto central do data estate (e do stack de bancos)

A Microsoft está fortalecendo a camada de bancos “no coração” do Fabric para suportar escala e performance exigidas por IA. Entre anúncios:

SQL Server 2025 (GA)

Azure DocumentDB (GA)

SQL Database e Cosmos DB no Fabric (GA)

Azure HorizonDB (preview)

A lógica por trás disso: ter opções de banco para rodar onde fizer sentido (edge, PaaS, SaaS) — mas com tudo Fabric-connected ou Fabric-native.

2) SQL Server 2025: modernização com viés de IA (sem sair do T-SQL)

O SQL Server 2025 chega como uma evolução “developer-first” para IA:

busca mais inteligente (semântica + full-text)

gestão de modelos via T-SQL (model definitions), integrando com serviços de IA (ex.: Foundry)

No lado enterprise:

performance de query e locking melhorados

failover aprimorado

credenciais mais fortes via Entra ID + Azure Arc

e, especialmente relevante para dados + IA: mirroring para OneLake (GA), colocando SQL no caminho do analytics/AI sem o ETL clássico.

3) Azure DocumentDB: NoSQL híbrido/multi-cloud, compatível com MongoDB, pronto para AI

O Azure DocumentDB entra com uma proposta bem objetiva:

padrão open-source “DocumentDB” compatível com MongoDB

roda consistente em Azure, on-prem e outros clouds

pronto para IA com vector e hybrid search

Para arquitetos, isso é uma peça importante em estratégias híbridas e multi-cloud: reduz “replatforming forçado” e mantém um caminho mais limpo para apps inteligentes.

4) HorizonDB: PostgreSQL para missão crítica (preview)

O HorizonDB (preview) tenta capturar o espaço de Postgres enterprise em larga escala com:

Postgres compatível

auto-scaling de storage e compute

latência multi-zona muito baixa

vector search e gestão de modelos integrada

conectividade direta com Foundry (para apps de IA)

Leitura prática: a Microsoft está reforçando Postgres como base para workloads modernos e AI-ready no enterprise.

5) Fabric SaaS Databases (GA): banco transacional dentro do mesmo “plano” de dados + IA

A disponibilidade geral de SQL Database e Cosmos DB no Fabric posiciona o Fabric como uma plataforma “developer-first”:

provisionamento rápido

menos configuração granular

segurança por padrão (auth cloud, encryption, CMK)

billing alinhado à capacidade do Fabric

O ganho arquitetural é reduzir a distância entre:

dado operacional/transacional (apps)

e dado analítico/AI (insights e agentes)

6) OneLake: “zero-ETL” para unificar (e agora trazendo produtividade junto)

O OneLake continua sendo a aposta para unificação com shortcuts e mirroring (menos cópia, menos pipeline, mais governança).

Novidade relevante: shortcuts para SharePoint e OneDrive (preview) — trazendo dado não estruturado do mundo de produtividade para o lake sem duplicar arquivos. Isso é particularmente importante para cenários de RAG e agentes, onde “documentos do trabalho” são contexto valioso.

7) Fabric IQ: semântica como combustível de IA (não é volume, é contexto)

A Microsoft introduziu o Fabric IQ, um workload para criar uma camada semântica que mapeia dados para entidades reais do negócio (relacionamentos, regras, hierarquias).

A mensagem é madura: IA não escala com tabelas; escala com significado. E isso prepara o terreno para operations agents que monitoram sinais, detectam padrões e tomam ação com base em contexto do negócio — não só em schema.

8) Agentes e MCP: Fabric virando “bloco composável” do ecossistema de IA

O Fabric está ampliando experiências de IA:

Copilot no Power BI

data agents para análises mais profundas

operations agents para ação em tempo real

E um detalhe arquitetural importante: data agents podem atuar como servidores MCP (hosted), facilitando integração com outros apps e agentes no ecossistema. Além disso, há integração com Azure AI Search para raciocinar sobre dados estruturados e não estruturados.

Obrigado pela sua leitura até aqui!

Microsoft Purview no Ignite 2025: segurança de dados integrada para a era de IA e agentes

Angelo Matias — Thu, 18 Dec 2025 16:55:40 +0000

Se você ainda pensa em segurança de dados como “perímetro + ferramentas isoladas”, 2025 já te passou por cima.

Hoje os dados circulam entre multi-cloud, SaaS, endpoints, copilots, agentes autônomos e pipelines de dados (Fabric, lakes, warehouses) numa velocidade que ferramentas legadas e silos simplesmente não acompanham. O resultado é previsível: baixa visibilidade, alto risco e resposta lenta — mesmo com investimentos gigantescos em segurança.

No Microsoft Ignite 2025, o posicionamento do Microsoft Purview como a resposta para esse novo cenário: uma plataforma de segurança e governança de dados integrada ao fluxo de trabalho (Microsoft 365, Azure, Fabric) e cada vez mais estendida para fora do ecossistema Microsoft.

A mensagem é direta: segurança de dados deixou de ser “visibilidade” e virou “ação” — orientada a postura, risco e automação.

O problema real: por que os modelos antigos falham

Três dores aparecem com frequência em qualquer conversa séria com CISO, DPO, arquitetura e engenharia:

Ferramentas fragmentadas
Soluções pontuais que não conversam bem → você perde o “filme” do risco e só enxerga “frames”.
Risco novo com IA no trabalho
Prompt vira canal de exfiltração. Agente vira executor. RAG vira “busca com consequência”.
Escassez de mão de obra especializada
Não dá para escalar segurança apenas com mais pessoas. Precisa escalar com automação + inteligência.

É nesse contexto que Purview evolui: menos “console de compliance”, mais plataforma operacional de proteção e governança de dados.

1) DSPM (Data Security Posture Management): de dashboard para playbook acionável

Uma das maiores novidades é a evolução do Purview DSPM, agora com uma experiência unificada (DSPM + DSPM for AI), como “ponto central” para insights e controles.

Na prática, DSPM está virando um sistema de postura: você não só mede o risco, você orquestra a correção.

Destaques:

Workflows orientados a resultados (Outcome-Based)

Você escolhe um objetivo (ex.: reduzir oversharing, melhorar rotulagem, reduzir DLP gaps) e recebe:

métricas relacionadas
padrões de risco
plano de ação recomendado
impacto esperado

Isso é muito “arquitetural”: cria linguagem comum entre segurança, compliance e tecnologia. Menos debate abstrato, mais backlog priorizado.

Remediação em escala

Avaliações de risco com análise em nível de item e ações concretas (ex.: desabilitar em massa links overshared no SharePoint).
Isso reduz o “tempo entre achar e corrigir” — o famoso gap que vira incidente.

Postura pronta de fábrica (Out-of-box reports)

Relatórios prontos com contexto real:

uso de labels
efetividade de auto-labeling
drift de postura (transições de label)
atividades de DLP

AI Observability

Inventário de agentes + nível de risco + métricas de postura com base nas interações agentic com dados corporativos.
Esse ponto é crucial: se você não consegue inventariar agentes, você não governa agentes.

Copilot para segurança (Security Copilot Agent)

Agente para acelerar descoberta/análise de dados sensíveis em arquivos, emails e mensagens — reduzindo o trabalho manual do time de segurança.

Visibilidade para dados fora da Microsoft

Integrações para enxergar riscos em Salesforce, Snowflake, GCP, Databricks (via integrações com parceiros e Microsoft Sentinel).
Leitura de arquiteto: o jogo é data estate, não “tenant”.

2) Auto-labeling expandido: governança que acompanha onde o dado vive

Purview está expandindo auto-labeling para novas fontes do Data Map (ex.: Snowflake, SQL Server, Amazon S3).

O que isso muda na vida real?

Você para de depender do usuário “lembrar de rotular”.
Você aplica política de forma consistente (e auditável).
Você prepara o terreno para IA com menos risco: se não classifica, não controla; se não controla, oversharing é questão de tempo.

3) Purview para agentes: quando “identidade” vira requisito de governança

Aqui está a parte que mais interessa para quem quer ser arquiteto de solução em cenário corporativo com IA.

Com agentes autônomos, surgem riscos novos:

acesso não supervisionado
interações em cascata (agente falando com agente)
accountability nebulosa (quem “fez” a ação?)

A evolução do Purview aponta para dois modelos:

Agentes que herdam políticas do usuário
Agentes com identidade própria (Agent ID), com políticas e controles específicos

E isso muda completamente o desenho de segurança.

Principais extensões:

Information Protection e DLP aplicados a agentes (Agent ID)
Você consegue aplicar políticas Purview considerando o agente como entidade governável.
Insider Risk Management para agentes
Indicadores e analytics comportamentais dedicados para detectar atividade suspeita de agente e atribuir score/nível de risco.
Compliance end-to-end para interações agentic
Communication Compliance, Data Lifecycle Management, Audit e eDiscovery cobrindo interações de agentes.
Purview SDK embutido no Agent Framework SDK
Isso é a ponte para dev/pro-code: permitir que agentes nasçam com classificação, prevenção de leak/oversharing e trilha de compliance “by design”.
Integração com Foundry
Interações de apps e agentes fluem para Purview para governança centralizada.
Azure AI Search honrando labels e políticas Purview
Esse ponto é ouro para arquitetura de RAG:
- indexadores (SharePoint, OneLake, Blob, ADLS Gen2) ingerem labels
- a busca aplica políticas correspondentes
- só retorna documentos autorizados, evitando oversharing em cenários agentic RAG
DLP estendido ao Copilot Mode no Edge for Business

Navegação assistida por IA respeitando proteções existentes (ex.: impedir colar em domínios sensíveis, evitar sumarizar conteúdo sensível).

4) Proteção contra oversharing com IA: o prompt virou “superfície de ataque”

Duas evoluções aqui são bem práticas:

DLP para Copilot: agora protegendo prompts

Antes: bloquear arquivos/emails rotulados como grounding.
Agora: bloquear prompt com dado sensível em tempo real — e impedir até consultas web que levariam o dado para fora do ambiente controlado.

Isso é uma virada importante: o controle não é só no “documento”, é no fluxo de interação.

Proteção inline ampliada no Edge for Business

Protege contra vazamento para apps de IA “consumer”
Expande o suporte para dezenas de apps e também para upload de arquivos, não só texto

Proteção inline em nível de rede (SSE)

Para atividades fora do browser, integrações com SSE (ex.: Netskope, iboss, etc.) para detectar e agora também bloquear dados sensíveis indo para destinos não gerenciados.

Purview e IA on-device (ex.: Recall em Copilot+ PCs)

DLP pode impedir captura/retention de conteúdo sensível baseado em label ou SITs.
Aqui entra um tema que arquitetos precisam antecipar: política de dado também no endpoint, não só na nuvem.

5) “Higiene corporativa” que dá escala: melhorias que parecem pequenas, mas mudam o jogo

Algumas capacidades são menos “glamourosas”, mas resolvem problemas reais:

Classificação sob demanda para transcrições de reunião
Porque muita informação sensível mora em transcrição gravada — e isso vira ouro (e risco) em ambientes com Copilot.
Extended SharePoint permissions
Aplicar label padrão em uma library inteira com enforcement dinâmico e criptografia automática em downloads, com controle via membership.
Isso facilita muito “arrumar a casa” em SharePoint antes de liberar IA em larga escala.
Endpoint DLP ampliado
Proteção para:
- arquivos não salvos
- mídia removível (mais ampla)
- anexos do Outlook sendo copiados para USB/network shares
- expansão de capacidades para macOS
Melhorias operacionais em DLP

Diagnósticos always-on, acesso on-demand a logs, investigação de alertas simplificada e severidade sincronizada com Defender.
Relatórios de consumo e postura

Ajuda a identificar gaps, otimizar licenças e entender custos de features consumptivas.

Arquitetos precisam disso para sustentar governança financeira do programa.

6) O que eu levaria para uma mesa de arquitetura: o “novo stack mínimo” para IA segura

Se você está desenhando adoção de Copilot/agentes em ambiente corporativo, Purview entra como peça estrutural.

Checklist de arquiteto:

Classificação e rotulagem (labels)
DLP baseado em conteúdo + contexto + identidade (usuário e agente)
Postura e priorização (DSPM) com workflows acionáveis
Observabilidade de agentes (inventário + risco)
RAG com enforcement de política (ex.: Azure AI Search honrando labels)
Cobertura de endpoints e rede (Edge + SSE + endpoint DLP)
Auditoria, retenção e eDiscovery para accountability agentic

Sem isso, o programa de IA pode até crescer rápido… mas cresce com risco proporcional.

Conclusão: segurança de dados não é “freio”; é habilitador de IA em escala

O que o Ignite 2025 sinaliza é uma mudança de mentalidade:

Antes: “vamos proteger arquivos”.
Agora: “vamos proteger interações, fluxos e execução por agentes”.

Purview está sendo posicionado como a base para transformar segurança de dados em vantagem estratégica, permitindo adoção de IA com velocidade — mas com controle, rastreabilidade e governança.

Para quem quer virar arquiteto: dominar Purview não é sobre “compliance por compliance”. É sobre projetar um ambiente onde IA pode operar com segurança, sem travar o negócio e sem deixar o risco invisível.

Pergunta para discussão

Na sua empresa, qual é o maior bloqueio para adotar IA em escala com segurança?

Falta de classificação/labels?
SharePoint/Teams “overshared” há anos?
DLP difícil de operar (ruído, falso positivo)?
Falta de visibilidade de dados fora da Microsoft?
Medo de vazamento via prompt e apps consumer?

Obrigado pela sua leitura até aqui!

Low-code, high-power: lições aplicadas à IA

Angelo Matias — Wed, 17 Dec 2025 17:06:24 +0000

Se o low-code já ensinou que qualquer um pode construir apps, por que não aplicar isso aos agentes de IA?

Lição 1: Segurança

Identidade e acesso controlados
Políticas de DLP aplicadas também em agentes

Lição 2: Operações

ALM (ciclo de vida) com dev, teste e produção
Logs de auditoria integrados

Lição 3: Disponibilidade

Failover automático e backups
Continuidade de negócios mesmo com agentes críticos rodando

Exemplos práticos

Reaproveitar CoE já existente para governar agentes
Criar pipelines de aprovação antes de bot ir pra produção

Links úteis

Copilot Studio Governance: https://learn.microsoft.com/microsoft-copilot-studio?utm_source=chatgpt.com

Low-code foi o treino. IA agents estão no jogo do campeonato.

Obrigado pela sua leitura!

Microsoft Ignite 2025: Copilot, Agents e a “Frontier Firm”! O que muda para arquitetos de solução

Angelo Matias — Wed, 17 Dec 2025 16:38:19 +0000

Se você é dev mirando virar arquiteto de soluções, essa virada é importante porque mexe com tudo o que arquitetos realmente carregam nas costas: governança, segurança, integração, observabilidade, compliance e desenho de processos.

Frontier Firm na prática: “agent-first” sem virar bagunça

A proposta é clara:

Cada colaborador tem um assistente (Microsoft 365 Copilot).
Times trabalham com agentes colaborativos (Teams + agentes por canal).
Processos de negócio ganham automação orientada a agentes (da pesquisa à execução).
A TI ganha um plano de controle para cadastrar, governar, monitorar e proteger esses agentes.

Tradução: o que antes era “um bot aqui e ali” vira uma frota de agentes com identidade, acesso a dados e capacidade de executar ações. E isso exige arquitetura séria.

2) Work IQ: a camada que faz o Copilot “entender trabalho”, não só texto

O anúncio mais estratégico (e mais arquitetural) é o Work IQ: a camada de inteligência por trás do Copilot e dos agentes.

Pense em Work IQ como a combinação de três coisas:

Dados de trabalho: e-mails, arquivos, chats, reuniões — o conhecimento vivo da empresa.
Memória: seu estilo, preferências, hábitos e workflows — como você e seu time realmente trabalham.
Inferência: conexões e “próxima melhor ação” — vai além de buscar informação; sugere caminhos, decisões e execução.

O salto aqui é que a IA deixa de ser só “resposta” e vira feedback loop: aprende com o sinal do trabalho real e devolve ações mais contextualizadas.

Para arquitetos, isso muda a pergunta de:

“Como conecto o Copilot ao meu sistema?”

para:

“Como projeto grounding, permissões, labels, auditoria, logs e monitoramento para uma inteligência que opera dentro do fluxo do negócio?”

3) Agents no Office: do “assistente” para “produção iterativa de artefatos”

Uma mudança prática: Word, Excel e PowerPoint entram num modo onde você trabalha iterativamente com agentes para gerar artefatos de alta qualidade.

O Office vira uma “linha de produção”:

você descreve intenção,
o agente rascunha,
você revisa,
ele ajusta,
você publica.

Isso parece simples, mas em empresas impacta diretamente:

padronização de documentos (templates, playbooks, padrões de proposta)
rastreabilidade (fontes, versões, responsabilidade)
risco de dados (o que entra no prompt, o que pode sair como output)

Se o Copilot acelera a geração, a arquitetura precisa acelerar a governança do conteúdo.

4) Agent 365: o “control plane” que finalmente conversa com realidade corporativa

Se Work IQ é a inteligência, o Agent 365 é o plano de controle: o que impede sua empresa de virar um zoológico de agentes.

Na visão apresentada, ele traz capacidades-chave:

Registry: inventário central de agentes (fonte de verdade).
Access control: privilégio mínimo (least privilege) para cada agente.
Visualização/analytics: conexões entre agentes, pessoas e dados; comportamento e performance.
Interoperabilidade: agentes equipados com apps e dados para fluxos humano-agente.
Security: proteção contra ameaças e resposta a ataques voltados a agentes.

Para quem quer ser arquiteto: esse é o ponto em que “agente” vira uma entidade operacional de primeira classe — quase como um microserviço com identidade, escopo e telemetria.

5) Teams + MCP: integração de agentes começando a virar padrão

Outro ponto relevante: agentes em canais do Teams se conectando a apps/agentes terceiros via Model Context Protocol (MCP) (ex.: GitHub, Asana, Atlassian/Jira).

Isso é um sinal de maturidade do mercado: em vez de integrações ad hoc, começa a aparecer um contrato padrão para contexto + ferramentas + ações.

Se você é arquiteto, anote:

padrões desse tipo reduzem lock-in,
aceleram integração,
e criam governança mais consistente (porque “como integrar” deixa de ser um caso por vez).

6) Como eu venderia isso internamente: a jornada de adoção por camadas

Se você quer defender Copilot + agentes sem parecer “apenas empolgação”, uma boa estratégia é desenhar adoção em camadas:

Camada 1 — Fundacional (sem isso, escala vira risco)

identidade e controle de acesso (RBAC/ABAC)
classificação/rotulagem (sensitivity labels), DLP, retenção
auditoria e logs centralizados
diretrizes de uso e catálogo de dados

Camada 2 — Produtividade (quick wins com guardrails)

Copilot Chat como entrada segura para o usuário
Agent Mode no Office com templates e padrões
casos de uso internos: resumo de reunião, status report, triagem de e-mails

Camada 3 — Processos (onde o ROI aparece)

agentes por domínio (vendas, jurídico, RH, TI)
automações por eventos (workflows)
integrações padronizadas (MCP/ITSM/DevOps)

Camada 4 — Operação (AgentOps real)

inventário + lifecycle + versionamento de agentes
telemetria: custo, qualidade, drift, segurança, incidentes
esteira de governança: aprovar, publicar, monitorar e desativar

Minha leitura final: “agentic enterprise” é arquitetura, não feature

O Ignite 2025 deixa o recado: a unidade de automação está mudando. Não é só workflow, não é só bot, não é só RPA. É um ecossistema de agentes com:

inteligência corporativa (Work IQ),
execução no fluxo do trabalho (Office/Teams/Windows/Edge),
e governança (Agent 365).

Se você quer virar arquiteto, a habilidade crítica é tratar agentes como você trata sistemas:
identidade, contrato, integração, observabilidade, segurança, governança e custo.

Pergunta para discussão (comentários)

Se você pudesse colocar um único agente na sua empresa hoje, qual seria o primeiro?

Facilitador de reuniões (agenda, notas e ações)?
Agente de status de delivery puxando riscos do Jira?
Agente de triagem e resposta de e-mails?
Agente de pré-vendas para acelerar pipeline?

Eu começo: o primeiro que eu colocaria é um agente de execução de governança... aquele que automatiza conformidade e evidencia (logs, labels, acessos) antes de sair criando agente para todo lado.

Obrigado por ler até aqui!

O novo organograma: CAIO, AI Risk Officer e companhia

Angelo Matias — Mon, 08 Dec 2025 14:34:33 +0000

A IA não cria só bots, cria também novos cargos

Novos papéis

Chief AI Officer (CAIO)
AI Risk Officer
AI Security Specialist
AI Community Manager

Por que isso importa?

Governar IA envolve tecnologia, ética, compliance e até cultura. Não dá pra deixar só na mão da TI.

Exemplos práticos

Empresas criando times de AI Champs para treinar outros funcionários
Organizações revisando políticas de ética em IA em conjunto com jurídico e RH

Qual desses cargos você acha que vai existir primeiro na sua empresa?

Obrigado pela leitura!

Governança não é burocracia, é liberdade com limites

Angelo Matias — Thu, 27 Nov 2025 17:58:45 +0000

Muita gente acha que governança trava inovação. Na real, ela cria segurança para ousar.

Por que governança é essencial?

Dá clareza de responsabilidades
Cria regras de acesso e uso de dados
Permite monitoramento contínuo
Evita que experimentos virem caos em produção

Exemplos práticos

Permitir que makers criem bots, mas em ambientes isolados
Revisar periodicamente agentes com muito acesso
Usar DLP para impedir vazamento de dados sensíveis
Segurança e privacidade
Controles no Power Platform Admin Center
Microsoft Purview para auditoria

Revisão de logs no Microsoft Sentinel

🔗 Links úteis

Microsoft Purview Overview: https://learn.microsoft.com/microsoftpurview?utm_source=chatgpt.com

Power Platform Governance: https://learn.microsoft.com/power-platform/admin/?utm_source=chatgpt.com

Você prefere inovar livremente sem rede de proteção ou criar com segurança sabendo que não vai se queimar?

Obrigado por sua leitura!

Zonas de governança: playground vs. produção

Angelo Matias — Mon, 27 Oct 2025 13:22:53 +0000

Não dá pra misturar experimentação com produção. Por isso existe o modelo de “zonas” (landing zone).

As 3 zonas

Zona 1 – Playground: makers testam ideias sem risco
Zona 2 – Colaboração: times criam juntos com mais controle
Zona 3 – Produção: bots auditados, monitorados e críticos para o negócio

Benefícios

Evita shadow IT
Escala inovação com segurança
Dá clareza sobre riscos

Links úteis

Zoned Governance Model: https://learn.microsoft.com/?utm_source=chatgpt.com

Onde você colocaria o seu primeiro agente hoje: playground, colaboração ou produção?

Obrigado pela sua leitura!