What exactly do we monitor? And how do we do it? Those were the two questions Trustible set out to answer alongside Mass General Brigham’s Amanda Centi and Melissa Bateman Fitzgerald at CHAI‘s 2026 Legal Summit.
Today, if you ask five teams what “AI monitoring” means, you’ll get likely get five different answers. Engineering thinks logs, latency, and uptime. Data science thinks drift and bias. Security thinks misuse and access control. Legal thinks IP exposure and new regulation. The business thinks cost growth and whether the thing is actually working. None of these answers is wrong, but without a shared definition, monitoring becomes five disconnected efforts instead of one.
Why AI monitoring is a challenge
Once you try to build a real monitoring practice, four issues show up fast:
- Metrics are use-case-specific. What matters for a claims assistant isn’t what matters for a code reviewer or an ambient listener. There’s no universal checklist.
- The most important signals need a human. You often can’t tell if an AI system is behaving without someone confirming the output is right or wrong. That judgment doesn’t come from an API.
- Watching one model misses the picture. A single use case can run on several models. Model-level telemetry alone never tells the whole story.
- Deployment type changes everything. Monitoring a model you host yourself is a different problem than monitoring a vendor tool you can only observe from the outside.
Govern the use case, not just the model
This is the reframe we spent the most time on. A model is a component. A use case is the thing an organization deploys, owns, and answers for. It’s the level where monitoring actually holds up.
| Monitor the model | Monitor the use case |
|---|---|
| One endpoint at a time, blind to the rest | Runs on many models or agents, tracked as one thing |
| Breaks the moment you swap or add a model | Survives vendor swaps and added agents |
| No owner, no risk profile, no obligation | Carries one owner, one risk profile, one story |
| Tells you nothing about vendor-hosted tools | Same view whether it’s self-hosted or vendor-hosted |
Anchor monitoring to the use case, and the hard problems (swapped models, mixed deployments, multi-model systems) all roll up to one place an organization can actually govern.
Internal monitoring
Internal monitoring covers what goes into and comes out of a system. It’s the set of metrics sampled over time, cost, quality, drift, safety, usage, that show whether the system is still doing its job. Most organizations already do some version of this. The harder part is knowing which numbers matter for a given use case and what to do when one crosses a line. We go deeper on the specific categories and metrics in our AI Monitoring white paper.
External monitoring
External monitoring covers signals about a system from outside its own boundary: vendor changes, public incidents, and shifting regulation. None of it shows up in your own logs, and it’s often the highest-impact trigger. A vendor can update a model or change pricing with limited disclosure. A competitor’s public failure can be a warning if you’re watching for it. Most organizations do some internal monitoring and almost none of this. Both matter. We break down the specific signals worth tracking in the same AI Monitoring white paper.
Key takeaways
- Monitoring only works when a use case, not a model, is the unit of governance.
- Internal metrics tell you if a system is still working. External signals tell you if the ground underneath it moved.
- The gap most organizations have isn’t internal monitoring. It’s the external half.