Policy & Compliance (PC)

Vendors Domain - HAIAMM v3.0

Practice Overview

Objective: Publish the priority policies and compliance map that make a Vendor AI Assurance program enforceable, so adoption of AI/HAI tools from vendors is gated, attributable, and defensible to auditors, regulators, and customers. Shadow AI prevention is the primary L1 outcome.

Description: PC-Vendors codifies three priority policies (AI Acceptable Use, AI Procurement & Intake, Data-sharing with AI vendors) and maps them to the compliance regimes that now explicitly apply to AI vendors: EU AI Act deployer duties (Art. 26), NIST AI RMF GOVERN, GDPR Art. 28 for AI processors, SOC 2 CC9.2 vendor management, and ISO/IEC 42001 AI management systems. At L1 the goal is not exhaustive control coverage, it is the minimum set of policies and compliance mappings needed to stop unsanctioned AI vendors from silently entering the environment.

Context: Most organizations already have a generic Acceptable Use Policy and a vendor-risk process, neither answers the specific questions an AI vendor raises (Can the vendor train on our data? Where does inference happen? What is the subprocessor chain? Does the "AI feature" inside an existing SaaS trigger a new DPA or AI-specific addendum?). Without AI-specific policies and an explicit compliance map, shadow AI grows unchecked and the organization cannot demonstrate deployer duties under the EU AI Act or processor due diligence under GDPR.

Maturity Level 1

Objective: Publish the three priority AI vendor policies, map them to priority compliance requirements, and gate new AI vendor adoption through a lightweight intake

At this level, the organization ships the minimum viable policy stack for AI vendor governance, maps each policy to the regulations and standards that make it enforceable, and implements a single procurement gate that no AI vendor can bypass.

Dependencies

• SM-Vendors L1 (required): policies are only enforceable if the AI vendor inventory exists, the program has an executive sponsor, and scope is defined.
• Alignment (not a hard dependency): enterprise Legal/Privacy function for DPA/contracting, enterprise AUP (to extend with AI-specific clauses rather than duplicate), and Procurement tooling for the intake gate integration.
• Supports / unblocks: EG-Vendors L1 (training needs published policies as the teaching object), SR-Vendors L1 (requirements inherit policy guardrails), IR-Vendors L1 (reviews check against policy rules), IM-Vendors L1 (exception and violation handling flows from policy).

Desired Outcomes

• Three short, AI-specific policies exist, are approved by Legal/Privacy + Security, and are discoverable by every employee who adopts tools.
• A one-page priority compliance map lets auditors and customers trace each regulatory requirement (EU AI Act Art. 26/50, NIST AI RMF GOVERN, GDPR Art. 28/22/44–49, SOC 2 CC9.2, ISO/IEC 42001, ISO/IEC 27001 A.5.19–A.5.23, sector-specific) to the single policy that carries it.
• No AI vendor reaches production without passing the intake gate; "AI-feature-inside-already-approved-SaaS" is explicitly in scope for the gate.
• Every AI vendor receiving non-public data has an executed DPA / AI addendum on file with an auditable subprocessor list.
• Previously undisclosed shadow AI surfaces for retroactive intake via an amnesty path rather than going deeper underground.
• The program demonstrates deployer duties under the EU AI Act with a documented chain from policy → intake → logging attestation → named human oversight.

Activities

A) Publish the three priority AI vendor policies

Ship these three policies in their smallest useful form, short, readable, enforceable. Each one is a distinct lever and each one must exist at L1.

1. AI Acceptable Use Policy (AUP), what employees may and may not do with AI vendors: - Approved AI vendors list (the sanctioned tools from the SM-Vendors inventory) - Data classes prohibited from any AI vendor (regulated data, source code if applicable, customer PII without DPA, third-party confidential info under NDA) - Personal-account prohibition, no organizational work in personal ChatGPT / Claude / Gemini accounts - Output review duty, AI outputs are treated as suggestions, not authoritative decisions, in scopes defined by role - Disclosure obligation, employees must disclose AI use where it affects decisions, code, or customer-facing output - Attestation required at hire and annually; violations routed through normal HR channels

2. AI Procurement & Intake Policy, how AI vendors enter the environment: - No AI tool may be paid for, installed, integrated, or enabled without an intake ticket - "AI-embedded features" in already-approved SaaS require a separate intake (Notion AI, Slack AI, Zoom AI Companion, M365 Copilot, Gemini in Workspace, etc.) - Intake produces: risk tier assignment, DPA / AI addendum confirmation, AUP-aligned data-handling decision, business owner and renewal date - Intake SLA published (e.g., 5 business days for triage; fast-track path for already-approved parent vendors) - Exception / amnesty path for already-in-use shadow AI, disclose without penalty, retroactive intake

