In the last three articles, I explored why successful AI pilots often fail to produce enterprise ROI, why an intelligence layer matters, and why access to data does not mean an AI system understands the business.

The next question is practical: Where do you begin?

In capital markets, let's take a trade break as an example.

A trade executes. The execution record says one thing, the booking system shows another, and the position or risk view does not yet line up. An analyst has to determine whether this is a timing difference, an amendment, an incorrect booking, or something that needs immediate escalation.

The data may be available in every system. Resolving the break still takes business knowledge.

An experienced analyst knows which record is authoritative at each stage of the trade's lifecycle. They know when a mismatch is expected to clear, which exceptions are routine, and which ones could affect a client, a position, or a risk limit. They also know whom to call when the records alone cannot explain what happened.

Some of that knowledge is documented. Some lives in the way the desk, risk and operations teams work together. Much of it becomes visible only when something goes wrong.

That makes the trade break a useful test of what we mean by enterprise context.

An AI tool connected to all the relevant systems might quickly assemble the execution, booking and position records. That would save time. But a useful answer requires more:

  • Which records describe the same trade after an amendment or allocation?
  • Which system is authoritative for the question being asked?
  • Is the difference expected at this point in the workflow?
  • What rule determines its priority?
  • Who owns the next action, and when should someone else be involved?

Without those answers, the tool may produce a convincing summary while missing the reason the break matters.

Map the decision before choosing the solution

I would begin by sitting with the people who resolve these breaks and following a small sample from detection to closure.

What first alerted them? Which screens did they open? Where did they stop trusting a field and seek confirmation elsewhere? What judgment did they apply? What action did they take, and who approved or reviewed it?

The goal is to identify one decision worth improving. For example: Does this break need immediate escalation, or can it follow the normal resolution path?

Then make the context behind that decision explicit. Document the evidence, the rules, the common exceptions, the owner and the points where human judgment is required. Test whether those rules hold across different products, desks and market conditions. Where they do not, record the difference rather than forcing a single answer.

This work has value even before AI enters the picture. It can reveal inconsistent definitions, unclear ownership, recurring breaks and manual steps that no one had measured.

Give AI a bounded job

Once that context is understood, AI could gather the relevant records, explain the mismatch in plain language, suggest a likely cause and show the evidence behind that suggestion. It could route the case to the right team and make similar past resolutions easier to find.

The analyst remains responsible for judging the case and taking the appropriate action. The system should also be able to say when the evidence is incomplete or its suggested explanation does not fit the facts.

Success is measurable. Does the team spend less time gathering information? Are urgent cases identified sooner? Do fewer breaks bounce between teams? Are recurring causes easier to spot and fix?

Those measures tell us far more than a demonstration in which an AI assistant answers a trade question correctly.

Build, buy or assemble—after understanding the gap

There is no reason to assume one new platform must solve this entire problem. Existing trade, workflow, data and monitoring tools may already provide much of what is needed. A vendor may offer a strong capability for a specific part of the process. Some context may require targeted work inside the firm.

The right combination becomes clearer once the decision, its missing context and the desired outcome are understood.

A trade break is only one example. The same method can apply to a risk exception, a failed settlement, a client onboarding decision or a recurring control issue.

Start with one consequential decision. Follow how people actually make it. Identify the context that systems do not share. Then improve that workflow and measure what changes.

That is how an intelligence layer begins to become real: one decision at a time.