Answer once, honestly: the AI security questionnaire in 2026 and the pre-answered pack that survives it

Why doesn't last year's security questionnaire settle an AI purchase?

Because in 2026 the questionnaires themselves changed, and the answer library you built for a SaaS sale does not reach the new sections.

Two families dominate European AI procurement. The SIG — the Standardized Information Gathering questionnaire from Shared Assessments — is what a bank, an insurer or a large corporate sends. The CAIQ — the Consensus Assessments Initiative Questionnaire from the Cloud Security Alliance, the self-assessment behind the STAR Registry — is what a cloud-native buyer expects to find already published. Both moved this year, and both moved in the same direction: toward AI as a distinct assessment surface rather than a feature of a hosted service.

If you sell an AI system, the practical consequence is that a well-maintained SOC 2 answer set now covers perhaps two thirds of what arrives, and the missing third is exactly the part that decides the deal. If you buy one, the consequence is better: the questions you did not know how to ask have been written for you.

This is engineering and procurement guidance, not legal advice. Where the answers feed a regulated decision, the obligations are yours and your counsel's to apply.

What actually changed

CCM and CAIQ went to v4.1 on 27 January 2026. The Cloud Controls Matrix now carries 207 controls across 17 domains, and CAIQ v4.1 asks 283 questions against them. Eleven controls were added, one removed. The important detail for anyone maintaining a published self-assessment is the sunset: v4.0.x stays acceptable until 31 December 2027 and is withdrawn on 31 January 2028. A CAIQ on your trust page dated 2023 is not neutral — it is a statement that nobody has looked at it in three years.

The CSA shipped a separate AI framework. The AI Controls Matrix (AICM) is not a chapter of the CCM; it is its own control set, at v1.1 with 247 control objectives across 18 domains — up from 243 in v1.0, with a new Model Development Security domain covering model architecture, training data, weights protection, guardrails and inference. Its questionnaire, the AI-CAIQ, runs to roughly 320 questions and maps to ISO/IEC 42001, ISO/IEC 27001, NIST AI RMF 1.0, BSI AIC4 and the EU AI Act. Version numbers here move faster than blog posts do; check the registry rather than trusting these figures a year from now.

And a designation to go with it. STAR for AI Level 1 is a submitted AI-CAIQ self-assessment; a "Valid-AI-ted" variant adds machine validation of the submission; Level 2 requires an ISO/IEC 42001 certification alongside it. So the ladder now has a rung that costs a careful week of work and a rung that costs a certification programme, and buyers will learn to tell them apart.

SIG 2026 absorbed AI into the standard flow. It adds ISO/IEC 42001 as a reference standard, codifies AI governance and supply-chain resilience as ordinary requirements rather than an appendix, formalises scoping presets so a reviewer picks Lite, Core or Detail against the vendor's risk profile, and embeds guidance in the questions themselves to cut the clarification round-trips. Shared Assessments also launched a browser-based platform for distribution and scoring in March 2026.

Read together, the message is consistent: AI assurance is no longer a conversation you have after the security review passes. It is inside the security review.

The five-actor split is where most questionnaires stall

The single most useful idea in the AICM is not a control. It is the shared-responsibility model, which names five actors across a generative AI stack: the cloud service provider, the model provider, the orchestrated service provider, the application provider, and the AI customer.

Most vendors selling an AI product are the application provider. They run retrieval, orchestration and the interface on infrastructure they rent, calling a model they did not train. When a 320-question AI-CAIQ lands, a large share of it — training data provenance, model evaluation methodology, weights handling, base-model red-teaming — belongs to the model provider, and a further share belongs to the cloud provider underneath.

The failure mode is not that vendors lie about this. It is that both sides assume the other owns the control, and the questionnaire has one column. Answering "yes" for a property your model provider actually delivers is how a vendor ends up asserting something it cannot evidence; answering "not applicable" for the same property is how a buyer ends up with a gap nobody owns.

The fix is unglamorous and it works: answer in three registers, and say which one you are in. We control this — here is our evidence. We inherit this — here is the named upstream provider, the document we rely on, and how we verify it still holds. Nobody controls this in your deployment — here is what that means for you. A pre-answered pack built this way survives a reviewer who reads properly. One built on a single yes/no column does not.

