The AI conversation has become crowded with impressive titles, technical language, and ambitious promises. What is still missing is the practical bridge between business, technology, sales, and delivery.

I am not a Global AI Leader.

I am not a Global Agentic AI Leader either.

I spent nearly 25 years at IBM, working in one capacity or another with close to 250 clients around the world. I also spent three years at CGI, one of Canada’s leading global consulting firms.

Period.

I do not bring deep technical prowess to the table. I do not have an MBA. And I am not interested in collecting an impressive title simply because AI is the latest thing everyone wants attached to their name.

What I bring is balance:

  • Business acumen
  • Technical astuteness
  • Domain and delivery experience
  • Communication and presentation skills
  • Relationship management and political acuity

That balance is missing from far too many AI conversations.

The Problem: Two Conversations That Rarely Meet

On one side, we have salespeople selling AI without sufficiently understanding the technology, the operating environment, or what it will take to deliver what they promised.

On the other, technical experts discuss models, infrastructure, agents, inference, APIs, data pipelines, and architecture without always connecting those capabilities to a business problem, delivery model, or measurable outcome.

Both perspectives matter. Neither is enough on its own.

A technically elegant solution that does not improve a business outcome is an expensive demonstration. A compelling sales promise that cannot survive implementation is future escalation material wearing a nice PowerPoint jacket.

Someone must stand in the middle and ask:

  • What business problem are we solving?
  • How will this generate revenue, reduce costs, manage risk, or improve customer experience?
  • Can we actually deliver what has been promised?
  • Who will own, operate, govern, and support it?
  • How will we know whether it worked?

The Business Impact of the Missing Middle

When those questions are not answered, the gap travels directly into the delivery organization.

Sales may price an outcome without understanding the integration effort. Architecture may optimize for technical performance without accounting for operational support. Transformation teams may celebrate the launch while service teams inherit monitoring gaps, unclear ownership, unreliable knowledge, and exceptions nobody designed for.

The business then experiences the consequences:

  • Implementation costs exceed the business case.
  • Delivery dates move while executive confidence falls.
  • Employees work around the AI rather than with it.
  • Customers encounter inconsistent or incorrect outcomes.
  • Operational teams absorb risk they were never funded to manage.
  • The initiative is labelled an AI failure when the real failure was alignment.

This is why AI is broader than a technology play. It is a business, operating-model, delivery, governance, and change-management decision.

An Enterprise IT-Delivery Example

Imagine a global financial institution introducing an AI agent to reduce delays in employee access requests.

The sales story is attractive. Employees will request access conversationally. The agent will interpret the need, identify the correct application roles, obtain approvals, provision access, update the ticket, and notify the employee. Faster access. Fewer manual touches. Lower support cost.

The technical team proves that the model can understand requests and call the required APIs. The demonstration works beautifully.

Then enterprise reality arrives.

The application team explains that hundreds of business applications use different role structures. The identity team identifies privileged-access rules that cannot be automated without additional controls. Middleware finds that several integrations do not return reliable completion statuses. The database team discovers inconsistent entitlement records. The network team requires segmentation changes for new service-to-service traffic. Cybersecurity needs traceable decisions and separation of duties. Service Management asks who owns incidents when the agent provisions the wrong access. Audit asks how the organization will reproduce the reasoning behind a decision six months later.

Meanwhile, the sales proposal assumed a mostly standard environment and priced a short implementation.

No single group is wrong. Each is looking at a different part of the same elephant.

Without someone connecting those perspectives, the project fractures. Milestones slip. Costs rise. The agent works for common requests but fails on exceptions. Employees learn that complicated requests still require calls and emails. Support teams receive incidents with incomplete evidence. Application owners dispute responsibility. Risk teams tighten controls, reducing automation. The promised return starts shrinking before the solution reaches scale.

The AI model did not fail.

The organization failed to connect the business case, sales promise, architecture, delivery plan, controls, and operational model.

What a Balanced Approach Changes

A balanced leader would bring the groups together before the promise hardens into a contract or executive commitment.

The initiative might begin with high-volume, low-risk applications. The team would establish a baseline for access delays, manual effort, failure rates, and employee productivity loss. Technical teams would define integration patterns. Security would set authority boundaries. Service Management would establish ownership, monitoring, escalation, audit evidence, and knowledge requirements.

The expected outcomes would be explicit:

  • Reduce time to productive access for eligible requests.
  • Lower manual administration without displacing work onto employees.
  • Maintain or improve security and audit compliance.
  • Escalate exceptions with complete evidence and clear ownership.
  • Expand only after benefits and stability are demonstrated.

Now the business case, technology, delivery plan, and operating model describe the same solution.

Lessons for Managers

Managers do not need to become data scientists to contribute meaningfully to AI.

They do need to understand the work well enough to identify friction, recognize failure, explain important exceptions, and connect outcomes to employees and customers.

They should challenge vague promises without dismissing innovation. They should translate technical capability into operational consequences. And they should bring the people who will inherit the solution into the conversation before implementation, not after the celebration photograph.

Lessons for Organizations

Organizations should stop treating AI leadership as a contest to find the person who uses the most advanced vocabulary.

Strong AI leadership is interdisciplinary. It needs people who can move comfortably between the boardroom, architecture discussion, sales pursuit, delivery checkpoint, and operational review.

That does not mean one person knows everything. It means someone is accountable for connecting everything.

Key Takeaways

  • AI does not need more impressive titles. It needs people who connect the dots.
  • Sales credibility requires an understanding of technical and delivery reality.
  • Technical excellence becomes valuable only when connected to a meaningful business outcome.
  • Operational teams must help shape the solution before it becomes their responsibility.
  • Business acumen, technical astuteness, domain experience, communication, and political acuity are complementary strengths.
  • Many so-called AI failures are failures of alignment, ownership, and operating-model design.

I may not call myself a Global AI Leader.

But I know how to ask whether the promise makes business sense, whether the technology can support it, whether the organization can deliver it, and whether someone can keep it running after everyone leaves the launch meeting.

That is the conversation I want to contribute to.

For more practical reflections on AI, leadership, and IT delivery, visit www.imadlodhi.com.