Guidelines for Responsible AI

The features of responsible AI named in the guide: bias, fairness, inclusivity, robustness, safety, and veracity. Read them as properties you can test for rather than aspirations.

Guardrails are the enforcement mechanism, and the distinction from prompting is the point. A system prompt asking a model to avoid a topic is a preference that shifts behavior. A guardrail is a control applied to input and output independently of the model. It filters, blocks, or redacts regardless of how the model was persuaded. Anything that must not happen needs the second kind.

Responsible model selection includes environmental and sustainability considerations. Larger models cost more energy per request, which is both a cost and, increasingly, a reporting obligation.

The legal risks AWS lists are worth committing to memory because they are the ones that reach a general counsel:

• Intellectual property infringement: in training data and in generated output
• Biased output: with discrimination exposure attached
• End-user harm: from acting on wrong information
• Loss of customer trust: slower and harder to reverse than any of the above
• Hallucinations: presented as fact and relied upon

For a manager, the practical version is: assume anything the system produces may be treated as your organization's statement, because that is how a court and a customer will both read it.

Dataset characteristics decide most of this before a model is trained: inclusivity, diversity, curation, and balance. A dataset that under-represents a group will produce a model that serves that group worse, and no amount of downstream adjustment fixes it cleanly.

Bias and variance are distinct failure modes worth separating:

• High bias / underfitting: the model is too simple, misses real patterns, performs poorly everywhere
• High variance / overfitting: the model learned the training data including its noise, scores brilliantly in development and poorly in production

The business signal for overfitting is the gap between the pilot results and the live results.

Disparate impact is the fairness-specific concern, and the operationally important property is that it is invisible in aggregate accuracy. A system at 92% overall can be 96% for one group and 71% for another. You will not see it unless you look.

How you would actually detect it, which is what the exam tests:

• Subgroup analysis: measure performance separately by group. The single most important technique here.
• Label quality analysis: check whether the training labels themselves carry human bias
• Human audits: sample real outputs and review them properly
• Ongoing monitoring: because a system fair at launch can drift

The tooling exists to support each of these, but the discipline is what matters: decide which segments you will measure before you launch, because deciding afterward tends to produce the segments that look acceptable.

Transparent and explainable models let you see how an output was produced. Opaque models do not. A decision tree can be read directly; a large neural network cannot, and no amount of tooling fully closes that.

Documentation artifacts are how you make an opaque model legible enough to govern. A model card records what a model is for, what data trained it, how it performs, and, crucially, its known limitations and the conditions under which it should not be used. For a manager reviewing an AI proposal, asking for this documentation is a reasonable and revealing request: teams that have it have thought about failure.

The trade-off is real and the exam expects you to acknowledge rather than resolve it: the most accurate model for a task is frequently the least interpretable. Where explainability is a regulatory requirement (credit, employment, insurance, healthcare), that constraint can rule out the highest-scoring option, and that is a correct outcome rather than a compromise.

Human-centerd design for explainable AI turns this into interface requirements:

• Tell people when a decision was automated
• Give a reason in language the affected person understands, not a feature-importance chart
• Provide a route to challenge or appeal
• Capture feedback and actually use it

The test of whether explainability has been designed in: can the person affected by a decision find out why, and do something about it? If not, you have documentation rather than explainability.