Judging vulnerability itself requires extra sensitive data

What it is

The detection paradox: identifying who needs protection requires knowing who is vulnerable, and vulnerability is composed of exactly the most sensitive information — cognitive status, financial distress, health conditions, age, emotional troughs. A recognition system built to protect creates a new central repository of sensitive data and a new harm surface: if that data leaks or gets repurposed, the people labeled "cognitively impaired" or "financially fragile" face targeted harvesting rather than protection. Protective intent does not change what the data is.

Why it happens

Inference precision and intrusiveness rise together: reliably distinguishing users who need slower flows from those who do not requires collecting or inferring executive function, income volatility, health markers — and the richer the inputs (typing cadence, error patterns, spending sequences), the more accurate the label and the more complete the profile. That profile carries three layers of risk: breach (a concentrated store of high-value sensitive data is a primary target), internal repurposing (protection labels reused by conversion optimization in the same product, "vulnerable" becoming a campaign segment), and outflow (data leaving its context via third-party SDKs or commercial transfer). Even with no incident, the label itself changes treatment: users flagged by the system may be downranked or feature-limited, experiencing a worse product — recognition precedes discrimination.

Where it stops holding

The paradox does not invalidate all recognition: in high-stakes domains (major finance, healthcare), modest detection plus strict data isolation can net positive; the operative principle is proportionality. User-declared modes ("I need a simpler interface" toggles) bypass inference entirely, create no covert profile, and sit outside the paradox — at the cost of low uptake. Regulation also draws the line: health and financial-distress inferences are special-category data in most jurisdictions, where processing without explicit authorization is unlawful regardless of "for their protection."

Applying it

• Fix the priority order: non-recognition approaches first (simpler, safer-by-default flows for everyone); recognition is a last resort that must document why those approaches fell short.
• Physically isolate recognition data from business data: separate storage, minimal retention, no reads by conversion or ad-targeting systems; write the isolation boundary into the architecture and audit it.
• Offer user-declared channels (prefer slower, simpler, more explicit confirmations), converting recognition from covert inference to on-demand opt-in.
• Verify: audit the protection system's data flows to confirm the inference label has no downstream reader outside protection flows; any single reuse is treated as an incident.

Related

• Same group: P4.04.6 Restraint applied to everyone beats differential treatment after identification · P4.04.4 Vulnerability is situational — anyone can enter it briefly
• Adjacent: O1.02 Data minimization · P4.05.3 Age verification itself involves a privacy trade-off
• Search terms: sensitive data inference · special category data · privacy trade-off in protection