The Model Is Only One Component

It is tempting to draw an AI system as one box labeled MODEL. That picture hides most of the engineering.

A more useful view is:

input → validation → preprocessing → model → decision policy → action → logging/monitoring

Human review, fallback behavior, and override authority may sit beside several of those stages.

The same model can live inside very different systems

Imagine a classifier that returns a score from 0 to 1.

System A displays the score to a technician.

System B automatically stops a machine when the score exceeds 0.70.

System C sends scores from 0.40–0.80 to a human and acts automatically only outside that uncertain band.

The model can be identical in all three systems. The consequences are not.

Suppose the model returns 0.74.

• In System A, the output is information.
• In System B, it becomes an automatic action.
• In System C, it triggers human review.

The model output did not change. The system policy changed what the output meant operationally.

Interfaces create new failure modes

Each boundary can fail independently:

• input schema changes;
• units change from centimeters to meters;
• preprocessing code is updated incorrectly;
• model service times out;
• a threshold configuration changes;
• logging stops;
• a fallback path is missing;
• human override becomes unavailable.

A high evaluation score does not test all of these conditions.

Build a system map before claiming system quality

For any AI application, identify:

1. where data enters;
2. what validates it;
3. what transforms it;
4. where inference occurs;
5. how scores become decisions;
6. what happens when a component fails;
7. who can stop or override the system;
8. what evidence is logged.

That map is the beginning of AI systems engineering.

Before moving on

Take a model you encountered earlier in the course and name three non-model components required to turn its prediction into a usable application.