Build a Runtime AI-Policy Compliance Brief: Paste Your Enterprise AI Use Policy, Get a Gap Analysis and Enforcement Checklist

The task

You're a consultant advising an enterprise client on their AI governance program. The client hands you their existing AI Use Policy (usually a Word doc the GC drafted eight months ago) and asks the real question: can we actually enforce this? You need to turn the policy into a gap analysis and a runtime enforcement checklist — fast, before the steering committee meeting.

Before AI

Today this is a highlighter-and-spreadsheet job. You read the policy twice, map each clause to a control category (data classification, PII handling, model allow-list, prompt logging), check which clauses are aspirational vs. technically enforceable, then draft a memo recommending which controls go in the DLP tool, which go in the AI gateway, and which stay as training-only. Usually 4-6 hours per policy, and you still miss things on the first pass.

The timing matters: vendors like Archer are now pitching clients on the exact gap you're trying to close. Archer's new Evolv AI Compliance release argues the market mostly ships policy repositories or guardrails, rarely the connection between them — and that regulation and company policy should become native Amazon Bedrock Guardrails, enforced on every prompt from employees or agents before the model responds, with every control traced to the obligation behind it. Whether or not your client buys that specific product, the question "which of our policy clauses are actually enforceable at runtime?" is now on every CIO's desk.

The workflow

1. Paste the policy and get a clause-by-clause gap analysis

The first prompt does the heavy lifting: it extracts every enforceable obligation from the policy text, classifies each by control type, and flags clauses that are aspirational (no runtime hook possible). Append the client policy to the end of this prompt.

You are a senior AI governance consultant preparing a runtime compliance brief for an enterprise client. Below is the client's current AI Use Policy.

Produce a GAP ANALYSIS TABLE in markdown with these columns:

| Clause ID | Policy text (short quote) | Obligation type | Runtime-enforceable? | Enforcement surface | Gap notes |

Rules:
- One row per discrete obligation. If a paragraph contains three obligations, make three rows.
- Obligation type: pick one of {Data classification, PII/PHI handling, Model allow-list, Prompt/output logging, Human review, Vendor/third-party, Training/awareness, Disclosure, IP/confidentiality, Other}.
- Runtime-enforceable: Yes / Partial / No. "Yes" means a guardrail at inference time can block or redact. "Partial" means detection is possible but prevention needs human workflow. "No" means it's training or culture only — be honest about this.
- Enforcement surface: the specific layer where it would live — e.g. "AI gateway input filter", "Bedrock Guardrail — denied topics", "DLP egress scan", "IAM policy on model endpoint", "SIEM log rule", "Procurement checklist", "Mandatory training module".
- Gap notes: in one sentence, what's missing or ambiguous in the current wording that would stop an engineer from implementing it.

After the table, add a short section titled "TOP 5 ENFORCEMENT GAPS" ranked by risk, each with a one-line fix recommendation.

Do not invent policy content. If a topic (e.g. agent autonomy, model fine-tuning) is absent from the policy, say so explicitly in the TOP 5 section rather than fabricating a clause.

CLIENT POLICY:

NORTHWIND MUTUAL — ACCEPTABLE USE OF GENERATIVE AI (v1.3, approved March 2026)

1. Purpose. Northwind Mutual ("the Company") permits employees and contractors to use approved generative AI tools to improve productivity, subject to the controls in this policy.

2. Approved tools. Employees may use (a) the Company's internal "NorthwindGPT" assistant, (b) Microsoft Copilot for M365 under the Enterprise license, and (c) any tool pre-approved by the AI Review Board. Use of consumer ChatGPT, Claude.ai, Gemini consumer, or any other non-approved public tool for Company business is prohibited.

3. Data handling.
   3.1 Employees must not submit customer PII, policyholder claims data, underwriting files, or any information classified "Confidential" or "Restricted" into any generative AI tool, approved or otherwise, unless the tool is specifically certified for that data class.
   3.2 Protected Health Information (PHI) may only be processed through tools covered by an executed Business Associate Agreement.
   3.3 Source code from the Company's core policy administration system shall not be pasted into any AI tool.

4. Output review. All AI-generated content used in customer-facing communications, regulatory filings, or legal documents must be reviewed and approved by a qualified human before release. The reviewer is accountable for accuracy.

5. Disclosure. Where AI materially contributed to a customer deliverable, the customer shall be informed in accordance with applicable state insurance disclosure rules.

6. Prohibited uses. Employees shall not use AI tools to make final adverse underwriting or claims decisions, to generate content intended to deceive, or to circumvent any Company control.

7. Training. All employees with AI tool access must complete the annual "Responsible AI at Northwind" training module.

