From data to decisions: how LSEG is scaling trusted AI

Enterprise AI projects fail at the production stage, not the prototype stage. The proof-of-concept works in the demo room. Leadership greenlights the budget. Then six months later, the initiative stalls—not because the model broke, but because nobody decided who owns the data, who approves the output, or who fixes it when it drifts. The technology was never the hard part.

This article is for operations leaders and IT executives evaluating whether to scale AI from a successful pilot into production. If you have already proven the model works and are now facing questions about governance, integration, and organizational readiness, what follows will help you avoid the expensive mistakes that surface in month four.

Why Pilots Succeed and Scale Fails

A pilot exists in controlled conditions. It runs on clean data, with engaged stakeholders, against a narrow use case. The team building it can make judgment calls in real time. None of those conditions survive the transition to production.

Production introduces three forces that pilots avoid:

• Data quality at scale—edge cases, stale records, conflicting sources that the pilot dataset excluded
• Organizational friction—competing priorities, unclear ownership, teams that were not consulted during the pilot now raising objections
• Accountability gaps—when the model produces a questionable output, who decides whether to trust it, override it, or escalate it

A recent piece from OpenAI on LSEG’s AI scaling work reflects this pattern. The financial services firm moved from experimentation to 4,000 employees using AI-assisted workflows. The success factor was not the model architecture—it was the governance layer they built around it: approval workflows, human review checkpoints, and clear escalation paths. Without those, even a technically superior model fails organizational adoption.

The Four Decisions That Determine Scaling Success

Before you invest in scaling infrastructure, you need clarity on four questions. Most organizations skip at least two of them, then pay to answer them under pressure six months later.

Who owns the output

AI generates recommendations, summaries, or decisions. Someone in the organization must be accountable for what happens when those outputs are wrong. This is not a technical role—it is an operational one. If your answer is “the AI team,” you have not answered the question. The AI team builds the system. A business owner must decide when to trust it, when to override it, and when to shut it down.

What review process exists

Production AI needs a human-in-the-loop checkpoint for high-stakes outputs. The question is where to place it. Too early, and you eliminate the efficiency gains. Too late, and errors propagate before anyone catches them. Successful deployments typically define three output categories: auto-approve (low stakes, high confidence), human-review (medium stakes or low confidence), and escalate (high stakes or anomalous). Each category needs explicit criteria, not judgment calls.

How you detect drift

Models degrade. Data distributions shift. Business rules change. A model that performs well in Q1 may produce unreliable outputs by Q3—not because anything broke, but because the world it was trained on no longer matches the world it operates in. You need monitoring that catches this before users lose trust. The typical warning signs: increased override rates, longer review times, rising exception volumes.

When you retrain or retire

Every model has a shelf life. You need predefined triggers for retraining (performance drops below threshold X, data shift exceeds threshold Y) and criteria for retirement (use case no longer exists, cost exceeds value, regulatory requirements change). Without these, you end up maintaining zombie models that no one trusts but no one has authority to kill.

What the Budget Actually Looks Like

The pilot budget is a fraction of the production budget. Most organizations underestimate by 3–5x. Here is where the money goes:

The integration line is where budgets break. Connecting a model to production systems—ERP, CRM, workflow tools—requires error handling, retry logic, and fallback procedures that do not exist in a pilot. Plan for 40–60% of your scaling budget to go toward integration and governance infrastructure, not the model itself.

The Adoption Risk No One Models

Technology adoption follows a pattern: early enthusiasm, friction with reality, selective abandonment, grudging acceptance of a narrower use case. AI adoption compresses this cycle because the outputs are probabilistic. Users do not understand why the model gave a particular answer, so they either over-trust it (dangerous) or under-trust it (wasteful).

The organizations that scale successfully do three things differently:

• They launch with explicit guidance on when to trust the output and when to verify it—not vague statements about “using judgment”
• They track override rates by user and use case, treating high override rates as a signal to investigate, not a failure to punish
• They create feedback loops where users can flag bad outputs without friction, and they visibly act on that feedback within weeks, not quarters

The counterargument is that this slows deployment. It does. A phased rollout with feedback loops takes two to three months longer than a big-bang launch. But the big-bang launch typically results in a shadow workaround within six months—users nominally have the AI tool, but they do not use it for anything that matters. You end up paying for the infrastructure without capturing the value.

What Integration Actually Requires

Connecting AI to your existing systems is not a one-time project. It is an ongoing operational commitment. The pilot connected to a data extract. Production connects to live systems with real users, real latency requirements, and real consequences for failure.

Three integration patterns cause the most pain:

Real-time decisioning

If the AI needs to respond in under a second—pricing recommendations, fraud detection, routing decisions—you need infrastructure that the pilot did not require. Caching, load balancing, failover logic. The model inference is the easy part. The reliability engineering is the hard part.

Workflow embedding

If the AI output appears inside an existing tool—CRM, service desk, ERP—you are now dependent on that tool’s extensibility. Some platforms make this easy. Others require custom development that the vendor will not support. Assess this before you commit to the architecture.

Data synchronization

The model needs current data. How current? If the answer is “as of last night’s batch,” you can use existing ETL. If the answer is “as of the last transaction,” you need event-driven architecture that may not exist today. The infrastructure cost to move from batch to real-time can exceed the cost of the AI system itself.

The Honest Tradeoff

Scaling AI faster means accepting higher risk of failure and rework. Scaling AI more carefully means capturing value later while competitors move. There is no framework that eliminates this tradeoff—only clarity about which risk your organization can absorb.

If your business model depends on speed, accept that you will rebuild portions of the system in year two as you learn what you got wrong. Budget for it. If your industry is highly regulated or your margin for error is low, accept that you will move slower and may lose first-mover advantage. Plan for it.

The mistake is pretending the tradeoff does not exist—launching fast and assuming governance can be added later, or planning carefully and assuming the business will wait indefinitely.

The disciplined organization treats AI scaling as a capability-building exercise, not a technology deployment. They staff for ongoing operation, not project completion. They budget for governance infrastructure at 40–60% of the total investment. They define decision rights before they define model parameters. And they accept that the production system will look different from the pilot—more constrained, more monitored, more governed—because that is what production requires.

The model will work. What fails is everything around it. Build for that.