Data Security in Voice AI: No recording storage, no location tracking, four-eye approval

When a voice assistant hears every question you ask, security isn’t a feature — it’s a design principle.

---

Introduction

Voice assistants face a unique security challenge: the device is always listening, recording your questions — including sensitive ones like “is there a clinic nearby,” “when do I take this medication,” or “what’s my bank account balance.”

Popular assistants like Alexa and Google Home store recordings in the cloud, analyze them to improve their services, and sometimes hand them over to third parties when legally compelled. Travelers have no idea where their data ends up. Elderly users may not understand the technology well enough to protect themselves.

Vivi Voice AI is built on “privacy by design” principles: no audio recordings stored, no location history retained, four-eye approval for all content, and tamper-proof audit logs. This article explains in detail how Vivi protects user data.

---

1. No recording storage, no location history

The principle

When you speak to Vivi — whether through the app, kiosk, or ESP32 — audio is transmitted to the server over a secure WebSocket channel, converted to text, processed by the AI, and the response is sent back to the device. After the conversation session ends:

• The original audio recording is deleted — not stored on the server, not stored on the device
• Location history is not recorded — Vivi knows you’re asking about “nearby temples” but doesn’t store your GPS coordinates
• Conversation content is not linked to identity — the traveler app works anonymously, no registration required

Compared with Alexa and Google Home

Criteria	Alexa / Google Home	Vivi Voice AI
Stores recordings	✅ Yes, in the cloud	❌ No
Analyzes recordings to improve AI	✅ Yes (opt-out)	❌ No
Stores location history	✅ Yes	❌ No
Requires account registration	✅ Yes	❌ No (traveler app)
Links conversations to identity	✅ Yes	❌ No (anonymous)

---

2. Four-eye approval — creators cannot approve their own work

The principle

Every piece of content shown to users — locations, ticket prices, opening hours, translations, AI scripts — must go through an approval step. And the person who created the content cannot approve their own work.

This isn’t “hiding the approve button in the UI” — the rule is enforced at the database layer. Even if you have admin privileges, you cannot bypass it.

Why it matters

• Prevents single-person errors: an editor might enter the wrong ticket price, but if a second person must confirm, the mistake gets caught
• Prevents bias: a translator might misread context; a reviewer who speaks the language checks the work
• Accountability: every change has both a creator and a reviewer — nobody can make unilateral changes

The CMS approval workflow

1. Editor creates or edits content (location, ticket price, translation)
2. Content enters the approval queue
3. A reviewer (different from the creator) checks it against the source, then approves or rejects
4. Only approved content is pushed to the app, kiosk, or ESP32

Machine translations never go live automatically: a speaker of that language must approve them. This is why Vivi supports 5 languages while maintaining translation quality.

---

3. Tamper-proof audit logs with hash chains

The principle

Every change in the CMS — create, edit, approve, delete — is recorded in an audit log. This log is:

• Append-only: old entries cannot be modified or deleted
• Hash-chained: each entry contains the hash of the previous entry; if someone tampers with an old entry, the hash won’t match and the entire chain is flagged as compromised
• Retained for 5 years: meets legal requirements for data retention

Compared with conventional systems

Criteria	Conventional systems	Vivi Voice AI
Audit log	✅ Yes	✅ Yes
Append-only	❌ Admins can edit	✅ Enforced at DB layer
Hash chain	❌ No	✅ Yes
Retention period	1–2 years	5 years

---

4. Role-based access control

CMS roles

• Admin: manages users, system configuration
• Operations: manages devices, notification campaigns
• Editor: creates and edits content
• Reviewer: approves content created by editors

Each role can only see and do what’s permitted. Editors can’t approve. Reviewers can’t create. Admins can’t bypass the four-eye approval rule.

Data isolation by deployment customer

If you’re Hotel A deploying Vivi, you only see Hotel A’s data. You can’t see Hotel B’s data. This is the data isolation principle — ensuring each deployment customer cannot access another’s data.

---

5. IoT device security

HMAC authentication

Each ESP32 device is issued a secret key when registered in the CMS. When connecting, the device signs its request with HMAC (Hash-based Message Authentication Code). The server verifies the signature before accepting the connection.

If a device is lost or tampered with, the CMS can revoke its key immediately.

Secure WebSocket channel

After authentication, the device opens a secure WebSocket channel for audio transmission. Audio is compressed with Opus — a high-quality, low-bandwidth codec. Data in transit cannot be read by anyone intercepting packets.

USB firmware loading from CMS

When firmware needs updating, a technician plugs a USB cable into the ESP32 device, opens the CMS in a browser, and loads the new firmware. WiFi settings and device keys are preserved — no reconfiguration needed.

In development: over-the-air (OTA) firmware updates.

---

6. Protecting vulnerable users in Companion

The principle

The Companion module for elderly care follows the same principles:

• No real names stored for the person being cared for — only nicknames
• No photos stored — avoids leaking images of elderly people
• Data visible only to designated family members — not shared with third parties

Compared with other care apps

Many elderly care apps require real names, photos, dates of birth, addresses, and medical history. If this data leaks, it’s extremely dangerous because elderly people are prime targets for fraud.

Vivi takes the opposite approach: collect only what’s needed to perform the function (reminders, conversation, alerts), and encode identity with nicknames.

---

7. Kiosk safety in public spaces

No web browser

The Vivi kiosk doesn’t run a full web browser. When it needs to display an official link or directions, it shows a QR code — guests scan it and open the link on their own phone.

Reason: a web browser on a public kiosk risks malicious code injection, keyloggers, or exploitation to access the internal network.

No payment processing

The kiosk doesn’t handle payments. If you need to buy a ticket, the kiosk directs you to the official website via QR code.

Reason: payment processing requires PCI-DSS compliance, and if compromised, guests’ credit card data could be stolen.

Emergency guidance is a fixed script

In emergency situations (fire, earthquake), the kiosk plays a pre-approved fixed message — never AI-generated.

Reason: AI can “hallucinate” — produce incorrect information in emergency situations. Fixed scripts are reviewed and verified for accuracy.

---

8. Summary: Privacy by design

Principle	How Vivi implements it
No recording storage	Audio deleted after conversation ends
No location storage	GPS coordinates not recorded
Anonymous use	Traveler app requires no registration
Four-eye approval	Creators can’t self-approve, enforced at DB layer
Tamper-proof logs	Hash chain, append-only, retained 5 years
Role-based access	RBAC, data isolation by deployment customer
Device security	HMAC, WebSocket, remote key revocation
Elderly protection	Nicknames only, no photos, visible to family only
Kiosk safety	No browser, no payments, fixed emergency scripts

Vivi Voice AI isn’t perfect — no system is. But we designed it from day one with the assumption that any sensitive data could be targeted, and the best defense is to not store what you don’t need to store.

---