Reusable AI capability
Assess Vendor Procurement Package Readiness
Assess whether a proposed vendor procurement package contains sufficient requirements, evidence, controls, ownership, and commercial information to proceed into formal due diligence.
This Skill packages a reusable way to use the linked Prompt or Workflow; Amo.ng does not run it for you.
# Assess Vendor Procurement Package Readiness Skill ID: AMO-S-000004 Skill URL: https://amo.ng/skills/evaluate-vendors-for-procurement-readiness Purpose: Give the procurement owner a reusable intake gate for deciding whether one proposed vendor package is ready to enter due diligence, which evidence is still missing, and who must supply it—without selecting the vendor or performing the due-diligence decision itself. Required inputs: - Proposed vendor, intended purchase, business outcome, scope, timetable, and procurement owner - Prioritized business, technical, service, integration, accessibility, and operational requirements - Data categories, access model, security, privacy, compliance, resilience, and mandatory-control requirements - Vendor proposal, pricing, commercial assumptions, contract or order-form materials, and supporting evidence currently available - Decision roles across procurement, business, finance, security, privacy, legal, technical, and operational review - Mandatory intake criteria, approval thresholds, known constraints, and evidence already requested How to use: When to use: - A specific vendor proposal or procurement package is being prepared for formal due diligence. - An intake owner needs to distinguish a reviewable package from one that is too incomplete or internally inconsistent to assess efficiently. - New evidence has arrived and the package's readiness must be reassessed before the next procurement stage. When not to use: - Sourcing, ranking, or selecting among vendors. - Performing the full security, privacy, legal, commercial, technical, or operational due-diligence review. - Approving a vendor, contract, purchase, exception, or production access. - Vendor renewal, renegotiation, resizing, replacement, or exit; use the vendor-renewal capability instead. - SaaS portfolio consolidation or redundancy analysis. Reusable procurement-package readiness method: 1. Define the proposed purchase, intended outcome, scope, timetable, mandatory intake criteria, decision roles, and the due-diligence stage the package must support. 2. Build a package inventory covering requirements, vendor claims, product and service scope, data and access, controls, architecture and integrations, commercial terms, ownership, and available supporting evidence. 3. For each required item, record whether it is supplied, attributable, current, internally consistent, decision-usable, missing, or not applicable. Do not treat a vendor assertion or document title as proof that the underlying claim is valid. 4. Map prioritized requirements and mandatory controls to the supplied evidence. Identify conflicts, ambiguous scope, unsupported assumptions, absent owners, non-comparable pricing, and evidence that belongs in deeper due diligence. 5. Classify each gap as an intake blocker, a condition that may be resolved during due diligence, an owner clarification, or a later-stage question. State why it affects readiness. 6. Issue owner-specific evidence requests with the artifact, acceptable source, deadline, and readiness condition required to close each blocker or condition. 7. Issue exactly one package-readiness recommendation: Proceed to due diligence, Proceed with conditions, or Not ready. Define the permitted next stage and do not convert readiness into vendor approval. Expected output: A procurement-package readiness record containing the package inventory, requirements-to-evidence map, ownership map, blocker and condition register, conflicting or missing information, owner-specific evidence requests, bounded due-diligence handoff, and one Proceed, Proceed with conditions, or Not ready recommendation. Evidence and authority boundaries: - Separate supplied evidence, vendor assertions, internal assumptions, unresolved questions, and material not inspected. - Do not invent product capabilities, certifications, control effectiveness, pricing, contractual terms, approvals, legal requirements, or review results. - The procurement owner controls admission into due diligence. Finance, security, privacy, legal, technical, accessibility, and operational reviewers define evidence needed in their domains; their intake input is not final approval. - Contract commitment, vendor selection, exception acceptance, data access, production access, and purchase approval remain outside this Skill. - Use AMO-W-000002 as the source for the deeper due-diligence journey after this readiness gate is passed. Powered by Workflow: Vendor Procurement Due Diligence Source ID: AMO-W-000002 https://amo.ng/workflows/vendor-procurement-due-diligence Completion criteria: Complete when: - The proposed purchase, intended outcome, scope, timetable, mandatory intake criteria, and accountable roles are explicit. - Every required package element has a supplied, missing, conditional, or not-applicable disposition with evidence provenance. - Requirements and mandatory controls map to available evidence without treating claims as verified due-diligence findings. - Every blocker and condition has an owner, specific evidence request, acceptable source, deadline, and closure condition. - The recommendation is exactly Proceed to due diligence, Proceed with conditions, or Not ready, with rationale and permitted next steps. - The record explicitly avoids vendor selection, full due diligence, contract approval, purchase authorization, and production-access decisions. Use this Amo.ng Skill with your preferred AI tool. Supply the required inputs and follow the usage instructions. # Assess Vendor Procurement Package Readiness Skill ID: AMO-S-000004 Skill URL: https://amo.ng/skills/evaluate-vendors-for-procurement-readiness Purpose: Give the procurement owner a reusable intake gate for deciding whether one proposed vendor package is ready to enter due diligence, which evidence is still missing, and who must supply it—without selecting the vendor or performing the due-diligence decision itself. Required inputs: - Proposed vendor, intended purchase, business outcome, scope, timetable, and procurement owner - Prioritized business, technical, service, integration, accessibility, and operational requirements - Data categories, access model, security, privacy, compliance, resilience, and mandatory-control requirements - Vendor proposal, pricing, commercial assumptions, contract or order-form materials, and supporting evidence currently available - Decision roles across procurement, business, finance, security, privacy, legal, technical, and operational review - Mandatory intake criteria, approval thresholds, known constraints, and evidence already requested How to use: When to use: - A specific vendor proposal or procurement package is being prepared for formal due diligence. - An intake owner needs to distinguish a reviewable package from one that is too incomplete or internally inconsistent to assess efficiently. - New evidence has arrived and the package's readiness must be reassessed before the next procurement stage. When not to use: - Sourcing, ranking, or selecting among vendors. - Performing the full security, privacy, legal, commercial, technical, or operational due-diligence review. - Approving a vendor, contract, purchase, exception, or production access. - Vendor renewal, renegotiation, resizing, replacement, or exit; use the vendor-renewal capability instead. - SaaS portfolio consolidation or redundancy analysis. Reusable procurement-package readiness method: 1. Define the proposed purchase, intended outcome, scope, timetable, mandatory intake criteria, decision roles, and the due-diligence stage the package must support. 2. Build a package inventory covering requirements, vendor claims, product and service scope, data and access, controls, architecture and integrations, commercial terms, ownership, and available supporting evidence. 3. For each required item, record whether it is supplied, attributable, current, internally consistent, decision-usable, missing, or not applicable. Do not treat a vendor assertion or document title as proof that the underlying claim is valid. 4. Map prioritized requirements and mandatory controls to the supplied evidence. Identify conflicts, ambiguous scope, unsupported assumptions, absent owners, non-comparable pricing, and evidence that belongs in deeper due diligence. 5. Classify each gap as an intake blocker, a condition that may be resolved during due diligence, an owner clarification, or a later-stage question. State why it affects readiness. 6. Issue owner-specific evidence requests with the artifact, acceptable source, deadline, and readiness condition required to close each blocker or condition. 7. Issue exactly one package-readiness recommendation: Proceed to due diligence, Proceed with conditions, or Not ready. Define the permitted next stage and do not convert readiness into vendor approval. Expected output: A procurement-package readiness record containing the package inventory, requirements-to-evidence map, ownership map, blocker and condition register, conflicting or missing information, owner-specific evidence requests, bounded due-diligence handoff, and one Proceed, Proceed with conditions, or Not ready recommendation. Evidence and authority boundaries: - Separate supplied evidence, vendor assertions, internal assumptions, unresolved questions, and material not inspected. - Do not invent product capabilities, certifications, control effectiveness, pricing, contractual terms, approvals, legal requirements, or review results. - The procurement owner controls admission into due diligence. Finance, security, privacy, legal, technical, accessibility, and operational reviewers define evidence needed in their domains; their intake input is not final approval. - Contract commitment, vendor selection, exception acceptance, data access, production access, and purchase approval remain outside this Skill. - Use AMO-W-000002 as the source for the deeper due-diligence journey after this readiness gate is passed. Powered by Workflow: Vendor Procurement Due Diligence Source ID: AMO-W-000002 https://amo.ng/workflows/vendor-procurement-due-diligence Completion criteria: Complete when: - The proposed purchase, intended outcome, scope, timetable, mandatory intake criteria, and accountable roles are explicit. - Every required package element has a supplied, missing, conditional, or not-applicable disposition with evidence provenance. - Requirements and mandatory controls map to available evidence without treating claims as verified due-diligence findings. - Every blocker and condition has an owner, specific evidence request, acceptable source, deadline, and closure condition. - The recommendation is exactly Proceed to due diligence, Proceed with conditions, or Not ready, with rationale and permitted next steps. - The record explicitly avoids vendor selection, full due diligence, contract approval, purchase authorization, and production-access decisions.Copy skill copies the Skill details. Use with AI adds a short instruction for your preferred AI tool; neither action runs the Skill.
Purpose
Give the procurement owner a reusable intake gate for deciding whether one proposed vendor package is ready to enter due diligence, which evidence is still missing, and who must supply it—without selecting the vendor or performing the due-diligence decision itself.
Required inputs
Have these details available before following the usage instructions.
- Proposed vendor, intended purchase, business outcome, scope, timetable, and procurement owner
- Prioritized business, technical, service, integration, accessibility, and operational requirements
- Data categories, access model, security, privacy, compliance, resilience, and mandatory-control requirements
- Vendor proposal, pricing, commercial assumptions, contract or order-form materials, and supporting evidence currently available
- Decision roles across procurement, business, finance, security, privacy, legal, technical, and operational review
- Mandatory intake criteria, approval thresholds, known constraints, and evidence already requested
How to use this Skill
When to use:
- A specific vendor proposal or procurement package is being prepared for formal due diligence.
- An intake owner needs to distinguish a reviewable package from one that is too incomplete or internally inconsistent to assess efficiently.
- New evidence has arrived and the package's readiness must be reassessed before the next procurement stage.
When not to use:
- Sourcing, ranking, or selecting among vendors.
- Performing the full security, privacy, legal, commercial, technical, or operational due-diligence review.
- Approving a vendor, contract, purchase, exception, or production access.
- Vendor renewal, renegotiation, resizing, replacement, or exit; use the vendor-renewal capability instead.
- SaaS portfolio consolidation or redundancy analysis.
Reusable procurement-package readiness method:
1. Define the proposed purchase, intended outcome, scope, timetable, mandatory intake criteria, decision roles, and the due-diligence stage the package must support.
2. Build a package inventory covering requirements, vendor claims, product and service scope, data and access, controls, architecture and integrations, commercial terms, ownership, and available supporting evidence.
3. For each required item, record whether it is supplied, attributable, current, internally consistent, decision-usable, missing, or not applicable. Do not treat a vendor assertion or document title as proof that the underlying claim is valid.
4. Map prioritized requirements and mandatory controls to the supplied evidence. Identify conflicts, ambiguous scope, unsupported assumptions, absent owners, non-comparable pricing, and evidence that belongs in deeper due diligence.
5. Classify each gap as an intake blocker, a condition that may be resolved during due diligence, an owner clarification, or a later-stage question. State why it affects readiness.
6. Issue owner-specific evidence requests with the artifact, acceptable source, deadline, and readiness condition required to close each blocker or condition.
7. Issue exactly one package-readiness recommendation: Proceed to due diligence, Proceed with conditions, or Not ready. Define the permitted next stage and do not convert readiness into vendor approval.
Expected output:
A procurement-package readiness record containing the package inventory, requirements-to-evidence map, ownership map, blocker and condition register, conflicting or missing information, owner-specific evidence requests, bounded due-diligence handoff, and one Proceed, Proceed with conditions, or Not ready recommendation.
Evidence and authority boundaries:
- Separate supplied evidence, vendor assertions, internal assumptions, unresolved questions, and material not inspected.
- Do not invent product capabilities, certifications, control effectiveness, pricing, contractual terms, approvals, legal requirements, or review results.
- The procurement owner controls admission into due diligence. Finance, security, privacy, legal, technical, accessibility, and operational reviewers define evidence needed in their domains; their intake input is not final approval.
- Contract commitment, vendor selection, exception acceptance, data access, production access, and purchase approval remain outside this Skill.
- Use AMO-W-000002 as the source for the deeper due-diligence journey after this readiness gate is passed.
Powered by an Amo.ng Workflow
Vendor Procurement Due Diligence
Open the linked workflow to use the instructions that power this Skill.
Open workflow
# Vendor Procurement Due Diligence
Workflow ID: AMO-W-000002
Workflow URL: https://amo.ng/workflows/vendor-procurement-due-diligence
## 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.
**Review note**
Confirm that research findings are not represented as procurement approval or completed legal, security, or financial diligence.
**Prompt ID**
AMO-P-000137
**Prompt URL**
https://amo.ng/prompts/vendor-claims-fact-check-dossier
**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.
**Review note**
Require qualified security, privacy, legal, or compliance review for issues outside the reviewer’s authority.
**Prompt ID**
AMO-P-000158
**Prompt URL**
https://amo.ng/prompts/ai-vendor-security-data-processing-review-brief
**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**
Evidence-Grounded 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.
**Review note**
Do not invent weights, policy thresholds, approval rules, or acceptable risk levels that the organization has not supplied.
**Prompt ID**
AMO-P-000086
**Prompt URL**
https://amo.ng/prompts/ai-vendor-evaluation-procurement-risk-scorecard
**Prompt content**
Evaluate the proposed AI vendor for procurement or renewal using only the supplied materials and any sources ChatGPT can actually access in the current session. Produce decision support for authorized business, procurement, security, privacy, legal, and compliance reviewers; do not present the analysis itself as organizational approval.
## Evaluation 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]
## Input and access rules
Treat the vendor identity, intended use, affected users, expected data categories, material integrations, applicable requirements, risk tolerance, and decision objective as minimum inputs. If any are absent or materially ambiguous, ask a concise set of blocking questions before issuing a recommendation. You may still create a clearly labeled preliminary assessment when bounded progress is safe.
Pricing details, contracts, data processing terms, security reports, subprocessors, architecture diagrams, retention schedules, incident history, accessibility reports, support terms, and exit documentation are useful supporting inputs. Mark their absence as an evidence gap rather than inventing their contents.
Use ChatGPT to organize supplied evidence, compare claims with requirements, expose conflicts, calculate transparent scores, and draft questions and controls. Do not imply that ChatGPT accessed a website, contract, private system, vendor portal, configuration, certification report, or live integration unless that access occurred in the current session. A URL alone is not evidence of its contents. If browsing is available and used, identify the pages consulted and retrieval date; otherwise request pasted or uploaded source material.
Do not contact the vendor, accept terms, approve expenditure, sign a contract, change configurations, connect an integration, provision users, upload business data, run a pilot, delete records, or certify compliance. Those actions require authorized humans and, where applicable, security, privacy, legal, compliance, procurement, and system-owner approval.
Do not request passwords, API secrets, private keys, authentication tokens, or unnecessary personal data. Recommend redacted documents and synthetic or de-identified pilot data where practical.
## Evidence discipline
Create an evidence ledger and assign each source a stable identifier. For every material conclusion, score, risk, and decision condition, cite one or more evidence identifiers or mark it unsupported.
Classify information as one of the following:
- Supplied fact: directly stated in business-provided material.
- Vendor claim: stated by the vendor but not independently or contractually verified.
- Independent evidence: supported by a credible third party, with scope and date recorded.
- Contractual commitment: contained in applicable executed or proposed terms, with the relevant clause identified.
- Observation: directly visible from an artifact or authorized demonstration available in the session.
- Assumption: a declared premise used for bounded analysis.
- Unknown: no adequate evidence is available.
- Conflict: sources disagree or apply to different products, plans, regions, or dates.
Never convert a vendor claim into a verified control. Check whether evidence applies to the correct product, service tier, hosting region, deployment model, integration, legal entity, and evaluation date. Flag stale, marketing-only, partial, inaccessible, or scope-mismatched evidence. Preserve conflicting claims and state what would reconcile them.
## Evaluation workflow
### 1. Establish scope and data flow
Summarize the business outcome, users, administrators, deployment model, integrations, and alternatives. Map the expected flow of prompts, files, recordings, metadata, outputs, telemetry, support data, and account data through collection, transmission, storage, model processing, human review, subprocessors, export, retention, deletion, and backup expiry.
Classify likely data sensitivity, including public, internal, confidential, personal, special-category, financial, health, customer, employee, authentication, intellectual-property, or regulated data. Do not assume a data category is permitted merely because the tool can process it.
### 2. Inventory and qualify evidence
Build the evidence ledger before scoring. Record source, owner or publisher, document date, retrieval date when applicable, product and plan scope, region, evidence class, relevant claim, limitations, and identifier. List missing critical artifacts such as a data processing agreement, security report, subprocessor list, retention policy, model-training terms, deletion procedure, breach notice terms, service levels, pricing schedule, and export documentation.
### 3. Apply critical decision gates
Evaluate these gates before calculating an overall result:
- Prohibited or unapproved data would enter the service.
- The vendor cannot explain training, retention, deletion, residency, or subprocessors for material data.
- Required SSO, MFA, role-based access, audit logging, encryption, tenant isolation, or administrator controls are absent or unverified.
- Applicable legal, regulatory, contractual, records-management, intellectual-property, accessibility, or data-transfer requirements cannot be met.
- Material contract terms conflict with mandatory requirements or accepted risk.
- The use case creates high-impact automated decisions without appropriate human oversight, testing, appeal, and accountability.
- No feasible containment, offboarding, export, access revocation, or incident-response path exists.
A failed gate should normally lead to Reject, Defer pending information, or a tightly restricted Pilot first recommendation. Explain any exception and identify the human risk owner authorized to accept it.
### 4. Score the vendor
Score each category from 1 to 5 only when enough evidence exists:
1 = confirmed material failure or unacceptable exposure
2 = major gaps requiring substantial remediation
3 = partially meets requirements with enforceable conditions
4 = meets documented requirements
5 = exceeds requirements with strong, applicable evidence
Use NE for not enough evidence and NA only when a category is genuinely irrelevant. Do not treat NE as zero or silently exclude it. Report evidence coverage as the percentage of applicable categories with a supported score. Do not issue a numeric overall score when coverage is below 70 percent or when security, privacy, compliance, or data-governance gates remain unresolved.
Assess:
- Business fit and measurable value
- Usability, accessibility, and adoption fit
- Security architecture and assurance
- Privacy and data protection
- Compliance and contractual readiness
- Identity, roles, and administrator controls
- Auditability, logging, and monitoring
- Integration and technical fit
- Pricing transparency and total cost exposure
- Vendor maturity, resilience, and incident response
- Support and service management
- Portability, termination, and lock-in risk
For every score, provide the rationale, evidence identifiers, confidence level, requirement gap, and condition needed to improve the score. If priorities justify weighting, show the proposed weights and obtain human agreement before using a weighted total; otherwise use equal weights and label the result provisional.
### 5. Perform domain assessments
Evaluate data use for foundation-model training, fine-tuning, product improvement, human review, abuse monitoring, and telemetry. Examine opt-out scope, default settings, retention periods, deletion behavior, backup expiry, legal holds, residency, cross-border transfers, subprocessors, data ownership, output rights, confidentiality, and intellectual-property protections.
Evaluate authentication, SSO, MFA, lifecycle provisioning, least privilege, role separation, service accounts, encryption, key management, tenant isolation, secure development, vulnerability management, penetration testing, audit reports, log availability, incident notification, business continuity, disaster recovery, recovery objectives, and administrator visibility. Distinguish certification possession from control effectiveness and scope.
Evaluate onboarding, workflow change, training, acceptable-use rules, support escalation, accessibility, internal ownership, model-output review, accuracy limitations, bias or harmful-output risks, monitoring, incident handling, and shadow-use risk.
Evaluate licensing units, usage limits, implementation services, integration work, storage, support tiers, overages, taxes, price escalation, renewal notice, minimum commitments, suspension rights, indemnities, liability limits, insurance, service levels, termination assistance, export formats, deletion commitments, and switching costs. Separate known prices from estimates and identify estimate assumptions.
### 6. Build the risk and control package
Create a risk register covering privacy, security, compliance, legal, commercial, operational, integration, model behavior, vendor viability, and exit risk. Each risk must include cause, event, consequence, affected data or process, inherent severity and likelihood, evidence, existing controls, proposed treatment, residual risk, owner, due date, decision gate, and status.
Create a prioritized vendor evidence request. Questions must be answerable and tied to a specific gap, risk, score, or contract condition. Separate requests for documents, written confirmations, product demonstrations, technical validation, and contract amendments.
### 7. Form the recommendation
Choose exactly one recommendation:
- Approve
- Approve with conditions
- Pilot first
- Defer pending information
- Reject
An Approve recommendation requires supported critical controls, acceptable residual risk, adequate evidence coverage, and no unresolved mandatory gate. Approve with conditions requires named conditions, accountable owners, deadlines, and a consequence if a condition is not met. Pilot first requires a bounded hypothesis and safeguards; it is not production approval. Defer pending information must list the evidence needed to resume. Reject must identify the failed requirements and whether reconsideration is possible.
State which authorized functions must review or approve the decision. Never state that the vendor has been approved, verified, certified, contracted, configured, tested, deployed, monitored, or deleted unless supplied execution evidence proves that action occurred. Use proposed, pending, unverified, blocked, or not performed as appropriate.
### 8. Design a safeguarded pilot when appropriate
If the recommendation permits a pilot, define its business hypothesis, participants, duration, approved use cases, prohibited uses, data restrictions, synthetic-data preference, administrator configuration, access controls, logging, human review, user training, support route, incident procedure, success metrics, failure thresholds, review date, and accountable owner.
Include stop conditions for unauthorized data exposure, material control failure, unexpected training or retention behavior, security incident, harmful output, regulatory conflict, uncontrolled cost, or inability to export or delete pilot data. Provide a recovery and exit procedure covering disabled access, revoked integrations and tokens, data export, deletion request, backup-expiry confirmation, record preservation, user communication, and fallback workflow. Label all of these as proposed until execution evidence is supplied.
## Required deliverable
### A. Decision brief
Include the recommendation, confidence, evidence coverage, critical gates, top risks, expected business value, estimated commercial exposure, mandatory conditions, and required human approvers.
### B. Scope and data-flow map
Use a table with: Stage | Data or metadata | Sensitivity | Source | Recipient or subprocessor | Purpose | Region | Retention | Training or improvement use | Control | Evidence ID | Unknowns.
### C. Evidence ledger
Use a table with: Evidence ID | Artifact or source | Evidence class | Publisher or owner | Date | Product, plan, and region scope | Supported claim | Limitations | Status.
### D. Critical-gate assessment
Use a table with: Gate | Requirement | Expected observation | Actual supported observation | Evidence ID | Pass, Fail, or Unresolved | Consequence | Required resolution.
### E. Evaluation scorecard
Use a table with: Category | Score or NE or NA | Weight if agreed | Rationale | Evidence ID | Confidence | Requirement gap | Improvement condition. Show evidence coverage and any permitted aggregate calculation.
### F. Detailed assessments
Provide separate findings for data governance and privacy, security and assurance, compliance and contracting, operational and model-risk fit, integrations, commercial exposure, and portability. For each finding state the requirement, supported observation, evidence, gap, risk, and proposed control.
### G. Risk register
Use the fields defined in the risk and control package. Rank risks without hiding low-confidence or unresolved high-impact items.
### H. Vendor evidence requests and negotiation points
Prioritize each item as blocking, pre-contract, pre-pilot, pre-production, or monitor. Link every request to an evidence gap, risk identifier, score, or decision condition.
### I. Recommendation and approval path
State the selected recommendation, rationale, rejected alternatives, residual risks, conditions, owners, deadlines, escalation route, and required reviewers. Clearly distinguish advisory analysis from formal approval.
### J. Pilot, rollout, monitoring, and exit controls
When relevant, provide the proposed pilot plan, production-entry criteria, metrics, review cadence, incident triggers, stop conditions, fallback, and offboarding evidence requirements. If a pilot is unsafe or premature, state why instead of drafting an executable rollout.
### K. Verification and acceptance matrix
Use a table with: Check | Expected evidence or observation | Actual supplied evidence or observation | Evidence ID | Status | Owner | Resolution needed. At minimum reconcile data-use terms, retention and deletion, subprocessors and residency, identity controls, audit logging, incident terms, contractual requirements, price assumptions, export capability, pilot safeguards, and unresolved source conflicts.
### L. Final decision checklist
Confirm whether minimum inputs are complete, critical evidence is applicable and current, unsupported claims are labeled, scores trace to evidence, gate failures control the recommendation, commercial totals reconcile with stated assumptions, risk owners are assigned, conditions are measurable, required approvers are named, and proposed actions are not misrepresented as completed.
End with a short section titled Unresolved Items and Handoff that lists blocking unknowns, who must resolve them, the evidence required, and the next authorized decision point.
## 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 procurement owner’s decision packet; preserve links to the underlying evidence and unresolved items.
**Review note**
The authorized procurement owner makes the final approval, rejection, conditional approval, or further-diligence decision.
**Prompt ID**
AMO-P-000011
**Prompt URL**
https://amo.ng/prompts/executive-decision-brief-prompt
**Prompt content**
Prepare an executive decision brief for the following decision.
Decision inputs
- Decision question: [Decision question]
- Decision owner and approval authority: [Decision owner and approval authority]
- Decision deadline: [Decision deadline]
- Business context: [Business context]
- Options already under consideration: [Options under consideration]
- Evidence pack: [Evidence pack]
- Constraints and non-negotiables: [Constraints and non-negotiables]
- Decision criteria and priorities: [Decision criteria and priorities]
- Affected stakeholders: [Affected stakeholders]
- Risk, authority, and escalation limits: [Risk, authority, and escalation limits]
- Definition of a decision-ready brief: [Definition of done]
Input requirements
Treat the decision question, accountable owner, deadline, known constraints, and at least one credible source describing the current situation as minimum inputs. Financial baselines, operating metrics, forecasts, customer evidence, contracts, policies, prior decisions, stakeholder positions, and option estimates are useful supporting inputs.
If the decision question, authority, material constraints, or baseline evidence is missing or contradictory, ask only the questions that block responsible comparison or recommendation. If answers are unavailable, continue only where bounded analysis is safe. Preserve each unresolved item as an unknown, conflict, or assumption; do not manufacture figures, stakeholder agreement, approvals, or evidence.
Evidence and tool rules
1. Use ChatGPT to organize supplied material, test reasoning, compare options, calculate only from provided figures, and draft the brief. State any calculation method and show enough working for review.
2. Do not imply access to internal systems, live dashboards, private links, meetings, or external sources unless their contents are actually available in the conversation. A URL alone is not evidence if its relevant content cannot be inspected.
3. Classify material claims as one of: supplied fact, direct observation from supplied material, calculation, stakeholder assertion, assumption, hypothesis, forecast, unknown, or conflict. Cite the file, excerpt, table, date, or source label supplied by the user whenever available.
4. Separate historical results from forecasts and correlation from demonstrated causation. Flag stale data, mismatched periods, inconsistent definitions, selection bias, omitted costs, optimistic adoption assumptions, and unsupported precision.
5. Never describe an option as approved, funded, validated, compliant, tested, launched, communicated, or completed unless the supplied evidence proves that state. Keep proposed, pending approval, blocked, unverified, and executed states distinct.
Decision analysis workflow
1. Frame the decision: Rewrite the question as a specific choice to be made by the named owner by the deadline. Define what is in scope, what is excluded, why a decision is needed now, and the consequences of delay or no decision.
2. Establish the baseline: Summarize the current operating and financial position using the most decision-relevant metrics. Record metric definitions, periods, sources, and known data-quality limitations. Distinguish verified baseline values from estimates.
3. Confirm decision rights: Identify the recommender, approver, consulted parties, implementers, and parties who must be informed. Flag conflicting mandates or any action exceeding the stated authority limits.
4. Define evaluation criteria: Convert the supplied priorities into clear criteria such as strategic fit, customer impact, expected value, cash requirement, time to value, operational feasibility, reversibility, compliance exposure, security or privacy impact, workforce impact, and execution risk. Assign weights only when supplied or transparently proposed; do not present invented weights as executive preferences.
5. Build a complete option set: Analyze the supplied options and add a status quo, defer, pilot, staged commitment, or reversible alternative when materially relevant. Do not add artificial options merely to create symmetry. Define scope, prerequisites, dependencies, timing, resource demand, and opportunity cost for each credible option.
6. Normalize the comparison: Use consistent time horizons, units, cost boundaries, discounting assumptions, and metric definitions. Reconcile one-time and recurring costs, benefits, downside exposure, implementation capacity, and displaced work. Identify values that cannot be compared reliably.
7. Test economics and outcomes: Where evidence permits, show formulas and inputs for relevant measures such as incremental revenue, avoided cost, total cost of ownership, contribution margin, payback period, break-even point, or expected value. Use ranges or scenarios rather than false precision. Never invent a return estimate when required inputs are absent.
8. Stress-test the options: Evaluate base, upside, and downside cases; key sensitivities; adoption or demand shortfalls; schedule slippage; cost overruns; dependency failure; vendor or concentration risk; regulatory, legal, privacy, security, reputational, and workforce effects where applicable. Identify assumptions capable of reversing the ranking.
9. Account for stakeholder effects: State who benefits, who bears cost or disruption, likely objections, distributional effects, change-management needs, and unresolved dissent. Do not infer stakeholder consent from silence.
10. Form the recommendation: Recommend one option only when the evidence supports a defensible preference. Explain why it wins against the criteria, what trade-offs are accepted, confidence level, and what new evidence would change the recommendation. If evidence is insufficient, issue a conditional recommendation or a clearly bounded no-recommendation finding.
11. Design execution gates: Translate the recommendation into decision gates, accountable owners, dependencies, resources, approval points, leading and lagging indicators, review cadence, stop-loss thresholds, and rollback or exit conditions. Treat all owners and dates not explicitly confirmed as proposed.
12. Verify decision readiness: Reconcile important claims to sources, arithmetic to inputs, option scores to rationale, recommendation to criteria, risks to controls, and implementation gates to named authority. Report every failed or unperformed check rather than claiming verification.
Authority and safety boundaries
- Produce analysis and a recommendation, not an approval. Do not authorize spending, sign contracts, change policy, contact stakeholders, publish communications, move data, alter systems, or initiate implementation.
- Require explicit human authorization for commitments involving funds, personnel, customers, regulated activity, contracts, production operations, security, privacy, legal positions, or external communications.
- Minimize exposure of personal, confidential, privileged, security-sensitive, or commercially restricted information. Recommend redaction or aggregation when detailed data is unnecessary. Do not reproduce secrets or credentials.
- Flag where qualified finance, legal, compliance, security, privacy, HR, procurement, or operational review is required. Do not represent the brief as a substitute for those approvals.
- Stop at analysis and escalate when evidence suggests unlawful conduct, material safety danger, unauthorized access, sanctions exposure, serious privacy or security risk, an unbounded financial commitment, or a decision outside the named owner's authority.
- For difficult-to-reverse actions, prefer staged commitment, pilot controls, backups, rollback planning, and explicit kill criteria where practical.
Required output
A. Decision header
- Decision statement
- Accountable decision owner and required approvers
- Decision deadline and urgency
- Scope and exclusions
- Current state of the decision: exploratory, under review, recommended, pending approval, or another evidence-supported state
B. Executive position
- Recommended option or no-recommendation finding
- Three to five reasons tied to evidence and criteria
- Material trade-offs being accepted
- Confidence level with rationale
- Immediate decision requested from the owner
C. Baseline and decision trigger
Provide the relevant operating, customer, market, workforce, and financial baseline; why action is being considered now; cost of delay; and status quo trajectory. Include source, period, metric definition, and limitation for each pivotal baseline claim.
D. Evidence ledger
Create a table with columns: ID; material claim; classification; source or calculation; source date or period; reliability or limitation; confidence; and implication. Include contradictory evidence rather than silently resolving it.
E. Decision criteria
Create a table with columns: criterion; definition; weight or priority; measurement method; threshold; source of priority; and uncertainty. Clearly mark proposed weights.
F. Options and trade-off matrix
Create a table with one row per credible option and columns: option; scope; strategic fit; expected benefits; full costs; time to value; feasibility; key dependencies; reversibility; principal risks; stakeholder effects; evidence gaps; and criterion-based result. Include status quo or defer when materially relevant. Follow the table with concise explanations for any scoring or ranking.
G. Economics and scenario analysis
Show applicable formulas, inputs, units, time horizon, and results. Compare base, upside, and downside cases. Identify the variables with the greatest effect on the outcome and any break-even threshold. If economics cannot be calculated, list the missing inputs and avoid numeric conclusions.
H. Recommendation rationale
Explain why the preferred option is superior to each viable alternative, which disadvantages remain, why they are tolerable, what assumptions the recommendation depends on, and the evidence or event that would reverse it. State meaningful dissent or unresolved objections.
I. Risk and control register
Create a table with columns: risk; cause; affected objective; likelihood; impact; exposure; early warning indicator; preventive control; contingency or recovery action; proposed owner; escalation threshold; and residual risk. Distinguish existing controls from proposed controls.
J. Approval-gated implementation outline
Create a table with columns: phase or gate; intended outcome; proposed owner; prerequisites; resources; approval required; target timing; acceptance evidence; stop condition; and rollback or exit path. Do not imply that any phase has begun unless execution evidence was supplied.
K. Measurement and review plan
Define the baseline, target, metric owner, data source, measurement frequency, leading indicators, lagging outcomes, guardrail metrics, review dates, and trigger for continue, adjust, pause, scale, or stop decisions. Note whether each target is supplied or proposed.
L. Verification and acceptance record
Create a table with columns: check; expected condition; actual observation from supplied material; evidence reference; result as passed, failed, unperformed, or blocked; and required resolution. At minimum check:
- the decision owner and approval path are explicit;
- options use consistent scope, units, and time horizons;
- pivotal claims trace to evidence;
- calculations reconcile to source inputs;
- assumptions and forecasts are labeled;
- status quo and delay consequences were considered;
- recommendation follows the stated criteria;
- material downside and affected stakeholders are represented;
- authority, specialist-review, privacy, and compliance limits are addressed;
- implementation gates have acceptance evidence and stop or exit conditions;
- no completion or approval claim exceeds available evidence.
M. Open issues and handoff
List blocking questions, non-blocking unknowns, evidence conflicts, required specialist reviews, decisions reserved for humans, and the smallest safe next action. End with a concise decision-owner checklist separating: decide now, obtain evidence, seek approval, and defer.
## 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.
Completion criteria
Complete when:
- The proposed purchase, intended outcome, scope, timetable, mandatory intake criteria, and accountable roles are explicit.
- Every required package element has a supplied, missing, conditional, or not-applicable disposition with evidence provenance.
- Requirements and mandatory controls map to available evidence without treating claims as verified due-diligence findings.
- Every blocker and condition has an owner, specific evidence request, acceptable source, deadline, and closure condition.
- The recommendation is exactly Proceed to due diligence, Proceed with conditions, or Not ready, with rationale and permitted next steps.
- The record explicitly avoids vendor selection, full due diligence, contract approval, purchase authorization, and production-access decisions.
Component Prompts
Browse PromptsVendor Claims Fact-Check Dossier
Use Perplexity to build a citation-backed procurement dossier that tests AI, SaaS, software, agency, or service-provider claims, grades evidence, records unresolved risks, and prepares precise vendor questions without representing research as approval or completed due diligence.
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.AI Vendor Security and Data Processing Review Brief
Prepare a defensible security, privacy, AI governance, and data-processing review for an AI vendor before procurement, approval, or renewal.
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.Evidence-Grounded AI Vendor Evaluation and Procurement Risk Scorecard
Evaluate an AI vendor using evidence-qualified scoring, data-flow analysis, security and privacy controls, commercial risk, decision gates, and a safeguarded pilot plan.
Evaluate the proposed AI vendor for procurement or renewal using only the supplied materials and any sources ChatGPT can actually access in the current session. Produce decision support for authorized business, procurement, security, privacy, legal, and compliance reviewers; do not present the analysis itself as organizational approval. ## Evaluation 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] ## Input and access rules Treat the vendor identity, intended use, affected users, expected data categories, material integrations, applicable requirements, risk tolerance, and decision objective as minimum inputs. If any are absent or materially ambiguous, ask a concise set of blocking questions before issuing a recommendation. You may still create a clearly labeled preliminary assessment when bounded progress is safe. Pricing details, contracts, data processing terms, security reports, subprocessors, architecture diagrams, retention schedules, incident history, accessibility reports, support terms, and exit documentation are useful supporting inputs. Mark their absence as an evidence gap rather than inventing their contents. Use ChatGPT to organize supplied evidence, compare claims with requirements, expose conflicts, calculate transparent scores, and draft questions and controls. Do not imply that ChatGPT accessed a website, contract, private system, vendor portal, configuration, certification report, or live integration unless that access occurred in the current session. A URL alone is not evidence of its contents. If browsing is available and used, identify the pages consulted and retrieval date; otherwise request pasted or uploaded source material. Do not contact the vendor, accept terms, approve expenditure, sign a contract, change configurations, connect an integration, provision users, upload business data, run a pilot, delete records, or certify compliance. Those actions require authorized humans and, where applicable, security, privacy, legal, compliance, procurement, and system-owner approval. Do not request passwords, API secrets, private keys, authentication tokens, or unnecessary personal data. Recommend redacted documents and synthetic or de-identified pilot data where practical. ## Evidence discipline Create an evidence ledger and assign each source a stable identifier. For every material conclusion, score, risk, and decision condition, cite one or more evidence identifiers or mark it unsupported. Classify information as one of the following: - Supplied fact: directly stated in business-provided material. - Vendor claim: stated by the vendor but not independently or contractually verified. - Independent evidence: supported by a credible third party, with scope and date recorded. - Contractual commitment: contained in applicable executed or proposed terms, with the relevant clause identified. - Observation: directly visible from an artifact or authorized demonstration available in the session. - Assumption: a declared premise used for bounded analysis. - Unknown: no adequate evidence is available. - Conflict: sources disagree or apply to different products, plans, regions, or dates. Never convert a vendor claim into a verified control. Check whether evidence applies to the correct product, service tier, hosting region, deployment model, integration, legal entity, and evaluation date. Flag stale, marketing-only, partial, inaccessible, or scope-mismatched evidence. Preserve conflicting claims and state what would reconcile them. ## Evaluation workflow ### 1. Establish scope and data flow Summarize the business outcome, users, administrators, deployment model, integrations, and alternatives. Map the expected flow of prompts, files, recordings, metadata, outputs, telemetry, support data, and account data through collection, transmission, storage, model processing, human review, subprocessors, export, retention, deletion, and backup expiry. Classify likely data sensitivity, including public, internal, confidential, personal, special-category, financial, health, customer, employee, authentication, intellectual-property, or regulated data. Do not assume a data category is permitted merely because the tool can process it. ### 2. Inventory and qualify evidence Build the evidence ledger before scoring. Record source, owner or publisher, document date, retrieval date when applicable, product and plan scope, region, evidence class, relevant claim, limitations, and identifier. List missing critical artifacts such as a data processing agreement, security report, subprocessor list, retention policy, model-training terms, deletion procedure, breach notice terms, service levels, pricing schedule, and export documentation. ### 3. Apply critical decision gates Evaluate these gates before calculating an overall result: - Prohibited or unapproved data would enter the service. - The vendor cannot explain training, retention, deletion, residency, or subprocessors for material data. - Required SSO, MFA, role-based access, audit logging, encryption, tenant isolation, or administrator controls are absent or unverified. - Applicable legal, regulatory, contractual, records-management, intellectual-property, accessibility, or data-transfer requirements cannot be met. - Material contract terms conflict with mandatory requirements or accepted risk. - The use case creates high-impact automated decisions without appropriate human oversight, testing, appeal, and accountability. - No feasible containment, offboarding, export, access revocation, or incident-response path exists. A failed gate should normally lead to Reject, Defer pending information, or a tightly restricted Pilot first recommendation. Explain any exception and identify the human risk owner authorized to accept it. ### 4. Score the vendor Score each category from 1 to 5 only when enough evidence exists: 1 = confirmed material failure or unacceptable exposure 2 = major gaps requiring substantial remediation 3 = partially meets requirements with enforceable conditions 4 = meets documented requirements 5 = exceeds requirements with strong, applicable evidence Use NE for not enough evidence and NA only when a category is genuinely irrelevant. Do not treat NE as zero or silently exclude it. Report evidence coverage as the percentage of applicable categories with a supported score. Do not issue a numeric overall score when coverage is below 70 percent or when security, privacy, compliance, or data-governance gates remain unresolved. Assess: - Business fit and measurable value - Usability, accessibility, and adoption fit - Security architecture and assurance - Privacy and data protection - Compliance and contractual readiness - Identity, roles, and administrator controls - Auditability, logging, and monitoring - Integration and technical fit - Pricing transparency and total cost exposure - Vendor maturity, resilience, and incident response - Support and service management - Portability, termination, and lock-in risk For every score, provide the rationale, evidence identifiers, confidence level, requirement gap, and condition needed to improve the score. If priorities justify weighting, show the proposed weights and obtain human agreement before using a weighted total; otherwise use equal weights and label the result provisional. ### 5. Perform domain assessments Evaluate data use for foundation-model training, fine-tuning, product improvement, human review, abuse monitoring, and telemetry. Examine opt-out scope, default settings, retention periods, deletion behavior, backup expiry, legal holds, residency, cross-border transfers, subprocessors, data ownership, output rights, confidentiality, and intellectual-property protections. Evaluate authentication, SSO, MFA, lifecycle provisioning, least privilege, role separation, service accounts, encryption, key management, tenant isolation, secure development, vulnerability management, penetration testing, audit reports, log availability, incident notification, business continuity, disaster recovery, recovery objectives, and administrator visibility. Distinguish certification possession from control effectiveness and scope. Evaluate onboarding, workflow change, training, acceptable-use rules, support escalation, accessibility, internal ownership, model-output review, accuracy limitations, bias or harmful-output risks, monitoring, incident handling, and shadow-use risk. Evaluate licensing units, usage limits, implementation services, integration work, storage, support tiers, overages, taxes, price escalation, renewal notice, minimum commitments, suspension rights, indemnities, liability limits, insurance, service levels, termination assistance, export formats, deletion commitments, and switching costs. Separate known prices from estimates and identify estimate assumptions. ### 6. Build the risk and control package Create a risk register covering privacy, security, compliance, legal, commercial, operational, integration, model behavior, vendor viability, and exit risk. Each risk must include cause, event, consequence, affected data or process, inherent severity and likelihood, evidence, existing controls, proposed treatment, residual risk, owner, due date, decision gate, and status. Create a prioritized vendor evidence request. Questions must be answerable and tied to a specific gap, risk, score, or contract condition. Separate requests for documents, written confirmations, product demonstrations, technical validation, and contract amendments. ### 7. Form the recommendation Choose exactly one recommendation: - Approve - Approve with conditions - Pilot first - Defer pending information - Reject An Approve recommendation requires supported critical controls, acceptable residual risk, adequate evidence coverage, and no unresolved mandatory gate. Approve with conditions requires named conditions, accountable owners, deadlines, and a consequence if a condition is not met. Pilot first requires a bounded hypothesis and safeguards; it is not production approval. Defer pending information must list the evidence needed to resume. Reject must identify the failed requirements and whether reconsideration is possible. State which authorized functions must review or approve the decision. Never state that the vendor has been approved, verified, certified, contracted, configured, tested, deployed, monitored, or deleted unless supplied execution evidence proves that action occurred. Use proposed, pending, unverified, blocked, or not performed as appropriate. ### 8. Design a safeguarded pilot when appropriate If the recommendation permits a pilot, define its business hypothesis, participants, duration, approved use cases, prohibited uses, data restrictions, synthetic-data preference, administrator configuration, access controls, logging, human review, user training, support route, incident procedure, success metrics, failure thresholds, review date, and accountable owner. Include stop conditions for unauthorized data exposure, material control failure, unexpected training or retention behavior, security incident, harmful output, regulatory conflict, uncontrolled cost, or inability to export or delete pilot data. Provide a recovery and exit procedure covering disabled access, revoked integrations and tokens, data export, deletion request, backup-expiry confirmation, record preservation, user communication, and fallback workflow. Label all of these as proposed until execution evidence is supplied. ## Required deliverable ### A. Decision brief Include the recommendation, confidence, evidence coverage, critical gates, top risks, expected business value, estimated commercial exposure, mandatory conditions, and required human approvers. ### B. Scope and data-flow map Use a table with: Stage | Data or metadata | Sensitivity | Source | Recipient or subprocessor | Purpose | Region | Retention | Training or improvement use | Control | Evidence ID | Unknowns. ### C. Evidence ledger Use a table with: Evidence ID | Artifact or source | Evidence class | Publisher or owner | Date | Product, plan, and region scope | Supported claim | Limitations | Status. ### D. Critical-gate assessment Use a table with: Gate | Requirement | Expected observation | Actual supported observation | Evidence ID | Pass, Fail, or Unresolved | Consequence | Required resolution. ### E. Evaluation scorecard Use a table with: Category | Score or NE or NA | Weight if agreed | Rationale | Evidence ID | Confidence | Requirement gap | Improvement condition. Show evidence coverage and any permitted aggregate calculation. ### F. Detailed assessments Provide separate findings for data governance and privacy, security and assurance, compliance and contracting, operational and model-risk fit, integrations, commercial exposure, and portability. For each finding state the requirement, supported observation, evidence, gap, risk, and proposed control. ### G. Risk register Use the fields defined in the risk and control package. Rank risks without hiding low-confidence or unresolved high-impact items. ### H. Vendor evidence requests and negotiation points Prioritize each item as blocking, pre-contract, pre-pilot, pre-production, or monitor. Link every request to an evidence gap, risk identifier, score, or decision condition. ### I. Recommendation and approval path State the selected recommendation, rationale, rejected alternatives, residual risks, conditions, owners, deadlines, escalation route, and required reviewers. Clearly distinguish advisory analysis from formal approval. ### J. Pilot, rollout, monitoring, and exit controls When relevant, provide the proposed pilot plan, production-entry criteria, metrics, review cadence, incident triggers, stop conditions, fallback, and offboarding evidence requirements. If a pilot is unsafe or premature, state why instead of drafting an executable rollout. ### K. Verification and acceptance matrix Use a table with: Check | Expected evidence or observation | Actual supplied evidence or observation | Evidence ID | Status | Owner | Resolution needed. At minimum reconcile data-use terms, retention and deletion, subprocessors and residency, identity controls, audit logging, incident terms, contractual requirements, price assumptions, export capability, pilot safeguards, and unresolved source conflicts. ### L. Final decision checklist Confirm whether minimum inputs are complete, critical evidence is applicable and current, unsupported claims are labeled, scores trace to evidence, gate failures control the recommendation, commercial totals reconcile with stated assumptions, risk owners are assigned, conditions are measurable, required approvers are named, and proposed actions are not misrepresented as completed. End with a short section titled Unresolved Items and Handoff that lists blocking unknowns, who must resolve them, the evidence required, and the next authorized decision point.Executive Decision Brief Prompt
Turn a consequential business decision into an evidence-grounded executive brief with comparable options, explicit trade-offs, risk controls, measurable outcomes, and a recommendation.
Prepare an executive decision brief for the following decision. Decision inputs - Decision question: [Decision question] - Decision owner and approval authority: [Decision owner and approval authority] - Decision deadline: [Decision deadline] - Business context: [Business context] - Options already under consideration: [Options under consideration] - Evidence pack: [Evidence pack] - Constraints and non-negotiables: [Constraints and non-negotiables] - Decision criteria and priorities: [Decision criteria and priorities] - Affected stakeholders: [Affected stakeholders] - Risk, authority, and escalation limits: [Risk, authority, and escalation limits] - Definition of a decision-ready brief: [Definition of done] Input requirements Treat the decision question, accountable owner, deadline, known constraints, and at least one credible source describing the current situation as minimum inputs. Financial baselines, operating metrics, forecasts, customer evidence, contracts, policies, prior decisions, stakeholder positions, and option estimates are useful supporting inputs. If the decision question, authority, material constraints, or baseline evidence is missing or contradictory, ask only the questions that block responsible comparison or recommendation. If answers are unavailable, continue only where bounded analysis is safe. Preserve each unresolved item as an unknown, conflict, or assumption; do not manufacture figures, stakeholder agreement, approvals, or evidence. Evidence and tool rules 1. Use ChatGPT to organize supplied material, test reasoning, compare options, calculate only from provided figures, and draft the brief. State any calculation method and show enough working for review. 2. Do not imply access to internal systems, live dashboards, private links, meetings, or external sources unless their contents are actually available in the conversation. A URL alone is not evidence if its relevant content cannot be inspected. 3. Classify material claims as one of: supplied fact, direct observation from supplied material, calculation, stakeholder assertion, assumption, hypothesis, forecast, unknown, or conflict. Cite the file, excerpt, table, date, or source label supplied by the user whenever available. 4. Separate historical results from forecasts and correlation from demonstrated causation. Flag stale data, mismatched periods, inconsistent definitions, selection bias, omitted costs, optimistic adoption assumptions, and unsupported precision. 5. Never describe an option as approved, funded, validated, compliant, tested, launched, communicated, or completed unless the supplied evidence proves that state. Keep proposed, pending approval, blocked, unverified, and executed states distinct. Decision analysis workflow 1. Frame the decision: Rewrite the question as a specific choice to be made by the named owner by the deadline. Define what is in scope, what is excluded, why a decision is needed now, and the consequences of delay or no decision. 2. Establish the baseline: Summarize the current operating and financial position using the most decision-relevant metrics. Record metric definitions, periods, sources, and known data-quality limitations. Distinguish verified baseline values from estimates. 3. Confirm decision rights: Identify the recommender, approver, consulted parties, implementers, and parties who must be informed. Flag conflicting mandates or any action exceeding the stated authority limits. 4. Define evaluation criteria: Convert the supplied priorities into clear criteria such as strategic fit, customer impact, expected value, cash requirement, time to value, operational feasibility, reversibility, compliance exposure, security or privacy impact, workforce impact, and execution risk. Assign weights only when supplied or transparently proposed; do not present invented weights as executive preferences. 5. Build a complete option set: Analyze the supplied options and add a status quo, defer, pilot, staged commitment, or reversible alternative when materially relevant. Do not add artificial options merely to create symmetry. Define scope, prerequisites, dependencies, timing, resource demand, and opportunity cost for each credible option. 6. Normalize the comparison: Use consistent time horizons, units, cost boundaries, discounting assumptions, and metric definitions. Reconcile one-time and recurring costs, benefits, downside exposure, implementation capacity, and displaced work. Identify values that cannot be compared reliably. 7. Test economics and outcomes: Where evidence permits, show formulas and inputs for relevant measures such as incremental revenue, avoided cost, total cost of ownership, contribution margin, payback period, break-even point, or expected value. Use ranges or scenarios rather than false precision. Never invent a return estimate when required inputs are absent. 8. Stress-test the options: Evaluate base, upside, and downside cases; key sensitivities; adoption or demand shortfalls; schedule slippage; cost overruns; dependency failure; vendor or concentration risk; regulatory, legal, privacy, security, reputational, and workforce effects where applicable. Identify assumptions capable of reversing the ranking. 9. Account for stakeholder effects: State who benefits, who bears cost or disruption, likely objections, distributional effects, change-management needs, and unresolved dissent. Do not infer stakeholder consent from silence. 10. Form the recommendation: Recommend one option only when the evidence supports a defensible preference. Explain why it wins against the criteria, what trade-offs are accepted, confidence level, and what new evidence would change the recommendation. If evidence is insufficient, issue a conditional recommendation or a clearly bounded no-recommendation finding. 11. Design execution gates: Translate the recommendation into decision gates, accountable owners, dependencies, resources, approval points, leading and lagging indicators, review cadence, stop-loss thresholds, and rollback or exit conditions. Treat all owners and dates not explicitly confirmed as proposed. 12. Verify decision readiness: Reconcile important claims to sources, arithmetic to inputs, option scores to rationale, recommendation to criteria, risks to controls, and implementation gates to named authority. Report every failed or unperformed check rather than claiming verification. Authority and safety boundaries - Produce analysis and a recommendation, not an approval. Do not authorize spending, sign contracts, change policy, contact stakeholders, publish communications, move data, alter systems, or initiate implementation. - Require explicit human authorization for commitments involving funds, personnel, customers, regulated activity, contracts, production operations, security, privacy, legal positions, or external communications. - Minimize exposure of personal, confidential, privileged, security-sensitive, or commercially restricted information. Recommend redaction or aggregation when detailed data is unnecessary. Do not reproduce secrets or credentials. - Flag where qualified finance, legal, compliance, security, privacy, HR, procurement, or operational review is required. Do not represent the brief as a substitute for those approvals. - Stop at analysis and escalate when evidence suggests unlawful conduct, material safety danger, unauthorized access, sanctions exposure, serious privacy or security risk, an unbounded financial commitment, or a decision outside the named owner's authority. - For difficult-to-reverse actions, prefer staged commitment, pilot controls, backups, rollback planning, and explicit kill criteria where practical. Required output A. Decision header - Decision statement - Accountable decision owner and required approvers - Decision deadline and urgency - Scope and exclusions - Current state of the decision: exploratory, under review, recommended, pending approval, or another evidence-supported state B. Executive position - Recommended option or no-recommendation finding - Three to five reasons tied to evidence and criteria - Material trade-offs being accepted - Confidence level with rationale - Immediate decision requested from the owner C. Baseline and decision trigger Provide the relevant operating, customer, market, workforce, and financial baseline; why action is being considered now; cost of delay; and status quo trajectory. Include source, period, metric definition, and limitation for each pivotal baseline claim. D. Evidence ledger Create a table with columns: ID; material claim; classification; source or calculation; source date or period; reliability or limitation; confidence; and implication. Include contradictory evidence rather than silently resolving it. E. Decision criteria Create a table with columns: criterion; definition; weight or priority; measurement method; threshold; source of priority; and uncertainty. Clearly mark proposed weights. F. Options and trade-off matrix Create a table with one row per credible option and columns: option; scope; strategic fit; expected benefits; full costs; time to value; feasibility; key dependencies; reversibility; principal risks; stakeholder effects; evidence gaps; and criterion-based result. Include status quo or defer when materially relevant. Follow the table with concise explanations for any scoring or ranking. G. Economics and scenario analysis Show applicable formulas, inputs, units, time horizon, and results. Compare base, upside, and downside cases. Identify the variables with the greatest effect on the outcome and any break-even threshold. If economics cannot be calculated, list the missing inputs and avoid numeric conclusions. H. Recommendation rationale Explain why the preferred option is superior to each viable alternative, which disadvantages remain, why they are tolerable, what assumptions the recommendation depends on, and the evidence or event that would reverse it. State meaningful dissent or unresolved objections. I. Risk and control register Create a table with columns: risk; cause; affected objective; likelihood; impact; exposure; early warning indicator; preventive control; contingency or recovery action; proposed owner; escalation threshold; and residual risk. Distinguish existing controls from proposed controls. J. Approval-gated implementation outline Create a table with columns: phase or gate; intended outcome; proposed owner; prerequisites; resources; approval required; target timing; acceptance evidence; stop condition; and rollback or exit path. Do not imply that any phase has begun unless execution evidence was supplied. K. Measurement and review plan Define the baseline, target, metric owner, data source, measurement frequency, leading indicators, lagging outcomes, guardrail metrics, review dates, and trigger for continue, adjust, pause, scale, or stop decisions. Note whether each target is supplied or proposed. L. Verification and acceptance record Create a table with columns: check; expected condition; actual observation from supplied material; evidence reference; result as passed, failed, unperformed, or blocked; and required resolution. At minimum check: - the decision owner and approval path are explicit; - options use consistent scope, units, and time horizons; - pivotal claims trace to evidence; - calculations reconcile to source inputs; - assumptions and forecasts are labeled; - status quo and delay consequences were considered; - recommendation follows the stated criteria; - material downside and affected stakeholders are represented; - authority, specialist-review, privacy, and compliance limits are addressed; - implementation gates have acceptance evidence and stop or exit conditions; - no completion or approval claim exceeds available evidence. M. Open issues and handoff List blocking questions, non-blocking unknowns, evidence conflicts, required specialist reviews, decisions reserved for humans, and the smallest safe next action. End with a concise decision-owner checklist separating: decide now, obtain evidence, seek approval, and defer.Explore related Workflows
Browse WorkflowsPlan a SaaS Portfolio Consolidation Decision
Reconcile application usage and ownership, evaluate true portfolio redundancy and dependencies, prepare vendor renewal or exit paths, and issue an evidence-backed consolidation decision.
Make an AI Initiative Value and Scale Decision
Reconcile an approved AI value case to realized evidence, diagnose value leakage, calculate accepted-outcome unit economics, and issue a Scale, Hold, Redesign, or Stop decision.
Safe 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.
Was this useful?