Uploading a Selfie to ChatGPT Is Not a Filter: Your Face Is a Credential You Cannot Reset

Table of Contents

1. TL;DR
2. What that Story is doing
3. Following the trend is rational, and that is the problem
4. Being seen in public and being ingested by a model are not the same thing
5. After a face goes in, the pipeline looks like this
6. Consent is written in the terms, the decision happens in the Story
7. We build amplification tools too, so we will say it plainly first
8. The red line: what can go to the cloud and what cannot
9. Closing
10. Further reading

Disclosure: Ultra Lab, MindThread and Ultra Advisor are products of the same group, Ultra Creation (傲創實業).

#TL;DR

• The Stories going around these past few days look like this: upload a selfie, ask ChatGPT "If you had been a Japanese gangster, what would you look like?", post the result, and add "your turn".
• It looks like a filter, but it is not. A filter changes pixels on your device; this flow sends a high-resolution frontal face to someone else's server.
• A face is a biometric credential. A leaked password can be changed; a face cannot be reset.
• The default on consumer accounts usually lets the provider use your content to improve its models, and turning the setting off is usually not retroactive.
• Deleting a conversation is not the same as pulling it back out of a training batch. There is no forgetting API for data that has been trained on.
• We have two paths of our own that touch faces. Section six lays them out; this is not a claim of zero contact.
• UltraProbe's ADP dimension blocks "input that should not go into a model". It can protect the application you are building. It cannot buy back the face you fed out yesterday.

#What that Story is doing

The frame is simple. A generated image, the subject is the poster in yakuza styling, the background aged. Below it one line: Asked ChatGPT "If you had been a Japanese gangster, what would you look like?". Below that, the view count, and "your turn".

What is worth looking at is not whether the picture looks cool. It is those last two words.

This Story has three parts: the result does the attracting, the recipe (that prompt) lowers the barrier, and the call-out turns "should I upload this?" from a decision into taking your turn.

The first two parts are in every tutorial. The third is the engine: it links individual behaviour into a chain. What you are seeing is not one person uploading a face. It is a queue.

The same week also brought 1980s retro portraits, Ghibli style and action-figure style. Different looks, same structure: hand over a real face, get one round of social interaction.

#Following the trend is rational, and that is the problem

The people playing along have not made any wrong judgement.

The reward is immediate: within thirty seconds you get a picture that looks better than you do and carries a story, and people reply when you post it. The cost feels like zero; you already had the selfie.

The risk is delayed and abstract. Nobody can tell you "where this face will turn up in three years", because that event has no image, no point in time, and no victim who can point to it. Humans have always responded badly to risks of this shape.

Add the sense of authority: this is not some app nobody has heard of, it is ChatGPT, and the brand itself is a hint of safety. Last comes etiquette. "Your turn" is not ad copy, it is a social obligation, and declining an invitation takes more justification than accepting it.

So this is not stupidity. It is a behaviour with an immediate reward, an invisible cost, an authority behind it, and a design built as a relay. Its spread is inevitable.

We are in no position to pretend we cannot see how it works. Ultra Lab builds content automation itself, and what we deal with every day is exactly "which posts get picked up and passed on". Growth systems feed on low friction, and we know how low friction is made.

#Being seen in public and being ingested by a model are not the same thing

The most common pushback: my Instagram profile picture is my face anyway, it has been public for ages.

That sentence squashes three different things into one.

Layer	What happens	Why it is more serious
Public social photo	Seen, screenshotted, reshared	It remains an image from start to finish. How far it spreads may get out of control, but the thing itself does not change in kind
Cloud photo album	Hosted, backed up, possibly grouped by face to make your search easier	Storage and indexing; the purpose is not to produce "another face of you". The risk lies mainly in account theft and provider breaches
Upload to a generative model	Inference, retained in conversation history, possibly used for training, possibly sampled for human review	The image has to be converted into the model's internal vector representation to be processed, not merely stored. Platforms have not published the details of this layer, so what really stands up is not "it amounts to a face template" but it cannot be reset: a leaked password can be changed, a face cannot

