← All posts

Identity Assurance

The Disclosure Ladder: What Does an AI Service Really Need to Know?

Before an AI service asks for more identity, the better question is not whether it can verify a person. It is what property the system actually needs to know.

Andrew Davidson
Andrew Davidson
R&D Nordic · July 8, 2026 · 14 min read

A service asks you to verify yourself.

Maybe it is an AI tool trying to prevent abuse. Maybe it is a platform checking whether you are old enough to use a feature. Maybe it is a workplace system, a financial service, a school portal, or a public-sector form. The wording is usually calm and procedural; verify your identity, confirm your age, prove you are human, continue securely, and so on.

The useful thing you want is on the other side of that check.

At that moment, the request can feel like a small administrative step. You want access, and the system has placed access behind an annoying gate. The immediate consequence of compliance is clear: the page opens, the account works, the task continues. The future consequences are harder to see. Where will the data go? How long will it be kept? What else can be inferred from the data? Can the verification be reused elsewhere? Who can challenge an error? What happens if the system, issuer, wallet, vendor, or database is compromised later? How will this affect me, or my family, or my work?

Those questions are often too large for the moment in which the choice is made. That is why identity assurance needs a better public vocabulary.

One useful way to think about it is a disclosure ladder.

The disclosure ladder is not a formal legal term. It is a practical way of asking how much personal information a system demands as the price of trust. At the bottom of the ladder, the service may need little or no personal information. A local check, a device-level proof, a payment token, or an anonymous credential might be enough. Higher up the ladder, the service asks for a verified email address, phone number, age attribute, government ID, selfie, biometric match, liveness check, or persistent account tied to a real-world identity. In more extreme cases, such as those related to getting a passport or international travel, fingerprints or DNA may also be collected.

The point is not that every higher step is automatically illegitimate. Some situations really do require stronger assurance. A bank, a benefits system, an educational exam platform, a high-risk workplace tool, and a child-safety service do not all face the same problem. The point is that each step up the ladder should need a reason. Or specifically, a legitimate reason.

Before asking for more identity, the system should answer a narrower question: what property do we actually need to know?

Identity is not one question

Part of the problem is that "identity verification" sounds like one task, a quick check before you move on. It is not.

An online service may want to know whether a person is over a certain age. That is an age question. It may want to know whether the same person is returning to an account. That is a continuity question. It may want to know whether one person is creating thousands of accounts. That is an abuse-resistance question. It may want to know whether a clinician, teacher, student, public employee, or contractor has a valid role. That is an authorisation question. It may want to know whether a person is globally unique across all services. That is a much stronger, and much more dangerous question.

These questions are often bundled together because stronger identity checks are administratively convenient. A passport scan plus selfie may answer several questions at once. It can support age checks, fraud review, account recovery, audit trails, and enforcement. From the organisation's perspective, the stronger check can look efficient.

But efficient for whom?

For the user, the bundle may mean giving away more information than the decision required. For the organisation, it may mean holding data that creates new security duties and new failure modes. For society, it may normalise the idea that access to ordinary digital life requires identification by default.

That is the governance problem. If a service only needs to know that someone is over 18, it does not automatically need to know their name, address, document number, face, and wider identity history. If a service needs to limit repeat abuse, it does not automatically need a permanent cross-service identifier. If a service needs to know that a credential is valid, it does not automatically need a central database of every occasion on which the credential was shown.

A narrow decision should not quietly become a broad identity collection system.

The behavioural problem

My previous privacy essay, Why Privacy Choices Are Harder Than They Look, argued that privacy choices are often arranged so that disclosure is immediate, easy, and rewarded, while privacy harms are delayed, uncertain, and difficult to picture. Identity assurance has the same structure but the stakes are higher.

The person standing at the gate trying to get in is not usually choosing between two equally visible options. They are choosing between access now, or an uncertain risk later. If they comply, the task continues. If they refuse, they may lose access to the service, miss the conversation, fail to complete an important form, be excluded from a workflow, or spend time searching for an alternative that ultimately may not exist.

From a behavioural analysis perspective this distinction is important, because the system has arranged a consequence. Disclosure produces immediate access. Refusal produces friction. Over repeated interactions, that arrangement can select for compliance, even when the person has real privacy concerns.