8. Monitoring. The Company reserves the right to log and review prompts and outputs submitted to approved tools.

9. Violations. Policy violations may result in disciplinary action up to and including termination.

2. Convert the gap analysis into an enforcement checklist mapped to concrete controls

Now turn the analysis into something an implementation team can actually use. This prompt runs on the previous step's output.

Using the gap analysis table you just produced, generate a RUNTIME ENFORCEMENT CHECKLIST organized by enforcement surface.

Format: markdown with one H3 per surface, and under each surface a checklist of specific controls in this form:

- [ ] **Control name** — one-sentence description. *Policy clause:* [Clause ID from prior table]. *Implementation hint:* one concrete sentence a platform engineer could act on (name the config, the field, or the rule type — e.g. "Bedrock Guardrail denied-topics entry for 'policyholder claims data'", "Microsoft Purview sensitivity label 'Restricted' blocked on Copilot prompt submission", "Okta group gating NorthwindGPT access to users who have completed training module code RAI-2026").

Group under these H3 headings in this order, omitting any that have no controls:
1. AI gateway / inference-time guardrails
2. Data loss prevention (DLP) and sensitivity labels
3. Identity and access (IAM / SSO / entitlements)
4. Logging, monitoring, and SIEM
5. Human workflow (review queues, approvals)
6. Procurement and vendor onboarding
7. Training and attestation

After the checklist, add a section titled "NOT RUNTIME-ENFORCEABLE — HANDLE OUT OF BAND" listing clauses from the gap analysis marked "No", with the mitigation route for each (training content update, manager attestation, audit sampling, etc.).

Keep every control traceable: every checklist item must cite a Clause ID. Do not add controls that have no basis in the policy text.

3. Draft the client-facing executive summary

Finally, package it for the steering committee. One page, no jargon dumps.

Draft a one-page EXECUTIVE SUMMARY for the client's AI governance steering committee, based on the gap analysis and enforcement checklist above.

Structure:

**Headline finding** (2 sentences): what proportion of the policy is runtime-enforceable today vs. requires workflow or training, and the single biggest enforcement gap.

**What we can turn on in 30 days** (bulleted, max 5 items): controls from the checklist that map to existing enterprise tooling (AI gateway, DLP, IAM, SIEM) and need configuration rather than new procurement.

**What needs a policy rewrite before it can be enforced** (bulleted, max 4 items): clauses whose wording is too vague for a guardrail (e.g. "qualified human", "materially contributed") — quote the ambiguous phrase and propose a tighter version in one sentence.

**What stays as training and attestation** (bulleted, max 3 items): obligations that are genuinely cultural, not technical.

**Recommended next step**: one sentence. Pick the single highest-leverage action.

Tone: direct, board-ready, no vendor name-dropping, no hype language. Do not recommend specific products. Do not use the words "leverage", "robust", or "cutting-edge".

Gotchas

• Vague verbs break guardrails. Phrases like "materially contributed", "qualified reviewer", or "sensitive data" sail through legal review but can't be turned into a rule. If step 1 marks a lot of clauses as "Partial," that's usually why — flag it in the policy rewrite section rather than pretending a guardrail exists.
• The model will try to invent controls for topics the policy doesn't cover. Agent autonomy, fine-tuning, model-to-model calls, and third-party AI inside SaaS tools are commonly absent from v1 policies. The step 1 prompt tells the model to call out gaps rather than fabricate — spot-check that it actually did.
• "Runtime-enforceable" depends on your client's stack. A control that's trivial on Bedrock may be impossible on a vanilla OpenAI API with no gateway in front. Before you send the brief, do a 10-minute pass to downgrade any "Yes" rows where the client lacks the enforcement surface.
• Vendor framing creeps in. If your client is already in a sales cycle with a governance vendor, the model may mirror that vendor's language if you paste in their marketing. Keep the input to the policy text only.
• PII in the policy itself. Rare, but policies sometimes include named reviewers or system names you don't want in a model's context. Scrub before pasting.

Time saved

Manual baseline for a 2-5 page AI use policy is 4-6 hours: close read, clause mapping, control category assignment, and the executive write-up. This workflow compresses the mechanical parts (extraction, classification, checklist drafting) into about 20 minutes of prompting plus 30-45 minutes of consultant review and client-specific tailoring. Call it 4-6 hours saved per policy review, with the honest caveat that the review step is non-negotiable — the model is a strong first-pass associate, not a signoff.

What we got when we ran it

We executed every prompt above, in order, against the sample input (model: claude-sonnet-4-6). Outputs below are real and unedited apart from length truncation.

Step 1 output

