La nueva Cátedra Devoteam-UGR apunta al verdadero agujero del sector: faltan manos que entiendan IA, código y seguridad a la vez

La noticia, en sí misma, parece modesta: una universidad pública y una consultora tecnológica firman una cátedra sobre DevSecOps e inteligencia artificial. Nada que obligue a interrumpir el café. Pero conviene mirar mejor. La Universidad de Granada y Devoteam han puesto nombre a uno de los problemas más incómodos del mercado: seguimos hablando de ciberseguridad como si bastara con comprar herramientas, cuando el cuello de botella real está en otro sitio. Faltan perfiles capaces de entender el ciclo completo: desarrollo, operaciones, seguridad e IA. Y no faltan un poco. Faltan mucho.

La nueva Cátedra Devoteam-UGR, centrada en “Soluciones de Seguridad, Operaciones y Desarrollo (DevSecOps) basadas en Inteligencia Artificial”, llega en un momento en el que las empresas aceleran la adopción de IA generativa mientras los reguladores endurecen el listón de resiliencia, gobernanza de proveedores, gestión de vulnerabilidades y control sobre el software. Es decir: justo cuando improvisar sale más caro.

La relevancia de la iniciativa no está en el titular institucional ni en la foto de firma. Está en lo que revela sobre el mercado. Durante años, la industria ha separado tres conversaciones que ya no se pueden separar sin pagar la factura después: cómo se construye software, cómo se protege y cómo se automatiza con IA. La cátedra intenta coser esas piezas. Eso, si se hace bien, tiene más interés que otra jornada sobre “transformación digital” con canapés y una presentación llena de flechas.

No es una cátedra más si aterriza donde duele: el pipeline de software

El término DevSecOps ya no es nuevo. A estas alturas, casi nadie en tecnología se atreve a negar que la seguridad debe integrarse desde el diseño y a lo largo de todo el ciclo de vida del software. El problema es que entre repetirlo en conferencias y aplicarlo en equipos reales hay un abismo. Ahí está la grieta que esta cátedra promete abordar.

Cuando una organización despliega software deprisa, utiliza librerías de terceros, contenedores, pipelines CI/CD, infraestructura como código y servicios cloud administrados, la superficie de ataque ya no se parece a la de hace diez años. El riesgo se desplaza al proceso de construcción. No solo importa si el perímetro está bien configurado; importa qué dependencias entraste en tu código, quién aprobó ese merge, qué secretos quedaron expuestos en repositorios, qué imagen de contenedor subió a producción y cuánto tardas en corregir una vulnerabilidad crítica.

Aquí la IA puede ayudar, pero también puede empeorar el problema. Puede automatizar revisión de código, priorización de alertas, correlación de eventos o generación de playbooks. También puede producir software inseguro a velocidad industrial si se usa sin control. Esa ambivalencia es el centro del debate serio, y por eso la combinación “DevSecOps + IA” tiene sentido académico y empresarial. No porque suene moderna, sino porque refleja una tensión real.

Hay una razón adicional para prestar atención a Granada. La UGR tiene una trayectoria reconocida en investigación informática y matemáticas, y Andalucía lleva tiempo intentando reforzar polos de talento tecnológico fuera del eje Madrid-Barcelona. En España, la descentralización del talento importa más de lo que se admite. Las empresas se quejan de escasez, pero luego reclutan como si el mapa terminara en la M-30. Asociaciones estables entre universidad y empresa pueden corregir parte de ese fallo, siempre que no se queden en relaciones públicas con barniz académico.

El mercado necesita híbridos, no especialistas encerrados en su torre

El perfil que intenta formar una iniciativa así es incómodo de definir porque obliga a romper silos. Ya no basta con el desarrollador que “no toca seguridad”, ni con el analista de seguridad que no entiende cómo funciona un pipeline de despliegue, ni con el experto en IA que entrena modelos pero no sabe qué pasa cuando se integran en un producto sujeto a auditoría, cumplimiento o requisitos sectoriales.

Las empresas buscan, cada vez más, profesionales que puedan moverse entre cuatro capas:

Primero, el desarrollo seguro: control de dependencias, revisión de código, patrones de diseño, gestión de secretos, pruebas y automatización. Segundo, la operación: observabilidad, respuesta a incidentes, logging, hardening de entornos, despliegues y rollback. Tercero, la seguridad aplicada: threat modeling, gestión de vulnerabilidades, acceso privilegiado, cadena de suministro de software, cumplimiento técnico. Cuarto, la IA: desde el uso de asistentes de código hasta modelos para detección, clasificación, análisis de comportamiento o apoyo a centros de operaciones de seguridad.

