Una historia que se repite
No existen dos proveedores de software de gestión idénticos, pero su relación con el OCR interno sigue un patrón sorprendentemente constante. Un cliente pide poder subir una factura en lugar de volver a teclearla. Un ingeniero motivado construye un prototipo con una librería de código abierto en pocas semanas, sobre un conjunto de documentos limpios. El prototipo funciona, la petición queda marcada, todo el mundo pasa a otra cosa — hasta que el primer documento real, mal escaneado o de un formato nunca visto, revela que el verdadero trabajo empieza justo ahora.
Este artículo documenta esa trayectoria en detalle, no para decir que nunca haya que construir internamente, sino para dar a los equipos técnicos las mismas referencias que quienes ya han pasado por ahí — y evitarles redescubrir, dieciocho meses después, algo que era previsible desde el principio.
Cómo empieza, casi siempre de la misma forma
El primer módulo funciona bien porque se prueba con un conjunto de documentos elegidos a mano — facturas limpias, bien alineadas, sin fotos torcidas. Ese éxito inicial es real, pero oculta una realidad estadística: los documentos que ese módulo encontrará en producción no se parecerán a esa muestra cuidada. Una factura escaneada al revés, un extracto bancario de un banco nunca visto, un ticket de caja descolorido — cada uno de estos casos, tomado individualmente, parece marginal. Juntos, componen la mayoría del tráfico real en cuanto el producto supera unas pocas decenas de usuarios activos.
La meseta de precisión que nadie anticipa
Las primeras semanas de un proyecto de OCR interno producen ganancias de precisión rápidas y visibles — cada corrección arregla toda una clase de documentos mal leídos. Después la curva se aplana: los casos restantes son cada vez más específicos, cada vez más raros individualmente, y cada vez más caros de corregir uno a uno. Es el momento en que el presupuesto inicial, calculado sobre la velocidad de las primeras semanas, deja de corresponder a la realidad del proyecto.
Una cronología compuesta de dieciocho meses
| Periodo | Qué suele ocurrir |
|---|---|
| Meses 1-2 | Prototipo convincente sobre una muestra limpia, lanzamiento en producción |
| Meses 3-5 | Primeros avisos de clientes, correcciones puntuales sobre la marcha |
| Meses 6-9 | Un segundo ingeniero se suma al proyecto para absorber la carga de mantenimiento |
| Meses 10-14 | La meseta de precisión se vuelve visible, las correcciones cuestan cada vez más |
| Meses 15-18 | Se rehace el cálculo construir-o-comprar, a menudo bajo la presión de un formato nuevo crítico |
El coste oculto: el tiempo del equipo, no solo el salario
El cálculo más engañoso consiste en contar solo el salario del ingeniero que mantiene el módulo de OCR. El coste real incluye también las funcionalidades del producto principal que no se construyen durante ese tiempo, las decisiones técnicas tomadas para acomodar el motor interno en lugar de servir al producto, y el tiempo de gestión dedicado a priorizar entre corregir una extracción y entregar una funcionalidad pedida por los clientes.
Campo a campo, la comparación honesta
| Criterio | OCR interno | API especializada |
|---|---|---|
| Coste inicial | Alto, principalmente en tiempo de ingeniería | Bajo, tarifa por página desde el primer documento |
| Coste de mantenimiento | Continuo, creciente con la diversidad de documentos | Nulo de tu lado, absorbido por el proveedor |
| Generalización a nuevos formatos | Limitada a la muestra de entrenamiento disponible internamente | Se beneficia del volumen agregado de todos los clientes del proveedor |
| Control total | Completo | Compartido con un proveedor, como con cualquier servicio de terceros |
| Plazo hasta el primer módulo usable | Semanas a meses | Días |
Antes y después de una migración a una API
Antes
Un ingeniero dedicado, al menos parcialmente, al mantenimiento de la extracción; cada nuevo formato de documento temido en lugar de acogido como un caso más.
Después
Una tarifa por página que sigue el volumen, un equipo completamente reasignado al producto, y un nuevo formato de documento tratado por el proveedor sin intervención de tu lado.
La trampa del multiidioma y el multiformato
Un proveedor que vende únicamente en España puede retrasar este problema, pero rara vez evitarlo por completo: un cliente con una filial en el extranjero, un proveedor que factura en inglés, una tarjeta corporativa usada fuera de la zona euro — cada uno de estos casos añade una capa de complejidad que un modelo interno, entrenado sobre todo con documentos españoles, generaliza mal. Un proveedor especializado que ya trata esa diversidad sobre el conjunto de sus clientes absorbe este problema sin trabajo adicional de tu lado.
Nombrar con honestidad la dependencia de un proveedor
Migrar a una API externa crea una dependencia real, exactamente igual que depender de un proveedor de pagos, de alojamiento o de envío de correos — no es un riesgo que minimizar, sino un riesgo que evaluar con honestidad en lugar de ignorar bajo la excusa de que «construir internamente» suena más independiente. La pregunta pertinente no es «depender o no de un tercero», puesto que eso ya ocurre con la infraestructura, sino «¿es este proveedor en concreto fiable, transparente sobre su funcionamiento, y reemplazable si hiciera falta sin perder los datos ya procesados».
Cuándo construir internamente sigue siendo justificable
Un volumen muy alto, homogéneo, sobre un único formato de documento estable en el tiempo, cambia realmente el cálculo — es el caso de unos pocos actores muy grandes que procesan millones de documentos estrictamente idénticos cada mes. Para la gran mayoría de proveedores de software de gestión, cuyos clientes envían una variedad de documentos en formatos cambiantes, este escenario sigue siendo la excepción y no la regla.
Una decisión de eficiencia de capital que un consejo entiende
Presentada correctamente, esta elección no es una cuestión técnica sino una cuestión de asignación de capital: uno o dos ingenieros dedicados de forma continua a un problema ya resuelto en otro lugar, en lugar de al producto que genera la facturación. Es un argumento que una dirección financiera o un consejo de administración entiende de inmediato, a menudo más rápido que un argumento puramente técnico sobre la calidad de extracción.
La señal que indica que toca rehacer el cálculo
Un ticket de soporte recurrente sobre el mismo tipo de documento
Un formato que reaparece regularmente en los avisos de clientes indica un límite estructural, no un caso aislado.
Una hoja de ruta de producto que se retrasa por el mantenimiento del OCR
Cuando funcionalidades pedidas por los clientes se posponen para corregir la extracción, el coste de oportunidad se vuelve visible.
Dificultad para contratar o retener la competencia interna
Una competencia en visión por computador, escasa y cara, que no es el negocio principal del proveedor, es difícil de mantener motivada en este proyecto a largo plazo.
Un mercado nuevo o un idioma nuevo en la agenda
La expansión internacional suele ser el momento en que el cálculo construir-o-comprar se reconsidera más en serio.
Cómo transcurre concretamente una migración
La práctica más segura consiste en hacer funcionar el antiguo pipeline interno y la nueva API en paralelo sobre una muestra de documentos reales, comparar los campos extraídos por ambos sistemas, y después trasladar progresivamente el tráfico una vez confirmada favorablemente la diferencia de calidad. Ningún dato ya extraído necesita reprocesarse — solo los nuevos documentos toman el nuevo camino. El detalle paso a paso de este cambio está cubierto en la guía de integración.
Las objeciones más frecuentes, y por qué no suelen sostenerse
«Perdemos el control total»
El control total sobre un componente que no es el negocio principal tiene un coste real, raramente contrastado con el beneficio real que aporta.
«Nuestros documentos son demasiado específicos para un proveedor genérico»
Un proveedor que ya trata miles de formatos distintos probablemente ya se ha encontrado con una variante cercana a tu caso particular.
«Es más caro a largo plazo»
El cálculo casi siempre se invierte cuando el coste de mantenimiento interno, a menudo subestimado al principio, se contabiliza con honestidad.
«Ya hemos invertido demasiado tiempo para abandonar ahora»
El tiempo ya invertido es un coste hundido; la pregunta pertinente es el coste futuro, no el coste pasado.
El caso particular del mercado español
Un proveedor que vende exclusivamente en España añade una condición adicional al cálculo: el alojamiento y procesamiento de datos en la Unión Europea, que espera la mayoría de clientes profesionales y que a menudo se verifica explícitamente en una revisión de seguridad. Un pipeline interno alojado en España resuelve esta cuestión por construcción; un proveedor externo debe demostrarlo explícitamente — un punto que conviene verificar antes de cualquier migración, detallado en la página de seguridad.
A esto se suma, cada vez más, el contexto del SII y de Verifactu: un proveedor que ya cumple con la lectura fiable de documentos de origen tiene una base más sólida sobre la que construir el cumplimiento de estas obligaciones, frente a un pipeline interno cuya prioridad de mantenimiento rara vez fue pensada para acomodar requisitos normativos que llegaron después.
Qué hace un equipo una vez abandonado el OCR interno
El hallazgo más reportado tras una migración no es solo una bajada de coste, sino un cambio en la naturaleza del trabajo del equipo: los tickets relacionados con la extracción desaparecen de las prioridades semanales, y el tiempo liberado vuelve directamente hacia las funcionalidades que realmente diferencian el producto frente a la competencia — exactamente lo contrario de la situación que motivó la migración.
Un estudio de caso anonimizado, en detalle
Un proveedor español de software de gestión de alquileres, una treintena de empleados, construyó su módulo de lectura de recibos internamente al lanzar su producto, ante la falta de una alternativa satisfactoria en el mercado en aquel momento. El primer prototipo, sobre una muestra de documentos limpios aportados por el propio equipo, alcanzaba una exactitud convincente en pocas semanas — suficiente para presentarse como una funcionalidad diferenciadora en las demostraciones comerciales.
Doce meses después, el equipo técnico dedicaba aproximadamente un tercio del tiempo de un ingeniero senior al mantenimiento de ese módulo — corrección de casos particulares, incorporación de nuevos formatos de recibos encontrados con nuevos arrendadores, gestión de avisos de clientes. Ese tercio de tiempo, valorado en términos anuales, ya superaba con creces lo que habría costado una tarifa por página sobre el mismo volumen de documentos que el proveedor procesó ese año.
La migración, decidida tras este hallazgo, llevó tres semanas de funcionamiento en paralelo antes del cambio completo. El tiempo de ingeniería así liberado se redirigió hacia una funcionalidad de conciliación automática de alquileres que los clientes venían pidiendo desde varios trimestres sin que el equipo hubiera tenido nunca tiempo de dedicarse a ello en serio.
Lo que la deuda técnica cuesta en realidad
Un pipeline de OCR interno que envejece se comporta exactamente como cualquier otra deuda técnica: cada parche rápido para corregir un caso particular añade una capa de complejidad que el siguiente arreglo debe entender primero antes de poder actuar. Tras dieciocho meses de correcciones puntuales acumuladas, un ingeniero nuevo que se incorpora al equipo suele tardar más en entender por qué existe una regla concreta que lo que habría tardado en escribirla desde cero.
Esta deuda casi nunca se salda mediante una gran reescritura — el tiempo para justificarla nunca se considera prioritario frente a peticiones de clientes más visibles. Se resuelve, en la práctica observada en la mayoría de proveedores, mediante una sustitución completa del componente en lugar de una refactorización progresiva.
Las señales financieras que seguir trimestre a trimestre
| Indicador | Qué revela |
|---|---|
| Porcentaje de tiempo de ingeniería dedicado al OCR | Coste de oportunidad real frente al resto de la hoja de ruta |
| Número de tickets de soporte relacionados con la extracción | Carga de mantenimiento visible del lado del cliente |
| Plazo medio de corrección de un caso señalado | Fluidez o rigidez creciente del pipeline interno |
| Coste anual cargado del equipo dedicado | Punto de comparación directo con una tarifa por página |
Seguir estos cuatro indicadores trimestre a trimestre, en lugar de rehacer el cálculo una única vez en el lanzamiento del proyecto, permite detectar el punto de inflexión en el momento en que se produce, no dieciocho meses después en una revisión presupuestaria anual.
Cómo presentar este cambio a tus propios clientes
Un cliente que ya usa la funcionalidad de lectura de documentos normalmente no percibe ninguna diferencia visible durante una migración bien ejecutada — la interfaz sigue siendo la misma, solo cambia el motor que procesa los documentos por detrás. La comunicación más honesta consiste en no anunciar nada espectacular, pero vigilar de cerca los primeros avisos tras el cambio, para confirmar que la calidad percibida se mantiene al menos equivalente.
Para un cliente que pregunta explícitamente por el alojamiento o el proveedor técnico —cada vez más frecuente en una revisión de seguridad—, una respuesta transparente sobre la elección de un proveedor especializado, alojado en la Unión Europea, suele recibirse mejor que una afirmación vaga de control total que ya no correspondía a la realidad del pipeline interno envejecido.
Errores que evitar durante la transición
Trasladar todo el tráfico de golpe, sin fase paralela
Una regresión de calidad no detectada a tiempo afecta inmediatamente a todos los clientes en lugar de a una muestra controlada.
Infradimensionar el tiempo de comparación entre ambos sistemas
Una comparación demasiado rápida oculta diferencias que solo aparecen en formatos de documentos menos habituales.
No avisar al equipo de soporte del cambio en curso
Un soporte sorprendido por un aviso de cliente relacionado con la migración reacciona más despacio que un equipo informado de antemano.
Eliminar el pipeline interno antes de confirmar el cambio
Mantener el sistema antiguo disponible como respaldo unas semanas más cuesta poco y evita una marcha atrás precipitada.
El contexto de la contratación técnica en España
El mercado español de contratación técnica hace que el cálculo construir-o-comprar sea particularmente desfavorable para el OCR interno en la mayoría de proveedores de tamaño medio. Una competencia en visión por computador sigue siendo escasa y disputada, incluso por empresas mucho más grandes que pueden ofrecer condiciones difíciles de igualar para un equipo de producto para el que no deja de ser una pieza más entre otras. Perder esa competencia escasa —una salida, una oportunidad en otro sitio— suele dejar el módulo en un estado frágil, entendido por una sola persona, hasta la siguiente contratación.
Esta fragilidad organizativa, distinta del coste puro en euros, pesa igualmente en la decisión: un módulo mantenido por una sola persona, sin redundancia real en el equipo, representa un riesgo operativo que pocas direcciones técnicas elegirían conscientemente si el cálculo se les presentara con claridad desde el principio.
Qué hacen los proveedores que venden fuera de España
Un proveedor que vende únicamente en España puede, durante un tiempo, construir un modelo interno razonablemente generalizado sobre los formatos bancarios y las facturas españolas más habituales. En cuanto la expansión llega a Portugal, Latinoamérica u otros mercados europeos, la diversidad de formatos encontrados aumenta bruscamente, y el modelo interno, hasta entonces suficiente, revela sus límites en el peor momento posible — en mitad de un lanzamiento comercial en un país nuevo.
Los proveedores que ya han hecho esta expansión reportan casi unánimemente haber migrado a un proveedor externo en ese momento preciso, en lugar de haber intentado extender su modelo interno a nuevos formatos bajo la presión de un calendario comercial ya comprometido.
El motivo que más se repite en estos testimonios no es un fallo técnico del intento de extender el modelo interno, sino una renuncia deliberada ante el plazo que esa extensión habría requerido comparado con el de una integración de API ya rodada — una decisión de calendario más que un fallo constatado.
Un segundo motivo, expresado con menos frecuencia pero igual de real, tiene que ver con la dificultad de evaluar de antemano la calidad de un modelo interno extendido a un mercado nuevo antes de haberlo probado realmente con un volumen suficiente de documentos de ese mercado — un riesgo que un proveedor ya establecido en ese mismo mercado, con un historial verificable, permite evitar casi por completo.
Qué enseña este ciclo, más allá del OCR
El patrón descrito en este artículo —un prototipo rápido, una meseta de precisión, una carga de mantenimiento creciente, una migración final— no afecta solo al reconocimiento de documentos. Toca a cualquier componente técnico periférico que un equipo de producto construye por reflejo en lugar de por necesidad estratégica real. La pregunta que conviene hacerse sistemáticamente antes de construir un componente así no es solo «podemos hacerlo», sino «es este el mejor uso posible del escaso tiempo de ingeniería del que disponemos, comparado con un proveedor ya especializado exactamente en este problema».
Para el OCR de documentos financieros en particular, la respuesta se inclina cada vez más hacia la integración y no hacia la construcción, a medida que los proveedores especializados acumulan un volumen y una diversidad de documentos que ningún proveedor individual podría reproducir por sí solo internamente.
No es un juicio sobre la competencia técnica de los equipos que construyen internamente — muchos de esos pipelines funcionan realmente, en el sentido de que producen resultados utilizables. La pregunta nunca ha sido si funcionan, sino si el tiempo que siguen consumiendo cada mes sigue siendo el mejor uso posible de ese tiempo, comparado con lo que ese mismo tiempo podría producir en cualquier otro lugar del producto.
Cómo elegir el proveedor al que migrar
Una vez tomada la decisión de migrar, elegir mal el proveedor externo puede reproducir exactamente los mismos problemas de fondo, solo que ahora fuera de tu control directo. Cuatro criterios distinguen de forma bastante fiable un proveedor sólido de uno que revelará sus propios límites dieciocho meses más tarde, exactamente como ocurrió con el pipeline interno que se está abandonando: la transparencia sobre dónde y cómo se procesan los documentos, la posibilidad real de probar con tus propios documentos antes de comprometerte, una tarifa que sigue directamente el volumen sin escalones opacos, y un historial verificable con clientes de un perfil similar al tuyo.
| Criterio | Cómo verificarlo |
|---|---|
| Alojamiento y procesamiento de datos | Confirmación explícita de la Unión Europea, no una respuesta vaga sobre «servidores seguros» |
| Prueba con documentos reales | Una cuenta gratuita que acepta tus propios documentos, sin necesidad de una demo comercial guiada |
| Estructura de tarifas | Por página, publicada, sin negociación caso por caso ni escalón oculto |
| Historial verificable | Clientes de un volumen y un sector comparables, dispuestos a compartir su propia experiencia |
Un proveedor que se niega a que pruebes con tus propios documentos antes de firmar, o que no puede explicar con precisión dónde se alojan los datos, merece descartarse sin más consideración — independientemente de lo convincente que resulte el resto de su discurso comercial. El detalle completo de lo que conviene preguntar a cualquier proveedor está en la guía de integración.
Lo que cambia para el equipo de producto, no solo el de ingeniería
La conversación sobre construir o comprar un OCR se enmarca casi siempre en términos de ingeniería — coste de mantenimiento, precisión, tiempo de desarrollo. Pero el efecto más visible para un equipo de producto suele ser otro: la capacidad de prometer una fecha de entrega para una funcionalidad de lectura de documentos sin depender de la disponibilidad, siempre incierta cuando el problema es realmente difícil, de una competencia interna escasa en visión por computador.
Un responsable de producto que ya ha vivido esta transición describe a menudo el cambio más notable no como una mejora de precisión, sino como la posibilidad de planificar una hoja de ruta trimestral sin una casilla permanente de «mantenimiento del OCR» que absorbe una fracción impredecible del tiempo de ingeniería disponible cada trimestre. Esa previsibilidad recuperada tiene un valor que rara vez aparece en el cálculo de coste inicial, centrado casi siempre solo en el euro por página frente al salario cargado de un ingeniero.