Introducción: la pregunta que no podemos aplazar
En 2024, los Premios Nobel de Química y de Física reconocieron conjuntamente el impacto transformador de la inteligencia artificial en la ciencia. AlphaFold2 pasó de ser una herramienta computacional de nicho a convertirse en la referencia que cambió la bioquímica estructural en menos de tres años. A partir de ese momento, la pregunta dejó de ser si la IA afectaría a la investigación química —ya lo hace— para convertirse en cómo debemos integrarla sin perder lo que define el trabajo científico de calidad.
Este ensayo parte de una posición con base empírica propia. El primer autor ha transformado en los últimos meses un flujo de trabajo completamente manual —caracterización espectroscópica, análisis termogravimétrico, ensayos mecánicos, construcción de figuras para discusión previa a la publicación— en un sistema de agentes de IA que ejecuta las mismas tareas entre 25 y 70 veces más rápido, con coherencia perfecta y sin errores de codificación ni de nomenclatura. El proceso se ha verificado sobre datos científicos previamente tratados de forma manual, lo que permite comparar resultados de ambos flujos sobre el mismo conjunto de muestras. Esa transformación siguió tres pasos que este ensayo describe con detalle: primero, esquematizar el flujo de trabajo y sus dependencias; segundo, automatizar los módulos susceptibles de ello mediante scripts desarrollados con ayuda de la IA; tercero, traducir el sistema automatizado a instrucciones en lenguaje natural para que un agente orquestador lo supervise. Una distinción que recorre todo el argumento: el script es la automatización —procesa, calcula y genera resultados aplicando criterios predefinidos por el investigador—; el agente es el orquestador —ejecuta scripts, verifica entradas y salidas, genera informes de sesión—. Ninguno de los dos sustituye el juicio científico sobre el significado de los datos. Este ensayo explica por qué esa distinción importa, qué ocurre cuando se ignora, y qué implica para la formación de investigadores y para la colaboración entre academia e industria.
Conviene señalar que el problema no se limita al procesado de datos experimentales. El profesor universitario de hoy dedica una fracción desproporcionada de su tiempo a tareas que, en cualquier análisis honesto del espacio de trabajo, son indistinguibles de trabajo administrativo: gestión de correspondencia institucional, redacción de certificados y actas, organización de registros de estudiantes, coordinación de convocatorias, preparación de documentación para agencias de evaluación. Estas tareas comparten exactamente las mismas características que hacen automatizable el procesado de datos: reciben un conjunto de información de entrada, aplican criterios predefinidos y producen un documento o acción de salida. No requieren juicio científico para ejecutarse; lo requieren para definir los criterios y validar el resultado. El espacio de trabajo del investigador académico está saturado de estas dependencias, y su peso acumulado —decenas de horas mensuales en algunos casos— es tiempo sustraído directamente a la investigación, a la docencia de calidad y a la reflexión que genera conocimiento nuevo. La misma lógica de transformación que se aplica al procesado de datos experimentales aplica aquí: esquematizar qué hace cada tarea, identificar cuáles son automatizables, y construir el módulo correspondiente. La IA no va a resolver la burocracia universitaria. Pero sí puede reducir drásticamente el coste cognitivo de gestionarla, devolviendo al investigador el tiempo y la energía para las tareas que ningún sistema puede hacer por él. Conviene precisar, sin embargo, que este potencial tiene límites concretos. Tareas como la revisión de exámenes, los procesos de contratación de personal, la evaluación de convocatorias competitivas o la revisión por pares de artículos científicos exigen juicio experto y responsabilidad que no son delegables en ningún sistema automatizado actual. La IA alivia la carga cognitiva de las tareas más estructuradas y de criterio predefinido; no sustituye la supervisión humana en los procesos que lo requieren.
Lo que la IA hace mejor que cualquier investigador: datos a escala
La ventaja comparativa de la IA en el laboratorio de química es inequívoca en una categoría de tareas: el procesado sistemático, rápido y reproducible de grandes volúmenes de datos de alta dimensionalidad. Este es el cuello de botella que ha ralentizado la ciencia experimental durante décadas y donde la IA produce un beneficio real e inmediato. Sin embargo, como se documenta en la sección 4, ese beneficio tiene un coste creativo cuya magnitud depende críticamente del modo de integración: la IA que asume el procesado de datos libera al investigador; la IA que invade la generación de hipótesis lo reemplaza. La distinción no es cosmética; es la que separa un modelo de trabajo sostenible de uno que degrada la calidad científica a largo plazo.
En espectroscopía, el impacto es particularmente directo. Técnicas como —MS, NMR, IR, Raman, UV-Vis— generan volúmenes crecientes de datos que crean una necesidad urgente de análisis automatizado más allá del sistema tradicional de trabajo.[1] Una revisión en Chem. Rev. de 2025 cubre el estado del arte en IA generativa y técnicas de aumento de datos para espectroscopía abarcando más de 100 revistas en 32 editoriales.[2] En espectroscopía vibracional, 2025 ha consolidado herramientas automatizadas para limpiar y procesar datos —eliminación de ruido, corrección de línea de base, identificación de picos— antes de cualquier interpretación.[3]
En síntesis química, la expansión del espacio explorable es igualmente rotunda. Si antes un grupo de investigación podía explorar decenas o centenares de sistemas, con IA se pueden explorar decenas de miles o incluso espacios con billones de combinaciones. Wang y colaboradores documentaron en Nature cómo la IA está siendo integrada para ayudar a los científicos a interpretar grandes conjuntos de datos y obtener conocimientos que no habrían sido posibles con métodos tradicionales.[4] Lo crítico es que esta integración en el flujo de datos no es lo mismo que la sustitución del científico: es la liberación del científico de las tareas que la máquina puede hacer mejor.
Lo que la IA no puede hacer: creatividad, hipótesis y serendipia
La capacidad de la IA para generar hipótesis genuinamente nuevas —no interpolaciones o recombinaciones del espacio conocido— sigue siendo el límite más robusto de la tecnología actual. Demis Hassabis, inventor de AlphaFold2 y Premio Nobel de Química 2024, lo expresó sin ambigüedad en una entrevista reciente: preguntándose si la IA puede proponer una nueva hipótesis o idea sobre cómo funciona el mundo, respondió su propia pregunta afirmando que, hasta ahora, estos sistemas no pueden hacer eso, y sitúa la verdadera innovación y creatividad en la IA a cinco o diez años vista.[5]
Los resultados del benchmark ChemBench, desarrollado por Mirza, Schwaller, Jablonka y colaboradores y publicado en Nat. Chem. en 2025, confirman esta imagen asimétrica: los mejores modelos de lenguaje superan en promedio a los mejores químicos humanos en pruebas de conocimiento y razonamiento químico, pero fallan en tareas que requieren conocimiento espacial-molecular o razonamiento de seguridad, y producen predicciones con una confianza que no correlaciona con su precisión real.[6] Los LLMs (Large Language Model, modelos de lenguaje de gran tamaño) responden con aparente seguridad incluso cuando se equivocan, un rasgo que amplifica directamente el riesgo de aceptación acrítica de resultados generados por IA.
Esta limitación no es sorprendente si se examina la arquitectura conceptual de los modelos actuales: aprenden de los datos que les han dado para entrenarse. Por definición, no pueden predecir algo muy innovador. En síntesis orgánica, por ejemplo, los algoritmos actuales dan la retrosíntesis lógica —la que se puede calcular—, pero no la retrosíntesis creativa e innovadora que surge de una intuición sobre un mecanismo no descrito. La síntesis química avanza históricamente en esas fronteras.
La serendipia —el hallazgo de algo inesperado y valioso mientras se busca otra cosa— es uno de los mecanismos de avance científico más documentados en química. El grupo de MacMillan en Princeton la convirtió en estrategia sistemática: empleando un flujo automatizado de alto rendimiento y evaluando miles de reacciones diarias entre moléculas nunca combinadas, descubrieron reacciones fotocatalíticas de funcionalización C–H que no existían en la literatura.[6] El elemento decisivo no fue la máquina: fue el diseño del espacio de búsqueda (decisión creativa del científico), la interpretación del resultado inesperado (juicio científico humano) y la capacidad de reconocer la relevancia de lo encontrado. La automatización multiplicó las posibilidades de que ocurriera la serendipia; el químico fue quien la reconoció y la convirtió en conocimiento.
Conviene, sin embargo, no simplificar este argumento. En el dominio del aprendizaje automático aplicado a sí mismo, la frontera de la autonomía está avanzando más rápido de lo que la mayoría de los investigadores experimentales percibe. Lu y colaboradores publicaron recientemente en Nature un sistema —denominado The AI Scientist— capaz de generar ideas de investigación, escribir código, ejecutar experimentos, analizar resultados y redactar el manuscrito completo, con calidad suficiente para superar la primera ronda de revisión por pares de un taller de una conferencia de primer nivel.[7] Esto no es ciencia ficción: es un resultado publicado y replicable. Lo que no es, todavía, es química experimental. El dominio de la IA aplicada a sí misma opera sobre datos perfectamente homogéneos, métricas de evaluación computables y criterios de éxito unívocos. La química experimental tiene datos heterogéneos, irreproducibilidad parcial inherente, y depende del juicio sobre qué resultado es «interesante» —un criterio que no está en los datos.
El coste oculto del modelo equivocado: producir más, comprender menos
La evidencia empírica más incómoda del panorama actual no proviene de reflexiones filosóficas, sino de un experimento controlado con mil investigadores reales. Toner-Rodgers (MIT, 2024) estudió la introducción aleatoria de una herramienta de IA para descubrimiento de materiales en el laboratorio de I+D de una gran empresa estadounidense con 1.018 científicos.[7] Los resultados de productividad son notables: los investigadores asistidos por IA descubrieron un 44 % más de materiales, con un 39 % más de patentes y un 17 % más de innovación en productos. Pero el mismo estudio revela el precio: la IA automatizó el 57 % de las tareas de «generación de ideas», reasignando a los investigadores a evaluar candidatos producidos por el modelo. Resultado: el 82 % reportó reducción en la satisfacción con su trabajo, citando subutilización de habilidades y reducción de la creatividad. De forma reveladora, el tercio inferior de científicos —los menos experimentados— vio poco beneficio; el tercio superior casi duplicó su producción. La IA amplifica el criterio experto; no lo crea ni lo sustituye.
Este hallazgo conecta con un problema conceptual más profundo: las herramientas de IA pueden explotar nuestras limitaciones cognitivas haciéndonos vulnerables a «ilusiones de comprensión» en las que creemos entender el mundo mejor de lo que realmente lo hacemos.[8] Messeri y Crockett, en Nature 2024, identifican el riesgo específico que llaman «ilusión de amplitud exploratoria»: la percepción falsa de que se está explorando todo el espacio de hipótesis posibles, cuando en realidad solo se explora el subconjunto accesible al modelo. Que el ajuste espectral se realice automáticamente no implica que el químico haya interpretado lo que el espectro le está diciendo sobre la estructura o dinámica del sistema. La velocidad sin criterio no es progreso científico; es eficiencia vacía.
Este fenómeno tiene ahora una base empírica cuantificada. Cuando un modelo de lenguaje produce una respuesta sobreconfiada sobre la toxicidad de un compuesto o la viabilidad de una ruta sintética, el investigador que no tiene criterio de dominio independiente no puede detectar el error, precisamente porque el formato de la respuesta es indistinguible del de una respuesta correcta. Bran y colaboradores documentaron este efecto con precisión al evaluar ChemCrow, un agente de IA descrito en la sección siguiente: cuando un LLM evaluador (sin herramientas) intentó juzgar la calidad de las respuestas de GPT-4 frente a las de ChemCrow, fue incapaz de distinguir las respuestas correctas de las alucinaciones. Solo los evaluadores humanos expertos lo consiguieron de forma consistente.[9] La implicación es directa: la evaluación automatizada de resultados científicos generados por IA no puede sustituir al criterio experto, al menos en el estadio actual de desarrollo.
El modelo correcto: IA como procesador, científico como árbitro
La respuesta a la dicotomía no es el rechazo de la IA ni su adopción acrítica. Es una arquitectura de colaboración con división de tareas explícita. Los laboratorios que encuentran el equilibrio más productivo son los que han definido con precisión qué procesa la IA y qué decide el científico, como ilustra la Figura 1.
Un ejemplo reciente en Nat. Chem. Eng. ilustra el modelo con precisión. Dai y colaboradores desarrollaron una plataforma de experimentación autónoma con un «asesor de IA» que realiza análisis de datos en tiempo real y monitorea el progreso del laboratorio. La IA proporciona análisis cuantitativo continuo; las decisiones sobre qué experimentos realizar y cómo interpretar los resultados permanecen en manos del investigador. Con esta arquitectura, el sistema alcanzó una mejora del 150 % en el rendimiento de conducción mixta de polímeros electrónicos e identificó un polimorfo no conocido.[10] El resultado clave no fue la autonomía del sistema sino la complementariedad entre procesado automatizado y juicio humano.
Conviene explicar un concepto técnico antes de continuar, porque aparecerá en la comparativa que sigue y puede resultar opaco para el lector no familiarizado con herramientas de IA. Por defecto, un modelo de lenguaje no recuerda nada entre conversaciones: cada sesión comienza desde cero, como si el interlocutor fuera un desconocido. Esto es una limitación severa para un flujo de trabajo científico donde el proyecto se extiende durante semanas o meses. La tecnología denominada MCP (Model Context Protocol, protocolo de contexto del modelo) permite conectar al agente con fuentes de información externas (archivos del proyecto, registros de sesiones anteriores, bases de datos del grupo) mediante un protocolo estandarizado, de modo que el agente puede consultar el estado del proyecto al inicio de cada sesión sin que el investigador tenga que re-describir todo el contexto. En la práctica, esto significa que el agente puede saber que ayer procesó 15 de las 20 muestras del proyecto y hoy debe continuar con las 5 restantes, sin que nadie se lo indique manualmente. Esto no es inteligencia ni juicio: es una agenda automatizada con estado persistente, análoga a un cuaderno de laboratorio digital que el agente consulta antes de empezar cada sesión de trabajo.
El riesgo silencioso: datos experimentales en servidores de terceros
Existe un riesgo asociado al modelo de trabajo con agentes de IA que el debate actual sobre creatividad y automatización rara vez aborda, pero que tiene implicaciones inmediatas para cualquier grupo de investigación: la confidencialidad de los datos experimentales no publicados. Cuando un investigador utiliza un agente basado en servicios externos (GPT-4, Claude u otros modelos comerciales) para procesar datos de un proyecto en curso, esos datos transitan por servidores de terceros. En un contexto de competencia internacional por prioridad científica y patentes, esto constituye un riesgo real de exposición de propiedad intelectual que la mayoría de los investigadores no evalúa explícitamente antes de usar la herramienta.
El problema tiene tres dimensiones concretas. Primera: los datos previos a publicación (composiciones de materiales, espectros de compuestos nuevos, rendimientos de síntesis no optimizadas) pueden quedar almacenados en los registros del proveedor del servicio de IA, con políticas de retención de datos que varían entre proveedores y que el usuario rara vez lee con detenimiento. Segunda: los modelos de lenguaje entrenados sobre grandes corpus pueden memorizar fragmentos de los datos que procesan; investigadores en seguridad informática han demostrado que es posible extraer datos de entrenamiento de modelos comerciales mediante técnicas de ataque dirigidas. Shanmugarasa y colaboradores documentaron en CHI 2025 que los científicos frecuentemente introducen datos confidenciales en sus interacciones con LLMs sin ser conscientes de los riesgos asociados, y que la naturaleza conversacional de estas herramientas fomenta la revelación de más información de la inicialmente prevista.[11] Tercera: la mayoría de universidades y agencias de financiación carecen de políticas explícitas sobre qué datos experimentales pueden procesarse mediante APIs de IA externas. El investigador opera en un vacío normativo que la velocidad de adopción de estas herramientas ha dejado atrás.
La arquitectura de trabajo descrita en la sección anterior ofrece una respuesta estructural parcial a este problema. En el modelo de scripts locales orquestados por un agente, los datos experimentales se procesan localmente: el script de TGA, el de IR, el de Raman, todos operan sobre archivos en el sistema del investigador. El agente orquestador solo necesita saber si el script se ejecutó correctamente, cuántos archivos procesó y si hubo errores. Los datos crudos y los resultados procesados nunca necesitan salir del sistema local. Lo que sí transita por el servidor externo son las instrucciones en lenguaje natural y los informes de sesión, que contienen metadatos del proyecto, pero no los datos experimentales en sí. Esta separación entre el plano de datos (local) y el plano de orquestación (potencialmente remoto) no es un efecto colateral del diseño: es una ventaja arquitectónica que debe preservarse de forma deliberada. El investigador que envía un espectro completo como prompt a un chatbot comercial para que lo interprete está cediendo datos innecesariamente; el que ejecuta un script local sobre ese espectro y le pide al agente que verifique la ejecución está protegiendo su propiedad intelectual sin perder ninguna capacidad de procesado. La Figura 2 contrasta ambos modelos.
La recomendación operativa es directa: antes de incorporar cualquier herramienta de IA al flujo de trabajo del grupo, el investigador debe responder tres preguntas. ¿Qué datos van a transitar por servidores externos? ¿Cuál es la política de retención de datos del proveedor? ¿Existe una alternativa arquitectónica que mantenga los datos sensibles en el sistema local? Si la respuesta a la tercera pregunta es afirmativa, la arquitectura de scripts locales con orquestación remota descrita en este ensayo proporciona exactamente esa alternativa.
Esta misma lógica de herramientas especializadas orquestadas por un modelo de lenguaje ha sido implementada con éxito en síntesis orgánica por Bran y colaboradores con ChemCrow, que ya habíamos comentado anteriormente,[9] un agente basado en GPT-4 que integra 18 herramientas diseñadas por expertos en química, incluyendo planificación retrosintética, predicción de reacciones, verificación de seguridad y ejecución robótica. El agente planificó y ejecutó de forma autónoma la síntesis de un repelente de insectos y tres organocatalizadores, y guió el descubrimiento de un nuevo cromóforo. La arquitectura de ChemCrow es conceptualmente idéntica a la que este ensayo describe para el procesado de datos experimentales: el LLM no sabe química; razona sobre qué herramienta usar y en qué orden, exactamente como el agente orquestador de nuestro sistema no analiza espectros sino que ejecuta scripts que sí lo hacen. La diferencia entre ambos sistemas no es de principio sino de escala y dominio.
Scheurer y Reuter, en una perspectiva en Nat. Catal. 2025, sintetizan la conclusión operativa desde los laboratorios autónomos de catálisis: el pleno potencial de los laboratorios autodirigidos requiere supervisión humana sostenida para garantizar la curación rigurosa de datos, validar hipótesis generadas por las máquinas y establecer referencias para mitigar errores de la IA.[12] No es una posición defensiva; es la conclusión de quienes están construyendo los sistemas más avanzados del campo.
La posición más directa quizás sea la de Dadfar y colaboradores en Macromol. Rapid Commun.: la verdadera innovación no provendrá de la plena autonomía, sino de una colaboración simbiótica humano-IA donde la intuición, los conocimientos creativos y la experiencia en el dominio científico se armonizan con el poder algorítmico.[13] El químico de materiales que usa IA para procesar sus datos de Raman no está siendo sustituido; está siendo liberado para pensar en qué significa la firma espectral que la IA acaba de representar.
El ensayo estaría sin embargo en deuda intelectual si no nombrara con rigor las posiciones que cuestionan esta arquitectura de complementariedad. Hay voces científicas serias que abogan por una automatización más amplia, no como escenario futuro sino como trayectoria activa. Boiko y colaboradores demostraron en Nature 2023 que sistemas basados en grandes modelos de lenguaje son capaces de realizar investigación química autónoma de extremo a extremo: proponer síntesis, planificar experimentos, ejecutarlos físicamente mediante robótica integrada e interpretar resultados sin intervención humana continua.[14] Su sistema sintetizó con éxito compuestos no previstos en el diseño original. Kitano, por su parte, planteó en 2021 el Nobel Turing Challenge: la hipótesis de que un sistema de IA podría, antes de 2050, realizar una contribución científica de calidad Nobel en biología de sistemas —no como herramienta de un científico humano, sino como agente independiente.[15] Estas posiciones no son especulación marginal; representan la dirección en la que una parte del campo está invirtiendo recursos y talento. El debate sobre dónde situar la frontera entre autonomía de la IA y criterio humano no está cerrado. Este ensayo defiende una posición concreta —el criterio humano es necesario en el estadio actual de desarrollo— pero reconoce que esa posición tiene una vigencia temporal: lo que es indelegable hoy puede dejar de serlo en un horizonte de diez o veinte años. La discusión debe permanecer abierta, no porque la respuesta sea incierta, sino porque la respuesta cambiará.
Transformar el espacio de trabajo: del flujo de dependencias al sistema de agentes
La mejor forma de ilustrar el modelo correcto no es con ejemplos de laboratorios de vanguardia tecnológica, sino con la transformación concreta de un espacio de trabajo real. Todo investigador opera dentro de lo que en ingeniería de sistemas se denomina Sistema de Trabajo: el conjunto de entornos, herramientas, personas y procesos de los que depende para hacer avanzar su trabajo. En un laboratorio de caracterización de materiales, ese entorno de trabajo incluye los instrumentos de medida, los estudiantes de doctorado que procesan datos, el software de análisis, las plantillas de figura y los flujos de comunicación con colaboradores. Cada uno de esos elementos constituye una dependencia crítica, donde cualquier falla o ineficiencia se traduce en un cuello de botella para el avance científico.
La transformación de ese Sistema de trabajo no es un proceso único sino una secuencia de tres pasos distintos que conviene no mezclar, porque cada uno tiene su propia lógica y sus propias herramientas (Figura 3).
El primero es esquematizar. Antes de tocar ninguna herramienta, el investigador debe dibujar el flujo: definir las entradas (inputs) de cada módulo, la lógica de transformación y las salidas (outputs) resultantes. Para cada proceso o persona involucrada en el tratamiento de datos hay que responder esa pregunta concreta. Si la respuesta es «recibe un archivo bruto del instrumento, aplica estos criterios de procesado y devuelve una gráfica formateada», estamos ante una tarea que es susceptible de automatizarse. No requiere juicio científico para ejecutarse; requiere juicio científico para definir los criterios y para evaluar el resultado. Esa distinción —entre ejecutar y juzgar— es exactamente la que determina qué puede delegarse y qué no.
El segundo paso es automatizar. Una vez esquematizado el flujo, se identifican los módulos que pueden convertirse en software: scripts Python, aplicaciones de escritorio, canalizaciones (pipelines) de línea de comandos. Aquí es donde la IA puede ayudar de forma muy concreta: el investigador le describe en lenguaje natural qué debe hacer cada módulo —qué columnas leer, qué transformaciones aplicar, qué criterio estadístico usar para eliminar valores atípicos, qué aspecto debe tener la figura de salida— y el agente genera el script correspondiente en una o dos horas de trabajo conjunto, partiendo de los archivos reales del instrumento. Conviene subrayar lo que ocurre en este paso: la IA ayuda a construir la automatización, pero no es ella quien automatiza. Lo que resulta de este paso son scripts deterministas que aplican criterios predefinidos de forma reproducible. El script es la automatización; la IA fue la herramienta para construirla.
El tercer paso es la orquestación. Traducir ese sistema automatizado a instrucciones en lenguaje natural para que un agente de IA pueda orquestarlo. Aquí es donde entra en juego el agente propiamente dicho: no como analizador de datos, sino como supervisor del flujo automatizado. El agente recibe instrucciones del tipo «hay una carpeta con archivos de esta técnica; ejecuta este script sobre cada uno de ellos; guarda los resultados en esta subcarpeta; verifica que el número de archivos de salida coincide con el de entrada; genera un informe de sesión». El agente no decide qué datos son válidos científicamente: aplica los criterios que el investigador ya definió en el paso anterior e informa si la ejecución fue correcta. Es la diferencia entre pedirle a un asistente que procese cien muestras siguiendo un protocolo escrito —tarea perfectamente delegable— y pedirle que decida cuál de las muestras tiene el comportamiento más interesante —tarea que requiere criterio de dominio que no está en el protocolo.
Esta arquitectura aplica del mismo modo a cada técnica del sistema. El caso del análisis termogravimétrico (TGA) ilustra con precisión qué significa esto en la práctica. El instrumento —un TA Instruments SDT Q600— exporta ficheros de texto con codificación UTF-16 LE y aproximadamente 8400 puntos por muestra: tiempo, temperatura y peso en mg. El script tga_batch_all.py lee cada fichero, localiza el marcador de inicio de datos, extrae las columnas relevantes, normaliza el peso respecto al valor inicial, genera el fichero formateado para visualización y exporta la figura en PNG. Un segundo script convierte en lote todos los ficheros de salida. El agente orquestador lanza ambos scripts sobre la carpeta del proyecto en el orden correcto, verifica que el número de ficheros de salida coincide con el de entrada, e informa si alguno produjo error. La misma lógica se reproduce en cada técnica del sistema: espectroscopía IR, Raman, mecánicas, reología, porosimetría, entre otras, cada una con su propio script especializado y sus propios criterios de procesado encapsulados. El agente no necesita saber de qué técnica se trata: sigue el protocolo documentado para cada módulo. Lo que no hace ningún script ni ningún agente es decidir si la pérdida de masa observada entre 200 y 400 °C corresponde a desorción de disolvente retenido, a degradación de cadenas poliméricas laterales o a una contaminación de la muestra: esa interpretación exige conocer la composición del material, el protocolo de síntesis y el contexto del experimento. El sistema gestiona el tratamiento de datos; la interpretación de los resultados permanece íntegramente en manos del investigador.
Hay un riesgo específico que conviene nombrar sin eufemismos. Si en lugar de darle al agente instrucciones concretas y criterios predefinidos se le pide que «analice los datos y determine cuándo la muestra tuvo el mayor impacto», el agente producirá una respuesta —siempre produce una respuesta— pero esa respuesta será una interpolación estadística sin fundamento fisicoquímico. Es el escenario de alucinación aplicado a ciencia experimental: el resultado parece coherente, está redactado con seguridad, y puede estar completamente equivocado. La barrera contra ese escenario no es tecnológica; es procedimental. El investigador debe definir con precisión qué puede pedirle al agente y qué no puede pedirle, exactamente cómo define qué puede pedirle a un doctorando recién incorporado y qué aún no.
Una vez completados los tres pasos, el sistema resultante es modular y extensible. En el plano experimental, cada módulo corresponde a una técnica de caracterización instrumental: espectroscopía infrarroja, análisis termogravimétrico, ensayos mecánicos uniaxiales, difracción de rayos X, microscopía electrónica de barrido y transmisión, espectroscopía fotoelectrónica de rayos X, área superficial BET, análisis elemental. En el plano computacional, los cálculos de estructura electrónica —DFT y métodos derivados— operan en una capa diferente, con archivos de salida de códigos de simulación y criterios de validación propios. Cuando aparece un nuevo instrumento o técnica, el proceso de incorporación es siempre el mismo: esquematizar el nuevo módulo, desarrollar el script con ayuda del agente y añadirlo a la cadena de procesado. La lógica científica no cambia; solo cambia el adaptador de formato.
Este último punto tiene una implicación práctica inmediata para cualquier investigador que haya cambiado de laboratorio. Cuando los instrumentos son diferentes o más nuevos, los archivos que exportan pueden tener un separador de columnas distinto, una codificación diferente (UTF-16 en lugar de ASCII) o un encabezado con dos líneas más. En el flujo manual, eso significa días de adaptación. En el sistema de agentes, significa actualizar el módulo de lectura del script correspondiente sin tocar el resto de la cadena de procesado. El conocimiento científico de cómo procesar esos datos —los criterios, las correcciones, los umbrales— está encapsulado en la lógica del módulo y se preserva íntegro.
También conviene señalar que el esquema del flujo —la descripción de qué hace cada módulo y por qué— no es únicamente un insumo para el agente. Es en sí mismo un activo científico del grupo: convierte el conocimiento tácito del investigador en un documento auditable, transferible a nuevos miembros del equipo y reutilizable en futuros proyectos. La automatización del procesado tiene como subproducto la explicitación del criterio científico que lo sustenta. Eso tiene valor más allá de la eficiencia.
La tabla siguiente recoge las comparativas de tiempo de un caso de estudio real en un único grupo de investigación de materiales (hidrogeles funcionales y nanomateriales de carbono). Los datos son estimaciones propias del grupo, no validadas de forma independiente, y se presentan como caso ilustrativo, no como evidencia cuantitativa generalizable. El argumento de fondo no es la velocidad: es que el flujo manual no escala y no garantiza coherencia entre figuras ni trazabilidad del procesado. El sistema de agentes procesa cien muestras con el mismo esfuerzo que diez:
Tabla 1: Caso de estudio ilustrativo: comparativa de tiempo manual frente a flujo con agente de IA en proyectos de caracterización de materiales. Estimaciones propias del grupo; no validadas de forma independiente.
| Tarea / escenario | Tiempo manual | Con agente IA | Factor × |
|---|---|---|---|
| FTIR proyecto completo (20 muestras) | 10–14 h | 20–30 min | 25–40× |
| TGA proyecto completo (20 curvas) | 10–14 h | 20–30 min | 25–40× |
| Mecánicas (4 muestras × 5 réplicas) | 4–6 h | 5–10 min | 40–70× |
| Proyecto completo hidrogeles (~60 archivos) | ~31 h – 4 días | ~45 min | ~40× |
| Proyecto nanomateriales (~200 archivos) | 10–15 días | 3–5 h | ~50× |
Es relevante distinguir entre tener scripts y tener agentes, porque la diferencia no es cosmética. Un script falla con un error críptico cuando encuentra un formato de archivo inesperado; el agente diagnostica el problema, identifica la causa y propone la solución en la misma sesión. Un script no tiene memoria entre ejecuciones; el agente mantiene el estado del proyecto entre sesiones y sabe qué muestras ya fueron procesadas y cuáles no. Pero la distinción más importante no está en ninguna de estas capacidades: está en la fila final de la tabla siguiente.
Que ambas columnas muestren ✗ en la validación científica no es un fallo del sistema: es su característica más importante. Revisar visualmente que una figura tiene buena pinta —que la curva no tiene artefactos obvios, que los ejes están bien escalados— no es validación científica. Es control de calidad formal, necesario pero insuficiente.
La validación científica real ocurre cuando el investigador se pregunta:
- ¿son correctas las asignaciones espectrales a la vista de la composición esperada del material?
- ¿La temperatura de degradación térmica es coherente con lo que sé de este sistema?
- ¿El módulo elástico calculado tiene sentido para este tipo de hidrogel a esta concentración?
Esas preguntas no las puede formular el script ni el agente porque requieren conocimiento de dominio que no está en los datos del proyecto actual. Sin esa validación de segundo nivel, los resultados generados en cuarenta minutos son datos con buena presentación, no ciencia. Con ella, son el punto de partida para la interpretación.
Tabla 2: Diferencias funcionales entre un script Python standalone y un agente de IA que orquesta esos scripts. La fila de validación científica es la única que muestra ✗ en ambas columnas: ni el script ni el agente pueden reemplazar el juicio del investigador.
| Capacidad | Solo con script | Con agente IA |
|---|---|---|
| Detectar formato inesperado de archivo | ✗ Falla con error | ✓ Diagnostica y sugiere solución |
| Adaptar código a nueva variante de muestra | ✗ No | ✓ Modifica bajo supervisión |
| Crear script para técnica nueva | ✗ No | ✓ ~1–2 h incluyendo tests |
| Detectar valores atípicos en los datos | ✗ No | ✓ Implementa criterio estadístico |
| Identificar artefactos visuales en la figura de salida (escala de ejes, superposición de curvas, truncado de etiquetas) | ✗ No | ✓ Lee el fichero .agr e identifica el problema |
| Aplicar el mismo modelo a cada técnica (TGA, IR, Raman…) con sus criterios propios | ⚠ Sólo el script activo | ✓ Orquesta todos los módulos |
| Mantener memoria entre sesiones | ✗ No | ✓ MCP + memoria automática |
| Validación científica del resultado | ✗ No | ✗ Siempre requiere al investigador |
La brecha de formación: el problema empieza en el profesorado
La discusión sobre cómo integrar la IA en la formación química se formula casi siempre en términos del alumno: ¿debe aprender Python en el grado? ¿En qué curso? ¿Reemplaza esto a la formación experimental clásica? Estas preguntas son legítimas, pero están mal ordenadas. El problema no empieza en el alumno. Empieza en el profesor.
Un docente que no ha transformado nunca su propio espacio de trabajo con herramientas de IA no puede enseñar a sus alumnos a evaluar si el resultado de esa transformación es científicamente correcto. No porque no sepa química —sabe más que suficiente—, sino porque no ha pasado por el proceso de mapear sus propias dependencias, documentar qué hace cada módulo de su flujo de trabajo, y comprobar empíricamente cuándo el agente se equivoca y por qué. Ese proceso es exactamente el que genera el criterio específico que no se puede transmitir de ninguna otra manera: saber cuándo la corrección automática de línea de base ha eliminado la señal junto con el ruido, reconocer que el módulo de ajuste ha sobreajustado sobre un artefacto experimental, identificar que el valor atípico descartado es, en realidad, la muestra con el comportamiento más interesante. Ese criterio no se lee en un artículo; se construye procesando datos reales y cometiendo errores reales con las herramientas.
El desafío es, por lo tanto, de capacitación docente antes que de reforma curricular. Y es más urgente, porque el desfase está ocurriendo ahora mismo. Los estudiantes tienen acceso a herramientas de IA que sus profesores no dominan en la práctica. Esto genera dos patologías simétricas. La primera es la prohibición reactiva: el docente que desconfía de la herramienta porque no entiende qué hace, y prohíbe su uso por precaución, privando a los alumnos de aprender a usarla con criterio. La segunda, más peligrosa, es la permisividad acrítica: el alumno que automatiza el procesado de sus datos, obtiene figuras perfectas, y no tiene a nadie en el aula que le enseñe a preguntarse si esas figuras son correctas. En ambos casos el resultado es el mismo: se produce más y se comprende menos.
La capacitación del profesorado no requiere que los docentes se conviertan en ingenieros de software. Requiere exactamente lo contrario: que recorran los tres pasos descritos en la sección anterior —esquematizar su propio flujo de trabajo, automatizar los módulos susceptibles de ello, y traducir el resultado a instrucciones que un agente pueda orquestar— desde su conocimiento de dominio y con sus propios datos reales. Aquí aparece una objeción legítima que conviene afrontar directamente: ¿cómo hace esa transición un investigador con treinta años de experiencia cuyo criterio científico se ha construido íntegramente en un flujo de trabajo manual? La respuesta es que ese investigador tiene precisamente la ventaja que el proceso necesita. Su valor no está en aprender a programar; está en ser la referencia contra la que se valida el sistema. El proceso concreto es el siguiente: tomar un conjunto de datos ya procesado manualmente —uno sobre el que el investigador tiene criterio formado y conoce el resultado correcto— y comprobar si el sistema automatizado produce el mismo resultado con los mismos criterios. Las discrepancias revelan exactamente dónde la esquematización del flujo no capturó el juicio implícito del experto. Ese ejercicio —procesar datos conocidos con el sistema y comparar— es la forma más eficiente de desarrollar criterio sobre los límites de la herramienta sin necesidad de abandonar la base de conocimiento propia.
La distinción pedagógica clave es la misma que estructura todo el argumento de este ensayo: enseñar a usar IA como herramienta de procesado de datos dentro de su propio espacio de trabajo es fundamentalmente diferente de enseñar a desarrollar modelos de IA. Un investigador que usa un agente para procesar sus datos espectrales no necesita entender la arquitectura del modelo subyacente, del mismo modo que no necesita entender la electrónica del espectrómetro para interpretar el espectro. Lo que sí necesita —y esto no es opcional— es el criterio para evaluar si el resultado que el agente produce es físicamente razonable. Y ese criterio solo lo puede transmitir quien haya aprendido a ejercerlo. Esta posición no desestima otras vías de formación que se están abriendo paso en distintas universidades: la incorporación de cursos de Python aplicado a química, ciencia de datos o introducción al aprendizaje automático en los grados de química, frecuentemente en colaboración con departamentos de ingeniería química o informática, responde a una necesidad real y complementaria. Algunas universidades internacionales —MIT, ETH Zürich o Stanford entre las más citadas— llevan años integrando estas competencias de forma sistemática en sus programas de ciencias, lo que ha generado un desfase formativo que en el contexto español aún está lejos de resolverse sistemáticamente. El argumento de este ensayo opera en una capa diferente: la del docente como árbitro de criterio científico ante los resultados que esas herramientas producen.
La industria ya ha decidido: universidad y empresa ante el mismo problema
La discusión sobre IA en investigación química se ha desarrollado mayoritariamente en el contexto académico, pero la mayoría de los graduados en química no acaban en universidades ni en centros de investigación públicos. Acaban en empresas farmacéuticas, de materiales, de control de calidad y de desarrollo de producto. Y esas empresas ya han decidido, o están a punto de hacerlo: la IA se implementa. El concepto de transformación del espacio de trabajo que este ensayo describe desde el laboratorio académico es exactamente el mismo proceso que los equipos de ingeniería de sistemas están ejecutando en entornos industriales, con la diferencia de que en la industria la presión temporal es mayor y el debate filosófico sobre la creatividad científica no existe. Lo que existe es presión por reducir tiempos de ciclo, eliminar errores en control de calidad y acelerar la validación. La IA responde a esas necesidades de forma directa.
El problema no es que la industria carezca de químicos con criterio de dominio —las grandes empresas farmacéuticas y de materiales emplean investigadores con doctorado y décadas de experiencia—. El problema es más sutil y más extendido: la ausencia de un proceso sistemático de documentación del criterio científico antes de automatizar. En muchos entornos industriales, el conocimiento de dominio existe pero está en la cabeza del experto, no en un documento de especificación que el sistema de automatización pueda ejecutar y el equipo pueda auditar. Cuando ese experto no está en el bucle de validación de cada resultado —porque el sistema ya corre de forma autónoma— y nadie ha documentado explícitamente qué criterios aplica y por qué, la coherencia interna de la cadena de procesado no garantiza la corrección científica del resultado. Es exactamente el mismo riesgo que en la academia, pero a mayor escala y con consecuencias más directas sobre producto o decisión regulatoria. El proceso de transformación del espacio de trabajo descrito en la sección anterior —mapear, documentar, implementar, validar— no es solo una metodología académica; es el proceso que la industria necesita para que la automatización produzca resultados en los que se puede confiar.
El criterio científico no documentado es el eslabón débil de cualquier cadena de automatización, en la academia y en la industria. Si no está escrito y validado, no puede auditarse. Si no puede auditarse, el sistema es coherente pero no necesariamente correcto.
La colaboración estructural entre universidad e industria tiene aquí su argumento más sólido, y es uno que va más allá del intercambio tecnológico habitual. No se trata de que la academia transfiera herramientas a la industria; se trata de que la academia forme profesionales capaces de actuar como árbitros de criterio dentro de los equipos industriales que implementan IA. El investigador académico que ha transformado su espacio de trabajo aporta exactamente lo que el equipo de ingeniería no tiene: la capacidad de especificar qué hace cada módulo desde el punto de vista del dominio, de validar que el resultado es científicamente correcto, y de identificar cuándo el sistema se equivoca. El ingeniero aporta lo que el investigador no tiene: la infraestructura para escalar esa lógica a miles de muestras, la integración con sistemas de producción y la gestión de la arquitectura de datos. Juntos cierran el ciclo. Por separado, cada uno tiene la mitad del sistema.
Conclusiones
El investigador de hoy opera en un espacio de trabajo lleno de dependencias: personas que procesan datos, instrumentos que exportan archivos en formatos propietarios, software que aplica correcciones, plantillas que dan coherencia visual a los resultados. Muchas de esas dependencias son software puro: reciben unos datos de entrada, aplican una lógica determinada y devuelven un resultado. Pueden —y deben— automatizarse. El proceso para hacerlo no empieza con código; empieza con el mapeo preciso de qué hace cada módulo del espacio de trabajo, documentado desde el conocimiento de dominio del investigador. Una vez documentado ese conocimiento, el agente puede implementarlo, adaptarlo y mantenerlo con una fracción del tiempo que requería el flujo manual.
Lo que ese proceso libera no es tiempo libre. Es capacidad cognitiva redirigida hacia las únicas tareas que no pueden automatizarse: diseñar los experimentos que tienen sentido, formular las hipótesis que el espacio de datos conocido no puede generar, y evaluar si lo que el agente produjo tiene significado científico real. La evidencia empírica, tanto propia como de la literatura, es consistente: cuando la IA ocupa ese segundo dominio sin criterio humano detrás, la calidad se degrada y los errores se propagan sin detección. Cuando se le asigna el primero, el investigador recupera el tiempo para ejercer el segundo.
Las implicaciones son concretas en tres frentes simultáneos. En el laboratorio: transformar el espacio de trabajo identificando qué dependencias son automatizables y construyendo los módulos correspondientes, empezando por las técnicas de mayor carga repetitiva. En la formación: capacitar primero al profesorado en la transformación de sus propios flujos de trabajo, porque el criterio de evaluación de los resultados de la IA no puede enseñarse sin haberlo ejercido. En la colaboración universidad-empresa: construir equipos donde el experto de dominio especifica y valida, y el ingeniero implementa y escala, reconociendo que ninguno de los dos puede hacer bien el trabajo del otro.
Lo que no puede delegarse —en ningún contexto, académico o industrial— es el criterio para saber cuándo el sistema se equivoca. La IA procesa; el investigador decide. La IA aplica los criterios que le hemos documentado; el científico evalúa si esos criterios siguen siendo válidos cuando el resultado aparece. Ese criterio no lo da el agente. Lo da años de trabajo con datos reales, errores reales y conocimiento de dominio que ningún modelo puede aprender porque nunca ha estado en el laboratorio.
Agradecimientos
Los autores agradecen al Dr. Antonio de la Hoz (UCLM) su lectura crítica de versiones previas del manuscrito y sus sugerencias sobre precisión terminológica.