AI-agents genereren queries die je pipeline monitoring niet kan traceren

Een Power BI dataset refresh mislukt om 03:14 uur met error code DMTS_DM_Error_1030: timeout tijdens query execution. Je opent de actualisatiegeschiedenis. Je ziet dat de duur piekte. Je controleert de data source. Die is prima.

Wat je niet ziet: een Copilot-gegenereerde DAX-measure is twee uur eerder aan het model toegevoegd door een business analyst die Copilot vroeg om 'omzet per regio weergeven gecorrigeerd voor valuta.' Copilot produceerde een SUMMARIZECOLUMNS-expressie met een geneste CALCULATETABLE die uitwaaiert over een fact table van 40 miljoen rijen zonder filtercontext. De measure compileerde. In Desktop gaf die zelfs resultaten terug. Maar bij de refresh, wanneer de Analysis Services-engine alle measures evalueert voor metadata, explodeert het query plan.

Het refresh log registreert de timeout. Het registreert de naam van de dataset. Het registreert niet dat de measure AI-gegenereerd was, want Power BI maakt geen onderscheid tussen DAX die mensen hebben geschreven en DAX die Copilot heeft gegenereerd. Voor de engine is een measure een measure.

Dat is het kernprobleem. Elk monitoring tool in de Microsoft data stack (de Activity Events API, XMLA endpoint diagnostics, Azure Monitor) behandelt query execution als een black box met een auteursveld dat 'user@domain.com' zegt. Of die gebruiker de DAX met de hand heeft getypt of op Accept heeft geklikt bij een Copilot-suggestie: voor de telemetrie maakt dat geen verschil. Hetzelfde gat bestaat in Databricks, waar AI-ondersteunde notebook-cellen SQL genereren die onder de identiteit van de notebook-eigenaar naar Unity Catalog worden gestuurd. En in Azure Data Factory, waar Copilot nu pipeline-expressies kan suggereren die onderdeel worden van je gedeployde data flows.

De failure modes zijn identiek aan fouten van mensen. De observability gap is dat je ze niet kunt filteren, niet kunt tracken over de tijd en niet kunt correleren aan het moment dat een agent de code produceerde.

Data lineage tools lezen je repository. Ze traceren een kolom van een dbt-model terug door een staging-laag naar een brontabel. Dat werkt omdat de SQL statisch is: die staat in een .sql-bestand, is gecommit naar Git en de lineage graph wordt gebouwd bij compile time.

Door agents gegenereerde SQL heeft geen bestand. Wanneer een Databricks AI function een query genereert in een notebook, of wanneer ADF Copilot een derived column-expressie suggereert, bestaat die code alleen op runtime. Die staat niet in je repo. Niet in je dbt manifest. Die staat in een execution log als je geluk hebt, en in ephemeral memory als je dat niet hebt.

Dit breekt lineage op twee manieren. Ten eerste kunnen downstream-consumers hun inputs niet traceren. Als een AI-gegenereerde transformatie een tabel omvormt die een Power BI dataset voedt, toont de lineage graph een gat: data arriveert in het semantic model vanuit een bron zonder gedocumenteerde transformatielogica. Ten tweede faalt impactanalyse. Wanneer je de vraag 'wat breekt er als ik deze kolom hernoem?' moet beantwoorden, kan je lineage tool geen rekening houden met door agents gegenereerde queries die die kolom dynamisch refereren.

Databricks Unity Catalog logt query-tekst wel in de query history, en je kunt die opvragen via de system.access.audit-tabel. Maar er is geen vlag die AI-gegenereerde queries van menselijke onderscheidt. Je zou de query-tekst moeten parsen op patronen: ongebruikelijke aliasing, specifieke opmaakkenmerken die LLMs produceren. Die aanpak is fragiel en onbetrouwbaar.

De praktische consequentie: je lineage-documentatie drijft af van de werkelijkheid elke keer dat een agent een query schrijft die niet in je transformatielaag wordt vastgelegd. Teams die voor compliance of debugging op lineage vertrouwen, werken met een onvolledige kaart. Ze merken dat mogelijk pas als een kolomwijziging uitmondt in een failure die ze niet kunnen verklaren.

Traditionele pipeline monitoring vertrouwt op baselines. Een dataset refresh die normaal 8 minuten duurt maar ineens 25 minuten in beslag neemt, triggert een alert. Dat werkt wanneer de workload deterministisch is: hetzelfde model, dezelfde queries, hetzelfde datavolume, voorspelbare groei.

AI-agents breken die aanname. Een Copilot-gegenereerde measure kan afhankelijk van de formulering van de gebruiker verschillende query plans produceren. Twee analisten die om 'omzet per kwartaal' en 'kwartaalomzet uitsplitsing' vragen, kunnen functioneel vergelijkbare maar structureel verschillende DAX krijgen. Elk produceert een andere memory footprint, een ander aantal storage engine-queries en een andere uitvoeringstijd.

