IA para ingenieros: qué ayuda en una oficina técnica y qué no

Una oficina técnica produce bastante más texto del que se ve desde fuera. Antes de que un proyecto llegue a obra o a fábrica ya se han escrito memorias, informes, especificaciones, pliegos, hojas de datos, peticiones de oferta, comparativas técnicas, hojas de comentarios, actas y varias rondas de correspondencia con proveedores. Nada de eso sale en la presentación de nadie, pero se lleva una parte considerable de la semana de un ingeniero.

Ahí es donde la IA generativa ayuda hoy de forma razonablemente fiable. Y hay otra parte —el cálculo, el dimensionamiento, la verificación de cumplimiento— donde no debe entrar. Conviene decirlo al principio y no en una nota al pie, porque es la única frontera de este artículo que no admite matices.

Mi trayectoria mezcla datos, automatización y entornos industriales, incluida la industria química, y eso condiciona cómo planteo esto: no es lo mismo una pyme puramente administrativa que un entorno donde pesan la seguridad, la trazabilidad, la fiabilidad del dato y la integración con los sistemas que ya existen. De ahí sale la distinción que más se repite aquí, y que cualquier ingeniero reconoce: la que hay entre una demo que funciona y un proceso que tiene que aguantar todos los días.

Este artículo es transversal —vale para ingeniería de proyecto, de instalaciones, de producto o de procesos— y trata el trabajo de oficina técnica. Si lo que buscas es el enfoque de planta y de entorno industrial concreto, está en IA en la industria del Camp de Tarragona; y si trabajas en edificación, el equivalente para estudios está en IA para arquitectura. Lo que sigue es el material con el que trabajo en el curso de ChatGPT para empresas cuando el grupo es de perfil técnico.

El cálculo no entra, y no es cuestión de versión

Un modelo de lenguaje genera lo plausible. Esa frase suena abstracta hasta que la aplicas a un número: puede devolverte un valor con las unidades correctas, un orden de magnitud creíble y un desarrollo impecablemente redactado que esté mal. No hay ninguna señal en el resultado que lo delate.

Y esa es la asimetría que hace de esto una línea roja y no una recomendación. Un texto mal redactado se ve al leerlo: chirría, suena raro, alguien lo corrige. Un factor mal aplicado, una hipótesis que se ha colado o un coeficiente cambiado no chirrían. Pasan la lectura rápida, pasan la revisión de formato y siguen adelante. Un cálculo incorrecto que parece correcto es peor que no tener cálculo, porque el que falta se busca y el que está mal se usa.

Así que la frontera es sencilla de enunciar: nada de lo que dependa la seguridad de una persona, la integridad de una instalación o el cumplimiento de un requisito se resuelve en un chat. Dimensionar, verificar capacidades, seleccionar un elemento por sus prestaciones o justificar cumplimiento normativo se hace con las herramientas de cálculo, los métodos y las fuentes de siempre, y lo firma quien responde de ello. No es una limitación de la versión gratuita que se arregle pagando, ni un problema de cómo se formula la pregunta.

Hay dos derivadas que conviene tener claras.

No le preguntes de memoria qué dice una norma. No consulta ninguna base normativa cuando responde: predice el texto que encaja con tu pregunta, y una referencia inventada —con su numeración y su redacción verosímil— no se distingue de una real hasta que la buscas. Lo que sí funciona es pegarle el texto que tienes delante y pedirle que cite literalmente los apartados aplicables, marcando lo que no pueda determinar. Cualquier referencia se comprueba después en la fuente oficial.

Alrededor del cálculo sí hay trabajo que delegar. Ordenar hipótesis y datos de partida antes de empezar, redactar el apartado que explica un cálculo ya hecho, preparar la lista de comprobaciones que hay que pasar, o pedirle que te haga las preguntas que faltan antes de escribir nada. Todo eso está fuera del número y dentro del documento.

Dónde sí ahorra tiempo: el texto que rodea al proyecto

Las tareas que siguen comparten el mismo patrón: parten de material que ya existe, producen un borrador y terminan con una persona que revisa y asume el resultado. Ese patrón es el que funciona; fuera de él, el rendimiento cae rápido.

Memorias e informes: la parte redactada, no la calculada

