Shelf five · Putting it to work
MLOps & Deployment
Kitchen table
Building the machine is one job. Keeping it working every single day is a different, longer job. Machines that learned from the world go stale as the world changes, like a map from five years ago that still looks crisp but is missing the new bridge. So you watch it, test it, keep the old version ready in case the new one misbehaves, and check its answers now and then against reality. Less like finishing a Lego set. More like owning a puppy.
Whiteboard
Versioning for models, data and prompts together – a prompt change is a deploy. Canary releases and rollback because model behaviour cannot be fully known before contact with real traffic. Drift monitoring on inputs and outputs. Tracing so any answer can be reconstructed after the fact. A model in a notebook is a hypothesis, not a system. The LLM twist: your 'model' is often someone else's endpoint that changes underneath you, so pin versions where you can and eval continuously where you cannot.
Boardroom
This is the gap between a successful pilot and a dependable service, and it is where most AI programmes actually stall. The industry's pilot graveyard is not full of bad models, it is full of models nobody could operate. Running AI costs real money after the launch party: monitoring, retraining, incident response, the second shift nobody budgeted. When a pilot is approved, approve its operating cost at the same time, or you have approved a demo. 'Who owns this model at 2 a.m.?' remains the sharpest question in the room.
Related concepts