3. AI Vendor Data-Sharing Policy, what data may flow to AI vendors and under what contract terms: - Default training-on-customer-data posture = off; vendor must support opt-out or contractual no-train commitment - DPA / AI addendum mandatory for any AI vendor receiving non-public data; subprocessor disclosure required - Data residency and cross-border transfer requirements (GDPR SCCs / UK IDTA where applicable) - Retention and deletion terms explicit (prompt/completion logs, fine-tuning artifacts, embeddings) - Incident notification SLA from vendor (typically ≤72 hours)

B) Map the three policies to the priority AI vendor compliance requirements

Build a short, one-page compliance map. At L1 you do not need coverage of every regulation, you need these mapped, because they are the ones auditors, regulators, and customers are already asking about for AI vendors.

This table becomes the program's "one-page compliance map." It tells an auditor in 60 seconds which policy answers which requirement.

C) Operate the intake gate and track foundational compliance outcomes

Policies that nobody enforces don't prevent shadow AI. L1 closes the loop by putting the policies behind a single, visible gate and measuring whether the gate actually catches adoption.

Gate mechanics (keep it light at L1): - One intake form, one ticket queue, one SLA, no parallel paths - Pre-approved AI vendors expose a fast-track path (the first four business units to request Copilot should not each re-run full review) - Integration with the AI vendor inventory (approval creates/updates the inventory record) and with procurement (no PO or SaaS expense reimbursement without intake ID) - Exceptions logged with owner and review date

Outcome metrics (L1, simple, auditable): | Metric | Baseline | L1 Target | Source | |---|---|---|---| | % of active AI vendors with current AUP-aligned data-handling decision on file | measure | ≥90% | Inventory + intake records | | % of AI vendors receiving non-public data with executed DPA / AI addendum | measure | 100% | Legal contract store | | % of workforce with acknowledged AI AUP (current-year attestation) | measure | ≥95% | HR / LMS | | % of new AI vendor adoptions routed through the intake gate (vs. discovered after the fact) | measure | ≥80% | Intake ticket queue vs. shadow-discovery log | | Priority compliance map published and reviewed in last 12 months | n/a | Yes | Document registry |

Process metrics (leading): - Intake triage SLA adherence (≥90% within 5 business days) - Policy exceptions open >90 days (should trend toward zero) - Sanctioned AI vendor catalog refreshed at least quarterly

Success criteria: - Three priority policies published, approved by Legal/Privacy + Security, and communicated org-wide - One-page priority compliance map published and linked from each policy - Intake gate operating with a published SLA and an amnesty path for previously undisclosed AI use - ≥95% AUP attestation across the workforce - 100% of AI vendors handling non-public data have an executed DPA / AI addendum on file - Quarterly PC-Vendors report to the program sponsor shows ≥80% of new AI adoptions going through the gate (and the number trending up)

Maturity Level 2

Objective: Deepen policies and compliance evidence per AI vendor risk tier, bind intake decisions to ongoing vendor attestations, and produce audit-ready evidence trails automatically

At this level, policy and compliance stop being point-in-time artifacts and become continuous. Each tier gets a policy depth that matches its risk; vendor attestations are tracked; evidence for EU AI Act deployer duties, GDPR Art. 28 processor adequacy, and ISO/IEC 42001 supplier controls is assembled continuously rather than at audit time.

Dependencies

• PC-Vendors L1 (required): three priority policies and the compliance map must be live.
• SM-Vendors L2 (required): tiers drive the differential policy depth.
• Supports / unblocks: EG-Vendors L2 (tier-aware reviewer training), TA-Vendors L2 (per-tier threat depth), IR-Vendors L2 (tier-differentiated config review), IM-Vendors L2 (tier-aware incident playbook).

Desired Outcomes

• Policy depth is calibrated to tier, Critical vendors carry deeper contractual and oversight controls; Low vendors stay fast-tracked.
• Vendor attestations (training-data posture, subprocessor list, incident-notification history, model-family changes) are tracked between renewals, not only at contract time.
• Every Critical or High AI vendor in the inventory has a live compliance-evidence bundle that a regulator could open today.
• Policy exceptions have finite lifespans with named owners and review dates; stale exceptions are visibly managed, not forgotten.
• Sector-specific regulatory obligations (HIPAA BAA, PCI SP, FINRA model risk, HHS/FDA clinical AI, NYDFS Part 500) are operationalized for the AI vendors they apply to, not generically acknowledged.

