What is Artificial Intelligence?

Imagine an insurance platform with four components:

• policy code that rejects claims submitted after a contractual deadline,
• a statistical model that estimates fraud risk,
• a language model that summarizes adjuster notes,
• and a workflow service that decides which employee may approve payment.

The company may describe the entire platform as "AI-powered." That description is convenient for marketing and nearly useless for engineering. Which component infers rather than executes a fixed instruction? Which component learned from data? Which one generates content? Which one has authority to affect a customer?

Those questions expose the central lesson of this chapter: AI is not one component, one algorithm, or one product category. Engineers need several dimensions to describe an AI system precisely.

The Big Question

What makes a system an AI system, and how can an engineer distinguish the AI field, an implementation method, a model family, a capability, a product, and the authority granted to that product?

Why This Matters

Imprecise language becomes imprecise architecture. If a requirement says only "add AI," a team cannot determine the required data, evaluation method, failure behavior, security boundary, latency budget, or human oversight. A classifier, a document generator, and an autonomous tool-using workflow have different contracts even when all three use the same underlying model provider. A precise description lets a team answer questions that matter:

• What output does the system infer?
• What evidence supports that output?
• Which behavior is learned, searched, optimized, or explicitly programmed?
• What can the model propose, and what may the application actually do?
• Who detects, contains, and corrects a wrong result?

This vocabulary is the foundation for every later volume. It prevents model names from replacing system design.

Learning Objectives

By the end of this chapter, you will be able to:

1. define an AI system operationally without claiming that it thinks like a human,
2. separate AI fields, methods, model families, capabilities, applications, and authority,
3. explain why learning and adaptation are possible AI capabilities rather than universal requirements,
4. classify rule-based, predictive, generative, and agentic systems without forcing them into one ladder,
5. identify the deterministic controls required around probabilistic components,
6. review a proposed AI system from beginner, engineer, and architect perspectives.

Prerequisites

No AI background is required. Familiarity with ordinary software inputs, outputs, APIs, tests, and business workflows will help, but all AI terminology used here is defined before it is applied.

Mental Model: Describe the System on Six Axes

The fastest way to become confused about AI is to place every term in one hierarchy. The terms answer different questions.

One system can have a value on every axis. An internal policy assistant might use Machine Learning as a method, an LLM as a model family, generation and retrieval as capabilities, a web application as its product surface, and "recommend only" as its authority.

Figure 2.1 - Six Axes for Describing an AI System

Rendering diagram...

The axes are complementary, not levels of maturity. Moving from "LLM" to "application" is not moving up a hierarchy; it is changing the question.

Core Concepts

AI as a Field and AI as a System

Artificial Intelligence names a broad field of research and engineering. The field studies computational systems that perform functions associated with perception, inference, learning, planning, language, decision support, and action.

An AI system is a deployed or deployable machine-based system that receives inputs and infers how to produce outputs such as predictions, content, recommendations, or decisions for explicit or implicit objectives. This operational framing is close to the updated OECD definition, which is designed for classifying real systems rather than settling philosophical arguments about human thought.

The word infers matters. The system does more than replay a fully specified sequence of human-written operations for every possible input. Its output is derived through a model, learned parameters, search, optimization, knowledge representation, or another computational inference mechanism.

There is no universally accepted boundary around AI. Research traditions often include symbolic expert systems and planning algorithms. Some modern regulatory definitions distinguish AI from software that only executes rules fully defined by people. Engineers should therefore state the definition they are using and describe the mechanism instead of arguing from a label.

Intelligence Is an Attribution, Not a Substance

Calling a system intelligent does not establish consciousness, intention, emotion, or human-like understanding. It attributes observable competence in a task and context.

Alan Turing made a related move in 1950: rather than solve the meaning of "thinking" first, he proposed examining machine behavior through the imitation game. The historical paper is useful because it shifts attention from an unobservable inner state to evidence that can be tested. See Turing, "Computing Machinery and Intelligence". For engineering, capability claims must be bounded:

• "The model classifies these radiographs with measured sensitivity on this dataset" is testable.
• "The model understands medicine" is too broad to design, evaluate, or govern.
• "The assistant may draft a response but cannot approve treatment" defines authority.

