AWS conecto 3 agentes de IA para verificar sustituciones de componentes aeronauticos

Cuando una pieza necesaria deja de fabricarse, no basta con encontrar un componente cuyo nombre sea parecido. El ingeniero debe recuperar las especificaciones; comparar el voltaje, el peso, las interfaces y el intervalo de temperatura; comprobar la geometria de la carcasa; averiguar el plazo de entrega; y reunirlo todo en un documento para su revision. En la aviacion, un error en este proceso puede costar mucho mas que varios dias de trabajo manual.

AWS mostro el prototipo de un asistente que divide esta tarea entre tres agentes especializados. Uno busca piezas adecuadas, otro comprueba las tolerancias tecnicas y el tercero trabaja con la documentacion y con informacion actualizada sobre el ciclo de vida de los componentes. Existe un limite importante: el sistema recopila pruebas y prepara un borrador de evaluacion, pero no autoriza la sustitucion. La ultima palabra sigue siendo del ingeniero.

Como se tramita una solicitud

Imaginemos que una rueda de reaccion para un satelite deja de estar disponible. Un ingeniero pide comprobar el riesgo de que el modelo sea retirado de produccion, encontrar alternativas y compararlas con la pieza original.

Primero, un pequeno componente de planificacion determina la secuencia de acciones. El agente de catalogo busca candidatos en la base de datos de piezas. El agente de evaluacion compara sus especificaciones. El agente de conocimiento recupera informacion de descripciones tecnicas, planos y fuentes web. Si han intervenido varios especialistas, un modelo independiente combina los resultados en una sola respuesta.

Esta separacion no solo resulta util desde el punto de vista organizativo. Cada agente puede acceder unicamente a las herramientas que necesita. El agente de busqueda no puede modificar los resultados de la evaluacion, y el agente de evaluacion no realiza busquedas abiertas de proveedores. Esto reduce la cantidad de acciones imprevistas y simplifica las auditorias.

Donde no se confian los calculos a los modelos

La parte mas solida de la solucion es que las comprobaciones de tolerancias se realizan mediante codigo Python convencional. Para cada categoria de componentes se definen previamente los parametros y las reglas criticas: coincidencia exacta del voltaje, aumento de peso permitido, compatibilidad de interfaces y otras restricciones.

Con los mismos datos de entrada, la comprobacion siempre produce el mismo resultado. Un modelo de lenguaje puede explicar la tabla y redactar un informe, pero no esta autorizado a cambiar estados como «aprobado», «incumplimiento» o «requiere revision». Despues de cada evaluacion, el sistema guarda un registro de acciones, por lo que el revisor puede ver no solo la conclusion, sino tambien el camino seguido para alcanzarla.

Es un buen patron para cualquier proceso de alta responsabilidad. El modelo actua donde hacen falta busquedas, analisis de documentos y texto coherente. El codigo se encarga de las reglas que deben reproducirse sin interpretaciones creativas.

Por que se necesita la busqueda multimodal

Parte de los datos de ingenieria no se encuentra en tablas. El par motor puede aparecer unicamente en un grafico, la posicion de un conector en una fotografia y las dimensiones de montaje en un plano. Amazon Nova Multimodal Embeddings situa el texto y las imagenes en un espacio de busqueda comun. De este modo, una consulta sobre una especificacion puede devolver el diagrama necesario, mientras que una imagen cargada puede encontrar una pieza similar.

Las fotografias de dos componentes tambien se comparan mediante similitud del coseno, tras lo cual el modelo describe las diferencias visibles en los anclajes, los conectores y la forma de la carcasa. Sin embargo, la similitud visual sigue siendo una prueba auxiliar. El resultado de la comprobacion lo determinan los requisitos de ingenieria previamente definidos.

Las limitaciones del enfoque son evidentes. Las reglas de tolerancia deben mantenerse manualmente, la calidad de la respuesta depende de que la base de datos este completa y una busqueda web no sustituye la confirmacion del fabricante. La demostracion utiliza solo siete piezas ficticias, por lo que prueba una idea arquitectonica, no su preparacion para una certificacion real.

La conclusion practica para los desarrolladores es sencilla: no construyan un unico agente omnisciente. Separen la busqueda, los calculos y la preparacion de documentos; trasladen las comprobaciones criticas a codigo determinista; conserven las fuentes y el registro de acciones; y dejen en manos de una persona las decisiones que tengan consecuencias. Es precisamente este limite el que convierte una vistosa demostracion de agentes en una herramienta que puede debatirse seriamente con ingenieros y auditores.