Zero-Knowledge Proofs Fuera de Crypto: KYC, Verificación de Edad, Supply Chain

Zero-knowledge es una opción real para determinados flujos de KYC, edad, supply-chain, credenciales y ML verificable. La preparación para producción depende de la afirmación, issuer, hardware y superficie de auditoría. Las bandas de coste son estimaciones de planificación de Wavect, no benchmarks ni presupuestos fijos.

¿Qué resuelve realmente ZK para productos no-crypto?

Una frase: probar un hecho sobre datos privados sin revelar los datos. Eso mapea a un número sorprendente de problemas de compliance y privacidad que los reguladores han estado empujando con más fuerza desde 2024. Puertas de edad, checks de residencia UE, procedencia de supply-chain, verificación de credenciales, inferencia de ML privada. Todos estos solían resolverse entregando el documento subyacente o confiando en un attester centralizado. ZK te da una tercera opción.

Caso de uso 1: KYC preservando privacidad

El problema. Tu producto necesita saber que un usuario es mayor de 18 y residente UE. No necesita saber su fecha de nacimiento, dirección postal o número de pasaporte. Almacenar esos datos es un pasivo bajo GDPR y un objetivo tentador para atacantes.

La tech ZK que encaja. zk-SNARKs sobre una verifiable credential firmada por la wallet gubernamental del usuario o un attestation provider. Groth16 o PLONK dependiendo de la complejidad del circuito. El despliegue de la wallet eIDAS 2.0 a través de la UE está haciendo el lado de attestation cada vez más viable en 2026.

Complejidad. Media. El circuito es pequeño. La integración con attestation providers es el trabajo real.

Banda de coste. Semanas de ingeniería: 4 a 8 para una integración en producción. Coste de infra del verifier: insignificante. Coste de auditoría: engagement separado con una firma especialista en ZK.

Caso de uso 2: Verificación de edad para contenido regulado

El problema. Las reglas UE sobre verificación de edad para contenido adulto, juego y ciertas categorías de contenido regulado se endurecieron en 2024 y 2025. La auto-declaración ya no es compliant en varias jurisdicciones. Subir un pasaporte es un desastre de UX y un riesgo de protección de datos.

La tech ZK que encaja. Un circuito pequeño que prueba "año de nacimiento es en o antes de X" desde una credencial emitida por el gobierno. Los zk-SNARKs suelen ser overkill aquí; un circuito con scope ajustado con un attester conocido te da pruebas rápidas y verifiers pequeños.

Complejidad. Baja a media, mayormente baja una vez que se elige la fuente de attestation.

Banda de coste. 3 a 6 semanas de ingeniería para un launch de una sola jurisdicción.

Caso de uso 3: Procedencia de supply-chain

El problema. Necesitas probar que tu envío pasó por etapas certificadas (origen, procesamiento, envío, aduanas) sin revelar tus proveedores específicos, rutas comerciales o términos comerciales a la competencia o counterparties.

La tech ZK que encaja. zk-STARKs por transparencia (sin trusted setup) y resistencia post-cuántica, o SNARKs recursivos si el tamaño de la prueba importa más que el tiempo de prover. Las pruebas se agregan a través de etapas; solo el verifier final ve el resultado.

Complejidad. Alta. La parte dura es el modelo de datos, no la criptografía. Conseguir que los proveedores hagan attestation es el workstream.

Banda de coste. 8 a 16 semanas de ingeniería para un piloto cubriendo una línea de producto.

Caso de uso 4: Credenciales privadas

El problema. Una plataforma quiere verificar "este usuario tiene un título de una universidad acreditada" o "este usuario es un profesional con licencia" sin almacenar o revelar el documento completo.

La tech ZK que encaja. Verifiable credentials más una prueba ZK de selective-disclosure. Los zk-SNARKs funcionan bien aquí. Estándares como W3C VC y firmas BBS+ se emparejan naturalmente.

Complejidad. Media. VC Data Model 2.0 es una Recomendación, pero la cryptosuite BBS seguía como Candidate Recommendation Draft en abril de 2026. Issuer, revocación e interoperabilidad son la fricción.

Banda de coste. 4 a 10 semanas de ingeniería dependiendo de las integraciones de issuer.

Caso de uso 5: Inferencia de ML confidencial

El problema. Un usuario quiere correr un modelo sobre input privado y confiar en que se usó el modelo correcto, sin revelar el input al host del modelo ni los pesos del modelo al usuario.