Activities

A) Tier-aware policy depth and contractual controls

• Extend the three priority policies with tier-specific addenda:
• Critical: contractual right-to-audit, right-to-test (red-team), model-version change notification ≥30 days, subprocessor add-notice ≥30 days with opt-out, incident-notification SLA ≤24 hours, training-data provenance attestation.
• High: subprocessor add-notice, incident-notification SLA ≤72 hours, annual SOC 2 / ISO 27001 evidence refresh, model-version change notification.
• Medium: annual attestation refresh, subprocessor list update, incident-notification SLA per DPA baseline.
• Low: annual attestation only.
• Policy exceptions framework: any deviation from the applicable tier's controls requires a named owner, a compensating control, and an expiry (max 12 months without re-review).

B) Continuous vendor attestation and compliance evidence assembly

• Each Critical or High AI vendor maintains a "compliance evidence view" that auto-assembles:
• Current DPA / AI addendum (versioned);
• Subprocessor list with last-update date;
• Training-data posture statement and source;
• Current SOC 2 Type II / ISO 27001 / equivalent;
• Model-version and notable changes log;
• Incident-notification history (vendor-side);
• Deployer-duty evidence from ML-Vendors (logs, human-oversight assignments, disclosures).
• Staleness rules: any element past its refresh window raises a PC-Vendors finding; routed to IM.
• Sector-specific bundles (HIPAA BAA evidence set, PCI SP evidence set, clinical-AI evidence set) are generated from the compliance view for the vendors to which they apply.

C) Exception management and tier-aware enforcement

• Exception register integrated with intake: no exception may be approved without tier-appropriate compensating-control definition.
• Monthly exception aging review, exceptions >90 days past expiry auto-escalate to the program sponsor.
• Enforcement asymmetry, unsanctioned AI in Critical-tier use cases triggers a blocking finding (cannot be routed through amnesty); all other tiers continue to use the amnesty path.

Outcome Metrics (L2)

Process Metrics (leading)

• Evidence-view refresh cadence honored by tier (Critical quarterly, High semi-annually).
• Policy-exception aging reviewed monthly.
• Vendor material-change tracker refreshed weekly from vendor changelogs, trust-center pages, and notification feeds.

Effectiveness Metrics (business value)

• Regulatory inquiry turnaround, evidence-view open time for an inquiry <5 business days.
• Auditor findings on AI-vendor control set trending down; repeat findings = 0.
• Vendor pushback on Critical-tier clauses handled through a documented redline framework, not case-by-case.

Success Criteria

• Three priority policies extended with tier-specific addenda; tier-appropriate contractual controls in place for ≥90% of Critical/High AI vendors.
• Compliance evidence view live for every Critical/High AI vendor; staleness inside target.
• Exception register comprehensive, reviewed monthly; no exception >90 days past expiry un-escalated.
• Sector-specific evidence bundles complete for in-scope vendors.
• Regulatory / auditor inquiry SLA met in the last 12 months.

Maturity Level 3

Objective: Automate compliance attestation, drive policy updates from monitoring telemetry, and contribute to AI-vendor regulatory and standards development

At this level, compliance is an automatic byproduct of the program rather than a separate artifact. Policy updates are data-driven, telemetry from ML-Vendors and incidents from IM-Vendors refresh the AUP/Intake/Data-Sharing policies on a known cadence. The program contributes to the development of AI-vendor regulation and standards, regulators and standards bodies receive evidence-backed feedback from operators, not only from vendors.

Dependencies

• PC-Vendors L2 (required): evidence view and exception register must be running.
• SM-Vendors L3 (required): automation substrate.
• ML-Vendors L2+ (required): telemetry feeds the policy refresh cycle.
• Supports / unblocks: L3 maturity across the Vendors domain, the L3 narrative needs PC evidence automation to be credible.

Desired Outcomes

• Audit-ready evidence for every active AI vendor can be generated on demand in hours.
• Policy refresh is evidence-driven, monitoring telemetry and incident learnings feed a published policy changelog.
• The program is an invited voice in AI-vendor regulation (EU AI Act implementation guidance, GDPR EDPB AI guidance, NIST AI RMF Playbook updates, ISO/IEC 42001 community, sector regulators).
• Vendor contract language leads the industry rather than trails it, the program contributes AI-addendum templates to standards bodies.
• External customers and regulators cite the program's evidence posture as a benchmark.

