Cómo Elegir una API de OCR de Pasaporte: 9 Criterios de Evaluación

Todas las APIs de OCR de pasaporte prometen lo mismo: mandas una foto, recibes los datos. Las diferencias aparecen en producción, y para entonces ya migraste.

Esta es la lista de criterios con los que evaluarlas, y —más importante— cómo comprobar cada uno antes de comprometerte. No comparamos proveedores por nombre: los precios y las capacidades cambian cada trimestre, y una tabla de competidores envejece mal y suele ser injusta. Preferimos darte el método para hacer tu propia evaluación con datos de hoy.

1. ¿Valida los dígitos verificadores de la MRZ?

El criterio más importante, y el que menos se pregunta.

Un pasaporte trae cuatro dígitos verificadores que permiten comprobar aritméticamente que el número y las fechas se leyeron bien. Una API que no los valida está desechando la mejor señal de calidad que existe en el documento.

Cómo comprobarlo: manda un pasaporte y mira si la respuesta incluye las dos líneas MRZ completas. Si no las devuelve, no puedes verificar nada por tu cuenta — y probablemente el proveedor tampoco lo esté haciendo.

2. ¿Qué hace cuando no puede leer?

Hay dos comportamientos posibles, y la diferencia es enorme:

• Falla explícitamente — "no pude leer estos campos".
• Devuelve su mejor conjetura — datos con la forma correcta y el contenido equivocado.

El segundo es mucho peor de lo que parece, porque el error es invisible: un número de pasaporte con un carácter cambiado pasa cualquier validación de formato y llega intacto a tu base de datos.

Cómo comprobarlo: manda deliberadamente una foto mala —borrosa, con reflejo sobre la MRZ, con el pie recortado—. Si te devuelve datos completos y seguros de sí mismos, desconfía. Si te devuelve un error identificando los campos ilegibles, buena señal.

3. ¿Cobra por los fallos?

Consecuencia directa del anterior. Si el proveedor cobra por una extracción fallida, tiene un incentivo económico para devolver algo siempre.

Cómo comprobarlo: revisa qué pasa con tu saldo tras un fallo. En nuestro caso, un 422 LOW_IMAGE_QUALITY reembolsa el token: una imagen ilegible no cuesta.

4. ¿Cuánto retiene de los datos?

Un pasaporte es de los datos personales más sensibles que vas a mover. Pregunta explícitamente:

• ¿Se almacena la imagen? ¿Cuánto tiempo?
• ¿Se almacenan los datos extraídos?
• ¿Se usan para entrenar modelos?
• ¿En qué jurisdicción están los servidores?

Cómo comprobarlo: que esté por escrito en el contrato o en la política de privacidad, no en un correo. Nosotros no conservamos los datos de una extracción exitosa: se procesan, se devuelven y no quedan almacenados.

5. ¿Qué formatos y tamaños acepta?

Parece un detalle y decide integraciones enteras. En particular HEIC: es lo que produce un iPhone por defecto. Una API que no lo acepta te obliga a convertir del lado del cliente, con todo lo que eso implica.

Cómo comprobarlo: manda un HEIC sin convertir, y un archivo de 8 MB. Los límites reales aparecen rápido.

6. ¿Cómo se envía la imagen?

Multipart, base64, URL, binario directo. Cuantas más opciones, menos código de pegamento. Si tus imágenes ya viven en S3, poder mandar una URL evita descargarlas para reenviarlas.

7. ¿Los errores son manejables en código?

Busca códigos de error estables y documentados, no solo mensajes en prosa. Tu lógica de reintentos tiene que distinguir "reintenta en 2 segundos" de "esta imagen no va a mejorar nunca".

Cómo comprobarlo: pide la lista de códigos. Si la respuesta es "devolvemos un mensaje de error", tu manejo de errores acabará comparando cadenas de texto — que se romperá el día que reescriban un mensaje.

8. ¿Cuál es el modelo de precios real?

Compara sobre tu volumen real, no sobre el precio de lista:

• ¿Mensualidad mínima, o pago por uso?
• ¿Caducan los créditos?
• ¿Se cobran los fallos? (ver criterio 3)
• ¿Hay que hablar con ventas para empezar?

Ese último punto es un filtro práctico: si no puedes probar el servicio sin una llamada comercial, no puedes evaluarlo con tus propios documentos antes de decidir.

9. ¿Puedes probarlo hoy, con tus documentos?

El criterio decisivo. Toda la evaluación anterior depende de poder ejecutarla.

Busca: prueba sin tarjeta, documentación pública con ejemplos ejecutables, y a ser posible una demo que funcione sin registro.

Un método de evaluación en una tarde

1. Reúne 20 imágenes reales de tu propio flujo, incluidas las malas. Evaluar solo con fotos de estudio te dará una impresión que no se sostendrá en producción.
2. Añade tres casos límite a propósito: una con reflejo sobre la MRZ, una con el pie recortado, una de baja resolución.
3. Manda las 23 a cada candidato y registra: campos correctos, fallos honestos, y —lo que de verdad importa— datos incorrectos entregados con confianza.
4. Verifica por tu cuenta los dígitos de la MRZ devuelta. El algoritmo cabe en diez líneas y está en Dígitos verificadores ICAO 9303.
5. Cuenta el coste de los fallos en cada modelo de precios.

La métrica que decide no es el porcentaje de aciertos, sino:

De los casos que el sistema no pudo leer bien, ¿en cuántos lo dijo?

Un proveedor que acierta el 95 % y avisa en el 5 % restante es operativamente muy superior a uno que acierta el 97 % y entrega el 3 % restante como si fuera correcto. El primero te deja construir un flujo de excepciones; el segundo mete errores silenciosos en tu expediente.

Pruébanos con este método

No hace falta que nos creas: la demo gratuita procesa un pasaporte sin registro ni tarjeta, y al crear una cuenta tienes 20 extracciones para correr la evaluación completa con tus propios documentos. Nuestro validador MRZ es gratuito y te deja verificar por tu cuenta cualquier MRZ que te devolvamos.

La documentación lista todos los códigos de error, y Cómo integrar una API de OCR de pasaporte muestra el manejo de cada uno en código.