This does not mean people are helpless, but it does mean that "the user consented" is an insufficient justification on its own. A click, scan, or upload records that a response occurred. It does not prove that the person understood the future uses of the data, had a meaningful alternative, or evaluated the wider identity architecture.

The same behavioural lens applies to organisations.

Organisations also act inside consequence arrangements. A stronger identity check can reduce some immediate risks. It may reassure investors, boards, regulators, advertisers, insurers, or procurement teams. It can create visible evidence that something was done about abuse, fraud, bots, children, safety, or compliance. Those consequences are concrete and near in time.

The costs are often more distributed. Over-collection of identifiable data may significantly increase the impact of a data breach. Biometric or document-based onboarding may exclude people who lack the right documents, devices, language, confidence, or time. Centralised identity records may create future misuse risks. But those consequences can be delayed, externalised, or hard to attribute to the original design decision.

That is how systems drift up the ladder; not necessarily through bad intent, but through ordinary, observable selection pressures.

Here, I am using "selection pressures" in the sense developed by Sandaker's selectionist perspective on organisational change. The useful unit of analysis is the relation between a practice and the consequences that make that practice more or less likely to recur within the system. In an identity-assurance workflow, those consequences are concrete enough to inspect: procurement criteria, risk registers, board reporting, audit evidence, vendor claims, incident-response incentives, user drop-off metrics, liability fears and more.

If those mechanisms reward fast deployment and visible risk control more than minimisation, reversibility, contestability, and non-exclusion, the direction of travel is predictable. A higher-disclosure check will tend to be repeated because it solves several visible institutional problems at once. A lower-disclosure design may better fit privacy and proportionality, but it requires more careful thinking, better architecture, narrower purpose definition, harder procurement conversations and, in short, more time, money, and effort. The system can therefore select the intrusive practice even while privacy-by-design remains part of the formal language.

Privacy-preserving assurance is not magic

There are better technical patterns than simply collecting more identity data.

A system can sometimes verify a property, rather than an identity. It may be enough to know that a person is over a threshold age, holds valid credentials, controls a previous account, or has passed a check, without revealing all the underlying documents every time. Privacy-preserving credentials, wallet-based proofs, selective disclosure, revocation checks, and local or mediated verification can all be part of that conversation.

These ideas matter because they change the question. Instead of asking, "How do we identify the user?", the design question becomes: what claim does the relying service need, who can issue it, how can it be checked, and what does the service learn in the process?

But privacy-preserving assurance does not eliminate trust. It moves it. The user may still need to trust an issuer. The relying service may need to trust a credential format, wallet, revocation mechanism, device, audit process, or governance scheme. Someone must decide who is allowed to issue credentials, how errors are corrected, how fraud is handled, how compromised credentials are revoked, and how people are protected when they cannot or do not want to use the preferred method.

That is why the disclosure ladder is useful. It keeps the technical excitement tied to the functional question. A privacy-preserving age proof may be much better than repeated document upload for a simple age gate, but it may not be enough for every high-risk transaction. A reusable credential may reduce repeated disclosure, but it may also create new dependencies and new patterns of exclusion if it becomes the only acceptable route.

The task is not to romanticise any technology, including AI. The task is to ask what behaviour and institutional practice the system will actually select. Will it make minimal disclosure easy? Will it make refusal meaningful? Will it make errors contestable? Will it discourage unnecessary collection? Will it prevent one narrow check from becoming a general-purpose identity infrastructure?

What the ladder should ask

A disclosure ladder turns identity assurance into a sequence of questions.

First, what is the actual decision? Is the system deciding access, age, account recovery, professional eligibility, payment risk, abuse prevention, exam integrity, or legal compliance? If the decision is vague, the data request will usually expand.

Second, what property is needed for that decision? Over 13, over 16, or over 18 is different from receiving a full date of birth or social security number. Credential valid is different from credential history. Same account holder is different from legal identity. Human enough for this interaction is different from globally unique personhood.

Third, what is the least revealing way to establish that property? The answer may be a local check, a one-time attribute proof, a trusted issuer, a risk-based step-up, a human review process, a pseudonymous reputation signal, or no identity check at all.

Fourth, what happens to people who refuse, fail, or cannot complete the check? A privacy option that exists only for highly informed, well-resourced, technically confident users is not a fair alternative. If refusal means exclusion from ordinary participation, then consent is carrying too much moral weight.

