POS Data Privacy for Retail Kiosks: What a Kiosk Should and Should Not Read

If you are putting an AI kiosk in your store, the privacy question is not "is it safe" — it is "what specifically does it read, what does it do with that data, and what should it never touch." The honest framework is narrower and more practical than most operators expect. This post walks through it, category by category, with a brief note at the end on where PCI compliance actually applies.

I am going to lay out the position I think every operator should take with their kiosk vendor — including Remi — and the questions to ask. The goal is a kiosk that helps your shoppers without becoming a surveillance product.

Three categories of data, three different rules

Almost everything in your POS falls into one of three buckets. The right answer is different for each.

Category 1: Product catalog and prices — yes, read freely

Product names, descriptions, categories, prices, attributes (gluten-free, vegan, kosher, age-restricted), images, variations. This is the data the kiosk needs to do its job. Without it, the kiosk cannot answer "do you carry X" or "where is Y" or "is this gluten free."

This data is not personal, not sensitive in PCI terms, and reading it does not create privacy issues. The kiosk should pull it on a regular cadence and use it freely. Read-only is the standard pattern; the kiosk should not be writing back to your catalog (that creates more risk than value).

There is a minor business-confidentiality consideration — your wholesale costs and your supplier contracts are in your POS too, and the kiosk does not need them. A clean integration reads the customer-facing catalog and skips the back-office fields.

Category 2: Individual transaction history — be careful

Square, Clover, Lightspeed, and Toast all expose transaction-level data through their APIs. This is where the privacy conversation gets real, and where I have seen vendors overreach.

What the data contains: timestamps, items purchased, prices paid, payment method type (credit/debit/cash, not card numbers), and — if the customer is identified via loyalty or customer profile — the link back to a specific person.

What it can be useful for: identifying which products are popular at the store level, validating promotions, and informing recommendation logic with real local sales patterns.

What it should not be used for: identifying individual shoppers from their transaction history without explicit consent. Building behavioral profiles. Training a third-party model on your customers' purchase patterns. Anything that turns the kiosk into a surveillance product.

The right pattern: aggregate-only access. The kiosk reads "best sellers in the wine category last week" not "Mary Smith bought a bottle of Caymus last Thursday." If the vendor's integration is reading transaction-level data with personal identifiers, ask why and demand a clear answer.

A useful test: ask the vendor whether you, as the operator, can opt out of transaction history sharing entirely while still using the product. If the answer is no, the vendor's data model assumes more access than they should have.

Category 3: Customer PII — no, separate flow

Names, emails, phone numbers, addresses, loyalty IDs, payment information. This category should never flow into a generic AI kiosk integration.

The reason is simple: the kiosk does not need to know who the shopper is to answer their wine pairing question. Pulling customer PII into a kiosk integration creates breach risk, regulatory exposure (CCPA, state privacy laws, possibly GDPR if you have any non-US customers), and a trust problem with your shoppers.

If a kiosk vendor's standard integration requests customer-data scope from your POS, that is a red flag. They should not need it. The valid use cases for customer PII at a kiosk — opt-in loyalty experiences, customer-initiated profile lookups via QR code — are narrow, explicit, and consent-based. They should be a separate flow with separate scope and clear customer consent, not part of the default integration.

What "consent-based" actually means

The kiosk has a customer in front of it. If the operator wants to enable a personalized experience (loyalty lookup, saved preferences, order history), the customer has to opt in to that experience explicitly. Examples of correct opt-in flows:

• The customer scans a QR code or taps an NFC tag to identify themselves. Their action is the consent.
• The customer types or speaks an email address into the kiosk to look up their account. Their action is the consent.
• The customer enrolls in a loyalty program through a separate flow that includes clear privacy disclosures.

Examples of incorrect "consent" flows:

• The kiosk recognizes the customer's face and pulls their profile without an explicit action. Even if there is a policy disclaimer somewhere, a passive identification with no opt-in moment is not real consent.
• The kiosk pulls all customer profiles from POS at startup and matches anyone who walks in.
• A vague "by entering this store you consent to..." sign at the door is treated as consent.

The bar for consent in a face-to-face commerce context is higher than the bar on a website. Treat it that way.

What we do at Remi

Concrete is better than abstract, so here is the position Remi takes:

