Skip to content

AI Governance & Regulation: EU AI Act, NIST AI RMF and ISO/IEC 42001 · Operating AI governance in a company · lesson 14 of 17 · 15 min

Model and vendor due diligence

Most of your AI risk is third-party risk

Few SMEs build models. They buy AI inside SaaS products, call model APIs, and use plug-ins and agents that connect to their data. So most AI risk sits in contracts, configurations and vendor behavior. Due diligence is how you find out what you are actually buying.

A tiered approach

Not every tool deserves a 60-question review. Tier by risk from your inventory:

| Tier | Example | Depth | |---|---|---| | Light | Grammar assistant with no client data | Terms check: training on inputs, retention, security basics | | Standard | Chat assistant used with client data; transcription | Security and privacy questionnaire, DPA, sub-processors, data location, model documentation | | Enhanced | Customer-facing chatbot, HR or credit tools, agents with write access to systems | All of the above plus testing, AI Act classification evidence, incident terms, audit rights, exit plan |

Core due-diligence domains

  1. Data use: Are our inputs and outputs used to train or improve models? Default and contractual position? Retention periods? Deletion on request? Human review of our data by the vendor?
  2. Security: Independent attestations (for example SOC 2 Type II or ISO/IEC 27001), encryption, access controls, SSO, audit logs, vulnerability management, penetration testing.
  3. Privacy: DPA available; roles (processor or controller); sub-processors list; data location and transfer mechanisms (EU SCCs, UK IDTA, KSA and UAE transfer rules).
  4. Model transparency: which underlying models are used; model cards or documentation; known limitations; evaluation results; how model changes are communicated.
  5. Regulatory posture: EU AI Act classification of the product and the vendor's role; Article 50 support (disclosures, content marking); GPAI Code of Practice status of underlying model providers; ISO/IEC 42001 certification or alignment.
  6. Safety and misuse: content filters, abuse monitoring, red-teaming, prompt-injection defenses for agents and connectors.
  7. Operations: SLAs, uptime history, support, incident notification timelines, rate limits.
  8. Commercial and exit: IP ownership of outputs; indemnities (some vendors offer IP indemnity for outputs under conditions); data export; termination and deletion; price change terms.

Special attention: agents and connectors

Tools that let AI act (send emails, update CRM records, run code, browse) or connect to your data (via APIs or MCP servers) expand risk:

  • Least privilege: grant only the scopes needed; separate read from write.
  • Human approval for irreversible or external actions.
  • Prompt injection: untrusted content (emails, web pages, documents) can contain instructions that hijack an agent. Ask how the vendor mitigates it and test it yourself.
  • Audit logs of every action taken.

Contract clauses to look for or request

  • No training on customer data without opt-in.
  • Defined retention and deletion, including logs and backups.
  • Sub-processor change notification with objection rights.
  • Security incident notification within a defined period.
  • Notice of material model changes that could affect outputs.
  • Cooperation with regulatory requests and your impact assessments.
  • Output ownership and, where offered, IP indemnity terms and their conditions.
  • Data export in usable formats on exit.

Worked example: a Lahore agency choosing a transcription and meeting-notes tool

Three candidates. The team runs a standard-tier review:

| Check | Tool A | Tool B | Tool C | |---|---|---|---| | Training on customer data | Off by default, contract | Opt-out required | On for free tier | | DPA and sub-processor list | Yes | Yes | No | | Data location options | EU, US | US only | Unknown | | Security attestation | SOC 2 Type II | ISO/IEC 27001 | None stated | | Notice to meeting participants | Built-in bot announcement | Manual | None | | Retention controls | Admin-configurable | Fixed 1 year | Unknown |

They choose Tool A, configure a 90-day retention, enable participant notices, and add it to the approved-tools list as "client calls allowed with notice".

Hands-on: a vendor AI questionnaire (standard tier)

Vendor AI questionnaire v1.2
A. Data use
 A1. Are customer inputs/outputs used to train or improve any model? Default and contractual position?
 A2. Retention periods for prompts, outputs, logs, backups. Can we configure them?
 A3. Do vendor staff review customer content? When and under what controls?
