Data & AI governance

At TechFabric it starts with an inventory of what's true today. Which grants exist, where lineage breaks, which tables nobody has queried in a year, and what an examiner would find.

Then the design work, which is catalogue and schema structure, a grant model expressed through groups, row filters and column masks where a table-level grant isn't fine enough, and the audit evidence pulled from system tables so the answer to a question is a query. The two-week Databricks Health Check at /databricks/health-check is the named way to start.

It's the substrate, not the answer. Turning it on gives you somewhere to express grants; it doesn't decide who should have them, whether lineage still resolves after a rebuild, or what an agent is allowed to touch. Most of the engagements we take start from a working Unity Catalog and an estate nobody can defend in a meeting.

The written answer to four questions. Which data each model and agent may read, under whose identity it acts, what it's allowed to do without a person approving, and what gets recorded so you can reconstruct a decision afterwards. On Databricks the enforcement half already exists.

Agents run under a service principal that inherits Unity Catalog permissions, AI Gateway logs the calls, and the audit table records the access. The framework is the policy that decides what those settings should be, and we write it with your security lead rather than for them.

The same way you govern a person, which is the point most teams miss. The agent runs under its own service principal and inherits Unity Catalog permissions rather than being handed a broad token.

What it may do is a policy decision made before it's built, not a setting adjusted after something goes wrong. Fabric Tower at /accelerators/fabric-tower is what we use when a squad of agents needs watching rather than one.

Yes, where the governance question turns out to be a definition question, which it usually does. Two teams both call a column revenue and both are right, and no grant fixes that.

We write the definitions down with whoever owns each number, put the quality checks into the pipeline so a bad load stops instead of landing, and handle the master data reconciliation that sits underneath. The pipeline half of that work is at /services/data-engineering.

Retrofitting it does. Designing it alongside the pipeline doesn't, and it's considerably cheaper than the alternative, which is discovering during a security review that the grants don't hold. We put the permissions boundary in the first architecture conversation for exactly that reason.

The first thing we establish is what's actually true: which grants exist, where lineage breaks, and what an examiner would find today. That inventory is quick, and it tells you what's reachable before the date rather than after it.

Most of the evidence an auditor asks for is already in system. access. audit and the lineage tables; the work is knowing which query answers which question.

Yes. We're a Microsoft Solutions Partner with a Data & AI designation, and a lot of the estates we govern have Power BI, Dynamics 365 or Azure SQL in them.

Row-level security in Power BI, the connection that lets a report inherit Unity Catalog permissions, and the Azure side of the identity model are all in scope, because a governance model that stops at the workspace boundary isn't one.

With the two-week Databricks Health Check, which is fixed fee and reads the estate as it stands, including the grants and the lineage. You get a scorecard and a written recommendation whether or not you continue. Longer work is scoped against that document rather than against a brief, so the second number is known before anyone commits to it.