• We read product catalog and inventory from POS. Read-only. We do not write back.
• We do not request customer-data scope from your POS by default. If you want to enable a customer-recognition feature, that is a separate, explicitly-enabled product surface.
• Customer identification on the kiosk is opt-in only — the customer scans a QR code or an NFC tag. We do not do passive face recognition for identification at this time, and even when we add it, it will be opt-in per shopper.
• Conversation logs belong to the operator. We do not train third-party models on your store's data.
• On disconnect, your data is purged within a documented window (we publish 30 days; can do faster on request).

Whether you choose Remi or a different vendor, the right answer should look broadly similar to that. If a vendor has a different answer to any of these, ask them to explain it.

A brief note on PCI compliance

PCI DSS — the Payment Card Industry Data Security Standard — is the framework that covers handling of credit card data. It applies to anyone who stores, processes, or transmits cardholder data.

For an in-store AI kiosk in the configuration described in the Square POS integration post, PCI is not the primary concern because the kiosk does not handle payment. The customer pays at the register. Card data flows through your POS and your processor; the kiosk never sees it.

If a vendor's kiosk does handle payment, PCI is suddenly very relevant. You need to know:

1. Is the vendor PCI-compliant? At what level? Do they have a current AOC (Attestation of Compliance)?
2. Where does cardholder data flow and where is it stored? (Ideally: nowhere on the kiosk; everything tokenized through the processor.)
3. Who is responsible for which parts of the PCI scope? (The vendor, the processor, the merchant — the responsibility split should be clear in writing.)

For a kiosk that is pre-register (the typical configuration), PCI does not apply directly. The data scope to focus on is the privacy framework above, not PCI.

The questions to ask the vendor

A short version of the questions you should put in writing with any kiosk vendor before signing.

1. What POS scopes do you request by default? Show me the OAuth consent screen.
2. What data do you pull on initial sync? What do you pull on an ongoing basis?
3. Do you read customer-identifying transaction history? If yes, why, and can I opt out while still using the product?
4. Do you train models on my store's data or my customers' interactions? If yes, can I opt out?
5. Where is my data stored? In what cloud, in what region, with what encryption at rest and in transit?
6. If I disconnect or terminate, when is my data deleted? Get a number, in days.
7. Do you handle payment? If no — confirm in writing. If yes — provide your AOC.

A vendor that has clear written answers to all seven is a vendor you can probably trust. A vendor that gets uncomfortable with these questions is one to be cautious about.

Why this matters more in 2026 than it did in 2020

Two reasons.

Regulatory. California's CCPA and the wave of state privacy laws (Virginia, Colorado, Connecticut, Texas, others) have raised the floor on how customer data has to be handled. Many of these laws apply to indie retailers above modest revenue thresholds. The kiosk vendor's data practices become your compliance risk.

Reputational. Shoppers are more aware of in-store data collection than they were five years ago. A kiosk that handles privacy well becomes a feature you can talk about. A kiosk that is opaque about data handling becomes a story your competitors can tell about you.

The good news is that good privacy practice is not expensive or hard. It is just deliberate. Pick the vendor that has thought about it carefully, and most of these questions go away.

If you want to talk through what the data flows look like in your specific store, reach out. The pricing page covers what a single-store deployment costs once the data conversation is settled.

Frequently asked

Does the kiosk store credit card numbers?

In the configuration we recommend (kiosk pre-register, customer pays at the register), the kiosk never sees credit card data. This is by design. If a kiosk-plus-payment configuration is being proposed, demand the PCI documentation.

What about voice recordings?

The kiosk records customer voice for conversational purposes. Recordings should be retained for a short, documented period (we use seven days by default) and never used for purposes other than improving that customer's experience or operator analytics. Ask each vendor about their retention policy.

Is the kiosk recording video?

Remi's kiosk does not capture video by default. Some vendors offer optional video features (gesture detection, accessibility features). Anything video-related should be opt-in by the operator and clearly disclosed to shoppers.

Can the kiosk identify a customer by face?

We do not do passive face recognition for identification. There is a roadmap feature for opt-in facial recognition for returning shoppers in a loyalty context, with explicit consent. We are deliberately slow on this because BIPA (Illinois) and similar laws make this category genuinely risky to implement carelessly.

What happens to my data if the vendor is acquired?

A good contract covers this — the buyer assumes the same data obligations. Read the contract. If it does not address acquisitions, ask for that to be added.

What about analytics tools (Google Analytics, Meta Pixel) on the kiosk?

Kiosks should not be running web-style analytics that share data with third-party ad platforms. The kiosk is a customer-service surface, not an ad surface. Confirm with each vendor what analytics, if any, are running on the device.