Un artículo publicado por Semiconductor Engineering el 27 de agosto de 2026 propone abordar la introducción de la inteligencia artificial en el diseño de circuitos de radiofrecuencia RF como un proceso gradual, no como un proyecto que requiera sustituir la plataforma actual o reconstruir por completo el flujo de trabajo. La idea parte de un problema práctico: una gran parte de la capacidad de los equipos de RF y microondas depende del conocimiento institucional acumulado por ingenieros experimentados, que incluye metodologías para diseñar amplificadores de potencia, caracterizar dispositivos y tomar decisiones durante el trabajo que no han sido documentadas en un formato reutilizable.
Según el artículo, la pérdida de esta experiencia prolonga el periodo de capacitación de los nuevos ingenieros, ralentiza la evaluación del espacio de diseño y puede conducir a un rediseño cuya necesidad podría haberse detectado probando un número mayor de candidatos. Por ello, la primera pregunta no debería ser si el equipo adoptará la inteligencia artificial, sino cómo construir esta capacidad sin interrumpir las herramientas de las que dependen los ingenieros para producir diseños reales.
Tres etapas que pueden ejecutarse en paralelo
El autor Daren McClearnon, a quien la fuente identifica como director de productos de inteligencia artificial y aprendizaje automático en Keysight, propone un marco de tres etapas: captura del conocimiento, coordinación de herramientas y aceleración de la exploración. Este marco no exige completar una etapa antes de comenzar la siguiente.
Capturar la experiencia y convertirla en activos reutilizables
La fuente señala que la experiencia en RF no suele existir únicamente en el código, sino que se distribuye entre las herramientas, las ecuaciones y la experiencia práctica necesaria para relacionar los resultados de simulación con lo que aparece en el hardware medido. En la etapa de captura, este conocimiento debe convertirse en formatos que el equipo pueda ejecutar y compartir, para posteriormente entregarlo a agentes de software.
- Exportar los esquemas y diseños de layout a código Python con parámetros ajustables.
- Registrar los procedimientos de los expertos en forma de scripts ejecutables.
- Convertir el diagrama de flujo de la simulación en código documentado que los sistemas basados en agentes puedan comprender.
El valor práctico de este paso no reside en utilizar un modelo lingüístico por sí mismo, sino en hacer que la metodología interna sea visible y reproducible, en lugar de permanecer en la memoria de personas concretas.
De escribir scripts a definir el objetivo
La etapa de coordinación aprovecha el conocimiento que se ha capturado. En lugar de que el ingeniero escriba y gestione manualmente cada script, puede definir el resultado deseado, como diseñar un amplificador de potencia MMIC con una ganancia superior a 20 dB y una potencia de salida superior a 28 dBm, y dejar que un modelo lingüístico conectado a las herramientas se encargue de encontrar y activar las herramientas adecuadas.
Según el artículo, esto no equivale a pasar directamente a la autonomía completa. Actualmente, las organizaciones suelen situarse entre la programación manual y el uso de asistentes colaborativos tempranos que comprenden la intención del ingeniero, mientras mantienen una supervisión humana cercana. El siguiente paso son agentes especializados que asumen tareas de varias etapas con delegación parcial, basándose en la misma estructura de coordinación.
Acelerar la exploración manteniendo la física bajo supervisión
La tercera etapa se centra en aumentar el número de diseños que pueden explorarse y reducir el tiempo de espera. La fuente menciona dos herramientas principales: los modelos sustitutos, que reemplazan las costosas simulaciones electromagnéticas por aproximaciones rápidas basadas en redes neuronales y que pueden ser entre dos y tres órdenes de magnitud más rápidas para algunas estructuras; y la optimización asistida por inteligencia artificial, capaz de manejar simultáneamente un número mayor de parámetros y encontrar soluciones adecuadas utilizando menos simulaciones.
Sin embargo, la aceleración no adquiere valor práctico si el resultado no es fiable. Los riesgos destacan especialmente en el encapsulado, las interconexiones, el acoplamiento, la integridad de la alimentación y la tierra, y las corrientes tridimensionales; estos factores pueden hacer que una respuesta rápida y segura se aleje del comportamiento real del hardware y dificulte posteriormente el análisis de la causa raíz de las fallas. Por ello, la física utilizada en el modelado debe compararse con las mediciones reales antes de ampliar el alcance de la delegación al sistema.
¿Qué debe verificarse antes de ampliar la escala?
El marco también subraya la importancia de rastrear el origen de los datos, no solo la calidad del modelo. El equipo necesita saber de dónde proceden los datos de entrenamiento del modelo sustituto, cómo se etiquetaron y limpiaron, y cuáles son sus supuestos y limitaciones conocidas. Esta transparencia es la que determina los límites de la velocidad e impide que se convierta en un riesgo invisible.
La fuente presenta el ejemplo de Sphere Semi, una empresa de diseño de RFIC que se enfrentaba al problema de explorar un diseño cada vez. La empresa adoptó un flujo completamente definido mediante código y basado en Python para ejecutar las etapas de generación, simulación, clasificación y optimización, con cientos o miles de candidatos ejecutados mediante simulación conjunta de circuitos y electromagnetismo. Según las cifras incluidas en el artículo, este enfoque logró un aumento de la productividad de entre 5 y 10 veces, una mejora de 6 dB en el aislamiento y una reducción del 30 % en el área del filtro frente a los procesos tradicionales de diseño manual.
Lectura de certi.news: El cambio real que propone el artículo no consiste en sustituir al ingeniero por un agente independiente, sino en trasladar el conocimiento disperso a flujos ejecutables y después vincularlo con objetivos de diseño claros y herramientas de verificación medibles. Esto hace que la adopción dependa menos de una decisión sobre una única plataforma y más de la calidad de la documentación, los datos y las mediciones. No obstante, los resultados mencionados corresponden a un solo ejemplo tal como lo presenta la fuente, y por sí solos no demuestran que los mismos beneficios se repitan en todos los diseños o entornos. Además, cuestiones como la capacidad de generalización de los modelos sustitutos y sus límites cuando cambian el encapsulado, las estructuras o los datos siguen requiriendo una verificación específica por parte de cada equipo.