This is also where the AI Act's Article 25 trap sits. Put your name on someone else's model, or change its intended purpose, and you stop being a deployer and become a provider — inheriting the whole obligation set. We wrote that up in Article 26 read as an engineering backlog. In questionnaire terms: the role you claim in your answers has to be the role you actually occupy, because both the regulation and a competent assessor will check.

The ten questions a generic answer library cannot answer

These recur across SIG 2026, the AI-CAIQ and the bespoke questionnaires large buyers write themselves. None of them has an answer in a SOC 2 report.

1. Is customer data used to train, fine-tune or improve any model? Including via the upstream provider's default terms, which are not your terms.
2. What is retained from a prompt and a response, where, and for how long? Inference logs are the most commonly forgotten personal-data store in an AI stack.
3. Which model and which version? Pinned, or floating? What notice does a version change carry, and can the customer refuse it?
4. Who are the subprocessors, including inference providers? An AI subprocessor list that omits the model API is incomplete, and it is the entry a DPO reads first.
5. Where does inference physically happen? Data residency answers usually describe storage. The question is about compute — and the two are frequently in different jurisdictions. We laid out the options in the EU sovereign AI stack and what the isolated end costs in air-gapped is an operating commitment.
6. What evaluation and adversarial testing was performed, and can you show the results? Not "we test" — the set, the date, the failures found.
7. How does human oversight actually work? Who can stop the system, with what authority, and is there evidence they ever have?
8. What is logged, and for how long? Article 26(6) sets a six-month floor for deployers of high-risk systems; whether your logging supports that is a property of the vendor's product, not of the deployer's goodwill.
9. What counts as an incident when the failure is a model behaviour? A wrong-but-confident answer trips no monitor. If your incident definition only covers availability and breach, this category has no path to a report.
10. On exit, what comes back? Documents are the easy part. Embeddings, the index, the evaluation set, and the conversation history are the parts that quietly stay behind.

If you are buying, these ten are a better use of an hour than a 300-row spreadsheet. If you are selling, they are the pack.

A pre-answered pack is a set of claims — and claims go stale

The case for pre-answering is straightforward: standardise on one maintained answer set, publish what can be published, and every questionnaire after the first is a diff rather than a rewrite. Buyers get answers before they ask, and the review starts from a narrower surface.

The risk is the same one we described in citations that can be wrong. A pre-answered pack is a body of assertions with a citation-shaped confidence to it, and almost nothing in the ordinary workflow re-checks whether each one is still true. Answers written when inference ran in one region and copied forward after it moved are not a documentation problem; they are a misrepresentation with your signature on it.

Four rules keep a pack honest, and they cost very little:

• Every answer carries an owner and a date. An answer nobody owns is an answer nobody will correct.
• Every answer names its evidence — the document, the configuration, the test — rather than restating the claim in different words.
• Anything architectural is re-verified on a release cadence, not on a questionnaire cadence. Residency, subprocessors, retention and model pinning are the four that move without anyone deciding to move them.
• "We do not do this yet" is a valid, and often winning, answer. Buyers discount vendors who answer everything affirmatively, because experienced reviewers know the distribution.

On tooling: dedicated questionnaire platforms and hosted trust centres pay for themselves somewhere around twenty to thirty inbound questionnaires a quarter. Below that, the honest answer is a maintained document, a public security page and a named owner — and the discipline above matters far more than the software.

Where we stand

We do not hold SOC 2, ISO 27001 or ISO/IEC 42001, we are not listed on the STAR Registry, and we say so in the first paragraph of any questionnaire we answer rather than in a footnote. What we maintain is the control-to-evidence mapping behind those frameworks, the three-register split above for anything we inherit from an upstream provider, and a deployment posture — single-tenant, EU-resident or air-gapped, with a per-tenant append-only audit trail — that makes several of the ten questions answerable by pointing at the architecture instead of at a policy.

That posture is written out on our security and compliance pages, including the parts where the answer is "not yet". If a questionnaire has stalled on a question you cannot answer for a system you did not build, that is a short conversation to start.