Model Use-Policy Compliance Evidence Pack

Prepare a compliance evidence pack for one defined AI model use. Map applicable policy requirements to the operating design and available evidence, without presenting policy interpretation as legal advice or treating a documented control as proof that it operates.

Inputs:
- Use case, users, decisions supported, deployment model, environments, and intended limitations: [Model use and operating context]
- Current internal policies, standards, approved-use rules, contractual restrictions, and jurisdiction-specific requirements supplied for review: [Applicable policies and obligations]
- Model/provider, data sources, context flow, retention, tools, outputs, integrations, and downstream actions: [Architecture data and tool flows]
- Control descriptions plus logs, tests, reviews, attestations, tickets, and other operating evidence: [Control design and operating evidence]
- Approved exceptions, incidents, violations, material changes, expiry dates, and open remediation: [Exceptions incidents and change history]
- Assessment boundary, review date, process owner, model owner, data/privacy owner, security reviewer, compliance reviewer, and approver: [Review scope and accountable roles]

Use only supplied policy text and evidence. Do not invent an obligation, approval, test result, control performance, or regulatory conclusion. Distinguish Design evidence, Operating evidence, Self-attestation, Inference, Missing evidence, and Not applicable. When requirements conflict or applicability is uncertain, identify the responsible policy or legal reviewer rather than resolving the ambiguity silently.

Method:

1. Bound the model use.
   Define what is in scope, what is excluded, who uses it, which decisions or actions it influences, and the environments and data classes involved. Identify unapproved scope expansion.

2. Build an obligation register.
   Extract each applicable policy requirement with source section, applicability rationale, required evidence, control owner, review frequency, exception path, and consequence of noncompliance. Keep mandatory obligations separate from guidance.

3. Map controls to obligations.
   For each obligation, identify preventive, detective, corrective, and governance controls. Separate control design from evidence that it operated during the assessed period. Flag controls that depend on undocumented manual practice or a vendor assertion.

4. Test evidence sufficiency.
   Assess relevance, period coverage, provenance, independence, completeness, and consistency. Identify contradictory evidence and whether samples support the population claimed. Do not extrapolate beyond the supplied period or sample.

5. Review exceptions and changes.
   Check authorization, scope, compensating controls, owner, expiry, monitoring, and closure evidence. Determine whether model, prompt, data, tool, provider, or deployment changes require reapproval.

6. Classify each obligation.
   Use Compliant with operating evidence, Compliant by design only, Partially supported, Noncompliant, Not applicable with rationale, or Not assessable. State the exact evidence and uncertainty.

7. Recommend disposition.
   Choose Continue within approved scope, Continue with named conditions, Restrict, Pause affected use, or Escalate for policy/legal determination. Use the smallest safe restriction and assign remediation evidence to accountable roles.

For every policy requirement, record acceptance evidence as a concrete expected observation and the actual observation supported by the supplied artifact. Reconcile differences explicitly; a policy document or control description is not passing evidence when operating evidence is required.

Required deliverable:

# Model Use-Policy Compliance Evidence Pack

## Assessed Use and Boundary
- Model use:
- Decisions/actions influenced:
- Data and tool boundary:
- Assessment period:
- Explicit exclusions:
- Accountable roles:

## Obligation and Evidence Matrix
| Requirement/source | Applicability | Required evidence | Control | Operating evidence | Evidence quality | Status | Owner |
|---|---|---|---|---|---|---|---|

## Exception and Change Register
| Exception/change | Approval | Scope | Compensating control | Expiry/reapproval | Evidence gap | Owner |
|---|---|---|---|---|---|---|

## Material Gaps and Contradictions
| Gap or contradiction | Affected obligation | Exposure | Smallest safe action | Evidence needed | Owner | Due condition |
|---|---|---|---|---|---|---|

## Disposition
- Decision: Continue / Conditional / Restrict / Pause / Escalate
- Approved operating scope supported by evidence:
- Unsupported or prohibited scope:
- Conditions and owners:
- Required policy/legal interpretations:
- Reassessment trigger:

## Completion Record
Completion requires every in-scope obligation to have a cited status, every exception to have an owner and expiry, material contradictions to remain visible, and the approver to distinguish demonstrated operating effectiveness from design claims.