--- title: Data Privacy for an AI Travel Platform description: "How we handle sensitive traveler data — passports, payment methods, travel history — responsibly, from classification and encryption to right-to-deletion." canonical: https://nowah.xyz/blog/data-privacy-ai-travel-platform lastModified: "2026-08-07T03:51:51.888Z" --- # Data Privacy for an AI Travel Platform How we handle sensitive traveler data — passports, payment methods, travel history — responsibly, from classification and encryption to right-to-deletion. Your passport number. Your credit card. Every flight you've taken. Every hotel you've stayed in. The names and birthdates of your family members. Your dietary preferences for airline meals. Your seat preference. The conversation where you told the AI agent about your anniversary trip. A travel platform holds an unusually intimate picture of a person's life. We know where you go, when you go, who you travel with, and what you spend. This data is necessary to provide the service (we can't book a flight without your passport details), but it's also a profound responsibility. We take this seriously, not as a compliance checkbox, but as a core design principle. ## Data classification ![Illustration for this section](https://pics.nowah.xyz/website-media/infrastructure-061-img-1.webp) Not all data deserves the same protection. A traveler's preferred airline and their passport number are both personal data, but they carry vastly different risk if exposed. We classify data into three tiers. **Critical data** includes passport numbers, government ID details, payment card information, and authentication credentials. Exposure of critical data causes immediate, concrete harm: identity theft, financial fraud. Critical data gets the highest protection at every layer. **Personal data** includes names, email addresses, phone numbers, travel preferences, trip history, and conversation content. Exposure of personal data is a privacy violation and a trust breach, but the immediate harm is less direct. Personal data gets strong protection with appropriate access controls. **Operational data** includes aggregate metrics, anonymized usage patterns, system logs (with PII stripped), and reference data like airport codes and airline information. Operational data has minimal privacy implications and receives standard protection. The classification determines encryption requirements, access controls, retention periods, and deletion behavior. Every new field added to the database schema gets classified before it's stored. We don't retroactively classify. We classify at design time. ## Encryption at rest and in transit All data in transit is encrypted with TLS. Every API call, every webhook, every server-to-server communication uses encrypted connections. This is table stakes and has been for years. I mention it only for completeness. Encryption at rest is more nuanced. The database encrypts all stored data at the filesystem level. This protects against physical theft of storage media and certain classes of backup exposure. But filesystem-level encryption doesn't protect against application-level access. An application bug that leaks database contents leaks the data in cleartext. For critical data, we add application-level encryption. Passport numbers and similar identifiers are encrypted before they're written to the database and decrypted when they're read by authorized code paths. The encryption key is managed separately from the database credentials. Compromising the database doesn't expose the encrypted fields without also compromising the key. I'll be honest about a gap we're working to close. Some sensitive fields in our database aren't yet encrypted at the application level. This is a known issue from our security audit and is actively being addressed. We're transparent about it because pretending everything is perfect would be worse than acknowledging the work in progress. On the mobile client, sensitive profile data uses the device's secure storage (the keychain on iOS, the keystore on Android) rather than general-purpose local storage. The secure store provides hardware-backed encryption that survives even if the device is jailbroken. We use it for authentication tokens, cached profile data, and any locally-stored traveler identifiers. ## Retention and deletion policies ![Supporting diagram](https://pics.nowah.xyz/website-media/infrastructure-061-img-2.webp) Data should not live forever. Every data category has a retention period tied to its purpose. Active trip data is retained while the trip is active and for 12 months after completion. [Travelers need](/blog/data-driven-packing-travelers-need) to reference past trips, but indefinite retention serves no purpose. Conversation history is retained for the duration of the traveler's account. Conversations contain context that improves future interactions. But if the traveler deletes their account, conversations are deleted too. Payment records are retained according to financial compliance requirements, typically 7 years. We can't delete payment records on request because we're legally required to keep them for tax and dispute purposes. We explain this to travelers when they request deletion. Authentication logs are retained for 90 days. They're useful for security investigations but don't need to persist beyond that. Operational logs are retained for 30 days. Enough for debugging and [incident response](/blog/incident-response-travel-platform). Not enough to become a liability. ## Right to deletion and data portability A traveler can request that we delete their data. This right exists in multiple regulatory frameworks, and we honor it regardless of which jurisdiction the traveler is in. Deletion is a cascade. It's not enough to delete the user record. We must delete: the user profile, all traveler profiles associated with the account, all trip records, all booking references (while retaining anonymized financial records as required by law), all travel documents (passport scans, [boarding passes](/blog/launching-document-management-boarding-passes)), all conversation history across all threads, and all data stored in the [agentic memory](/blog/agentic-memory-smarter-over-time) service. That last item is important and easy to miss. The AI agent's memory system stores conversation context and learned preferences across sessions. This data is stored in a separate service from the main database. A deletion request must cascade to the memory service as well. Deleting the user record from the database while leaving their conversation context in the memory service is an incomplete deletion. We verify deletion by running a post-deletion check that queries all data stores for any remaining records associated with the deleted user ID. If anything remains, the deletion is flagged as incomplete and an engineer investigates. Data portability is the other side of the same coin. A traveler can request an export of all data we hold about them. The export includes everything: profile, trips, bookings, documents, conversation history, and preferences. We provide the export in a structured format (JSON) that the traveler can read and potentially import into another service. ## Privacy in AI agent memory The AI agent's memory creates a specific privacy challenge. The agent remembers things the traveler told it: "I prefer aisle seats," "my wife is allergic to shellfish," "we always stay at boutique hotels." This memory improves the experience over time. But it's also personal data that the traveler shared in conversation, and it needs to be handled with the same rigor as any other personal data. The traveler controls their AI memory. They can view what the agent remembers about them. They can correct inaccuracies. They can delete specific memories without deleting their entire account. The control is granular: "Forget that I prefer aisle seats" shouldn't delete the memory about boutique hotels. The agent's memory is also scoped. The agent doesn't share one traveler's preferences with another. The memory is per-user and per-conversation-thread. A booking made for one family member doesn't leak into recommendations for another. When the agent references a memory in conversation, it's transparent about it. "I remember you prefer aisle seats, so I filtered for those" tells the traveler what data influenced the recommendation. This transparency builds trust and gives the traveler an opportunity to correct outdated preferences. ## Build privacy into your platform If you're building a platform that handles personal data, here's the framework that guides us. Classify data at design time. Before you store a field, decide its classification. The classification determines every downstream decision about encryption, access, retention, and deletion. Encrypt critical data at the application level. Filesystem encryption is necessary but insufficient. Application-level encryption for the most sensitive fields provides defense in depth. Build deletion as a cascade. Map every data store that contains user data. The deletion must reach all of them. Miss one and you haven't actually deleted the user's data. Verify deletion works. Don't trust that the cascade is complete. Run a verification check after every deletion. Treat incomplete deletion as a bug. Give users control over AI memory. If your AI system learns about users, those users must be able to see what it knows, correct inaccuracies, and request deletion of specific memories. Memory that the user can't control is surveillance. Be honest about gaps. No system is perfect. Acknowledge the work in progress rather than pretending everything is complete. Users trust honesty more than perfection. --- Nowah is an AI travel agent that searches and books real flights and hotels through conversation — no filters, no thirty open tabs. [Plan your next trip](https://app.nowah.xyz).