Working Backward from Business to Data

This chapter is the strategic anchor of the whole talk.

So far we’ve covered the age of AI, the concept of data, the dimensions of quality, the production method, and the flywheel’s evolution. But unless we anchor it back to business value, it all still sounds like a technical pitch.

The real question is:

We don’t govern data for the sake of governing data — we do it to let AI close the business loop, and ultimately lift core competitiveness and productivity.

The industry’s biggest mistake is to govern the data first and then ask what AI can do. That’s the BI-era playbook from ten years ago, and in the age of AI it burns a fortune.

The value chain from data to competitiveness

The right value chain runs in reverse:

Core competitiveness and productivity gains decide the business loop;

the business loop decides what AI capabilities you need;

those AI capabilities decide what high-quality data you need.

So the starting point isn’t “what data do we have,” but:

What kind of AI-driven business loop are we trying to build?

Take a healthcare group. The business loop might run: patient acquisition, screening, diagnosis, treatment, follow-up, insurance coordination, health management, return visit.

Every step can be AI-enabled — but every step needs completely different data.

The four-step working-backward method

Step 1: Diagnose the business.
Map the AI-enabled business loop first. Don’t inventory the database first. Get clear on where the business needs to win, and which step AI should plug into.

Step 2: Split the AI’s role in two.
Decide whether this AI earns productivity or earns core competitiveness.

• Productivity AI: raises efficiency, cuts cost — usually buyable off the shelf
• Core-competitiveness AI: builds proprietary capability and business differentiation — must be built in-house or jointly built

Step 3: Work backward to the data.
Return to the five classes of fuel from Chapter 6. Productivity AI is mostly knowledge-type or workflow-type — it mainly needs external knowledge bases and internal SOPs. Core-competitiveness AI is mostly a mix of data-type, reasoning-type, and workflow-type — it demands self-built data assets.

Step 4: Govern with precision.
Don’t govern all the hospital’s data — govern the data AI will actually use. Don’t wait until governance is done to launch AI — let the AI launch force the governance.

Buy vs. build

Buying isn’t settling for less, and building more isn’t always better. It’s a strategic choice.

What to build:

• Tied to core competitiveness: specialty reasoning, patient profiles, expert preferences, clinical feedback
• Highly sensitive data: patient privacy, trade secrets, client-exclusive material
• Data no one else has: your own specialty cohorts, MDT reasoning chains, a firm’s methodology

What to buy:

• Industry-generic knowledge: insurance policy, clinical guidelines, drug labels, statute libraries, contract templates
• The algorithm and model layer: diagnostic AI, CDSS engines, general-purpose LLMs
• Compute and infrastructure
• Annotation services and generic platform capability

The one-liner is simple:

Build what decides competitiveness; buy what decides productivity.

Law works exactly the same way. Statute libraries, compliance libraries, and contract-template libraries are best bought — the price-to-value is unbeatable. Expert-argument libraries, client-exclusive agents, and a firm’s distilled methodology must be built.

Three pieces of advice for CIOs / CTOs

Don’t launch a hospital-wide governance mega-project in year one.
Pick 3–5 AI business loops to fund, and let real business force the governance priorities.

Ship productivity AI in three months.
Start with knowledge-type, office, and process applications — build AI confidence fast and earn next year’s budget.

Give core-competitiveness AI two to three years of strategic patience.
Specialty data assets, reasoning-chain production lines, and domain ontologies cannot pay off in a single quarter.

These three hold just as well for managing partners and heads of legal.

Palantir’s ontology path

Plenty of you know OpenAI and Anthropic, but may not see what Palantir has to teach the professional industries.

OpenAI takes the general-intelligence route. Palantir takes another: the ontology path.

Palantir’s Ontology turns every business object, attribute, relationship, and action inside an enterprise into a living semantic graph:

• Objects: aircraft, parts, orders, patients, medical records, contracts, precedents, parties
• Relationships: belongs to, reports to, triggers, composes, references, cites
• Actions: procure, dispatch, diagnose, transfer, draft, review, adjudicate

The LLM never looks at raw data directly — it queries, reasons, and executes actions on top of this ontology. That solves the model’s fundamental problem: not understanding the enterprise’s business.

Why professional industries should learn from Palantir

A hospital or a law firm will never train an OpenAI-grade foundation model. That road is closed.

But the Palantir road is learnable:

• No need to train a general-purpose LLM
• You build your own domain ontology: a medical ontology, a legal ontology, a specialty ontology, a business ontology
• The general-purpose LLM can be bought; the ontology must stay in your own hands

This is exactly why Chapter 2 planted the concept of ontology.

Professional industries don’t race on the model — they race on the domain ontology.

On top of the ontology, the model can swap, the agent can change, the business loop stays.

That is the real moat of a data asset.

Wrapping up the chapter

First get clear on which business loop AI should support; then get clear on whether the AI earns productivity or competitiveness; and only then decide how to govern the data, and whether to build or buy.

Governing data is the means; winning the business is the end. Don’t mistake the means for the end.

Next chapter: mapping this whole logic onto a legal-profession audience.