B. Security and privacy
 B1. Current SOC 2 Type II or ISO/IEC 27001 report or certificate (date)?
 B2. DPA, sub-processor list, data locations, transfer mechanisms.
 B3. SSO, role-based access, audit logs available to us?
C. Models
 C1. Which foundation models power the product? Which versions? How are changes notified?
 C2. Model documentation, known limitations, evaluation results relevant to our use.
 C3. Underlying model providers' GPAI Code of Practice status (if known).
D. Regulation
 D1. Your EU AI Act classification of the product and your role. Any high-risk intended purpose?
 D2. Support for Article 50 (chatbot disclosure, machine-readable marking of generated content).
 D3. ISO/IEC 42001 certification or alignment?
E. Safety
 E1. Content filtering, abuse monitoring, red-teaming.
 E2. Prompt-injection mitigations for agents/connectors; permission scopes.
F. Operations and exit
 F1. SLA, incident notification timeline, status page.
 F2. Output ownership; IP indemnity (conditions).
 F3. Data export and deletion on termination.

Measuring success

Every standard and enhanced tool has a completed questionnaire, a DPA where personal data is processed, a named owner and a review date. Re-review on renewal, major model change or incident.

Pitfalls

  • Using free tiers for client work when the terms allow training on inputs.
  • Accepting "we are compliant with all regulations" as an answer. Ask for specifics and evidence.
  • Forgetting to re-review when the vendor swaps the underlying model.

Video lecture: Model and vendor due diligence

Lecture coming soon · 13 chapters · about 8 minutes. Read the full transcript below.

  1. Vendor due diligence
  2. Why due diligence
  3. Tier your reviews
  4. Analogy: an after-hours contractor
  5. Eight domains
  6. Agents and connectors
  7. Contract clauses
  8. Worked example: meeting-notes tool
  9. Keep it current
  10. Example 2: Riyadh WhatsApp booking agent
  11. Review on triggers
  12. Watch me do it: vendor questionnaire
  13. Recap and next step

Lecture transcript

Vendor due diligence

Most small businesses never build an AI model. They buy AI inside software, call model APIs, and connect agents to their data. That means most of your AI risk is really vendor risk, hidden in terms of service, default settings and contracts. In this lesson, you'll learn a tiered approach to due diligence, the eight domains to check, extra care for agents and connectors, the contract clauses that matter, and a ready-made questionnaire.

Why due diligence

Why does due diligence matter so much for small teams? Because you inherit your vendors' practices. If a transcription tool trains on your client calls, your clients' confidential information has left your control. If a chatbot vendor stores conversations abroad, you may be breaching a data transfer rule. If an agent platform has weak permissions, a single malicious email could trigger actions in your CRM. You can't outsource accountability, so you need to know what you're buying.

Tier your reviews

Don't give every tool the same sixty-question review. Tier it. Light tier, for something like a grammar assistant with no client data: check whether inputs are used for training, retention and security basics. Standard tier, for a chat assistant used with client data or a transcription tool: a security and privacy questionnaire, a data processing agreement, sub-processors, data location and model documentation. Enhanced tier, for customer-facing chatbots, HR or credit tools, and agents with write access: all of that plus testing, AI Act classification evidence, incident terms, audit rights and an exit plan.

Analogy: an after-hours contractor

An analogy: vendor due diligence is like hiring a contractor to work inside your office after hours. You'd check references, see their insurance, agree which rooms they can enter, know who else they'll bring, and make sure you get the keys back when the job ends. AI vendors often get access to your most sensitive data, your clients' conversations, documents and customer lists. The questions are the same: who are you, what can you touch, who else is involved, what happens if something goes wrong, and how do I get my data back?

Eight domains

There are eight domains to cover. Data use: are your inputs used for training, how long are they kept, and do vendor staff read them? Security: independent attestations like SOC two type two or ISO twenty-seven thousand and one, encryption, single sign-on and audit logs. Privacy: the processing agreement, sub-processors, data location and transfer mechanisms. Model transparency: which models, which versions, documented limits and how changes are announced. Regulatory posture. Safety and misuse controls. Operations, like uptime and incident notification. And commercial and exit terms, including output ownership and data export.

Agents and connectors

