Construir o comprar verificación de edad: los números, incluido el que juega en mi contra

Las tres rutas (y cuál merece números)

Cuando alguien evalúa montar verificación de edad EUDI en casa, casi siempre se costea el escenario equivocado: implementar OID4VP desde cero, contra la especificación, con criptografía propia. Nadie en su sano juicio hace eso, así que el argumento "construir es dificilísimo" se cae solo — y quien lo usa para venderte algo te está tratando de tonto.

Las rutas reales son tres:

• Desde cero. Descartada en el párrafo anterior.
• Autoalojado sobre un motor precontruido. La ruta de construir de verdad. Tiene dos sabores: motores open source (hay varios en el ecosistema; el que conocemos de primera mano es EUDIPLO, Apache 2.0, en los labs de la OpenWallet Foundation — espuni corre sobre él) y stacks licenciados, que mueven parte del mantenimiento al vendor a cambio de una licencia y de lock-in propietario. El licenciado es, en realidad, un híbrido: se parece más a comprar de lo que su comprador suele creer, pero sin la cláusula de salida que veremos al final.
• Servicio gestionado. Comprar.

Este artículo costea la segunda ruta con honestidad — incluido el break-even a partir del cual construir gana y comprar (por ejemplo, a nosotros) deja de tener sentido. Y un aviso importante: como vas a ver, casi nada de la cuenta depende de qué motor elijas. Uso EUDIPLO como ejemplo trabajado porque sus semanas son las que ese camino nos costó a nosotros — dato vivido, no estimación de folleto.

Lo que cuesta construir: el escenario honesto

Supongamos el caso favorable: un desarrollador senior que ya conoce OID4VP. No es el caso común — si nadie en el equipo ha tocado el ecosistema, añade 4 a 6 semanas al total — pero es el escenario que menos me conviene y por eso es el que uso.

• Entender el AV Profile, DCQL, mso_mdoc, ISO 18013-5/7 — 2 a 4 semanas
• Desplegar y configurar el motor elegido — 1 a 2 semanas
• Integración con el backend propio (sesiones, webhooks, estados) — 2 a 3 semanas
• Trusted List: parsing, cadenas de certificados, caché, refresh — 1 a 2 semanas
• Frontend: QR, deep link, DC API, fallbacks, cross-device — 2 semanas
• Testing contra carteras reales — 1 a 2 semanas

Total: 9 a 14 semanas. A coste total de empresa de un senior en Europa (entre 5.000 y 7.500 € al mes), eso son entre 12.000 y 25.000 € de coste único. La infraestructura es ruido al lado: 600 a 2.400 € al año.

Fíjate en un detalle: de toda la lista, la única línea que depende del motor que elijas es la segunda. Las demás — entender el perfil, integrar con tu negocio, operar Trusted Lists, pelear los fallbacks del frontend, probar contra carteras reales — son tuyas elijas lo que elijas. Por eso da casi igual qué motor pongas en la casilla: la objeción "yo usaría otro motor" no mueve la cuenta.

Hay otro detalle honesto que contar aquí: hoy no existe el motor "solo AV". O despliegas un motor generalista de credenciales para consultar un único claim — complejidad que no usas pero sí operas —, o eliges una pieza mínima y el pegamento que le falta pasa a ser código tuyo. En ambos casos, el coste acaba en la misma lista de arriba.

Hasta aquí, construir parece razonable. El problema no está en esta lista.

El coste que nadie presupuesta

La integración inicial es la parte visible. La invisible es que el ecosistema sobre el que acabas de construir no se está quieto:

• El Age Verification Blueprint evoluciona; la v2 traerá cambios.
• ISO 18013-7 sigue en draft, y la Digital Credentials API de los navegadores cambia de forma mientras se estandariza.
• Cada Estado miembro despliega su cartera con sus propias rarezas. Ya lo conté con AltID: la cartera danesa rechazaba de plano peticiones que la implementación de referencia aceptaba sin pestañear — validación estricta de esquema, sin DC API en v1, su propio formato de QR. Hay siete front-runners más en camino, cada uno con su lectura de la misma spec.
• Las Trusted Lists rotan certificados, y tu validación de emisores tiene que seguirles el ritmo.

Nada de esto es hipotético; es la lista de lo que ya ha cambiado en los últimos meses. Mantener un verifier interoperable con esto en movimiento cuesta, siendo conservador, 0,2 a 0,3 FTE de forma continua: entre 12.000 y 27.000 € al año, para siempre. No es un proyecto; es una línea permanente de presupuesto. Y es la línea que no aparece en ningún business case de "lo montamos en un sprint". (En el sabor licenciado, parte de esta línea se convierte en cuota de licencia — cambia de nombre, no desaparece.)

El break-even, encima de la mesa

Con esos dos números, la cuenta es una división:

break-even (verif/año) = coste interno anual ÷ precio por verificación

