Cómo recuperar hardware sin soporte con inteligencia artificial: método y cuatro casos reales

Un dispositivo rara vez funciona solo. Necesita software en el ordenador y, cada vez más, servicios remotos. Cuando una de esas piezas desaparece o deja de ser compatible, el aparato puede quedar inservible con la electrónica intacta. Estas son las capas que conviene distinguir:

• Controlador (driver): el software que permite al sistema operativo hablar con el dispositivo. Es la pieza que suele romperse cuando cambia la arquitectura (por ejemplo, de Intel a Apple Silicon) o el kernel.
• Firmware: el programa que corre dentro del propio aparato. Grabar uno equivocado es la operación más arriesgada de todas.
• Aplicación: el software que configura el equipo o gestiona sus datos, como el editor de sonidos de una unidad de audio.
• Protocolo: el conjunto de mensajes que intercambian el ordenador y el dispositivo, por USB, MIDI, Bluetooth o la red.
• Servidor externo (backend): el servicio remoto que recibe y procesa los datos. Si el fabricante lo apaga, el dispositivo pierde las funciones que dependían de él.

Hablamos de obsolescencia de software cuando la pieza que falta deja de mantenerse: un driver abandonado o una nube cerrada. La incompatibilidad puede darse con productos que se siguen vendiendo, como una revisión nueva de un modelo con otro chip. La avería física es otra cosa: un motor roto, un condensador agotado o un conector dañado no se arreglan con software, y ninguno de los métodos de este artículo los resuelve.

En los casos documentados, los asistentes de programación aportan sobre todo velocidad en tareas que antes eran lentas y tediosas. Lo que pueden hacer, con las evidencias adecuadas:

• Leer y explicar código heredado, incluido código de kernel o de controladores escrito hace décadas.
• Sustituir APIs obsoletas e iterar sobre los errores del compilador hasta que el código compila.
• Comparar registros del sistema de una ejecución que falla con los de una que funcionaba.
• Leer capturas largas de tráfico USB, detectar patrones (una secuencia que se repite con un byte distinto) y proponer qué significan.
• Desensamblar el firmware de una ROM volcada y describir comandos no documentados.
• Escribir pruebas que confirmen o descarten una hipótesis, y adaptar un backend para ejecutarlo en local.

No sustituye al hardware de referencia ni a la documentación que no existe, no decide si el resultado es correcto y no sabe qué revisión de placa tienes delante. Hacen falta el aparato, permisos para operar con él, revisión humana del código y pruebas físicas. Sin observaciones fiables, la IA produce código plausible que nadie puede comprobar.

Recuperar un dispositivo no siempre exige ingeniería inversa, y conviene no meter todo en el mismo saco. Son intervenciones distintas, con riesgos distintos:

• Modernizar un driver: adaptar un controlador que ya existe a las interfaces de un sistema actual. Se parte de código conocido.
• Ingeniería inversa: deducir cómo funciona algo sin su documentación, a partir de su comportamiento (capturas, paquetes) o de su código binario.
• Sustituir el backend: ejecutar en local, o reescribir, el servicio remoto del que dependía el dispositivo.
• Emular: reproducir un equipo en software. Sirve para usar programas o datos antiguos, pero no repara una unidad física.

No hay una receta que funcione con cualquier aparato. Lo que sí se repite en los casos documentados es un ciclo: reunir evidencias, formular hipótesis, hacer cambios pequeños y contrastarlos con el equipo. Este es un método prudente, construido a partir de ese patrón:

La petición importa tanto como el modelo. Este ejemplo ilustrativo, que no corresponde a ninguno de los casos reales, aplica los pasos 3 y 4: aporta evidencia concreta, pide hipótesis comprobables y cambios reversibles, y pone límites a lo que el asistente puede proponer.

Contexto: unidad de cinta antigua en un Linux actual. El módulo compila y carga,
pero el sistema no detecta la unidad.

