Appearance
AI Applicability Rationale
Determining applicability across a newly adopted framework means writing a justification for every obligation you exclude. For a 93-clause standard with a dozen exclusions, that is a dozen pieces of careful writing.
AI can draft them. It cannot decide them.
What it does
Given an applicability record, the AI reads the requirement text and the scope context and proposes:
- Draft justification wording
- A suggested applicability status
Both are advisory. Neither is applied.
The authority boundary
| AI does | AI does not |
|---|---|
| Read the requirement and its framework context | Set the applicability status |
| Read the declared scope characteristics | Submit the decision |
| Draft justification wording | Approve anything |
| Suggest a likely determination | Make the record authoritative |
A suggested status is not a decision
The AI may suggest Not Applicable. The record stays where it is until a person sets the status, and stays non-authoritative until an independent approver approves it.
There is no path by which an AI suggestion becomes an approved applicability decision.
The permission split enforces this: generating a draft needs only compliance.read plus the AI entitlement. Recording the decision needs compliance.manage or obligations.update. Approving it needs compliance.validate or workflow.approve, and cannot be done by the person who recorded it.
What the model can and cannot know
This distinction is the whole reason the human gate exists here.
| The model can read | The model cannot know |
|---|---|
| The requirement text | Whether your organisation actually operates that business line |
| The framework and clause structure | Which entity in the group holds which licence |
| The scope name, type and purpose | What was agreed with your supervisor last year |
| Scope membership characteristics | Whether an obligation is discharged elsewhere under a different scope |
| Related requirements in the framework | Your legal counsel's view of an ambiguous provision |
An AI draft that says "the institution does not process cardholder data" is repeating a plausible pattern, not asserting a fact about you. Verifying it is the work.
Reviewing a draft
Check every factual claim. A justification is a factual assertion about your organisation. If the draft says you do not operate a trading book, confirm that with someone who would know.
Check the reasoning, not the fluency. AI drafts read well. Reading well is not the same as being right, and a fluent wrong justification is more dangerous than a clumsy correct one because it invites less scrutiny.
Add what the model could not know. The strongest justifications cite a named person, a date and a source: "Confirmed with the Head of Payments, March 2026." No model can produce that line.
Reject drafts for statutory obligations. Where a requirement is statutorily mandatory, a Not Applicable justification is expected to cite the lawful waiver or exemption relied on. That is a legal position, and it should come from someone qualified to take it.
Where a draft genuinely helps
| Situation | Why a draft helps |
|---|---|
| A clearly out-of-scope technical clause | The reasoning is mechanical; the draft saves the typing |
| A long exclusion list in one framework domain | Consistency of structure and tone across a dozen justifications |
| An analyst new to the framework | The draft surfaces what a justification should address |
| Restating a decision already made for another scope | The context is already established; the draft is a reformulation |
Where it does not
| Situation | Why |
|---|---|
| Anything jurisdictional | The model does not know which regime binds you |
| Anything depending on group structure | It does not know your legal entity map |
| Anything an assessor is likely to challenge | These need a human argument, not a generated one |
| Statutorily mandatory obligations | These need a legal position |
Permissions
| Action | Permission |
|---|---|
| Request an AI rationale draft | compliance.read plus the AI entitlement |
| Record the applicability decision | compliance.manage or obligations.update |
| Approve or reject the decision | compliance.validate or workflow.approve |
Example
Requirement: a clause on secure development environment separation.
Scope: SCP-2026-0007 — Payments Platform Production, 63 members, all production systems.
AI draft: "This requirement addresses the separation of development, testing and production environments. The declared scope comprises production systems only. Development activity does not occur within this boundary."
What the analyst changed:
"No development activity occurs within this scope. All change is delivered by the group engineering function under separate scope
SCP-2026-0009, where this clause is Applicable and addressed byCTL-2026-0052. Confirmed with the Head of Platform Engineering, 14 March 2026."
The difference: the AI draft states that development does not happen here. The analyst's version states where it does happen, that the obligation is met there, under which scope, by which control, and who confirmed it.
An assessor reading the first version asks a follow-up question. Reading the second, they do not.
Troubleshooting
"AI rationale is unavailable." Requires the AI entitlement. Manual justification is unaffected and always available.
"The draft states something untrue about our organisation." Expected, and the reason for review. Edit or discard it.
"The suggested status was applied automatically." It cannot be. Check the record — if the status changed, a person changed it.
"Drafts across a framework read identically." They will. If a dozen exclusions share one generated structure, an assessor will notice. Vary them by writing what is actually specific to each.