Verificação de idade

Verificação de idade

O módulo idade responde uma pergunta, e não a que a maioria espera: ele não diz a idade do titular, ele diz se o titular aparenta ter pelo menos a idade que o seu flow exige. A estimativa sai pela selfie, sem documento e sem captura nova, e existe para o caso em que pedir documento é desproporcional (barreira de conteúdo adulto, por exemplo). Ele depende da prova de vida: sem ela não há rosto ao vivo para estimar, e o módulo recusa antes de estimar qualquer coisa.

Disponível desde 11 de setembro de 2026. Ele aparece na tabela de preços e no GET /v1/capabilities com preço e status available, e pode ser ligado num flow. Até essa data a venda estava pausada, por licença do modelo que estima a idade: o peso anterior tinha origem restrita a pesquisa e foi retirado do produto. O que roda hoje tem cadeia de licença aberta, declarada na página de segurança.

Dois campos numéricos, e o que decide é o segundo. minimum é a idade que o seu caso de uso exige (o requisito legal, 18 por exemplo). challenge é o corte efetivo que aplicamos, sempre maior ou igual ao minimum, e é contra ele que a estimativa é comparada. A margem entre os dois é deliberada: estimativa de idade por imagem erra para os dois lados, e exigir aparentar um pouco mais é o que impede que um menor de idade passe por ruído do modelo. Hoje o corte padrão é 19 para o mínimo de 18, ou seja um ano de margem. Quem comparar estimated_age com minimum chega a uma conclusão diferente da nossa.

// idade: aparenta ter a idade exigida. O score sobe com a folga sobre o corte.
{ "module": "idade", "passed": true, "outcome": "approved", "score": 92,
  "data": { "decision": "YES",        // YES | NO | INCONCLUSIVE | NO_LIVENESS
            "estimated_age": 31.2,    // anos, uma casa decimal
            "minimum": 18,            // o que o seu caso EXIGE
            "challenge": 19 } }       // o corte que de fato aplicamos (>= minimum)

// zona cinzenta: nem confirma nem nega -> pending, e vai a revisão
{ "module": "idade", "passed": null, "outcome": "pending", "score": 50,
  "data": { "decision": "INCONCLUSIVE", "estimated_age": 17.6,
            "minimum": 18, "challenge": 19 } }

// a prova de vida não sustentou a estimativa: recusamos ANTES de estimar
{ "module": "idade", "passed": false, "outcome": "failed", "score": 5,
  "data": { "decision": "NO_LIVENESS", "estimated_age": null,
            "minimum": null, "challenge": null } }

Os quatro campos podem vir null juntos quando a selfie não teve qualidade para nenhuma medida. E os quatro vereditos têm significados distintos que vale separar: YES é "aparenta ter", NO é "aparenta não ter", INCONCLUSIVE é a faixa em que não afirmamos nem uma coisa nem outra (e a verificação vai a revisão, em vez de barrar alguém legítimo), e NO_LIVENESS é o caso em que nem chegamos a estimar. No sandbox só existem YES e NO: o ambiente de testes não produz INCONCLUSIVE nem NO_LIVENESS, e chega a emitir o par outcome: "pending" com decision: "NO", que a produção nunca emite (lá NO é sempre failed). Trate esses dois vereditos como caminhos a implementar às cegas, e teste-os com o seu próprio duplo.