Tag: Lopez Research

  • Why Enterprises Need an AI Operating Model | IBM Think 2026

    Why Enterprises Need an AI Operating Model | IBM Think 2026

    Last year produced several sobering research findings on AI’s business value. The McKinsey “State of AI in 2025: Agents, innovation, and transformation” survey found that only 6 percent of organizations are seeing a significant financial impact from AI. Deloitte’s research puts typical payback timelines at two to four years. While the exact numbers vary by study and sector, the pattern is consistent: most enterprises are managing something genuinely difficult. AI is a technology that changes every few months, costs more than projected, and carries real governance and security risks that regulators, boards, and risk teams take seriously. Eighty-eight percent of organizations now use AI in at least one business function. The McKinsey study found that approximately one-third have begun to scale it across the enterprise. No matter what research report you review, including those from Lopez Research, you’ll find the number is less than 50%. The gap between “using AI” and “running the business on AI” is real, and it exists for legitimate reasons — fragmented data, evolving tools, integration complexity, and compliance requirements that don’t pause while the technology moves fast. IBM’s Think 2026 announcements are aimed squarely at that gap. The company is calling its approach an AI Operating Model, comprising four connected systems: agents, data, automation, and hybrid infrastructure. Arvind Krishna, IBM’s Chairman and CEO, framed the urgency directly in the Think 2026 keynote: “The enterprises pulling ahead are not deploying more AI — they’re redesigning how their business operates. Running AI in the enterprise requires a new operating model, and IBM is enabling organizations to manage AI-driven systems with the same rigor, governance, and scale as their most critical infrastructure.” IBM argues that these problems are connected, and solving them one at a time, such as buying a point solution here, running a pilot there, is why many AI programs stall. Yet, companies have told Lopez Research they can’t wait for a complete AI strategy before acting. That tension is real, and IBM is trying to help enterprises navigate it.Here’s what it means for organizations in that position. 

    The Real Reason AI Projects Stay in Pilot Mode

    The standard explanation for slow AI scaling is that organizations aren’t moving fast enough. That framing isn’t fair.Deloitte’s 2025 AI survey of 1,854 executives found that 85 percent of organizations increased AI investment over the past year, and 91 percent plan to increase it again. These are not organizations standing still. They are organizations that have invested heavily and are still waiting for returns that take longer than expected. Deloitte found that most executives expect significant AI payback to take 2 to 4 years — far longer than the 7- to 12-month payback period they expect from traditional technology investments. The reasons are structural, not motivational. Lopez Research discussions found that: 

    • Data hygiene issues persist. Most enterprise data is siloed, static, and inconsistent. AI systems — especially agentic ones that take actions on your behalf — need real-time, reliable data to make decisions you can trust. Lopez Research’s 2025 Enterprise AI Benchmark found that 85 percent of companies were struggling to find AI ROI, with data quality problems the most consistently cited cause. McKinsey’s research reaches the same conclusion: fragmented data and legacy architecture are the most persistent blockers to AI scaling, across industries and company sizes.
    • Governance that hasn’t caught up. Deloitte’s 2026 State of AI report found that only one in five companies has a mature model for governing autonomous AI agents. The Cloud Security Alliance (CSA) puts a finer point on why that matters. In its December 2025 CSA study, only 1 quarter of organizations reported having comprehensive AI security governance in place. Companies with governance policies were twice as confident in their ability to protect AI systems.  Governance isn’t just a compliance exercise. It’s the factor most strongly correlated with successful AI adoption.
    • Security exposure is growing faster than most organizations realize. The Cloud Security Alliance’s April 2026 survey of 418 IT and security professionals found that 82 percent of organizations have unknown AI agents running in their IT infrastructure — agents deployed by employees or teams without central visibility. Sixty-five percent have experienced an AI agent-related security incident in the past twelve months, with consequences including data exposure (61%), operational disruption (43%), and financial losses (35%). This isn’t a theoretical risk. It’s happening now, in organizations that believe they have reasonable visibility into their AI deployments.
    • Integration debt continues to escalate. McKinsey projects that IT infrastructure costs will increase by two to three times by 2030 as AI workloads expand, while budgets remain flat. Organizations are being asked to adopt new tools on top of existing tools that were already expensive to operate and difficult to connect.

    These are structural constraints, not capability gaps. IBM’s AI Operating Model is designed around them. 

    What IBM Announced and What It Solves

    IBM defines the AI Operating Model as the system by which enterprises move from fragmented AI experimentation to AI that runs the business. Where most technology vendors frame AI adoption as a capability question — which models, which tools, which platforms — IBM frames it as an operational question: how do you connect intelligence, action, operations, and trust into a system that functions at enterprise scale? The four pillars are designed to be sequential. Intelligence comes first, because AI amplifies whatever data foundation it sits on — fragmented data produces fragmented decisions, faster. Actions follow, because insight without the ability to act is observation, not transformation. Operations addresses the scale problem: individual AI actions become valuable only when they can run across thousands of systems and decisions simultaneously. Trust closes the loop, allowing an action to be audited and explained. Rob Thomas, IBM’s Senior Vice President, Software and Chief Commercial Officer, frames the progression not as a linear journey but as a zigzag — organizations will move two steps forward and one step back — with the meaningful milestone being the transition from isolated pilots, to connected projects, to a program where AI is embedded in daily operations. IBM is addressing multiple specific problems that enterprise buyers have told it matter most. 

    Giving developers an AI partner that understands enterprise constraints, not just code.

    IBM Bob, now generally available, is an agentic development partner designed to work across the full software development lifecycle — from requirements gathering and architecture planning through code generation, testing, security scanning, and documentation. Bob is not only a code autocomplete tool. Coding assistants can respond to individual prompts, but IBM’s Bob also functions as a persistent team member that reads your organization’s standards, follows your approval gates, and meets the same compliance requirements as any other developer on the team.For organizations running core workloads on mainframes, IBM Bob Premium Package for Z extends these capabilities to IBM Z environments—a detail worth noting for financial services, insurance, and government agencies, where Z infrastructure handles the most sensitive transaction processing. IBM reports that 80,000 of its developers are using Bob, with an average productivity improvement of 45 percent. Those are IBM’s own numbers, but the Dublin development team featured in the keynote reported independently: a 70 percent reduction in onboarding time, 40 percent faster feature implementation, and sprint forecast variance tightening from 35 percent to 15 percent.

    Managing agents you didn’t all build yourself. — and the ones you didn’t know you had.

    IBM watsonx Orchestrate is IBM’s answer to a problem every scaling enterprise will face. AI agents are proliferating faster than the ability to govern them. In most large organizations, agents are already being created across different teams, tools, and frameworks — some built in-house, some embedded in vendor applications, some procured as point solutions. What has been missing is a way to manage that reality without forcing teams to rebuild what they already have. Orchestrate addresses this through an agentic control plane that brings agents into a single operational layer regardless of how they were built or where they run. Today, that includes IBM native agents, LangGraph agents, Langflow agents, and agents built on the open A2A protocol, with broader interoperability planned. Beyond connectivity, Orchestrate adds observability and tracing across agent interactions, build-time, and runtime evaluation. It adds a governed catalog, which is a centralized registry of agents and tools with performance metrics, certification workflows, and lifecycle management. The catalog allows organizations to see which agents exist and assess their trustworthiness. The positioning is deliberate. IBM is not leading with agent-building tooling. The argument is that enterprises don’t need another way to build agents — they need a way to operationalize the ones they’ve already built. As organizations scale from a handful of AI agents to dozens, hundreds, or thousands, built by different teams on different platforms, the governance problem grows faster than the deployment problem. Orchestrate is designed to enforce policy, log actions, and provide accountability across agents regardless of which vendor produced them. This matters because the agent governance gap is already visible in breach data, not just survey responses. Having a place to see what agents are doing, what they’re accessing, and whether they’re operating within sanctioned boundaries is a reasonable requirement before deploying them in consequential workflows. The 82 percent unknown-agent figure from CSA is the risk case for why this capability exists.

    Giving AI access to data that reflects what’s happening now.

    IBM acquired Confluent and is integrating the company’s Kafka streaming and Flink processing capabilities into watsonx.data. The practical effect: AI systems can act on data that’s current, not data that was accurate several hours ago.Most enterprise AI runs on batch data with snapshots taken at intervals and loaded into a system that the AI then queries. For low-stakes use cases, that’s fine. For AI agents making supply chain decisions, resolving customer service issues, or assessing fraud, the gap between what the data says and what’s actually happening in real time poses real risk. In the keynote, Krishna described the logic directly: “Confluent, which is the data streaming platform used by over 6,500 enterprise clients and 40% of the Fortune 500, brings real-time streaming data into our data foundation. After all, AI agents are only going to be as good as the data they can access.” The Confluent acquisition is recent, so buyers should validate the depth of integration in production scenarios before committing.

    Fixing security vulnerabilities, not just finding them.

    Concert Secure Coder addresses a gap that every enterprise security team lives with. Scanners surface vulnerabilities, and developers don’t always fix them. It’s not because developers don’t care. Developers struggle because fixing a dependency that’s been in production for years requires understanding what else will break. The blast radius of a patch is often unknown, which means the patch doesn’t happen. Concert provides visibility into the dependency chain first, then uses an AI agent to execute the fix, verify the result, and create the pull request. Dinesh Nirmal, SVP of IBM Software, described the Sovereign Core design philosophy in terms that apply equally here: “AI has made sovereignty a runtime requirement, not a policy statement.” The same shift applies to security — from point-in-time scanning to continuous, embedded remediation.

    Giving regulated enterprises a sovereignty foundation they actually control.

    IBM Sovereign Core is a full-stack deployment foundation designed for organizations where data residency, model governance, and operational control are non-negotiable — particularly in Europe, where the EU Sovereignty Framework issued in October 2025 introduced a measurable eight-criteria standard for evaluating sovereignty claims. The distinction from conventional approaches is meaningful: most vendor-sovereignty offerings stop at contracts, data-residency commitments, and policy documentation. Sovereign Core goes further — the control plane, secrets, keys, identity, and access all stay within the customer’s environment boundary, and the customer decides what runs inside it. It ships with 160 compliance frameworks out of the box, continuously monitored and automatically verified, with proof generated at the ready rather than reconstructed at audit time. It is also explicitly architected for replaceability. A customer can retain a credible exit strategy rather than trading one form of dependency for another. For organizations in heavily regulated industries — financial services, healthcare, government — Sovereign Core is positioned as the answer to whether a company can adopt AI at scale without surrendering operational control. But the harder problem is the accountability gap. Governance frameworks from NIST AI RMF and ISO 42001 require explicit accountability lines for AI decisions — specific people with documented oversight responsibilities. In practice, security teams assume compliance owns model monitoring. Compliance assumes security owns it. When an agent makes a consequential error, the question “who approved that decision?” often generates no clear answer. 

    What’s Still Hard

    IBM’s portfolio addresses structural problems, but structural problems don’t resolve quickly. For example: 

    1. Observability consolidation takes time. Concert’s value proposition — currently in public preview — depends on bringing signals from applications, infrastructure, network, and cost into a single view. Most enterprises already have Datadog, Dynatrace, Splunk, or a combination of these tools handling parts of that job. IBM’s positioning is that Concert doesn’t require replacing those tools. That’s the right framing, but integration depth varies, and the work required to connect existing tooling into a coherent view should be factored into any realistic timeline.
    2. AI infrastructure costs are continuing to rise. Deloitte found that AI is now the fastest-growing line item in corporate technology budgets, with cloud costs rising roughly 19 percent in 2025 for many enterprises. IBM’s GPU-accelerated Presto capability, co-developed with NVIDIA and currently in private preview, aims to reduce data processing costs. IBM cites 83 percent cost savings and a 30x price-performance improvement from a proof-of-concept with Nestlé spanning 186 countries. That reference is credible, but a proof-of-concept in one environment is not a production benchmark. Test against your own data before treating it as a baseline expectation. General availability is targeted for later in 2026.
    3. The governance gap isn’t policy — it’s proof. Many, but not all, enterprises have AI governance strategies. For those with governance in place, many are still missing the audit trail that demonstrates it’s working. The EU AI Act comes into full effect on August 2, 2026. High-risk AI systems, such as those that touch employment decisions, essential services, or critical infrastructure, must have conformity assessments completed, human oversight mechanisms operational, and technical documentation ready for regulatory inspection.

    What the Customer Evidence Actually Shows

    IBM’s strongest proof point is internal. Krishna cited $4.5 billion in annualized productivity gains from applying AI and automation across IBM’s own operations — a reported figure in financial filings, not a projection. Eighty thousand IBM developers use Bob, achieving an average productivity improvement of 45 percent. External customer evidence is early but directional. Aramco, whose partnership with IBM dates to 1947, described moving AI from experiments to field-scale operations across upstream, refining, and corporate functions — generating more than $5.2 billion in value from AI executions, with over 50 percent of that coming from production deployments rather than pilots. Elevance Health described investing approximately $1 billion in AI to simplify the healthcare experience for members, providers, and internal staff — using 500 data points to match members with appropriate providers and deploying AI to help members understand their benefits through a virtual assistant. These are meaningful reference points. They also reflect organizations with substantial data infrastructure, technical teams, and leadership commitment already in place. Neither story starts from zero.

    One Thing to Remember

    In the Think 2026 keynote, Krishna drew a historical parallel worth taking seriously. He traced the arc from computing in the 1960s through the internet era of the 1990s and 2000s. In each case, the organizations that redesigned their business model around the new technology pulled decisively ahead of those that used it only at the margins. His assessment of where most enterprises stand today: “Most enterprises run AI at the margin. The core end-to-end processes — how an enterprise makes money, makes decisions — are largely untouched.” That observation is accurate, and the data support it. The organizations making progress with AI are not the ones with the most tools. They are the ones who have connected the right data to the right processes with clear accountability for what happens when AI gets it wrong. IBM is not the only company providing these types of AI strategies. Different vendors have one or more of these aspects; however, it’s good to see that IBM’s portfolio is built to address real enterprise challenges.

  • Amazon Connect Is Now a Family of Products That Adds Agentic AI  to CX, HCM, Supply Chain and Healthcare

    Amazon Connect Is Now a Family of Products That Adds Agentic AI to CX, HCM, Supply Chain and Healthcare

    AWS is betting that Amazon Connect agentic AI belongs in supply chain, hiring, and healthcare — not just customer service. The branding is smart. Here’s my quick take. 

    For years, Amazon Connect meant one thing: contact center software. As of this week, it means four products, three new markets, and a bet that agentic AI is ready to run business operations — not just answer customer calls.

    At its “What’s Next with AWS” event, Amazon Web Services announced the expansion of the Amazon Connect name into a family of agentic business solutions. The original contact center product is now called Amazon Connect Customer. Three new products join it: Amazon Connect Decisions (supply chain and demand planning), Amazon Connect Talent (high-volume hiring), and Amazon Connect Health (clinical documentation and patient coordination). All four products sit under the Connect name. All four are agentic by design.

    The naming will raise eyebrows — more on that shortly. But the strategic logic is sound, and enterprise buyers should pay attention.

    What “Agentic by Design” Actually Means Here

    It’s worth being precise about what makes these products different from the AI-infused software most enterprises already live with.

    Agentic AI doesn’t just surface recommendations. It plans a sequence of actions, executes them, monitors the results, and adjusts. The word “connect” is doing double duty in this brand: it references both the product family name and the agents’ actual function — connecting to your systems, your data, and your workflows to get something done without waiting for a human to click “approve” at every step.

    The original Amazon Connect spent the last year being rebuilt on this principle. In 2025, AWS introduced what it called “next generation connect” — adding AI across the full customer journey, not just within a single interaction. Sentiment analysis, agent assist, post-call wrap-up, outbound communication, and full transcription all came along. The shift from the original Connect to Connect Customer is a shift from AI as a feature to AI as the operating model.

    The three new products start from that same premise, except they aren’t retrofits. They were built from scratch for agentic execution.

    Three Reasons the Benefits Case Is Credible

    Vendor AI announcements are easy to be skeptical of. This one has a few things working in its favor.

    Scale. Amazon Connect Customer handled 20 million interactions per day and processed 12 billion AI-powered minutes of conversation last year. That’s not a pilot. The new products are built on the same infrastructure. For enterprise buyers who have watched AI proofs of concept collapse under production load, operational scale at this level is a legitimate differentiator.

    Domain expertise embedded in the product. Amazon didn’t hire supply chain consultants to build Connect Decisions. It extracted the models and decision frameworks from its own retail and logistics operations — systems managing demand planning across more than 400 million SKUs. Connect Talent draws from Amazon’s process for hiring 250,000 seasonal workers in a single season. Connect Health is built on the clinical AI running at One Medical, which has now processed more than one million ambient documentation visits. This is proprietary operational knowledge baked into the product, not a general-purpose LLM applied to a new domain. That distinction matters for buyers evaluating whether a product will actually understand their problem.

    Integration with existing AWS infrastructure. For organizations already running on AWS, these products inherit the identity management, access controls, audit logging, and compliance certifications already in place. Buyers don’t start from zero on security posture or governance. That’s a real reduction in implementation risk, particularly in regulated industries like healthcare and financial services.

    On the Branding: Confusing Short-Term, Coherent Long-Term

    The name “Amazon Connect” has strong recognition in the enterprise market specifically as a contact center product. Adding supply chain, hiring, and healthcare products under the same name will require education.

    That said, the decision is defensible. The Connect products share a common architecture and a common design philosophy. AWS is calling that philosophy “Humorphism” — building products designed around how humans and AI agents collaborate, rather than how humans use static tools. Agents ask clarifying questions. They capture the reasoning behind manual edits. They improve over time as they learn from user decisions. Every Connect product is designed to work this way.

    The naming creates a coherent category: all Connect products are agentic, all are built on Amazon’s internal operational experience, and all are designed for line-of-business adoption rather than IT-led implementation. That’s a real product strategy, not just a logo change.

    Buyers evaluating these products should simply be explicit in conversations with AWS about which Connect product they mean. In the short term, that’s a small friction. In the long term, a unified family brand is cleaner than four separate product names with no connective tissue.

    The Open Questions That Need Answers

    Pricing is TBD. AWS did not address how these products will be priced or licensed. For supply chain and hiring products competing with established enterprise software, pricing model matters significantly. Per-transaction, per-user, and consumption-based models all create different budget implications. Enterprise buyers should not evaluate these products without getting pricing clarity first.

    The ERP and HCM question is unresolved. Connect Decisions targets supply chain planning. Connect Talent targets high-volume hiring. Both markets have entrenched incumbents — SAP and Oracle on the ERP side, Workday and Oracle HCM on the talent side — that already hold enterprise data and run existing workflows.

    The question isn’t whether Amazon can build better AI. The question is how Connect Decisions and Connect Talent interact with the systems enterprises already have. A few scenarios are possible, and AWS hasn’t clarified which one applies. The existing ERP or HCM system could become a data source that feeds the Connect agents. The incumbent vendor could build its own agents that call Connect products as tools. Or both systems end up running parallel agent workflows that need to be orchestrated together. Each of these plays out differently for buyers in terms of integration complexity, data governance, and total cost of ownership.

    The demos shown at the event depict Connect Decisions and Connect Talent operating as primary systems of action — generating demand plans, running interviews, surfacing candidate assessments. That implies some displacement of existing workflow software, at minimum for the activities these agents handle. Whether that displacement requires wholesale replacement of incumbent systems, or whether it can coexist alongside them, is not clear from what was announced. Buyers who already run SAP or Workday should press AWS specifically on this before evaluating further.

    What to Do With This Information

    If you’re an existing Amazon Connect customer, evaluate what the next-generation Connect Customer capabilities mean for your current deployment before looking at the new products. The AI-across-the-journey architecture is a meaningful shift from the original product, and understanding it fully is the right starting point.

    If you’re in supply chain, high-volume hiring, or healthcare and are currently underserved by your existing software, these products are worth a serious look. The domain expertise and scale credentials are real. Get pricing clarity and understand the integration model before committing.

    If you’re running SAP, Workday, or another incumbent system in these domains, don’t assume this announcement is irrelevant to you. The better question to ask your existing vendor is: what is your agent strategy, and how does it interact with what AWS just announced?

    The question isn’t whether Amazon Connect should be a family of products. The question is whether or how to make your current stack work alongside it.

    Subscribe to my AI with Maribel Lopez podcast on your channel of choice at https://www.buzzsprout.com/194744.