Pulimos los presupuestos de Cerrajería Carlos Rodríguez con IA — y sin sacar sus datos del servidor

Cuando los presupuestos delatan que se hicieron con prisa

En una empresa de servicios técnicos, el presupuesto y la factura son la cara escrita de la marca. El cliente final puede no fijarse en la cerradura que se instaló, pero sí lee el texto que recibe. Y ese texto, en cuanto lo redactan personas distintas en momentos distintos, deja de sonar a la misma empresa.

En Cerrajería Carlos Rodríguez, los presupuestos salían a veces con prisa, otras veces con detalle, casi nunca con consistencia. No era falta de criterio del equipo: era el coste invisible de tener que escribir un párrafo profesional al final de un día atendiendo aperturas, vandalismos y urgencias. El cliente recibía descripciones desiguales, volvía con dudas, y la imagen de la empresa quedaba siempre por debajo del trabajo real que se hacía en la calle.

Lo que decidimos antes de construir

La solución natural era integrar un asistente de IA dentro de su software de gestión, conectado a alguno de los grandes proveedores en la nube. Funciona, lo hace ya muchísima gente y es lo que probablemente les habría propuesto cualquier otro.

Pero antes de empezar les expliqué qué supone esa decisión cuando los datos no son los tuyos sino los de tus clientes. Cada vez que alguien pulse el botón para mejorar un texto, el contenido del presupuesto — con el nombre del cliente, su dirección, qué hicimos en su portal a las 3 de la madrugada y cuánto le cobramos — se envía a un proveedor que no controlamos, sujeto a sus términos, sus subcontratistas y sus políticas de uso de datos para entrenamiento.

Alejandro no se lo había planteado. Pocos clientes lo hacen — no es su trabajo. En cuanto lo escuchó, la respuesta fue inmediata: “no, eso no”. Y ahí nació la decisión de hacerlo en su propio servidor.

Qué hace el asistente exactamente

Junto al campo de descripción de cada presupuesto o factura, dentro del software de gestión que ya usaban a diario, apareció un botón: mejorar texto. Ese botón es todo el cambio visible.

• El usuario teclea la descripción como sabe, como tiene tiempo, sin pelearse con la prosa.
• Pulsa el botón.
• El asistente devuelve la misma idea, reescrita con tono profesional y consistente con el resto de presupuestos de la empresa.
• El usuario aprueba o edita el resultado antes de guardar. La última palabra siempre es humana.

Cero formación. Cero pestañas nuevas que abrir. Cero cambios en el flujo de trabajo. La IA aparece exactamente donde la fricción estaba.

Cómo está montado

El modelo. Qwen 2.5 3B. Un modelo pequeño y eficiente, suficiente de sobra para reescribir un párrafo en español con tono profesional. Un modelo de 70B parámetros sería desproporcionado para esta tarea, consumiría más RAM y tardaría más por respuesta sin aportar valor proporcional. Elegir el modelo correcto para el problema es parte del oficio.

El motor. Ollama. Es uno de los runtimes de inferencia local más sólidos de 2025-26: expone una API HTTP en localhost:11434, gestiona la descarga y carga de los modelos, y se opera con la simplicidad de cualquier servicio Linux. La barrera técnica para correr un modelo local pequeño se ha desplomado en los últimos dos años.

La integración. El software de gestión hace una petición HTTP al motor Ollama corriendo en el mismo servidor, con el texto del usuario y una instrucción de tono. Ollama devuelve el texto reescrito. La aplicación lo muestra al usuario para que apruebe o edite. Todo ocurre dentro de la red del cliente.

La consecuencia. Ningún dato de los clientes finales sale del servidor de Cerrajería. Ningún proveedor de IA en la nube tiene acceso a sus presupuestos. Cero coste por token, sin facturación variable. Y si mañana cambia la política de algún proveedor, el asistente sigue funcionando igual: no depende de nadie.

Tres cosas que aprendimos

1. No siempre necesitas el modelo más grande. Hay una inercia, alimentada por los titulares, a tirar del modelo más grande disponible para cualquier tarea de IA. Pero un 3B local hace este trabajo perfectamente. Elegir el modelo proporcional al caso ahorra recursos, mejora la latencia y abre la puerta al despliegue on-prem en máquinas que ya tiene la empresa.

2. El usuario tiene la última palabra. El asistente sugiere; no autopublica. Ese detalle de diseño hace dos cosas: baja a casi cero el riesgo de errores que lleguen al cliente, y sube la confianza del equipo en la herramienta. Una IA que decide sola es una IA que no usas; una IA que te asiste y te deja revisar es una IA que se queda.

3. On-prem ya no es lo que era. Hace cinco años, servir un modelo local exigía hardware caro y conocimiento de DevOps de nicho. En 2025-26, con Ollama y modelos pequeños eficientes, servir IA en el propio servidor es operativamente similar a llamar a una API en la nube. La barrera técnica que justificaba “tirar todo a OpenAI” se ha desplomado. Para empresas que tratan datos sensibles, esto cambia la conversación.

Lo que viene

El asistente lleva en producción desde 2026 y sigue iterando. En el roadmap inmediato:

• Extender el asistente a otros textos del software de gestión: emails al cliente, descripciones de trabajos cerrados, comunicaciones internas.
• Subir a Qwen 2.5 7B si en algún caso el 3B se queda corto, manteniendo el despliegue local.
• Plantillas por tipo de trabajo (cerraduras, blindajes, vandalismo, urgencias 24h) para que el asistente afine aún más el tono según el contexto.