In Databricks betekent AI-ondersteunde code-generatie in notebooks dat hetzelfde notebook verschillende SQL kan produceren per run als de cel opnieuw is gegenereerd. Een data engineer kan op maandag een Copilot-suggestie accepteren die een window function gebruikt, en op woensdag dezelfde cel opnieuw genereren en een CTE-gebaseerde aanpak krijgen. Beide zijn correct. Beide hebben andere performance-kenmerken. Je monitoring ziet twee verschillende execution profiles voor hetzelfde notebook en kan de variantie niet koppelen aan een codewijziging die buiten version control plaatsvond.

Dat maakt anomaly detection onbetrouwbaar. Als je baseline is opgebouwd uit een mix van menselijk en agent-geschreven query executions, is de variantie in de baseline zelf groter dan zou moeten. Echte anomalieën, zoals een trage data source of een onverwacht groeiende tabel, verdwijnen in het ruis van de agent-gegenereerde query-variantie.

De oplossing is niet om AI-agents uit je data stack te weren. Dat schip heeft gevaren: Microsoft meldde dat 70% van de Fortune 500-bedrijven begin 2026 Copilot-functies in Fabric gebruikte. De oplossing is je monitoring te instrumenteren om te detecteren wanneer execution-patronen afwijken van gecommitte code, zodat je in elk geval kunt isoleren welke failures correleren met niet-gecommitte, mogelijk door agents gegenereerde wijzigingen.

Organisaties die Power BI Copilot in fases uitrolden, zagen een patroon: refresh failure rates piekten 2-3 weken na elke golf van gebruikersactivering. Niet direct, want Copilot-suggesties beginnen in Desktop en het duurt even voordat die measures en visuals naar de Service worden gepubliceerd en de refresh-cyclus raken.

De failure-signaturen zijn consistent. DMTS_DM_Error_1030 (timeout) en DMTS_DM_Error_1033 (memory exceeded) komen vaker voor. De betrokken datasets zijn doorgaans grotere semantic models waar Copilot-gegenereerde measures interacteren met complexe relaties. De fouten zijn legitiem: de queries overschrijden daadwerkelijk resource-limieten. Maar de root cause is een measure die niemand in het datateam heeft geschreven of beoordeeld.

ADF-pipelines laten een vergelijkbaar vertragingenpatroon zien. Wanneer Copilot ingeschakeld is voor pipeline authoring, nemen expressiefouten in derived column-transformaties binnen weken toe. De fouten zijn vaak type mismatches: Copilot genereert een expressie die ervan uitgaat dat een string-kolom numeriek is, of produceert een datumformaat dat niet overeenkomt met de bron. Deze failures verschijnen bij pipeline runtime als DFExecutorUserError met een interne melding over type conversion, wat er identiek uitziet als een expressiefout van een mens.

De correlatie is moeilijk te bewijzen met alleen native tools, want je zou de timestamp van elke Copilot-interactie moeten koppelen aan opvolgende pipeline- of refresh-failures. De Activity Events API registreert sommige Copilot-gebruiksgebeurtenissen, maar die data koppelen aan refresh failure logs vereist maatwerk: een pipeline bouwen om je pipelines te monitoren, precies het soort recursieve complexiteit dat engineering-tijd opbrandt.

MetricSign detecteert deze failure-clusters door refresh errors over datasets te groeperen en timingpatronen te correleren met root cause-context, zodat je kunt vaststellen of een piek in timeouts samenvalt met een model-wijzigingsvenster in plaats van een probleem bij de data source.

Je kunt niet wachten tot Microsoft of Databricks een 'AI-gegenereerd'-vlag toevoegt aan elk query log. Maar je kunt met bestaande mogelijkheden al guardrails bouwen.

In Power BI gebruik je XMLA endpoint read-toegang om periodiek een snapshot te maken van je semantic model-metadata. Script het met het Tabular Object Model (TOM): enumereer alle measures en calculated columns, hash hun expressies en sla de hashes op met timestamps. Wanneer een refresh mislukt, vergelijk je de huidige modelstatus met de laatste bekende goede snapshot. Als een measure-expressie is gewijzigd sinds de laatste succesvolle refresh, heb je je kandidaat. Het script is eenvoudig in C# of PowerShell via de Microsoft.AnalysisServices.Tabular-namespace en loopt voor de meeste modellen in minder dan een seconde.

In Databricks schakel je audit logging in naar je eigen storage account en query je system.access.audit voor notebook execution-events. Bouw een geplande job die de SQL-tekst van elke query vergelijkt met de gecommitte notebook-bron in je Git-repo. Elke query die niet overeenkomt met een gecommitte cel is dynamisch gegenereerd of is aangepast in de interactieve sessie. Beide gevallen verdienen review als ze voorafgaan aan een job failure.

In ADF schakel je diagnostic logging in naar Log Analytics en schrijf je KQL-queries die pipeline failures filteren waarbij de mislukte activiteit recentelijk is gewijzigd. De ActivityUpdated-timestamp in de pipeline-metadata geeft je, gecombineerd met de failure-timestamp, een venster om te onderzoeken.

Geen van deze aanpakken is perfect. Het zijn workarounds voor een observability gap die de platforms nog niet hebben gedicht. Maar ze zetten een klasse van onzichtbare failures, door agents gegenereerde code die iets downstream breekt, om in iets dat je in elk geval kunt detecteren en onderzoeken voordat de volgende stakeholder-mail in je inbox belandt.