The difference is in the third column. The first two layers deal with "who will see this picture"; the third deals with "what this face is turned into, and what is then grown from it".

Some restraint is needed here. Any model that can look at images has to encode the image into some internal representation before it can process it; that by itself is a truism and does not amount to an accusation. Whether that representation is equivalent to a matchable, reusable biometric template is still debated in the industry, and platforms have not disclosed that layer. We call the face a credential not because we know for certain there is a face recognition algorithm running behind it, but because it shares one property with a fingerprint: it cannot be reset.

The same image also carries things you did not mean to give. EXIF usually contains the capture time and device model, and sometimes GPS coordinates. Even if you strip the EXIF, the background talks: the buildings outside the window, the certificate on the wall, the documents on the desk, the family members and children in the frame. Several vision models have shown in public tests that they can estimate where a photo was taken from visual clues alone, without EXIF. This behaviour has been reproduced repeatedly; it is not hypothetical.

So "it's already public anyway" does not hold. Not because being public does not matter, but because the consequences of the two are of different kinds: one is an exposure problem, the other a raw-material problem.

#After a face goes in, the pipeline looks like this

Straight to the flow:

Original image (may contain EXIF: capture time / device model / sometimes GPS)
  ↓
Uploaded to the provider's servers
  ↓
Enters the conversation context (tied to your account)
  ↓
Vision model encodes the image into an internal representation (platforms have not disclosed details of this layer)
  ↓
Output generated
  ↓
Conversation retained in account history
  ↓
If a consumer account has not turned off the "improve the model" type of setting
  → the content may be included in training data for future models
  ↓
After you delete the conversation
  → the system may still retain it for a period under its policy (commonly cited as about 30 days, with separate exceptions for legal and safety reasons)
  ↓
Once it has been through a training batch
  → there is no forgetting API

The last line is the only irreversible point in the whole pipeline. Every step before it is still data processing, with policies that can govern it and settings that can be switched off. Once it has been through a training batch, it has been kneaded into the weights and is no longer a record that can be deleted.

The above is common practice for consumer services today, not a law of physics: actual policy is whatever each provider's current data controls documentation says, and it changes. Enterprise plans and APIs usually have different defaults, and most state explicitly that they do not train on your data.

And because this is a design problem, not fate, it can be designed differently. We have written about our own approach many times: data that must stay confidential and should not leave the country goes through local Ollama, and the data never leaves this machine. Unless the full report is unlocked, UltraProbe scans do not store the tested system prompt by default.

Someone decides where data goes.

#Consent is written in the terms, the decision happens in the Story

The terms themselves are not obscure. OpenAI's Terms of Use put it like this:

You may provide input to the Services (“Input”), and receive output from the Services based on the Input (“Output”). Input and Output are collectively “Content.” You are responsible for Content… You represent and warrant that you have all rights, licenses, and permissions needed to provide Input to our Services.

We may use Content to provide, maintain, develop, and improve our Services…

If you do not want us to use your Content to train our models, you can opt out by following the instructions in this article.

The page explaining training is more direct:

When you use our services for individuals such as ChatGPT or DALL•E, we may use your content to train our models. … Once you opt out, new conversations will not be used to train our models.

Note the word "new" in the last sentence. Opting out takes effect going forward.

Section 6 of the Service Terms has another passage, specifically about likeness:

You may not use Visual Capabilities to reproduce the likeness of any person without express consent and all necessary rights. By choosing to share an image or video publicly on the Services, such as by sharing it to the Sora feed or uploading it to create a Sora cameo, you represent you have all necessary rights, and you give OpenAI the right to reproduce, distribute, modify, display and perform it for the purpose of operating and promoting the Services.

The weight of this passage lies in its direction. The terms treat a face as ordinary "Content", then push consent and the associated liability entirely back onto the uploader. The moment you upload, you are the one declaring that you have the right to do so. If anyone else is in the picture, you are the guarantor.

