Enter for every AI system. Some of its controls apply only where it decides about people (B2). Go as deep as your system letter, and implement in your mode.
Why it exists
Match the explanation you can give to what is at stake. A tool that suggests a phrasing needs almost none; a system that influences whether someone gets a loan, a job, a diagnosis, or a benefit needs a great deal, because a person’s life turns on it and they have a right to know why. Decide the required level of explanation for each use case at design time, driven by the stakes and by whether the output affects a person, and let that decision govern how much of the rest of this domain applies. Deciding this late — after building a system you then discover you cannot explain — is how organisations end up unable to defend decisions they have already made.
What to actually do
Set the explanation requirement from the stakes, before you build. Classify each use case by how much explanation it will owe: minimal for low-stakes assistance, full and person-facing for decisions that materially affect someone. Do this before selecting or building the system, because some designs cannot be made explainable after the fact, and discovering that after launch is discovering it too late.
Treat a decision about a person as the high bar by default. Wherever AI decides or materially shapes a decision about an individual — their money, work, health, rights, or access to a service — assume the highest explanation requirement unless you have a specific reason to lower it. This is where the legal and reputational exposure concentrates, and where an unexplainable system is least defensible.
Controls
Baseline1 controls
Control 161
Classify each use case by its required level of explanation, at design time.