Accés API verificat per a proveïdors de models d'IA: una arquitectura de risc per nivells (CA)

La part difícil de posar la verificació d'identitat davant d'una API d'IA no és la verificació. És decidir qui no en veu cap.

Si això es fa malament en la direcció estricta, haureu penalitzat cada desenvolupador que volia provar el vostre model un dissabte a la tarda, la població exacta que vau gastar el vostre pressupost de creixement per adquirir. Si es fa malament en la direcció permissiva, haureu construït un control que les úniques persones que importen eludeixen.

Això és un problema d'arquitectura, i té una resposta raonablement ben definida: verificar segons el risc, no segons la població. Aquesta guia explica com organitzar l'accés per nivells, què hauria de desencadenar una comprovació a cada nivell, quins punts finals de Didit implementen cadascun i quant costa.

Punts clau

• La verificació pertany a les transicions d'accés — augments de quota, concessions de crèdit, emissió de noves claus, actualitzacions de nivell — no a la inscripció.
• Quatre nivells funcionen per a la majoria de plataformes: anònim / gratuït, autoservei de pagament, quota alta o crèdit alt, i organització o investigació.
• El cost s'escala amb la fracció de l'accés que realment protegiu: 0,03 $ per a anàlisi d'IP i dispositius, 0,33 $ per al paquet complet d'identitat, 0,10 $ per a reautenticació biomètrica, des de 2,00 $ per a verificació d'empreses.
• El KYC reutilitzable és gratuït — un desenvolupador ja verificat a la xarxa Didit supera una comprovació sense repetir-la.
• Les alertes de comportament de la vostra pròpia capa de trànsit són els millors desencadenants. La identitat és la resposta, no el detector.
• Tot plegat és un flux de treball, no una paret. Construïu-lo a l'Orquestrador de Fluxos de Treball (gratuït) i canvieu la política sense haver de desplegar codi.

El principi de disseny

Cada decisió de verificació intercanvia dos costos: la fricció que imposeu als usuaris legítims i l'accés que concediu a un usuari no verificat. Una política plana no optimitza cap dels dos, ja que assumeix el màxim d'ambdós.

L'alternativa és fer que la verificació sigui una funció del que el compte sol·licita. Un desenvolupador que realitza 200 sol·licituds contra un model públic amb un límit de despesa de 5 $ no representa un risc d'extracció significatiu, independentment de qui sigui. Un compte nou creat que sol·licita un augment de quota de 50x, pagant amb un instrument que ha aparegut en nou altres comptes aquesta setmana, des d'un dispositiu que el vostre sistema ja ha vist abans amb un propietari diferent, és una proposta totalment diferent, i val trenta-tres cèntims saber qui són.

Les mitigacions publicades per Anthropic apunten exactament en aquesta direcció. A més dels classificadors de detecció i l'empremta digital de comportament, la companyia enumera "verificació reforçada per a comptes educatius i d'inici" — verificació dirigida a categories d'accés específiques en lloc d'aplicar-se a tota la base de desenvolupadors. Aquesta és la forma.

Els quatre nivells

Nivell 0 — anònim / gratuït

Qui: qualsevol que s'hagi inscrit per provar el model.

Verificar: res. Comprovació de correu electrònic com a molt.

Per què: la població és enorme, el valor per compte per a un atacant està limitat pels vostres límits de taxa, i qualsevol fricció aquí és un impost directe al creixement.

Cost: 0,03 $ per a la verificació de correu electrònic, o zero.

El control en aquest nivell és el límit de taxa, no la identitat.

Nivell 1 — autoservei de pagament

Qui: qualsevol que hagi adjuntat un mètode de pagament i estigui gastant.

Verificar: només senyals passives — anàlisi d'IP i dispositius a 0,03 $.