Adjunto dos registros del sistema:
  1) la carga actual, que falla;
  2) una lectura correcta que guardé en el sistema antiguo.

Tarea:
- Enumera las diferencias relevantes entre ambos registros.
- Para cada una, propón una hipótesis, qué dato la confirmaría o la descartaría
  y un cambio mínimo y reversible para probarla.
- Indica qué parte está en los registros y qué parte es deducción tuya.
- No propongas escribir en la unidad, formatear ni modificar firmware.

Sirven tanto si desarrollas tú el proyecto como si vas a usar el de otra persona. Son una recomendación editorial, no una certificación de los proyectos citados.

• Tarea concreta: qué función debe volver a funcionar y en qué condiciones.
• Salida correcta: cómo sabrás que el resultado es bueno y con qué referencia lo comparas.
• Entorno probado: qué sistema, versión y revisión del hardware se han probado de verdad.
• Fallos y reversión: qué pasa si algo falla y cómo se vuelve al estado anterior.
• Confianza en el software: de dónde sale el código, quién lo ha revisado y qué permisos pide.
• Mantenimiento: quién se ocupará del código cuando vuelva a cambiar el sistema operativo.

Los cuatro casos cubren las tres situaciones típicas: un driver incompatible, una aplicación o un protocolo que había que reconstruir y un servidor que desapareció. Para cada uno respondemos a las mismas cinco preguntas. Los datos proceden de los autores de cada proyecto, consultados el 3 de noviembre de 2026.

El Eleven Rack de Avid es una unidad de audio para guitarra que se conecta por USB. Según Production Expert, el hardware seguía funcionando bien, pero no era compatible con los Mac actuales. A su alrededor hay dos proyectos distintos, de autores distintos y con objetivos distintos.

• Qué dejó de funcionar: el driver para Mac con Apple Silicon y, por otro lado, la dependencia del editor de Avid para gestionar los sonidos guardados en la unidad.
• Evidencias disponibles: para el editor, el tráfico USB/MIDI de la propia unidad. Eleven Edit, de Charles Wardick, dedujo el protocolo SysEx por análisis directo de paquetes, sin usar software ni firmware de Avid, y toma como referencia conceptual ElevenHack, el trabajo de ingeniería inversa que Guillaume Schmid publicó en 2013. El driver de Matt Housley no detalla su método en el README.
• IA y persona: el commit inicial del driver figura como coescrito con Claude, y Eleven Edit declara haberse construido con Claude Code. Su autor dejó fuera la configuración del pedal y la integración con Pro Tools porque no tiene el equipo necesario para deducirlas y probarlas con seguridad.
• Resultado documentado: el driver funciona en espacio de usuario como un plug-in de Core Audio, sin extensión de kernel, en macOS 13 o posterior con Apple Silicon; la unidad aparece en Audio MIDI Setup y en las aplicaciones de audio como dispositivo de 8 entradas y 6 salidas. Eleven Edit edita y respalda los sonidos en Windows 10 y 11.
• Límites: el instalador del driver no está firmado con un certificado de desarrollador de pago, así que macOS pide aprobarlo una vez. Eleven Edit necesita el driver USB de Avid, solo se ha probado en Windows y está validado con el firmware 2.0.1: si la unidad tiene otro, se detiene.

Dmitry Brant recupera datos de cintas QIC-80, un formato de copia de seguridad que se conectaba a la controladora de disquete del PC. Aquí hay dos trabajos que conviene separar: modernizar un driver existente, que no es ingeniería inversa, y emular la unidad, que sí lo es.