Ese cruce no sale de forma espontánea del sistema universitario ni de la empresa por separado. La universidad suele tener más tiempo para profundidad conceptual; la empresa, más presión por la aplicabilidad. Cuando funciona una cátedra de este tipo, sirve precisamente para traducir entre ambos idiomas: investigación que no ignore las restricciones reales del mercado y práctica profesional que no se limite a apagar fuegos trimestrales.

El dato incómodo es que la brecha de talento en ciberseguridad sigue lejos de cerrarse. Distintas mediciones internacionales la sitúan en millones de profesionales a escala global, aunque las cifras exactas varían según la metodología. No hace falta aferrarse a un número redondo para entender el problema. Basta mirar lo que ocurre en muchas compañías españolas: puestos que tardan meses en cubrirse, candidatos con certificaciones pero poca experiencia operativa, equipos de desarrollo obligados a asumir tareas de seguridad sin formación suficiente y CISOs que dependen demasiado de consultoras para tareas que deberían internalizarse.

Una cátedra no va a arreglar sola ese mercado. Pero puede hacer dos cosas útiles. Una, crear un flujo de perfiles mejor preparados. Dos, elevar el nivel de la conversación: menos discurso grandilocuente sobre innovación y más trabajo serio sobre qué significa desplegar IA sin romper la seguridad ni el cumplimiento.

La IA no llega a un campo virgen: entra en un terreno regulado y lleno de minas

Quien lea esta noticia como un simple movimiento de employer branding se pierde la mitad del cuadro. La otra mitad la pone el regulador. La IA aplicada a desarrollo y operaciones de seguridad no se desplegará en el vacío. Va a hacerlo bajo un ecosistema normativo cada vez más denso.

En Europa, el AI Act ya marca un punto de inflexión. Aunque no toda herramienta de IA para ciberseguridad o DevSecOps será de “alto riesgo”, sí aparecerán obligaciones concretas cuando estos sistemas se integren en entornos laborales, afecten a decisiones relevantes o formen parte de productos sujetos a normativa sectorial. A eso se suma el Reglamento DORA para el sector financiero, plenamente aplicable desde el 17 de enero de 2025, con exigencias directas sobre gestión de riesgo TIC, pruebas de resiliencia, incidentes y terceros tecnológicos. DORA no habla de “usar IA” como tal, pero cualquier automatización que toque procesos críticos cae de lleno en la lógica de control, trazabilidad y gobernanza del reglamento, especialmente en sus artículos 5 a 16 sobre gestión del riesgo TIC y en el artículo 28 sobre terceros prestadores de servicios TIC.

En paralelo, NIS2 obliga a entidades esenciales e importantes a reforzar medidas técnicas, operativas y organizativas. El artículo 21 no deja mucho espacio para la poesía: análisis de riesgos, gestión de incidentes, continuidad, seguridad de la cadena de suministro, seguridad en adquisición, desarrollo y mantenimiento de redes y sistemas, políticas para evaluar la eficacia de las medidas y formación básica en ciberhigiene. Dicho de forma más cruda: si vas a meter IA en tu ciclo de desarrollo o en tu SOC, tendrás que demostrar que no has perdido el control por el camino.

Luego está el GDPR, que sigue siendo el invitado que nadie puede expulsar de la sala. Si una herramienta de IA procesa datos personales en logs, tickets, correos, repositorios, trazas o datasets de entrenamiento, la organización tiene que resolver base jurídica, minimización, retención, seguridad del tratamiento y, si toca, evaluación de impacto. Los artículos 5, 25 y 32 del GDPR son bastante claros en esto. Y si la IA se apoya en proveedores externos o transfiere datos fuera del EEE, el asunto se vuelve todavía menos simpático.

La gracia, si queremos llamarla así, es que el mercado quiere velocidad y el regulador quiere evidencia. Una cátedra bien orientada puede ser útil precisamente porque enseña a trabajar dentro de esa tensión. No basta con que el modelo “funcione”; hay que saber explicarlo, validarlo, documentarlo y gobernarlo. Quien forme a estudiantes en IA aplicada a seguridad sin enseñarles control interno, trazabilidad y gestión de riesgos les estará preparando a medias. Y a medias, en este sector, es una forma elegante de decir mal.

DevSecOps con IA: dónde hay valor de verdad y dónde hay puro humo

Conviene separar dos planos: las aplicaciones donde la IA ya aporta valor operativo razonable y las promesas infladas que abundan en presentaciones comerciales.

