You Bought the #1 AI Governance Tool. It Still Can't Prove One Decision Was Authorized.

The certificate you paid for attests to the model. The event under scrutiny is the action. A regulator does not sanction a model card. A customer does not appeal a drift chart. A court does not adjudicate a feature store. The loan is denied. The claim is rejected. The account is frozen. The credit line is cut the week before a mortgage closes. That action — automated, consequential, taken on a prediction — is the highest-liability surface in your enterprise, and lifecycle model governance stops one step short of it.

This is not a knock on the discipline. It is a boundary in the architecture. The platforms that win the governance category govern the model and the call to it. The exposure your office is accountable for lives in the decision — and the decision executes somewhere the model platform does not run.

Give the category its due, because over-claiming here is how you lose the expert in the room. The model-risk and AutoML vendors, and the universal AI platforms that say they "close the governance loop," earned those rankings on real capability. Feature stores, model registries, and end-to-end lineage genuinely make a model reproducible and auditable as an artifact. One-click serving really does compress deployment from months to hours. Drift and quality monitoring, and the newer agent-evaluation layers — judges that score accuracy, factuality, and cost — are real and valuable. And the most advanced AI gateways genuinely govern the model call itself: rate limits, guardrails, credential management, inference logging, applied even to agents running off-platform. That is sophisticated, and it is not vaporware.

Here is the wedge. Everything in that paragraph governs the model and the call to it. The prediction is served, evaluated, and logged. But a served prediction is not a committed decision — and the platform's governance ends where the artifact ends.

There is a line inside every ML architecture that audit programs rarely draw explicitly. Call it the prediction boundary. On one side, the model is trained, registered, deployed, served, and monitored — and, in the best designs, the inference request and any tool invocation are proxied through a gateway that rate-limits, guardrails, and captures the call. All of that is on the governed side. All of it is real.

But that gateway, however advanced, is a governed proxy in front of model-serving. It governs the call and captures it. The business action the prediction drives — post the transaction, release the payment, freeze the account, deny the application — commits in a system of record the gateway sits beside, not inside. Between the served prediction and the committed action sits a seam: application code, a message queue, an RPA bot, a human clicking through a console. The model platform observes that seam at best; it does not govern it. And that seam is exactly where liability concentrates and where the decision-level audit trail goes quiet.

Reframe the word governance. In the model-platform vocabulary it means build-time and access-time control: who trained it, on what data, with what performance, served through which gate. In the vocabulary of the frameworks you answer to, governance means decision-time control. Read them closely and the pattern is unmistakable — every obligation attaches to the action, not the artifact.

• ECOA / FCRA adverse action. When credit is denied, the duty attaches to the adverse-action event itself: specific principal reasons, delivered, on the record, to a named consumer. The statute governs the act of denial, not the discrimination performance of the scorecard behind it.
• EU AI Act, high-risk systems. The obligations bind the deployed system in use — human oversight of the decision, event-level logging, and traceability of the outcome for the person affected. A validated model with an ungoverned decision path does not satisfy oversight of the decision.
• SR 11-7 implementation controls. Model validation is necessary but explicitly insufficient; supervisory expectation runs to the controls around how the output is used in a business decision. "The model is sound" is not the same finding as "the decision was controlled."

In each case the unit the law contemplates is the action. Artifact governance answers "is the model sound?" It does not, by construction, answer "was this specific decision permitted, within policy, segregated by duty, and reversible?" Those are properties of the action — and the action lives on the far side of the prediction boundary, in the seam the platform does not run.

This is an architectural difference, not a feature you can bolt on. On a Composable Process Fabric, the model does not sit at the end of a pipeline as an endpoint the rest of the enterprise calls out to. It runs as a governed Function inside a Deterministic Workflow. The prediction is consumed, on the same runtime, by the very workflow step that acts on it — under inline controls: an approval gate, a threshold, a segregation-of-duties check, a human-in-the-loop hold that is first-class rather than bolted on. The action that commits — deny, release, freeze — passes through a governed Connector, the only primitive that touches an external system of record, and the whole event is written to an immutable per-action audit over a shared Semantic Ontology.

That is why the difference is structural rather than incremental. The gateway pattern governs the call and captures it beautifully; the action still commits in a system the gateway sits beside. Here, model-to-action closes on one runtime. "Was this decision permitted, controlled, and reversible?" has a per-action answer — because the permission check and the action are the same governed step, not two systems you reconcile with a data pull after a complaint lands.

Be honest about what that does and does not require. This is not zero-integration, and no serious buyer should believe a vendor who implies it is. The fabric runs over your existing estate through governed Connectors; your systems of record stay where they are. What changes is not the map of your infrastructure — it is where the decision executes: inside a governed process, rather than in the ungoverned space between a served prediction and the app that acts on it.

Consider an adverse-action decision, purely as an illustration of the architecture — not a delivered result. On the endpoint pattern, the scorecard is validated and the score is logged; whether the denial that followed carried the required reason codes, respected a policy override, and remained reversible on appeal is something you reconstruct across systems, after the fact, under time pressure. As a governed Function inside a workflow, the denial is the audited event: the reasons, the duty gate, the human hold, and the commit are one record on one runtime. That is an architectural property of putting the model inside the process — it is what the design makes true, stated as such.