La imagen de un desarrollador firmando una línea de código puede parecer antigua en una época en la que los agentes de Inteligencia Artificial generan parches, tests y documentación en segundos. Pero esa firma sigue teniendo más peso que nunca. No porque el software deba volver a una artesanía lenta y manual, sino porque los sistemas críticos necesitan algo que ningún modelo puede aportar por sí solo: responsabilidad humana verificable.

El avance de los asistentes de programación ha cambiado el ritmo del desarrollo. Herramientas como Copilot, Claude Code, Cursor o Codex ayudan a escribir funciones, localizar errores, proponer refactorizaciones y automatizar tareas que antes consumían horas. En algunos equipos ya no se discute si se debe usar IA, sino cómo integrarla sin perder control sobre la calidad, la seguridad y la autoría del código.

El problema aparece cuando la velocidad se confunde con fiabilidad. Un parche generado por IA puede compilar, seguir el estilo del proyecto y superar pruebas simples, pero fallar en un caso límite, introducir una dependencia insegura o replicar un patrón vulnerable aprendido de código público. La apariencia de corrección no basta. En software, y más aún en infraestructura crítica, el coste de un fallo suele aparecer cuando el sistema ya está en producción.

Linux marca una frontera: la IA ayuda, pero no firma

El kernel de Linux ha formalizado una regla que resume bien el momento. Los asistentes de IA pueden ayudar al desarrollo, pero no pueden añadir la etiqueta Signed-off-by. Esa firma está vinculada al Developer Certificate of Origin, el mecanismo por el que un contribuidor certifica que tiene derecho a enviar ese código y asume la responsabilidad de la contribución.

La guía del kernel es clara: solo una persona puede revisar el código generado con IA, comprobar su compatibilidad con la licencia, añadir su propia firma y responder por el resultado. Cuando una herramienta de IA haya participado, debe indicarse con una etiqueta Assisted-by, donde se identifique el agente, la versión del modelo y, si procede, otras herramientas de análisis utilizadas.

La decisión no es un rechazo a la Inteligencia Artificial. Es una forma de encajarla dentro de un proceso de confianza que ya existía. El mensaje para el resto de proyectos es sencillo: la IA puede escribir, sugerir o acelerar, pero no puede asumir consecuencias legales ni técnicas. Si un parche rompe algo, introduce una vulnerabilidad o incumple una licencia, la responsabilidad no puede recaer en un modelo, ni en una API, ni en una empresa proveedora situada a varios niveles de distancia.

Esta distinción será cada vez más importante. En entornos de desarrollo con agentes autónomos, la tentación de delegar decisiones completas crecerá. Pero cuanto más autonomía tenga una herramienta, más necesario será registrar qué hizo, con qué permisos, sobre qué repositorio, bajo qué instrucciones y quién validó el resultado final.

El código generado rápido también genera deuda rápida

La seguridad de la IA aplicada al desarrollo no puede limitarse a pasar un linter o ejecutar una batería básica de tests. Un informe de Veracode sobre código generado por IA concluyó que el 45 % de las muestras analizadas introducía fallos de seguridad conocidos. El dato no significa que todo código generado por IA sea inseguro, ni que el código humano sea perfecto. Sí indica que la productividad sin revisión puede acumular deuda técnica y deuda de seguridad a una velocidad nueva.

Aquí entra una idea que debería convertirse en norma: tratar el código generado por IA como código no confiable hasta que se demuestre lo contrario. Eso implica revisión humana, pruebas automatizadas, análisis estático, análisis de dependencias, control de secretos, pruebas de seguridad y revisión de arquitectura cuando el cambio afecte a zonas sensibles.

También conviene vigilar las dependencias. Los modelos pueden proponer librerías inexistentes, obsoletas o poco mantenidas. En un flujo tradicional, un desarrollador suele conocer el ecosistema en el que trabaja. En un flujo agéntico, una herramienta puede incorporar paquetes por conveniencia sintáctica sin entender la política de seguridad de la organización. Ese riesgo no se resuelve con confianza, sino con controles.

El principio clásico de mínimo privilegio debe ampliarse con otro: mínima agencia. Un agente no debería poder hacer todo lo que técnicamente sabe hacer, sino solo aquello que necesita para cumplir una tarea concreta. No es lo mismo pedirle que genere una propuesta de parche que darle permisos para modificar ramas, abrir pull requests, cambiar pipelines, instalar dependencias o desplegar en producción.

