Scaling Enterprise AI Requires More Than Better Models

Kosta Haritakis, Global Head of AI at Mizuho, on why business ownership, platform capability and governance need to operate as one system

Enterprise AI is reaching the point where model capability is no longer the only constraint that matters.

As financial institutions move AI into workflows that touch customer data, operational decisions, risk processes and regulated activity, the harder question is what has to be true around the technology before the institution can give AI greater responsibility.

In the discussions following LatentBridge’s New York executive roundtable, Kosta Haritakis, Global Head of AI at Mizuho, framed the issue clearly:

Enterprise AI only scales when business ownership, platform capability and governance operate as a single system.

That is the execution challenge.

A financial institution can have sophisticated AI infrastructure, mature control functions and business teams with credible opportunities, yet still struggle to turn those capabilities into dependable outcomes if they are designed and governed separately.

In practical terms, enterprise AI execution means connecting AI capability to a business-owned workflow with defined authority, embedded controls, observable evidence and clear accountability.

The difficult work begins when all of those elements have to function together.

‍

Is the workflow ready for the authority being given to AI?

For a material AI-enabled workflow, the business, technology platform and control environment have to converge around the work itself.

The business needs to own the outcome and the residual risk. The platform needs to provide the models, enterprise context, tools, permissions and integrations required to perform the work. Governance needs to define what the system may do, what evidence it must retain, how exceptions are handled and when the workflow must stop, escalate or return to a person.

That becomes more important as the role of AI changes.

A system may begin by gathering information or preparing an output. It may later recommend a decision. Over time, the institution may allow it to complete defined, lower-risk activities within set limits.

Each change in authority changes the operating requirement.

A different model, a new tool, an expanded permission or a changed data source can alter the risk profile of a workflow even when the underlying business objective remains unchanged. Governance therefore cannot be treated as a one-time approval before deployment.

For leadership, the question is no longer simply:

Is the model capable enough?

It is:

Is the workflow ready for the level of authority we are about to give it?

That distinction forces more precise decisions about ownership, permissions, controls, evidence and fallback.

‍

Authority has to be designed, not assumed

One of the first decisions is to define exactly what AI is authorized to do.

“Human in the loop” is too broad to function as an operating model. An institution needs to distinguish between a system that can read information, prepare an output, recommend a decision, change a record, approve an action or execute one.

Those are materially different levels of responsibility. They should carry different permissions and assurance requirements.

The boundary also needs to be enforceable.

If an AI system may prepare a credit memo but may not alter a customer record, that distinction should exist in permissions and workflow policy, not simply in an operating guideline. If an agent may act only when specific evidence is present, the workflow should validate that condition before the action becomes available.

The same discipline applies to exceptions.

When evidence is missing, data conflicts, a policy threshold is breached or a case falls outside the approved scope, the workflow needs to know what happens next. It may request more information, narrow the available action, route the case to a specialist or stop entirely.

These are not edge cases around the workflow. They are part of the workflow.

‍

Evidence is what allows authority to move

As AI assumes more responsibility, institutions need enough visibility to understand how the workflow is behaving in practice.

Technical monitoring remains necessary, but it is not sufficient.

For consequential processes, leaders should be able to reconstruct which model or agent performed the work, what enterprise context it used, which tools it called, what permissions it exercised, what validations ran, where exceptions appeared, whether a person intervened and what downstream action followed.

The depth of that visibility should rise with the consequence and authority of the workflow.

The objective is not to produce more telemetry. It is to create a common evidence base that business, technology and control teams can use to determine whether the workflow remains inside its approved boundary.

That evidence should also inform whether AI responsibility can increase.

If performance is consistent, exception levels remain acceptable and controls behave as intended, the institution may have a basis for allowing the system to do more. If a model changes materially, a new tool is introduced, data quality deteriorates or exception patterns shift, the same operating model should be able to tighten authority.

AI authority should therefore be task-specific, evidence-based and reversible.

That is a more durable operating principle than allowing autonomy to move simply because the underlying model has become more capable.

‍

Assurance needs to travel with the work

For consequential AI-supported activity, the final output alone is rarely enough.

The institution should be able to reconstruct how an outcome was produced: the source evidence, model or agent state, permissions in force, validations performed, exceptions raised, human challenge or override and the final action.

That record serves a wider purpose than audit.

It helps teams determine whether the workflow is behaving as designed. It can show where the same control repeatedly catches a failure mode. It can also reveal that the underlying problem is not the model at all, but the data, authority boundary or workflow design.

