Appearance
AI Mapping Suggestions
Mapping an obligation to the right control means reading it against several hundred control descriptions. AI can shorten the search. It cannot make the decision.
Two distinct capabilities
1. Control discovery — retrieval only
Discovery retrieves a ranked list of control candidates for an obligation from your tenant's control index.
It creates nothing. It is a search that understands meaning rather than keywords, so an obligation about "restricting elevated permissions" surfaces a control titled "Privileged Access Management" even with no shared vocabulary.
Requires mapping.discover. The index is built with control.index.
2. AI mapping proposal — creates proposals
An AI comparison pass reads an obligation against candidate controls and persists mapping records in proposed status, with a suggested relationship type, a rationale and a confidence value.
Requires mapping.ai_propose and the AI entitlement.
The authority boundary
AI proposes. Humans authorise.
AI-generated mappings:
- Always enter as
proposed— the system offers no path for an AI pass to write anapprovedmapping - Require human review and maker-checker approval through
mapping.review - Carry complete provenance: AI provider, model, prompt version and confidence
- Are never permitted to auto-approve or auto-link
The permission split enforces it. mapping.ai_propose grants the ability to generate proposals. It does not grant mapping.review. Holding the first without the second means you can generate a thousand suggestions and approve none of them.
What the AI sees
An AI proposal pass is given the obligation text, its framework context, and the candidate controls retrieved from your tenant's control index. It compares them and reports where it believes a relationship exists.
Everything it reads stays within your tenant. See Tenant Data Boundaries.
Provenance
Every AI-suggested mapping records:
| Field | Purpose |
|---|---|
| Mapping source | ai_suggested |
| AI provider | Which provider produced it |
| AI model | Which model |
| Prompt version | Which prompt generated it |
| AI confidence | The model's assessed confidence |
| Rationale | The model's stated reason |
This is not decoration. Two years later, when someone asks how a mapping came to exist, the answer is a record rather than a recollection. It also means that if a model version turns out to have produced poor mappings, you can identify every mapping it produced.
How good are the suggestions?
Realistically:
| Suggestion quality | Typical pattern |
|---|---|
| Strong | Obligations with clear technical vocabulary — encryption, authentication, logging, backup |
| Mixed | Obligations about governance, oversight or accountability, where the right control is organisational rather than technical |
| Weak | Obligations that depend on jurisdiction-specific definitions, or on facts about your organisation the model has no way to know |
The most common AI error is over-claiming the relationship type: proposing equivalent where the honest relationship is subset. This is the single thing to scrutinise on review.
The second most common is confident mapping to a plausible-sounding control that your organisation does not actually operate as described.
Reviewing AI proposals
Read the control, not the rationale. The AI rationale explains what the model thought. Your judgement should rest on the control description itself.
Interrogate every equivalent. Ask: if this control operates perfectly, is the obligation entirely discharged? If not, adjust to subset or intersection.
Record no_match for confident wrong answers. This prevents the same suggestion resurfacing on the next run and documents that the question was considered.
Treat confidence as triage, not evidence. High confidence means the model found strong textual similarity. Textual similarity is not organisational truth.
Do not batch-approve by confidence threshold. Approving everything above a confidence score reproduces exactly the problem maker-checker exists to prevent.
Where AI mapping fits
Note that the only path from the AI to an approved mapping runs through a person who is not the person who triggered the AI.
Related AI capabilities in this domain
| Capability | What it does | Permission |
|---|---|---|
| Design adequacy check | Produces a draft recommendation on whether an approved mapping is adequate by design | adequacy.run plus AI entitlement |
| AI-suggested expected evidence | Generates recommended expected-evidence requirements for a control | expected_evidence.ai_suggest plus AI entitlement |
Both follow the same pattern: the AI drafts, a human accepts or rejects, and the acceptance permission is separate from the generation permission.
See Design Adequacy and Expected Evidence & Freshness.
Permissions
| Action | Permission |
|---|---|
| Build or refresh the control discovery index | control.index |
| Retrieve ranked control candidates | mapping.discover |
| Run the AI comparison and persist proposals | mapping.ai_propose plus ai_risk_intelligence |
| Approve or adjust a proposal | mapping.review |
Example
A bank adopts a new framework with 210 requirements. Its control register holds 287 organisational controls.
The Compliance Analyst builds the control index, then runs AI proposal against the 81 requirements determined Applicable.
Result: 214 proposed mappings across 81 obligations.
Review by the Compliance Manager:
| Outcome | Count |
|---|---|
| Approved as proposed | 78 |
Adjusted then approved — mostly equivalent to subset | 61 |
| Rejected | 44 |
Recorded as no_match | 31 |
Obligations left with no mapping after review: 14. Each becomes a finding — these are the genuine control gaps the exercise was for.
Twelve days of analyst work replaced by two days of generation and four days of review, and the residual 14 gaps are real rather than hidden behind optimistic mappings.
Troubleshooting
"AI proposal is unavailable." Requires mapping.ai_propose and the AI entitlement. Discovery alone requires only mapping.discover.
"Discovery returns nothing." The control index has not been built or is stale. Rebuild it with control.index.
"The same wrong suggestion keeps reappearing." Record it as no_match rather than rejecting it. A rejection closes one proposal; a no_match records a conclusion.
"Suggestions are poor across the board." Usually control descriptions are too thin. A control described as "Access is managed appropriately" gives a model nothing to match against. See the writing guidance in Control Register.