Con 25.000 € al año de coste interno de mantenimiento y un servicio gestionado en la banda de los céntimos bajos por verificación, el punto de equilibrio queda en el orden de medio millón de verificaciones al año — unas 40.000 al mes, arriba o abajo según dónde caiga el precio dentro de esa banda.

Ese número juega en mi contra y lo publico igual: por encima de ~40.000 verificaciones al mes, construir sobre un motor open source te sale a cuenta si tienes el equipo y quieres ese trabajo en tu backlog. No te diré lo contrario.

Por debajo, la asimetría es brutal. Una plataforma con 5.000 verificaciones al mes paga en un servicio gestionado unos pocos miles de euros al año, como mucho — contra 25.000 € o más solo el primer año de construirlo. Más de diez veces más caro construir. Y no es casualidad que el umbral caiga donde viven las integraciones más grandes: a ese volumen, la conversación es otra.

La objeción del CFO: CapEx contra OpEx

Hay una objeción financiera legítima: construir es pagar una vez, un servicio es pagar para siempre, y hay CFOs que prefieren lo primero por principio. La respuesta honesta es que construir no es pagar una vez. Es pagar una vez la integración más una fracción de una persona indefinidamente — la sección anterior. Si el business case interno solo contiene la primera mitad, no está mal calculado: está incompleto.

"Pero el motor ya existe y es gratis"

Es verdad, y es el mejor argumento del lado de construir — por eso este artículo lo usa como base en lugar de esconderlo. Un equipo competente levanta EUDIPLO, o cualquiera de sus alternativas, en cuestión de días.

Pero el motor es el motor, no el coche. No trae la capa de metering y sesiones sobre tu negocio, ni el frontend con todos los fallbacks que las carteras reales exigen, ni la operación de Trusted Lists, ni — sobre todo — a alguien cuyo trabajo sea seguir la especificación por ti mientras siete Estados sacan siete carteras con siete comportamientos distintos. El motor es el 70% del trabajo. El coche es casi todo lo demás.

El riesgo de proveedor, también encima de la mesa

Si estás evaluando comprar, hay una pregunta incómoda que deberías hacerle a cualquier proveedor, incluido yo: ¿qué pasa si desapareces? Tu cumplimiento del Artículo 28 del DSA no puede depender de que a tu proveedor le vaya bien.

Nuestra respuesta no es una promesa sino estructural: espuni está construido sobre el mismo EUDIPLO open source que podrías desplegar tú. Si mañana no existimos, despliegas EUDIPLO, apuntas tu integración y sigues operando — con el coste de mantenimiento de este artículo, pero sin rescribir nada. Es exactamente la cláusula de salida que un stack propietario no puede ofrecerte, y la razón por la que construir-sobre-open- source no es solo una decisión técnica nuestra: es la mitigación de tu riesgo, no del nuestro.

Lo que compras hoy no es donde acaba

Una cosa más que cambia la cuenta a varios años vista. La verificación de edad no es un sistema aparte: corre sobre los mismos raíles que todo el ecosistema de la cartera de identidad europea — OID4VP, credenciales mdoc, Trusted Lists. Es, deliberadamente, el primer caso de uso de esa infraestructura que llega a producción.

Eso significa que la decisión de hoy no es solo "AV sí o no". El ecosistema EUDI va a ir añadiendo tipos de credencial — atributos de identidad, carné de conducir, lo que cada Estado vaya emitiendo — y cada uno traerá sus propios cambios de paradigma, como AV está trayendo los suyos. Quien construye en casa vuelve a la lista de tareas de arriba con cada uno. Nuestro servicio está construido sobre esos raíles comunes precisamente para crecer con ellos: la integración que hoy verifica edad es la misma API con la que iremos soportando lo que venga, y los cambios del ecosistema se asimilan al otro lado de esa API, progresivamente, sin que cada salto sea un proyecto tuyo. Integrarse temprano con AV es, en la práctica, entrar en la cartera europea por la puerta pequeña — y no volver a pasar por la grande.

La conclusión práctica

Podrías montar tu propia pasarela de SMS; nadie lo hace, y no porque sea imposible. La pregunta correcta nunca fue "¿podemos construirlo?" — sobre un motor precontruido la respuesta es sí, en un trimestre. La pregunta es si quieres ser propietario de este problema para siempre.

El valor de comprar no está en la integración inicial: está en no tener nunca este tema en el backlog. En que cuando el siguiente Estado miembro saque su cartera y algo se rompa — y se romperá, porque ya ha pasado — el sprint que se rompe no sea el tuyo.

Y si mueves más de 40.000 verificaciones al mes: los números de arriba son tuyos, úsalos. Son los mismos que usaría yo.

---

Las cifras de este artículo son estimaciones propias basadas en costes de mercado europeos y en la experiencia de construir espuni sobre EUDIPLO (OpenWallet Foundation Labs, Apache 2.0); el desglose de tareas refleja el trabajo real descrito en artículos anteriores de esta serie, incluidas las pruebas contra el entorno de test de AltID. Nada de lo aquí expuesto refleja interioridades de los sistemas de ningún empleador; todas las fuentes enlazadas son públicas.