# Regulatory mapping — what these practices satisfy

The rest of this kit is engineering discipline. This page connects that
discipline to the obligations a regulated Australian lender actually carries, so
a risk or compliance reader can see that "verify with data" and "audit trail"
aren't nice-to-haves — they're how you meet a standard you're already held to.

This is a *generic* mapping to public obligations, not legal advice and not any
one institution's control framework. Treat it as the bridge between the kit and
your own compliance team's mapping.

## The obligations, and the kit pages that serve them

| Obligation (public) | What it asks for | Kit practice |
|---------------------|------------------|--------------|
| **APRA CPS 230** — Operational Risk Management | Identify and manage operational risk; maintain critical operations through disruption; manage material service providers | `incident-response.md` (detect/contain/correct/learn), `model-approval.md` (service-provider governance), kill-switch/fallback |
| **APRA CPS 234** — Information Security | Protect information assets; control access; manage third-party information security | `model-tiers.md` (data-class gating), `vendor-eval.md` (security posture), PII scrubbing before egress |
| **APRA CPG 235** — Managing Data Risk | Data quality and lineage appropriate to its use | `audit-trail.md` (lineage of every AI input/output), data classification at the boundary |
| **Privacy Act 1988 / Australian Privacy Principles** | Collect/use personal information lawfully; control disclosure (incl. cross-border, APP 8) | `model-tiers.md` (residency + where data may go), scrub/tokenise PII, data agreements in `model-approval.md` |
| **ASIC — responsible lending (NCCP Act)** | Lending assessments that are not unsuitable; decisions explainable | Human-in-the-loop on decisions of record (`audit-trail.md`), "estimate, not advice" framing, reconstructable reasoning |
| **APRA CPS 220 / risk culture** | Board-visible risk management; clear accountability | `model-approval.md` register with named owners, `lessons-log.md` as evidence of learning |

## The three questions a regulator actually asks

Most regulatory scrutiny of an AI-assisted process reduces to three questions.
The kit is organised to answer them:

1. **"Why did the system produce that output?"** → the audit trail reconstructs
   the inputs, model, and version.
2. **"Who is accountable for letting it?"** → the model register names an owner
   and an approval; a human approved anything of record.
3. **"How do you know it's right, and what happens when it isn't?"** → the
   verification baseline and the incident-response process.

If you can answer those three from records — not recollection — you can defend
the use of AI in a regulated process.

## How to use this with your compliance team

- Don't present this as *the* control mapping — present it as the engineering
  evidence that *feeds* their mapping. They own the obligation; you own the proof.
- Where a row is thin for your use case, that's a gap to close before scaling, not
  after.
- Keep the mapping versioned. Obligations move (CPS 230 took effect mid-2025);
  so does your stack.

## The one-line test

> For each regulated process touching AI, can you name the obligation it sits
> under and the record that proves you meet it? The mapping is done when there are
> no blanks in that sentence.