Decision intelligence and embedded analytics: making the decision the unit of design

The term "decision intelligence" gets used loosely. Some vendors attach it to any product that has an AI recommendation somewhere on screen. Academics trace it to a formal discipline combining decision theory, data science, and organisational design. Both framings exist simultaneously, which is exactly why CDOs end up talking past their CFOs and boards when the topic comes up.

The concept worth pinning down is this: decision intelligence is the discipline of designing the information environment around a specific decision, not around a dataset or a dashboard. That shift in unit of analysis changes almost everything downstream.

Why this matters for a CDO specifically

The CDO role is often pulled toward infrastructure: data qualitydata qualityThe degree to which data is fit for purpose: accurate, complete, consistent, timely, valid and unique. Poor quality data undermines analytics, reporting and AI.View full definition →, governance, platform architecture. Those things matter. But the case for the data function is ultimately made at the point where data changes a choice that someone would otherwise have made on instinct or habit.

Most organisations have invested heavily in dashboards. According to MIT Sloan Management Review, generative AI adoption has reached roughly 2.4 billion users globally, yet by most independent assessments, the gap between data availability and actual data-drivendata-drivenAn approach where decisions are systematically informed by data analysis rather than intuition alone.View full definition → decisions inside enterprises has not closed at the same pace. The dashboards exist. The decisions still happen in the hallway.

This gap is the CDO's problem to solve. Not because data teams built bad dashboards, but because dashboards were designed to inform, and decisions require more than information. They require the right framing, the right timing, and the right friction. Decision intelligence is the discipline that addresses all three at once.

How it actually works: the mechanics

The core mechanic is simple: instead of starting with "what data do we have and how should we display it," you start with "what decision happens here, who makes it, what would change their choice, and when do they need that input."

Take a concrete example. A retail bank's loan-officer workflow involves dozens of small credit decisions daily. Traditionally, the bank builds a credit score model and surfaces it in a separate analytics portal. The loan officer pulls data when they remember to, or when a case seems borderline. Most of the time, they apply judgment without the model.

Embedded analytics changes the operating condition. The credit signal is surfaced directly inside the loan-origination system at the moment the officer is reviewing an application. They do not navigate to a separate tool. The model output is there, contexted with a plain-language explanation and a confidence band. The officer still decides, but the decision environment has been engineered.

This is the distinction between analytics that inform andanalytics embedded into workflows at the decision point. The second approach requires knowing the workflow, which means the data team has to talk to operations, product, and the people actually making the calls.

The technical stack for this typically includes a semantic layer that standardises metric definitions across tools, an APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition →-accessible analytics layer (something like a headless BIBITechnologies and processes that turn raw data into actionable insights via reporting, dashboards and analysis, so teams can decide based on facts rather than intuition.View full definition → setup), and integration points into whatever system of record owns the workflow (CRMCRMCustomer Relationship Management: software and strategy to manage and analyse customer interactions throughout their lifecycle.View full definition →, ERP, origination platform, ITSM). dbt Labs, a commercial vendor of data transformation tooling, has made this argument explicitly: that the transformation layer and the compute platform are separate decisions, and that what sits between them (the definition of what a metric means) determines whether analytics land correctly in the consuming system. That framing is vendor-motivated, but it describes a real architectural problem.

The harder part is decision architecture: defining what type of decision is being made (one-time versus recurring, individual versus committee, reversible versus not), what information genuinely changes the outcome, and what cognitive load the decision-maker can absorb. A number on a screen is not embedded analytics. A number on a screen at the right moment, with a clear action attached to it, inside the system the person is already using, is.

The role of AI in this picture

AI, including generative AI, changes the surface area available for embeddingembeddingAn embedding is a numerical vector that represents data (text, images, or items) in a way that captures meaning, so similar items sit close together in space.View full definition →. The NVIDIA and Palantir collaboration reported by The New Stack in September 2026 on fine-tuningfine-tuningFine-tuning adapts a pre-trained model to a specific task or domain by continuing training on a smaller, targeted dataset, improving accuracy and style for that use case.View full definition → a 30-billion-parameter Nemotron model for supply chain decisions is one illustration: domain-specific models embedded in operational workflows can outperform much larger general-purpose models on the decisions that actually occur in a given context. The implication is that embedding is not just about where the analytics appear, but about fitting the intelligence to the specific decision type.

Claude's performance on the "agents that build agents" benchmark, also reported by The New Stack in September 2026, passed fewer than a quarter of tests, which is worth remembering when anyone proposes fully autonomous AI decision-making. Assisted decisions, where a human is in the loop with well-designed AI input, still dominate in operational settings where the cost of error is material.

When to use it and when not to: the honest tradeoffs

Decision intelligence investment makes sense when a decision is repeated frequently, when data genuinely changes the probability of a better outcome, and when the decision-maker is reachable in a defined workflow. Loan approvals, inventory replenishment, customer escalation routing: these fit the model well.

It does not fit every problem.Strategic decisions with long time horizons involve too many variables and too little signal for embedded analytics to add much. A CEO deciding whether to enter a new market does not benefit from a recommendation module in their calendar app. The benefit of decision intelligence is specificity, and that specificity disappears at altitude.

There is also an organisational tradeoff. Building around specific decisions requires the data team to spend time in operational workflows, understand change management, and maintain more integration points. That is a different capability profile than building a data warehousedata warehouseA central repository that consolidates data from many source systems into a structured, query-optimized store designed for analytics, reporting, and business intelligence.View full definition →. Teams that try to do both simultaneously usually do neither well, which means sequencing and prioritisation matter as much as the architecture.

The practical starting point for most CDOs is to identify three to five high-frequency decisions where data inputs already exist but are not reaching the decision-maker at the right moment. Fix those first. The wins from that work, measured in outcomes rather than dashboard views, are what make the broader investment legible to a board.