Last Updated on September 17, 2026 by Craig Allen Keefner
Your Kiosk Order Is More Than an Order — It May Be Training a Customer Model
A recent Gizmodo headline got our attention:
“Your McDonald’s File is Probably Bigger Than Your FBI File.”
That is intentionally provocative and sensational. But the story behind it is considerably more interesting for the self-service industry.
Gizmodo was reporting on a WIRED investigation by reporter Reece Rogers, who used California privacy law to request the information McDonald’s had collected about him. What came back was reportedly 515 pages of information.
The size of the document makes a good headline. What was in the document matters much more.
According to WIRED, the information included transaction history, loyalty activity, offers, Monopoly game interactions and predictions about Rogers’ future behavior. McDonald’s had estimates for how frequently he was likely to visit, how much he would spend and what products he was likely to purchase.
That moves the discussion well beyond a traditional loyalty database.
It also raises an important question for the kiosk and self-service industry:
When a customer places an order at a kiosk, where does that transaction really end?
The Kiosk Is Becoming a Data Endpoint
The traditional view of a self-order kiosk is straightforward.
Customer approaches kiosk. Customer selects products. Customer pays. Restaurant receives order.
Transaction complete.
Except increasingly, it isn’t.
A modern restaurant transaction can potentially connect several systems:
Kiosk → POS → Payment → Loyalty → Mobile App → Customer Data Platform → Analytics → AI/Prediction Engine → Personalized Offer
If a customer identifies themselves through a loyalty account, app, QR code or other identifier, an otherwise anonymous kiosk transaction can become another event associated with a persistent customer profile.
The kiosk doesn’t necessarily create that profile.
But it can feed it.
That distinction is important.
From Transaction History to Prediction
There is nothing particularly unusual about a restaurant remembering what customers purchased. Retailers have analyzed transaction histories for decades.
What has changed is the ability to combine those transactions with other signals and turn historical data into predictions.
Instead of simply knowing:
Customer bought a Quarter Pounder and fries Tuesday at 12:30.
A modern customer-data platform can potentially determine:
This customer typically visits this location at lunchtime, prefers these products, responds to this type of promotion, normally spends within this range and has a calculated probability of returning within a particular period.
That is a very different asset.
It is no longer simply a transaction record.
It is a behavioral model of the customer.
McDonald’s own privacy disclosures describe the collection of purchase history, interactions with its digital services and restaurant technologies, location information in certain circumstances, and inferences used to create profiles reflecting customer preferences and behavior.
None of that means McDonald’s is doing something unique or inherently improper. Similar technologies are used throughout retail, restaurants, travel, entertainment and financial services.
But the scale and sophistication deserve more attention from the self-service industry.
Verification Versus Profiling
There is an interesting parallel with another issue we have been examining at Kiosk Industry: ID scanning.
When an ID is presented to a kiosk or scanner, an important procurement question is:
Is the system simply verifying the identity—or creating a persistent identity-data record?
We should start asking a similar question about self-service transactions:
Is the kiosk simply processing the transaction—or contributing data to a persistent behavioral profile?
Those are not the same thing.
And increasingly, manufacturers, integrators and deployers need to understand which architecture they are implementing.
The Loyalty Connection Changes Everything
A kiosk transaction can be relatively anonymous.
A loyalty transaction generally isn’t.
Once customers identify themselves, the restaurant potentially gains the ability to connect activity across multiple channels.
A customer might:
- order from a kiosk Monday;
- use the mobile app Wednesday;
- redeem an offer Friday;
- visit a different location Saturday;
- participate in a promotion;
- respond to one offer but ignore another.
Individually, these are transactions.
Connected to the same customer identity, they become a behavioral history.
Apply machine learning to that history and the system can begin generating predictions.
That is where self-service becomes part of something much larger than order automation.
AI Makes the Data More Valuable
Artificial intelligence increases the importance of this discussion.
For years, the industry focused primarily on the operational benefits of kiosks: labor optimization, order accuracy, throughput, upselling and customer convenience.
Those benefits remain.
But every digital transaction can also produce structured information that becomes useful for analytics and AI.
The strategic value of a kiosk deployment therefore may not be limited to how many orders the kiosk processes.
It can also include the quality of the data generated by those interactions and how effectively that data connects with the organization’s larger customer intelligence systems.
That creates opportunity.
It also creates responsibility.
Privacy Needs to Become an Architecture Question
Privacy is often treated as something handled by the legal department after the technology has been selected.
That approach is becoming increasingly difficult to defend.
Manufacturers and deployers should understand questions such as:
What data does the kiosk collect?
What identifiers are attached to the transaction?
Where is the information stored?
How long is it retained?
Which systems receive it?
Is it being used for analytics or AI training?
Can a customer request access or deletion?
What happens when the same architecture is deployed in California, Europe, India or other jurisdictions with different privacy requirements?
Those are becoming system-design questions, not merely privacy-policy questions.
The 515 Pages Aren’t Really the Story
The Gizmodo headline comparing a McDonald’s customer file with an FBI file is entertaining, but we wouldn’t make too much of that comparison.
A database export can become hundreds of pages very quickly. Page count tells us very little about the actual sophistication of a system.
The important part of the WIRED investigation is that the information apparently went beyond historical purchases.
It included predictions.
That is the dividing line worth watching.
Self-service technology started primarily as a way for customers to perform transactions themselves.
Then it became an omnichannel interface.
Now it is increasingly becoming a sensor within the customer-data infrastructure.
That may ultimately prove to be one of the most consequential changes taking place in self-service.
The question is no longer simply:
What did the customer order?
Increasingly, it is:
What does this transaction teach the system about what the customer will do next?
Sources and further reading: Gizmodo, “Your McDonald’s File is Probably Bigger Than Your FBI File,” August 12, 2026; WIRED, Reece Rogers’ investigation into his McDonald’s customer-data disclosure; McDonald’s U.S. Privacy Statement and Privacy Rights Center.
Addendum – What About Healthcare or Hotels?
Yes—and hotel check-in and healthcare check-in may actually be more consequential examples than McDonald’s, because the kiosk can handle identity documents, payment credentials, travel history, health information, insurance information, biometrics, and other sensitive data.
The important answer to our second question is: there is no universal U.S. rule saying “a check-in kiosk must delete its transaction data after X days.” Instead, retention protection comes from a patchwork of sector-specific rules, state privacy laws, contractual requirements, and an organization’s own retention policy.
Hotel check-in: the kiosk can become an identity hub
Think about what a modern hotel kiosk can potentially touch:
Reservation → name → address → phone/email → loyalty ID → payment card → government ID/passport → room assignment → arrival/departure → companions → preferences → previous stays → offers/upgrades → potentially biometrics
That is substantially richer than a restaurant order.
The important architectural distinction is between information needed to complete check-in and information retained afterward to build the guest profile.
For example, a hotel might legitimately need to scan a driver’s license to establish that the person standing at the kiosk is the reservation holder. But that doesn’t automatically mean the hotel—or the kiosk vendor, ID-verification provider or cloud service—needs to retain an image of that license indefinitely.
That’s exactly the distinction from our ID-scanning research:
Verify → return result → discard source data
versus
Capture → upload → retain → associate with identity → reuse
And hotels aren’t theoretical targets. In its Marriott/Starwood enforcement action, the FTC specifically required a data-minimization policy under which personal information is retained only as long as reasonably necessary for the purpose for which it was collected, with the purpose and business need for retention documented.
That is a very useful principle for kiosk procurement.
Healthcare check-in is another level
A healthcare kiosk might process:
Identity → appointment → DOB → address → insurance → coverage → copay → payment → reason for visit → questionnaires → consent → symptoms → medications → accessibility needs → clinical information
Now we’re dealing with PHI when the system is operating for a HIPAA-covered provider or within the appropriate business-associate relationship.
HIPAA provides significant protections. Among them is the minimum necessary principle: covered entities generally must make reasonable efforts to limit uses, disclosures and requests for PHI to what’s reasonably necessary for the purpose, although there are important exceptions, including treatment.
But here’s a surprisingly important point for article:
HIPAA does not establish a general medical-record retention period.
HHS explicitly says the HIPAA Privacy Rule does not require medical records to be kept for a particular period. State laws generally establish medical-record retention requirements. HIPAA requires the PHI to remain appropriately protected for however long the organization maintains it, including through disposal.
So “HIPAA compliant” does not mean:
Patient check-in data is automatically deleted after X years.
That’s an important distinction.
California gets closer to “privacy by default”
California’s CCPA/CPRA framework provides a much clearer data-minimization concept.
The California Privacy Protection Agency says businesses subject to the CCPA must limit the collection, use and retention of personal information to purposes that meet the law’s requirements, and the amount collected, used and retained must be reasonably necessary and proportionate to those purposes. Consumers also have deletion rights, subject to exceptions.
That’s much closer to the question you are asking.
Rather than:
“Can we store this?”
the design question becomes:
“Why do we need to store this, and for how long?”
Europe goes further conceptually
The GDPR’s model is built around data minimization, purpose limitation and storage limitation. That creates a strong argument against collecting information merely because a kiosk can collect it, or retaining it indefinitely because storage is inexpensive.
And this becomes particularly interesting with global kiosk deployments.
The same hotel check-in kiosk could operate in California, Florida, Germany, Singapore and Dubai—but the privacy and retention obligations surrounding the transaction can differ substantially.
That connects directly to the global-regulatory framework you’ve been developing for accessibility.
I think we have uncovered a second dimension for that framework
We’ve been looking at the transaction primarily like this:
User → Self-Service Transaction → Accessibility / Payment / Identity / Safety / Security Requirements
But there’s another axis:
Collection → Verification → Transmission → Storage → Profiling → AI → Retention → Deletion
Put those together and you get something quite powerful:
| Transaction | Restaurant | Hotel | Healthcare |
|---|---|---|---|
| Identity | Loyalty/QR | ID/passport | Patient identity |
| Transaction | Order | Check-in | Appointment |
| Payment | Card/wallet | Card/deposit | Copay |
| Sensitive data | Preferences/location | Travel + ID | PHI + insurance |
| Persistent profile | Customer | Guest | Patient |
| Prediction potential | Purchase/visit | Travel/preferences | Potentially much more restricted |
| Retention question | How long? | ID image retained? | PHI/clinical record or transient check-in data? |
| Key question | Order or profiling? | Verify or archive? | Check-in or medical record? |
The healthcare distinction in that last row is particularly important.
A kiosk might temporarily collect an insurance-card image, driver’s-license image or questionnaire answer to complete check-in. That does not necessarily mean every intermediate artifact has to become part of the permanent medical record.
So manufacturers should arguably be designing systems where transactional data has explicit lifetimes.
For example:
Government ID image → verify → delete
Payment credential → tokenize → don’t retain raw credential
Insurance image → extract necessary information → apply provider retention policy
Temporary kiosk session → purge on session completion
Clinical questionnaire → send appropriate information into EHR → remove kiosk copy
Analytics → aggregate/de-identify where feasible
That is essentially privacy-by-design for self-service.
The bigger TIG/KMA concept here:
Every field collected by a self-service system should have a defined purpose, destination, retention period and deletion rule.
That could become a very practical Self-Service Data Lifecycle Framework:
COLLECT → USE → TRANSFER → RETAIN → DELETE
with four questions attached to every data element:
Why are we collecting it?
Who receives it?
How long is it kept?
Who deletes it?
That framework would work across restaurants, hotels, healthcare, airports, retail, vending, lockers, EV charging and identity verification—and it fits remarkably well beside the global accessibility/regulatory framework we have been developing.
