Connecting an AI service to business systems can create value quickly, but it also creates a dependency on an organization you do not control. The vendor may process sensitive information, hold credentials, rely on additional subprocessors, change its service, or become unavailable at a critical moment.
Third-party risk review is not about proving that a vendor is perfectly safe. It is about understanding the dependency well enough to decide whether the risk is acceptable and what controls are needed around it.
Understand the data flow
Document what information leaves your environment, why the vendor needs it, where results return, and what downstream systems can act on those results. Ask whether the service retains inputs or outputs, for how long, and for what purposes.
Do not assume that a vendor’s general privacy statement answers the questions for your specific product, plan, API, or configuration.
Clarify model and data-use terms
For AI services, determine whether customer data may be used to train or improve models, whether that behavior can be disabled, and whether different contractual tiers have different terms. Understand what happens to data when an account or contract ends.
Review identity and access
Ask how users and service integrations authenticate, whether strong authentication is available for administrative access, how API credentials are managed, and whether permissions can be scoped to the minimum required access.
Within your own environment, avoid giving a vendor integration broader access simply because it is easier to configure.
Look beyond the vendor itself
Important services often depend on cloud providers, model providers, identity platforms, communications services, or other subprocessors. Understand which dependencies are material to your use and how changes to those relationships are communicated.
Ask how incidents are handled
Determine how the vendor detects and communicates security incidents relevant to customers, what contractual notification commitments apply, and how your organization would coordinate investigation. Your own incident-response plan should include important third parties rather than assuming the vendor will manage everything.
Plan for service failure and exit
Consider what happens if the service is unavailable, pricing changes significantly, a feature is discontinued, or the organization decides to leave. Can critical data be exported? Can credentials be revoked? Is there a manual or alternate operating path for important workflows?
Exit planning is easier before a vendor becomes deeply embedded in daily operations.
Match diligence to consequence
A low-impact writing assistant and an integration that can access sensitive records or trigger consequential actions should not receive identical review. Scale due diligence based on data sensitivity, permissions, business criticality, autonomy, reversibility, and the consequence of failure.
Third-party risk management works best as an ongoing relationship. Reassess material changes rather than treating the initial vendor questionnaire as permanent approval.