Activities

A) Continuous compliance attestation and on-demand evidence packs

• Evidence packs (by regulation, by sector, by use case) are generated on demand from the live compliance view.
• Vendor-side changes (product-update RSS, trust-center deltas, subprocessor changes, incident disclosures) auto-open tickets that refresh the evidence view.
• SLAs: any regulator or customer evidence request turned around inside 3 business days with complete provenance.

B) Telemetry-driven policy refresh

• Quarterly policy-refresh cycle driven by:
• ML-Vendors detection trends (what classes of violation are rising);
• IM-Vendors incident learnings (what policy gap did this reveal);
• Tier-movement data (which tier is growing fastest);
• External regulatory and standards updates.
• Refresh output: versioned AUP / Intake / Data-Sharing changelog, communicated org-wide; EG-Vendors training content refreshed in the same cycle.

C) Regulatory and standards contribution

• Participate in AI-vendor regulatory and standards forums: EU AI Act deployer-guidance consultations, GDPR EDPB AI guidance, NIST AI RMF working groups, ISO/IEC 42001 community, sector regulators (HHS / FDA / FINRA / NYDFS / OCC / PRA).
• Contribute AI-vendor clause templates, evidence-view schemas, and incident taxonomy to public standards (Shared Assessments, CSA AI Safety Initiative, OpenSSF).
• Target: at least 2 substantive public comments or standards contributions per year on AI-vendor topics.

Outcome Metrics (L3)

Process Metrics (leading)

• Evidence-view change-detection pipeline health monitored.
• Policy refresh pipeline on calendar with zero missed cycles in last 12 months.
• Contribution pipeline ≥2 items in-flight at any time.

Effectiveness Metrics (business value)

• Regulator / auditor / customer feedback explicitly positive on evidence posture.
• Audit findings on AI-vendor controls = 0 material in the last 12 months.
• Policy changes measurably close incidents identified in prior quarters (repeat-class incident rate trends down).

Success Criteria

• On-demand evidence pack generation inside 3 business days; SLA met in last 12 months.
• Quarterly telemetry-driven policy-refresh cycle operating with a versioned changelog.
• ≥2 public regulatory or standards contributions per year on AI-vendor topics.
• External recognition documented (invitations, citations, adoption of contributed artifacts).
• Zero material audit findings on AI-vendor controls in the last 12 months.

Key Success Indicators

Level 1: - Three priority policies published and approved by Legal/Privacy + Security: AI Acceptable Use, AI Procurement & Intake, AI Vendor Data-Sharing - One-page priority compliance map published, covering EU AI Act Art. 26 + 50, NIST AI RMF GOVERN, GDPR Art. 28 / 22 / 44–49, SOC 2 CC9.2, ISO/IEC 42001, ISO/IEC 27001 A.5.19–A.5.23, and any sector-specific (HIPAA/PCI/FINRA) that applies - AI vendor intake gate operational, single queue, published SLA, fast-track for pre-approved parent vendors, amnesty path for previously undisclosed use - AUP attestation ≥95% of workforce, current within 12 months - 100% of AI vendors receiving non-public data have an executed DPA / AI addendum; subprocessor list on file

Level 2: - Three priority policies extended with tier-specific addenda; tier-appropriate contractual controls (audit right, change-notice, incident-SLA) in place for ≥90% of Critical/High AI vendors. - Continuous compliance evidence view live for every Critical/High AI vendor; staleness inside target by tier. - Exception register comprehensive with named owners, compensating controls, and expiry dates; monthly aging review active. - Sector-specific evidence bundles (HIPAA BAA, PCI SP, clinical-AI, financial-services as applicable) complete for in-scope vendors. - Regulatory / auditor inquiry evidence turnaround SLA met in last 12 months.

Level 3: - On-demand evidence packs generated inside 3 business days for any active AI vendor; SLA met in last 12 months. - Quarterly telemetry-driven policy refresh cycle operating with a versioned changelog; 100% of changes traceable to ML/IM telemetry or external regulatory update. - ≥2 substantive public regulatory or standards contributions per year on AI-vendor topics (EU AI Act, GDPR/EDPB, NIST AI RMF, ISO/IEC 42001, sector regulators, or community standards bodies). - Zero material audit findings on AI-vendor controls in the last 12 months. - External recognition (invitations to working groups, citations, contributed-artifact adoption) documented.

Common Pitfalls

