La seguridad del código propietario frente a la IA ya no es un tema para tu CISO dentro de seis meses, es un tema para ti esta semana. En un proyecto reciente con Extra Dev, vimos a un cliente perder dos días rastreando lo que un becario había pegado en un asistente de IA de consumo antes de que bloqueáramos el acceso, por una corrección que normalmente lleva una hora.

  • 📊 Vulnerabilidad persistente, el 45% del código generado por IA contiene una vulnerabilidad OWASP conocida, incluso cuando compila a la primera.
  • ⚠️ Fuga en 20 días, ingenieros de Samsung transmitieron código fuente confidencial a ChatGPT en 2023, sin posibilidad de recuperarlo.
  • 🔓 Ofuscación muerta, Claude desensambló 5 MB de su propio código minificado en 30 minutos, sin que hiciera falta pedírselo dos veces.
  • 🛠️ Veredicto operativo, ni bloqueo total ni acceso libre: la pasarela controlada con especificaciones claras es la única opción que aguanta.

El reflejo más común es zanjar el falso dilema: bloquear todas las herramientas de IA, o dejar que el equipo haga lo que quiera. Ninguna de las dos opciones protege tu código, y te lo voy a demostrar con hechos, no con miedos.

El verdadero riesgo no es el bug, es lo que tu desarrollador pega en el prompt

Un desarrollador atascado en un incidente en producción piensa en arreglarlo rápido, no en la seguridad. Abre un asistente de IA y pega un log de error, un archivo de configuración, a veces un trozo entero de código propietario. Es el escenario que describe una serie de vídeos de H2H Technology sobre la gobernanza de los asistentes de código IA: la consulta puede contener credenciales de clientes o claves API sin que el desarrollador se dé cuenta.

No es una hipótesis de laboratorio. Según webnet.fr, ingenieros de Samsung transmitieron código fuente confidencial a ChatGPT en 20 días, en 2023. Esos datos alimentaron los servidores de OpenAI y se volvieron imposibles de recuperar. La misma fuente sostiene que el 38% de los empleados comparte hoy datos confidenciales sin autorización, un fenómeno que el sector llama "shadow AI" (el uso no declarado de herramientas de IA, fuera del control del departamento de TI).

¿Por qué el shadow AI se escapa al control de TI?

Porque no pasa por ninguna puerta controlada. Una extensión de navegador, una clave API personal, un agente conectado en treinta segundos: cada interacción puede mover datos sensibles sin dejar un rastro explotable. Un ingeniero que trabaja en un sistema crítico para la industria aeroespacial se topa con el mismo problema, documentado en un vídeo dedicado a sectores regulados: el contratista sigue siendo responsable de cómo se ha tratado la información, con IA o sin ella. Si tu empresa maneja datos sensibles de clientes, la pregunta ya no es "¿puede pasar?" sino "¿te está pasando ya?", un tema que analizo desde el lado de los equipos no técnicos en lo que cuesta desplegar sin supervisión técnica.

El código generado por IA casi siempre compila, pero sigue siendo vulnerable una de cada dos veces

Aquí es donde muchos directivos se tranquilizan por error, confundiendo "funciona" con "es seguro". Un estudio de Veracode citado por kaspersky.fr midió más de 100 modelos de IA populares en código Java, Python, C# y JavaScript: el código producido compila con éxito en el 90% de los casos hoy, frente a menos del 20% hace dos años. La velocidad se ha disparado.

La seguridad, en cambio, apenas se ha movido. Según ese mismo estudio, el 45% del código generado contiene una vulnerabilidad clásica de la lista OWASP Top 10 (el ranking de referencia de fallos de seguridad web), una cifra estable desde hace dos años. Tu asistente de IA entrega código que funciona, pero una funcionalidad de cada dos lleva potencialmente una puerta trasera que nadie ha auditado.

¿Hay que fiarse del código que entrega Claude o Copilot?

No, no sin una revisión humana o automatizada. Es la conclusión de un hilo del subreddit r/devops: un equipo de SecOps se niega a dejar que agentes de IA en la nube escaneen repositorios propietarios enteros, aunque admite que la diferencia de productividad se vuelve difícil de ignorar. Su solución de compromiso: mapear el árbol del repositorio en local, enviar solo firmas de contexto puntuales, y exigir una aprobación manual en cada modificación escrita en disco. Artesanal, pero lo veo repetirse en casi todos nuestros proyectos.

He comprobado el mismo patrón en nuestras propias revisiones: los proyectos que tratan a Claude Code o Copilot como un junior productivo pero poco fiable, con revisión sistemática, salen mucho mejor parados que los que fusionan directamente la salida de la IA. No es un matiz de estilo, es la diferencia entre entregar rápido y entregar una deuda de seguridad que se descubre en una auditoría.

