If your museum, gallery, archive, or heritage site is evaluating AI tools, you’ll find there’s a growing landscape of vendors offering solutions for everything from chatbots to collection search, interpretation, accessibility, and visitor analytics. It’s on you to do your own due diligence here. The EU AI Act rolls out strict transparency rules for public-facing AI in August 2026.
This piece picks up where my lunch break guide left off. If you’re already working through your Deployer obligations, your next hurdle is AI vendor selection, starting with what they aren’t telling you about security and data protection.
If you’ve got a call with a vendor this afternoon, feel free to scroll to my section on ‘The questions to ask your vendor’. I won’t be offended.
Let’s start with security standards
ISO 27001 is an information security management standard. To achieve it, the vendor submits to an independent third-party audit of their security controls, including risk management, access controls, incident response, physical security, encryption at rest and in transit. The audit is repeated annually. Let it lapse, lose it. ISO 27001 is preferable for EU institutions because it clicks with GDPR Article 32’s requirement for “appropriate technical and organisational measures.”
When a vendor tells you they’re ISO 27001 certified, ask for the certificate. Check that it’s in date, and that the product you’re buying is included in scope (a vendor can be certified for one product line and not another).
ISO 27001 is not a privacy standard. The certificate just tells you their house has locks on the doors, not what they’re doing in there. To find that out, you have to ask; later, I’ll share some specific questions you can use.
If your vendor will be handling collections records or donor data, absence of a certificate is a red flag. An ISO 27001 certified vendor can have excellent encryption and still have terrible data minimisation, opaque AI training policies, or unclear retention.
SOC 2 Type II is the rough equivalent to ISO 27001 for North American institutions. (There’s also a Type I, but that’s a point-in-time snapshot rather than a sustained commitment, and it’s materially weaker.)
Whichever certification your vendor claims, require them to maintain it for the duration of the agreement, and to notify you promptly if it lapses, is suspended, or changes in scope.
Then there’s data protection
When a vendor says “we’re GDPR compliant,” they’re basically telling you: we have a privacy policy, we’ve done some internal review, we have a Data Processing Agreement template ready for you to sign, and we believe we’re operating within the regulation.
There’s no third party assessing GDPR compliance and giving vendors a certificate. It’s just “we think we did this right and we hope that’s true if the regulators ever come knocking.”
The other thing is, a vendor can have an impeccable privacy policy and still route your data through five sub-processors in three jurisdictions you’ve never heard of. That’s the fundamental problem with GDPR — it doesn’t require independent verification of data architecture. Vendors aren’t trying to be sketchy; it’s just that a small company building on top of OpenAI’s API doesn’t get to choose which data centres OpenAI uses. They inherit OpenAI’s sub-processor chain, and they themselves may not have the full picture. Most SME SaaS vendors have never been audited and never will be, and they rely on that. The question is whether you should. There is an upgrade to ISO 27001 that deals with privacy (ISO 27701), but it’s exceptionally rare among smaller AI vendors.
If you’re an EU institution contracting with a US-based vendor, transferring personal data to them requires a legal mechanism under GDPR Chapter V: either the EU-US Data Privacy Framework (DPF) or Standard Contractual Clauses (SCCs). Both are on thin ice. The DPF was built on the assumption that the US maintains independent oversight of its surveillance practices.
In January 2025, the Trump administration fired all the Democrat members of the independent oversight board. Norway, Germany, and Denmark have since advised European businesses to develop exit strategies.
If you fall back on SCCs, your legal team must execute a Transfer Impact Assessment (TIA) to prove US law doesn’t undermine your data protections. Right now, making that case is nearly impossible. Do not sign a US vendor contract involving personal data without your solicitor in the room.
The situation for institutions in North America
In the US: there’s no federal privacy law. What you have is a patchwork: nineteen states with privacy laws of wildly inconsistent scope, plus sector-specific federal laws like HIPAA and FERPA that mostly don’t touch museum operations. There is no federal regulator creating pressure on your AI vendors. I suggest you align your procurement standards to GDPR, and hold vendors accountable yourself. It’s all on you.
In Canada: still operating under a privacy law written for the year 2000. Replacement legislation has stalled twice. The Liberal government has signalled new federal privacy legislation is coming with potential fines up to C$25 million or 5% of global revenue. As of mid-2026, it has not been introduced.
The one real anchor in Canada is Quebec. Law 25 requires opt-in consent for sensitive data and Privacy Impact Assessments before deploying technology that touches personal information. If you’re a Quebec institution, that’s your GDPR. If you’re elsewhere in Canada, the more sophisticated institutions are aligning with Law 25 and GDPR voluntarily.
Your AI vendor might be ChatGPT in a trench coat
A significant portion of the AI products being pitched to museums right now are not purpose-built AI, they’re thin wrappers around OpenAI, Anthropic, or Google APIs. The vendor’s product is the user interface, the system prompt, and the integration layer.
What should concern you here:
Your vendor’s certification doesn’t cover the model. An ISO 27001 certificate covers the vendor’s infrastructure (their servers, access controls, incident response) but not OpenAI’s data handling. Your DPA is with the vendor, but the vendor’s DPA is with OpenAI and you may not like what’s in it.
Your data sovereignty commitments may be at risk. When your curators’ notes, conservation reports, object metadata, and donor records pass through an OpenAI API call, they’re processed on US servers under US jurisdiction. Whether this is legally sound depends on the faltering DPF. For Canadian institutions, this data sovereignty question is exactly why you need the new federal law.
For institutions holding indigenous collections, repatriation-sensitive documentation, sacred objects documentation, or cultural patrimony, you’re dealing with a trust obligation to source communities.
You’ve spent real time and effort adopting the CARE Principles, implementing Local Contexts labels, and developing community protocols for collections data, but when this data passes through a commercial LLM API, all those commitments could be undone.
If you discover your vendor is running on a third-party API and you have indigenous data sovereignty obligations, you have options before walking away:
- Go back to the community first. Some communities will draw a hard line; others may have no objection for certain uses. You need to know what you agreed to before you can evaluate any technical fix.
- Ask if the vendor can run on a different model. Some vendors can switch to EU-based providers like Mistral. If jurisdiction is the core concern, this may resolve it.
- Exclude the sensitive data entirely. Use the tool for general collections and contractually require the vendor to enforce the exclusion. This only works if your collections data is tagged well enough to make the exclusion enforceable.
The questions to ask your vendor
Before getting to the museum-specific questions, make sure you’ve covered the general bases. ThinkTech’s AI Procurement Checklist is a useful starting point for general procurement. The questions below are designed to go beyond the basics and see if you’re talking to a vendor who understands the unique needs of our industry.
- Is your product built on a third-party foundation model API? If so, which provider, which model, and can you provide the sub-processing agreement?
- Have you worked with museums, galleries, archives, or other cultural institutions before? What did you have to do differently to meet their requirements?
- Our collections include works subject to restricted access, contested provenance, and repatriation obligations. How does your product handle data that can’t be treated as standard content?
- A significant portion of our funding carries donor conditions and grant restrictions on how data can be used and where it can be stored. Have you worked with institutions under those kinds of constraints, and what does your contract structure accommodate?
- Our institution holds data on behalf of communities like indigenous groups, not just visitors and staff. How does your product’s data governance account for data that isn’t fully ours to decide about?
- Does your training opt-out cover data generated through the tool on behalf of third-party communities and source groups, not just our own institutional data — and can you confirm that in writing?
- If a visitor made a subject access request, or a funder asked us to demonstrate how their grant-funded data had been handled, what could you produce to support that, and how quickly? (You’re listening for specific outputs like logs, audit trails, and data exports, with specific timeframes.)
- Museums operate in a high-scrutiny public environment. If a journalist or activist raised a complaint about how visitor or community data had been handled, what would your incident response look like, and have you been through that with another client? (“We’d cross that bridge when we come to it” tells you they haven’t thought about it.)
Look, if your vendor stumbles a bit with these questions, it’s not automatically disqualifying. What you’re listening for is whether you get a sincere “I’ll look into that and come back to you” or just a pivot back to the standard pitch.
Vendor green flags
Signs you’re dealing with a trustworthy AI vendor:
- They offer their DPA proactively without waiting to be asked.
- They name their sub-processors readily, and their foundation model provider.
- They have a clear, written training opt-out that’s the default, not an upsell.
- They’ll participate in a DPIA with you, and have ideally done one before.
- They have a documented option for EU-based inference if you need it.
- They can distinguish between their security posture and their data protection posture without conflating them.
- They don’t oversell. A vendor saying “we are fully GDPR compliant and there are no risks” is either lying or doesn’t understand the question.
One internal process note. The default pattern in cultural institutions is that Curatorial or Interpretation finds a tool, falls in love with it in a demo, brings it to Digital, who then brings it to legal…by which point internal stakeholders are invested and saying no will ruffle feathers. Technology procurement decisions for AI tools should involve your Data Protection Officer or legal advisor before the demo stage.
Cultural institutions sometimes feel like they’re being difficult by asking hard questions of their vendors, but you shouldn’t feel like the supplicant in your vendor relationships. The consequences of being an AI Deployer get real for you in August 2026. Grill them.
Ready to sign? My follow-up, Three contract fights your AI vendor hopes you won’t pick, covers what to put in the contract.
