El futuro de la IA en la oficina técnica: privacidad, modelos locales y trabajo desatendido

La IA que llegue al cálculo y al despiece puede quedarse dentro de la oficina. Probé si un equipo con tarjeta gráfica de 24 GB puede hacerlo y a qué precio en tiempo.

Ilustración del puesto de trabajo con el modelo 3D y la sesión del agente en local.

Lo que está en juego

En una oficina técnica y en una fábrica de madera se trabaja con información que no se enseña: escuadrías, despieces, márgenes, detalles constructivos y criterios de mecanizado. Es el know-how con el que se compite.

Cuando un programa de cálculo como Cadwork incorpore IA —si lo hace; no tengo acceso a su beta—, la vía más cómoda será enviar ese contexto a un servidor externo. Para un estudio o un taller, eso significa que el conocimiento sale de casa.

La alternativa es la inferencia local: ejecutar el modelo en los ordenadores de la propia oficina. No es una idea teórica. Es una decisión de infraestructura, con un coste y unos límites que conviene medir.

La duda

Los modelos que caben en un ordenador de oficina se equivocan. A veces inventan y, lo que es peor, aseguran que el trabajo está bien cuando no lo está.

En una tarea de código eso se detecta ejecutando las pruebas. En una tarea de taller, el error se descubre más tarde y cuesta más. Por eso la pregunta no era solo si el modelo sabe hacer el trabajo, sino si puedo dejarlo trabajando solo y revisar el resultado por la mañana con garantías.

La prueba

No tengo acceso a la beta de Cadwork, así que no pude probar con cálculo o despiece real. Usé dos tareas de programación porque tienen algo en común con el trabajo de oficina técnica: un resultado que se puede comprobar automáticamente. Si el modelo cumple o no, no depende de mi impresión. Una consistía en ordenar y renombrar contraseñas de un servidor; la otra, en aligerar una aplicación web que tardaba en cargar.

El equipo: una tarjeta gráfica de 24 GB, 32 GB de memoria y Ollama, el programa que ejecuta el modelo en local. Dos modelos, dos tareas, una ejecución por combinación. La especificación de cada tarea incluía los criterios de aceptación. Después verifiqué todo por separado, sin fiarme del informe del modelo.

El modelo rápido era espectacular en velocidad y desastroso en fiabilidad. En una tarea dijo que habían pasado siete pruebas cuando el programa buscaba un dato con un formato que no existía. En otra redujo un archivo de más de 3.000 líneas a 20, sin guardar el cambio, y aseguró que estaba terminado. El modelo grande resolvió las tres entregas a la primera, con informes que coincidían con la realidad. La tarea más compleja le llevó 49 minutos; al modelo de frontera le llevó unos seis.

No es una estadística. Es un caso por tarea y modelo, con una configuración concreta. Pero la diferencia de comportamiento fue consistente: el modelo rápido no sostiene una tarea larga; el modelo grande sí, a cambio de tiempo.

La privacidad: qué sale y qué no

Aquí conviene separar dos cosas que suelen mezclarse: la teoría de la tarea y el material de la empresa.

La especificación —qué hay que hacer y con qué criterios se acepta— es teoría. Puede escribirla un modelo de frontera sin que vea una sola escuadría. La verificación también puede hacerse con datos inventados: pruebas que comprueban reglas, no el proyecto real.

El material que tiene valor —el despiece, los márgenes, el criterio de taller— se queda en el modelo local, dentro de la oficina. Esa es la división que hace útil el montaje: fuera se decide cómo se comprueba; dentro se trabaja con el conocimiento de la empresa.

Ilustración de la tarjeta gráfica que ejecuta los modelos en local.

En mi prueba, el modelo de frontera escribió la especificación y el modelo local ejecutó sobre el material. La especificación no necesita contener el material real. La privacidad no depende de que todo el proceso sea local, sino de que lo sensible no salga del equipo.

El resultado que importa

Un modelo local sí tiene capacidad para resolver un problema técnico complejo de forma privada. Pero es lento.

Para el trabajo interactivo del día a día no sirve: 49 minutos esperando no es una forma de trabajar. Para el trabajo desatendido sí abre una puerta: dejar tareas preparadas al terminar la jornada, que el equipo las ejecute de noche y que a la mañana siguiente haya un resultado que revisar.

El turno de noche

Con estos datos monté un traspaso nocturno. A la 1:30, un servicio coge tareas de una lista de pendientes. Cada tarea lleva una especificación, las comprobaciones que debe pasar y la lista de archivos que se pueden tocar. Un programa con herramientas —el agente— las ejecuta en local. Después, el servicio verifica por su cuenta, fuera del control del agente: ejecuta los criterios, compara los archivos cambiados con la lista permitida y exige que el cambio esté guardado y que no queden archivos sueltos. Si algo falla, devuelve al agente los errores reales. Al final genera un informe y avisa al móvil. Nunca fusiona ni sube nada.

La pieza clave no es el modelo. Es el verificador. Sin una comprobación cruzada independiente, el informe de éxito de la IA no vale nada.

También mantengo una lista de lecciones sacadas de los fallos, de solo lectura. La amplía el revisor, no el modelo. No es aprendizaje autónomo: es memoria de errores revisada por una persona.

Qué puede significar para una oficina técnica

No he probado nada de esto con Cadwork. No sé qué interfaz ofrecerá ni si permitirá ejecutar modelos en local. Lo que sí he comprobado es el patrón: un modelo local puede resolver una tarea acotada, con criterios verificables, sin que el material salga del equipo.

Trasladado al taller, apunta a tareas repetitivas y comprobables: generar listados de corte, revisar históricos, preparar variantes de despiece o comprobar que una optimización de corte (nesting) cumple unas reglas. Son ejemplos, no resultados medidos. La condición es la misma: definir el criterio de aceptación antes de delegar y verificar después.

Límites

Esto no es una prueba comparativa. Es un caso con un equipo, un modelo y dos tareas. La parte de privacidad exige una arquitectura concreta: el material sensible se queda en local; la especificación y la verificación pueden hacerse fuera con datos de prueba. Y la verificación independiente no es opcional.

El siguiente paso sería repetir la prueba con tareas reales de CAD o despiece cuando haya acceso a una versión que permita un flujo local. Hasta entonces, lo que tengo es una infraestructura que funciona con tareas de programación y un límite medido: 49 minutos para una tarea que un modelo de frontera resuelve en seis.