A visitor walks up to a painting, pulls out their phone, and asks your AI audio guide: "My daughter has autism — can you explain this painting in a simple way?" That question contains sensitive personal information. What happens to it?
If you don't know the answer for your institution, that's a problem. Not a theoretical one. Under GDPR, you're the data controller. The audio guide vendor is your processor. If visitor data is mishandled, the museum is on the hook — not the technology company.
Most museum professionals we talk to understand GDPR in the context of mailing lists and ticketing systems. The rules haven't changed. But AI-powered audio guides create a new category of data — conversational data from real-time visitor interactions — that doesn't fit neatly into existing privacy frameworks. It's not a cookie. It's not a form submission. It's a person talking to a machine about things they care about, sometimes revealing more than they intend to.
This article isn't legal advice. It's a practical guide for museum professionals who need to understand what privacy compliance actually looks like when your audio guide listens back.
What data are we actually talking about?
Traditional hardware audio guides (the devices visitors check out at the desk) collect almost no data. Maybe a device number and the time it was checked out. Privacy exposure is minimal because the technology is minimal.
BYOD solutions collect more. At minimum, you're tracking which content gets accessed, session duration, and device information. Some platforms require account creation, which immediately puts you in personal data territory: names, emails, potentially payment information.
AI-powered conversational guides generate a third category. Everything a visitor says or types becomes data. Questions about exhibits. Personal anecdotes shared mid-conversation. Health conditions mentioned when asking for accessibility help. Names of travel companions. Languages that reveal national origin.
This conversational data is where privacy gets hard. It's unstructured, it's personal in unpredictable ways, and it's generated in volume. A busy museum might produce thousands of visitor conversations per week. Somewhere in that stream, people are sharing things that qualify as personal data, or even special category data under GDPR, without thinking about it.
The question isn't whether conversational data contains personal information. It does. The question is what your system does about it.
The data minimization principle
GDPR's data minimization requirement says you should collect only what's necessary for the stated purpose. This sounds simple. In practice, it creates a real tension for museums.
You want rich analytics. You want to know what visitors ask about, where they lose interest, which exhibits generate the most curiosity. This data is valuable for exhibition planning, content improvement, and operational decisions. But the richer the data, the more privacy exposure you carry.
The wrong approach is to record everything and figure out privacy later. Some audio guide systems store full conversation transcripts indefinitely, attached to device identifiers or user accounts. That's a liability sitting in a database, waiting for either a data breach or a subject access request to make your life complicated.
The right approach is to separate the signal from the identity. You can know that 400 visitors asked about Impressionist techniques this month without knowing which visitors asked. You can track engagement patterns across languages without linking those patterns to individuals. The analytics stay useful. The privacy risk drops dramatically.
This is an area where we've put significant engineering effort at Musa. Conversational data goes through automatic PII redaction. Names, emails, phone numbers, and other identifiable information get stripped before anything reaches the analytics layer. The raw conversational data isn't stored indefinitely. After defined retention periods, it's deleted. What remains is aggregate, anonymized insight about what visitors care about.
That goes beyond a GDPR checkbox. It's a design philosophy: collect what's useful, discard what's dangerous, and make the default setting the safe one.
The account problem
Most museums don't think of this as a privacy decision, but it is: does your audio guide require visitors to create an account?
If yes, you've just created a personal data record for every user. Name, email, possibly payment details. You need consent mechanisms, you need to handle subject access requests, you need deletion workflows, and you need to secure that database forever or until you delete it. Every account is a GDPR obligation.
If visitors can simply scan a QR code and start using the guide, your privacy exposure shrinks dramatically. No account means no personal data record. The visitor has a session, interacts with the guide, and leaves. Their session data exists temporarily, gets processed for analytics, and the identifying elements get cleaned out.
It's also a usability win. We've seen the difference firsthand: when you remove the "create an account" step, adoption goes up because there's less friction. Visitors don't want to hand over their email to listen to a painting description. They just want to use the thing.
Musa doesn't require account creation. Visitors get their own sessions with full functionality: personalized tour progress, conversation history during the visit, the ability to pick up where they left off. All of that works without knowing who the visitor is. Privacy and user experience pointing in the same direction, for once.
AI-specific privacy concerns
Standard audio guides raise standard privacy questions. AI-powered guides raise new ones.
Conversational data processing. When a visitor asks a question, that text gets sent to a language model for processing. Where does that processing happen? Which model provider handles it? Is the data transmitted across borders? These are questions your data processing agreement needs to answer, and "we use OpenAI" is not a sufficient answer. You need specifics about data routing, processing jurisdiction, and sub-processor agreements.
Model training. This one matters more than most museums realize. If your vendor's AI provider uses visitor conversations to improve its models, your visitors' words are being fed into a training pipeline they never consented to. Under GDPR, this would require explicit consent. And practically, it's impossible to obtain meaningful consent for something most visitors don't understand.
Reputable providers contractually prohibit their AI sub-processors from using input data for training. This should be explicit in your data processing agreement. If a vendor can't confirm this in writing, that's a red flag.
Cross-border transfers. Many AI models run on infrastructure in the United States. Under GDPR, transferring European visitor data to US servers requires specific legal mechanisms — Standard Contractual Clauses, adequacy decisions, or equivalent safeguards. Well-trodden compliance territory, but it needs to be addressed specifically for the AI processing component, not just the main application hosting.
Data retention for AI logs. AI systems often maintain logs for debugging, quality assurance, and safety monitoring. How long are these logs kept? What do they contain? Can they be linked back to individual visitors? These are operational details that have real privacy implications.
Safety, hallucinations, and the privacy connection
Museums often group safety and privacy into the same bucket. They're related but distinct.
Hallucination (the AI saying something factually wrong about your collection) is a content accuracy problem, not a privacy problem. But the systems that prevent hallucination share infrastructure with the systems that protect privacy. Both require careful orchestration of what the AI can access and what it does with inputs.
On the safety side: a well-built AI guide has multiple layers of protection. Content grounding keeps responses tied to museum-provided data. Behavioral guardrails prevent the AI from going off-script in ways that could be harmful. At Musa, our hallucination prevention rate sits at roughly 99.99% across production traffic. The remaining edge cases come almost exclusively from adversarial prompting — visitors deliberately trying to break the system, which violates terms of service, and for which we maintain logs as evidence.
The privacy relevance is this: the same architectural rigor that prevents hallucination also prevents data leakage. A system that can't be tricked into making up facts about your paintings is also harder to trick into revealing data from other visitors' sessions. Defense in depth applies to both problems.
Cookie consent and the simpler stuff
Not everything about audio guide privacy is novel. Some of it is the same compliance work you do for your website.
If your audio guide runs in a browser (which most modern BYOD solutions do), standard cookie consent rules apply. Analytics cookies, session cookies, any third-party tracking: all need appropriate consent mechanisms. This isn't different from your museum website; it just needs to be applied to the audio guide interface too.
Privacy policies need to cover the audio guide specifically. Your existing museum privacy policy probably doesn't mention conversational AI data processing. It should. Visitors should be able to understand, in plain language, what data the audio guide collects, why, and for how long.
Consent for the audio guide itself is worth thinking about carefully. Starting to use the guide is arguably an affirmative action: you scan the code, you start talking. But GDPR requires that consent be informed. A brief, clear privacy notice when the visitor first opens the guide (not a wall of legal text) works both as a compliance measure and a trust signal.
What to ask your audio guide vendor
If you're evaluating audio guide platforms and privacy matters to you (it should, both ethically and because the fines are real), here's a practical checklist.
- Account requirements. Does the system require visitors to create accounts? If so, why? What personal data is collected and how long is it retained?
- Conversational data handling. How is PII in visitor conversations identified and redacted? What's the retention period for raw conversational data? What form does it take after retention expires?
- AI model training. Is visitor data used to train or fine-tune AI models, either by the vendor or their sub-processors? Get this in writing.
- Data processing location. Where is data stored? Where is it processed? If AI inference happens in a different jurisdiction from data storage, document both.
- Sub-processors. Who else touches the data? AI providers, analytics platforms, hosting services — you need a complete sub-processor list, and your DPA should require notification when it changes.
- Subject access and deletion. If a visitor requests their data or asks for deletion, what's the process? How quickly can it be completed? Systems that don't collect much personal data in the first place make this dramatically simpler.
- Breach notification. What's the vendor's process for notifying you of a data breach? GDPR gives you 72 hours to notify your supervisory authority — your vendor needs to give you enough lead time to meet that deadline.
- Safety logs. What logging exists for safety and quality monitoring? Who can access it? How long is it retained?
The trade-off that isn't
The conventional framing is that privacy and analytics are in tension. You can have rich visitor data or you can have privacy compliance. Pick one.
That framing is wrong, or at least outdated. The most useful analytics for museums are aggregate patterns, not individual profiles. You don't need to know that visitor #4,721 asked about Monet's garden. You need to know that 300 visitors this month asked about Impressionist garden scenes, which tells you something about audience interest that could inform your next exhibition.
Automatic PII redaction, session-based (not account-based) architecture, defined retention periods, and aggregate analytics. These aren't privacy restrictions that limit your data. They're design choices that focus your data on what's actually useful while keeping you on the right side of regulations that carry fines up to 4% of annual turnover.
We built Musa around this principle because it's what we'd want as a museum. Useful data without the liability. Visitor trust without sacrificing insight.
If you're sorting through the privacy implications of a new audio guide system, or wondering whether your current one is handling this well, we can walk through how we approach it.