A Good Argument About AI Governance, and One Line We Draw Differently

I learned a lot from the conversation Krishna Gade of Fiddler AI had with Maryam Ashoori, who runs product and engineering for IBM watsonx.governance. The recording is here, and it repays the hour. Ashoori has shipped a governance platform into large enterprises and has the scar tissue to prove it, and most of what she said we would sign without edits. We want to write about the small part where we would draw the line somewhere else, and it seems only fair to start with the larger part where she is right.

Her opening move was to refuse the technology question. Follow the problem, not the trend. Enterprises have run governance, risk, and compliance programs for two decades, and while the nature of the risk keeps shifting, the machinery underneath has held. That framing carries more weight than its plainness suggests. A risk officer who hears that AI governance is a new discipline will reach for the brake. A risk officer who hears that it is the same discipline pointed at a faster-moving asset will reach for the manual.

She then laid out three layers of trust. Visibility comes first, because an organization cannot assess exposure to a workload it cannot see, and shadow AI keeps most of the estate out of view. Control comes second, where a risk is met by a control, and a control is measured by a metric. Accountability comes third. Her line was that control without accountability is only good intention, and we have not heard the gap put better.

We would sign four more things she said.

Governance has to arrive at the moment a builder starts describing an idea, before any code exists. Ashoori described a check that runs when a developer first prompts an assistant, looks for approved use cases that resemble the new one, and hands back the guardrails those precedents already carry. Most governance programs wait for a submission form. By then the thing is built, and the guardrail becomes rework.

Tracing alone will not hold. A trace shows what already happened, and if the failure was a disclosure, the disclosure has occurred by the time it appears on a dashboard. Runtime monitoring earns its place when it changes an outcome before the action lands.

Governance is a structure of relationships rather than an inventory. IBM calls their version a governance graph. An AI asset points to its use case, and the use case to the risk it opens. The risk points to the control that mitigates it, and the control to a metric tied to a business objective. An inventory tells you what you own. A graph tells you what breaks when one node fails.

And the party defining a standard should not be the party building against it. Ashoori reached for SOC 2 to make the point. We reach for the same argument in different words, since an organization can buy nearly all of the mechanics and still has to establish the authority above them independently.

Where they are ahead of us, and we will say so plainly, is the last link in that graph. Tracing a breached control back to the specific business objective it dents, with the financial number attached, is the capability every sponsor asks for and few programs deliver. Our own implementation guidance treats full outcome attribution as a later-stage concern and asks only for partial linkage in the first governed workflow. IBM has productized what we defer. We think our sequencing is defensible, and we also think the deferral has been too comfortable, and we are moving that obligation earlier.

The line we draw differently

Ashoori declines to define a control plane. In her account it is a tool, and the label is interchangeable with control tower or governance console. What she holds fixed is a four-part cycle: define the controls, implement them, enforce them, and track whether enforcement worked.

We hold the opposite thing fixed.

The cycle is a process model, and a process model cannot tell you when an implementation has quietly folded several jobs into one component. Deciding what is allowed, enforcing that decision at runtime, and recording what actually happened are three separate jobs with three different failure modes. Our rule is that no single component may hold more than one of them. The rule is boring until the day an auditor asks whether the system that graded the controls is the same system that wrote them, and by then the answer is already in the architecture.

Which is Ashoori's own argument, turned one notch further. She uses SOC 2 to insist that the assessing party stand apart from the building party. We think the same separation has to survive inside the runtime, not only at the org chart. A governance console that defines the controls, implements them, enforces them, and then reports on its own enforcement is the same concentration her analogy warns against, relocated inside one product boundary.

The second difference follows from the first. She distributes enforcement by risk category, so security risk lands in the security tool, disclosure risk lands in the observability layer, and a governance council assembles a single view across the coverage. The design is easier to sell and harder to prove. Coverage that is assembled from many tools cannot demonstrate that the decision made was the decision enforced, and it fails closed one tool at a time rather than as a system.

Nothing in the cycle tells a company where it currently stands, or what to build next. The wheel is either turning or it is not. We use readiness levels for that job, scored by the weakest gate rather than the average. A company with strong policy documentation and no durable record is not two thirds of the way to governed. It is stuck at the first level with an impressive binder.

None of which makes the conversation less useful. Ashoori named accountability as the top concern her customers raise, said out loud that nobody in the market has settled who answers when an agent misbehaves, and declined to pretend a product solves it. That kind of candor from a vendor is rare enough to be worth an hour of anyone's attention.

Baser Potential helps companies build governed AI operating models. If you want to argue with any of the above, we would enjoy the argument.