Un informe de cálculo tiene dos mitades. Una es el cálculo. La otra es la memoria que lo explica: objeto, alcance, datos de partida, hipótesis, criterios adoptados, descripción del método y conclusiones. La segunda mitad se escribe con las mismas palabras proyecto tras proyecto y es la que se queda para el final, cuando ya no queda tiempo.

«Te paso los datos de partida, las hipótesis y los resultados de un cálculo que ya he hecho: [datos]. Redacta el apartado descriptivo siguiendo la estructura de este informe nuestro que te adjunto como modelo. No calcules nada, no redondees ni modifiques ningún valor y no añadas hipótesis, criterios ni conclusiones que no estén en lo que te he dado. Si falta algo, escribe [PENDIENTE] en lugar de suponerlo.»

Revisa: los valores transcritos, uno a uno, contra tu fuente. Es donde más se relaja la atención, porque el texto que los rodea está bien escrito y da confianza. Y comprueba que no haya introducido una hipótesis razonable que tú no habías adoptado.

Especificaciones y requisitos: convertir lo ambiguo en verificable

Aquí hay un uso que rinde más de lo que parece y que no es redactar, sino auditar el propio texto. Buena parte de los problemas de una especificación aparecen meses después, cuando alguien discute qué significaba exactamente «adecuado», «de primera calidad» o «suficiente para el servicio previsto».

«Te paso el borrador de una especificación técnica. Haz dos cosas: primero, extrae todos los requisitos en una lista numerada, indicando para cada uno cómo se verificaría; segundo, señala los que están redactados de forma ambigua o no son verificables tal y como están escritos, y propón una redacción alternativa. No añadas requisitos que no estén en el texto.»

Revisa: que no haya añadido nada. Y trata las redacciones alternativas como propuestas, no como correcciones: quien decide qué se exige eres tú.

Ofertas de proveedores: comparar sí, decidir no

Comparar tres ofertas técnicas contra una especificación es trabajo de tabla, no de criterio, hasta que llega el momento de decidir. La parte mecánica —cruzar cada requisito con lo que dice cada oferta— es tediosa, se hace con prisa y es donde se cuelan las sorpresas: lo que no está incluido, lo que se ha ofertado con una desviación anotada en una nota a pie de página, lo que directamente no se menciona.

«Te paso nuestra especificación y la oferta técnica de un proveedor. Genera una tabla con una fila por requisito y tres columnas: requisito, qué dice la oferta y estado (cumple / desviación / no consta). Usa “no consta” siempre que la oferta no lo mencione explícitamente; no deduzcas cumplimiento. Añade después dos listas: desviaciones declaradas y exclusiones de alcance. No valores cuál es mejor ni recomiendes nada.»

Revisa: cada línea contra el documento original, empezando por las que marca como «cumple». Y la comparativa no es la decisión: elegir proveedor pondera precio, plazo, experiencia previa y riesgo, y eso tiene un responsable con nombre. Lo mismo con la petición de aclaraciones: la herramienta redacta bien el correo a partir de las desviaciones, pero qué se pregunta y qué se acepta lo decides tú.

Comentarios y revisiones de documentos

El ciclo de comentarios se lleva más horas de las que se contabilizan: leer un documento de un tercero, redactar comentarios claros, recibir las respuestas, comprobar si se han atendido y cerrar. Dos usos concretos funcionan bien: convertir notas sueltas de lectura en una hoja de comentarios ordenada, con referencia al apartado y una petición concreta en cada uno; y resumir qué ha cambiado entre dos revisiones de un mismo documento cuando el proveedor no ha marcado los cambios.

Con una advertencia para lo segundo: si lo que hay que comparar son tablas de datos, valores o listas largas, esto no es un comparador de documentos y no debe usarse como tal. Sirve para orientarte sobre qué apartados mirar, no para certificar que el resto está igual. Pídele explícitamente que marque lo que no pueda determinar, y no aceptes «sin cambios» como conclusión suya.

Traducción técnica

Documentación que llega o sale en otro idioma. Es uno de los usos donde el resultado sale más limpio, con dos condiciones: darle el glosario de la casa y prohibirle expresamente tocar designaciones de equipo, códigos de documento y referencias. Una traducción fluida esconde un error de término mucho mejor que una traducción torpe, así que la terminología crítica y las unidades se comprueban siempre.

