Tarjetas de visita sin nube: PaddleOCR en React Native pasó de 7,8 a 3 segundos

Un escáner de tarjetas de visita parece una tarea de una tarde: se fotografía, se envía a una API y se obtienen el nombre y el teléfono. Pero la tarjeta no es suya, sino de un tercero. Su nombre, número y cargo llegan a un servidor sin que lo sepa, y en la práctica rusa esto choca con la ley 152-FZ. El equipo del que habla el autor de un artículo en Habr resolvió el problema de forma radical: la foto no sale nunca del teléfono.

Qué construyeron y por qué sin LLM

La pila es PaddleOCR v5, que se ejecuta mediante ONNX Runtime dentro de una aplicación de React Native para Android. Es decir, el modelo de reconocimiento reside en el dispositivo y no se necesita red para procesar la imagen.

El autor menciona expresamente que descartaron un LLM. El anuncio no da detalles, pero las razones suelen ser claras. Un modelo grande en el teléfono es pesado y lento. Si se llama en la nube, se vuelve al problema original: la foto sale del dispositivo. Para una tarjeta, donde solo hay que extraer unos pocos campos cortos, un OCR clásico más reglas de análisis suele ser más práctico. No es una conclusión del artículo, sino una pauta general de ingeniería, pero explica bien la elección.

Un ejemplo sencillo. El usuario fotografía una tarjeta, el OCR encuentra los bloques de texto y los lee, y la aplicación decide mediante plantillas cuál es el teléfono, cuál el correo y cuál el nombre. Todo ocurre en local y al final la persona ve una ficha de contacto rellenada.

De 7,8 a 3 segundos

La cifra más llamativa del anuncio: el procesamiento de la imagen se aceleró de 7,8 a 3 segundos. La diferencia es fundamental para el producto. Casi ocho segundos de espera tras la foto se perciben como una aplicación bloqueada. Tres segundos aún son tolerables, aunque lejos de una respuesta instantánea.

El anuncio no explica cómo se logró la aceleración; para los detalles habrá que ir al texto completo. Pero el OCR local en un teléfono tiene los lugares habituales de optimización: el tamaño de la imagen de entrada, el número de ejecuciones de modelos en la cadena, el formato de los pesos y la forma de pasar datos entre JavaScript y el código nativo. En React Native, este último suele ser el cuello de botella.

La telemetría oculta de ONNX Runtime

El detalle más útil para los profesionales no trata de velocidad, sino de privacidad. El autor escribe que ONNX Runtime envía algo a Microsoft por defecto. El anuncio no precisa qué exactamente ni en qué compilaciones, por lo que no se puede evaluar la magnitud real de la fuga. Pero la lección importa: la frase «el modelo funciona en local» no garantiza que la aplicación no use la red en absoluto.

Para un producto basado en el argumento de que «los datos no salen del dispositivo», esto es crítico. Si la política de privacidad promete una cosa y una biblioteca hace otra en silencio, se obtiene tanto un riesgo legal como una pérdida de confianza.

Qué hacer como desarrollador y responsable de producto

• Revise el tráfico de red de la aplicación en un dispositivo real, no solo el código. Un proxy como mitmproxy mostrará adónde van las solicitudes.
• Estudie los ajustes y las compilaciones de cada dependencia que maneje datos de usuario, sobre todo fotos y documentos. Desactive todo lo innecesario.
• Incluya la velocidad en las métricas del producto. El procesamiento local casi siempre es más lento que el de la nube, y la diferencia entre 7,8 y 3 segundos decide si se usará la función.
• No recurra a un LLM por defecto. Para una tarea acotada con estructura clara, un OCR ligero en el dispositivo puede ganar en privacidad, coste y previsibilidad.

Limitaciones

Solo vimos el anuncio: no incluye mediciones completas, modelos de teléfono, precisión de reconocimiento ni comparación con soluciones en la nube. Las cifras de 7,8 y 3 segundos corresponden a la configuración concreta del equipo y pueden variar en otro hardware. La interpretación jurídica de la ley 152-FZ también depende de cada caso, por lo que conviene consultarlo con un abogado.

Aun así, el caso muestra un camino viable: un perímetro de datos cerrado, un OCR abierto y maduro, y una comprobación cuidadosa de lo que hacen realmente las dependencias. Para los equipos que desarrollan aplicaciones con datos personales, es una buena lista de verificación para el próximo sprint.