I've spent a lot of words this year making the abstract case that Fabric's ease of creation demands governance to match. Today I want to make it the other way — through three stories. All three are real in shape, anonymised in detail, and all three are near-disasters rather than actual ones, because each got caught in time. That "in time" is the whole point. The gap between a governance horror story and a governance disaster is usually just whether someone was watching. Here's what to watch for.
Horror story one: the data that was shared with everyone
What happened. A team built a lovely, useful semantic model and, wanting to be helpful, shared its workspace generously so colleagues could self-serve. The model contained detailed, sensitive personal data. "Shared generously" turned out to mean a couple of hundred people could query information that, on any honest reading, a couple of hundred people should not have been able to query. Nobody did anything malicious. Someone was just being helpful with a sharing button that made being over-helpful frictionless.
How it was caught. Not by anyone noticing — by a routine posture review surfacing the sensitive dataset as dramatically over-exposed. Which is the first lesson: this class of problem is invisible to the people who created it, because from where they sit everything's working fine. You only find it if something is actively looking for the gap between who can access and who should.
The fix. Immediate access reduction to the people with a genuine need. Then the durable fix: sensitivity labels applied at the source so the data's classification travels with it, and row-level security so that where broad access is legitimate, people see only their slice. And a cultural one — a short, clear guideline that "sharing a workspace with sensitive data is a decision, not a convenience." The button stayed easy; the awareness of what it meant got harder to skip.
Horror story two: the two versions of the truth in a board meeting
What happened. Two teams had each, independently, built a semantic model for "company performance." Slightly different logic, slightly different numbers, neither wrong exactly — just different, because nobody had governed which was canonical. The horror moment: both numbers arrived in the same board meeting, in different decks, and disagreed. In front of the people whose trust in the data function is the whole basis of that function's existence.
How it was caught. Painfully, publicly, in the worst possible room. Which is itself the lesson — this one doesn't get caught by a tool, it gets caught by a credibility incident, unless you were governing definitions before it happened.
The fix. In the moment, honest triage: work out which model reflected the agreed definitions and why. Then the structural fix — certify the canonical model so it wears the visible trust mark and surfaces first, and retire the duplicate rather than leaving it to ambush someone again. And underneath, the actual work: getting the two teams to agree, out loud, a single definition of the contested measures, so the duplication couldn't silently regrow. The tooling made the agreement durable; the humans still had to reach it.
Horror story three: the pipeline that ate production
What happened. A new pipeline was built to reprocess a large historical dataset — reasonable in isolation. It was scheduled to reprocess everything, nightly, an old habit from a world where compute was free. On a shared Fabric capacity, it quietly consumed an enormous share of the pool every night, and one morning the capacity was throttling badly enough that production reports — the ones people actually depended on — slowed to a crawl. One team's un-thought-through job degraded everyone's service.
How it was caught. Users complaining that reports were slow, which led to the Capacity Metrics app, which named the culprit immediately. Lesson: on a shared capacity, one team's ungoverned workload is everyone's problem, and you will find out via angry colleagues unless you're watching the metrics proactively.
The fix. Immediately, the runaway job was rescheduled and throttled back. Properly, it was rebuilt to process incrementally — only the new data, not all of history every night — which fixed the cost and the contention at once. And structurally: some guardrails about what can be deployed to the shared production capacity without review, because "anyone can create anything instantly" is a feature that needs a fence around the shared resource everyone depends on.
Every one of these was caught by something actively looking — a posture review, a metrics app, a certification standard. Ungoverned Fabric doesn't fail loudly on day one. It accumulates quiet risk until something forces it into the light. Governance is just deciding to look before the light is a board meeting.
The pattern under all three
Read the three together and the same shape appears every time. In each, nobody was negligent — a helpful share, an independently-built model, a reasonable-looking pipeline. The platform made each easy, and the ease is what let a small unconsidered action become a large unmanaged risk. That's the real pitfall of Fabric without governance: not that people do reckless things, but that the friction which used to give you a moment to think has been engineered away, so unconsidered actions scale instantly.
The fixes weren't heroic, and that's the encouraging part. Label the sensitive data. Certify the real model and retire the impostor. Make workloads incremental and fence the shared resource. Above all, have something looking — a posture review, a metrics habit, a certification standard — so quiet risk gets surfaced before it becomes a story you tell at conferences. None of it requires a governance department. It requires the decision to look, on purpose, before circumstance looks for you. Do that, and these stay horror stories you read instead of ones you live.