Hay usos defensivos bastante concretos. Revisión semiautomática de código para detectar patrones inseguros. Priorización de vulnerabilidades combinando CVSS con contexto interno. Correlación de alertas en centros de operaciones de seguridad. Generación asistida de reglas de detección. Resumen de incidentes para acelerar handoffs entre equipos. Apoyo al análisis de dependencias en software de terceros. Recomendaciones para hardening en infraestructura como código. Todo eso puede ahorrar tiempo y reducir fricción si se implementa con controles serios.

Ahora bien, una cosa es asistir y otra delegar criterio. Si una organización convierte un copiloto en piloto, el accidente no tarda. Los modelos se equivocan, inventan, priorizan mal y heredan sesgos del dato o del diseño. En seguridad, un falso negativo no es una anécdota; puede ser una brecha. En desarrollo, una sugerencia de código funcional pero inseguro puede terminar en producción si el equipo está demasiado acostumbrado a confiar en la máquina. La productividad, cuando se vende sin frenos, tiene una costumbre fea: desplaza el riesgo hacia más adelante, donde el coste es mayor y el responsable ya no está en la demo comercial.

Por eso una cátedra de esta naturaleza será valiosa si enseña también a desconfiar. A medir tasas de error. A validar resultados. A registrar decisiones. A separar automatización de autonomía. Y a entender que un sistema útil de IA en seguridad necesita datos de calidad, procesos claros y límites operativos. Sin eso, lo que obtienes no es inteligencia aumentada. Es una fábrica de ruido más elegante.

Hay un ejemplo muy ilustrativo en la seguridad de la cadena de suministro de software. Tras incidentes y campañas de alto impacto de los últimos años, el sector ha asumido que no basta con “escuchar” alertas; hay que saber qué software tienes, de dónde viene y qué componentes arrastra. Herramientas basadas en IA pueden ayudar a clasificar hallazgos o identificar combinaciones de riesgo, pero la obligación operativa real sigue siendo prosaica: mantener inventarios fiables, revisar SBOM cuando exista, controlar dependencias, segmentar accesos, exigir condiciones contractuales a proveedores y parchear a tiempo. La IA puede ayudar a decidir mejor; no sustituye el trabajo básico que muchas organizaciones aún no hacen bien.

La universidad tiene una oportunidad rara: enseñar lo que las empresas piden y casi nunca explican bien

La palabra “empleabilidad” suele aparecer en estos anuncios, a veces con el entusiasmo hueco de los folletos. Aquí, sin embargo, la cuestión merece tratarse en serio. El mercado no solo necesita más profesionales; necesita profesionales menos ingenuos sobre cómo funciona la tecnología en producción.

Un programa de estas características puede marcar diferencia si baja al terreno. ¿Qué debería incluir para no quedarse en una etiqueta bonita? Bastantes cosas, y todas concretas.

Un bloque sólido de secure coding y revisión de código, con prácticas sobre errores frecuentes y explotación básica de fallos para que el alumno entienda la lógica atacante. Trabajo con pipelines CI/CD reales, integrando análisis estático, análisis de composición de software, gestión de secretos y controles de aprobación. Casos sobre contenedores e infraestructura como código, porque la mayoría de problemas modernos no nacen en un ejecutable aislado, sino en cadenas de configuración, permisos y automatización. Formación en logging, detección y respuesta, no para convertir a todos en analistas SOC, sino para que sepan qué trazas necesita una investigación y cómo se conecta eso con el diseño de aplicaciones. Y una capa de gobernanza y regulación: protección de datos, contratos con proveedores cloud, resiliencia operacional, documentación y evidencias.

Si además incorpora laboratorios sobre ataques a modelos, prompt injection, data poisoning, fuga de datos por uso indebido de asistentes de IA o validación de salidas generativas, el programa estaría leyendo bien el momento. La explosión de IA generativa ha metido riesgos nuevos en equipos que antes ya iban justos de tiempo. Ahora un desarrollador puede generar funciones enteras en segundos. Maravilloso. También puede introducir bibliotecas inseguras, secretos expuestos o lógica vulnerable con la misma alegría y en la mitad de tiempo. La productividad es fantástica hasta que llega auditoría, forense o el incidente en domingo.

Aquí hay una ironía que conviene no desperdiciar: durante años, muchas compañías pidieron “perfiles junior con tres años de experiencia”. Ahora se dan cuenta de que tendrán que invertir de verdad en construir talento. Las cátedras universidad-empresa son una de las pocas herramientas razonables para hacerlo sin fingir que el mercado lo resolverá solo. Pero solo si incluyen prácticas, proyectos con datos o entornos realistas, mentorización técnica y objetivos medibles. Si se quedan en seminarios inspiracionales, habremos asistido a otra producción institucional impecable y operativamente irrelevante.