La tech ZK que encaja. Frameworks zkML. Este es la frontera de la lista. La generación de pruebas es pesada. Usa casos donde una prueba de 30 segundos a varios minutos sea aceptable.

Complejidad. Alta. Enmarcado honesto: esto sigue siendo bleeding edge en 2026. Ver nuestro servicio bleeding-edge para ver cómo enfocamos este tipo de riesgo.

Banda de coste. 12 a 24 semanas de ingeniería para un piloto vertical estrecho.

Caso de uso 6: Selective disclosure de identidad descentralizada

El problema. Un usuario tiene una wallet que contiene varias credenciales. La relying party debería aprender solo el atributo específico que necesita (residencia, profesión, rango de edad), nada más.

La tech ZK que encaja. Firmas BBS+ con selective disclosure, más una prueba opcional de predicado ZK para atributos derivados. Funciona limpiamente con wallets de account abstraction del lado EVM.

Complejidad. Media.

Banda de coste. 5 a 10 semanas de ingeniería.

¿Cómo se ve la planificación entre los seis?

Las semanas son estimaciones de Wavect para un primer release estrecho. Auditoría, onboarding del issuer, certificación, legal e infraestructura de proving van aparte.

"ZK finalmente se está convirtiendo en una herramienta de integración, no un proyecto de research solo-crypto."

Q&A: ¿es ZK overkill para KYC?

Para algunos equipos, sí. Si puedes pasar el KYC a un provider regulado y no almacenas los datos tú mismo, ya tienes una respuesta aceptable para la mayoría de jurisdicciones. ZK se vuelve atractivo cuando (a) quieres verificaciones repetidas sin volver a preguntarle al usuario, (b) operas en una jurisdicción donde el flow de wallet eIDAS 2.0 está vivo y los usuarios lo esperan, o (c) el coste de un breach de tu base de datos KYC es existencial. Si cualquiera de esos aplica, ZK se paga solo rápido.

Q&A: ¿cuánto tarda realmente la generación de pruebas?

Depende del circuito, sistema, implementación, hardware, memoria, wrapper y runtime. Mopro publica desde cientos de milisegundos hasta muchos segundos; algunas verificaciones Halo2 superan 100 ms y circuitos grandes alcanzan segundos o fallan en memoria móvil. Mide prover y verifier en los dispositivos objetivo.

Q&A: ¿puede un equipo pequeño construir esto sin un criptógrafo?

Un equipo pequeño puede integrar un protocolo o SDK auditado. Escribir o cambiar un circuito de producción exige otro nivel de assurance. Unas semanas de ramp-up no sustituyen revisión de protocolo, tests, fuzzing, version pinning y auditoría independiente.

Q&A: ¿qué pasa con account abstraction y ZK juntos?

Se pueden combinar: una wallet AA puede exigir una credencial o prueba fresca en su política. Es útil, pero no es un estándar universal y añade requisitos de recovery, revocación, replay, privacidad y upgrades.

Q&A: ¿los smart contracts necesitan estar involucrados en absoluto?

No. ZK funciona bien totalmente off-chain. Un backend web2 regular puede verificar un SNARK o STARK con una pequeña librería. La cadena solo se necesita si quieres verificación pública, resistente a censura o composabilidad con lógica on-chain. La mayoría de los deployments de KYC y verificación de edad que hemos dimensionado son puramente off-chain.

Para profundizar: nuestra guía pragmática para construir con ZK y FHE cubre el framework de decisión y los modos de fallo, el post sobre el estado del arte de ZK en 2026 lleva los benchmarks actuales de zkVMs y los costes de proving, y ZK vs FHE vs MPC vs TEE compara las alternativas.

Fuentes y verificación

1. European Commission (2026). European Digital Identity and the end-of-2026 wallet availability deadline. commission.europa.eu
2. European Commission (2026). EU age-verification blueprint and implementation status. digital-strategy.ec.europa.eu
3. W3C (2025). Verifiable Credentials Data Model 2.0. w3.org
4. W3C (2026). Data Integrity BBS Cryptosuites v1.0, Candidate Recommendation Draft. w3.org
5. Mopro (2026). Mobile and browser proof-generation and verification benchmarks. zkmopro.org
6. Lagrange (2026). DeepProve open-source release and vendor-reported zkML results. lagrange.dev