Consultar el ERP con IA local: lenguaje natural sin nube

"¿Qué clientes no han pedido nada en los últimos tres meses?" Es una pregunta sencilla para cualquier responsable comercial, pero obtener la respuesta suele requerir escribir SQL, pedirle el dato a alguien del equipo técnico o esperar a que se actualice el informe de turno. Profesionales del sector comparten cada vez más en X una alternativa diferente: un LLM ejecutándose localmente en los servidores de la empresa, capaz de traducir esa pregunta en lenguaje natural a SQL y ejecutarla directamente contra la base de datos del ERP, sin que ni una línea de datos salga de la red interna.

Cómo funciona text-to-SQL con un LLM local

El flujo de trabajo es directo. Un usuario de negocio escribe la pregunta en lenguaje natural. El modelo local la convierte en una consulta SQL. La consulta se ejecuta contra la base de datos del ERP. El resultado vuelve formateado en texto comprensible o en tabla estructurada.

Cuatro pasos, todos locales:

1. Entrada en lenguaje natural: "Muéstrame todas las facturas pendientes superiores a 5.000 € del segundo trimestre."
2. Generación de SQL: El LLM produce la consulta SELECT adaptada al esquema concreto de la base de datos.
3. Ejecución contra la base de datos: La consulta se lanza contra el backend del ERP (SAP Business One, Odoo o una exportación de contabilidad).
4. Respuesta formateada: El modelo presenta el resultado en lenguaje claro o como tabla estructurada.

Sin claves de API, sin suscripción a la nube, sin transmisión de datos. Todo el proceso ocurre en hardware propio de la empresa.

Qué modelos funcionan mejor

No todos los modelos locales son igual de capaces con consultas estructuradas. La comunidad de IA local ha identificado varias opciones especialmente destacadas:

SQLCoder, desarrollado por Defog.ai, es un modelo de código abierto ajustado específicamente para text-to-SQL. Funciona a través de Ollama y, según mediciones reportadas por la comunidad, supera significativamente a modelos de propósito general de tamaño similar en patrones típicos de consulta ERP: uniones multitabla, agregaciones, filtros por rango de fechas. En hardware Apple Silicon con 192 GB de memoria unificada, los benchmarks comunitarios reportan entre 20 y 40 tokens por segundo para la variante de 15B parámetros, suficiente para uso interactivo.

Qwen 2.5 de 32B en adelante ofrece un razonamiento SQL sólido incluso para consultas complejas con múltiples tablas o condiciones anidadas. Según mediciones reportadas por la comunidad, los modelos de 14B manejan tareas básicas de reporting con fiabilidad — ingresos por período, mejores clientes, cuentas a cobrar abiertas — mientras que se recomiendan modelos de 32B o más para cargas de trabajo analíticas complejas.

Llama 3.3 70B es especialmente útil si el equipo realiza consultas en varios idiomas, algo habitual en PYMES españolas con operaciones internacionales que trabajan en castellano, inglés y alemán sobre el mismo sistema ERP.

Compatibilidad con los ERP más comunes en PYMES europeas

Los tres sistemas ERP más habituales en pequeñas y medianas empresas europeas tienen distintos puntos de acceso técnico:

SAP Business One

SAP B1 usa HANA o Microsoft SQL Server como base de datos. Ambos son accesibles mediante conectores ODBC estándar o clientes SQL directos. La tarea principal de configuración es escribir una descripción del esquema: documentar las tablas y columnas clave para que el LLM sepa exactamente qué está consultando. En la práctica, se trata de una inversión única de uno a dos días de trabajo.

Odoo

Odoo utiliza PostgreSQL, una de las bases de datos relacionales mejor documentadas disponibles. Dado que el modelo de datos de Odoo está documentado públicamente, construir el contexto de esquema para el LLM local es más rápido que con sistemas propietarios. Las configuraciones basadas en SQLCoder funcionan bien aquí desde el primer momento.

Exportaciones de software de contabilidad

Para empresas que usan software de contabilidad sin acceso directo a la base de datos, el enfoque práctico es exportar informes como CSV o XLSX de forma programada, cargarlos en una base de datos SQLite local y apuntar el LLM hacia esa base de datos. Cero contacto con la nube: los datos financieros permanecen en el entorno propio de la empresa.

