Skip to content

Chapter 0.1 — Model, product and system

🎯 Chapter objective

Distinguish three levels of abstraction that are often confused: model, product and system — and show why this distinction is the root of the most expensive mistakes in enterprise AI.

🧠 Core concept

  • A model is a function that maps inputs to outputs. It has weights, an architecture, a competence boundary, assumptions about the data, and a validity window.
  • A product is the application consumed by a person or another system. It has UX, API contracts, business rules, SLAs and context.
  • A system is the full operational whole: product + model + data services + evaluation services + security + governance + cost + operation + lifecycle.

The central thesis of this book is that real AI value appears in the system, not in the isolated model.

🏗️ How this shows up in production

A classifier with 98% offline accuracy can fail in production because:

  • production data differs from training data;
  • the most informative feature is only available with a delay;
  • the downstream consumer interprets the output incorrectly;
  • there is no rollback if quality drops;
  • there is no accountable person when an incident happens.

None of these problems is solved by swapping the model.

⚖️ Trade-offs

Dimension "Model" focus "System" focus
Time to demo Short Longer
Time to production Usually long Shorter
Maintenance cost High and hidden Visible from the start
Operational risk Concentrated in incidents Distributed and mitigated
Success at scale Unpredictable Predictable

🚨 Failure modes

  • "Works in the notebook" as proof of production-readiness.
  • Offline metrics disconnected from the business KPI.
  • Model swapped without behavior regression testing.
  • Upstream data failure causing silent degradation.
  • A good model serving the wrong data (cross-tenant, old version, different language).

🛡️ Controls and mitigations

  • Treat AI as critical software: versioning, tests, observability, CI/CD, rollback, runbooks.
  • Document accepted failure modes and unacceptable failure modes.
  • Distinguish what is the responsibility of the model, the product and the system.

🔭 How to observe and measure

  • Technical metrics: latency, throughput, error rate, cost per call.
  • Quality metrics: accuracy, F1, groundedness, recall@k.
  • Business metrics: conversion, satisfaction, ticket deflection, MTTR.
  • Governance metrics: policy violations, DLP events, pending approvals.

🧪 How to test

  • Unit and integration tests in the product.
  • Eval harness (offline and online) on the model.
  • Replay of real traces.
  • Canary deploy for changes.
  • EX-FUND-01 — compare the output of an isolated model vs the same model embedded in a product with pre-processing and post-processing.

📌 Checklist

  • [ ] Does the system have an owner for model, product and operation?
  • [ ] Is there documentation of the input/output contract?
  • [ ] Is there an upstream data validation pipeline?
  • [ ] Is there a rollback process?
  • [ ] Is there a runbook?

📚 References