The AI Vendor DDQ: 3 Questions Your SaaS Security Form Misses

Most regulated firms evaluate AI vendors using standard SaaS security forms. This fails because standard IT forms miss the three specific controls APAC regulators demand for AI: training-data retention, model update frequency, and inference logging. A compliant AI vendor Due Diligence Questionnaire (DDQ) must isolate these three AI-specific risks to satisfy HKMA and MAS outsourcing guidelines. You are reading this because your compliance team is trying to map OpenAI, Anthropic, or Microsoft Copilot into an old risk framework. The trap is assuming a SOC2 report covers AI data behavior. It doesn't. The reality is that AI risk is fundamentally different from traditional cloud storage risk.

Why do standard SaaS security questionnaires fail for AI vendors?

You send your standard 150-question IT security spreadsheet to a new AI vendor. The vendor returns it with every box checked. They have SOC2 Type II. They encrypt data at rest and in transit. They enforce role-based access control. You file the questionnaire, approve the vendor, and let your employees start using the tool.

Then the Monetary Authority of Singapore (MAS) or the Hong Kong Monetary Authority (HKMA) issues an update on third-party risk management. You realize your standard form never asked what happens to the data after it enters the prompt box.

Standard SaaS forms treat data as a static asset. You upload a file, the system stores it, you download it later. AI systems treat data as fuel. The moment your employee pastes a client portfolio into an AI tool, that data is processed through a model. Your IT form asks how the data is stored. It never asks if the vendor uses that data to train their future models.

According to the PCPD (Privacy Commissioner for Personal Data) in Hong Kong, organizations must clearly understand how third parties process personal data in AI systems. If your vendor uses your customer data to improve their base model, you have effectively leaked that data to the public. Your standard security questionnaire is blind to this.

You are also blind to model drift. Traditional software updates change the interface or fix bugs. AI model updates change how the system reasons. When an AI vendor silently updates their underlying model, the outputs your team relies on can degrade or change entirely. Your standard form has no mechanism to track this.

Your risk committee is operating on a false sense of security. You have documented proof that the vendor's servers are secure, but zero proof that their AI behavior is safe. The gap between your written policy and actual vendor behavior is where regulatory fines happen.

What is the difference between SaaS security and AI governance?

The default view in mid-market compliance is that AI is just another software category. You assume the existing vendor risk management process works. You think if Microsoft or Google provides the AI, the risk is managed.

This is a dangerous assumption. Data security and AI governance are entirely different disciplines. Data security focuses on who can access the database. AI governance dictates how the machine interprets the data.

When I review the AI posture of regulated firms in APAC, I see the same pattern. The risk officer relies on the vendor's general terms of service. They treat AI risk as a binary approved or unapproved status. They miss the compliance gradient.

My view is that you must treat the AI model as an active participant in your business, not a passive storage drive. The HKMA SA-2 guidelines emphasize continuous monitoring of third-party services. You can't continuously monitor an AI system if you don't log its decisions.

Most firms fail to ask for inference logging. Inference is the actual generation of an answer by the AI. If an employee uses an AI tool to draft a sensitive client email, and the client complains about the advice, you need to prove exactly what the AI generated versus what the employee edited. If the vendor doesn't log the inference, you have no audit trail. Evidence over summaries is the rule. You need artifacts, not assurances.

The ISO 42001 standard for AI management systems requires clear documentation of the AI system's lifecycle. A standard DDQ ignores the lifecycle entirely. It assumes the tool you buy in January is the exact same tool in December. With AI, the model evolves, the guardrails shift, and the risk profile changes monthly.

You must stop treating AI vendors like cloud storage providers. You are not renting space. You are renting a reasoning engine. You can't secure a reasoning engine with a padlock.

How do you build an AI DDQ that satisfies HKMA and MAS?

To fix this, you must rebuild your vendor onboarding process. You need a dedicated AI addendum to your standard DDQ. This addendum doesn't replace your security checks. It isolates the specific operational risks that AI introduces.

Here is how you adjust your vendor assessment to satisfy APAC regulators:

* Demand explicit training-data opt-outs. Force the vendor to state in writing that your prompt data, uploaded files, and generated outputs will never be used to train their base models or fine-tune models for other customers. This is the only way to satisfy PCPD data privacy expectations. * Require model update notifications. Establish a contractual obligation for the vendor to notify your IT team at least 30 days before they deprecate a model or roll out a major version update. You need time to test the new model against your internal benchmarks. * Verify inference logging capabilities. Ask the vendor to demonstrate how your administrators can export prompt and response logs. You need these logs in a structured format to satisfy internal audit requirements and prove exactly what happened during an incident. * Map the sub-processor chain. Identify exactly which foundational model the vendor uses. If you buy a specialized legal drafting tool, you must know if it calls OpenAI, Anthropic, or an open-source model under the hood. You inherit the risk of the base model. * Establish an emergency kill-switch. Define the exact process for your administrators to instantly revoke user access across your entire firm if a model begins hallucinating or leaking sensitive data. A written policy means nothing if you can't physically stop the data flow.

These five steps move your firm from passive trust to active governance. When the MAS Outsourcing guidelines require you to maintain control over your third-party arrangements, this is what control looks like. You are no longer relying on a generic SOC2 report. You are demanding specific operational proof of how the AI behaves. This is how you build boring, reliable AI that your risk committee will actually approve.

The reality of vendor risk

Your standard SaaS security form is a relic. It protects you from yesterday's data breaches while leaving you completely exposed to today's AI risks. Update your DDQ to ask about training retention, model updates, and inference logging. The regulators will eventually ask you for this evidence. It's better to have the answers ready before they do.