Per què: voleu el substrat d'enllaç sense la fricció. Recollir senyals de dispositiu i de xarxa en aquest nivell significa que quan un compte escala més tard, o quan la vostra capa de trànsit el marca, ja teniu les dades de correlació. Retrofitar això després és impossible.

Cost: 0,03 $ per compte, una vegada.

Aquest és el nivell de més gran palanquejament de tot el disseny i el que més sovint s'omet. Els codis que esteu comprant — DUPLICATED_DEVICE_FINGERPRINT, DEVICE_RECOVERED_HIGH_CONFIDENCE, DUPLICATED_IP_ADDRESS, AUTOMATION_FRAMEWORK_DETECTED — són els que fan possible qualsevol investigació posterior.

Nivell 2 — quota alta / crèdit alt / amb accés restringit per capacitat

Qui: comptes que sol·liciten límits de taxa elevats, grans concessions de crèdit o accés a nivells de capacitat que considereu sensibles.

Verificar: identitat completa — 0,33 $ per document d'identitat, prova de vida passiva, coincidència facial i anàlisi d'IP.

Per què: aquí és on l'economia d'extracció comença a funcionar per a un atacant, i on vincular el compte a una persona atribuïble canvia el seu càlcul.

Cost: 0,33 $ per compte verificat. Les primeres 500 verificacions KYC cada mes són gratuïtes.

La cerca facial 1:N s'executa automàticament durant el pas de la prova de vida aquí, de manera que el nivell que més importa és també el nivell on obteniu la detecció de duplicats de forma gratuïta.

Nivell 3 — organització, empresa, investigació i educació

Qui: empreses, laboratoris i institucions que sol·liciten accés a nivell d'organització, condicions personalitzades o entrada a programes de recerca.

Verificar: verificació d'empreses des de 2,00 $ — consulta de registre, beneficiaris finals, directius, anàlisi d'entitats, a més d'una comprovació d'identitat vinculada per a cada beneficiari final.

Per què: "és aquesta una empresa real, i qui la controla realment" és una pregunta diferent de "és aquesta una persona real", i en aquest nivell és la correcta. També és el nivell on una entitat pantalla compra el major palanquejament per unitat d'esforç.

Cost: des de 2,00 $ per empresa; 0,20 $ per document; 0,20 $ per anàlisi d'entitat.

Què hauria de desencadenar una comprovació

Els nivells descriuen qui. Els desencadenants descriuen quan. Els millors dissenys de desencadenants s'activen amb les transicions i amb les proves, no amb el calendari.

Transicions d'accés. Augment de quota, concessió de crèdit, emissió de nova clau API, actualització de nivell, primer pagament, addició d'un membre de l'equip amb un abast elevat.

Alertes de comportament de la vostra pròpia capa de trànsit. Aquesta és la important. La vostra detecció semàntica —ja sigui un classificador intern o alguna cosa amb la forma de l'enfocament de màxima diferència mitjana a arXiv 2606.05725 — produeix un senyal que la infraestructura d'identitat no pot. Utilitzeu-lo com a desencadenant. La identitat és la resposta a aquesta alerta, no un substitut.

Senyals d'enllaç d'una verificació prèvia. Un compte el dispositiu del qual ja porta DEVICE_RECOVERED_HIGH_CONFIDENCE, o la cara del qual coincideix amb un usuari verificat existent, ha guanyat un pas endavant independentment del que estigui demanant.

Geografia de la política. IP_LOCATION_NOT_ALLOWED i COUNTRY_FROM_DOCUMENT_DOES_NOT_MATCH_COUNTRY_FROM_IP cobreixen restriccions jurisdiccionals on n'hi hagi.

Mai només per un temporitzador. Reverificar tothom trimestralment genera costos i fricció proporcionals a la vostra base d'usuaris i inversament proporcionals a res.