Ofuscar tu código ya no protege tu ventaja competitiva

Aquí es donde se equivocan de lleno la mayoría de los directivos que confían en "nuestro código está compilado, así que está protegido". Un artículo de korben.info documenta cómo el desarrollador Geoffrey Huntley pidió a Claude de Anthropic que analizara el archivo cli.mjs del propio Claude Code, un archivo minificado de 5 MB cuyos símbolos habían sido eliminados para impedir la ingeniería inversa. Claude produjo un código legible y funcionalmente equivalente en 30 minutos.

La compilación y la ofuscación (el enmascaramiento deliberado del código para impedir su lectura) ya no son una protección fiable de tu propiedad intelectual. Un competidor equipado con un LLM con una ventana de contexto suficiente (context window, la cantidad de código que la IA puede analizar de una sola vez) puede reconstruir tu lógica de producto sin copiar una sola línea, lo que hace casi imposible demostrar la infracción. Las startups que venden licencias de pago sobre código "source available" (visible pero bajo licencia restrictiva) son las primeras expuestas: su única barrera técnica acaba de caer.

¿Cómo desensambló Claude su propio código en 30 minutos?

Instalando el paquete npm público de Claude Code, localizando el archivo compilado que constituye el núcleo de la aplicación, y pidiendo al modelo que lo inspeccionara y reconstruyera una versión legible. No hizo falta ninguna herramienta de ingeniería inversa especializada, solo un prompt bien formulado. Si un ingeniero aislado hace esto una noche, tu competidor mejor financiado lo hace a escala.

¿A quién pertenece el código que la IA ha escrito para ti?

Es la pregunta que demasiadas empresas solo se hacen después del incidente. Según app.asso.fr, cuando un LLM sugiere código, lo extrae de bases de entrenamiento con miles de millones de líneas, algunas bajo licencia open source restrictiva. Integrar ese código sin verificar su licencia puede constituir una infracción, y el caso GitHub Copilot es el ejemplo más citado.

Segundo punto ciego: ¿conserva tu software su protección por derechos de autor si contiene una parte significativa de código generado por IA? La respuesta depende de la originalidad que conserve, según la misma fuente, pero el tema sigue siendo jurídicamente inestable. altij.fr recuerda que se ha presentado ante la Asamblea Nacional francesa una proposición de ley para regular la IA a través del derecho de autor, y que la Ley de Ciberresiliencia europea impone desde 2026 nuevas obligaciones de ciberseguridad, con un plazo límite el 11 de septiembre de 2026 que pocos editores han anticipado.

Si tu código contiene fragmentos generados por IA sin trazabilidad de su origen, tu protección jurídica es más frágil de lo que crees. Es un punto que tratamos sistemáticamente en nuestros contratos de proyecto, sobre todo en remoto: el tema merece un repaso a las cláusulas contractuales que realmente protegen tu código.

Lo que de verdad funciona: la pasarela controlada en lugar del bloqueo o el laissez-faire

Tras estos cuatro hallazgos, se impone una evidencia: bloquear la IA sacrifica tu velocidad a cambio de un riesgo que migra hacia el shadow AI no declarado. Autorizarla sin filtro acumula de golpe los cuatro riesgos anteriores. Existe una tercera vía, ni teórica ni costosa de implementar.

Transparencia: dirijo Extra Dev, donde entregamos con desarrolladores senior (ocho años de experiencia mínimo, nunca menos) potenciados por IA sobre repositorios propietarios de clientes. Esto sesga inevitablemente mi mirada, pero viene con un protocolo probado en decenas de proyectos, no con un argumentario abstracto.

Este protocolo se resume en tres reglas. Especificaciones precisas antes de cualquier sesión de código asistido (creo que un buen proyecto de IA parte de criterios de aceptación claros, nunca de un prompt vago). Una división en bloques cortos y comprobables, revisados antes del merge, nunca un agente que toque producción sin validación humana. Y ningún secreto hardcodeado en el código ni en los prompts: las claves API pasan por un gestor de secretos, nunca por una conversación con un asistente.

Un proyecto open source encontrado en r/regolo_ai formaliza una variante industrial de esta lógica: un bucle que audita el código (escaneo SAST/AST, el análisis estático que detecta fallos sin ejecutarlo), memoriza las restricciones arquitectónicas, exige aprobación humana antes de cualquier parche, y luego revalida en zero-trust (sin confianza por defecto) antes de fusionar. El mismo espíritu se ve en pasarelas comerciales como Tutela, que inspeccionan el tráfico hacia los asistentes de IA y aplican una política (enmascarar un dato sensible, avisar, bloquear) antes de que la consulta llegue al modelo.

