# Tutorial — Privacy and Logging *Augmented Traveler local tutorial.* Back to [[AI Mind — Tutorials]] · who reads the logs: [[Tutorial — Staff Dashboard]] · vendor choice: [[Tutorial — Choosing Cloud or Local Models]] · ethics: [[Ground Rules — Historical Virtual Humans]] What the conversation service **logs**, what it **never logs**, how long we keep it, what visitors are told, and how children, schools, Massachusetts rules and cloud vendors change the picture. The Ground Rules say "log every question" and "questions, not faces". This page turns that into practice. > **Not legal advice — confirm with counsel.** Written from the laws, regulations and vendor pages listed under Sources, read on 20 September 2026. Counsel and each venue must confirm before opening. The DevOps engineer and AI conversation engineer implement it. ## 1. What we log One row per turn ([[Tutorial — Staff Dashboard]] section 5): | Field | Why | |---|---| | Question text, **after redaction** (section 3) | Review; golden set; corrections | | Answer ID, authored-or-generated flag, answer text | Know what the figure said | | Corpus hits (citation IDs), retrieval scores | Check answers against sources | | Refusal flags and the rule that fired | Hard-question protocol review | | Timings (ASR, retrieval, first token, first audio) | Latency | | Venue ID, figure ID, kiosk ID | Per-venue review | | **Anonymous session ID** (random per visit; reset when the visitor leaves or after idle) | Group follow-up questions | | Corpus, model, voice and lexicon versions | Trace a wrong answer to its cause | ## 2. What we never log - **Audio.** Held in memory for the turn, then discarded. Never written to disk, never sent to a vendor that stores it (section 6). - **Faces or camera images.** The kiosk has no camera for the conversation. If a venue adds one for presence detection, it must not store images. - **Voiceprints** or any speaker identification. We don't identify who is speaking. - **Names, phone numbers, emails, addresses, school names** a visitor volunteers. Redacted before storage. - **IP addresses or device IDs** of visitors' phones beyond what the web server needs to work; not joined to question logs. ## 3. Redaction Visitors, especially children, say things like "My name is Emma and I go to Harbour Street School, room 4" (a made-up example). 1. **Redact before the log write,** in the service, not later in the dashboard. 2. Replace with tags: `[NAME]`, `[PHONE]`, `[EMAIL]`, `[SCHOOL]`, `[ADDRESS]`. 3. Use a named-entity step plus patterns for phone and email. **Keep historical names** (Maria Mitchell, Absalom Boston) using an allow-list from the corpus. 4. The model still sees the unredacted question for that turn only, so the figure can respond politely; it never repeats a visitor's name back ([[Tutorial — Policy Layer with Guardrails]]). 5. Test redaction with the QA tester's list of 100 tricky questions. ## 4. Retention (proposal for counsel) | Data | Keep | Then | |---|---|---| | Audio | 0 (memory only) | — | | Turn logs (redacted) | 13 months: covers a full season and year-on-year review | Delete, keeping only counts per question cluster | | Golden-set candidates copied from logs | Until the figure is retired | Review yearly | | Dashboard audit log | 3 years | Delete | | Test recordings with consent ([[Tutorial — Speech In]] section 8) | End of the project, or as the consent form says | Delete | - **Write the retention periods into the privacy notice** as specific periods. The amended COPPA Rule requires a written retention policy with specific timeframes and bans indefinite retention for children's data. - **Automate deletion** (nightly job) and log that it ran. ## 5. Notices at the kiosk and online **At the kiosk** (short, large type, beside the push-to-talk button): > You are talking to an AI interpretation of Maria Mitchell, voiced by [actor]. It can be wrong. Your words are turned into text to answer you. We keep the text of questions, without your voice or face, to improve the exhibit. Please don't share personal details. More: [QR code] - Also say it's an **interpretation** with a cutoff year ([[Ground Rules — Historical Virtual Humans]]); Anthropic's and OpenAI's minors guidance also expect a clear AI disclosure. - **Massachusetts:** the wiretap statute targets *secret* recording of conversations. A clear notice, plus push-to-talk, keeps capture open and visible. We also don't keep audio. Counsel confirms. - **The QR page** holds the full notice: what we collect, why, retention periods, vendors, contact. ## 6. Children - **COPPA** (under 13): the amended rule (compliance date 22 April 2026) adds **biometric identifiers, including voiceprints,** to personal information, and codifies an **audio file exception**: a child's voice may be collected without parental consent only to respond to the child's request and must be **deleted immediately** after. The FTC's earlier policy excluded cases where the operator asks for personal information such as a name. - **Our design fits that pattern:** push-to-talk, no audio kept, no questions asking for names, redaction of anything volunteered. Whether COPPA applies to a museum kiosk at all is a question for counsel. - **Vendors and children:** - OpenAI: personal data of under-13s only with zero data retention in place. - Anthropic: allowed with safeguards, COPPA compliance stated publicly, AI disclosure. - Google Gemini Developer API terms forbid services likely to be accessed by under-18s. - **Companionship ban** and no secret-keeping with children are enforced in the policy layer. ## 7. Schools - **FERPA** applies to education records. We don't receive student records; visitors are anonymous. If a school ever sends us student data (a class list for a booking), it falls under the "school official" exception conditions: direct control by the school, use only for the authorised purpose, no re-disclosure. - **Massachusetts districts** commonly require vendors to sign a data privacy agreement through the **Massachusetts Student Privacy Alliance** (covering FERPA, COPPA and more, district ownership of data, breach notice, audit rights). Expect to sign one for school use. - **School visits run local-only** if the founders accept that suggestion ([[Tutorial — Choosing Cloud or Local Models]]). ## 8. Massachusetts data security and other state law - **201 CMR 17.00** protects "personal information", defined as a Massachusetts resident's name combined with a Social Security number, driver's licence or ID number, or financial account or card number. **Our logs should hold none of these.** If we ever take bookings or payments, a written information security programme (WISP) is required; plan one anyway for staff and contractor data. - **Massachusetts Consumer Data Privacy Act:** passed the House 146–0 on 4 June 2026 and went back to the Senate (status after that unconfirmed; check). It would treat minors' data and biometric data as sensitive. - **Biometrics:** Massachusetts has no Illinois-style biometric law in force that we found. Illinois BIPA covers voiceprints and face geometry. We avoid the issue by never making voiceprints or face templates. Relevant for touring venues outside Massachusetts. ## 9. Vendor data processing | Vendor type | What leaves the site | Setting to require | |---|---|---| | Cloud ASR (Deepgram) | Audio | `mip_opt_out=true` on every request (Deepgram otherwise may keep data for model improvement) | | Cloud ASR (AssemblyAI) | Audio | Opt out of model training; streaming then has zero retention of audio and transcripts per its FAQ | | TTS (ElevenLabs) | Answer text | Zero Retention Mode, `enable_logging=false` (enterprise only) | | LLM (Anthropic, OpenAI) | Question and passages | Signed ZDR; see [[Tutorial — Choosing Cloud or Local Models]] section 3 | | Local only | Nothing | — | - **Sign a data processing agreement** with each vendor. - **List every vendor** on the QR notice page. ## 10. Access control and security - Named accounts, multi-factor sign-in, least access ([[Tutorial — Staff Dashboard]] section 3). - Logs encrypted at rest and in transit; API keys in the kiosk's secure config, never in content or logs ([[Tutorial — Conversation Client Plugin]]). - Kiosk PCs: no local log copies beyond a short outbound queue for offline venues, deleted after sync. ## 11. Incident response 1. **Detect:** unexpected data in logs (unredacted name, audio file found), lost device, vendor breach notice. 2. **Contain within 24 hours:** stop the leak, remove the data, rotate keys. 3. **Assess** with counsel: what data, whose, which laws (Massachusetts breach notice under chapter 93H if personal information is involved). 4. **Notify** the venue, and schools under their agreements, within the agreed times. 5. **Fix and record:** root cause, the change, a new test so it can't happen again. ## 12. Practice exercise Write five questions a child might ask that contain personal details. Run them through the redaction step and check the log rows. Then read the kiosk notice aloud to someone outside the project and ask them what we keep. Fix the notice if they get it wrong. ## 13. Check before opening - [ ] No audio on disk anywhere (search kiosk and server temp folders) - [ ] Redaction tested with 100 tricky questions - [ ] Retention periods set, automated and written in the notice - [ ] Kiosk notice and QR page up; counsel sign-off - [ ] Vendor ZDR / opt-out settings confirmed in contracts and in code - [ ] School data privacy agreement signed where needed - [ ] Incident contacts listed; drill done once ## Sources - FTC, COPPA Rule final amendments (Federal Register, 22 April 2025): https://www.federalregister.gov/documents/2025/04/22/2025-05904/childrens-online-privacy-protection-rule - Gibson Dunn, FTC updates to the COPPA Rule: https://www.gibsondunn.com/ftc-updates-to-coppa-rule-impose-new-compliance-obligations-for-online-services-that-collect-data-from-children/ - Fenwick, What the amended COPPA Rule means for data retention: https://www.fenwick.com/insights/publications/what-the-amended-coppa-rule-means-for-data-retention-practices - Keller and Heckman, FTC guidance on voice recordings under COPPA: https://www.khlaw.com/insights/ftc-releases-guidance-voice-recordings-under-coppa - US Department of Education, Responsibilities of third-party service providers under FERPA: https://studentprivacy.ed.gov/sites/default/files/resource_document/file/Vendor%20FAQ.pdf - Dedham Public Schools, Student data privacy (MSPA): https://sites.google.com/dedham.k12.ma.us/dpset/student-data-privacy - Cornell LII, 201 CMR 17.02 definitions: https://www.law.cornell.edu/regulations/massachusetts/201-CMR-17-02 - Mass.gov, 201 CMR 17.00: https://www.mass.gov/regulations/201-CMR-1700-standards-for-the-protection-of-personal-information-of-residents-of-the-commonwealth - Massachusetts Legislature, Consumer Data Privacy Act (House, June 2026): https://malegislature.gov/PressRoom/Detail?pressReleaseId=1396 - Digital Media Law Project, Massachusetts recording law: https://www.dmlp.org/legal-guide/massachusetts-recording-law - Justia, Illinois BIPA 740 ILCS 14: https://law.justia.com/codes/illinois/chapter-740/act-740-ilcs-14/ - Deepgram, Model Improvement Partnership Program: https://developers.deepgram.com/docs/the-deepgram-model-improvement-partnership-program - AssemblyAI, Data retention and model training: https://assemblyai.com/docs/faq/does-assemblyai-offer-zero-data-retention - ElevenLabs, Zero Retention Mode: https://elevenlabs.io/docs/eleven-api/resources/zero-retention-mode - OpenAI, Under 18 API guidance: https://developers.openai.com/api/docs/guides/safety-checks/under-18-api-guidance - Anthropic Help Center, Guidelines for organizations serving minors: https://support.claude.com/en/articles/9307344-responsible-use-of-anthropic-s-models-guidelines-for-organizations-serving-minors - Google, Gemini API additional terms of service: https://ai.google.dev/gemini-api/terms - Full list: [[Sources — 2026-09-20]]