Datos: cuándo Excel deja de ser la herramienta

Una parte del trabajo técnico no es texto: son horas imputadas, seguimiento de compras, listas de documentos, planificación, históricos de ensayos. Y casi todo eso vive en hojas de cálculo que empezaron pequeñas.

La IA ayuda ahí de dos maneras honestas: escribir una fórmula que no te sale y explicarte una que heredaste y nadie entiende. Ambas están desarrolladas, con lo que hay que revisar en cada caso, en ChatGPT en Excel. Ojo con la diferencia respecto al apartado anterior: hablamos de datos de gestión, no de la hoja donde haces el cálculo del proyecto.

Pero llega un punto en que afinar la fórmula es trabajar en la capa equivocada: cuando la hoja se repite a diario sobre decenas de miles de filas y el proceso depende de que una persona concreta esté disponible, lo que sobra no es una función, es el sitio donde vive el cálculo. Cuándo se cruza ese umbral y qué señales lo anuncian está desarrollado en IA para finanzas y control de gestión.

Eso ya no es formación. Enseñar a un equipo a usar estas herramientas y construir una capa de datos o conectar la IA con vuestros sistemas son dos proyectos distintos, con alcances, plazos y riesgos distintos. La parte de formación la doy desde aquí; los proyectos técnicos los hago desde Meridian Data.

Resumen: qué sí y qué no

Antes de nada de esto, la conversación sobre qué se puede pegar y qué no. En una oficina técnica hay documentación de cliente, ofertas bajo acuerdo de confidencialidad y datos de personas; el criterio está en qué no compartir nunca con ChatGPT, y se decide antes de formar a nadie.

De una demo que funciona a un proceso que aguanta

Este es el punto donde se cae la mayoría de las pruebas internas. Alguien encuentra una instrucción que funciona muy bien, la enseña en una reunión, todo el mundo asiente, y tres semanas después nadie la usa. No es que la herramienta fallara: es que se probó una vez, con un documento elegido, por la persona que sabía qué pedir y qué mirar.

Un proceso es otra cosa. Es esa misma instrucción usada en la revisión D del documento, con el proveedor que contesta a medias, por el compañero que ese día cubre a otro y que no estuvo en la demostración. Lo que sobrevive a ese escenario es bastante menos vistoso: instrucciones guardadas y reutilizables, un criterio escrito de qué se marca como «no consta», y una regla clara de quién revisa qué antes de que el documento salga.

Y hay un patrón que se repite en todos los sectores: lo que más ahorra tiempo es convertir información ya existente en una primera versión útil. Lo que menos funciona es «hazme todo el informe desde cero» y darlo por bueno; la revisión se come el ahorro, y en un documento con consecuencias esa revisión no es opcional.

Por dónde empezar

Por un documento, no por una herramienta. La pregunta útil no es qué IA usar, sino qué documento escribís todas las semanas que cuesta más de lo que debería. De ahí sale el caso de prueba y también la forma de saber si ha servido.

Con material vuestro. Una especificación real, una oferta real, un informe real. Lo que más falla en una formación técnica es hacerla espectacular y desconectada del trabajo: muchas demos y ningún proceso del alumno. Al día siguiente nadie sabe por dónde empezar.

Con la frontera del cálculo dicha desde el primer ejercicio. No como advertencia legal al final, sino como parte del método. Un equipo técnico acepta muy bien una herramienta con límites claros y desconfía, con razón, de la que se presenta sin ninguno.

Si queréis pasar de la prueba individual a una forma de trabajar común en la oficina técnica, eso es lo que se trabaja en la formación en IA para empresas, sobre vuestros documentos y con las reglas de verificación incorporadas desde el principio; y si lo que falla es cómo se pide —que suele ser el caso en perfiles técnicos, acostumbrados a instrucciones precisas—, el terreno es el curso de prompt engineering. Si trabajáis en el entorno industrial de la zona, la formación en IA en Tarragona se plantea en vuestras instalaciones.

Si quieres ver si encaja con tu equipo, reserva media hora y lo miramos con un documento vuestro sobre la mesa.