O relatório virou aplicativo e o Fabric pré-pago
Nesta edição
- 🟠 Apps no Power BI chegam ao Pro e ao PPU e eles gravam dados
- 💳 F0: dá para começar no Fabric sem comprar capacidade
- 🔓 O acesso da IA ao seu modelo semântico vem ligado por padrão
- 🛠️ Entrou em preview um agente de engenharia de dados
- 📚 Artigo: a sua rotina virou uma linha no orçamento
#DataNews 📰
Notícias sobre o mundo dos dados e IA para ler enquanto toma um café ☕
Apps no Power BI chegam ao Pro e ao PPU 🟠
Na semana passada, em Barcelona, a Microsoft anunciou a criação de aplicativos a partir do Power BI, construída sobre o Fabric Apps. É a mudança mais concreta do FabCon para quem já publica relatório.
O caminho é este: você parte de um modelo semântico em que já confia, descreve o aplicativo em linguagem natural, pré-visualiza, edita e publica no Fabric.
A diferença não está na tela. Está no que ela faz: esses apps aceitam entrada de dados, gravam de volta e mantêm estado compartilhado. Cada um ganha banco de dados próprio, autenticação e segurança.
Ou seja, o relatório deixa de só mostrar número e passa a receber. O ciclo "exporta pro Excel, preenche na mão, manda por e-mail, alguém recarrega" encolhe.
💡 você sabia?
A Microsoft diz que os apps ficam disponíveis em preview nas próximas semanas para Power BI Pro e Premium Per User, além de quem tem capacidade Fabric, sem custo adicional, incluindo banco de dados de até 1 GB por app. A criação dentro do Desktop vem depois, "nos próximos meses".
Qual planilha do seu time viraria um app primeiro?
F0: dá para começar no Fabric sem comprar capacidade 💳

Até agora, entrar no Fabric exigia escolher uma capacidade antes de provar que valia a pena. O F0 desmonta essa ordem: é uma capacidade zero provisionada, ou seja, com acesso ao Fabric e ao OneLake sem computação reservada.
Junto vem a cobrança sob demanda, ligada por padrão no F0 e estendida aos demais workloads. Nas opções de F2 ou acima, dá para mover categorias de cobrança específicas para sob demanda e deixar o resto reservado.
Sob demanda significa pagar o que se consome, medido em CU-hora, com limite de gasto numa janela móvel de 24 horas. (CU é a unidade de capacidade do Fabric, o "medidor" do consumo.)
Porém, o preço não foi publicado. O multiplicador sobre a tarifa pay-as-you-go não saiu em Barcelona, e os dois recursos estão como "em breve", em preview nas próximas semanas. Nada de cancelar reserva por causa de anúncio.
💡 você sabia?
Existe um irmão menos comentado disso: o capacity overage, já em disponibilidade geral. É computação paga a mais para a capacidade não entrar em throttling (freio por excesso de uso), cobrada em medidor separado a 3x a tarifa pay-as-you-go e sem desconto de reserva. O limite de 24h é um teto de gasto. Vale conferir a configuração em cada capacidade.
Se o seu projeto fosse pago por uso, ele ainda pareceria barato?
O acesso da IA ao seu modelo vem ligado por padrão 🔓

Na #96 a gente contou que o dono do modelo passou a poder bloquear usuários somente-leitura de chegarem ao modelo via Copilot ou MCP. A informação adicional é que essa chave vem ligada.
É uma configuração por modelo semântico, gerida por quem tem permissão de escrita. Ela decide se usuários somente-leitura alcançam o modelo pelo Copilot do Power BI, pelo Microsoft 365 Copilot Chat e Cowork, pelos data agents e pelos servidores MCP do Fabric e do Power BI.
Enquanto ninguém desligar, o acesso continua. São duas camadas de controle: a do administrador (Restrict from Copilot, que define quais modelos participam de experiências de IA) e a do dono do modelo.
A boa notícia é que rótulos de confidencialidade agora acompanham o conteúdo para dentro do Copilot. Assim, o cuidado que você já teve não se perde no caminho.
💡 você sabia?
O Microsoft 365 Copilot dentro do Power BI entrou em preview com a lógica inversa: vem desligado, atrás de uma configuração nova no portal de administração do Fabric, independente da configuração do Copilot do Power BI, e só para quem tem licença do Microsoft 365 Copilot.
Dez minutos hoje: liste seus três modelos mais sensíveis e confira essa chave.
Entrou em preview um agente de engenharia de dados 🛠️