• Qué dejó de funcionar: ftape, el driver de Linux para estas unidades, llevaba sin mantenimiento desde aproximadamente el año 2000 y se retiró del kernel en la versión 2.6.20. Para usarlo, Brant tenía que arrancar un Linux de hace dos décadas.
• Evidencias disponibles: el código fuente del driver original, los errores del compilador, los registros del sistema y un registro guardado de una lectura correcta. Para la emulación, un volcado de la ROM de la unidad y una foto de su placa.
• IA y persona: según su relato, Claude Code sustituyó las APIs obsoletas hasta que el driver compiló como módulo independiente. Brant cargó el módulo él mismo, porque requiere privilegios de administrador, y fue pegando los registros para compararlos con la lectura correcta; así apareció un problema de configuración que impedía detectar la unidad. Corrigió código a mano y subraya que sin su experiencia previa con C y módulos del kernel no lo habría conseguido. Para emular una unidad QIC-117 en 86Box, la IA desensambló el firmware de la ROM y describió los comandos de diagnóstico propios del fabricante, que no están documentados.
• Resultado documentado: el driver cargó, detectó la unidad y volcó una cinta de prueba. El repositorio de ftape indica pruebas en Xubuntu 24.04 y 26.04 y en Debian 12.12, con kernels 6.1 o posteriores. La emulación permite que el software de copia original, dentro del emulador, trabaje con imágenes de cintas ya volcadas.
• Límites: el proyecto prioriza la lectura frente a la escritura, avisa de que queda mucho por probar y de que el autor dispone de pocas unidades. Sigue necesitando una controladora de disquete compatible o el puerto paralelo. La emulación trabaja con imágenes binarias y no repara ninguna unidad física.

Hello Sense era un monitor de sueño: una esfera con sensores ambientales y un sensor de movimiento para la almohada. Es el caso de sustitución del backend: el aparato dependía de unos servidores que dejaron de existir.

• Qué dejó de funcionar: la empresa cerró en junio de 2017 y apagó sus servidores, así que la aplicación dejó de mostrar datos.
• Evidencias disponibles: no era una caja negra. Hello había publicado en GitHub casi todo su software, desde la aplicación y el backend hasta el firmware. A eso se sumaron la documentación del fabricante del chip y pruebas empíricas.
• IA y persona: según el relato de Joseph Spurrier, la IA localizó ese código y ayudó a ejecutarlo en local. La parte difícil fue física: cada esfera cifraba sus comunicaciones con una clave propia, y extraerla exigió desmontarla, cablear un adaptador y entrar en modo de depuración. El bloqueo se resolvió con una pregunta del autor sobre la alimentación del adaptador, mientras el modelo daba la conexión por buena y buscaba el fallo en el protocolo. También hubo un error serio: se grabó en el sensor de almohada el firmware de otra revisión, el sensor dejó de responder y recuperarlo llevó unos diecinueve días y hardware de depuración adicional.
• Resultado documentado: el autor describe el sistema completo funcionando con un backend propio. Según el repositorio hello-sense, los algoritmos de sueño son los de Hello, en Java y sin cambios; lo reescrito es la infraestructura, que pasó de dieciséis contenedores a tres componentes.
• Límites: es un proyecto personal pensado para un solo usuario. El firmware cubre el Sense original; el modelo posterior con voz usa otro chip y no está cubierto. Las dos revisiones del sensor de almohada comparten chip pero no el firmware. El repositorio incluye material de Hello sin licencia y pide revisar sus avisos antes de redistribuir nada. Por nuestra parte, añadimos que no es un sistema validado para uso médico.

No todo dispositivo sin soporte es un producto abandonado. Christian F. K. Schaller compró un escáner de negativos Plustek OpticFilm 8200i porque figuraba como compatible con Linux. Después descubrió que la versión nueva usa un controlador Genesys GL128 sin soporte; el modelo anterior con el mismo nombre, con otro chip, sí funcionaba con SANE, el sistema de escáneres de Linux.

