Cuando un proyecto de inteligencia artificial fracasa en una pyme, casi nunca es porque el modelo no fuera capaz. Es porque el dato estaba en un ERP de 2011 sin API, porque nadie sabía quién era el propietario del proceso, o porque la salida del modelo era correcta pero no tenía dónde aterrizar y acabó en un Excel que revisaba una persona a mano.
El modelo es la parte comprada: la pieza comoditizada, que funciona razonablemente bien de serie y que se puede sustituir en unas horas. Todo lo demás —de dónde sale el dato, cómo llega, dónde aterriza el resultado, qué pasa cuando algo falla a las tres de la mañana— es lo que hay que construir y lo que decide si el proyecto vive o muere. Este artículo va de esa parte: no de qué modelo elegir, sino de cómo conectarlo con lo que ya tienes sin romper el sistema que sostiene tu facturación.
Por qué la integración es casi todo el trabajo
Elegir el modelo y ajustar el pipeline de inferencia ocupa una fracción pequeña del calendario. El resto es fontanería: conseguir acceso a los sistemas, entender esquemas que nadie documentó, negociar permisos y montar la operativa para que funcione todos los días sin supervisión. Hay tres razones estructurales.
El modelo es sustituible y el resto no. Cambiar de proveedor de inferencia es una modificación acotada; cambiar de dónde lees los albaranes te obliga a rehacer medio proyecto. Lo caro es lo específico de tu empresa.
Los sistemas de gestión de una pyme rara vez se diseñaron para que otro programa los consulte, sino para que una persona introdujese datos por una pantalla. El acceso programático, cuando existe, es un añadido posterior y mal documentado.
El dato real casi nunca está donde dice el organigrama. El ERP tiene la versión oficial del pedido, pero la condición pactada con ese cliente está en un correo, y la excepción que hace que se sirva distinto vive en la cabeza de quien lleva veinte años en administración.
Regla práctica: si al planificar un proyecto de IA la mayor parte del calendario no está dedicada a integración, datos y operativa, la planificación está mal hecha y el desajuste aparecerá con el presupuesto ya comprometido.
El inventario que hay que hacer antes de nada
Antes de escribir código o probar un modelo hay que levantar un mapa: determina si el caso de uso es viable y cuánto va a costar. Son cuatro preguntas.
¿Qué sistemas hay realmente?
No los del contrato de mantenimiento: todos. El ERP, la contabilidad, el CRM, el gestor documental, el correo, la carpeta de los escaneos y la hoja de cálculo del jefe de almacén que resulta ser la fuente de verdad de las existencias. En una pyme salen entre seis y quince, y al menos dos son sorpresas. De cada uno: qué proceso soporta, quién lo administra, versión y si tiene soporte vivo. A un sistema sin soporte nadie te arreglará la API cuando se rompa.
¿Cuáles tienen acceso programático?
Hay que verificarlo, no suponerlo: pedir credenciales, hacer una llamada real y ver qué devuelve. Una API que existe en el PDF comercial pero no responde no es una API. Por sistema: si hay API documentada; si la licencia la incluye o es un módulo aparte que hay que comprar (caso frecuente); si se puede acceder a la base de datos, con qué permisos y sin perder el soporte; y si admite exportaciones programadas.
¿Dónde vive el dato de verdad?
Un mismo concepto suele estar en varios sitios con valores distintos: el precio de un artículo puede estar en el ERP, en la tarifa enviada por correo y en el catálogo de la web, y los tres discrepar. Hay que decidir por escrito cuál es la fuente autoritativa de cada dato que toca el proceso. Si la respuesta honesta es "depende", ese dato no está listo: has descubierto un problema de gobierno del dato que existía antes de la IA y que la IA no va a resolver.
¿Quién es el propietario del proceso?
Quien puede decidir que a partir del lunes las facturas se clasifican de otra manera, y cuya decisión acatan los demás. No el director general por defecto ni el responsable de sistemas: quien tiene autoridad funcional real sobre ese flujo. Sin propietario, nadie aprueba los criterios ni defiende el cambio ante los usuarios. Es el mismo vacío que hace fracasar la validación de un caso de uso, tratada en el framework de validación en 4 semanas.
Si el dato clave solo existe en un sistema sin acceso programático, sin soporte y sin propietario funcional claro, el problema del proyecto no es de IA. Resolver eso primero es más barato que descubrirlo a mitad de la implantación.
Las cuatro vías de integración
Cada sistema del inventario cae en una de cuatro categorías, de mejor a peor. La peor sigue siendo mejor que no hacer nada, y un proyecto real suele combinar dos o tres.
1. API documentada: la buena
El sistema expone endpoints documentados y el fabricante mantiene compatibilidad. Es la vía que hay que buscar primero: el contrato es explícito, los errores son códigos interpretables y al escribir se aplican las validaciones de negocio del propio sistema.
Cuidados: los límites de peticiones (importan en el lote de fin de mes), la renovación de credenciales y comprobar antes que la API cubre la operación que necesitas. Muchas permiten leer casi todo y escribir casi nada.
2. Lectura directa de base de datos: frágil pero viable
Cuando no hay API pero sí acceso a la base de datos. Es más común de lo que a nadie le gusta admitir, pero el esquema es un detalle interno del fabricante, no un contrato: una actualización menor puede renombrar una columna y romperlo todo sin aviso.
Tres reglas: usuario de solo lectura, siempre —escribir en las tablas de un ERP salta sus validaciones de negocio y corrompe datos de formas que tardas meses en detectar—; consultar contra una vista propia que aísle los nombres de tabla; y verificar el esquema automáticamente al arrancar.
3. Exportación programada de ficheros: fea y sorprendentemente robusta
El sistema deja cada noche un CSV o un XML en una carpeta y tu proceso lo lee. Estéticamente es de los años noventa; operativamente es de lo más fiable que hay, porque desacopla: si tu proceso se cae, los ficheros se acumulan y los recuperas al arrancar, y si el ERP se cae, tú sigues.
Sus límites: la latencia es la del ciclo de exportación —si el fichero sale a las 22:00, no hay tiempo real— y la vuelta es complicada, porque exportar es fácil pero importar muchas veces no. Un detalle evita disgustos: escribir con nombre temporal y renombrar al terminar, para no leer exportaciones a medias.
4. Automatización de interfaz o RPA: último recurso
Un programa que abre la aplicación y hace clic y teclea igual que lo haría una persona. Se recurre a esto cuando no hay API, ni base de datos accesible, ni exportación posible.
A veces es la única opción, pero es la más cara a lo largo del tiempo por un motivo estructural: depende de que la pantalla no cambie. Un botón que se mueve o una actualización que reordena las pestañas rompen el flujo, y el mantenimiento pasa de coste eventual a goteo constante. Además los errores son mudos: una API devuelve un 409; un robot de interfaz se queda esperando ante un diálogo inesperado. Si acabas aquí, trátalo como deuda técnica declarada.
Comparativa
| Vía | Esfuerzo inicial | Fragilidad | Mantenimiento | Permite escribir |
|---|---|---|---|---|
| API documentada | Medio | Baja | Bajo | Sí, con validaciones del sistema |
| BD en solo lectura | Bajo-medio | Media-alta | Medio (revisar en cada actualización) | No |
| Exportación de ficheros | Bajo | Baja | Bajo | Solo si admite importación |
| RPA / interfaz | Alto | Muy alta (depende de la UI) | Alto y constante | Sí, con la fragilidad del método |
Lectura y escritura no tienen por qué usar el mismo canal. Un patrón que funciona muy bien en pymes: leer por la vía más robusta disponible (ficheros o base de datos en solo lectura) y escribir solo por API, o dejando el resultado en una bandeja que alguien aprueba.
El patrón que funciona: una capa intermedia
La tentación, si el ERP admite desarrollo a medida, es meter la IA dentro del sistema heredado. Es un error caro: acopla dos cosas que evolucionan a velocidades muy distintas —el ERP cambia cada varios años, el componente de IA varias veces en un trimestre— y el día que cambies de ERP o de modelo rehaces todo.
El patrón que aguanta es un servicio propio en medio, con su código, su almacenamiento y su registro, que hace tres cosas: lee de cada origen por la vía que le corresponda, procesa (normaliza, llama al modelo, aplica reglas de negocio y decide qué hacer con los casos de baja confianza) y escribe el resultado en el destino, o lo deja en una cola de revisión. Las ventajas:
- El sistema heredado no se toca. No pones en riesgo lo que sostiene la facturación, y el fabricante no puede alegar que has modificado su producto.
- El modelo es reemplazable. Cambiarlo afecta a un módulo, no al proyecto.
- Cada origen queda aislado. Si mañana el ERP incorpora una API, cambias el adaptador de lectura y el resto sigue igual.
No tiene por qué ser grande: en la mayoría de pymes es un servicio modesto desplegado en un contenedor. Lo importante es que sea tuyo y esté separado. Es la misma lógica del análisis entre software a medida, SaaS y low-code: lo específico de tu negocio tiene que vivir en código que controlas.
Tres ejemplos con la misma forma: leer, procesar, decidir, escribir o escalar
Facturas en PDF volcadas a contabilidad. La capa extrae proveedor, NIF, fecha, base, tipo de IVA y total; verifica que el total cuadra con la suma de líneas y que el proveedor existe en el maestro; y solo entonces propone el asiento. Lo que no cuadra va a revisión.
Correos entrantes convertidos en tareas. La capa clasifica cada correo (incidencia, pedido, consulta comercial), extrae los datos y crea la tarea. Los ambiguos y los que mencionan cancelaciones o reclamaciones se marcan para revisión.
Albaranes cruzados con pedidos. Dos exportaciones nocturnas. La capa empareja líneas, detecta discrepancias de cantidad, referencia o precio y genera un informe de excepciones.
Cambia el dominio, no la arquitectura.
Idempotencia, reintentos y trazabilidad
Aquí está la diferencia entre un piloto que impresiona en una demo y algo que aguanta dos años en producción. Tres propiedades, ninguna opcional.
Idempotencia: toda escritura debe poder repetirse
Idempotente significa que ejecutar la misma operación dos veces produce el mismo resultado que ejecutarla una. Importa porque en producción las operaciones se repiten: se cae la red justo después de escribir pero antes de recibir la confirmación, alguien relanza el proceso, un reintento se dispara dos veces. Sin idempotencia, cada incidente deja un asiento duplicado o una tarea repetida, y los duplicados son especialmente dañinos porque no rompen nada visible: contaminan los datos en silencio hasta que alguien cuadra las cuentas y no salen. En orden de preferencia:
- Clave natural del negocio. Antes de crear un asiento, comprobar si ya existe uno para ese proveedor, factura y ejercicio. La más robusta: sobrevive a un cambio de sistema.
- Identificador de operación propio, generado por la capa y escrito en el destino en un campo de referencia externa. Antes de escribir, se busca.
- Registro propio de lo procesado, con el hash del documento de origen. La red de seguridad cuando el destino no ofrece dónde apoyarse.
Reintentos: fallar es normal, la pregunta es cómo
En una integración real fallan cosas continuamente, casi siempre de forma transitoria: mantenimiento nocturno del ERP, un error temporal de la API, un parpadeo de red. Hay que distinguir dos familias.
Errores transitorios (tiempos de espera agotados, 5xx, límites de peticiones, conexión rechazada): se reintenta con espera creciente —unos segundos, luego el doble, luego el doble otra vez— y un máximo de intentos. Reintentar en bucle contra un sistema saturado lo empeora.
Errores permanentes (el proveedor no existe, el documento está mal formado, faltan permisos): no se reintenta nunca. Cien reintentos de algo que va a fallar cien veces solo generan ruido y esconden el problema real.
Y una tercera categoría que se olvida siempre: lo que agotó los reintentos. Tiene que quedar en un sitio consultable, con el dato original íntegro, para relanzarlo cuando el problema esté resuelto.
Trazabilidad: todo queda registrado
El día que alguien pregunte "¿por qué esta factura se imputó a esta cuenta?", la respuesta tiene que estar en un registro, no en la memoria de nadie. Por cada unidad de trabajo: identificador de operación, marca de tiempo, origen del dato, versión del componente y del modelo, entrada, salida, confianza si la hay, decisión tomada (escrito, revisado, rechazado), quién aprobó y el identificador del registro creado en destino.
Sirve para depurar, mejorar (los casos escalados son la lista de lo que hay que afinar) y rendir cuentas ante una auditoría o un cliente. Dos precauciones: si se procesan datos personales, el registro también los contiene, y minimizar lo almacenado, fijar plazo de conservación y controlar quién accede ayuda a cumplir con la normativa de protección de datos; y un registro que nadie mira no sirve, así que hace falta una pantalla donde el propietario vea qué se procesó y qué quedó pendiente.
Un sistema con idempotencia, reintentos diferenciados y trazabilidad se puede relanzar sin miedo, auditar sin arqueología y mejorar con datos. Sin eso, cada incidente es una investigación manual y cada mejora una conjetura.
Humano en el bucle, pero donde toca
"Humano en el bucle" se usa como conjuro tranquilizador. Pero si se pone revisión en todo, el sistema no ahorra nada y la gente acaba aprobando en bloque, que es peor que no revisar porque genera una falsa sensación de control. La decisión se toma acción por acción, con tres criterios.
Reversibilidad. Una tarea interna mal clasificada se corrige en diez segundos; un asiento contable en un ejercicio cerrado, no. Lo irreversible se confirma.
Impacto económico. Lo que mueve dinero, compromete stock o genera una obligación con un tercero pasa por una persona. Un umbral por importe es un mecanismo razonable y fácil de explicar.
Exposición al cliente. Todo lo que sale de la empresa —correos, presupuestos, documentos— se revisa. El coste de un error interno es tiempo; el de uno que llega al cliente es reputación.
En los ejemplos anteriores: las facturas se contabilizan solas cuando cuadran, están por debajo del umbral y el proveedor es conocido; los correos generan tareas internas, pero no respuestas al cliente; los albaranes se conforman en las líneas idénticas.
Cuando el proceso puede estimar cuán seguro está de un resultado, ese valor también debe usarse para enrutar. El umbral no se fija de una vez: se empieza conservador y se ajusta midiendo qué proporción de los casos escalados aprobaba la persona sin cambios.
La revisión humana solo funciona si la persona tiene contexto para decidir en segundos. Una bandeja que muestra el documento original, lo que el sistema propone y por qué, se revisa de verdad. Una con un identificador y un botón de aprobar se aprueba a ciegas.
Checklist antes de dar un proyecto por integrado
Un piloto que funciona en el portátil de un desarrollador no es una integración. Esto es lo que conviene exigir antes de dar el trabajo por terminado.
- Cada sistema tiene documentada su vía de acceso, credenciales fuera del código y un responsable identificado.
- Está escrito cuál es la fuente autoritativa de cada dato que toca el proceso, y el propietario funcional ha validado los criterios.
- Toda escritura es idempotente, y está probado: ejecutar dos veces el mismo lote no genera duplicados.
- Los errores transitorios se reintentan con espera creciente; los permanentes no se reintentan.
- Lo que agota los reintentos queda en una cola consultable, con el dato original y el motivo.
- Está probado qué pasa si el destino no está disponible: el proceso no pierde trabajo.
- Cada unidad de trabajo tiene registro con origen, decisión, versión del componente y resultado.
- Hay una pantalla que el propietario del proceso entiende sin ayuda técnica, y aviso automático cuando la tasa de fallos o de escalados se sale de lo normal.
- Ninguna acción irreversible, por encima del umbral económico o de cara al cliente se ejecuta sola.
- El mantenimiento está presupuestado, con atención a las integraciones frágiles (base de datos directa y RPA).
Conclusión
La parte difícil de meter IA en una empresa no es la IA. Es que el dato vive en cuatro sitios con cuatro versiones distintas, que el sistema que lo guarda no fue diseñado para hablar con otros programas, y que un proceso que funciona el día de la demo tiene que seguir funcionando el martes de agosto en que nadie está de guardia.
Los proyectos que aguantan comparten una forma reconocible: inventario antes de empezar, la vía más robusta disponible en lugar de la más vistosa, una capa propia en medio en vez de soldar la IA al sistema heredado, y la idempotencia, los reintentos y el registro tratados como parte del alcance. Hecho así, cambiar de modelo deja de ser un proyecto y pasa a ser una tarde. Que es exactamente donde conviene que esté esa decisión.
Si estás valorando integrar IA en los sistemas que ya tienes y quieres una opinión técnica sobre por dónde entrar, cuéntanos tu caso y lo miramos sin compromiso.