# GAP ANALYSIS TABLE — Northwind Mutual AI Acceptable Use Policy v1.3 | Clause ID | Policy text (short quote) | Obligation type | Runtime-enforceable? | Enforcement surface | Gap notes | |-----------|--------------------------|-----------------|----------------------|--------------------|-----------| | 2.a | "Employees may use…NorthwindGPT" | Model allow-list | Yes | IAM policy on model endpoint; AI gateway allow-list | Policy names approved tools but provides no machine-readable tool registry or version-pinning; an engineer cannot determine which API endpoints or model versions are in scope. | | 2.b | "Microsoft Copilot for M365 under the Enterprise license" | Model allow-list | Partial | M365 Tenant Conditional Access policy; Purview data-loss-prevention rule | No control specified for Copilot plugins or third-party extensions within Copilot, which expand the attack surface beyond the base model. | | 2.c | "any tool pre-approved by the AI Review Board" | Model allow-list | No | Procurement checklist; AI Review Board workflow | No time-bound approval cadence, revocation process, or published registry defined; engineers cannot build an automated allow-list without a canonical source of truth. | | 2 (prohibition) | "Use of consumer ChatGPT, Claude.ai…is prohibited" | Model allow-list | Partial | DNS/proxy block-list; browser isolation policy; DLP egress scan for known AI endpoint domains | Prohibited endpoints are listed by name at policy-write time but the list will become stale; no process defined for updating the block-list as new consumer tools emerge. | | 3.1 | "must not submit customer PII…unless the tool is specifically certified for that data class" |

…output truncated at 250 words.

Step 2 output

# Runtime Enforcement Checklist — Northwind Mutual AI Acceptable Use Policy v1.3 > How to use this checklist: Each item maps to a discrete policy obligation identified in the gap analysis. Assign a DRI (Directly Responsible Individual) per section. Target state: all boxes checked before any approved AI tool is promoted to production. --- ### 1. AI Gateway / Inference-Time Guardrails - [ ] Tool allow-list enforcement — Block any prompt submission destined for an endpoint not present in the approved tool registry. Policy clause: 2.a, 2.b, 2.c. Implementation hint: In your AI gateway (e.g., AWS AI Gateway, Azure API Management, or Kong), define a route allowlist table keyed on destination_endpoint_url; return HTTP 403 with policy reference code NW-AUP-2 for any unregistered host. - [ ] Consumer AI domain block — default-deny egress — Reject outbound prompt traffic to any AI provider endpoint not on the approved allow-list, covering known consumer domains and future unlisted ones. Policy clause: 2 (prohibition). Implementation hint: Configure the AI gateway upstream block-list with explicit deny entries for chat.openai.com, claude.ai, gemini.google.com, and *.ai wildcard catch-all routed to a CASB inspection queue; pair with a proxy PAC file enforcing the same deny. - [ ] PII entity detection — input filter — Detect and block prompts containing customer PII (names, policy numbers, SSNs, dates of birth, contact details) before they reach any AI model endpoint. Policy clause: 3.1. Implementation hint: Enable the Bedrock Guardrail sensitive-information filter with entity types NAME, EMAIL, PHONE, SSN, US_INDIVIDUAL_TAX_IDENTIFICATION_NUMBER; set action

…output truncated at 250 words.

Step 3 output

# Executive Summary: AI Policy Runtime Enforcement Assessment Northwind Mutual — AI Governance Steering Committee | Prepared by: AI Governance Practice For steering committee review — not for external distribution --- HEADLINE FINDING Of the nineteen discrete obligations in AI Acceptable Use Policy v1.3, eight (42%) can be enforced in real time at the inference layer using tooling the Company already operates; seven (37%) are partially detectable but require human workflow to prevent — not just flag — a violation; and four (21%) are entirely unenforceable at runtime and depend on training and culture alone. The single largest enforcement gap is the absence of a machine-queryable tool certification registry: without it, the policy's central data-handling controls — governing PII, PHI, and classified content — cannot be applied conditionally at inference time and are effectively unenforceable in production. --- WHAT WE CAN TURN ON IN 30 DAYS These controls require configuration of existing enterprise tooling, not new procurement or policy amendment: - PII and PHI input blocking — Activate sensitive-entity detection in the existing AI gateway to block prompts containing customer PII and health information before they reach any model endpoint; PHI blocking should be conditional on BAA status once the registry (see below) is in place. - Consumer AI domain blocking — Configure the existing web proxy and AI gateway to deny all outbound prompt traffic to non-allowlisted AI endpoints by default, replacing the current named-tool prohibition with a default-deny posture. - Sensitivity-label enforcement on AI submissions — Enable the

…output truncated at 250 words.