Agents and connectors deserve extra care, because they let AI act: send emails, update the CRM, run code, browse the web, or connect to your data through APIs or MCP servers. Four rules. Least privilege: only the scopes needed, and separate read from write. Human approval for irreversible or external actions. Prompt injection defenses, because an email or web page can contain hidden instructions that hijack an agent. Ask the vendor how they handle it, and test it yourself. And audit logs of every action.

Contract clauses

Now contracts. Look for, or ask for: no training on your data without opt-in. Defined retention and deletion, including logs and backups. Notice of sub-processor changes with a right to object. Security incident notification within a set time. Notice of material model changes that could affect outputs. Cooperation with regulators and your impact assessments. Clear output ownership, and where vendors offer IP indemnity, read the conditions carefully. And data export in usable formats when you leave.

Worked example: meeting-notes tool

A worked example. A Lahore agency compared three meeting-notes tools. Tool A had training off by default in the contract, a processing agreement, EU and US data location options, a SOC two type two report, a built-in announcement to meeting participants, and configurable retention. Tool B required an opt-out for training, stored data only in the US and kept it for a fixed year. Tool C trained on free-tier data and had no processing agreement. They chose Tool A, set ninety-day retention, enabled participant notices, and listed it as approved for client calls with notice.

Keep it current

Measure it simply. Every standard and enhanced tool should have a completed questionnaire, a processing agreement where personal data is involved, a named owner and a review date. Re-review on renewal, when the vendor changes the underlying model, or after an incident. And watch three traps: free tiers used for client work when the terms allow training on your inputs; accepting we comply with all regulations as an answer; and forgetting to re-check when the vendor quietly swaps models.

Example 2: Riyadh WhatsApp booking agent

A second, enhanced-tier example. A Riyadh property developer wants an AI agent that answers buyers on WhatsApp and can book viewings directly into the sales calendar. Enhanced review: the vendor provides a security report, a processing agreement, the list of sub-processors and where conversations are stored, which matters under Saudi transfer rules. The team tests prompt injection by sending messages like cancel all viewings. They limit the agent to creating tentative bookings only, which a salesperson confirms. And the contract includes incident notice and data export on exit.

Review on triggers

A final practical tip: review vendors on triggers, not just on a calendar. The obvious triggers are contract renewal, a change of underlying model, a new data category, like starting to process health information, a new market with different data rules, and any security incident at the vendor. Put those triggers in the tool's inventory entry, so whoever owns the tool knows when a fresh review is due.

Watch me do it: vendor questionnaire

Watch me do it. The meeting-notes tool is standard tier, so I open the vendor questionnaire and fill it with the vendor's answers side by side. A one, training on customer data: the trust page says off by default for business plans, and the contract confirms it, so green. A two, retention: admin-configurable, so I set ninety days in the admin console right now and screenshot it. A three, human review of our content: only with our permission for support, green. B one, security attestation: SOC two type two report dated this year, I request it under NDA and file it. B two, processing agreement and sub-processors: signed, and the list shows EU and US processing, and I note our transfer mechanism. B three, single sign-on and audit logs: available on our plan, I switch on single sign-on. C one, underlying models: named, with change notices by email. E two, the bot joins calls, so I enable the automatic announcement to participants. F three, export and deletion on exit: documented. Then I link the completed questionnaire from the inventory row and set the next review for contract renewal.

Recap and next step

Recap. Tier your reviews by risk. Cover the eight domains. Give agents and connectors least privilege, human approval, injection defenses and logs. Negotiate the clauses that protect your data and your exit. Your next step: send the standard questionnaire from the lesson text to the vendor behind your highest-risk AI tool, and record the answers alongside the tool's inventory entry.

Key takeaways

  • Most SME AI risk is third-party risk; tier due diligence as light, standard or enhanced by risk.
  • Cover data use, security, privacy, model transparency, regulatory posture, safety, operations and exit.
  • Agents and connectors need least privilege, human approval for risky actions, prompt-injection defenses and audit logs.
  • Key clauses: no training without opt-in, retention and deletion, sub-processor and model-change notice, incident notice, output ownership, exit.

Try it

Send the standard vendor AI questionnaire to the vendor of your highest-risk AI tool. Record answers against its inventory entry and note any contract changes to request.