I per ser explícit sobre el límit: res d'això impedeix l'extracció de models. Una arquitectura d'accés verificat redueix l'anonimat, vincula els comptes a un sol actor i fa que els comptes regenerats siguin cars; no inspecciona les ordres i no us pot dir que un flux de sol·licituds s'assembla a la destil·lació. Els controls de sortida a nivell de model i la detecció de trànsit semàntic són capes separades que romanen dins de la vostra pròpia pila. Aquesta arquitectura fa que aquestes capes siguin més accionables; no substitueix cap de les dues.

Implementació

Un punt final de sessió, un flux de treball per política

Cada nivell de verificació és una sessió contra el mateix punt final. El flux de treball determina quines comprovacions s'executen.

curl -X POST 'https://verification.didit.me/v3/session/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "workflow_id": "YOUR_TIER2_WORKFLOW_ID",
    "vendor_data": "acct_8842",
    "callback": "https://yourplatform.example/verification/complete"
  }'

vendor_data és el vostre propi identificador de compte. Manteniu-lo estable en cada sessió per a aquest compte; és el que us permet correlacionar una reautenticació biomètrica posterior amb la verificació original, i és el que apareix a les coincidències de cerca facial perquè pugueu mapar els resultats directament als ID de compte.

La resposta inclou una URL de sessió a la qual redirigiu el desenvolupador, o podeu incrustar el flux directament amb els SDK web, iOS, Android, React Native o Flutter, tots gratuïts.

Les decisions arriben per webhook

Subscriviu-vos a session.status.updated i llegiu la decisió:

curl -X GET 'https://verification.didit.me/v3/session/{sessionId}/decision/' \
  -H 'x-api-key: YOUR_API_KEY'

La decisió inclou els resultats per funció i els codis d'advertència. Baseu-vos en les advertències en lloc de només en l'estat de nivell superior: una sessió pot ser aprovada i encara contenir DUPLICATED_DEVICE_FINGERPRINT, que és un senyal que voleu.

Composeu els nivells a l'Orquestrador de Fluxos de Treball

L'Orquestrador de Fluxos de Treball és gratuït i visual. Construïu un flux de treball per cada nivell, amb ramificació condicional perquè un únic flux de treball pugui escalar: comenceu amb l'anàlisi d'IP i dispositius, ramifiqueu-vos a la verificació completa de documents quan s'activa una advertència, ramifiqueu-vos a la verificació d'empreses quan el compte declara una organització. Canviar la política és un canvi a la consola, no un desplegament.

Mantingueu el camí de confiança ràpid

Aquí importen dos mecanismes.

El KYC reutilitzable és gratuït. Un desenvolupador que ja ha completat la verificació en un altre lloc de la xarxa Didit pot superar la vostra comprovació sense haver de repetir el flux de documents i selfies. Per a una audiència de desenvolupadors —que tendeix a incloure persones que ja s'han verificat abans—, això redueix materialment la fricció percebuda.

Llistes blanques. L'API de Llistes admet llistes blanques en els 12 tipus d'entrada. Els dispositius, rangs d'IP, entitats comercials i usuaris coneguts com a bons es poden afegir a la llista blanca perquè mai hagin de fer un pas addicional. IP_ADDRESS_IN_ALLOWLIST i DEVICE_FINGERPRINT_IN_ALLOWLIST s'emeten quan es produeix una coincidència, de manera que podeu confirmar que s'ha aplicat l'exempció.

Quant costa això a la pràctica

L'objectiu de la classificació per nivells és que les comprovacions costoses s'apliquin a una petita fracció dels comptes. Una plataforma amb 100.000 desenvolupadors registrats podria veure alguna cosa semblant a:

Nivell	Quota de comptes	Comprovació	Cost unitari
Gratuït	85%	cap, o correu electrònic a 0,03 $	0 $ – 0,03 $
Autoservei de pagament	12%	IP + dispositiu	0,03 $
Quota / crèdit alt	2,5%	paquet d'identitat complet	0,33 $
Organització / investigació	0,5%	verificació d'empreses	des de 2,00 $

