Most conversations about AI stop at capability: what can the model do? The more useful question for anyone running a business is availability: will it still be doing it at three in the morning, on a holiday, under load, when its inputs --- and the model behind them --- have quietly changed?
Reliability is a property of the system, not the model
The model is one component among many, and most of what threatens the system is not the model. The provider deprecates a version or changes its behavior overnight; a rate limit throttles you at peak; a burst of traffic turns token cost into a bill nobody approved; the retrieval index drifts and answers quietly degrade. Staying up means timeouts and retries, graceful degradation when a dependency is slow, sensible fallbacks when a response fails validation, and hard limits that stop a bad day from becoming an outage or a runaway bill. None of this is model research, but all of it is engineering an AI system --- and it is what makes a model usable in production.
Observability for systems that are allowed to be wrong
Traditional monitoring assumes a clear line between working and broken. AI systems live in the gap: every health check green, latency normal, error rate zero --- and the answers quietly worse than last week. A model can be technically healthy and functionally broken at the same time. That calls for a different kind of observability --- output quality, groundedness, retrieval hit rate, cost per request and drift, not just uptime and error rates --- so that a slow degradation surfaces as an alert rather than a customer complaint.
The pager is part of the design
An operable system is designed with its worst day in mind: runbooks for the failures you can predict, alerts that page a human before customers notice, the ability to roll back a model or pin a version as easily as a deployment, and clear ownership of who responds when it fires. Deciding all of this after launch is how a promising system becomes one nobody wants to maintain.
Operating the system is not an afterthought to the engineering; it is the engineering. That is what it means to build software that survives contact with reality.