02 Aplicaciones, integraciones y sistemas sobre modelos, escritos para tu operación.
Esta parte reúne tres clases de software: las aplicaciones con las que trabaja cada puesto, las integraciones que mueven los datos entre tus programas y los sistemas que ponen un modelo de lenguaje a trabajar dentro de un proceso, con límites fijados en código. Las tres comparten el entorno, las cuentas y el registro de actividad del resto del sistema.
Aplicaciones para cada puesto de trabajo
Cada aplicación parte de un modelo de datos explícito y de los permisos que ya existen en tu empresa, y deja constancia de quién crea, modifica o aprueba cada registro.
-
01 Aplicaciones web internas
Paneles, portales, CRM propios y herramientas de equipo en el navegador, con una cuenta por persona y permisos por rol. Leen y escriben a través de las mismas integraciones que el resto del sistema.
-
02 Apps para iPhone y Android
Para el trabajo fuera de la oficina: fotos y notas de voz en obra, en el almacén o en una visita, y consulta del estado de un pedido o un proyecto. Usan la cámara, el micrófono y las notificaciones del teléfono, y envían lo capturado al mismo sistema que usa la oficina.
-
03 Programas de escritorio para Mac y Windows
Para ficheros locales pesados, carpetas de red o diálogo con programas instalados en el puesto, como los de modelado, cálculo o presupuestos. Se ejecutan en el ordenador y se sincronizan con los servicios de la empresa.
-
04 Pantallas delante de programas antiguos
El programa antiguo sigue siendo el sistema de registro. La pantalla nueva valida cada dato antes de escribirlo en él, por la misma vía que usan sus integraciones, y cada operación se registra completa o no se registra. Un alta de proyecto, cliente o pedido se introduce una sola vez y la pantalla la reparte entre los programas que la usan.
Integraciones entre programas
Elegimos la vía de conexión por estabilidad: primero la interfaz documentada del fabricante, después el intercambio de ficheros y, en último término, la lectura directa de su base de datos, que exige más mantenimiento. Todo lo que entra se guarda en bruto antes de procesarse, de modo que cualquier dato puede reprocesarse y auditarse.
Por API y webhooks
Conectores sobre API REST, con webhooks cuando el programa notifica sus eventos y consulta periódica cuando no lo hace. Cada llamada respeta los límites de tasa del proveedor, se reintenta con espera creciente y es idempotente: un reintento nunca duplica un pedido ni una factura.
Por ficheros
Cuando no hay API, el intercambio usa los formatos que el programa ya sabe leer y escribir: IFC desde el modelo BIM, BC3 para el programa de presupuestos, DWG para planos, y CSV, Excel o PDF para el resto. Cada fichero se valida contra su estructura antes de importarse.
Servidores MCP
Un servidor MCP envuelve un sistema antiguo y expone a un modelo un conjunto cerrado de operaciones con parámetros tipados, en su mayoría de lectura. Así un modelo consulta un ERP o un programa técnico sin acceso a su base de datos.
Pruebas de cada conector
Un conector se da por bueno cuando se puede cortar el programa de origen a mitad de una operación sin perder ni duplicar un registro. Cada mensaje se valida contra el esquema esperado: si un proveedor cambia un campo, el mensaje se detiene con su error en lugar de escribirse a medias. Las equivalencias entre programas, como códigos de cliente y de artículo, unidades o tipos de IVA, viven en una tabla revisable.
Sistemas construidos sobre un modelo concreto
Cada modelo difiere en ventana de contexto, fiabilidad al invocar herramientas, cantidad de tokens que genera para una misma tarea y rendimiento en cada idioma. Por eso cada sistema tiene su propio W.A.T. (Workflows, Agents, Tools) y sus propias cadenas de proceso, ajustados al modelo y a la versión fijada sobre la que corre.
-
01 El flujo, diseñado para el modelo
El flujo de trabajo es la secuencia fija del proceso. La dividimos en pasos del tamaño que ese modelo resuelve con fiabilidad, cada uno con sus instrucciones y su esquema, y guardamos el estado de cada etapa: si algo falla, el proceso se reanuda donde se detuvo. Lo que resuelve código determinista no pasa por el modelo.
-
02 El criterio, solo donde hace falta
Los agentes son roles con un objetivo, unas herramientas y unos límites definidos, y solo intervienen en los pasos del flujo que exigen criterio: uno redacta, otro comprueba el resultado contra reglas, otro prepara la acción para que una persona la apruebe.
-
03 Herramientas precisas
Cada herramienta hace una sola cosa, con parámetros tipados, una descripción inequívoca y errores que el modelo sabe interpretar. El modelo solo propone la llamada; la ejecución, los permisos y el registro corresponden a nuestra capa. Las operaciones irreversibles quedan fuera de la caja de herramientas: las ejecuta una persona, o código determinista tras una aprobación registrada.
-
04 En la nube o en tu servidor
Con un modelo en la nube, hoy de las familias Mistral o Claude, un paso puede manejar más contexto y más herramientas. Un modelo abierto instalado en tu servidor, como Granite, ALIA/Salamandra o EuroLLM, recibe pasos más cortos, menos herramientas y esquemas más estrictos, y ningún dato sale de la empresa. Lo servimos con vLLM o SGLang en producción, que reutilizan la caché entre peticiones, y con Ollama en los prototipos. El modelo de cada tarea se revisa cada mes.
Eficiencia y control del gasto
Cada sistema se diseña para gastar lo mínimo por resultado útil, con sus límites escritos en código, donde no dependen de que el modelo obedezca una instrucción.
- Coste por tarea terminada: medimos el coste de cada pedido registrado o respuesta enviada, no el precio por token: un modelo barato que genera más tokens de salida puede salir más caro.
- Prefijo estable: instrucciones, esquemas y definiciones de herramientas van siempre delante y sin cambios, para aprovechar la caché de prefijo del proveedor o del servidor propio; lo variable va al final.
- Recorte determinista: antes de resumir con un modelo, el contexto se recorta con reglas, descartando duplicados, turnos antiguos y campos que la tarea no usa.
- Topes duros: un máximo de pasos y de gasto por tarea y por clave, aplicado por código y registrado.
- Escalado por paso: cada paso usa el modelo más económico que lo resuelve con fiabilidad, comprobado con casos reales, y solo los casos que lo exigen pasan a un modelo mayor.
- Salidas estructuradas: cada respuesta es un objeto validado contra JSON Schema, con su nivel de confianza y la indicación de si debe pasar a una persona. Lo que no valida se registra como error, sin reintentos silenciosos.
Resultados y cómo se miden
- Menos reentradas: las veces que se teclea el mismo dato en dos programas, contadas con el método de la línea base del diagnóstico.
- Tiempo por tarea: antes y después, en cada tarea sobre la que actúa el software, con el mismo método.
- Coste y pasos por tarea terminada: en los sistemas sobre modelos, comparados tras cada ajuste del flujo o cambio de versión.
- Entradas detenidas por validación: cuántos datos frena cada comprobación antes de llegar a un programa, y por qué motivo.
¿Ponemos tu empresa al día?
Empezamos con una llamada de 30 minutos para entender tu caso y explicarte en qué consiste el diagnóstico y cuál es su precio.
Pide el diagnóstico