Así se construye el túnel submarino más profundo del planeta | Watch
miércoles, 21 de octubre de 2026
Conexión directa con ARMADA AUTÓNOMA 2045 es la justificación de la Fase I 2027–2030: empezar con una Unidad Experimental Multiplataforma Autónoma, aprender, validar y escala.
Autor: Salvador Lechuga Lombos + IA
El artículo de MSN apunta a algo mucho más importante que una simple curiosidad automovilística: estamos viendo la convergencia entre plataforma comercial, electrificación, autonomía e integración militar.
Lo verdaderamente interesante del vehículo
General Motors, a través de GM Defense, presentó en AUSA 2026 un UGV (Unmanned Ground Vehicle) basado en la arquitectura de una Chevrolet Silverado 3500HD.
Pero hay una precisión importante respecto al titular de MSN:
no es todavía un vehículo operacional completamente autónomo del US Army. Es un concepto/prototipo de GM Defense, con demostrador previsto para pruebas funcionales en 2027. news.gm.com
Y eso, paradójicamente, hace que el asunto sea todavía más interesante.
¿Qué incorpora?
- Sin conductor a bordo.
- Arquitectura basada en Silverado 3500HD.
- Capacidad de carga de hasta 8.000 lb ≈ 3.628 kg.
- Orientación a logística autónoma.
- Posibilidad de evacuación de heridos.
- Propulsión híbrida: motor térmico utilizado también como generador.
- Batería de aproximadamente 100 kWh.
- Capacidad de proporcionar energía eléctrica a otros sistemas.
- Sensores, comunicaciones y sistema de autonomía integrados.
- Posibilidad de transportar diferentes cargas/payloads. news.gm.com
Janes señala además que durante AUSA se mostró con un láser de alta energía Locust X3 como carga útil conceptual, aunque eso no significa que el vehículo vaya a entrar en servicio con esa configuración. Default
Y aquí aparece una conexión directa con ARMADA AUTÓNOMA 2045
Este desarrollo de GM encaja extraordinariamente bien con el planteamiento que hemos venido construyendo.
Porque la idea fundamental no es fabricar un vehículo autónomo.
Es fabricar una familia de plataformas autónomas sobre arquitecturas comunes.
Podríamos representarlo así:
PLATAFORMA BASE → AUTONOMÍA → COMUNICACIONES → PAYLOAD → MISIÓN
Y el mismo principio puede trasladarse del ámbito terrestre al marítimo:
UGV → USV → UUV/AUV → UAV → HAPS
Eso cambia radicalmente el enfoque de adquisición.
El equivalente español que yo incorporaría a ARMADA AUTÓNOMA 2045
Crearía un concepto denominado provisionalmente:
TRIDENTE-UGV
o, si queremos mantener una nomenclatura más institucional:
A-2045 UGV — Plataforma Terrestre Autónoma Modular
No necesariamente habría que diseñar un vehículo desde cero.
La filosofía sería:
adquirir una plataforma industrial existente y convertirla en un nodo autónomo modular de la arquitectura TRIDENTE.
Esto es exactamente lo que está haciendo GM Defense: aprovechar una arquitectura industrial/comercial existente en lugar de desarrollar desde cero cada componente. GM afirma explícitamente que su estrategia consiste en transferir tecnología, ingeniería, cadena de suministro y fabricación comercial directamente al ámbito militar. news.gm.com
Pero hay algo todavía más importante
El Ejército estadounidense está dando simultáneamente un paso institucional enorme.
El 13 de octubre de 2026 el Army anunció la transformación de su estructura Futures and Concepts Command en Futures and Autonomous Systems Command (FASCOM).
Y el objetivo ya no es experimentar únicamente con drones.
El propio Army habla de autonomía a través de todas las funciones de combate, incluyendo:
- fuegos autónomos;
- embarcaciones autónomas;
- reconocimiento blindado autónomo;
- brecha/ingeniería autónoma;
- ISR aéreo autónomo;
- transporte aéreo;
- equipos tripulados-no tripulados. www.army.mil
Esto es extraordinariamente significativo para nuestro documento.
Porque confirma una hipótesis central de ARMADA AUTÓNOMA 2045:
La autonomía deja de ser un programa de vehículos y pasa a convertirse en una arquitectura militar.
Y ahí está precisamente el salto conceptual de nuestro proyecto.
No:
"Comprar drones."
Sino:
Construir una fuerza capaz de integrar permanentemente humanos, plataformas autónomas, IA, sensores, comunicaciones y sistemas de decisión.
Incluso podemos extraer una arquitectura comparativa
| EEUU / GM Defense | ARMADA AUTÓNOMA 2045 |
|---|---|
| Silverado 3500HD | Plataforma terrestre española/UE |
| UGV | UGV autónomo |
| 8.000 lb carga | Logística/reabastecimiento |
| Evacuación | CASEVAC/MEDEVAC |
| Batería ~100 kWh | Energía embarcada |
| Sensores + autonomía | Sensores + IA |
| Payload modular | Payload intercambiable |
| Láser conceptual | Sensores/efectores según misión |
| Comunicaciones | TRIDENT-NET |
| UGV | UGV + UAV + USV + AUV |
| Experimentos 2027 | Fase I 2027–2030 |
Y aquí aparece una idea que creo que merece entrar como uno de los ejes del documento definitivo:
"La plataforma como servicio autónomo"
Una misma plataforma física puede cambiar completamente de función dependiendo del software, sensores y carga útil.
Logística → reconocimiento → comunicaciones → evacuación → guerra electrónica → apoyo energético → sensor ambiental, etc.
Eso reduce costes de desarrollo, facilita mantenimiento y permite una evolución tecnológica mucho más rápida.
Además, el Army está adoptando precisamente una filosofía experimental de incorporar y retirar empresas/capacidades a medida que las pruebas demuestran qué funciona, en lugar de esperar a disponer desde el principio de una solución perfecta.
Este es un caso de referencia internacional en ARMADA AUTÓNOMA 2045, porque refuerza muchísimo la justificación de nuestra Fase I 2027–2030: empezar con una Unidad Experimental Multiplataforma Autónoma, aprender, validar y escala.
martes, 20 de octubre de 2026
IA Evolutiva y Adaptativa (III): El Genoma Artificial Evolutivo (GAE)
Arquitectura conceptual, principios de diseño y
programa de validación experimental
Salvador Lechuga Lombos
20 de octubre de 2026
Resumen
Este artículo propone el Genoma Artificial Evolutivo
(GAE) como un marco conceptual para representar, versionar, evaluar y modificar
de forma controlada los componentes de un sistema inteligente. El término
«genoma» se emplea por analogía funcional: no implica equivalencia con un
genoma biológico, reproducción biológica, conciencia ni autonomía evolutiva
ilimitada.
El GAE se plantea como una representación estructurada
de la arquitectura, las funciones, la percepción, los criterios de evaluación,
las restricciones de seguridad, el historial de variantes y los mecanismos de
intercambio entre sistemas. Se propone un ciclo de adaptación que comprende
generación de variantes, evaluación, validación independiente y despliegue
gradual con posibilidad de reversión.
La propuesta se relaciona con disciplinas existentes,
entre ellas la robótica evolutiva, la robótica modular, la evolución encarnada,
la ingeniería de sistemas autoadaptativos y la morfogénesis adaptativa. No se
presenta como una tecnología experimentalmente demostrada, sino como una
hipótesis de integración que requiere especificación, implementación y
evaluación comparativa.
Se introduce un modelo formal mínimo, tres hipótesis
experimentales iniciales y un caso de estudio hipotético basado en vehículos submarinos
autónomos. La contribución pretendida consiste en investigar si una
representación común y versionada de los componentes modificables, sus
dependencias y sus restricciones puede mejorar la trazabilidad, la
reutilización y la gestión de riesgos frente a arquitecturas de referencia.
Palabras clave: inteligencia artificial adaptativa; robótica
evolutiva; evolución encarnada; morfogénesis adaptativa; arquitectura de
sistemas; seguridad; gestión de variantes; Genoma Artificial Evolutivo.
1. Introducción
Los sistemas inteligentes pueden adaptarse mediante
cambios en parámetros, políticas de control, modelos internos o componentes de
software. En robótica, algunas líneas de investigación amplían la adaptación a
la morfología física: la forma, la rigidez o la configuración de un robot
pueden modificarse para responder a diferentes entornos.
Estas investigaciones muestran que la adaptación puede
abarcar varias capas del sistema, aunque cada implementación se enfrenta a
límites físicos, computacionales y de seguridad.
Este artículo plantea el Genoma Artificial Evolutivo
(GAE) como una arquitectura conceptual para organizar esa adaptación multicapa.
La metáfora del genoma se refiere a una representación estructurada y
versionada de los elementos que pueden modificarse dentro de límites
explícitos. No supone equivalencia con el ADN, reproducción biológica,
conciencia ni capacidad de automodificación irrestricta.
La pregunta central es la siguiente: ¿cómo diseñar un
marco que permita proponer, evaluar, seleccionar y desplegar variantes de un
sistema inteligente sin perder trazabilidad, verificabilidad ni control humano?
El objetivo no es afirmar que exista ya una solución
general, sino formular una hipótesis arquitectónica y un itinerario
experimental que permitan someterla a prueba. La propuesta parte de la
posibilidad de que una representación común de los elementos modificables, sus
dependencias, sus restricciones y sus resultados facilite la coordinación de
los procesos de adaptación.
El valor científico del GAE deberá determinarse
mediante comparación con arquitecturas existentes. Será necesario comprobar si
la integración propuesta aporta ventajas medibles en trazabilidad,
reutilización, adaptación o gestión de riesgos y si esas ventajas compensan los
costes adicionales de representación, validación y mantenimiento.
En consecuencia, el trabajo distingue tres niveles:
- Propuesta
conceptual:
definición de los elementos y responsabilidades del GAE.
- Especificación
e implementación: desarrollo de un modelo de datos, interfaces y
mecanismos ejecutables.
- Validación
experimental:
comparación reproducible con arquitecturas de referencia.
El presente artículo se sitúa en el primer nivel y
formula una base para avanzar hacia los dos siguientes.
2. Relación con el estado de la cuestión
La robótica evolutiva estudia métodos inspirados en la
evolución para diseñar o mejorar controladores y, en algunos casos, morfologías
robóticas. Las revisiones del campo destacan tanto su potencial como las
dificultades de trasladar los resultados de simulación al mundo físico
(Doncieux et al., 2015).
La robótica modular y reconfigurable investiga
sistemas compuestos por unidades que pueden conectarse o reorganizarse, con
desafíos específicos de coordinación, fiabilidad, escalabilidad e interoperabilidad
(Alattas et al., 2019).
La evolución encarnada amplía el proceso evolutivo a
robots que interactúan físicamente con el entorno y, en ciertas arquitecturas,
con otros robots. En este ámbito, la selección y la adaptación deben
considerarse en relación con las condiciones reales de interacción, no solo
como problemas abstractos de optimización (Bredeche et al., 2018).
Baines et al. (2024) examinan enfoques de evolución
bajo demanda y estrategias que relacionan la adaptación robótica con cambios en
las capacidades, las configuraciones o las propiedades materiales de los
sistemas. Estos trabajos resultan pertinentes para el GAE porque plantean la
necesidad de definir qué puede modificarse, en qué condiciones y mediante qué
criterios puede evaluarse el resultado.
En otro ámbito, Garrido-García et al. (2026) estudian
cómo una estructura celular programable durante el desarrollo de los ojos
compuestos de Drosophila contribuye a determinar curvaturas locales del
ojo adulto. Este trabajo biológico no demuestra la viabilidad del GAE
artificial, pero constituye un antecedente útil para examinar la relación entre
organización estructural, patrones locales y forma resultante.
La propuesta también se relaciona con la ingeniería
del software para sistemas robóticos autoadaptativos. Sartaj et al. (2026)
presentan una agenda de investigación sobre los desafíos que plantea
desarrollar y mantener sistemas robóticos capaces de adaptarse durante su ciclo
de vida. Entre las cuestiones relevantes se encuentran la arquitectura modular,
la verificación de comportamientos adaptativos y el equilibrio entre
flexibilidad, rendimiento y seguridad.
En materia de gobernanza y gestión de riesgos, el
marco AI RMF 1.0 del National Institute of Standards and Technology (NIST) y la
norma ISO/IEC 23894:2023 ofrecen referencias para organizar la identificación,
evaluación y tratamiento de riesgos de los sistemas de inteligencia artificial
(Tabassi, 2023; ISO/IEC, 2023). Son referencias de gestión de riesgos, no
especificaciones del GAE ni pruebas de su eficacia.
Por tanto, el GAE no se presenta como sustituto de
estas disciplinas ni como una idea surgida al margen de ellas. Se propone como
una posible capa de integración que conecte adaptación funcional, configuración
estructural, evaluación, seguridad, historial y distribución mediante una
representación común.
La hipótesis específica es que esta representación
podría facilitar la coordinación y auditoría de los cambios realizados en un
sistema inteligente. Sin embargo, la integración conceptual no constituye por
sí misma una novedad técnica demostrada.
Para delimitar su contribución será necesario comparar
el GAE con enfoques de gestión de configuraciones, líneas de producto software,
sistemas autoadaptativos, optimización evolutiva y validación de sistemas
críticos. La investigación deberá determinar qué ventajas proceden realmente de
la representación común y cuáles pueden obtenerse mediante la combinación de
técnicas ya existentes.
3. Definición operativa del Genoma Artificial Evolutivo
Se define provisionalmente el GAE como un conjunto
estructurado de descripciones, parámetros, dependencias, restricciones y
metadatos que permite generar y gestionar variantes de un sistema inteligente a
lo largo de un ciclo controlado de evaluación y despliegue.
La unidad evolutiva no tiene por qué ser un único
archivo ni una red neuronal completa. Puede ser una configuración de módulos,
una política de control, un modelo perceptivo, un planificador, una estructura
robótica reconfigurable o una combinación versionada de estos elementos.
Cada variante debe disponer de una identidad
inequívoca, dependencias declaradas, criterios de compatibilidad y un registro
de procedencia. Cuando resulte pertinente, también deberá conservar información
sobre el entorno de evaluación, los resultados obtenidos, las restricciones
comprobadas y la decisión que autorizó o rechazó su despliegue.
El término «evolutivo» describe un proceso de
generación y selección de alternativas, no una garantía de mejora. Una variante
puede ser rechazada, resultar peor que su predecesora o ser válida únicamente
en un entorno delimitado. La mejora debe definirse en relación con objetivos,
condiciones de prueba y restricciones concretas.
El GAE no determina por sí mismo los fines del
sistema. Los objetivos, las restricciones críticas y los criterios de
autorización deben proceder de una especificación gobernada y verificable. El
proceso evolutivo opera dentro de esos límites y no debe poder modificarlos
unilateralmente.
Desde el punto de vista operativo, una implementación
del GAE debería permitir responder a cinco preguntas:
- ¿Qué
componentes constituyen la variante evaluada?
- ¿Qué
cambios la distinguen de la versión de referencia?
- ¿Qué
dependencias y restricciones resultan aplicables?
- ¿Qué
pruebas ha superado y bajo qué condiciones?
- ¿Quién
o qué procedimiento autorizó su despliegue?
Estas preguntas proporcionan un criterio funcional
para evaluar si una implementación materializa realmente el marco propuesto.
4. Módulos propuestos
4.1. Módulo estructural
Describe la composición del sistema, los módulos
disponibles, sus interfaces, dependencias y, cuando proceda, la configuración
física o las posibilidades de reconfiguración. Su finalidad es identificar qué
elementos forman el sistema y qué combinaciones resultan compatibles.
4.2. Módulo
funcional
Representa políticas de control, algoritmos,
parámetros operativos, secuencias de acción y relaciones entre funciones. Debe
especificar qué elementos pueden cambiar, cuáles permanecen fijos y qué
dependencias funcionales deben conservarse.
4.3. Módulo
perceptivo
Registra sensores, modalidades de entrada,
transformaciones de datos, modelos de percepción y sus requisitos de calidad.
Las variantes deben evaluarse frente a cambios de iluminación, ruido, oclusión,
condiciones ambientales u otros factores relevantes para la aplicación.
4.4. Módulo
de evaluación
Define tareas, escenarios, métricas, umbrales y
métodos de comparación. Debe separar los criterios de rendimiento de los
requisitos obligatorios de seguridad y establecer de antemano cómo se medirán
los resultados.
4.5. Módulo
de seguridad y gobernanza
Contiene restricciones que el proceso evolutivo no
puede modificar, permisos de cambio, criterios de aprobación, mecanismos de
parada, auditoría y reversión. Las reglas críticas no deben depender
exclusivamente del mismo mecanismo que genera las variantes.
Este módulo debe identificar las responsabilidades de
autorización y las condiciones bajo las cuales se permite avanzar desde la
simulación a las pruebas físicas y al despliegue operativo.
4.6. Módulo
evolutivo
Gestiona la generación de candidatos, la búsqueda, la
selección, la eliminación de variantes, la gestión de versiones y la
comparación con una línea base. Puede emplear métodos evolutivos, búsqueda,
aprendizaje u optimización, según el problema.
El módulo debe conservar la procedencia de cada
candidato y permitir reconstruir, dentro de las capacidades previstas por la
implementación, cómo se obtuvo una variante y qué evaluaciones superó.
4.7. Módulo
distribuido
Permite compartir resultados entre sistemas o nodos,
manteniendo procedencia, compatibilidad, autenticidad de las variantes y
evaluación local antes de aceptarlas. Compartir una variante no debe equivaler
a desplegarla automáticamente.
La interoperabilidad exige comprobar que una variante
puede ejecutarse en la plataforma de destino y que sus supuestos, dependencias
y restricciones siguen siendo válidos en el nuevo contexto.
Los siete módulos constituyen una propuesta de
organización funcional. No implican que cada implementación deba
materializarlos como componentes de software independientes: una primera
implementación podría integrar varios módulos, siempre que sus
responsabilidades e interfaces quedaran identificadas.
La utilidad de esta división deberá evaluarse frente a
alternativas más simples. Si una arquitectura con menos módulos consigue los
mismos resultados con menor coste y complejidad, esa diferencia deberá
reflejarse en la evaluación del GAE.
5. Modelo formal mínimo
Para evitar que el GAE permanezca únicamente como
metáfora, se propone una formalización inicial. Sea una representación de
referencia del genoma artificial la tupla:
G = (S, F, P, E, C, H, D)
donde:
- S representa la estructura del
sistema.
- F representa las funciones y
políticas.
- P representa la percepción y el
procesamiento de entradas.
- E representa los criterios y
procedimientos de evaluación.
- C representa las restricciones y
controles de seguridad.
- H representa el historial de
versiones, procedencia y resultados.
- D representa las reglas de
distribución e interoperabilidad.
Esta tupla es una propuesta de notación para investigación,
no un estándar establecido ni una implementación formal completa.
Sea (\Omega(G)) el conjunto de variantes candidatas
que pueden generarse a partir de (G) mediante operadores permitidos. Para cada
candidata (g) y contexto de operación (x), se define un vector de objetivos:
[
J(g\mid x)=
\big(J_1(g\mid x),\ldots,J_m(g\mid x)\big)
]
Los objetivos pueden incluir rendimiento de tarea,
consumo energético, fiabilidad y tiempo de adaptación. Cada objetivo deberá
especificar si se desea maximizar o minimizar.
Como estos objetivos pueden entrar en conflicto, es
preferible informar una frontera de Pareto o una regla de selección explícita
en lugar de ocultar todos los compromisos en una única puntuación. La elección
dependerá de los requisitos de cada aplicación.
Se define el conjunto de candidatas admisibles como:
[
A(G,x)=
\left{
g\in\Omega(G):
V(g,x)=\text{aprobado}
\land
C_i(g,x)\leq 0,\ \forall i
\right}
]
En esta expresión, (V) representa el resultado de un
procedimiento de validación definido previamente y (C_i) representa cada
restricción formalizada. La condición (C_i(g,x)\leq 0) expresa que la candidata
satisface la restricción correspondiente bajo la convención matemática
adoptada.
La selección final se realiza dentro de (A(G,x))
mediante una regla de decisión declarada, que puede basarse en prioridades,
ponderaciones explícitas o criterios de optimalidad de Pareto.
Si (A(G,x)) está vacío, no se autoriza el despliegue
de una variante y se conserva la versión estable.
La formulación distingue tres operaciones:
- Generación
de candidatas.
- Comprobación
de admisibilidad.
- Selección
según los objetivos.
Esta separación es importante porque una variante con
buen rendimiento no debe aceptarse si incumple una condición obligatoria de
seguridad.
La validación puede incluir, cuando sea pertinente,
pruebas unitarias, pruebas de integración, simulación, pruebas de robustez,
evaluación adversarial y ensayos físicos graduales. La cobertura de pruebas, la
calidad del modelo ambiental, la corrección de la especificación y la
posibilidad de fallos no anticipados siguen siendo límites relevantes.
En consecuencia, la condición (V(g,x)=\text{aprobado})
debe interpretarse como aprobación dentro de un alcance de validación
declarado. No constituye una garantía universal de seguridad ni demuestra que
se hayan identificado todos los escenarios posibles.
La especificación implementable deberá definir, como
mínimo:
- Los
tipos de datos y las reglas de integridad.
- Los operadores
de variación permitidos.
- Las
dependencias y condiciones de compatibilidad.
- Los
procedimientos y criterios de validación.
- Las
reglas de autorización del despliegue.
- Los
mecanismos de registro, parada y reversión.
El modelo formal mínimo debe entenderse, por tanto,
como una base de trabajo para desarrollar una especificación verificable.
6. Ciclo de
adaptación controlada
El ciclo propuesto consta de seis fases.
Fase 1. Percepción del contexto. El sistema identifica las
condiciones de operación y detecta una necesidad o desviación respecto de los
objetivos previamente definidos.
Fase 2. Generación de variantes. Se producen candidatos a partir de
una versión identificada y mediante operadores permitidos. Cada candidato
conserva su procedencia y las modificaciones introducidas.
Fase 3. Evaluación inicial. Las variantes se someten a
simulaciones o bancos de prueba para descartar las que no satisfagan los
criterios iniciales.
Fase 4. Validación independiente. Los candidatos restantes se
contrastan con requisitos funcionales, pruebas de robustez y restricciones de
seguridad. La independencia del validador debe definirse en términos de
responsabilidades, acceso y capacidad para rechazar variantes.
Fase 5. Despliegue gradual. La variante aprobada puede introducirse
en modo sombra, en un grupo limitado o bajo supervisión reforzada, según el
nivel de riesgo de la aplicación.
Fase 6. Registro y decisión posterior. Se registran los resultados, se
comparan con la línea base y se decide conservar, revertir o retirar la
variante.
El sistema debe conservar una versión conocida como
estable. El despliegue no es la consecuencia automática de una puntuación
elevada: requiere superar las barreras de validación y cumplir las
autorizaciones aplicables.
En sistemas críticos, los cambios de arquitectura,
objetivos o límites operativos deben requerir autorización humana y los
procesos de evaluación o certificación que correspondan. La posibilidad de
revertir una variante debe probarse como parte del procedimiento, no darse por
supuesta.
El ciclo también debe contemplar situaciones en las
que el sistema no pueda generar una variante válida. En tales casos, deberá
mantener el comportamiento seguro definido para la aplicación, solicitar
intervención cuando corresponda o detener la operación si no existe una
alternativa aceptable.
7. Caso de estudio hipotético: vehículos submarinos autónomos
Como escenario de investigación se propone una flota
de vehículos submarinos autónomos dedicada a inspeccionar infraestructuras
marinas. Los vehículos pueden operar bajo distintas corrientes, condiciones de
visibilidad, salinidad, obstáculos y limitaciones de comunicación.
En una primera etapa, el GAE gestionaría variantes de
navegación, fusión sensorial y planificación de rutas, sin modificar la
estructura física. El objetivo sería comprobar si la representación versionada
facilita comparar configuraciones, registrar cambios y seleccionar variantes
que mantengan los requisitos establecidos.
En una segunda etapa, podrían evaluarse
configuraciones alternativas de sensores o módulos intercambiables, siempre que
el hardware admita esos cambios. Las variantes se probarían primero en
simulación, después en un tanque o instalación controlada y, finalmente, en
condiciones de campo delimitadas.
La distribución entre vehículos permitiría compartir
candidatos y resultados, pero cada vehículo comprobaría la compatibilidad y
seguridad antes de aceptar una variante. La aceptación por otro nodo no se
consideraría evidencia suficiente de idoneidad local.
El programa experimental compararía dos condiciones:
- Arquitectura
de referencia:
sistema modular con gestión de versiones y procedimientos convencionales
de evaluación.
- Implementación
del GAE:
sistema con representación común de variantes, dependencias,
restricciones, historial y ciclo de gestión integrado.
Ambas condiciones deberían operar con tareas, recursos
y condiciones de ensayo comparables. Se documentarían las diferencias de
implementación y se evitaría atribuir al GAE mejoras debidas exclusivamente a
algoritmos, hardware o presupuestos computacionales diferentes.
Este ejemplo es hipotético y no describe una flota
construida ni resultados obtenidos. Sirve para mostrar cómo podría
operacionalizarse la propuesta y qué preguntas experimentales debería
responder.
8. Métricas, hipótesis y programa de validación
Un programa de validación inicial debería comparar el
GAE con una arquitectura de referencia que use el mismo hardware, tareas y
presupuesto computacional, pero sin el mecanismo integrado de gestión
evolutiva. La comparación deberá permitir identificar qué efectos proceden de
la arquitectura propuesta y cuáles se deben a diferencias de recursos,
algoritmos o condiciones de prueba.
8.1. Hipótesis experimentales
H1. Trazabilidad. La
implementación del GAE aumenta la proporción de modificaciones cuya
procedencia, resultados de evaluación y decisión de despliegue pueden reconstruirse
de forma verificable.
H2. Adaptación. La implementación del GAE reduce el tiempo necesario
para identificar y desplegar una variante admisible cuando cambian las
condiciones ambientales, sin aumentar de forma inaceptable los fallos o
incumplimientos de restricciones.
H3. Coste de integración. Las ventajas obtenidas en
trazabilidad, reutilización o adaptación compensan los costes adicionales de
representación, validación, almacenamiento y mantenimiento introducidos por la
arquitectura.
Estas hipótesis son propuestas que deben someterse a
prueba. No se presupone que vayan a confirmarse.
8.2. Métricas
Las métricas iniciales propuestas incluyen:
- Rendimiento
de tarea: tasa
de inspecciones completadas y calidad de los datos recogidos.
- Precisión: error de navegación,
localización y detección de anomalías.
- Coste
operativo:
energía por tarea, tiempo total y recursos computacionales.
- Fiabilidad: tasa de fallos, incidentes y
recuperación tras errores.
- Adaptación: tiempo y número de iteraciones
necesarios para responder a cambios ambientales.
- Seguridad: variantes rechazadas por
incumplimiento, fallos no detectados y cumplimiento de restricciones.
- Reconfiguración: coste, tiempo y desgaste
asociados a cambios físicos o de software.
- Transferencia: rendimiento de una variante en
otros vehículos, entornos o misiones.
- Trazabilidad: proporción de cambios con
procedencia, resultados de prueba y decisión de despliegue documentados.
Para cada métrica se especificarán la definición
operacional, la unidad de medida, el método de cálculo, las condiciones de
ensayo y el criterio de comparación.
8.3. Diseño experimental
El protocolo debería fijar de antemano las tareas, los
escenarios, los criterios de exclusión y el análisis estadístico. Conviene
utilizar múltiples ejecuciones cuando corresponda, separar los escenarios de
desarrollo de los de evaluación y documentar tanto los resultados positivos
como los negativos.
Cuando sea pertinente, se informarán el tamaño de
muestra, la variabilidad entre ejecuciones, los intervalos de confianza y el
tamaño del efecto. La significación estadística, si se utiliza, no deberá
confundirse con relevancia práctica.
Una mejora en una métrica no debe considerarse éxito
si degrada de forma inaceptable otra dimensión o incumple una restricción
obligatoria de seguridad. Los umbrales de aceptación deben definirse antes de
conocer los resultados finales para reducir el riesgo de ajustar
retrospectivamente los criterios al comportamiento observado.
Las preguntas experimentales centrales serían:
a) ¿Reduce el GAE el tiempo de adaptación frente a una
arquitectura modular convencional?
b) ¿Mejora la reutilización de variantes entre
plataformas?
c) ¿Qué coste introduce la validación y el
mantenimiento del historial?
d) ¿Pueden mantenerse las restricciones de seguridad
al aumentar el número de variantes y nodos?
e) ¿Qué proporción de las ventajas observadas procede
de la representación común y cuál procede de los algoritmos concretos
utilizados para generar las variantes?
f) ¿Qué complejidad adicional introduce el GAE frente
a una arquitectura de referencia más sencilla?
Estas preguntas permitirían evaluar no solo el
rendimiento global, sino también la contribución específica de la arquitectura.
Los resultados podrían mostrar ventajas, ausencia de diferencias relevantes o
costes que limitaran su utilidad. Todas estas posibilidades deben considerarse
resultados informativos.
9. Riesgos, límites y gobernanza
El principal riesgo conceptual consiste en confundir
la capacidad de generar variantes con la capacidad de mejorar de forma fiable.
La búsqueda puede sobreajustarse a simulaciones, explotar errores de las
métricas o producir configuraciones difíciles de verificar. La transferencia
entre simulación y realidad puede fallar, y la modificación física añade
riesgos materiales que no se resuelven únicamente mediante software.
Por ello, las restricciones de seguridad deben
tratarse como condiciones de admisión y no como objetivos intercambiables por
rendimiento. Se recomienda mantener una versión estable recuperable, separar el
generador de variantes del validador, registrar cada modificación, restringir
permisos, probar en entornos progresivamente más realistas, monitorizar el comportamiento
posterior al despliegue y disponer de mecanismos de parada y reversión.
La distribución plantea riesgos adicionales: variantes
incompatibles, contaminación de datos, pérdida de procedencia o propagación de
errores. Una red de sistemas no debería aceptar una variante por popularidad o
por el resultado de otro nodo sin comprobar su autenticidad, compatibilidad y
adecuación al contexto local.
El GAE tampoco debe describirse como una entidad
autónoma que decide por sí misma sus fines. Los objetivos, las restricciones y
las condiciones de despliegue dependen de decisiones humanas, requisitos
legales y evaluación técnica. La arquitectura propuesta debe incorporar
explícitamente quién puede autorizar cambios, qué cambios requieren aprobación
y bajo qué condiciones se permite la operación.
La gobernanza debe formar parte del diseño inicial. No
basta con añadir controles al final del proceso: los permisos, la trazabilidad,
la separación de responsabilidades y la posibilidad de reversión deben
contemplarse desde la definición de la arquitectura.
También debe reconocerse que ningún mecanismo aislado
garantiza la ausencia de fallos. La seguridad depende de la calidad de la
especificación, las condiciones de operación, la cobertura de evaluación, el
comportamiento del hardware y los procedimientos de supervisión.
10. Discusión: contribución y límites de originalidad
La contribución de este artículo es una propuesta de
integración y organización, no el descubrimiento de un mecanismo biológico ni
la demostración de una nueva clase de inteligencia artificial. Los elementos
que componen el marco tienen precedentes en gestión de versiones, optimización
evolutiva, robótica modular, aprendizaje adaptativo, validación de sistemas y
robótica con morfología variable.
La hipótesis específica del GAE es que una
representación común, explícita y versionada de estructura, función,
percepción, evaluación, seguridad, historial y distribución puede facilitar la
coordinación de esos elementos y hacer más auditable la evolución de sistemas
inteligentes.
Esta hipótesis solo podrá sostenerse si la
arquitectura produce ventajas medibles respecto de alternativas existentes, sin
introducir costes o riesgos desproporcionados. En consecuencia, la originalidad
pretendida debe situarse en la organización e integración de los elementos, no
en la afirmación de que cada uno de ellos sea nuevo por separado.
Para fortalecer la contribución en trabajos futuros,
será necesario implementar un prototipo, especificar un esquema de datos,
definir operadores de variación, describir un validador independiente y
realizar experimentos comparativos. También deberá determinarse si la
denominación «Genoma Artificial Evolutivo» aporta precisión útil frente a
términos ya consolidados o si genera ambigüedad.
La comparación experimental debería incluir, cuando
resulte viable, una evaluación de ablación: retirar o simplificar componentes
del GAE para determinar cuáles aportan beneficios efectivos. Por ejemplo,
podría compararse el marco completo con una versión que mantenga el historial y
la gestión de versiones, pero carezca de una representación integrada de
restricciones y distribución.
Este enfoque permitiría distinguir la contribución de
la organización arquitectónica de los efectos producidos por los mecanismos convencionales
que se incorporen a la implementación.
La evaluación externa y la replicación independiente
serán esenciales. La comparación con sistemas de referencia deberá mostrar qué
ventajas aporta el marco, bajo qué condiciones se producen y qué limitaciones
persisten. Hasta disponer de esa evidencia, las ventajas descritas deben
tratarse como posibilidades que se someterán a prueba, no como resultados
demostrados.
11. Conclusiones
El Genoma Artificial Evolutivo se propone como un
marco para organizar la evolución controlada de sistemas inteligentes que puedan
modificar sus políticas, componentes o configuraciones dentro de límites
definidos. Su valor potencial reside en combinar capacidad de adaptación con
trazabilidad, validación independiente, restricciones de seguridad y gestión de
variantes distribuidas.
La propuesta se conecta con áreas científicas
existentes y no debe presentarse como una tecnología ya demostrada. Su
contribución pretendida consiste en proporcionar una representación común y
versionada de elementos que, en sistemas adaptativos complejos, pueden
gestionarse de forma separada.
El paso decisivo será convertir la arquitectura
conceptual en una especificación implementable y contrastarla experimentalmente
con sistemas de referencia. Hasta entonces, el GAE debe entenderse como una
hipótesis de diseño y un programa de investigación, no como una capacidad
general validada.
La utilidad del marco dependerá de que sus ventajas
puedan medirse, reproducirse y distinguirse de las aportadas por las técnicas
de adaptación subyacentes. Su evaluación deberá considerar conjuntamente
rendimiento, coste, trazabilidad y seguridad.
El resultado de la investigación no debe presuponerse:
el GAE podría aportar mejoras, mostrar ventajas limitadas a determinadas
aplicaciones o resultar menos eficiente que alternativas más sencillas.
Determinar cuál de estas posibilidades se cumple constituye precisamente el
objetivo del programa de validación propuesto.
Nota metodológica
Este documento es un artículo científico-conceptual.
No presenta experimentos originales, datos empíricos nuevos ni resultados de un
prototipo del GAE. Las ecuaciones, los módulos, las hipótesis y las métricas
son propuestas para orientar la formalización y la evaluación futuras.
La bibliografía es selectiva y de carácter
orientativo; no procede de una revisión sistemática exhaustiva de la
literatura. Las referencias se utilizan para contextualizar la propuesta, no
para afirmar que los trabajos citados validen el GAE.
La selección bibliográfica y el análisis del estado de
la cuestión deberán ampliarse en futuros trabajos que requieran una revisión
exhaustiva. Las conclusiones sobre la utilidad, eficacia, originalidad
comparativa y seguridad del GAE deberán someterse a evaluación experimental y
revisión independiente.
Referencias
Alattas, R. J., Patel, S., & Sobh, T. M. (2019).
Evolutionary modular robotics: Survey and analysis. Journal of Intelligent
& Robotic Systems, 95, 815–828. https://doi.org/10.1007/s10846-018-0902-9
Baines, R., Fish, F., Bongard, J., &
Kramer-Bottiglio, R. (2024). Robots that evolve on demand. Nature Reviews
Materials, 9, 822–835. https://doi.org/10.1038/s41578-024-00711-z
Bredeche, N., Haasdijk, E., & Prieto, A. (2018).
Embodied evolution in collective robotics: A review. Frontiers in Robotics
and AI, 5, Article 12. https://doi.org/10.3389/frobt.2018.00012
Doncieux, S., Bredeche, N., Mouret, J.-B., & Eiben,
A. E. (2015). Evolutionary robotics: What, why, and where to. Frontiers in
Robotics and AI, 2, Article 4. https://doi.org/10.3389/frobt.2015.00004
Garrido-García, J., Walther, R. F., Torres-Tirado, J.,
Andrés-San Román, J. Á., Sanz-Herrera, J. A., Pichaud, F., Casares, F., &
Escudero Cuadrado, L. M. (2026). A natural programmable metamaterial controls
3D curvature of compound eyes. Nature Communications, 17, Article 5553. https://doi.org/10.1038/s41467-026-74276-6
International Organization for Standardization, &
International Electrotechnical Commission. (2023). ISO/IEC 23894:2023:
Information technology—Artificial intelligence—Guidance on risk management.
https://www.iso.org/standard/77304.html
Sartaj, H., Ali, S., Cavalcanti, A., Esterle, L.,
Gomes, C., Larsen, P. G., Tefas, A., Woodcock, J., & Zhang, H. (2026).
Software engineering for self-adaptive robotics: A research agenda. ACM
Transactions on Software Engineering and Methodology, 35(9), Article 276,
1–44. https://doi.org/10.1145/3828754
Tabassi, E. (2023). Artificial intelligence risk
management framework (AI RMF 1.0) (NIST AI 100-1). National Institute of
Standards and Technology. https://doi.org/10.6028/NIST.AI.100-1
Suscribirse a:
Entradas (Atom)