• Qué dejó de funcionar: nada se había roto. Faltaba soporte en Linux para una revisión concreta del producto.
• Evidencias disponibles: al principio, solo pruebas a ciegas. Después, capturas del tráfico USB del driver del fabricante, ejecutado en una máquina virtual con Windows, durante escaneos que funcionaban.
• IA y persona: en marzo de 2026 Schaller describía su primer intento como «un fracaso enorme»: había logrado que SANE detectara el escáner y controlar el motor y la lámpara, pero ni una imagen reconocible, y sin experiencia en drivers no sabía hacia dónde orientar a la IA. En su relato de octubre cambia de método: la IA lee miles de líneas de captura, detecta secuencias que se repiten con un byte distinto, propone qué significan y escribe la prueba que lo confirma. Él decide qué construir y comprueba los resultados en su escáner; en sus palabras, el hardware real es el único juez.
• Resultado documentado: el primer escaneo reconocible llegó en pocas horas y, en días, un driver casi completo, con infrarrojos.
• Límites: el propio autor pide tratar sus resultados como un único dato: una sola unidad, y su herramienta solo está probada en el 8200i. Además, otra persona añadió por su cuenta soporte para este escáner al backend genesys de SANE en septiembre de 2026. Ese soporte no procede de su proyecto, y Schaller espera usar el driver oficial cuando alcance las mismas funciones.
• La lección: el mismo equipo, con la misma IA, pasó del fracaso a un resultado cuando hubo un comportamiento correcto con el que comparar. La observación de referencia vale más que la confianza en el código generado.

Que algo compile, cargue o aparezca en el sistema es un paso intermedio. La tabla resume, para cada caso, qué componente faltaba, cómo intervino la IA, qué evidencia de funcionamiento existe y cuál es su límite principal.

Elaboración propia a partir de las fuentes enlazadas en cada caso, consultadas el 3 de noviembre de 2026. Las pruebas son de los autores de cada proyecto, no de DatIACode, y ninguna fila es una validación independiente.

Recuperar el software tiene sentido cuando el dispositivo aporta algo que no se consigue de otra forma —un formato de datos, una calidad o una función concreta— y existe una manera de comprobar el resultado. Hay situaciones en las que no conviene intentarlo, o no sin más preparación:

• Avería física: si el fallo es electrónico o mecánico, el problema no es el driver.
• Alternativa mantenida: si ya existe un driver con soporte o un repuesto razonable, suele ser mejor camino. El caso del escáner lo muestra: el soporte oficial llegó por otra vía.
• Datos irremplazables sin copia: cualquier prueba debería partir de una copia o de un modo de solo lectura.
• Sin forma de comprobar: sin una referencia fiable, no sabrás si el resultado es correcto.
• Consecuencias graves de un fallo: equipos médicos, industriales o de seguridad necesitan otro nivel de validación.
• Sin responsable: si nadie va a mantener el resultado, el próximo cambio de sistema lo volverá a dejar fuera.

Antes de empezar, revisa las licencias del código que reutilizas, las condiciones de uso del dispositivo y las normas aplicables en tu jurisdicción; la licitud de la ingeniería inversa depende del contexto y este artículo no ofrece una conclusión jurídica. Trata el código generado con ayuda de IA como cualquier código de terceros: revísalo antes de darle permisos elevados, como explicamos en código generado por IA y ciberseguridad.

El patrón no es exclusivo del hardware doméstico. En las empresas hay instrumentación industrial, lectores, impresoras especializadas o equipos de laboratorio que siguen funcionando y quedan fuera cuando se actualiza el sistema operativo, el servidor o la aplicación que los integraba. Sustituirlos puede ser caro, y mantener un equipo antiguo solo para usarlos es un riesgo operativo.

Los mismos principios sirven para decidir: definir la función mínima que hay que conservar, reunir evidencias del comportamiento correcto, hacer cambios pequeños y verificables y tener claro quién mantendrá el resultado. Es el mismo salto que separa un prototipo de un sistema mantenible, que tratamos en IA generativa en empresas. La diferencia está en el nivel de validación: en un entorno productivo, «funciona en mi equipo» no basta, y la decisión de reparar o sustituir debe incluir el coste de mantener lo recuperado.