Consider a hypothetical vendor that completes a SIG Core assessment in March with acceptable answers in every domain. In June, the vendor moves its document-summary feature to a new model provider and starts to keep prompts for quality review. Your assessment file has not changed, but your confidential data now goes to an external party that you have never assessed.
Nothing in that story is a control failure, because every answer was true when the vendor gave it. The risk comes from a change that a point-in-time questionnaire cannot examine, in a part of the service that AI questions alone does not describe.
If you already run SIG assessments, you have most of what you need. This article shows how to apply the SIG or similar assessments to AI-enabled vendors in four steps. Choose the scope from inherent risk, extend the domains you already assess, ask for evidence that matches the risks, and keep the assessment current.
SIG already includes an AI domain, so the task is to scope it well
Shared Assessments added an Artificial Intelligence risk domain in SIG 2024, and the questionnaire now covers 21 risk domains. The SIG also maps to the NIST AI Risk Management Framework (NIST AI 100-1) and to ISO/IEC 42001, which gives assessors a shared reference for AI governance questions.
The AI domain is a starting point and most AI risk appears where it touches data, access, change, suppliers, and resilience, and other SIG domains already cover those areas. A vendor may give acceptable answers in the AI domain while its logs sit outside your privacy review and its underlying model provider sits outside your Nth-party inventory.
Remember also that the SIG is an information-gathering standard, it collects structured answers and evidence, and your own processes for intake, risk acceptance, remediation, contracts, and monitoring decide what those answers mean.
Let inherent risk choose the questionnaire, not the presence of AI
Shared Assessments recommends that your choice of SIG Lite, SIG Core, or a Custom SIG follow the inherent-risk rating of the service. AI may raise that rating, but just adding AI doesn’t automatically change it. An internal writing assistant that never sees confidential data carries a different risk from a third-party engine that scores loan applicants or triages insurance claims.
| SIG option | Intended use | Fit for AI-enabled services |
|---|---|---|
| SIG Lite | Lower-risk third parties, pre-assessments, and preliminary review | Screening a low-impact AI feature that does not process sensitive data or influence consequential decisions |
| SIG Core | Medium- to high-risk third parties, sensitive or regulated data, and critical services | An AI service that processes confidential or regulated data, supports a material process, or affects customers or employees |
| Custom SIG | Cases where the preconfigured templates do not fit | Pairing the AI domain with the specific domains the AI touches, at the scope level each one needs |
A Custom SIG lets you select risk domains, mapping references, or control families, set Lite, Core, or Detail scope for each, and add questions from the Content Library. For many AI-enabled services, this may be the most efficient design. You can go deep on the AI and its data paths without a full Detail assessment of everything else.
Confirm that AI is material before you extend the assessment
Because of the hype surrounding AI, base the decision on facts about the service, not on the vendor’s marketing language. The questions below can guide a short scoping conversation with the business owner, procurement, legal, privacy, security, and the vendor and can feed intoyour AI register.
| Scoping question | What the answer tells you | Evidence to request |
|---|---|---|
| What does the AI do in this service? | Whether AI is incidental, assistive, or central to delivery | Product description, architecture diagram, AI system inventory |
| What data, prompts, files, or outputs enter the AI system? | Your confidentiality, privacy, retention, and residency exposure | Data-flow diagram, data classification, retention schedule |
| Does the vendor use your data to train, fine-tune, or evaluate models? | Whether your data has a secondary use beyond service delivery | Contract terms, data-use policy, opt-out controls |
| Which models and external providers support the service? | Your fourth-party and supply-chain dependencies | Subprocessor list, model-provider list, change-notification process |
| Does AI output influence a decision about a person? | How much human oversight, testing, fairness review, and recourse you need | Decision workflow, human-review controls, bias and performance testing |
| How does the vendor change models, prompts, retrieval sources, and agents? | Whether risk can change without a conventional software release | Versioning records, release approvals, rollback procedures |
| How does the vendor detect and handle AI-specific incidents? | Whether incident response covers prompt leakage, unsafe output, and poisoning | Incident-response plan, monitoring procedures, notification terms |
If the answers show that AI is incidental and sees no sensitive data, the standard assessment may be enough. If the answers show sensitive data, consequential decisions, or external model providers, extend the assessment as the next section describes.
Extend the domains you already assess to cover AI
Treat AI as an overlay across your existing SIG domains rather than a separate checklist. This keeps AI findings inside the control areas your team already knows how to evaluate, escalate, and remediate.
| SIG domain | AI extension to add |
|---|---|
| Privacy Management and Asset and Information Management | Retention of prompts, files, and outputs, use of customer data for training, and the location of model processing |
| Access Control | Who can change model settings, system prompts, and retrieval stores, and whether retrieval enforces each user’s permissions |
| Application Management | Version control, approval, and rollback for changes to models, prompts, and retrieval sources |
| Nth Party Management and Supply Chain Risk Management | Model providers, hosting providers, and data suppliers, with commitments to notify you of changes |
| Cybersecurity Incident Management | Detection and response for prompt injection, data leakage through outputs, model abuse, and data poisoning |
| Operational Resilience | Fallback models, safe degradation, and recovery from a model-provider outage |
| Threat Management | Adversarial testing of AI features before release and after material changes |
The hypothetical vendor in the opening would have triggered two of these extensions. Nth-party questions would have asked how the vendor tells you about changes in model provider, and privacy questions would have uncovered whether it keeps prompts and for how long.
Ask for evidence that matches the stakes, not for AI principles
A responsible-AI statement tells you what a vendor intends, but it is inadequate evidence of what the vendor does. Investigation into implemented controls and results often need independent verification.
Adjust the evidence requirements to the impact of the use case. For a low-risk feature, a description of data handling, a contract term that restricts training, and confirmation of access and retention controls may be enough. For a high-risk or business-critical service, you may need architecture documents, model and subprocessor inventories, test summaries, security assessment reports, a privacy impact assessment, and proof of human oversight.
Five properties can structure what you ask the vendor to demonstrate:
- Accountability: the vendor can name who reviews outputs, accepts residual risk, investigates incidents, and tells you about material changes.
- Control: the vendor can approve changes, manage data use, restrict access, and enforce retention.
- Traceability: the vendor can identify the data sources, model, system boundaries, and responsible people.
- Testing: the vendor tests accuracy, security, reliability, privacy, and relevant fairness risks before and after material changes.
- Resilience: the vendor can continue service, or degrade it safely, when a model or provider fails.
Hold your own AI assessment tools to the same standard
AI can make the SIG process faster by classifying vendor responses, finding unanswered questions, comparing answers with earlier assessments, mapping evidence to controls, and flaging contradictory statements.
AI-generated summaries can also be wrong, incomplete, or overconfident, and an assessment tool often holds some of your most sensitive vendor evidence. Apply the same rigour you apply to vendors. Restrict what data the tool can reach, and keep confidential evidence away from unapproved models. Test the tool for prompt injection and disclosure, keep an auditable record of material decisions, and require a person to validate every finding.
Put the findings in the contract and reassess when the AI changes
AI findings carry weight only when they reach the contract. Contract terms may state whether the vendor can use your data for training or service improvement. They may also name the subprocessors and model providers that can receive your data, and set how the vendor reports incidents that involve prompts or model behaviour. Terms may also cover notice of material changes, cooperation with investigations, access to relevant test results, and the return or deletion of data at termination. Keep these terms proportionate to risk, and do not ask for transparency that the vendor cannot realistically give.
A completed SIG exposes the service on the day the vendor answered it. AI services can change through model updates, new retrieval sources, revised system prompts, new tools, or new providers, so define the events that start a reassessment:
- a new AI use case, or a new type of data that enters the AI system
- a new model provider, or a significant model update
- a security or privacy incident that involves the AI
- a relevant regulatory change
- a change in the business criticality of the service
In the opening example, a change-notification clause and a reassessment trigger for new model providers would have brought the June change to your attention before it became a surprise.
Build the capability in stages
You do not need a complete AI assessment program before you ask your first AI question. Each stage below builds on the one before it.
| Stage | Focus | Outcome |
|---|---|---|
| Foundational | Record AI use, data types, business owner, and vendor dependencies at intake | You can see and rank your AI-enabled relationships |
| Defined | Add standard AI scoping questions to your SIG workflow | Assessors apply the same criteria to every vendor |
| Evidence-based | Require control evidence, test summaries, contract restrictions, and change commitments | Decisions rest on demonstrated practice, not vendor assurance |
| Continuous | Monitor changes, incidents, model providers, and reassessment triggers | You manage AI risk for the full life of the relationship |
| Optimised | Combine SIG results with technical monitoring, privacy review, and business-impact data | You direct effort to the AI risks that matter most |
Start with your next AI-enabled assessment
The SIG gives you a common structure for vendor controls, and its AI domain gives you a starting set of questions. The value comes from connecting them to your use cases. On your next AI-enabled vendor, choose the scope from inherent risk and extend the domains the AI touches. Then ask for evidence that matches the impact, and write the reassessment triggers into the contract. If you do those four things consistently, the June change in the opening story becomes a notice you receive, not a risk you discover.