AI Evaluation Framework: A Risk Matrix Beyond Hallucination and Bias

By Amin Rabinia · Founder, Glissando AI

Ask most founders what could go wrong with their AI feature and you'll get one of two answers: "it might make something up" or "it might say something biased." Both are real risks. Neither is close to the whole list. An AI output has far more ways to fail than the two everyone already knows to worry about — and the ones nobody checks for are the ones that show up in front of a customer.

We see this gap constantly with clients. They arrive with one or two risks already in mind — usually the two above — and no structured way to find the rest. That's not a knowledge problem. It's a structure problem. Without a framework, a team can only check for the risks it has already imagined. Everything else stays invisible until it breaks in production.

Hallucination and Bias Are Two Rows of a Bigger Table

Hallucination and bias get all the attention because they're the easiest risks to name and the ones written up most often. That makes them the default answer, and the default answer feels like coverage. It isn't. A team that has checked for hallucination and bias has covered maybe two of twenty-plus dimensions that can actually apply to a given AI feature — and walked away feeling done.

It's the same blind spot that makes a demo look finished in a screenshot and then break the moment real data arrives: the failure modes that matter were never on the list of things being checked for, so nothing flagged them until a real user did.

The Real Structure: Use Cases Crossed With Failure Dimensions

The fix isn't a longer checklist. A longer list of risks is still a list — you either happen to think of the right ones or you don't. The fix is a matrix: every real use case your AI touches, crossed with every dimension that can fail for that use case. A support chatbot and a document parser get evaluated against the same six dimensions, but which of those dimensions actually matter, and how strictly, is different for each.

We use six branches to cover the full surface of what can go wrong with an AI output, each one built around a distinct question a risk or compliance-minded reviewer would actually ask:

• Safety & Policy Compliance — could it cause harm, or break a rule?
• Output Quality — does it say what it should?
• Robustness & Reliability — does it hold up under edge cases and pressure?
• Transparency & Calibration — can you explain what it did, and how confident should you be?
• Integrity — can a downstream system or person actually rely on the structure of what it produced?
• Efficiency & Cost — at what latency and cost?

Those six branches spell SORTIE — Safety, Output Quality, Robustness, Transparency, Integrity, Efficiency — which is also a fair description of running one: a targeted pass over the whole system, not a scan for the one risk you already suspect.

Where This Came From: Building One for a Real Client

We designed SORTIE on an engagement for a client building an AI governance and compliance platform — confidential, so it stays unnamed here. They already had real infrastructure in production: monitoring dashboards, audit logs, evaluator prototypes. What they didn't have was a principled way to say what actually needed to be measured, for which use case, and why. Evaluators were named and categorized inconsistently, with no structure connecting them.

The irony wasn't lost on anyone: a company built to help other businesses govern their AI had the same gap internally. The biggest problem clients have in this position isn't a lack of tools — it's that without a taxonomy, they only ever see part of the risk picture. They think of the one or two risks they can already imagine, when the real surface is a full matrix of use cases against failure dimensions. We wrote up the full build, including the matrix diagram, in the SORTIE evaluator taxonomy case study.

A Taxonomy Alone Doesn't Tell You What to Run

Knowing that six branches of risk exist doesn't tell you which evaluators to actually run, in what order, or how to measure them without it costing a fortune. That needs a registry: for every evaluator, a specific answer to how it gets measured — a deterministic check that runs on every single output for free, or an expensive judgment call reserved for the cases that actually need one.

That distinction is where most teams overspend without noticing. The default is to reach for an expensive AI-judged evaluation for something that could have been a simple, free, deterministic check — did the output parse as valid JSON, is the number inside the expected range, is the required field present. Getting that split right is often the single biggest lever on what an evaluation system costs to run.

Making It Usable: Scenario Cards

A taxonomy and a registry are still reference material until you connect them to real use cases. The last piece is a scenario card for each one — a support chatbot, a document parser, a Q&A assistant, a content summarizer — specifying exactly which evaluators are required, which are recommended, and which only apply conditionally.

That mapping is what turns "what do we need to check for this AI feature" from a one-off decision your team improvises every time, into a repeatable process you reuse the next time you add a use case. It's the same instinct behind deciding how many agents a product actually needs: name the structure once, and every future decision gets faster instead of starting from a blank page.

You Don't Need a Governance Platform to Need This

This pattern isn't only relevant to enterprise compliance platforms. Any team launching one AI feature is implicitly making a bet about what could go wrong, whether they've written it down or not. The matrix — real use cases crossed with the dimensions that actually matter for each — is the same tool whether you're a two-person startup evaluating one chatbot or a platform monitoring AI for dozens of enterprise customers. The size of the matrix changes. The need for one doesn't.

This is also one of the places a proof of concept quietly turns into a liability on its way to production. A prototype works because a person is standing next to it, picking good inputs and shrugging off the rough edges. Nobody does that once it's live. Turning a GenAI proof of concept into something production-ready means answering, in writing, what "correct" means for each use case — which is exactly what a risk matrix forces you to do before a customer finds the gap for you.

Building Your Own Matrix This Week

You don't need a consultant to start this. You need an hour and a whiteboard.

1. List every real use case your AI touches — not "the chatbot" as one line, but each distinct job it does: answering pricing questions, summarizing a document, routing a request.
2. Cross each use case against the six SORTIE branches. For each one, ask plainly: does this dimension apply here, and how badly does it hurt if it fails?
3. For every cell that applies, decide cheap or expensive. Can this be a deterministic check that runs every time for free, or does it need a judgment call reserved for higher-stakes cases?
4. Turn it into a card you reuse. The next time you add a use case, you're filling in a known structure — not starting the whole conversation over.

We go deeper on the measurement side of this in building an AI evaluation strategy — how to define and measure whether an AI system is actually working, not just running.

If you're evaluating a vendor proposal or reviewing your own team's plan for an AI feature, ask to see the matrix, not just the demo. If nobody can show you which use cases were crossed against which risks, that's the gap this whole framework exists to close. Our list of questions to ask an AI consultant before hiring them covers the rest of that conversation.

Get Expert Input if you want a second opinion on what your own AI feature's risk matrix should actually cover.

Related reading

• Building an AI Evaluation Strategy
• Why Does My AI Demo Break With Real Data?
• How Do You Productionalize a GenAI Proof of Concept?
• How Many AI Agents Does Your Product Actually Need?

This post is part of the AI Strategy Guide.