The problem is not that the terms are unclear. It is that nobody makes this decision while reading the terms. The decision happens in the Story, within thirty seconds of being called out. A training setting that is on by default, paired with a moment driven by social pressure, produces formal consent plus a de facto waiver.

And do not look at only one company. Many third-party wrapper tools that "ask ChatGPT for you" add another hand in the middle, with retention policies even less transparent than the original provider's, and you do not even know where to go to turn the setting off. The original provider at least has a data controls page you can open.

This is exactly why we put the ADP dimension into AASS.

AI Trust Score = AVS × 0.30 + PDS × 0.35 + ADP × 0.35

ADP asks only one thing: did you give AI data you should not have given it? Faces, identity documents, keys and national ID numbers are, under this dimension, different densities of the same kind of problem. When we wrote the long piece on attack vectors, the subject was how to stop a model from being tricked into giving things up. ADP is about the step before that: some things should never go in at all.

One pushback needs dealing with on the spot: so should accounts have no photos at all? Even if I do not upload mine, someone else will.

A profile photo is there so people recognise you; that is its purpose. Sending a high-resolution frontal face into a generative model is a different thing. As for someone else uploading your face behind your back, that person is breaking the terms; when you upload it yourself, you have signed the terms as guarantor. The legal positions are different. This is not saying do not use social media. It is saying these two actions should not be treated as the same one.

On the same timeline, the top half is debating whether AI will end humanity and the bottom half is handing faces over to the current generation of models. The risk that is actually deployed looks like a Story.

#We build amplification tools too, so we will say it plainly first

This section is a disclosure of interest, not a product section. What we build are tools that make posts easier to pick up and pass on, so we should talk about ourselves first.

My original draft of this section said "our growth tools do not collect faces". It was sent back during adversarial fact-checking, because that sentence was false.

What is actually the case:

• The content automation line has one feature that reads faces. MindThread's image-to-post feature lets users upload a work photo and generates post copy from it; that image is converted to base64 and sent to Gemini for image recognition. If there is a face in the picture, that face is read once by a cloud model at that moment. We have no "is there a face in the picture" check on this path, and the image is stored in Firebase Storage with no automatic expiry.
• UltraSite's business card generator has an optional avatar field. The interface says "Add a photo (optional, it will look more like a business card)". The image is compressed into a small square in the browser and stored in the database, with one use only: being displayed on your own card. It does not go into the prompt, does not take part in generation, and is not sent to any generative model.
• When the public interface looks up that card, it returns "whether there is a photo", not the photo itself. Fetching the image goes through a separate endpoint, so that crawlers cannot harvest them in bulk.
• The comment next to that line in our code reads 人臉 base64 ("face base64"), followed by a PDPO tag (Hong Kong's Personal Data (Privacy) Ordinance). Internally it was already being handled as personal data; the external sentence just claimed too much.

So the honest version: we have two paths that touch faces, one that sends them into a cloud model and one that only stores them for display. We know where both are and what they do, but neither is "zero contact". Calling it zero contact was my mistake.

The rule has not changed, it now simply applies to us as well: if a future feature genuinely needs faces or identity documents, it must be treated as a new category, with separate consent, defaulting to local processing or zero retention, and it must never be treated as one more small option inside an existing tool. Accelerating circulation does not grant a right to collect identity.

In an article about how others collect faces, if the section about ourselves is false, none of the sentences after it are worth reading. We wrote a separate piece on how we prove we actually do these things.

#The red line: what can go to the cloud and what cannot

Straight to the classification:

Fine for consumer cloud models	Keep on your own machine, or do not upload at all
Copy and content you have already published	Original frontal face photos, ID photos, children's faces
Material and illustrations with no faces or documents	Client lists, client conversation records
Screenshots that are cropped, de-identified and stripped of EXIF	Photos of your home and workspace
Public data, public reports	Camera originals with EXIF still attached
Drafts you wrote yourself that contain no one else's information	Any face that is not your own

If you still want to join the trend after reading this, what follows is harm reduction, not safety. The distinction matters, so here it is once more: each item below only makes the damage smaller; none of them makes this safe.

And to be clear about which part they reduce: these measures deal with the step of whether content goes into training, which is the only irreversible step in the pipeline. What they cannot deal with is the moment before that: the act of generating has already had a frontal face fully processed once on someone else's server. No setting can switch that one time off.

• In the data controls settings, turn off the "Improve the model for everyone" type of setting (remember it is not retroactive and only applies to conversations after the change).
• Use Temporary Chat. According to the official documentation it is not used for training and is retained for a shorter time; the actual conditions are whatever the provider's current policy says.
• Before uploading, crop to head and shoulders, strip the EXIF, and remove locations and documents from the background.
• Do not upload other people's faces, and above all not children's.
• Delete the conversation when you are done. Deleting the conversation does not delete a file saved separately in Library, and does not necessarily delete a memory saved from it; Part 4 of this series sets out the three places to clear separately.

Then Probe's position, stated flatly so there is no misunderstanding:

ADP/Probe defends against your own application becoming a collection point. It cannot buy back a face already fed to ChatGPT.

If you are building an AI application that takes user input, UltraProbe can help you check whether it collects things where it should not. If you only played along with a Story, it cannot help. Stating a tool's scope clearly is more useful than making it sound bigger.

#Closing

The trend will pass. Next month there will be a different look, and this batch of images will sink to the bottom of the Stories.

But the face will not pass. It has already been processed once on someone else's server, and that one time is not in your photo album or in your account, and there is nowhere you can check where it went afterwards.

This post is not asking you to stop using generative models; we use them every day ourselves. It is asking you to manage your face as a credential, not post it like a sticker. Credentials have credential rules: do not hand them out carelessly, be able to revoke what you hand out, and do not hand out what cannot be revoked.

To close in product terms: a system that has not clearly stated four things, what the default is, how far the scope reaches, how long retention lasts, and whether it can be revoked, should not collect people's faces.

You have always had the right to ask these four questions before you press upload.

#Further reading

• Part 2 of this series: ChatGPT's terms write your face down as "Content"
• Part 3 of this series: if your product accepts photo uploads, you are already building a biometric system
• We defined a security standard for the AI era: AASS v1.0
• Free Tier Wars 2026: why confidential data goes through Ollama
• How do we prove we actually do AI?

FAQ

How is uploading a selfie to ChatGPT to generate an image different from applying a filter?

A filter changes pixels on your own device; the image never leaves your phone. A generative model means sending a high-resolution frontal face to the provider's servers, where it is processed, kept in your conversation history and, under the default settings of consumer accounts, possibly used to improve the model. The difference is not how good the result looks. It is where the data goes and whether it can come back.

My face is already public in my Instagram profile picture. Does it still make a difference?

Yes, and the consequences are of a different kind. The risk of a public social photo is who sees it; the thing itself is still an image. Once it is sent to a generative model, the image has to be converted into the model's internal representation before it can be processed, and once it has been through a training batch there is no way to recall it. The first is an exposure problem, the second is a raw-material problem.

If I delete the conversation, is the photo gone?

Not the same thing. After deletion the provider may still retain it for a period under its policy (the commonly cited figure is about 30 days, with separate exceptions for legal and safety reasons). More importantly, if the content has already been through a training batch, no interface can pull it back out of the model weights. Deleting a conversation deals with the record, not with training that has already happened.

Am I safe once I turn off the "improve the model" setting?

That is harm reduction, not safety, and it is usually not retroactive: it only applies to conversations after the change. It deals with the step of whether content goes into training. What it cannot deal with is the moment before that: the act of generating has already had a frontal face fully processed once on someone else's server.

What can go into cloud AI, and what should not?

Fine: copy you have already published, material with no faces or documents, screenshots that have been cropped, de-identified and stripped of EXIF, and public data. Should not be uploaded: original frontal face photos, ID photos, children's faces, client lists and conversation records, photos of your home and workspace, camera originals with EXIF still attached, and any face that is not your own.