Fifth, what data is retained, by whom, and for how long? A check that verifies a property in the moment is different from one that creates a durable record. The difference matters especially when documents, faces, behavioural signals, or device identifiers are involved.

Sixth, what behaviour is the system likely to reinforce over time? If every service asks for stronger identity, users learn that disclosure is the routine price of participation. If procurement rewards vendors for maximum risk reduction but does not test minimisation, vendors learn to climb the ladder. If regulators and boards ask only whether a control exists, institutions learn to implement visible controls rather than proportionate ones.

These are not abstract questions. They belong in data protection impact assessments, fundamental rights impact assessments, procurement templates, AI governance reviews, age-assurance debates, workplace AI assessments, and platform trust-and-safety design.

A practical example: age assurance

Age assurance is a good test case because the underlying concern can be real. Children and young people do need protection in digital environments. Platforms and AI services may face legal, ethical, and reputational duties. It would be too simple to say that every age check is surveillance by another name.

But it would also be too simple to treat any age check as justified because the word "safety" appears nearby.

The disclosure ladder asks: what age property is needed, for which feature, at which level of risk, and with what alternative path?

A low-risk feature may need no age check. A higher-risk feature may need an age band. A regulated service may need stronger assurance. Some situations may justify step-up checks only if risk signals appear. Others may require a trusted third party. The answer should depend on purpose and proportionality, not on the convenience of collecting a document and face scan once and using that as a universal answer.

A behavioural view also asks what the design will teach. If teenagers, parents, and adults repeatedly learn that every online safety concern is solved by document upload or biometric verification, then society may normalise a very heavy form of digital participation that ultimately places an unacceptable risk on the children themselves. If, instead, services learn to ask for narrow proofs and justify escalation, a different practice can be selected.

That distinction matters for AI services because the pressure to verify is likely to grow. Concerns about bots, synthetic media, fraud, child safety, copyright, harassment, market manipulation, and political influence will all create demand for stronger assurance. Some of that demand will be legitimate. Some will be opportunistic, and much of it will be messy.

The public debate needs a way to say: yes, this problem may require assurance, but no, that does not automatically justify the highest-disclosure method.

The governance implication

Good identity governance should make escalation visible.

A service should be able to explain why it is on a particular step of the ladder. It should explain why a lower-disclosure method is insufficient. It should identify who receives the data, what is retained, how long it is kept, what happens after failure, and how errors are corrected. It should test not only whether people click through the process, but whether the process excludes, pressures, or trains behaviour in ways the organisation would not defend openly.

This is where behavioural analysis helps. It keeps the focus on observable arrangements rather than reassuring labels. "Consent", "trust", "safety", "assurance", and "responsible AI" are useful words, but they do not explain anything by themselves. The explanation begins when we ask what the system makes easy, hard, visible, hidden, immediate, delayed, rewarded, punished, and practically unavoidable.

For AI-era services, that question is becoming urgent. Identity will be used to manage abuse, protect children, allocate access, enforce law, verify credentials, prevent fraud, personalise systems, and decide who is accountable for what. If the default answer becomes more collection, more centralisation, and more biometric verification, we may solve some immediate problems, while building a deeper infrastructure of dependency and exposure.

The alternative is not naive anonymity everywhere. The alternative is proportional assurance.

Ask for the property, not the person, where that is enough. Escalate only when the risk justifies it. Keep lower-disclosure routes operationalised and real, not decorative. Make organisational incentives visible. Treat refusal, failure, and exclusion as design outcomes and not edge cases. Measure whether the system protects people in practice, not only whether it produces a compliance artefact.

The first privacy article ended with a simple idea: if disclosure is the path of least resistance, we should not be surprised when people disclose.

The disclosure ladder adds the next question.

Before we ask people to climb, who decided how high the ladder needs to be? Who holds the data at the top, what are they doing with it, and why does access to a low-step service require a high-step verification?

Disclosure

This essay was drafted with AI assistance under my direction and edited for argument, tone, and accuracy before publication. I used AI to draw on sources associated with my master's in behavioural science, articles I have written as part of my work at a Norwegian university, and material from R&D Nordic in order to clarify my points and translate some complex behavioural science taxonomy into everyday language. R&D Nordic advises on privacy, ethics, IPR, and AI governance; this essay is published as general analysis and reflects my personal opinions. It is not legal advice.

Sources

Share by email Talk to us
Privacy Identity assurance AI governance