La cadena de suministro demuestra que la confianza implícita falla

Los incidentes recientes fuera del desarrollo asistido por IA refuerzan la misma lección. En abril de 2026, el sitio de CPUID, conocido por herramientas como CPU-Z y HWMonitor, fue comprometido durante menos de 24 horas. Según el análisis de Kaspersky, los atacantes sustituyeron enlaces de descarga legítimos por instaladores troyanizados que incluían un ejecutable firmado y una DLL maliciosa llamada CRYPTBASE.dll, cargada mediante DLL sideloading.

El detalle importa. No siempre hace falta modificar el binario firmado para comprometer al usuario. A veces basta con alterar la cadena de distribución, colocar una biblioteca en el lugar adecuado y aprovechar reglas de carga heredadas. La firma del ejecutable seguía dando una sensación de confianza, pero el paquete entregado al usuario ya estaba contaminado.

Apple corrigió también en abril de 2026 la vulnerabilidad CVE-2026-28950 en Notification Services, un problema por el que notificaciones marcadas para eliminación podían quedar retenidas inesperadamente en el dispositivo. Varios medios de seguridad vincularon el fallo con la recuperación forense de contenido procedente de notificaciones de Signal. El cifrado extremo a extremo de una aplicación puede ser sólido, pero la privacidad final depende también del sistema operativo, las notificaciones, las copias locales, los registros y las herramientas de extracción.

Estos casos tienen una lectura común. La seguridad no depende de una sola capa ni de una sola promesa. Un modelo puede generar código correcto en apariencia. Un ejecutable puede estar firmado. Una app puede cifrar sus mensajes. Pero si la cadena de suministro, el sistema operativo, la carga de bibliotecas o la gestión de logs fallan, la confianza se rompe por otro sitio.

Verificación continua, no auditoría ceremonial

La gobernanza de IA no debería convertirse en una carpeta de políticas que se revisa una vez al año. Si los agentes generan código, modifican documentación, abren incidencias, revisan pull requests o proponen despliegues, la verificación debe acompañar el flujo diario de trabajo.

Eso significa registrar qué partes de un cambio han sido asistidas por IA, conservar trazabilidad de prompts y acciones relevantes, exigir revisión humana en rutas críticas, aplicar controles automáticos antes del merge y limitar permisos de agentes por repositorio, entorno y tarea. También implica medir falsos positivos, errores repetidos y zonas donde la herramienta se equivoca más.

El objetivo no es frenar la adopción de IA. Es hacerla sostenible. La innovación que no deja rastro, no se puede auditar. La automatización que no tiene límites, no se puede gobernar. Y el código que nadie firma, aunque funcione hoy, será un problema cuando falle mañana.

La figura del desarrollador no desaparece con los agentes. Cambia. Es menos mecanógrafo de funciones repetitivas y más responsable de criterio, contexto, arquitectura, seguridad y validación. La IA puede escribir mucho, pero alguien debe saber qué no debería escribirse, qué no debe desplegarse y qué merece una revisión más lenta.

En 2026 la pregunta ya no es si una organización usa IA para desarrollar software. La pregunta seria es quién firma lo que esa IA produce, qué controles lo verifican y qué ocurre cuando el resultado falla. El humano sigue al mando no por nostalgia, sino porque sigue siendo el único capaz de responder.

Preguntas frecuentes

¿Puede una IA firmar código en el kernel de Linux?
No. La guía del kernel indica que los agentes de IA no pueden añadir etiquetas Signed-off-by. Solo una persona puede certificar el Developer Certificate of Origin y asumir la responsabilidad.

¿Qué significa la etiqueta Assisted-by?
Indica que una herramienta de IA ha ayudado en la contribución. Sirve para dar transparencia sin trasladar a la IA la responsabilidad legal o técnica del cambio.

¿Es inseguro todo el código generado por IA?
No. Pero debe revisarse como cualquier código no confiable. Estudios de seguridad han encontrado fallos frecuentes en muestras generadas por IA, así que la revisión humana y las pruebas siguen siendo necesarias.

¿Qué controles debería aplicar una empresa que usa agentes de IA para programar?
Debe limitar permisos, registrar acciones, exigir revisión humana en cambios sensibles, aplicar análisis de seguridad, controlar dependencias y mantener verificación continua dentro del flujo de desarrollo.