Designing for Trust: Observability When the System Is AI

When an AI system is running in production, someone has to be able to answer one question fast: is this healthy, and can I trust what it's doing right now? That question is deceptively hard, because the answer lives in three places that rarely talk to each other. The AI metrics say one thing, the security signals say another, and the operational health sits in a third dashboard nobody opens until something breaks.
The instinct is to put it all on one screen. The trap is that most attempts at this just crowd every available number into a wall of charts, and a wall of charts is not observability. It's noise with good production values. The person looking at it still can't tell whether to act.
This session is about the design discipline underneath a genuinely useful overview. What earns a place on the top-level view and what belongs one click down. How to show trust and reliability, not just throughput and latency, so an AI system's confidence is as visible as its uptime. How security posture and model behavior can share a surface without drowning each other out. And why the hardest work is subtraction: deciding what to leave off, so the signals that matter are the ones a human sees first.
We'll look at the difference between a dashboard that reports and one that lets someone decide. Reporting shows you what happened. A good overview tells you whether to trust it and what to do next, which is a much higher bar, and the one that matters when the system underneath is probabilistic rather than deterministic.