Cada preu anterior és publicat, de pagament per èxit i no té mínims. Se us factura per les comprovacions reeixides, de manera que els fluxos abandonats no us costen. Les primeres 500 verificacions KYC cada mes són gratuïtes.

La distribució il·lustrativa no és un punt de referència; la vostra combinació variarà. El punt estructural es manté independentment: el nivell que costa més s'aplica a menys comptes, i el nivell que s'aplica a més comptes no costa res.

Casos d'ús

Proveïdors de models fronterers que limiten l'escalada de quotes i l'entrada a programes de recerca, deixant el nivell gratuït intacte.

Agregadors d'inferència i API que revenen l'accés a models i hereten l'abús sense ser propietaris dels controls a nivell de model; per a ells, la capa d'accés sol ser l'únic control que tenen de manera realista.

Productes d'IA per a codificació i agents que vinculen les concessions de crèdit i les extensions de prova a una persona verificada, ja que la creació massiva de crèdits i l'extracció comparteixen la mateixa mecànica.

Mercats d'IA al núvol que verifiquen l'entitat venedora i els seus beneficiaris finals abans de llistar-los.

Preguntes freqüents

On hauria de situar-se exactament el pas de verificació en el flux?

En el moment de la concessió de l'accés, no en la inscripció. Deixeu que el desenvolupador s'inscrigui, llegeixi la documentació, obtingui una clau i faci trucades reals. Demaneu la verificació quan demanin alguna cosa que impliqui un risc. La verificació en la inscripció converteix pitjor i protegeix menys.

Què passa amb un desenvolupador que es nega a verificar-se?

Aquesta és la vostra política, i la resposta honesta és que normalment no hauria de ser una prohibició. Manteniu-lo en el nivell per al qual es qualifica sense verificació. La negativa és un senyal, no un veredicte; molts desenvolupadors legítims simplement no volen lliurar un document per a un projecte d'afició, i haurien de poder seguir construint en un nivell on el seu accés no valgui gaire per a un atacant.

Pot funcionar això sense redirigir el desenvolupador a una pàgina allotjada?

Sí. Els SDK web, iOS, Android, React Native i Flutter incrusten el flux en el vostre propi producte, i la marca blanca (0,20 $) elimina completament la marca Didit. Tots els SDK són gratuïts.

Com evito verificar la mateixa persona dues vegades?

Utilitzeu un vendor_data estable per compte, i confieu en el KYC reutilitzable —gratuït— perquè un desenvolupador verificat en un altre lloc de la xarxa no repeteixi el flux. La cerca facial 1:N també us indica quan una nova verificació coincideix amb un usuari verificat existent, la qual cosa és un senyal de deduplicació i un senyal d'abús segons el context.

Didit veu les nostres ordres o el nostre trànsit?

No. Didit veu la sessió de verificació —document, selfie, senyals de dispositiu i de xarxa per a aquesta sessió— i res sobre el trànsit de la vostra API. La detecció semàntica roman completament dins de la vostra pila. El punt d'integració és que la vostra alerta es converteix en un desencadenant per a un pas de verificació.

Quant de temps triga tot el procés per al desenvolupador?

La verificació en si mateixa retorna en menys de dos segons un cop capturades les imatges. De principi a fi, un flux de document i selfie sol durar molt menys d'un minut, i el KYC reutilitzable és encara més ràpid.

Llest per començar?

Construïu l'estructura de nivells una vegada i ajusteu els llindars per sempre més tard.

• Llegiu la documentació — API de Sessions, Anàlisi d'IP i Dispositius, KYC Reutilitzable i l'API de Llistes per a llistes blanques.
• Vegeu el producte — Verificació d'Usuaris i Verificació d'Empreses.
• Consulteu els preus — cada mòdul té un preu públic, sense mínims.
• Comenceu gratuïtament — business.didit.me. Construïu el flux de treball, executeu 500 verificacions KYC al mes sense cost.