Capabilities Are Optional and Composable

AI systems may contain several capabilities, but no single list is mandatory.

A rule-based expert system can infer without learning. A batch-trained model can learn before deployment but never adapt online. A recommendation model can rank items without acting. An LLM can generate a tool request, while application code decides whether that request is authorized. These distinctions become system boundaries.

Figure 2.2 - The Minimal AI System Boundary

Rendering diagram...

The model or inference mechanism is only one part of the system. Controls determine whether an output may influence the world.

Machine Learning Is a Method, Not a Synonym for AI

Machine Learning produces behavior by fitting patterns or parameters from data. It is one important family of AI methods, not the definition of AI itself. Other methods include:

• symbolic rules and knowledge representation,
• graph and tree search,
• constraint solving,
• probabilistic inference,
• mathematical optimization,
• planning algorithms,
• combinations of learned and deterministic components.

This is why a chess engine can be considered AI even when its core uses search and an evaluation function rather than learning from a training dataset. It is also why ordinary business rules are not automatically AI: a deterministic tax calculation may be sophisticated software without performing model-based inference under the definition used by the team or regulator.

Deep Learning, Foundation Models, LLMs, and Generative AI

These terms describe different axes:

• Deep Learning is a Machine Learning family based on multi-layer neural networks.
• A Foundation Model is trained broadly enough to be adapted to many downstream tasks. The term was introduced to emphasize both broad reuse and the fact that applications are built on top of a shared base. See the Stanford CRFM report.
• A Large Language Model is a high-capacity learned model centered on language or language-like token sequences. Many broadly pretrained, reusable LLMs are Foundation Models, but a specialized language model need not be one.
• Generative AI describes the capability to produce new artifacts such as text, code, images, audio, video, or structured data. Generative capability is not limited to LLMs.

Do not describe a Foundation Model as stored or reusable "intelligence." More precisely, it contains learned parameters and representations that support a range of downstream capabilities under specific prompting, adaptation, data, and system conditions.

Engineering Perspective: Classify Before You Select

When a stakeholder requests AI, do not begin with a model catalog. Write a one-paragraph system contract.

For which users, the system receives which inputs and authorized context, uses which inference method to produce which output, may influence which decision or action, and falls back to which safe behavior when evidence or confidence is insufficient.

That sentence reveals missing requirements earlier than a provider comparison. Use six review questions:

1. Output: Does the system classify, predict, rank, retrieve, generate, plan, or act?
2. Evidence: Which rules, training data, retrieved sources, tool results, or human inputs support the output?
3. Mechanism: Which parts are deterministic, searched, optimized, or learned?
4. Boundary: Where does the model end and application responsibility begin?
5. Authority: May the system inform, recommend, draft, decide, or execute?
6. Failure contract: Must it abstain, request more evidence, route to a person, use a fallback, or reverse an action?

The final question is especially important. "The API returned 200" says nothing about whether an AI-assisted outcome was correct, authorized, or useful.

Real-World Examples

Example 1: Rule-Based Medical Expert System

The system represents clinical facts and manually authored inference rules. It belongs to the historical symbolic AI tradition. It does not need Machine Learning, Deep Learning, or Generative AI. Its strengths are traceability and determinism; its weaknesses include knowledge-acquisition cost, brittle rule coverage, and maintenance when medical guidance changes.

Example 2: Credit-Risk Model

A gradient-boosted model estimates probability of default from structured features. It uses Machine Learning but not necessarily Deep Learning. It predicts a score; it does not approve credit by itself. Policy code, affordability rules, fairness controls, reason codes, and an authorized decision process surround the model.

Example 3: Enterprise Policy Assistant

An LLM receives a question and excerpts retrieved from internal policy documents. It drafts an answer with citations. The product is an AI application; the LLM is a model component; retrieval is an application capability; generation creates the response; identity and source permissions determine which evidence the user may access.

The assistant should not silently turn a draft into an authoritative policy decision. Its authority might be limited to inform and recommend, with human review required for employee-specific decisions.

Common Mistakes

Treating Every AI Term as One Ladder

AI, ML, Deep Learning, Foundation Models, LLMs, Generative AI, and applications do not all describe the same dimension. Use the six-axis model.

