· 7 min de lectura · IA para Empresas
Lo que la ley te deja hacer con tu propio ERP cerrado, lo que no, y la cláusula del contrato que no vale nada aunque la hayas firmado.
Este mes se ha hecho viral en GitHub un proyecto llamado REA, Reverse Engineer Anything, que conecta agentes de IA como Claude Code o Codex con herramientas clásicas de ingeniería inversa. InfoQ cifraba en octubre sus estrellas por encima de las doscientas mil. El titular que ha circulado es "la IA ya copia cualquier aplicación", y con él la ingeniería inversa con IA ha pasado de ser cosa de tres frikis a ser una pregunta de dirección.
Si tienes una distribuidora o una empresa de servicios, la pregunta que te importa no es si podrías clonar Photoshop. Es otra, más aburrida y más rentable: ese programa que lleva quince años en tu empresa, sin documentación y sin API, ¿se puede abrir? La respuesta es que sí, y que la parte difícil ya no es técnica. Es saber dónde está la raya.
No recupera el código fuente: el propio proyecto dice que no lo pretende. Pone desensambladores y analizadores —Ghidra, IDA, Hopper— al alcance de un agente, que ya puede mirar un binario, seguir las llamadas entre funciones, formular una hipótesis de cómo está hecha una función y comprobarla. También analiza aplicaciones de JavaScript o Electron y ensamblados .NET sin motor nativo.
Lo relevante es el coste. Lo que era una semana de un especialista carísimo ahora son horas de un agente supervisado por alguien que sepa leer lo que sale. No es una capacidad nueva: es una de siempre, diez veces más barata. Y cuando algo se abarata así, lo empieza a hacer gente que antes no se lo planteaba, con los frenos sin poner. Ahí está el riesgo, no en el repositorio.
El escenario no tiene nada de exótico. Un ERP vertical de 2011, el fabricante absorbido, un módulo que nadie sabe cómo calcula los descuentos por escalado, un fichero de exportación con formato propio que no documenta nadie, y una integración que el proveedor te presupuesta en cinco cifras porque sabe que no tienes alternativa.
Eso no es un problema de propiedad intelectual ajena. Es tu sistema, tu licencia y tus datos. Hasta hace poco la única salida era pagar el peaje o cambiar de ERP, el proyecto de dos años que nadie quiere. Hay una tercera vía, la que ya contábamos al explicar cómo conectar la IA con tu ERP sin cambiar de ERP: entender cómo habla tu sistema y hablarle en su idioma.
Tres usos concretos, y en los tres el objeto de estudio es un sistema del propio cliente:
Reconstruir el esquema de una base de datos que nadie documentó. Cientos de tablas con nombres de ocho caracteres y campos llamados CAMP01. El agente cruza la estructura con datos reales y con las pantallas de la aplicación hasta deducir qué significa cada cosa. Es el paso previo a cualquier automatización: sin saber dónde vive el dato, no hay agente que lo lea.
Descifrar formatos de fichero propios. El albarán que tu ERP escupe en un .dat con posiciones fijas y sin especificación. Se analiza el formato, se escribe un lector y se acabó el copia-pega manual.
Averiguar cómo pide los datos una aplicación interna para pedírselos igual, cuando no hay API publicada pero sí una aplicación que por dentro la está usando.
En los tres casos el sistema es de su propiedad o está bajo su licencia, el encargo va por escrito y el resultado es un conector, nunca un sustituto. Cuando lo que hace falta de verdad es una herramienta nueva, la construimos como software a medida y no como una copia de nada.
Aquí es donde casi todo lo que se ha escrito este mes es ruido. En la Unión Europea esto está regulado desde hace décadas por la Directiva 2009/24/CE sobre protección jurídica de los programas de ordenador, transpuesta en España en el texto refundido de la Ley de Propiedad Intelectual, y dice tres cosas que conviene no mezclar.
Mirar cómo funciona es libre. El usuario legítimo de una copia está facultado para observar, estudiar o verificar su funcionamiento sin pedir permiso a nadie, mientras lo haga en operaciones que tiene derecho a realizar. Determinar las ideas y los principios que hay detrás de un programa no infringe nada.
Tocar el código solo vale para interoperar. La reproducción o traducción del código sin autorización es legítima cuando es indispensable para obtener la información necesaria para que otro programa, creado de forma independiente, funcione con el primero. Con tres condiciones: que lo haga quien tiene licencia o alguien en su nombre, que esa información no estuviera ya disponible de forma fácil y rápida, y que se limite a las partes necesarias. Y con dos prohibiciones que son las que de verdad separan el conector del plagio: esa información no puede usarse para otros fines, ni comunicarse a terceros salvo lo necesario, ni servir para desarrollar o comercializar un programa sustancialmente similar en su expresión.
Y la cláusula del contrato que lo prohíba todo es nula. La Directiva declara nula y sin efecto cualquier disposición contractual contraria a la descompilación para interoperabilidad y a la facultad de observar y estudiar. Es decir: si tu contrato de mantenimiento te prohíbe mirar cómo funciona tu propio ERP para conectarlo con otra cosa, esa cláusula no vale. Merece la pena releer el contrato antes de aceptar un presupuesto de integración, igual que merece la pena hacer las preguntas incómodas a un proveedor de IA antes de firmar.
Esa nulidad protege la interoperabilidad. No protege nada más. Porque en paralelo corre la Ley de Secretos Empresariales, y ahí la obtención de información por observación, estudio, desmontaje o ensayo de un producto es lícita cuando el producto está a disposición del público o lo tienes en posesión lícita, y además no estás sujeto a ninguna obligación que válidamente te impida obtenerla así. Traducido: fuera del carril de la interoperabilidad, un acuerdo de confidencialidad o una cláusula de uso sí te pueden cerrar la puerta.
Así que la frontera práctica es esta. Analizar lo que tienes, para conectarlo: carril protegido, y el contrato no puede quitártelo. Analizar el producto de otro para entenderlo: normalmente lícito, salvo que hayas firmado lo contrario. Analizar el producto de otro para rehacerlo: fuera.
Un conector que entiende tu ERP sigue siendo un conector sobre un ERP viejo. Si el sistema está a punto de dejar de cumplir —y la obligación de facturación electrónica entre empresas viene con requisitos técnicos que alguien tiene que certificar—, la ingeniería inversa compra tiempo, no soluciona la decisión de fondo. Rehacer por tu cuenta un módulo de facturación significa heredar esa carga de cumplimiento entera, y ese cálculo lo hemos planteado antes al hablar de si es legal procesar facturas con IA.
Lo segundo: nada de esto recupera código fuente. Deduces comportamiento, no obtienes el original, y lo deducido hay que mantenerlo cuando el fabricante actualice. Y lo tercero, lo más incómodo: un agente puede equivocarse en una hipótesis y dejarla escrita con toda la seguridad del mundo. Sin alguien que sepa leer un desensamblado, esto no es una herramienta: es un generador de conclusiones plausibles.
En la auditoría gratuita de procesos miramos qué parte de lo que te bloquea es técnica y qué parte es solo falta de documentación. Treinta minutos. Si la respuesta es que toca cambiar de sistema, también te lo decimos.
Transparencia: este artículo contiene partes generadas con un agente de IA de MALDITAIA y se ha publicado con aprobación humana. Predicamos con el ejemplo.
Volver al blog de MalditaIA · Solicita una consultoría gratuita