A Microsoft colocou em preview um agente construído sobre a tecnologia da Osmos, empresa que ela comprou. Ele assume trabalho longo e chato: migrações, harmonização de esquema e ETL (extrair, transformar e carregar o caminho do dado bruto até a tabela pronta).
O desenho conversa direto com o que discutimos na #96: o engenheiro define o resultado e os limites; o agente planeja, executa e valida, rodando no Fabric Spark.
E ele pode ser levado para fora, para locais como GitHub Copilot, VS Code, Codex e Claude Code, o que indica para onde esse tipo de ferramenta está indo: um caminho menos botão e mais instrução.
Importante: validar não é o mesmo que estar certo. O agente confere se o processo rodou. Continua sendo você quem sabe qual número deveria aparecer no fim.
💡 você sabia?
Desde 1º de outubro, experiências de IA selecionadas no Fabric/Copilot no Fabric, data agents, AI Functions e ontologias do Fabric IQ, saíram do consumo fixo para o dinâmico: mede-se o recurso que cada tarefa exige, e a taxa pode variar conforme o tamanho do modelo usado.
Que parte do seu ETL você delegaria primeiro e como conferiria o resultado?
A sua rotina virou uma linha no orçamento 📚
Repare no que as três notícias desta edição têm em comum. O Fabric passou a cobrar por uso. As experiências de IA passaram a medir o recurso de cada tarefa. E o relatório ganhou a capacidade de receber dado em vez de só exibir.
Junte os três e aparece uma mudança silenciosa: o seu jeito de trabalhar passou a ter preço por execução.
Produtividade x Velocidade
Durante muito tempo, "ser produtivo" em dados significou entregar mais rápido. E com a IA, bater essa métrica de produtividade é tentador, afinal, quem não quer uma IA que já faz todo o processo "chato" e entrega o dashboard final para revisão? Quando a computação é cobrada por uso, o que pode pesar não é o que você faz, é o que você refaz. E refazer pode ter um custo oculto, que sempre foi invisível, porque não aparecia em lugar nenhum. Agora aparece.
Três trabalhos que somem do orçamento
- O trabalho que você refaz. A atualização que roda seis vezes porque ninguém sabe qual versão é a boa. O modelo recarregado inteiro para corrigir uma coluna. Antes isso custava só paciência e agora custa dinheiro.
- O trabalho que você espera. A planilha que vai por e-mail, volta preenchida errada e precisa de outra rodada. É exatamente esse ciclo que os apps com gravação de dados tentam resolver.
- O trabalho que nunca deveria ter começado. O relatório que ninguém abre há sete meses e atualiza de hora em hora. Esse é o mais caro dos três, e o único que some sem ninguém sentir falta.
A rotina se impõe, e não a ferramenta
Nenhum desses três se resolve trocando de ferramenta. Eles se resolvem na rotina: quem atualiza o quê, com que frequência, e quem foi avisado quando o número mudou.
É um trabalho pouco glamouroso. Mas é o que separa um ambiente que custa pouco e responde rápido de um que custa caro e ninguém confia.
Um aviso para não virar avareza
Seria fácil ler até aqui e concluir que a meta é gastar menos. Não é. Custo é um sintoma e não um objetivo último. Tem relatório caro porque gera valor e vale cada centavo, e relatório barato que não deveria existir.
A pergunta certa não é "quanto isso custa?". É "quantas vezes isso precisou acontecer para entregar uma decisão?". Se a resposta for 6, 7, 10 e deveria ser menos, o problema não é o preço e sim o processo.
🛠️ dica: sua tarefa desta semana
Escolha o relatório que você mais atualiza na mão. Cronometre uma rodada completa, da origem até alguém ler. Depois marque quantos passos existem ali só porque o dado precisa voltar para uma planilha. Esse número é a sua lista de corte. E, pela primeira vez, ele tem preço.