When the same issue keeps surfacing, another approval layer may not solve it. The process itself may need to change.

The independence of assurance matters too. Where an AI component materially influences an outcome, the mechanism validating that result should be sufficiently independent from the mechanism producing it.

Pre-deployment evaluation, runtime validation, evidence lineage, ongoing sampling and independent checks can create an operating record that serves several functions. Operations can use it to understand workflow performance. Risk, Compliance, Model Risk and Internal Audit can reconstruct how decisions were reached. Business owners can use the same evidence to determine whether AI responsibility should increase, remain unchanged or be reduced.

Assurance, in that sense, is not only about proving that controls worked. It creates the evidence required to decide what should happen next.

‍

Human oversight becomes more important as performance improves

One of the less obvious risks appears when an AI system becomes consistently reliable.

A reviewer who sees correct output after correct output may gradually become less likely to challenge the system. Human approval can remain formally present while becoming weaker as a practical control.

Effective human oversight does not mean reviewing every AI action.

It means concentrating qualified human judgment around material exceptions, unusual cases, higher-consequence decisions and situations where the system reaches the edge of its approved authority.

Those reviewers need access to the evidence that matters, sufficient expertise to understand what they are seeing, enough time to interrogate it and genuine authority to override or escalate.

Otherwise, “human in the loop” becomes an operating label rather than meaningful oversight.

Resilience needs the same level of design discipline.

Providers can become unavailable. Models can regress. Integrations can fail. Enterprise data can change. Material workflows therefore need fallback paths, safe-stop conditions, recovery ownership and clear escalation.

An institution should be able to reduce AI authority quickly without losing the evidence required to understand what happened and recover safely.

‍

The LatentBridge view: governance has to become executable

Kosta’s perspective establishes the institutional requirement.

At LatentBridge, we see the workflow as the place where that requirement becomes operational.

Business ownership has to translate into a defined outcome, measurable economics and named accountability. Platform capability has to become usable enterprise context, controlled access, orchestration and integration. Governance has to become permissions, validation, evidence, exception handling, escalation and human accountability inside the workflow itself.

This is why custom workflow design matters.

The operating architecture for an AI system preparing research should not look the same as one changing customer information, influencing a credit decision or completing an operational action. Each carries a different consequence, authority boundary, evidence requirement and exception path.

Applying one governance pattern across every AI-enabled process misses those differences.

Instead, a policy needs to become an enforceable permission. A risk boundary needs to become a validation, decision rule or escalation path. An assurance requirement needs to become evidence that travels with the work. A business objective needs to remain connected to the workflow expected to produce it.

That is where LatentBridge focuses: designing and engineering enterprise workflows where AI, business logic, platform capability, governance and controls are built together from the outset.

For leadership teams deciding whether an AI-enabled workflow is ready for greater responsibility, the practical test is straightforward.

They should be able to explain:

Who owns the business outcome?

What exactly is the system authorized to do?

What evidence demonstrates that it is operating inside that boundary?

What happens when it encounters an exception?

What conditions will cause the institution to reduce its authority?

These are not abstract governance questions. They are operating and design decisions that determine whether an institution can rely on AI in consequential work.

‍

The frontier raises the stakes

This discipline becomes more important as model capability improves.

Our whitepaper, Closing the Enterprise AI Execution Gap, takes the discussion further from the frontier side: what financial institutions need to change as AI becomes capable of longer, more consequential work and greater levels of AI authority become technically possible.

The paper includes a practitioner perspective from Julian Mason of Anthropic, who argues that greater capability should not automatically lead to greater authority. Evidence from the workflow should determine when responsibility expands.

Julian also points toward the next enterprise challenge: connecting individual AI skills into complete business functions.

That raises a more difficult question for financial institutions.

If an AI system becomes capable of performing more of an end-to-end process, are the workflow, controls, evidence and accountability around it mature enough to support that change?

Kosta’s lens is about what the institution around AI needs to become. Julian’s looks at what advancing capability is making possible.

For financial-services leaders, those questions are converging.

As models improve, institutions will have more choices about what AI can do. The harder decisions will concern what AI should be allowed to do, under what conditions, with what evidence and with whom ultimately accountable.

That is the enterprise AI execution gap.

And it is why scaling enterprise AI requires much more than better models.

‍

Go deeper into the execution challenge

Closing the Enterprise AI Execution Gap - Whitepaper examines how financial institutions can redesign workflows, controls and operating models as frontier capability advances, including a practitioner perspective from Julian Mason of Anthropic.