Lo que esto dice sobre España: más madurez en ciberseguridad, pero todavía muy desigual

España ha mejorado notablemente su ecosistema de ciberseguridad en la última década. Ahí están el papel del INCIBE, la actividad del CCN-CERT en el sector público, el crecimiento de hubs regionales y la mayor sofisticación de muchas grandes empresas. También ha subido el interés por posgrados, certificaciones y carreras vinculadas a seguridad ofensiva, defensa, cloud y privacidad. Sería injusto negarlo.

Pero el avance sigue siendo muy desigual. Las grandes organizaciones han profesionalizado funciones, aunque con dependencias fuertes de terceros. Las medianas avanzan a trompicones. Muchas pymes, mientras tanto, siguen atrapadas entre una presión regulatoria creciente y una falta de capacidad técnica bastante brutal. El problema de talento no se distribuye igual: donde hay marca empleadora y presupuesto, se compite. Donde no, se parchea. Literal y metafóricamente.

En ese escenario, iniciativas como la de la UGR y Devoteam pueden tener una utilidad adicional: crear cantera local y fijar conocimiento fuera de los polos tradicionales. Granada ya tiene una base académica potente. Si el proyecto se abre a colaboración con tejido empresarial, administraciones y quizá startups o centros tecnológicos, podría contribuir a generar una masa crítica regional en seguridad e IA aplicada. Eso no es menor. La ciberseguridad española necesita más nodos sólidos y menos dependencia de cuatro plazas donde todo el mundo se roba talento entre sí.

También puede tener efecto reputacional. Para muchos estudiantes, seguridad sigue sonando a nicho técnico oscuro o a carrera inaccesible. Cuando una universidad prestigiosa y una empresa con presencia internacional ponen recursos y estructura sobre la mesa, mandan una señal de mercado: esto no es marginal, esto es empleable, estratégico y transversal. Puede parecer obvio, pero no lo es. En muchas facultades todavía se enseña informática como si la seguridad fuese un módulo periférico en vez de una propiedad esencial del software.

Para las empresas, la lección no es patrocinar una cátedra; es revisar cómo fichan y cómo trabajan

Sería cómodo leer esta noticia y concluir que la solución al déficit de talento pasa por más convenios universitarios. Ayudan, sí. Pero las empresas también tienen deberes bastante menos fotogénicos.

El primero es dejar de contratar como si buscaran unicornios baratos. Si una organización quiere perfiles capaces de unir seguridad, desarrollo, cloud e IA, tendrá que ofrecer formación, carrera, tiempo para aprender y equipos que no estén estructuralmente quemados. Pretender incorporar perfiles híbridos sin cambiar procesos internos es tan útil como comprar un SIEM caro sin tener a nadie que sepa afinarlo.

El segundo es integrar de verdad seguridad en ingeniería. No sirve predicar DevSecOps y después medir a los equipos solo por velocidad de entrega. Lo que se incentiva se ejecuta; lo demás se aparca. Si el desarrollo se premia por sacar features y la seguridad por reducir riesgo, el conflicto está garantizado. Las métricas tienen que alinearse: tiempo de corrección de vulnerabilidades, cobertura de análisis en pipeline, calidad de dependencias, reducción de secretos expuestos, excepciones justificadas, revisión de componentes críticos y trazabilidad de cambios.

El tercero es ordenar el uso de IA interna antes de que se desordene sola. Muchas compañías ya tienen desarrolladores usando asistentes de código y equipos de seguridad probando automatizaciones con LLM sin una política madura detrás. Eso exige reglas claras: qué datos pueden introducirse, qué proveedores están aprobados, cómo se evalúan las salidas, qué logs se conservan, cómo se revisan sugerencias de código, qué casos de uso están prohibidos y quién asume la supervisión. Sin ese marco, la adopción ocurre igual, solo que peor documentada.

Y el cuarto es colaborar con la academia con objetivos verificables. No basta con poner el logo y dar una charla al semestre. Si una empresa entra en una cátedra de ciberseguridad e IA, debería comprometerse con contenidos, casos de uso, mentoría, prácticas, retos aplicados y feedback real sobre habilidades que faltan. Lo contrario es filantropía decorativa. Queda bien, pero no corrige el problema.

La regulación va a empujar esta convergencia, aunque algunos aún no lo vean

Hay una conexión que muchas organizaciones todavía no terminan de asumir: las exigencias regulatorias están acercando, a la fuerza, las funciones de ingeniería, ciberseguridad, riesgos y cumplimiento. Y van a acercarlas más.