Treating the Model as the Product

A useful model can still produce an unsafe product. Authentication, context authorization, workflow state, validation, evaluation, monitoring, and human escalation remain application responsibilities.

Assuming AI Must Learn or Adapt Online

Some AI systems never learn. Many learned systems are frozen after deployment. Online adaptation is an architectural choice with additional validation, security, and rollback requirements.

Equating Fluent Output with Understanding

Fluency is observable; broad understanding is a much stronger claim. Evaluate the specific task, context, failure distribution, and ability to abstain.

Automating Authority Because a Model Is Accurate

Measured accuracy does not grant permission to act. Authority depends on impact, reversibility, law, policy, user expectations, and available oversight.

Enterprise Perspective: A Model Is Inside a Control System

Consider the policy assistant as an enterprise architecture rather than a demo.

Figure 2.3 - Enterprise Policy Assistant With Explicit Control Boundaries

Rendering diagram...

The architecture separates evidence access, model inference, output validation, authority, and operational feedback. Replacing the LLM does not remove those responsibilities.

An architect should make at least the following decisions explicit:

NIST's AI Risk Management Framework organizes risk work around Govern, Map, Measure, and Manage. The key lesson for this chapter is that AI risk belongs to the complete socio-technical system and its context, not only to model accuracy.

Engineering Trade-offs

The most mature design is rarely the one with the most AI. It is the smallest system that meets the outcome, evidence, reliability, and authority contract.

When AI Is the Wrong Abstraction

Prefer ordinary software when:

• a deterministic formula produces the authoritative answer,
• complete rules are available and change through controlled policy updates,
• a database query directly answers the question,
• errors are unacceptable and no independent verification or recovery exists,
• the organization cannot define an evaluation target,
• the proposed use has no owner for data, outcomes, or incidents.

A banking system calculates an account balance from a ledger. A language model may explain the balance, but it must not invent or replace the source-of-truth calculation.

Architect-Level Completion Check

A team proposes an assistant that answers policy questions, summarizes uploaded documents, creates support tickets, and recommends next actions. You understand this chapter at architect level when you can produce four artifacts:

1. a six-axis classification of each capability,
2. a component and trust-boundary diagram separating models from deterministic controls,
3. an authority matrix stating what the system may inform, recommend, draft, decide, and execute,
4. a failure contract covering insufficient evidence, unauthorized context, model failure, unsafe output, and rollback.

The dedicated Lab tab turns this scenario into a reviewable architecture brief. The Python and Java tabs provide a runnable classifier that detects contradictory taxonomy claims rather than merely printing a hierarchy.

Chapter Summary

Artificial Intelligence is a broad field; an AI system is a concrete machine-based system that infers outputs for objectives in a context. Learning, adaptation, perception, generation, and autonomous action are possible capabilities, not universal requirements.

Engineers describe a system across six axes: field, method, model family, capability, application, and authority. This prevents an LLM from being confused with the product around it and prevents model capability from being confused with permission to act.

Enterprise AI engineering begins at the system boundary. Evidence access, authorization, validation, evaluation, fallback, monitoring, ownership, and change control determine whether model output becomes reliable business behavior.

Key Takeaways

• Define the observable system and context before debating whether it is "really AI."
• Machine Learning is one method for building AI behavior; AI does not universally require learning.
• Deep Learning, Foundation Models, LLMs, and Generative AI answer different classification questions.
• A model produces candidate output; the application grants authority and contains failure.
• Capability claims must be scoped to a task, population, environment, and evaluation.
• The smallest reliable system is usually better than the most fashionable model.

Before You Continue

You are ready for Chapter 3 when you can explain, without using a single ladder:

1. why a symbolic expert system can be AI without Machine Learning,
2. why an LLM is not the same thing as a chat application,
3. why Generative AI is a capability rather than a universal model family,
4. why a high-quality recommendation does not automatically authorize an action,
5. which deterministic controls surround an enterprise model endpoint.

What's Next?

Chapter 3 examines types of Artificial Intelligence. It separates useful engineering classifications from speculative labels and shows how capability, memory, autonomy, and generality change a system's requirements and risks.