The most accurate model isn't always the right choice, and sharing everything about a system isn't always the safest choice. This lesson covers two tradeoffs the exam expects you to weigh: interpretability against predictive performance, and transparency against safety. In both, the answer depends on the use case, and AWS's guidance is to agree on the right balance with stakeholders early rather than discover it after launch.
Accuracy Versus Interpretability
As a rule of thumb, more complex models can capture more complicated patterns, so they're often more accurate on hard problems. A deep neural network may beat a decision tree at spotting fraud in messy data. But that complexity is exactly what makes it hard to explain. A simpler model, such as a linear model or a small decision tree, is easy to follow, but it may miss some patterns and give up a little accuracy.
This isn't a law of nature. On clean, structured data, a simple model is sometimes nearly as accurate as a complex one, which is why AWS recommends measuring the actual gap for your use case before assuming you have to sacrifice explainability.
How Much Explainability Does the Use Case Need
The right balance depends on what's at stake:
- High explainability: regulated decisions in lending, insurance, healthcare or hiring, where people may be entitled to reasons, and decisions that affect safety or large sums of money.
- Lower explainability: low-stakes predictions, such as which email folder a message belongs in, where accuracy matters more than reasons.
AWS's machine learning guidance lists common mistakes: treating explainability as an afterthought, picking the most complex model without checking explainability needs, and not setting explainability measures before development starts. The fix is to agree on the required level of explainability with business stakeholders at the start, then choose an interpretable model, or a complex model plus post-hoc explanations, to meet it.
Measuring Both Sides
Teams can't trade off what they don't measure. Performance has familiar metrics such as accuracy and F1. Explainability can be measured too: AWS suggests user studies that check whether people understand the explanations, whether explanations help them complete tasks correctly, and whether users can tell when to trust or question an output. Comparing both sets of results makes the tradeoff a documented decision rather than a guess.
Transparency Versus Safety
Transparency also has limits. Publishing every detail of a system can help attackers. For example, if a chatbot's full system prompt is made public, attackers learn its exact instructions and tag structure, which makes it easier to craft prompts that slip past them. AWS's prompt security guidance lists extracting the prompt template as a known attack for exactly this reason.
So responsible teams separate what people need to know from what attackers would like to know. They publish the system's purpose, limitations, the kinds of content it refuses and how to appeal a decision. They keep the exact filter settings, keyword lists and system instructions private. Open-weight models raise a similar tension: open weights allow independent inspection, but they also let anyone change the model's safety tuning.
On the Exam
- If a regulator needs reasons for each decision and a simple model's accuracy is acceptable, choose the interpretable model.
- If accuracy must stay high, keep the complex model and add explanations.
- If a question asks how to be transparent without helping attackers, the answer shares purpose, limits and risks, not internal safety settings.