DORA obliga a instituciones financieras y a buena parte de su ecosistema a profesionalizar la gestión del riesgo TIC, la resiliencia y la relación con terceros. NIS2 extiende obligaciones de gobernanza y medidas técnicas a sectores esenciales e importantes. El Cyber Resilience Act, una vez desplegado plenamente, apretará a fabricantes y proveedores de productos con elementos digitales, incluyendo obligaciones de seguridad por diseño, gestión de vulnerabilidades y documentación. Todo eso empuja en una dirección muy concreta: menos seguridad como parche posterior y más seguridad integrada en el desarrollo, la operación y la cadena de suministro.

Sumemos la IA a esa ecuación y la convergencia se vuelve inevitable. Si una herramienta de IA participa en clasificación de incidentes, priorización de vulnerabilidades, generación de código o recomendación de cambios en producción, los equipos de compliance y auditoría querrán saber qué hace, con qué datos, bajo qué controles y con qué tasa de error aceptable. Y harán bien. La época en la que se podía desplegar una tecnología compleja con una policy genérica y una demo convincente se está cerrando bastante deprisa.

Por eso la noticia de Granada importa más de lo que parece. No porque una cátedra vaya a cambiar el tablero regulatorio, sino porque responde a la dirección en la que ya se mueve el tablero. El talento que se forme hoy trabajará en entornos donde la pregunta no será solo “¿funciona?” sino “¿funciona de forma segura, explicable, gobernable y compatible con nuestras obligaciones?”. Esa es una pregunta más difícil. También más honesta.

Lo que habrá que vigilar a partir de ahora

La medida del éxito no será el anuncio, sino lo que ocurra en los próximos cursos. Hay al menos cinco señales que merecerá la pena seguir de cerca.

Una: si la cátedra publica líneas de trabajo concretas, laboratorios o proyectos aplicados, en vez de limitarse a actividades institucionales. Dos: si incorpora colaboración interdisciplinar; la seguridad con IA no es solo asunto de informáticos, también toca derecho, gobernanza y gestión del riesgo. Tres: si genera prácticas o inserción laboral medible en perfiles de seguridad aplicada, cloud, software seguro o automatización defensiva. Cuatro: si produce materiales, investigaciones o pruebas de concepto útiles para empresas reales, no solo papers que nadie fuera de la universidad leerá. Cinco: si consigue formar profesionales que entiendan tanto el entusiasmo tecnológico como sus límites. Eso es bastante más difícil que enseñar una herramienta de moda.

También habrá que observar qué tipo de IA se prioriza. Si el foco se desplaza demasiado hacia narrativa generativa y se descuida la ingeniería de base, el resultado será superficial. El mercado necesita gente que sepa trabajar con pipelines, dependencias, observabilidad, autenticación, permisos y arquitectura segura. La IA debe reforzar esas competencias, no sustituirlas con un barniz de actualidad.

Otra cuestión relevante será la relación con el tejido empresarial local. Si la cátedra se convierte en un puente entre universidad, consultora y organizaciones de distintos tamaños, puede tener efecto multiplicador. Si se concentra en un circuito demasiado cerrado, su alcance será menor. El talento en ciberseguridad se forma mejor cuando ve problemas diversos: empresa grande, pyme, administración, servicios críticos, entornos cloud, legado, producto propio. La realidad del riesgo no cabe en una sola vertical.

Una buena noticia, con una condición: que no se quede en ceremonia

La firma entre la UGR y Devoteam es, de entrada, una buena noticia. No porque descubra algo que el sector ignoraba, sino porque pone recursos y estructura sobre una necesidad evidente: formar perfiles que unan ciberseguridad, desarrollo, operaciones e inteligencia artificial. Ese cruce es donde se va a jugar una parte muy seria de la competitividad y de la resiliencia de las organizaciones en los próximos años.

La condición es obvia. Tiene que traducirse en trabajo útil. En currículo exigente. En laboratorios reales. En casos operativos. En colaboración sostenida. En estudiantes que salgan sabiendo no solo desplegar tecnología, sino cuestionarla, medirla y gobernarla. Si ocurre eso, la cátedra habrá tocado una fibra estratégica del mercado español.

Si no, será otra pieza de institucionalidad impecable, con titulares amables y efecto limitado. Y ya vamos bien servidos de eso.

El momento, en cualquier caso, está bien elegido. El software se construye más rápido, la IA se adopta más deprisa y el regulador aprieta con más precisión. Entre tanta aceleración, alguien tiene que formar a quienes luego cargarán con la responsabilidad técnica y legal. Granada quiere ocupar parte de ese espacio. Ahora toca ver si lo hace con bisturí o con folleto.