Amo.ng curated workflow
Vendor Procurement Due Diligence
Assess vendor claims, evidence quality, security and privacy risk, procurement fit, and decision readiness before approval.
# Vendor Procurement Due Diligence Workflow ID: AMO-W-000002 ## Outcome Produce a traceable procurement recommendation that distinguishes supported vendor claims from gaps, evaluates security and data-processing risk, and gives the decision owner clear conditions or next actions. ## Before you begin - Vendor proposal, claim set, and source links - Evidence dates and accessible supporting documents - Security, privacy, data-processing, and compliance materials - Business requirements, commercial context, and decision criteria - Known stakeholders and approval authority ## Step 1 — Test the vendor claims against accessible evidence **Prompt** Vendor Claims Fact-Check Dossier **Instructions** Build a source-backed dossier that separates supported, contradicted, stale, inaccessible, and unsupported claims. **Input for this step** Provide exact claim wording, vendor materials, independent sources, dates, jurisdiction or market context, and known evidence gaps. **Carry forward** Carry the claim matrix, source record, contradictions, unanswered questions, and evidence limitations into the risk review. **Human checkpoint** Confirm that research findings are not represented as procurement approval or completed legal, security, or financial diligence. **Prompt content** Create a procurement-focused fact-check dossier for the following inputs. Vendor and product: [Vendor and product] Claims and sales materials: [Claims and sales materials] Procurement context: [Procurement context] Evidence standard: [Evidence standard] Security, privacy, compliance, and AI requirements: [Security, privacy, compliance, and AI requirements] Commercial, contract, and customer claims: [Commercial, contract, and customer claims] Competitors: [Competitors] Provided public or sanitized sources and research cutoff date: [Provided public or sanitized sources and research cutoff date] INPUT CONTROL 1. Treat the supplied text and links as assertions or leads, not proof. Do not infer that a sales statement, logo, testimonial, comparison table, trust badge, questionnaire answer, or contract draft is accurate or current. 2. The minimum inputs needed to begin claim-level research are an identifiable vendor or product, at least one claim, the procurement decision being supported, and an evidence cutoff date. If any are missing, stop and request them. If optional inputs are absent, continue only where useful and list the omission without filling it by assumption. 3. If a claim is broad, split it into testable units. For example, separate a compliance claim into certification type, covered legal entity, product or service scope, audit period, status, and availability of supporting documentation. 4. If inputs conflict, preserve both versions, identify their sources, and ask which governs. Do not silently reconcile different product editions, legal entities, regions, dates, plan names, security scopes, prices, or contract terms. 5. Do not expose confidential sales materials, personal data, credentials, non-public security artifacts, or contract terms beyond what the user has supplied and is authorized to review. Recommend an approved private review channel when sensitive evidence cannot safely be assessed here. PERPLEXITY RESEARCH BOUNDARY Use Perplexity to locate and summarize publicly accessible sources and to attach citations to factual findings. Research requested in this prompt is not necessarily research executed: report only searches and source inspections actually reflected in the response. Never imply access to a private trust center, data room, paid report, customer reference call, internal system, signed agreement, audit report, or blocked page unless its contents were supplied or genuinely accessible in the current session. For every inaccessible, paywalled, login-gated, missing, or technically unreadable source, mark it Unavailable and state the limitation. If Perplexity returns a citation whose page does not support the stated proposition, mark the proposition Unverified rather than relying on the search summary. Never claim that evidence was verified merely because a citation was generated. Distinguish work state explicitly: - Requested: research or confirmation the buyer asked for. - Executed: a search or source inspection actually performed and evidenced by a citation or supplied material. - Proposed: a future review, vendor request, legal check, test, reference call, or negotiation step. - Unavailable: evidence could not be accessed or was not supplied. - Unverified: available material was insufficient to establish the claim. Do not say a claim, control, price, certification, customer relationship, test result, contract term, approval, message, or remediation was confirmed, tested, approved, sent, completed, or implemented without direct evidence for that exact statement. The dossier is decision support, not legal advice, a security assessment, an audit, a penetration test, a financial approval, or procurement authorization. CLAIM AND EVIDENCE METHOD 1. Build a complete inventory of material claims from the supplied inputs before searching. Record each atomic claim once and assign a stable identifier such as C-01. 2. Classify each claim as security, compliance, privacy, AI or data use, performance, pricing, contract, customer proof, integration, support, implementation, or competitive positioning. 3. Define the evidence needed before evaluating the claim. Apply [Evidence standard]; if it is unclear, ask for clarification when it would change the decision. Otherwise use a conservative standard and label it as an assumption. 4. Prefer evidence tied to the correct vendor legal entity, product, plan, region, and time period. Suitable primary evidence may include current official documentation, pricing and policy pages, contract language supplied by the buyer, certification registry records, regulator or standards-body records, official security advisories, and detailed customer case studies. 5. Seek independent corroboration where material, including regulator records, certification registries, public incident reports, procurement records, reputable technical evaluations, customer-authored statements, and dated marketplace records. Label vendor-authored and independent evidence separately; independence does not automatically make a source reliable. 6. For each source, record title, publisher, source category, URL or citation, publication or effective date when available, access date when available, relevant claim identifiers, exact proposition supported, and limitations. Never invent missing metadata. 7. Grade evidence as Strong, Moderate, Weak, or Insufficient, with a claim-specific reason. Marketing copy, unsourced comparison charts, sales decks, generic testimonials, and customer logos alone are Weak or Insufficient. 8. Assign exactly one verdict to each atomic claim: - Confirmed — current evidence meeting [Evidence standard] directly supports the complete atomic claim for the relevant legal entity, product, plan, region, period, and scope. - Partially confirmed — evidence supports only part of the claim or supports it only for a narrower entity, product, plan, region, period, condition, or scope. - Unsupported — no adequate supporting evidence was found or supplied within the stated research scope. Unsupported does not by itself mean that the claim is false. - Ambiguous — the wording, terminology, measurement, scope, ownership, timeframe, or intended interpretation is too unclear to assess reliably. - Contradicted — credible, relevant evidence directly conflicts with the atomic claim. Preserve the conflicting evidence and do not infer the cause without support. - Outdated — supporting evidence exists but is too old, superseded, or temporally mismatched for the current procurement decision. - Not enough evidence — access, source coverage, evidence quality, or the available research scope is insufficient to reach another verdict. A vendor-authored assertion alone may confirm only the narrower proposition that the vendor currently publishes or represents that statement. It does not independently confirm the underlying control, performance result, customer relationship, compliance status, or contractual commitment. Do not treat failure to find public evidence as proof that a claim is false. Record the search and access limitations and use Unsupported or Not enough evidence according to the distinction above. 9. Record conflicting evidence side by side. Explain differences in scope, date, entity, plan, geography, methodology, or terminology when supported; otherwise leave the cause unresolved. 10. Convert every decision-relevant evidence gap into a precise vendor question identifying the artifact, scope, date, or contractual commitment needed. DOMAIN-SPECIFIC CHECKS - Security and compliance: distinguish claimed, documented, certified, independently assessed, and contractually enforceable controls. Verify the standard, auditor or registry where public, audit period, report type, covered entity, product scope, exceptions, and document freshness. Do not equate a framework-aligned statement with certification. - Privacy and AI: distinguish model or subprocessors, customer-data use, training or improvement use, retention, deletion commitments, residency, cross-border transfers, human access, opt-out scope, logging, and contractual enforceability. Do not infer no-training or zero-retention commitments from general privacy language. - Performance: require a defined metric, test population, baseline, methodology, date, conditions, sample size when available, and independent reproducibility. Treat undefined accuracy, productivity, reliability, or best-in-class language as unsupported. - Pricing and contracts: identify currency, region, billing interval, plan, included usage, overages, minimum commitments, add-ons, implementation fees, renewal mechanics, cancellation terms, discounts, and source date. Published pricing is not proof of a buyer-specific final price; only supplied current contractual terms can evidence that price. - Customer proof: distinguish a vendor-displayed logo from a customer-authored confirmation. Check whether the relationship appears current, concerns the evaluated product, and supports the claimed use case or outcome. Do not contact customers or represent that a reference call occurred. - Competitors: compare only equivalent products, plans, regions, dates, and claim areas supported by evidence. Label missing or non-comparable data instead of ranking by assumption. REQUIRED DOSSIER Produce concise markdown with these sections: Keep the dossier concise and proportional to the number, materiality, and complexity of the claims and to the evidence actually available. Do not repeat the same claim, source description, evidence gap, or limitation across multiple sections unnecessarily. Use claim IDs and evidence IDs to cross-reference earlier records. Include only applicable domain-specific subsections. Where a subsection is genuinely outside scope or cannot be assessed, retain its heading when needed for decision clarity, state Not assessable, and explain briefly why. Never omit: - decision scope and research status; - claim inventory and verdict register; - evidence ledger; - decision-critical findings; - prioritized evidence requests; - research-informed decision posture; - verification and reconciliation record; - human review gates. Do not fill unsupported sections with generic procurement advice merely to complete the format. 1. Decision scope and research status State the vendor and product, decision, buyer context, cutoff date, required evidence level, material exclusions, missing or conflicting inputs, and a count of Requested, Executed, Proposed, Unavailable, and Unverified research items. State that no procurement approval has been granted by this dossier. 2. Claim inventory and verdict register Provide a table with: Claim ID; atomic claim; category; source of the claim; why it matters; required evidence; verdict; evidence strength; procurement reliance risk; and short rationale. Use these qualitative procurement-reliance risk labels: - High — accepting the claim without stronger evidence could materially change the buying decision or create substantial security, privacy, legal, financial, contractual, operational, customer, or reputational exposure. - Medium — the evidence gap is decision-relevant and should become a condition, vendor request, contractual requirement, or assigned follow-up, but it does not independently establish an immediate blocker. - Low — the claim is adequately supported for the stated evidence standard or the remaining uncertainty has limited consequence for the current decision. - Unknown — the available evidence, scope, or authority is insufficient to classify the reliance risk defensibly. Base each label on the importance of the claim, the evidence gap, the decision context, and the consequence of relying on it incorrectly. Do not infer likelihood or severity merely from generic industry experience. Do not convert the labels into a numerical score or present them as a comprehensive vendor-risk rating. 3. Evidence ledger Separate Vendor-authored, Independent, Buyer-supplied, and Unavailable evidence. For each accessible source provide: Evidence ID; title and publisher; source category; citation or URL; relevant date; claim IDs; exact support; strength; limitations; and access status. Do not list a source as independent if the vendor sponsored, republished, or supplied it unless that relationship is disclosed. 4. Material findings by claim For each High-risk or decision-critical claim, provide the verdict, supporting and conflicting evidence IDs, scope and freshness assessment, remaining uncertainty, buyer implication, and a proposed next step. Clearly label future steps as Proposed. 5. Security, privacy, AI, commercial, and customer-proof checks Include only applicable subsections. Map each supplied requirement or claim to evidence, unresolved gaps, and the artifact or contract language needed. If a subsection is not assessable, say why rather than producing a generic assessment. 6. Competitor evidence comparison If competitors were supplied, provide: claim area; vendor evidence; competitor evidence; comparability limits; and buyer implication. Omit unsupported rankings. 7. Prioritized vendor evidence requests Group precise questions by security and compliance, privacy and AI data use, pricing and contract, customer references, implementation, and support. Give each question a priority, linked claim ID, required response artifact, and acceptance condition. Do not state that questions were sent. 8. Decision posture Choose one: Choose one research-informed posture: - Proceed to approval review - Proceed to approval review with conditions - Delay approval review pending evidence - Do not proceed to approval review - Not enough evidence to form a posture. Tie the posture to specific claim IDs, conditions, unresolved evidence, residual reliance risks, and required human approvals. The posture indicates what the evidence supports as the next procurement step. It is not procurement approval, contract authorization, legal clearance, security acceptance, budget approval, or permission to onboard the vendor. 9. Verification and reconciliation record Report each check below as Pass, Fail, or Not assessable, with concrete evidence or an explanation: - Claim reconciliation: every material input claim appears once in the inventory or is identified as out of scope; provide input count, atomic claim count, and omitted-item count. - Verdict traceability: every verdict cites at least one evidence ID or explicitly states that no supporting evidence was found. - Citation entailment: each cited page supports the exact proposition attributed to it; identify citations that were not inspectable or did not support the proposition. - Scope match: security, compliance, privacy, pricing, performance, and customer evidence matches the relevant entity, product, plan, region, and period, or the mismatch is disclosed. - Freshness: source dates are recorded where available and evidence predating the stated cutoff or decision need is flagged with its resulting risk. - Source separation: vendor-authored, independent, buyer-supplied, and unavailable materials are not conflated. - Conflict handling: contradictory sources are retained and unresolved conflicts affect the verdict and risk. - Commercial reconciliation: quoted prices and terms identify currency, plan, region, billing basis, effective date, and contractual status where available. - Customer-proof threshold: no logo or vendor testimonial is reported as an independently confirmed current relationship without corroboration. - Completion integrity: every statement suggesting research, verification, contact, approval, testing, or completion is supported by evidence; otherwise it is relabeled Requested, Proposed, Unavailable, or Unverified. Acceptance requires all material claims to be reconciled, all verdicts to be traceable, all inaccessible evidence to be disclosed, and all decision-critical conflicts or gaps to appear in the vendor requests and decision posture. If any requirement fails, label the dossier Incomplete for procurement reliance and list the exact remediation needed. 10. Human review gates Identify the authorized functions that still need to review applicable legal terms, privacy obligations, security evidence, financial exposure, regulatory fit, and final procurement approval. Recommend escalation proportionate to risk, but do not assign approval that has not occurred. ## Step 2 — Review security, privacy, and data processing **Prompt** AI Vendor Security and Data Processing Review Brief **Instructions** Assess how the vendor handles data, access, subprocessors, retention, deletion, incidents, and contractual security commitments. **Input for this step** Provide the claim dossier plus the vendor security pack, privacy terms, data-flow description, subprocessors, certifications, and required controls. **Carry forward** Carry material risks, exceptions, missing evidence, proposed mitigations, and accountable owners into procurement scoring. **Human checkpoint** Require qualified security, privacy, legal, or compliance review for issues outside the reviewer’s authority. **Prompt content** You are a senior security, privacy, and AI governance reviewer supporting procurement, legal, security, compliance, and business stakeholders. Prepare an AI vendor security and data-processing review brief that evaluates the vendor’s security posture, privacy commitments, data lifecycle, model training use, subprocessors, retention, deletion, compliance fit, contractual risks, operational controls, and approval conditions. The goal is to help human stakeholders decide whether to approve, approve with conditions, defer, or reject an AI vendor before procurement, renewal, or expanded use. ## Context Placeholders Use the context below. If the vendor, product, intended use, or data categories are missing, ask for them before producing the review. If other inputs are missing, continue only with clearly labeled assumptions. - [Vendor, product, and intended use] - [Data categories, users, and access scope] - [Security and privacy documents] - [Compliance, contract, and DPA requirements] - [Model training, retention, and deletion terms] - [Subprocessors, support access, and data residency] - [Approval stakeholders and decision deadline] ## Important Constraints - Do not invent vendor claims, security controls, certifications, audit findings, contract terms, DPA language, compliance status, subprocessors, retention periods, deletion commitments, or stakeholder approvals. - Separate confirmed vendor evidence from assumptions, gaps, risks, and recommendations. - Label confidence level and uncertainty for every major conclusion. - Do not accept vendor marketing claims as evidence unless supported by supplied security, privacy, legal, technical, or contractual documents. - Do not present this output as legal, regulatory, procurement, financial, security, or compliance advice. - Contract interpretation, DPA terms, liability, indemnity, data protection, cross-border transfer, regulated data, and compliance obligations must be reviewed by qualified legal, privacy, security, or compliance owners. - Treat missing DPA, unclear model training terms, unclear retention, unclear deletion process, unknown subprocessors, weak access controls, poor logging, and lack of incident response evidence as review risks. - Do not recommend approval for sensitive, regulated, customer, employee, financial, health, children’s, biometric, confidential, or proprietary data use without explicit human review gates. - Do not recommend sharing secrets, credentials, production keys, source code, customer data, employee data, payment data, regulated data, or confidential documents unless the intended use, controls, and approvals support it. - Make recommendations specific to the supplied vendor materials, intended use, data categories, user groups, documents, compliance requirements, contract terms, approval stakeholders, and deadline. ## Step-by-Step Instructions 1. Summarize the vendor review context: - vendor name - product description - intended business use - user groups - data categories involved - deployment model - procurement or renewal context - approval stakeholders - decision deadline 2. Map the data lifecycle: - data collected - data uploaded by users - data generated by the AI system - data processed by the vendor - data stored - data retained - data deleted - data exported - data used for model training or improvement - data accessed by support staff - data shared with subprocessors - data transferred across regions 3. Review security evidence: - SOC 2 or equivalent report if supplied - ISO 27001 or equivalent certification if supplied - penetration test summary if supplied - vulnerability management - encryption in transit - encryption at rest - access control - SSO and MFA support - RBAC or least-privilege controls - audit logging - tenant isolation - incident response - business continuity - disaster recovery 4. Review privacy and data-processing evidence: - privacy policy - DPA - subprocessors - retention policy - deletion process - data residency - model training terms - opt-out terms - customer content ownership - support access - data export rights - cross-border transfer terms - data subject request support if relevant 5. Review AI governance concerns: - intended use risk - sensitive data exposure - human review needs - output reliability risk - hallucination or incorrect output risk - explainability needs - auditability - user permissions - prompt and output logging - model training boundaries - restricted use cases - policy alignment 6. Identify risk areas: - unacceptable risk - approval with conditions - missing evidence - contract gap - operational control gap - privacy gap - security gap - compliance gap - user training need - monitoring requirement 7. Prepare approval options: - approve - approve with conditions - defer pending evidence - reject - pilot only - low-risk limited use only 8. Create follow-up questions and owner-specific actions for security, legal, privacy, procurement, finance, IT, business owners, and executive reviewers. ## Output Format ### 1. Missing Context List missing inputs needed before a reliable AI vendor review can be completed. If enough context is available, say so. ### 2. Vendor Review Snapshot Use this table: | Area | Current View | Evidence Supplied | Risk or Uncertainty | |---|---|---|---| Cover vendor, product, intended use, users, data categories, documents, approval stakeholders, and deadline. ### 3. Data Lifecycle Map Use this table: | Data Stage | What Happens | Vendor Evidence | Risk | Follow-Up Needed | |---|---|---|---|---| Cover collection, upload, processing, storage, model training, retention, deletion, subprocessors, support access, export, and regional transfer. ### 4. Security Evidence Review Use this table: | Control Area | Evidence Supplied | Gap or Concern | Risk Level | Owner Follow-Up | |---|---|---|---|---| Cover access control, encryption, logging, SSO/MFA, RBAC, tenant isolation, incident response, vulnerability management, and business continuity where relevant. ### 5. Privacy and Contract Evidence Review Use this table: | Area | Evidence Supplied | Gap or Concern | Required Review | |---|---|---|---| Cover privacy policy, DPA, retention, deletion, subprocessors, data residency, model training, opt-out rights, support access, cross-border transfer, and customer content ownership. ### 6. AI Governance Risk Register Use this table: | Risk | Evidence | Impact | Severity | Mitigation or Condition | |---|---|---|---|---| ### 7. Required Follow-Ups Use this table: | Follow-Up Question or Action | Owner Role | Why It Matters | Required Before Approval? | |---|---|---|---| ### 8. Approval Options Use this table: | Option | When Appropriate | Conditions | Residual Risk | |---|---|---|---| Include approve, approve with conditions, defer, reject, pilot only, and limited-use approval where relevant. ### 9. Human Approval Recommendation Provide a clear recommendation: approve, approve with conditions, defer, reject, pilot only, or limited-use approval. Include rationale, confidence level, conditions, unresolved questions, and required human review gates. ### 10. Executive Brief Provide a concise leadership-ready summary covering intended use, data involved, top risks, missing evidence, approval recommendation, required conditions, and decision deadline. ### 11. Missing Inputs and Human Checks List assumptions made, blocked decisions, unresolved risks, confidence level, and reviews required from security, legal, privacy, procurement, IT, business owners, finance, or executives. ## Verification Checklist Before finalizing, confirm that: - no vendor claim is accepted without evidence or caveat - data categories and user groups are clearly identified - data handling, retention, deletion, model training, subprocessors, support access, and data residency are addressed - security controls are separated from privacy and contract controls - sensitive or regulated data use requires human review - approval recommendation includes conditions and residual risk - legal and compliance interpretations are flagged for qualified review - missing documents and follow-up questions are clearly listed - final output does not present assumptions as facts ## Final Instruction to Begin Begin now. First review the supplied vendor, product, intended use, data categories, user groups, security documents, privacy documents, compliance requirements, contract terms, model training terms, retention terms, subprocessors, support access, approval stakeholders, and decision deadline. If required context is missing, ask for it. Otherwise, produce the full AI vendor security and data-processing review brief in the requested markdown format. ## Step 3 — Evaluate procurement fit and decision risk **Prompt** AI Vendor Evaluation and Procurement Risk Scorecard **Instructions** Apply the organization’s actual requirements to business fit, integration, cost, governance, security, and implementation readiness. **Input for this step** Provide the verified claims, risk review, decision criteria, commercial assumptions, operational requirements, and acceptable exceptions. **Carry forward** Carry the structured scorecard, disqualifiers, conditions, tradeoffs, and remaining evidence needs into the decision brief. **Human checkpoint** Do not invent weights, policy thresholds, approval rules, or acceptable risk levels that the organization has not supplied. **Prompt content** You are an expert AI procurement advisor specializing in vendor evaluation, data privacy, security, compliance, cost analysis, integration risk, and responsible AI governance. Your task is to help a business evaluate an AI vendor or AI tool before purchase, approval, renewal, or rollout. Context: Business context: [Business context] AI tool or vendor name: [AI tool or vendor name] Vendor website or product summary: [Vendor website or product summary] Intended use case: [Intended use case] Departments or users: [Departments or users] Data the tool will access: [Data the tool will access] Data the tool will store or process: [Data the tool will store or process] Integrations required: [Integrations required] Compliance requirements: [Compliance requirements] Security requirements: [Security requirements] Budget or pricing information: [Budget or pricing information] Contract or procurement constraints: [Contract or procurement constraints] Existing alternatives: [Existing alternatives] Risk tolerance: [Risk tolerance] Definition of done: [Definition of done] Important constraints: - Do not approve a vendor blindly. - Do not assume security or compliance claims are true unless evidence is provided. - If information is missing, list the questions the business should ask the vendor. - Consider data protection, access controls, retention, model training, auditability, cost, and lock-in. - Keep the evaluation practical for business decision-makers. Task: 1. Summarize the vendor and use case. Explain: - What the tool does - Who will use it - What business problem it solves - What systems it may connect to - What data it may access - Why the evaluation matters 2. Create a vendor evaluation scorecard. Use a 1–5 score for: - Business fit - Ease of use - Security posture - Data privacy - Compliance readiness - Admin controls - Audit logs - Integration fit - Cost transparency - Vendor maturity - Support quality - Exit or portability risk 3. Assess data handling risk. Review: - What data enters the tool - Whether sensitive data is involved - Whether data may be used for model training - Whether data is retained - Whether users can delete data - Where data may be hosted - Whether access controls are sufficient 4. Assess security and compliance. Evaluate: - Authentication options - SSO or MFA support - Role-based access controls - Audit logs - Encryption - Data retention - Incident response - Compliance certifications - Vendor security documentation - Admin visibility 5. Assess operational fit. Review: - User onboarding - Workflow fit - Integration needs - Training requirements - Support needs - Change management - Internal ownership - Rollout complexity 6. Assess commercial and lock-in risk. Evaluate: - Pricing model - Hidden costs - Contract terms - Renewal risk - Export options - Switching cost - Dependency risk 7. Create a risk register. Use a table with: Risk | Category | Severity | Evidence Needed | Mitigation | Owner | Priority 8. Create vendor questions. Provide questions to ask the vendor about: - Security - Privacy - Model training - Data retention - Compliance - Admin controls - Audit logs - Integrations - Pricing - Support - Exit process 9. Provide a recommendation. Classify the decision as: - Approve - Approve with conditions - Pilot first - Defer pending information - Reject Explain the rationale. 10. Create a safe rollout plan. Include: - Pilot group - Data restrictions - Approved use cases - Admin setup - Training - Monitoring - Review date - Success metrics Output format: ## Executive Summary ## Vendor and Use Case Summary ## Evaluation Scorecard ## Data Handling Risk Assessment ## Security and Compliance Assessment ## Operational Fit Assessment ## Commercial and Lock-In Risk ## Risk Register ## Vendor Questions ## Recommendation ## Safe Rollout Plan ## Final Decision Checklist Verification: Before finalizing, check that: - Missing vendor information is clearly identified. - Sensitive data risks are not ignored. - Recommendation is based on evidence and risk. - Approval conditions are practical. - The rollout plan includes safeguards. Begin the AI vendor evaluation now. ## Step 4 — Prepare the procurement decision brief **Prompt** Executive Decision Brief Prompt **Instructions** Condense the traceable evidence, options, tradeoffs, risks, and conditions into a decision-ready brief for the authorized owner. **Input for this step** Provide the claim dossier, risk review, scorecard, commercial options, stakeholder constraints, and outstanding decisions. **Carry forward** Use the brief as the human decision packet; preserve links to the underlying evidence and unresolved items. **Human checkpoint** The authorized procurement owner makes the final approval, rejection, conditional approval, or further-diligence decision. **Prompt content** Act as a senior Business specialist using ChatGPT. Your task is: [Goal or task]. Context: - Current situation: [Current context] - Constraints: [Constraints] - Available materials: [Files, data, examples, URLs, logs, notes] - Success criteria: [Definition of done] Workflow: 1. Restate the objective in operational terms and identify any missing information that would block a reliable answer. 2. Make reasonable assumptions only when they are low risk, and label them clearly. 3. Produce the main deliverable for "Executive Decision Brief Prompt" with enough detail that a skilled operator can execute it immediately. 4. Include edge cases, failure modes, dependencies, and tradeoffs that a junior prompt would usually miss. 5. Add a verification checklist with concrete tests, review questions, metrics, or acceptance criteria. 6. End with the smallest safe next action. Output format: - Executive summary - Detailed plan or implementation - Risks and mitigations - Verification checklist - Next action Do not give generic advice. Optimize for a production-quality strategy outcome. ## Completion criteria Material claims are traced to evidence, unresolved security and privacy issues are explicit, procurement criteria are applied consistently, and the final recommendation identifies conditions, owners, and evidence still required before approval. # Vendor Procurement Due Diligence Use this Amo.ng workflow with your preferred AI tool. Complete the steps in order and carry the specified output forward. Outcome: Produce a traceable procurement recommendation that distinguishes supported vendor claims from gaps, evaluates security and data-processing risk, and gives the decision owner clear conditions or next actions. Required inputs: - Vendor proposal, claim set, and source links - Evidence dates and accessible supporting documents - Security, privacy, data-processing, and compliance materials - Business requirements, commercial context, and decision criteria - Known stakeholders and approval authority ## Step 1 — Test the vendor claims against accessible evidence **Instructions** Build a source-backed dossier that separates supported, contradicted, stale, inaccessible, and unsupported claims. **Input for this step** Provide exact claim wording, vendor materials, independent sources, dates, jurisdiction or market context, and known evidence gaps. **Carry forward** Carry the claim matrix, source record, contradictions, unanswered questions, and evidence limitations into the risk review. **Human checkpoint** Confirm that research findings are not represented as procurement approval or completed legal, security, or financial diligence. **Prompt** Vendor Claims Fact-Check Dossier **Prompt URL** https://amo.ng/prompts/vendor-claims-fact-check-dossier ## Step 2 — Review security, privacy, and data processing **Instructions** Assess how the vendor handles data, access, subprocessors, retention, deletion, incidents, and contractual security commitments. **Input for this step** Provide the claim dossier plus the vendor security pack, privacy terms, data-flow description, subprocessors, certifications, and required controls. **Carry forward** Carry material risks, exceptions, missing evidence, proposed mitigations, and accountable owners into procurement scoring. **Human checkpoint** Require qualified security, privacy, legal, or compliance review for issues outside the reviewer’s authority. **Prompt** AI Vendor Security and Data Processing Review Brief **Prompt URL** https://amo.ng/prompts/ai-vendor-security-data-processing-review-brief ## Step 3 — Evaluate procurement fit and decision risk **Instructions** Apply the organization’s actual requirements to business fit, integration, cost, governance, security, and implementation readiness. **Input for this step** Provide the verified claims, risk review, decision criteria, commercial assumptions, operational requirements, and acceptable exceptions. **Carry forward** Carry the structured scorecard, disqualifiers, conditions, tradeoffs, and remaining evidence needs into the decision brief. **Human checkpoint** Do not invent weights, policy thresholds, approval rules, or acceptable risk levels that the organization has not supplied. **Prompt** AI Vendor Evaluation and Procurement Risk Scorecard **Prompt URL** https://amo.ng/prompts/ai-vendor-evaluation-procurement-risk-scorecard ## Step 4 — Prepare the procurement decision brief **Instructions** Condense the traceable evidence, options, tradeoffs, risks, and conditions into a decision-ready brief for the authorized owner. **Input for this step** Provide the claim dossier, risk review, scorecard, commercial options, stakeholder constraints, and outstanding decisions. **Carry forward** Use the brief as the human decision packet; preserve links to the underlying evidence and unresolved items. **Human checkpoint** The authorized procurement owner makes the final approval, rejection, conditional approval, or further-diligence decision. **Prompt** Executive Decision Brief Prompt **Prompt URL** https://amo.ng/prompts/executive-decision-brief-prompt Completion criteria: Material claims are traced to evidence, unresolved security and privacy issues are explicit, procurement criteria are applied consistently, and the final recommendation identifies conditions, owners, and evidence still required before approval.Outcome
Produce a traceable procurement recommendation that distinguishes supported vendor claims from gaps, evaluates security and data-processing risk, and gives the decision owner clear conditions or next actions.
Before you begin
- Vendor proposal, claim set, and source links
- Evidence dates and accessible supporting documents
- Security, privacy, data-processing, and compliance materials
- Business requirements, commercial context, and decision criteria
- Known stakeholders and approval authority
Ordered sequence
Workflow steps
-
Step 1 Test the vendor claims against accessible evidence
Build a source-backed dossier that separates supported, contradicted, stale, inaccessible, and unsupported claims.
Prompt: Vendor Claims Fact-Check DossierCreate a procurement-focused fact-check dossier for the following inputs. Vendor and product: [Vendor and product] Claims and sales materials: [Claims and sales materials] Procurement context: [Procurement context] Evidence standard: [Evidence standard] Security, privacy, compliance, and AI requirements: [Security, privacy, compliance, and AI requirements] Commercial, contract, and customer claims: [Commercial, contract, and customer claims] Competitors: [Competitors] Provided public or sanitized sources and research cutoff date: [Provided public or sanitized sources and research cutoff date] INPUT CONTROL 1. Treat the supplied text and links as assertions or leads, not proof. Do not infer that a sales statement, logo, testimonial, comparison table, trust badge, questionnaire answer, or contract draft is accurate or current. 2. The minimum inputs needed to begin claim-level research are an identifiable vendor or product, at least one claim, the procurement decision being supported, and an evidence cutoff date. If any are missing, stop and request them. If optional inputs are absent, continue only where useful and list the omission without filling it by assumption. 3. If a claim is broad, split it into testable units. For example, separate a compliance claim into certification type, covered legal entity, product or service scope, audit period, status, and availability of supporting documentation. 4. If inputs conflict, preserve both versions, identify their sources, and ask which governs. Do not silently reconcile different product editions, legal entities, regions, dates, plan names, security scopes, prices, or contract terms. 5. Do not expose confidential sales materials, personal data, credentials, non-public security artifacts, or contract terms beyond what the user has supplied and is authorized to review. Recommend an approved private review channel when sensitive evidence cannot safely be assessed here. PERPLEXITY RESEARCH BOUNDARY Use Perplexity to locate and summarize publicly accessible sources and to attach citations to factual findings. Research requested in this prompt is not necessarily research executed: report only searches and source inspections actually reflected in the response. Never imply access to a private trust center, data room, paid report, customer reference call, internal system, signed agreement, audit report, or blocked page unless its contents were supplied or genuinely accessible in the current session. For every inaccessible, paywalled, login-gated, missing, or technically unreadable source, mark it Unavailable and state the limitation. If Perplexity returns a citation whose page does not support the stated proposition, mark the proposition Unverified rather than relying on the search summary. Never claim that evidence was verified merely because a citation was generated. Distinguish work state explicitly: - Requested: research or confirmation the buyer asked for. - Executed: a search or source inspection actually performed and evidenced by a citation or supplied material. - Proposed: a future review, vendor request, legal check, test, reference call, or negotiation step. - Unavailable: evidence could not be accessed or was not supplied. - Unverified: available material was insufficient to establish the claim. Do not say a claim, control, price, certification, customer relationship, test result, contract term, approval, message, or remediation was confirmed, tested, approved, sent, completed, or implemented without direct evidence for that exact statement. The dossier is decision support, not legal advice, a security assessment, an audit, a penetration test, a financial approval, or procurement authorization. CLAIM AND EVIDENCE METHOD 1. Build a complete inventory of material claims from the supplied inputs before searching. Record each atomic claim once and assign a stable identifier such as C-01. 2. Classify each claim as security, compliance, privacy, AI or data use, performance, pricing, contract, customer proof, integration, support, implementation, or competitive positioning. 3. Define the evidence needed before evaluating the claim. Apply [Evidence standard]; if it is unclear, ask for clarification when it would change the decision. Otherwise use a conservative standard and label it as an assumption. 4. Prefer evidence tied to the correct vendor legal entity, product, plan, region, and time period. Suitable primary evidence may include current official documentation, pricing and policy pages, contract language supplied by the buyer, certification registry records, regulator or standards-body records, official security advisories, and detailed customer case studies. 5. Seek independent corroboration where material, including regulator records, certification registries, public incident reports, procurement records, reputable technical evaluations, customer-authored statements, and dated marketplace records. Label vendor-authored and independent evidence separately; independence does not automatically make a source reliable. 6. For each source, record title, publisher, source category, URL or citation, publication or effective date when available, access date when available, relevant claim identifiers, exact proposition supported, and limitations. Never invent missing metadata. 7. Grade evidence as Strong, Moderate, Weak, or Insufficient, with a claim-specific reason. Marketing copy, unsourced comparison charts, sales decks, generic testimonials, and customer logos alone are Weak or Insufficient. 8. Assign exactly one verdict to each atomic claim: - Confirmed — current evidence meeting [Evidence standard] directly supports the complete atomic claim for the relevant legal entity, product, plan, region, period, and scope. - Partially confirmed — evidence supports only part of the claim or supports it only for a narrower entity, product, plan, region, period, condition, or scope. - Unsupported — no adequate supporting evidence was found or supplied within the stated research scope. Unsupported does not by itself mean that the claim is false. - Ambiguous — the wording, terminology, measurement, scope, ownership, timeframe, or intended interpretation is too unclear to assess reliably. - Contradicted — credible, relevant evidence directly conflicts with the atomic claim. Preserve the conflicting evidence and do not infer the cause without support. - Outdated — supporting evidence exists but is too old, superseded, or temporally mismatched for the current procurement decision. - Not enough evidence — access, source coverage, evidence quality, or the available research scope is insufficient to reach another verdict. A vendor-authored assertion alone may confirm only the narrower proposition that the vendor currently publishes or represents that statement. It does not independently confirm the underlying control, performance result, customer relationship, compliance status, or contractual commitment. Do not treat failure to find public evidence as proof that a claim is false. Record the search and access limitations and use Unsupported or Not enough evidence according to the distinction above. 9. Record conflicting evidence side by side. Explain differences in scope, date, entity, plan, geography, methodology, or terminology when supported; otherwise leave the cause unresolved. 10. Convert every decision-relevant evidence gap into a precise vendor question identifying the artifact, scope, date, or contractual commitment needed. DOMAIN-SPECIFIC CHECKS - Security and compliance: distinguish claimed, documented, certified, independently assessed, and contractually enforceable controls. Verify the standard, auditor or registry where public, audit period, report type, covered entity, product scope, exceptions, and document freshness. Do not equate a framework-aligned statement with certification. - Privacy and AI: distinguish model or subprocessors, customer-data use, training or improvement use, retention, deletion commitments, residency, cross-border transfers, human access, opt-out scope, logging, and contractual enforceability. Do not infer no-training or zero-retention commitments from general privacy language. - Performance: require a defined metric, test population, baseline, methodology, date, conditions, sample size when available, and independent reproducibility. Treat undefined accuracy, productivity, reliability, or best-in-class language as unsupported. - Pricing and contracts: identify currency, region, billing interval, plan, included usage, overages, minimum commitments, add-ons, implementation fees, renewal mechanics, cancellation terms, discounts, and source date. Published pricing is not proof of a buyer-specific final price; only supplied current contractual terms can evidence that price. - Customer proof: distinguish a vendor-displayed logo from a customer-authored confirmation. Check whether the relationship appears current, concerns the evaluated product, and supports the claimed use case or outcome. Do not contact customers or represent that a reference call occurred. - Competitors: compare only equivalent products, plans, regions, dates, and claim areas supported by evidence. Label missing or non-comparable data instead of ranking by assumption. REQUIRED DOSSIER Produce concise markdown with these sections: Keep the dossier concise and proportional to the number, materiality, and complexity of the claims and to the evidence actually available. Do not repeat the same claim, source description, evidence gap, or limitation across multiple sections unnecessarily. Use claim IDs and evidence IDs to cross-reference earlier records. Include only applicable domain-specific subsections. Where a subsection is genuinely outside scope or cannot be assessed, retain its heading when needed for decision clarity, state Not assessable, and explain briefly why. Never omit: - decision scope and research status; - claim inventory and verdict register; - evidence ledger; - decision-critical findings; - prioritized evidence requests; - research-informed decision posture; - verification and reconciliation record; - human review gates. Do not fill unsupported sections with generic procurement advice merely to complete the format. 1. Decision scope and research status State the vendor and product, decision, buyer context, cutoff date, required evidence level, material exclusions, missing or conflicting inputs, and a count of Requested, Executed, Proposed, Unavailable, and Unverified research items. State that no procurement approval has been granted by this dossier. 2. Claim inventory and verdict register Provide a table with: Claim ID; atomic claim; category; source of the claim; why it matters; required evidence; verdict; evidence strength; procurement reliance risk; and short rationale. Use these qualitative procurement-reliance risk labels: - High — accepting the claim without stronger evidence could materially change the buying decision or create substantial security, privacy, legal, financial, contractual, operational, customer, or reputational exposure. - Medium — the evidence gap is decision-relevant and should become a condition, vendor request, contractual requirement, or assigned follow-up, but it does not independently establish an immediate blocker. - Low — the claim is adequately supported for the stated evidence standard or the remaining uncertainty has limited consequence for the current decision. - Unknown — the available evidence, scope, or authority is insufficient to classify the reliance risk defensibly. Base each label on the importance of the claim, the evidence gap, the decision context, and the consequence of relying on it incorrectly. Do not infer likelihood or severity merely from generic industry experience. Do not convert the labels into a numerical score or present them as a comprehensive vendor-risk rating. 3. Evidence ledger Separate Vendor-authored, Independent, Buyer-supplied, and Unavailable evidence. For each accessible source provide: Evidence ID; title and publisher; source category; citation or URL; relevant date; claim IDs; exact support; strength; limitations; and access status. Do not list a source as independent if the vendor sponsored, republished, or supplied it unless that relationship is disclosed. 4. Material findings by claim For each High-risk or decision-critical claim, provide the verdict, supporting and conflicting evidence IDs, scope and freshness assessment, remaining uncertainty, buyer implication, and a proposed next step. Clearly label future steps as Proposed. 5. Security, privacy, AI, commercial, and customer-proof checks Include only applicable subsections. Map each supplied requirement or claim to evidence, unresolved gaps, and the artifact or contract language needed. If a subsection is not assessable, say why rather than producing a generic assessment. 6. Competitor evidence comparison If competitors were supplied, provide: claim area; vendor evidence; competitor evidence; comparability limits; and buyer implication. Omit unsupported rankings. 7. Prioritized vendor evidence requests Group precise questions by security and compliance, privacy and AI data use, pricing and contract, customer references, implementation, and support. Give each question a priority, linked claim ID, required response artifact, and acceptance condition. Do not state that questions were sent. 8. Decision posture Choose one: Choose one research-informed posture: - Proceed to approval review - Proceed to approval review with conditions - Delay approval review pending evidence - Do not proceed to approval review - Not enough evidence to form a posture. Tie the posture to specific claim IDs, conditions, unresolved evidence, residual reliance risks, and required human approvals. The posture indicates what the evidence supports as the next procurement step. It is not procurement approval, contract authorization, legal clearance, security acceptance, budget approval, or permission to onboard the vendor. 9. Verification and reconciliation record Report each check below as Pass, Fail, or Not assessable, with concrete evidence or an explanation: - Claim reconciliation: every material input claim appears once in the inventory or is identified as out of scope; provide input count, atomic claim count, and omitted-item count. - Verdict traceability: every verdict cites at least one evidence ID or explicitly states that no supporting evidence was found. - Citation entailment: each cited page supports the exact proposition attributed to it; identify citations that were not inspectable or did not support the proposition. - Scope match: security, compliance, privacy, pricing, performance, and customer evidence matches the relevant entity, product, plan, region, and period, or the mismatch is disclosed. - Freshness: source dates are recorded where available and evidence predating the stated cutoff or decision need is flagged with its resulting risk. - Source separation: vendor-authored, independent, buyer-supplied, and unavailable materials are not conflated. - Conflict handling: contradictory sources are retained and unresolved conflicts affect the verdict and risk. - Commercial reconciliation: quoted prices and terms identify currency, plan, region, billing basis, effective date, and contractual status where available. - Customer-proof threshold: no logo or vendor testimonial is reported as an independently confirmed current relationship without corroboration. - Completion integrity: every statement suggesting research, verification, contact, approval, testing, or completion is supported by evidence; otherwise it is relabeled Requested, Proposed, Unavailable, or Unverified. Acceptance requires all material claims to be reconciled, all verdicts to be traceable, all inaccessible evidence to be disclosed, and all decision-critical conflicts or gaps to appear in the vendor requests and decision posture. If any requirement fails, label the dossier Incomplete for procurement reliance and list the exact remediation needed. 10. Human review gates Identify the authorized functions that still need to review applicable legal terms, privacy obligations, security evidence, financial exposure, regulatory fit, and final procurement approval. Recommend escalation proportionate to risk, but do not assign approval that has not occurred.Input for this step
Provide exact claim wording, vendor materials, independent sources, dates, jurisdiction or market context, and known evidence gaps.
Carry forward
Carry the claim matrix, source record, contradictions, unanswered questions, and evidence limitations into the risk review.
Human checkpoint
Confirm that research findings are not represented as procurement approval or completed legal, security, or financial diligence.
-
Step 2 Review security, privacy, and data processing
Assess how the vendor handles data, access, subprocessors, retention, deletion, incidents, and contractual security commitments.
Prompt: AI Vendor Security and Data Processing Review BriefYou are a senior security, privacy, and AI governance reviewer supporting procurement, legal, security, compliance, and business stakeholders. Prepare an AI vendor security and data-processing review brief that evaluates the vendor’s security posture, privacy commitments, data lifecycle, model training use, subprocessors, retention, deletion, compliance fit, contractual risks, operational controls, and approval conditions. The goal is to help human stakeholders decide whether to approve, approve with conditions, defer, or reject an AI vendor before procurement, renewal, or expanded use. ## Context Placeholders Use the context below. If the vendor, product, intended use, or data categories are missing, ask for them before producing the review. If other inputs are missing, continue only with clearly labeled assumptions. - [Vendor, product, and intended use] - [Data categories, users, and access scope] - [Security and privacy documents] - [Compliance, contract, and DPA requirements] - [Model training, retention, and deletion terms] - [Subprocessors, support access, and data residency] - [Approval stakeholders and decision deadline] ## Important Constraints - Do not invent vendor claims, security controls, certifications, audit findings, contract terms, DPA language, compliance status, subprocessors, retention periods, deletion commitments, or stakeholder approvals. - Separate confirmed vendor evidence from assumptions, gaps, risks, and recommendations. - Label confidence level and uncertainty for every major conclusion. - Do not accept vendor marketing claims as evidence unless supported by supplied security, privacy, legal, technical, or contractual documents. - Do not present this output as legal, regulatory, procurement, financial, security, or compliance advice. - Contract interpretation, DPA terms, liability, indemnity, data protection, cross-border transfer, regulated data, and compliance obligations must be reviewed by qualified legal, privacy, security, or compliance owners. - Treat missing DPA, unclear model training terms, unclear retention, unclear deletion process, unknown subprocessors, weak access controls, poor logging, and lack of incident response evidence as review risks. - Do not recommend approval for sensitive, regulated, customer, employee, financial, health, children’s, biometric, confidential, or proprietary data use without explicit human review gates. - Do not recommend sharing secrets, credentials, production keys, source code, customer data, employee data, payment data, regulated data, or confidential documents unless the intended use, controls, and approvals support it. - Make recommendations specific to the supplied vendor materials, intended use, data categories, user groups, documents, compliance requirements, contract terms, approval stakeholders, and deadline. ## Step-by-Step Instructions 1. Summarize the vendor review context: - vendor name - product description - intended business use - user groups - data categories involved - deployment model - procurement or renewal context - approval stakeholders - decision deadline 2. Map the data lifecycle: - data collected - data uploaded by users - data generated by the AI system - data processed by the vendor - data stored - data retained - data deleted - data exported - data used for model training or improvement - data accessed by support staff - data shared with subprocessors - data transferred across regions 3. Review security evidence: - SOC 2 or equivalent report if supplied - ISO 27001 or equivalent certification if supplied - penetration test summary if supplied - vulnerability management - encryption in transit - encryption at rest - access control - SSO and MFA support - RBAC or least-privilege controls - audit logging - tenant isolation - incident response - business continuity - disaster recovery 4. Review privacy and data-processing evidence: - privacy policy - DPA - subprocessors - retention policy - deletion process - data residency - model training terms - opt-out terms - customer content ownership - support access - data export rights - cross-border transfer terms - data subject request support if relevant 5. Review AI governance concerns: - intended use risk - sensitive data exposure - human review needs - output reliability risk - hallucination or incorrect output risk - explainability needs - auditability - user permissions - prompt and output logging - model training boundaries - restricted use cases - policy alignment 6. Identify risk areas: - unacceptable risk - approval with conditions - missing evidence - contract gap - operational control gap - privacy gap - security gap - compliance gap - user training need - monitoring requirement 7. Prepare approval options: - approve - approve with conditions - defer pending evidence - reject - pilot only - low-risk limited use only 8. Create follow-up questions and owner-specific actions for security, legal, privacy, procurement, finance, IT, business owners, and executive reviewers. ## Output Format ### 1. Missing Context List missing inputs needed before a reliable AI vendor review can be completed. If enough context is available, say so. ### 2. Vendor Review Snapshot Use this table: | Area | Current View | Evidence Supplied | Risk or Uncertainty | |---|---|---|---| Cover vendor, product, intended use, users, data categories, documents, approval stakeholders, and deadline. ### 3. Data Lifecycle Map Use this table: | Data Stage | What Happens | Vendor Evidence | Risk | Follow-Up Needed | |---|---|---|---|---| Cover collection, upload, processing, storage, model training, retention, deletion, subprocessors, support access, export, and regional transfer. ### 4. Security Evidence Review Use this table: | Control Area | Evidence Supplied | Gap or Concern | Risk Level | Owner Follow-Up | |---|---|---|---|---| Cover access control, encryption, logging, SSO/MFA, RBAC, tenant isolation, incident response, vulnerability management, and business continuity where relevant. ### 5. Privacy and Contract Evidence Review Use this table: | Area | Evidence Supplied | Gap or Concern | Required Review | |---|---|---|---| Cover privacy policy, DPA, retention, deletion, subprocessors, data residency, model training, opt-out rights, support access, cross-border transfer, and customer content ownership. ### 6. AI Governance Risk Register Use this table: | Risk | Evidence | Impact | Severity | Mitigation or Condition | |---|---|---|---|---| ### 7. Required Follow-Ups Use this table: | Follow-Up Question or Action | Owner Role | Why It Matters | Required Before Approval? | |---|---|---|---| ### 8. Approval Options Use this table: | Option | When Appropriate | Conditions | Residual Risk | |---|---|---|---| Include approve, approve with conditions, defer, reject, pilot only, and limited-use approval where relevant. ### 9. Human Approval Recommendation Provide a clear recommendation: approve, approve with conditions, defer, reject, pilot only, or limited-use approval. Include rationale, confidence level, conditions, unresolved questions, and required human review gates. ### 10. Executive Brief Provide a concise leadership-ready summary covering intended use, data involved, top risks, missing evidence, approval recommendation, required conditions, and decision deadline. ### 11. Missing Inputs and Human Checks List assumptions made, blocked decisions, unresolved risks, confidence level, and reviews required from security, legal, privacy, procurement, IT, business owners, finance, or executives. ## Verification Checklist Before finalizing, confirm that: - no vendor claim is accepted without evidence or caveat - data categories and user groups are clearly identified - data handling, retention, deletion, model training, subprocessors, support access, and data residency are addressed - security controls are separated from privacy and contract controls - sensitive or regulated data use requires human review - approval recommendation includes conditions and residual risk - legal and compliance interpretations are flagged for qualified review - missing documents and follow-up questions are clearly listed - final output does not present assumptions as facts ## Final Instruction to Begin Begin now. First review the supplied vendor, product, intended use, data categories, user groups, security documents, privacy documents, compliance requirements, contract terms, model training terms, retention terms, subprocessors, support access, approval stakeholders, and decision deadline. If required context is missing, ask for it. Otherwise, produce the full AI vendor security and data-processing review brief in the requested markdown format.Input for this step
Provide the claim dossier plus the vendor security pack, privacy terms, data-flow description, subprocessors, certifications, and required controls.
Carry forward
Carry material risks, exceptions, missing evidence, proposed mitigations, and accountable owners into procurement scoring.
Human checkpoint
Require qualified security, privacy, legal, or compliance review for issues outside the reviewer’s authority.
-
Step 3 Evaluate procurement fit and decision risk
Apply the organization’s actual requirements to business fit, integration, cost, governance, security, and implementation readiness.
Prompt: AI Vendor Evaluation and Procurement Risk ScorecardYou are an expert AI procurement advisor specializing in vendor evaluation, data privacy, security, compliance, cost analysis, integration risk, and responsible AI governance. Your task is to help a business evaluate an AI vendor or AI tool before purchase, approval, renewal, or rollout. Context: Business context: [Business context] AI tool or vendor name: [AI tool or vendor name] Vendor website or product summary: [Vendor website or product summary] Intended use case: [Intended use case] Departments or users: [Departments or users] Data the tool will access: [Data the tool will access] Data the tool will store or process: [Data the tool will store or process] Integrations required: [Integrations required] Compliance requirements: [Compliance requirements] Security requirements: [Security requirements] Budget or pricing information: [Budget or pricing information] Contract or procurement constraints: [Contract or procurement constraints] Existing alternatives: [Existing alternatives] Risk tolerance: [Risk tolerance] Definition of done: [Definition of done] Important constraints: - Do not approve a vendor blindly. - Do not assume security or compliance claims are true unless evidence is provided. - If information is missing, list the questions the business should ask the vendor. - Consider data protection, access controls, retention, model training, auditability, cost, and lock-in. - Keep the evaluation practical for business decision-makers. Task: 1. Summarize the vendor and use case. Explain: - What the tool does - Who will use it - What business problem it solves - What systems it may connect to - What data it may access - Why the evaluation matters 2. Create a vendor evaluation scorecard. Use a 1–5 score for: - Business fit - Ease of use - Security posture - Data privacy - Compliance readiness - Admin controls - Audit logs - Integration fit - Cost transparency - Vendor maturity - Support quality - Exit or portability risk 3. Assess data handling risk. Review: - What data enters the tool - Whether sensitive data is involved - Whether data may be used for model training - Whether data is retained - Whether users can delete data - Where data may be hosted - Whether access controls are sufficient 4. Assess security and compliance. Evaluate: - Authentication options - SSO or MFA support - Role-based access controls - Audit logs - Encryption - Data retention - Incident response - Compliance certifications - Vendor security documentation - Admin visibility 5. Assess operational fit. Review: - User onboarding - Workflow fit - Integration needs - Training requirements - Support needs - Change management - Internal ownership - Rollout complexity 6. Assess commercial and lock-in risk. Evaluate: - Pricing model - Hidden costs - Contract terms - Renewal risk - Export options - Switching cost - Dependency risk 7. Create a risk register. Use a table with: Risk | Category | Severity | Evidence Needed | Mitigation | Owner | Priority 8. Create vendor questions. Provide questions to ask the vendor about: - Security - Privacy - Model training - Data retention - Compliance - Admin controls - Audit logs - Integrations - Pricing - Support - Exit process 9. Provide a recommendation. Classify the decision as: - Approve - Approve with conditions - Pilot first - Defer pending information - Reject Explain the rationale. 10. Create a safe rollout plan. Include: - Pilot group - Data restrictions - Approved use cases - Admin setup - Training - Monitoring - Review date - Success metrics Output format: ## Executive Summary ## Vendor and Use Case Summary ## Evaluation Scorecard ## Data Handling Risk Assessment ## Security and Compliance Assessment ## Operational Fit Assessment ## Commercial and Lock-In Risk ## Risk Register ## Vendor Questions ## Recommendation ## Safe Rollout Plan ## Final Decision Checklist Verification: Before finalizing, check that: - Missing vendor information is clearly identified. - Sensitive data risks are not ignored. - Recommendation is based on evidence and risk. - Approval conditions are practical. - The rollout plan includes safeguards. Begin the AI vendor evaluation now.Input for this step
Provide the verified claims, risk review, decision criteria, commercial assumptions, operational requirements, and acceptable exceptions.
Carry forward
Carry the structured scorecard, disqualifiers, conditions, tradeoffs, and remaining evidence needs into the decision brief.
Human checkpoint
Do not invent weights, policy thresholds, approval rules, or acceptable risk levels that the organization has not supplied.
-
Step 4 Prepare the procurement decision brief
Condense the traceable evidence, options, tradeoffs, risks, and conditions into a decision-ready brief for the authorized owner.
Prompt: Executive Decision Brief PromptAct as a senior Business specialist using ChatGPT. Your task is: [Goal or task]. Context: - Current situation: [Current context] - Constraints: [Constraints] - Available materials: [Files, data, examples, URLs, logs, notes] - Success criteria: [Definition of done] Workflow: 1. Restate the objective in operational terms and identify any missing information that would block a reliable answer. 2. Make reasonable assumptions only when they are low risk, and label them clearly. 3. Produce the main deliverable for "Executive Decision Brief Prompt" with enough detail that a skilled operator can execute it immediately. 4. Include edge cases, failure modes, dependencies, and tradeoffs that a junior prompt would usually miss. 5. Add a verification checklist with concrete tests, review questions, metrics, or acceptance criteria. 6. End with the smallest safe next action. Output format: - Executive summary - Detailed plan or implementation - Risks and mitigations - Verification checklist - Next action Do not give generic advice. Optimize for a production-quality strategy outcome.Input for this step
Provide the claim dossier, risk review, scorecard, commercial options, stakeholder constraints, and outstanding decisions.
Carry forward
Use the brief as the human decision packet; preserve links to the underlying evidence and unresolved items.
Human checkpoint
The authorized procurement owner makes the final approval, rejection, conditional approval, or further-diligence decision.
Completion criteria
Material claims are traced to evidence, unresolved security and privacy issues are explicit, procurement criteria are applied consistently, and the final recommendation identifies conditions, owners, and evidence still required before approval.
Related Workflows
Browse WorkflowsSafe AI Agent Workflow Selection and Deployment Readiness
Move from a broad list of AI opportunities to one prioritized, mapped, governed, and measurable agent workflow that is ready for an informed pilot decision.
Production Incident to Safe Patch and Prevention Plan
Turn production logs and repository evidence into a minimal patch proposal, verification plan, independent review, deployment controls, and a blameless prevention backlog.
Was this useful?