¿Qué protocolo mínimo aplicar antes de autorizar un agente en un repo propietario?

Bastan tres comprobaciones para empezar. Uno, verifica que tu oferta de IA corporativa garantiza contractualmente la no retención de datos (zero data retention), no solo una promesa de marketing. Dos, impón la revisión humana en todo código que toque autenticación, pagos o datos personales, donde la tasa de vulnerabilidad OWASP medida por Veracode pesa más. Tres, prohíbe copiar y pegar logs de error en bruto en una herramienta de consumo, formando a tus equipos con casos concretos en lugar de una política que nunca leerán.

Estrategia de acceso a la IA Riesgo de fuga Velocidad de entrega Coste de implementación Tendencia
Bloqueo total de las herramientas de IA Bajo en superficie, alto en shadow AI no declarado Ralentizada, vuelta a métodos manuales Nulo en herramientas, alto en frustración del equipo ↓ abandono progresivo
Acceso libre sin filtro Elevado, exposición directa de secretos y código Máxima a corto plazo Nulo, pero coste oculto en incidentes ↓ riesgo creciente
Pasarela controlada + especificaciones claras Reducido, datos sensibles filtrados antes de la IA Alta, comparable al acceso libre Moderado, herramientas + proceso ↑ adopción empresarial

FUENTE: Vídeos H2H Technology, transcripciones citadas, Kaspersky/Veracode · ACT. 08/2026

«El verdadero problema con un agente de IA no es su inteligencia, es su fiabilidad operativa: quién aprueba qué, adónde van los secretos, y qué pasa cuando algo falla.»

Vincent, agosto de 2026

Un desarrollador senior que dirige un equipo potenciado por IA suele valer más que un equipo tradicional más numeroso, siempre que sepa exactamente qué dejar hacer al agente y qué mantener bajo control humano, un tema que desarrollo en el desarrollador aumentado y lo que cambia para el presupuesto de un proyecto.

El veredicto: no bloquees, encuadra

La respuesta a "¿hay que autorizar la IA en código propietario?" es sí, pero nunca sin una pasarela de control. Bloquear desplaza el riesgo hacia el shadow AI que nunca verás venir. Dejar hacer sin filtro acumula los cuatro riesgos detallados más arriba: fuga vía prompt, código vulnerable una de cada dos veces, ofuscación que ya no protege nada, estatus jurídico incierto.

El criterio de decisión es simple: si tu equipo maneja datos sensibles de clientes o código con alto valor competitivo, implanta una pasarela controlada y una revisión humana antes de que acabe el trimestre, no después del primer incidente. Si tu exposición es baja, basta con un encuadre más ligero y formación de los equipos. En ambos casos, el secreto ya no es una estrategia viable: es el proceso lo que protege tu código, no la compilación.

Preguntas frecuentes

¿Se puede evitar totalmente una fuga de código propietario hacia un asistente de IA?

No, no al 100%, pero una pasarela que inspecciona el tráfico antes de que llegue al modelo y filtra las credenciales reduce drásticamente el riesgo. El bloqueo total simplemente empuja el uso hacia herramientas no declaradas, peor que la ausencia de control.

¿Puede el código generado por una IA como Copilot o Claude Code estar protegido por derechos de autor?

Depende de la originalidad que conserve el software final: un software que sigue siendo "original" mantiene su protección aunque contenga código asistido por IA. La zona gris jurídica se centra sobre todo en la parte generada automáticamente y en el respeto de las licencias de las fuentes de entrenamiento del modelo.

¿La ofuscación del código sigue sirviendo de algo frente a los LLM recientes?

Ralentiza a un atacante humano aislado, pero ya no protege frente a un LLM con una ventana de contexto suficiente, capaz de desensamblar código minificado en unas pocas decenas de minutos. Tu verdadera protección viene del contrato y del control de acceso, no del secreto técnico por sí solo.

¿Hay que prohibir Claude Code o Copilot a los desarrolladores por precaución?

No, la diferencia de productividad es demasiado costosa como para dejarla pasar y la prohibición simplemente desplaza el uso hacia un shadow AI incontrolado. Autoriza estas herramientas mediante un canal supervisado, con reglas claras sobre lo que circula en un prompt y revisión humana en el código sensible.

¿Cuál es el coste real de un incidente de fuga de código propietario vía IA?

Depende del sector, pero el ejemplo de Samsung muestra que una fuga puede volverse irrecuperable en pocas semanas, sin contar el tiempo de investigación interna. El coste de una pasarela de control suele ser inferior al coste de un solo incidente serio.

Fuentes