# How to interpret AIRUM output

AIRUM is a pre-discovery preparation aid. It helps an auditor start with better AI risk assumptions, expected controls, and challenge questions before discovery. It does not replace audit judgment, legal/compliance review, specialist review, or engagement-specific workpaper tailoring.

## What AIRUM can support

- Broader first-pass AI risk discovery preparation.
- More explicit risk-selection assumptions.
- Expected-control conversations before fieldwork starts.
- Disclosure-safe source labels and source families for public-demo explanation.
- Internal AIRUM provenance support where the private working version retains source notes, locators, and rationale.

## What AIRUM cannot conclude

- It does not decide final audit scope.
- It does not assess control effectiveness or residual risk.
- It does not provide legal advice or legally validated conclusions.
- It does not provide audit assurance.
- It is not source-perfect public validation of every source and control rationale.
- It is not final audit workpaper material without engagement-specific tailoring.

## How to challenge an AIRUM output

For each candidate risk or control, ask:

1. Why did this risk appear?
2. Which audit-context assumption caused it?
3. What evidence would remove it?
4. What evidence would escalate it?
5. Which control owner, system owner, data owner, vendor owner, or specialist should review it?
6. Does a legal/regulatory reference only indicate regulatory relevance, or does it require legal/compliance review?
7. Which disclosure-safe source family supports the expected-control conversation?

## Evidence still needed before audit scoping

Before treating an AIRUM topic as in-scope, confirm actual AI use, system/process boundaries, data flows, third-party dependencies, lifecycle stage, governance ownership, control design, population completeness, incidents/exceptions, and management's risk acceptance or remediation position.

## Legal and regulatory references

Treat legal/regulatory references as risk prompts. Use language such as regulatory relevance, potential obligation area, compliance prompt, or legal/compliance review needed. Do not describe public-demo output as legally mapped, legally validated, or proof of compliance.

## Public versus internal provenance

The internal AIRUM working version may retain source notes, licensed-source locators, local vault paths, and detailed source-to-control rationale where appropriate. The public demo does not publish those details. Public surfaces should use disclosure-safe source labels, source families, and reduced summaries only.