{
  "$schema": "https://www.slavin.ai/data/ai-vendor-due-diligence-schema.json",
  "dataset": {
    "name": "AI Vendor Due-Diligence Checklist",
    "version": "2026-06",
    "publisher": "Slavin AI (SLAtech LTD)",
    "publisherUrl": "https://www.slavin.ai/",
    "license": "CC-BY-4.0",
    "lastUpdated": "2026-06-14",
    "description": "Structured due-diligence checklist for selecting enterprise AI vendors. 60 questions across 8 evaluation dimensions: regulatory fit, data handling, model integrity, operational reliability, security posture, commercial structure, vendor stability, and integration surface. Each question pairs the request with the architect's interpretation of common evasive answers and the verification step that confirms or contradicts the claim. Companion to: failure modes catalog (caught before launch), incident response playbook (handled in production).",
    "audience": ["CIO", "CTO", "AI Procurement Lead", "Compliance Officer", "Enterprise Architect"],
    "methodology": "Compiled from 150+ Slavin/SLAtech engagements 2022-2026 where enterprise AI vendor selection processes were observed. Questions cover the gaps that contracts, marketing decks, and standard RFP templates routinely miss. Each question has been observed to surface a material issue in at least three independent vendor evaluations before inclusion. The architect's interpretation column reflects what the vendor's evasive answer typically signals; entries are documented as patterns, not specific events."
  },
  "scoring_guidance": {
    "approach": "Score each question 0-3. 0 = vendor unable to answer or evasive; 1 = answer provided but unverified; 2 = answer provided and partial verification possible; 3 = answer verified independently. Sum per dimension and per total.",
    "thresholds": {
      "enterprise_ready": "Total >= 144 (80%+); no dimension below 50%",
      "qualified_with_remediation": "Total 108-143 (60-79%); document gaps as contractual SLA",
      "do_not_proceed": "Total < 108 OR any single dimension under 30% (especially regulatory, security, data handling)"
    },
    "weighting": "Dimensions are equal-weighted by default. For regulated industries (healthcare, finance, government) multiply regulatory_fit + data_handling + security_posture by 1.5x before summing."
  },
  "dimensions": [
    {
      "id": "DIM-REG",
      "name": "Regulatory fit",
      "description": "Whether the vendor's posture matches the regulatory regime that applies to your deployment.",
      "questions": [
        {
          "id": "Q-REG-01",
          "ask": "Which specific regulators have audited or certified your platform, and can you share the audit report or certification scope?",
          "evasive_signal": "References to 'SOC 2 compliance' without specifying Type II + scope, or 'GDPR-aligned' without naming the specific Articles addressed.",
          "verification": "Request the actual audit report (under NDA) and confirm scope covers the surface you'll use. SOC 2 Type I is materially different from Type II."
        },
        {
          "id": "Q-REG-02",
          "ask": "For EU AI Act: which Annex III categories does your platform cover, and at what risk tier do you classify yourself as provider vs deployer?",
          "evasive_signal": "Vendor says 'we're not high-risk' without naming Article 6 + Annex III analysis. Or refuses to take provider responsibility.",
          "verification": "Walk through your use case against Annex III lines yourself; if your deployer use becomes high-risk, vendor must support that classification in writing."
        },
        {
          "id": "Q-REG-03",
          "ask": "What is your data-residency commitment for our region, and what happens if your infrastructure routes through a non-compliant region during an outage?",
          "evasive_signal": "'Our DPA covers all routing' without naming specific regional endpoints or DR fallback regions.",
          "verification": "Request architecture diagram showing all data flow paths including failover. Confirm with vendor SLA in writing."
        },
        {
          "id": "Q-REG-04",
          "ask": "How do you handle right-to-deletion (GDPR Art. 17 / equivalents)? What's the full data lineage from prompt to deletion?",
          "evasive_signal": "'30-day retention' without addressing training data retention, vector store retention, or third-party processor retention.",
          "verification": "Request the data lineage document; confirm vendor can produce a deletion audit trail for one synthetic test record."
        },
        {
          "id": "Q-REG-05",
          "ask": "For our jurisdiction's data localization law (152-FZ, China DPL, India DPDP, etc.) - name the specific provision and your specific control that satisfies it.",
          "evasive_signal": "'We work with customers in that region' without naming the legal provision.",
          "verification": "Ask for a customer reference in the same jurisdiction who passed regulator audit while using the vendor's platform."
        },
        {
          "id": "Q-REG-06",
          "ask": "What is your process when a regulator inquiries about a customer's deployment? Specifically: do you cooperate with regulators bypassing the customer?",
          "evasive_signal": "Vendor will not commit in writing to customer notification before regulator engagement.",
          "verification": "Contractual amendment: vendor must notify customer within 24h of regulator inquiry, unless legal order forbids."
        },
        {
          "id": "Q-REG-07",
          "ask": "Do you have a published model card with bias evaluation, known failure modes, and intended use restrictions?",
          "evasive_signal": "Model card is marketing material, no quantitative bias data, no negative-use disclosures.",
          "verification": "Check published model card against NIST AI RMF reference. Specifically: are subgroup performance numbers published?"
        }
      ]
    },
    {
      "id": "DIM-DATA",
      "name": "Data handling",
      "description": "How customer data is processed, stored, isolated from other tenants, and used (or not) for vendor model training.",
      "questions": [
        {
          "id": "Q-DATA-01",
          "ask": "Will any of our prompts, outputs, embeddings, or metadata be used for your model training, evaluation, or fine-tuning by default? What's the opt-out mechanism?",
          "evasive_signal": "Opt-out only via account settings (not contractual default), or opt-out doesn't apply to 'abuse detection' or 'safety improvement'.",
          "verification": "Contractual amendment: zero-retention for all data classes, explicit list of exceptions if any, with logging guarantees."
        },
        {
          "id": "Q-DATA-02",
          "ask": "What is your tenant isolation model? Specifically: shared vector store or per-tenant; shared embedding model fine-tuned across tenants or per-tenant?",
          "evasive_signal": "'Logical isolation' without explanation of the physical mechanism. RAG corpus shared across tenants is a common source of cross-tenant leak.",
          "verification": "Pen-test from a separate test tenant attempting to retrieve from another tenant's corpus."
        },
        {
          "id": "Q-DATA-03",
          "ask": "How long are prompts, outputs, and logs retained? In what systems? By what control?",
          "evasive_signal": "Marketing answer '30 days' without addressing internal debug logs, vendor's vendor processors, or backup retention.",
          "verification": "Data lineage document with retention per stage. Confirm vendor's own subprocessors have aligned retention."
        },
        {
          "id": "Q-DATA-04",
          "ask": "What PII detection and redaction runs before our data reaches the model? Can it be disabled? What's the audit trail?",
          "evasive_signal": "'We don't see PII' without naming the redaction tool, the rule set, or showing detection metrics.",
          "verification": "Submit synthetic PII test set and confirm redaction. Request false-negative rate on standard test corpora."
        },
        {
          "id": "Q-DATA-05",
          "ask": "What is your subprocessor list, when did it last change, and what is the customer notification process for changes?",
          "evasive_signal": "Subprocessor list is short or generic; new subprocessors added without customer notification.",
          "verification": "Request current subprocessor list with country + role. Verify each against your DPA matrix."
        },
        {
          "id": "Q-DATA-06",
          "ask": "If we ingest customer PII into your RAG corpus, what is the deletion flow when an end-user requests deletion?",
          "evasive_signal": "Vendor cannot guarantee deletion from vector embeddings, only from source documents.",
          "verification": "Request the deletion audit trail format; confirm with a test deletion."
        },
        {
          "id": "Q-DATA-07",
          "ask": "Do you train on your customers' data in aggregate for model improvement? If yes, with what consent mechanism?",
          "evasive_signal": "'Anonymized aggregate' without explanation of how aggregation prevents reconstruction.",
          "verification": "Contractual prohibition on aggregate training without explicit opt-in per data type."
        }
      ]
    },
    {
      "id": "DIM-MODEL",
      "name": "Model integrity",
      "description": "Whether the model behaves consistently, drift is managed, and quality controls catch regression before customers do.",
      "questions": [
        {
          "id": "Q-MODEL-01",
          "ask": "Do you version your models? How long is a specific version available before forced migration?",
          "evasive_signal": "'We continuously improve the model' without version pinning option.",
          "verification": "Contractual commitment: 12+ months availability for any version you depend on."
        },
        {
          "id": "Q-MODEL-02",
          "ask": "What is your model drift detection? At what threshold do you notify customers of behavior change?",
          "evasive_signal": "No drift program; or drift detection is internal only with no customer notification SLA.",
          "verification": "Customer-facing change log; eval suite available for customers to run drift detection themselves."
        },
        {
          "id": "Q-MODEL-03",
          "ask": "What is your evaluation harness? Can we see the benchmark suite and current scores? Is it run continuously?",
          "evasive_signal": "Eval scores from marketing decks; no continuous evaluation; benchmarks chosen to flatter the model.",
          "verification": "Run your own golden set through the model and compare to claimed performance."
        },
        {
          "id": "Q-MODEL-04",
          "ask": "How do you handle prompts that hit safety filters? Specifically: is the customer told what was filtered and why?",
          "evasive_signal": "Filters return generic refusal without surfacing the trigger.",
          "verification": "Submit ambiguous prompts that test filter boundaries. Confirm trigger reporting in logs."
        },
        {
          "id": "Q-MODEL-05",
          "ask": "Do you support reproducibility - given the same prompt, same model version, same seed, do we get the same output?",
          "evasive_signal": "Vendor will not commit to deterministic output even with temperature=0 + fixed seed.",
          "verification": "Test reproducibility yourself with controlled inputs."
        },
        {
          "id": "Q-MODEL-06",
          "ask": "What is the model's training data cutoff date? When was the last RLHF / instruction fine-tune?",
          "evasive_signal": "Vendor will not name training cutoff or fine-tune dates.",
          "verification": "Confirm cutoff matches your knowledge-currency requirements. Critical for compliance/legal use cases."
        },
        {
          "id": "Q-MODEL-07",
          "ask": "Are there documented prompt-injection mitigations? What's the residual risk you accept?",
          "evasive_signal": "'We have prompt injection defenses' without describing what or testing against adversarial corpora.",
          "verification": "Run an open prompt-injection benchmark (e.g., adversarial inputs from public research) against the model."
        }
      ]
    },
    {
      "id": "DIM-OPS",
      "name": "Operational reliability",
      "description": "Whether the platform delivers the latency and uptime your dependent systems can rely on.",
      "questions": [
        {
          "id": "Q-OPS-01",
          "ask": "What is your published SLA? What are the financial credits for breach?",
          "evasive_signal": "'99.9% effort' without SLA language. Or credits capped at one month invoice (negligible for enterprise).",
          "verification": "Negotiate financial credits that reflect business impact, not vendor list price."
        },
        {
          "id": "Q-OPS-02",
          "ask": "Show the last 12 months of incident history with severity, duration, and root cause.",
          "evasive_signal": "Status page only shows last 30 days; or no public incident history.",
          "verification": "Request the postmortem records for any P0/P1 in the last year."
        },
        {
          "id": "Q-OPS-03",
          "ask": "How do you handle quota/rate-limit changes - specifically, can our quota be reduced without notice?",
          "evasive_signal": "'Subject to fair use' clauses that allow unilateral rate-limiting.",
          "verification": "Contractual minimum sustained rate with quantitative measure (RPS, TPM)."
        },
        {
          "id": "Q-OPS-04",
          "ask": "What's the latency p50 / p95 / p99 commitment for our region under expected load?",
          "evasive_signal": "p50 only; no p99 commitment; latency 'guidance' instead of SLA.",
          "verification": "Run load tests from your region. Confirm vendor's published latency numbers match production."
        },
        {
          "id": "Q-OPS-05",
          "ask": "What is the maximum vendor outage duration in the last 12 months and the cause?",
          "evasive_signal": "Vendor unwilling to specify duration of past incidents.",
          "verification": "Cross-reference with public status page archives and customer reports."
        },
        {
          "id": "Q-OPS-06",
          "ask": "Do you provide a multi-region fallback? What is the customer experience during a regional failover?",
          "evasive_signal": "'We handle failover transparently' without describing what changes (model version? latency? data residency?).",
          "verification": "Test failover by querying the alternate region endpoint and confirming behavior matches primary."
        },
        {
          "id": "Q-OPS-07",
          "ask": "What is your maintenance window policy? How much notice for breaking changes?",
          "evasive_signal": "'Best effort' notice; breaking changes without versioning.",
          "verification": "Contractual minimum notice (90+ days) for breaking API or behavior changes."
        }
      ]
    },
    {
      "id": "DIM-SEC",
      "name": "Security posture",
      "description": "How the vendor protects customer data, secrets, and tenant boundaries against intentional adversaries.",
      "questions": [
        {
          "id": "Q-SEC-01",
          "ask": "What is your encryption at-rest and in-transit? Specifically: key management - vendor-managed, customer-managed, or BYOK?",
          "evasive_signal": "'TLS 1.2+' without specifying key management; encryption at rest not customer-controlled.",
          "verification": "BYOK support for sensitive customer data. Verify by submitting a customer-rotated key and confirming rejection on rollback."
        },
        {
          "id": "Q-SEC-02",
          "ask": "How are administrative actions on our tenant logged, and can we receive these logs in real time?",
          "evasive_signal": "Admin actions logged but not exported to customer; vendor employees can access tenant data with weak audit.",
          "verification": "Confirm SIEM integration is available. Request a sample audit log of admin actions on a test account."
        },
        {
          "id": "Q-SEC-03",
          "ask": "What is your background-check policy for engineers with production access?",
          "evasive_signal": "Vendor will not specify the policy; or 'standard industry practice' without naming the standard.",
          "verification": "Request the specific policy document and confirm via SOC 2 audit scope."
        },
        {
          "id": "Q-SEC-04",
          "ask": "Have you been breached in the last 24 months? Describe scope and customer notification timeline.",
          "evasive_signal": "'We don't discuss security incidents publicly' or vague answers.",
          "verification": "Cross-reference with public breach databases (e.g., have-i-been-pwned, security news). A vendor that won't say is a red flag."
        },
        {
          "id": "Q-SEC-05",
          "ask": "What is your pen-test cadence and who performs it? Will you share the executive summary?",
          "evasive_signal": "Internal pen-test only; or external pen-test summary not available even under NDA.",
          "verification": "Read the executive summary; check for unresolved high-severity findings."
        },
        {
          "id": "Q-SEC-06",
          "ask": "How do you protect customer prompts from cross-tenant exposure via embedding leakage or shared context?",
          "evasive_signal": "Vendor does not address embedding-level isolation, only document-level.",
          "verification": "Architecture review with vendor's security team. Test by submitting a unique synthetic identifier in tenant A and querying tenant B."
        },
        {
          "id": "Q-SEC-07",
          "ask": "What is your customer-facing vulnerability disclosure policy? Bug bounty? Mean time to fix?",
          "evasive_signal": "No bug bounty; no published vulnerability disclosure policy.",
          "verification": "Check the vendor's security.txt and published policy. Lack of process is a warning sign."
        }
      ]
    },
    {
      "id": "DIM-COMM",
      "name": "Commercial structure",
      "description": "Whether the pricing, contract terms, and exit ramp match a multi-year enterprise dependency.",
      "questions": [
        {
          "id": "Q-COMM-01",
          "ask": "What is the price-protection commitment over the contract term? What happens at renewal?",
          "evasive_signal": "Vendor will only commit to current-term pricing; renewal price uncapped.",
          "verification": "Contractual price-cap on renewal (CPI + N% maximum)."
        },
        {
          "id": "Q-COMM-02",
          "ask": "What is the data export format and timeline at end of contract? Specifically: vector embeddings, fine-tuned models, conversation history?",
          "evasive_signal": "Vendor exports only customer-provided source data, not derived artifacts.",
          "verification": "Pre-contract export test; confirm exports include all artifacts you'll need to migrate."
        },
        {
          "id": "Q-COMM-03",
          "ask": "Can we test our intended workload before commercial commitment? What's the trial structure?",
          "evasive_signal": "Trial limited to demo workloads; or requires immediate commercial commitment.",
          "verification": "30-90 day PoC at near-production scale before signing."
        },
        {
          "id": "Q-COMM-04",
          "ask": "What is the customer-success structure for our deployment size? Who is the named technical contact?",
          "evasive_signal": "Customer success means quarterly slides; no named technical contact; support tier mismatched to deployment scale.",
          "verification": "Named technical contact with documented availability; escalation path defined."
        },
        {
          "id": "Q-COMM-05",
          "ask": "What happens to our deployment if you are acquired, restructured, or sunset a product line?",
          "evasive_signal": "Vendor will not address this scenario.",
          "verification": "Source-code escrow or 18-month sunset notice clause for product-line deprecation."
        },
        {
          "id": "Q-COMM-06",
          "ask": "What is the exclusivity / change-of-control protection? Can a competitor acquire access to our deployment data?",
          "evasive_signal": "Standard M&A clause without customer protections.",
          "verification": "Contractual right to terminate without penalty on change of control; data export window guaranteed."
        }
      ]
    },
    {
      "id": "DIM-VEND",
      "name": "Vendor stability",
      "description": "Whether the vendor will still be around - and around in the same form - in three years.",
      "questions": [
        {
          "id": "Q-VEND-01",
          "ask": "How long have you been in business? What is your runway (for private vendors) or revenue trend (for public)?",
          "evasive_signal": "Refusal to provide runway info; revenue trend declining; recently pivoted from non-AI business.",
          "verification": "Public financial filings for public vendors; reference customers for private vendors."
        },
        {
          "id": "Q-VEND-02",
          "ask": "Who are your top three customers by revenue? What is concentration risk?",
          "evasive_signal": "Customer concentration > 30% from one customer; or unwilling to share at any granularity.",
          "verification": "Public reference customers + analyst commentary on concentration."
        },
        {
          "id": "Q-VEND-03",
          "ask": "What is your engineering team retention rate? Specifically: tenure of senior ML/AI engineers?",
          "evasive_signal": "Vague answers; recent senior departures around key features we depend on.",
          "verification": "LinkedIn analysis of senior team tenure; check Glassdoor for engineering culture signals."
        },
        {
          "id": "Q-VEND-04",
          "ask": "What is your model-strategy roadmap? Specifically: which models do you build vs license vs wrap?",
          "evasive_signal": "Vendor wraps a single foundation model without proprietary differentiation; or strategy keeps changing.",
          "verification": "Track public roadmap consistency over the last 18 months."
        },
        {
          "id": "Q-VEND-05",
          "ask": "Who is your largest competitor and how do you differentiate? What is your moat?",
          "evasive_signal": "Vendor cannot articulate moat clearly; or moat is solely about pricing or features that competitors match.",
          "verification": "Test the moat: can the competitor's product replace this one in your deployment in 6 months?"
        },
        {
          "id": "Q-VEND-06",
          "ask": "What is your customer churn rate? Specifically: enterprise customers > $100K ARR.",
          "evasive_signal": "Vendor will not share enterprise churn; or churn rate > 15% in enterprise tier.",
          "verification": "Reference customers; analyst commentary; LinkedIn signals of customer departures."
        }
      ]
    },
    {
      "id": "DIM-INT",
      "name": "Integration surface",
      "description": "Whether the platform integrates cleanly with your stack today and is portable away from the vendor in the future.",
      "questions": [
        {
          "id": "Q-INT-01",
          "ask": "Is your API surface OpenAPI-spec'd? Versioned? With deprecation policy?",
          "evasive_signal": "API documented only in human-readable form; no machine-readable spec; no versioning.",
          "verification": "Download and validate the OpenAPI spec; check version history."
        },
        {
          "id": "Q-INT-02",
          "ask": "Is your client SDK open-source? What's the language coverage?",
          "evasive_signal": "Proprietary SDK without source access; limited language coverage forcing us to maintain custom clients.",
          "verification": "Inspect SDK code; check that it doesn't have vendor-lock side effects."
        },
        {
          "id": "Q-INT-03",
          "ask": "Do you support standard SSO (SAML, OIDC) for admin access and customer end-user authentication?",
          "evasive_signal": "Username/password only; or 'enterprise SSO' requires premium tier.",
          "verification": "Integration test with our IdP (Okta, Azure AD, etc.)."
        },
        {
          "id": "Q-INT-04",
          "ask": "What logging and observability hooks do you provide? Specifically: structured event stream we can consume?",
          "evasive_signal": "Logs only via vendor dashboard; no programmatic access; no webhook event stream.",
          "verification": "Confirm webhook event stream with our SIEM/observability platform."
        },
        {
          "id": "Q-INT-05",
          "ask": "What is the migration path from a competing vendor to yours, and from yours to a competitor?",
          "evasive_signal": "Vendor explains incoming migration but not outgoing.",
          "verification": "Request migration documentation; check that exports include conversation context, embeddings, and fine-tune artifacts."
        },
        {
          "id": "Q-INT-06",
          "ask": "Is your deployment OpenAPI-compatible with the standard LLM gateway pattern? Can we put a gateway between our app and you to enable multi-vendor?",
          "evasive_signal": "Vendor requires direct SDK usage; gateways unsupported or undocumented.",
          "verification": "Test with an open-source LLM gateway (e.g., LiteLLM, Portkey) and confirm semantic compatibility."
        }
      ]
    }
  ],
  "summary": {
    "total_questions": 60,
    "dimensions": 8,
    "max_score": 180,
    "by_dimension": {
      "Regulatory fit": 7,
      "Data handling": 7,
      "Model integrity": 7,
      "Operational reliability": 7,
      "Security posture": 7,
      "Commercial structure": 6,
      "Vendor stability": 6,
      "Integration surface": 6
    }
  },
  "see_also": {
    "position_page": "https://www.slavin.ai/Architect-vs-AI.aspx",
    "failure_modes_catalog": "https://www.slavin.ai/data/ai-failure-modes-catalog.json",
    "incident_response_playbook": "https://www.slavin.ai/data/ai-incident-response-playbook.json",
    "vendor_pricing_intelligence": "https://www.slavin.ai/data/llm-vendor-pricing.json",
    "governance_baseline": "https://www.slavin.ai/data/ai-governance-baseline.json"
  }
}
