Why “AI Detected” Can Be Misleading for Identity Verification

AI automation is becoming part of normal digital behavior, and we can even prove it.

The question is: how to manage it?

Take autofill, for example. An AI tool can read the name, date of birth, and document number from an ID the customer has chosen to submit, then place those details into the corresponding form fields. 

The customer then reviews the entries and completes the selfie or liveness check personally. This removes tedious typing and reduces transcription errors without changing the evidence behind the verification. Totally fair.

The real risk begins when AI supplies the face, the evidence, or the authority that should come from the customer.

A virtual camera, for instance, can feed generated or prerecorded media into a selfie check while presenting it as live camera output. In this case, even if face comparison returned a match, it would not matter anymore. The check has only proved resemblance, but not whether someone just uploaded a photo of a person who is not them.

What’s more, AI agents are now clever enough to use valid customer data to request account recovery or change payout details without consent. Every field may be correct while the person behind the identity never approved the action.

In both examples, software has replaced something the business expected from the customer: live evidence in one case, authorization in the other.

Once AI can replace evidence or act without consent, blocking every automated session may feel like the safest answer. However, a blunt rejection rule can block legitimate applicants, force repeated biometric requests, and create more support work.

What’s interesting is that the commerce sector is already testing a more precise response. Visa created its Trusted Agent Protocol to help merchants distinguish approved shopping agents from hostile bots, since both may reach a website through similar channels. Rather than asking an agent to behave like a human visitor, the protocol gives it a verifiable identity of its own.

When an approved agent sends a request, it attaches a cryptographic signature — tamper-resistant proof that the request came from an agent holding an approved key. The merchant or its bot-protection provider validates that signature against a trusted public key. A timestamp and unique code also help confirm that the request is fresh and has not been copied or reused.

Applied to an ID verification session, Visa’s general principle can lead to four different responses:

These responses also depend on the company’s risk appetite. During a low-risk task, an authorized agent may be allowed to prepare or submit information within a recorded scope. But for a high-risk action (e.g., account recovery or payment approval), the company may refuse delegated identity evidence and accept only evidence captured directly by the end user. 

On top of that, biometrics specifically show why such separation is needed: 

1. Face comparison tells us whether two faces resemble each other. 

2. Liveness checks tell whether a live person participated. 

3. Capture-source controls tell how the media reached the system.

Lastly, uncertainty also needs its own route. Another capture, a different verification method or human review may resolve the case without a hard rejection. That’s why teams should track abandonment, complaints and reversed decisions beside confirmed attacks. Otherwise, a strict policy can look effective while legitimate customers disappear from its reports.

Regula IDV Platform does not claim to see every browser extension, translation product or AI assistant. However, even perfect visibility would only tell a company that software was present; It would not establish whether the software acted with permission or replaced identity evidence.

The solution brings together identity lifecycle management, document and biometric checks with liveness detection and injection attack prevention, automated decisions and external services. 

By doing so, it gives each company control over how the above recommendations can be applied. Teams can configure various checks, thresholds, agent permissions and review routes according to their risk appetite, use case and internal policy. Alternatively, they can start with preconfigured workflows and adapt them to their needs.

This way, a company can:

• Keep the usual checks for routine onboarding.

• Request stronger proof before account recovery or payment approval.

• Send uncertain cases to human review.

• Keep each decision attached to the evidence and session history behind it.

And that turns AI ≠ fraud from a useful principle into something identity teams can apply session by session.