Vendor Due Diligence for AI Implementation Partners
Due diligence should test architecture, security thinking, production experience, and evidence of delivery.
Specify the task, permitted data, system interfaces, acceptance evidence, and operating responsibilities. Ask bidders to separate existing product capability from new development and price implementation, recurring access, usage, and support distinctly.
Specify the Outcome and System Boundary
Name the user task, permitted information, source systems, interfaces, and expected deliverables. Ask the supplier to distinguish existing functionality, configuration, and new development.
Write Observable Acceptance Criteria
Describe the test, evidence, responsible reviewer, and conditions for acceptance. Use task-specific evidence instead of vague promises of enterprise-grade AI.
Example: Illustrative requirement: the authorized test user can retrieve the approved policy and its supporting passage; the unauthorized user cannot retrieve that passage through the tested interface. Adapt the test to the actual access model.
Address Portability and Operating Responsibilities
Document data export, transition help, configuration ownership, support, incident handling, and third-party dependencies. State who maintains source content and permissions after delivery.
Separate the Price Components
Break out discovery, implementation, recurring access, usage, support, and changes. Treat sample language as a scoping aid for the buyer and counsel to adapt to the actual procurement.
Two proposals can describe the same assistant while assigning very different work to the buyer. One may include source cleanup and ongoing connector maintenance; another may assume the customer supplies prepared content and handles upstream changes. Ask both bidders to state those assumptions before comparing prices. The same applies to acceptance: identify who supplies test questions and who resolves conflicting source material. A clear division of work helps the buyer compare the actual delivery obligations and reduces the chance that an attractive initial price depends on substantial unpriced effort.
Discuss the implementation scope with Sprinklenet. A useful starting point: a scope and acceptance-criteria review for a planned AI integration purchase.
References
The recommendations above are Sprinklenet’s practical guidance. Technical context: OMB M-25-22, April 3, 2025, NIST Secure Software Development Framework.
