AI begins where code meets data

Why the value of an AI application comes from data, software, rules and control working together — not from the model alone.

A new model appears, a benchmark rises and a demo answers questions more fluently. It is easy to believe that the central decision has already been made: choose the most capable model, add an interface and connect the organisation's documents.

In practice, this is where system engineering begins. A pretrained model represents statistical patterns from its training data. Without supplied context, it does not reliably know an organisation's current pricing logic, approval stages, customer agreements, protection classes or exceptions. Even a powerful model cannot support a dependable operational decision when required data is missing, terminology conflicts or tools operate without clear boundaries.

The title is therefore not a literal definition of artificial intelligence. Models are, of course, trained on data. It describes the moment when general model capability becomes a concrete application: software deliberately connects the model to accountable data, rules, tools and real processes.

The model is a component, not the system

A useful architecture lens separates four layers:

1 · Data: documents, tables, events, master data, metadata and permission information.

2 · Processing: ingestion, parsing, cleaning, normalisation, linking, chunking and retrieval.

3 · Model and logic: deterministic rules, traditional machine learning, generative models and possibly agentic planning.

4 · Control: identities, access, approvals, logging, evaluation, monitoring and intervention boundaries.

Looking only at the language model hides many failure modes. A wrong output may result from model behaviour, but also from an obsolete source, parsing error, incorrect unit conversion, broken mapping or unsuitable access configuration. The better question is not merely which model failed, but where meaning, validity or control was lost across the system chain.

Data work changes system behaviour

Three systems may label the same state "completed", "closed" and "done". People may infer equivalence; an automated pipeline may create three categories. A model can propose a mapping, but it should not silently decide which definition is organisationally binding.

The same issue appears with currencies, time zones, measurement units, customer identifiers and roles. If "revenue" means net revenue in one source, gross revenue in another and forecast revenue in a third, model selection is not the primary problem. The system needs a data dictionary, an approved mapping and a testable transformation.

Data work therefore becomes indirect model work. It may not alter trained parameters, but it changes the signals the system receives, the categories it constructs and the actions that may follow.

Data contracts connect domain meaning and software

A robust interface needs more than a file format. A data contract states required fields, meaning, allowed values, freshness and the response to violations.

dataset: customer_requests
version: 2.1
required_fields: [request_id, received_at, category, status]
status_values: [new, triaged, in_progress, resolved]
timezone: Europe/Berlin
owner: Service Operations
freshness_target: 15m
on_validation_error: quarantine

The contract does not prove perfect data. It makes expectations testable. If a source suddenly sends new status values, the pipeline can quarantine the records instead of passing them silently into models and automation.

Not every problem needs a large language model

Good AI Data Engineering selects the right mechanism. Deterministic rules are appropriate when conditions are stable and outcomes must be unambiguous. Approval thresholds, required fields and access blocks should not be creatively interpreted. Traditional machine learning supports learned classification, prediction and anomaly detection when appropriate training and evaluation data exists. Generative models help summarise, transform, explain and provide natural-language access.

Agentic systems add planning and tool use. This increases both capability and blast radius. A draft is reversible; a sent email, changed permission or placed order may have immediate consequences. Greater impact requires constrained tools, least privilege, preview, approval, cancellation and audit trails.

The strongest architecture is rarely "LLM everywhere". It combines deterministic controls with statistical and generative components and places people at explicit decision boundaries.

From data flow to action loop

A simple AI application reads data and produces a proposal. An agentic system can also call tools, observe results and choose the next step:

1. Ingest data and determine current state.

2. Retrieve and validate relevant information.

3. Produce a plan or proposal.

4. Use permitted tools within defined limits.

5. Observe outcome and side effects.

6. Continue, correct, escalate or stop.

At every transition, define the input data, applicable rule and accountable role. Without these definitions, flexibility becomes unpredictability.

Production begins after the demo

A demo may succeed with a few curated documents. Production introduces new versions, unexpected inputs, permission changes, outages, retention periods, budgets and conflicting sources. A good example answer is not sufficient evidence of operational readiness.

Production requires a lifecycle: ingest, validate, provide, use, measure, trace errors and update sources. Changes to prompt, model, retrieval or data must be versioned because each can alter system behaviour. A model replacement may change synthesis. A parser update may split tables differently. A refreshed index may retrieve different passages. A permission change may widen or narrow available evidence.

Every release therefore needs a traceable configuration of data state, code version, model, rules and evaluation results.

Observability must measure causes

Latency and exceptions are not enough. Domain quality needs additional signals: retrieved sources, active filters, validation failures, human corrections, cost, duration, abstentions and escalations.

Evaluation should separate layers. Data checks examine schema, freshness and allowed values. Retrieval tests examine evidence selection. Output tests examine groundedness, completeness and appropriate uncertainty. Process tests verify tool permissions and stop conditions.

A single score cannot replace these views. Good observability lets teams trace a weak result to its source instead of merely prompting again.

The human role changes

People do not need to execute every intermediate step manually. Their central task is to define domain meaning, risk boundaries and approval rules. They confirm critical mappings, handle exceptions and review high-impact actions.

Effective control requires more than an approval button. Reviewers need relevant inputs, evidence, uncertainty, applied rules and actual authority to reject, modify or stop an action before consequences occur.

The decisive architecture idea

A model can be impressive. A reliable application emerges from the surrounding system. Data connects it to reality. Software joins components. Rules constrain behaviour. Controls make decisions traceable. Humans secure meaning and accountability.

For an operational use case, decisive AI design therefore begins where code meets accountable data — not because intelligence appears from nothing, but because general capability is translated into a real, testable and consequential function.

Worksheet: Design the four layers of an AI system

Choose a real or fictional use case. Build a system map that separates data, processing, model/logic and control.

1. Define purpose and impact. Describe users, desired outcome and failure consequences. Mark reversible and high-impact actions.

2. Define data and contracts. List sources, owners, freshness, protection class and expected fields. Write at least three testable data rules.

3. Select the mechanism. Assign each step to deterministic rules, traditional machine learning, generative AI or human decision. Explain why.

4. Set decision boundaries. Define when the system may continue and when it must pause, escalate or request approval.

5. Plan observability. Specify at least one signal, one test and one accountable role per layer.

All materials to download — the topic overview and the worksheet:

Scope: The title is an editorial thesis about operational AI applications. Models are already trained on data; the intended point is that business value emerges when a model is deliberately connected to current data, software, rules and processes. The NIST AI RMF is voluntary.

Sources and professional scope