La IA ya escribe código, propone parches, genera tests, revisa pull requests y puede recorrer repositorios completos en busca de errores. Para administradores de sistemas y desarrolladores, eso no es una promesa de futuro: es una herramienta de trabajo que ya está entrando en terminales, IDE, pipelines y plataformas de colaboración. La pregunta importante ya no es si se puede usar, sino bajo qué límites.
La respuesta empieza por una regla incómoda pero necesaria: el código puede estar asistido por IA, pero la responsabilidad no se automatiza. Un agente puede sugerir una función impecable en apariencia, preparar una migración o corregir un fallo de concurrencia, pero no puede asumir la responsabilidad legal, operativa ni técnica de lo que entra en producción. Si algo rompe un servicio a las tres de la madrugada, no responde el modelo. Responde la persona, el equipo y la organización que lo aceptaron.
El kernel de Linux marca un criterio útil para todos
La documentación del kernel de Linux ha trazado una línea muy clara para el uso de asistentes de IA en contribuciones de código. Los agentes no pueden añadir etiquetas Signed-off-by, porque solo una persona puede certificar el Developer Certificate of Origin. El contribuidor humano debe revisar el código generado por IA, comprobar licencias, añadir su propia firma y asumir la responsabilidad completa de la contribución.
La misma guía introduce una etiqueta Assisted-by para declarar el uso de herramientas de IA. No es un detalle cosmético. Es una forma de decir la verdad en el historial del proyecto: este cambio ha sido revisado y firmado por una persona, pero ha contado con asistencia de una herramienta concreta. Para proyectos internos, repositorios empresariales y software crítico, esa distinción debería convertirse en una práctica estándar.
Un buen registro podría incluir qué agente se ha usado, qué versión del modelo, en qué fase intervino y quién revisó el resultado. No hace falta convertir cada commit en un expediente burocrático, pero sí evitar que el código generado por IA aparezca como si hubiera sido escrito y razonado íntegramente por una persona. La trazabilidad no es enemiga de la productividad. Es lo que permite investigar después.
Para equipos DevOps, SRE y plataformas, esta regla tiene una consecuencia práctica: los agentes no deberían tener permisos equivalentes a los de un maintainer humano. Pueden abrir una rama, proponer un parche o generar un informe, pero el merge, la firma, el despliegue y los cambios sobre infraestructura crítica deben seguir pasando por controles humanos y automatizados.
El “vibe coding” también escala la deuda técnica
El problema de la IA aplicada al desarrollo no es que escriba mal siempre. El problema es que escribe con mucha seguridad incluso cuando se equivoca. Puede generar código que compila, pasa pruebas superficiales y mantiene el estilo del repositorio, pero introduce una validación incompleta, una dependencia innecesaria, una gestión pobre de errores o una ruta vulnerable que solo aparece con carga real.
Veracode analizó más de 100 modelos de lenguaje en tareas de generación de código y concluyó que el 45 % de las muestras introducía fallos de seguridad conocidos. En otro resumen de la investigación, la compañía señala que esos fallos incluían vulnerabilidades de OWASP Top 10, con tasas especialmente altas en algunos lenguajes y tipos de tarea.
Para un desarrollador senior, el dato no debería llevar a prohibir la IA. Debería llevar a tratarla como se trata cualquier input no confiable. El código generado por IA debe pasar por revisión, tests, análisis estático, análisis de dependencias, detección de secretos y validaciones de seguridad. Si afecta a autenticación, autorización, criptografía, parsing, entrada de usuario, despliegues, infraestructura o datos sensibles, la revisión debe ser todavía más estricta.
El riesgo se multiplica cuando los agentes operan sobre repositorios grandes. Un cambio pequeño puede tener efectos laterales en scripts de despliegue, políticas de IAM, migraciones de base de datos, jobs de CI/CD o plantillas de infraestructura como código. Por eso el criterio no puede ser “si compila, vale”. La pregunta correcta es qué superficie toca, qué permisos necesita y qué pruebas demuestran que no rompe nada relevante.
Mínimo privilegio ya no basta: hace falta mínima agencia
Los administradores de sistemas conocen bien el principio de mínimo privilegio. Un usuario o servicio debe tener solo los permisos imprescindibles para hacer su trabajo. Con agentes de IA hay que añadir otra capa: mínima agencia. El agente no debe poder hacer todo lo que técnicamente sabe hacer, sino solo lo que la tarea exige.
Un agente que revisa logs no necesita credenciales para modificar producción. Un agente que genera un parche no necesita publicar una release. Un agente que analiza Terraform no debería aplicar cambios sin aprobación. Un agente que propone actualizaciones de dependencias no debería alterar secretos, pipelines o políticas de red.
Esta separación debe reflejarse en permisos reales: tokens de corta duración, cuentas de servicio específicas, repositorios limitados, entornos aislados, ejecución en sandboxes, acceso de solo lectura por defecto y políticas claras para escalar acciones. También conviene registrar cada operación relevante: ficheros leídos, comandos ejecutados, cambios propuestos, dependencias añadidas y decisiones tomadas por la persona que revisa.
La gobernanza no debe vivir en un PDF apartado del flujo técnico. Debe estar en Git, en CI/CD, en el sistema de tickets, en las políticas de ramas, en los registros de auditoría y en las herramientas de seguridad. Si un agente toca código o infraestructura, su actividad debe ser verificable.
La cadena de suministro recuerda dónde falla la confianza
Los incidentes recientes de seguridad enseñan la misma lección desde otro ángulo. En abril de 2026, la web de CPUID fue comprometida durante una ventana corta y sirvió instaladores manipulados de herramientas como CPU-Z y HWMonitor. Los paquetes usaban una técnica de DLL sideloading con un archivo CRYPTBASE.dll para desplegar malware, según el análisis publicado por medios de seguridad.
El caso es útil para sysadmins porque demuestra que la firma o la confianza histórica en un proveedor no bastan. Un binario puede parecer legítimo, un sitio puede ser oficial y una descarga puede venir de una URL conocida, pero la cadena de distribución puede estar comprometida. La verificación debe incluir hashes, repositorios confiables, allowlists, EDR, control de ejecución, análisis de comportamiento y procesos de respuesta.
También en abril de 2026, Apple corrigió CVE-2026-28950, una vulnerabilidad en Notification Services que podía hacer que notificaciones marcadas para eliminación quedaran retenidas en el dispositivo. El fallo se relacionó con escenarios forenses en los que contenido de notificaciones de Signal podía recuperarse aunque la aplicación hubiera sido eliminada.
La lectura para administradores y desarrolladores es clara: una aplicación puede cifrar bien, un binario puede estar firmado y un asistente de IA puede generar código aparentemente correcto, pero el sistema completo falla por la capa menos protegida. La seguridad real depende de cómo se combinan sistema operativo, permisos, almacenamiento local, logs, notificaciones, dependencias y distribución.
Un modelo práctico para equipos técnicos
La gobernanza de IA en desarrollo y operaciones debería empezar por unas reglas simples. Todo código asistido por IA debe declararse cuando sea relevante. Todo cambio debe tener una persona responsable. Los agentes deben operar con permisos limitados. Las acciones críticas deben requerir aprobación humana. Las dependencias nuevas deben validarse. Los secretos no deben estar disponibles para agentes salvo necesidad justificada. Las salidas generadas deben pasar por los mismos controles que el código humano, no por menos.
En pipelines, conviene separar tres fases: asistencia, verificación y promoción. La IA puede asistir en generación, revisión o diagnóstico. La verificación debe apoyarse en herramientas deterministas siempre que sea posible: tests, SAST, DAST, SBOM, escaneo de contenedores, comprobación de licencias, análisis de IaC y políticas de compliance. La promoción a entornos superiores debe quedar bajo control del equipo responsable.
Para entornos de producción, el uso de agentes debe ir acompañado de observabilidad. No basta con saber que un cambio se desplegó. Hay que saber quién lo aprobó, qué generó la IA, qué controles pasaron, qué métricas cambiaron después y cómo revertirlo. La IA puede acelerar el ciclo de desarrollo, pero también puede acelerar la propagación de errores si no hay frenos técnicos.
La conclusión no es defensiva. La IA puede ser muy útil para sysadmins y desarrolladores: ayuda a leer código heredado, explicar logs, generar playbooks, escribir tests, detectar patrones, preparar scripts y documentar sistemas. Pero cuanto más entra en el flujo real de trabajo, más importante es mantener una frontera clara entre asistencia y responsabilidad.
El humano sigue al mando no por romanticismo, sino por diseño operativo. Alguien debe firmar, revisar, responder y apagar el incendio si llega. La IA puede acompañar en la guardia, pero no puede llevar el buscapersonas legal de producción.
Preguntas frecuentes
¿Puede una IA firmar commits o parches en proyectos serios?
No debería. En el kernel de Linux, los agentes de IA no pueden usar Signed-off-by; una persona debe revisar, certificar y asumir la responsabilidad del cambio.
¿Qué significa Assisted-by en un commit?
Indica que una herramienta ha ayudado a crear o revisar una contribución. Sirve para dar transparencia sin sustituir la responsabilidad humana.
¿Qué permisos debería tener un agente de IA en un repositorio?
Los mínimos necesarios. Lo recomendable es empezar con lectura o propuestas en ramas separadas, sin permisos directos para hacer merge, modificar secretos, cambiar CI/CD o desplegar producción.
¿Cómo se revisa código generado por IA?
Igual que código no confiable: revisión humana, tests, análisis estático, escaneo de dependencias, control de licencias, detección de secretos y validación específica si toca seguridad, infraestructura o datos sensibles.
