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

Zero-knowledge está escapando del sandbox de crypto. La tecnología que te permite probar una afirmación sin revelar los datos subyacentes es ahora una herramienta de integración viable para KYC, verificación de edad, procedencia de supply-chain, checks de credenciales y ML confidencial. El listón es más bajo de lo que era hace tres años. El tooling es real. El paisaje de auditoría es más delgado que el de crypto, pero existe. Este post cubre seis casos de uso concretos no-crypto que Wavect ha dimensionado o construido, con bandas de coste, ratings de complejidad y el Q&A honesto sobre si vale la pena para tu equipo.

¿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. Los estándares son maduros; el lado del issuer es 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 el panorama de coste entre los seis?

"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 mucho del tamaño del circuito y el prover. Para circuitos pequeños estilo KYC, la generación de pruebas corre en unos pocos cientos de milisegundos en un laptop moderno o en el navegador vía wasm. Para circuitos multi-attestation complejos, espera segundos. Para zkML, espera decenas de segundos a minutos. La verificación es siempre barata, típicamente sub-100ms. Planifica el UX alrededor del lado del prover, no del lado del verifier.

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

Para los casos de uso 1, 2, 4 y 6, sí, con cuidado. El tooling (Circom, Noir, Halo2, plonky2, zkVMs recientes) ha madurado al punto de que un ingeniero senior fuerte con unas pocas semanas de ramp-up enfocado puede lanzar un circuito en producción. Para los casos de uso 3 y 5, no. Quieres un especialista en criptografía en el equipo o como reviewer externo, más una auditoría externa adecuada. Traemos especialistas de dominio cuando se necesita. Ver nuestro servicio de zero-knowledge para ver cómo funciona eso.

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

Combinación fuerte. Las wallets AA pueden verificar pruebas ZK on-chain o off-chain como parte de su lógica de firma. Eso desbloquea flujos como "esta wallet solo puede transaccionar si se adjunta una prueba fresca de verificación de edad". Para productos web3 con bases de usuarios reguladas, este se está volviendo un patrón estándar en 2026.

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.