What it means
- When AI helps make or shape a decision about a person (loan approval, credit limit, fraud block, claim rejection, job shortlist), you can tell that person, in plain words:
- that AI was involved,
- the main factors that drove the outcome,
- what they can do next (provide more information, ask for human review, complain).
- Internally, staff can reconstruct why the system produced a given output for a given case.
- ISO 27001 reuse: None. New for AI, not covered by ISO 27001.
Why it matters
- RBI FREE-AI asks for a board-approved consumer protection framework built on transparency, fairness and recourse; customers cannot seek recourse for a decision nobody can explain.
- Existing RBI rules already require reasons for loan rejection; AI does not remove that duty.
- Explanations support audits, disputes and litigation, and expose bias early.
Checklist
- List decisions in the inventory that affect individuals and tag where AI is involved (SC-AI-003 AI system inventory).
- For each, define the explanation level: customer-facing reason codes, and an internal technical explanation (feature importance, retrieved sources, rules fired).
- Choose explainability methods suited to the model (reason codes, SHAP or similar for tabular models; cited sources for retrieval-based LLMs).
- Write plain-language reason templates; test them with non-technical staff for clarity.
- Store the inputs, model version and explanation with each decision (SC-AI-032 Logging and record keeping).
- Link the explanation to the next step: human review or complaint channel (SC-AI-027 Right to contest and human review for individuals, SC-AI-028 Customer grievance redressal for AI).
- Train front-line and grievance staff to read and relay explanations.
- Check explanations during validation that they match real model behaviour (SC-AI-015 Pre-deployment testing and validation).
Evidence examples
- Reason code catalogue with plain-language text.
- Sample adverse action or rejection letters showing AI disclosure and reasons.
- Model documentation describing the explainability method (SC-AI-014 Model documentation (model cards, system cards)).
- Decision log entries containing input snapshot, model version and explanation.
- Training records for customer service and grievance teams.
Common pitfalls
- Generic reasons ("did not meet our criteria") that tell the customer nothing.
- Explanations generated from a different model version than the one that decided.
- Black-box vendor scores bought without any right to an explanation in the contract (SC-AI-007 Third-party and vendor AI due diligence).
- Exposing so much detail that fraudsters learn to game the model; balance is needed.
Satisfies
- BindingEU AI Act
- BindingNYC Local Law 144 (AEDT)
- BindingKorea AI Basic Act
- SupervisoryOSFI E-23
- VoluntaryRBI FREE-AI
Also relevant to
- Tamil Nadu Safe and Ethical AI Policyguidance mapping (audit trail of decisions; no obligation IDs)
- AI (Ethics and Accountability) Bill 2025guidance mapping (pending bill; no obligation IDs)
Standards crosswalk
Clause references only. Check the standard itself for the exact wording.
ISO/IEC 42001
- A.6.2.7 technical documentation
- A.8.2 system documentation and information for users
- A.8.5 information for interested parties
ISO/IEC 27001
No direct equivalent
SOC 2
- CC2.3
Key takeaways
- If AI shapes a decision about a person, be able to explain the main reasons in plain words.
- Store the explanation with the decision, tied to the exact model version.
- An explanation is only useful if it points to a next step: review or complaint.