Level 1: - ❌ Relying on the generic AUP without AI-specific clauses (no rule against personal-account GenAI, no prohibited data classes, no disclosure duty) - ❌ No separate intake for AI features inside already-approved SaaS, "parent vendor is approved, so AI is approved" loophole - ❌ Compliance map is aspirational: lists frameworks but doesn't say which policy carries which requirement, so auditors can't trace evidence - ❌ DPA / AI addendum required in policy but not enforced by procurement, PO issued before contract executed - ❌ Policy published but not operational: no intake queue, no named owner, no SLA, employees route around it - ❌ No amnesty path, past shadow AI use goes underground instead of surfacing for retroactive intake - ❌ EU AI Act deployer duties not addressed (no named human oversight, no logging attestation, no disclosure to affected persons) for any AI vendor in regulated use

Level 2: - ❌ "Tier-specific addenda" published but contract templates never updated, Critical-tier controls exist in policy only. - ❌ Evidence view is a folder-of-PDFs that only the compliance lead understands, a peer reviewer cannot assemble the regulator pack without them. - ❌ Exception register lacks expiry dates, stale exceptions quietly become the norm. - ❌ Sector-specific bundles are treated as "covered by the DPA", HIPAA BAA or PCI SP specifics not operationalized. - ❌ Audit trail of policy enforcement is tribal knowledge, not evidence, an auditor asking "how do you know this control was enforced?" gets a story, not artifacts.

Level 3: - ❌ Automation generates evidence packs that are technically complete but narratively thin, the regulator still needs a human walkthrough. - ❌ Policy refresh is cadence-only; quarterly ritual without real telemetry input. The changelog reads like formatting updates, not learnings. - ❌ "Regulatory contributions" are comments on deadline but not technical artifacts that regulators actually cite. - ❌ Contributed templates get adoption but are not maintained, external users find stale versions and stop trusting the program. - ❌ ROI narrative omits compliance cost reduction, the biggest L3 business case (lower audit + legal + evidence-collection overhead) left unmeasured.

Practice Maturity Questions

Level 1: 1. Have you published and formally approved the three priority AI vendor policies, AI Acceptable Use, AI Procurement & Intake, AI Vendor Data-Sharing, with AI-specific clauses (prohibited data classes, personal-account prohibition, AI-feature-inside-SaaS intake requirement, training-on-data default-off, DPA/AI addendum requirement)? 2. Is there a one-page priority compliance map that ties each priority requirement (EU AI Act Art. 26/50, NIST AI RMF GOVERN, GDPR Art. 28/22/44–49, SOC 2 CC9.2, ISO/IEC 42001, ISO/IEC 27001 A.5.19–A.5.23, plus any sector-specific) to the specific L1 policy that carries the control? 3. Is the AI vendor intake gate operational with a published SLA, an amnesty path for previously undisclosed use, ≥95% AUP attestation, and 100% DPA/AI-addendum coverage for AI vendors handling non-public data?

Level 2: 1. Have the three priority AI vendor policies been extended with tier-specific addenda, and do Critical/High AI vendors carry tier-appropriate contractual controls (audit rights, model-version change notice, subprocessor add-notice, incident-notification SLA, training-data provenance attestation)? 2. Does every Critical/High AI vendor have a live, continuously-assembled compliance evidence view covering DPA / AI addendum, subprocessor list, training-data posture, SOC 2/ISO evidence, model-version log, incident history, and deployer-duty evidence, with staleness inside tier-specific targets? 3. Is an exception register operated with named owners, compensating controls, and expiry dates, reviewed monthly, with unsanctioned AI in Critical-tier use cases subject to blocking enforcement (no amnesty) and sector-specific evidence bundles (HIPAA / PCI / clinical / financial) complete for in-scope vendors?

Level 3: 1. Can on-demand, regulator-grade evidence packs for any active AI vendor be generated inside 3 business days, with vendor-side changes auto-refreshing the evidence view and full provenance traceable? 2. Does the program operate a quarterly, telemetry-driven policy-refresh cycle (ML-Vendors detection trends + IM-Vendors incident learnings + tier-movement + external regulatory updates) with a versioned changelog, and are the changes reflected in EG-Vendors training within 30 days? 3. Does the program contribute at least two substantive public comments or standards artifacts per year on AI-vendor topics (EU AI Act deployer guidance, GDPR EDPB AI guidance, NIST AI RMF, ISO/IEC 42001, sector regulators, or community standards bodies), with documented external recognition?

Document Version: HAIAMM v3.0 Practice: Policy & Compliance (PC) Domain: Vendors Last Updated: 2026-05-12 Author: Verifhai