Por qué el RGPD convierte esto en algo más que comodidad

Los sistemas ERP contienen datos especialmente sensibles: historiales de pago de clientes, datos de remuneración de empleados, precios estratégicos con proveedores, niveles de inventario confidenciales. Cuando se envía cualquiera de estos datos a un sistema de IA en la nube, aunque sea como parte de un prompt, se está transmitiendo a infraestructura de terceros sujeta a las condiciones de servicio de ese proveedor y a la legislación del país donde están sus servidores.

Según nuestra interpretación del RGPD — especialmente el artículo 5.1.f sobre el principio de integridad y confidencialidad, y el artículo 32 sobre medidas técnicas y organizativas adecuadas — esa transmisión es precisamente donde se acumula el riesgo legal. Las condiciones de terceros, el posible uso de los datos para entrenamiento y las reclamaciones de jurisdicción extraterritorial no aplican cuando el procesamiento se queda en las instalaciones propias.

Un LLM local elimina estos riesgos de forma estructural. Si no hay transferencia de datos, no hay nada que interceptar. Lo que se procesa en hardware propio no está sujeto a ninguna jurisdicción externa. Esto no es una afirmación de marketing — es la realidad técnica de la infraestructura de IA local.

Profundizamos en el concepto de soberanía de datos y su implementación técnica en /data-sovereignty.html.

Kit Digital: ¿puede financiarse este tipo de implementación?

Las PYMES españolas con acceso al programa Kit Digital deben valorar qué categorías de subvención pueden cubrir este tipo de proyecto. La categoría Gestión de Procesos financia la implementación y parametrización de soluciones de automatización y eficiencia empresarial. Una implementación de IA local con conector ERP puede encajar en esta categoría, especialmente si incluye módulos de automatización de consultas, integración con flujos de trabajo existentes o visualización de datos estructurados.

Según nuestra interpretación de las bases del programa, la elegibilidad depende del agente digitalizador, del alcance del proyecto y del segmento de empresa. Recomendamos verificar la aplicabilidad con un agente digitalizador habilitado antes de comprometer el presupuesto de subvención. Más información sobre cómo aprovechar Kit Digital para proyectos de IA local en /kit-digital.html.

Una configuración práctica

Una implementación text-to-SQL lista para producción en una PYME incluye habitualmente un conjunto reducido de componentes:

• Ollama como servidor de modelos local (funciona en Windows, macOS, Linux)
• SQLCoder o Qwen 2.5 como LLM (servido a través de Ollama)
• Open WebUI como interfaz de chat, con plugin de conector de base de datos
• Descripción del esquema como contexto del sistema (se escribe una vez, se actualiza cuando el esquema evoluciona)
• Conector SQL hacia SAP B1, Odoo o un archivo SQLite con exportaciones de contabilidad

El enfoque estándar de implementación: empezar con un piloto sobre dos o tres de las tablas más consultadas y entre 10 y 15 consultas de prueba representativas. Evaluar la precisión antes de ampliar al esquema completo. Este despliegue controlado suele llevar entre dos y cuatro semanas.

Lo que abarca un proceso de piloto en detalle — incluyendo criterios de evaluación y umbrales de calidad — lo describimos en /local-ai.html.

Para qué sirve y para qué no

Este enfoque no reemplaza herramientas BI completas como Power BI o Tableau. Es un complemento — y en muchos casos un sustituto de las peticiones informales de "¿me puedes sacar ese dato?" que a diario consumen tiempo de desarrolladores y analistas.

Los usuarios de negocio que más se benefician son los que tienen necesidades de información ad-hoc y urgentes: el responsable comercial que quiere saber qué cuentas se están enfriando antes de una reunión, el responsable de operaciones que necesita un desglose rápido de tiempos de entrega por proveedor, el directivo que quiere ver los tres últimos pedidos antes de una llamada con un cliente.

Para estos casos, el text-to-SQL local suele ser la herramienta adecuada precisamente porque no requiere construir un dashboard, no necesita un especialista en BI disponible y no necesita aprobación de IT. Una pregunta, escrita en lenguaje natural, respondida en segundos, en servidores que no salen del edificio.

Si quieres explorar cómo podría ser una implementación de IA local conectada a tu ERP, hablemos de un proyecto piloto.