La Administración Pública española vive un proceso de transformación digital que, en los últimos años, ha incorporado un nuevo actor con capacidad de alterar profundamente la forma en que se construye el software: la Inteligencia Artificial generativa. Esta irrupción no es ajena a las Administraciones Locales, que cada vez con mayor frecuencia desarrollan o contratan aplicaciones, sedes electrónicas, portales de transparencia o sistemas de gestión de expedientes apoyándose en herramientas de IA para acelerar la programación, generar pruebas o automatizar despliegues. Sin embargo, la velocidad que aporta la IA no puede ir nunca en detrimento de dos exigencias irrenunciables en el ámbito público: la calidad del software, garantizada históricamente por las metodologías de ciclo de vida, y la seguridad de la información, garantizada por el marco normativo del Esquema Nacional de Seguridad, regulado por el Real Decreto 311/2022, de 3 de mayo.
La tesis que se defiende en este tema es que la IA generativa no sustituye al ciclo de vida del software ni exime del cumplimiento del ENS, sino que se inserta como una herramienta más dentro de las fases ya existentes; y precisamente por su carácter probabilístico y no determinista, exige reforzar —no relajar— los mecanismos de auditoría, trazabilidad y control de calidad que el código generado por humanos ya tenía, aunque ahora con matices propios derivados de su origen automatizado. Para desarrollarla, conviene partir del marco que ya existía antes de que la IA llegara al desarrollo de software, es decir, del propio ciclo de vida y de las metodologías que lo sustentan, para después analizar cómo se inserta la IA en cada una de sus fases, cómo se audita el resultado de esa inserción, y cómo todo ello queda finalmente enmarcado por las exigencias del Esquema Nacional de Seguridad.
El ciclo de vida del software puede entenderse como el conjunto de fases por las que atraviesa un producto desde que se concibe la necesidad hasta que se retira de producción. De forma clásica, este recorrido arranca con la planificación y el análisis de requisitos, donde se define qué debe hacer el sistema y se identifican las restricciones funcionales, legales y de seguridad que deberá respetar; continúa con el diseño, en el que se establece la arquitectura, el modelo de datos y las interfaces; sigue con la construcción o codificación, fase en la que el diseño se traduce en código fuente; avanza hacia las pruebas, donde se verifica que el sistema cumple los requisitos y no contiene defectos; se materializa en el despliegue o implantación, momento en el que el sistema se pone en producción; y se prolonga en el mantenimiento, donde se corrigen errores, se actualiza el sistema y se lo adapta a nuevas necesidades. Esta secuencia de fases constituye el esqueleto sobre el que se apoyará todo el análisis posterior, porque cuando más adelante se hable de IA generativa, lo que en realidad se estará describiendo es cómo esa tecnología incide en cada una de estas fases sin alterar su lógica de fondo.
Ahora bien, la forma de organizar estas fases ha evolucionado con el tiempo. El modelo en cascada, secuencial y rígido, resultaba adecuado cuando los requisitos eran estables y estaban muy documentados, como puede ocurrir con cierta normativa de obligado cumplimiento, pero se mostraba poco flexible ante el cambio. Los modelos iterativos e incrementales surgieron precisamente para reducir ese riesgo, construyendo versiones sucesivas del producto en lugar de esperar a un único gran entregable final. Sobre esa base se asentaron las metodologías ágiles, como Scrum o Kanban, que organizan el desarrollo en ciclos cortos o sprints, con entregas incrementales, retroalimentación constante del cliente y adaptación continua al cambio, y que hoy predominan en los proyectos de Administración Electrónica. Más recientemente, la filosofía DevOps ha venido a integrar desarrollo y operaciones mediante la automatización de la integración continua y la entrega o despliegue continuo, reduciendo drásticamente el tiempo que transcurre entre que se escribe una línea de código y esa línea llega a producción. Y de DevOps ha surgido, a su vez, DevSecOps, que añade la seguridad como práctica continua desde el primer momento del ciclo, en lugar de tratarla como un sello final que se estampa justo antes de pasar a producción. Este último concepto merece subrayarse porque es el puente natural hacia la Inteligencia Artificial: muchas de las herramientas de IA aplicadas al desarrollo se integran precisamente en esas canalizaciones de integración y despliegue continuo, de modo que cualquier reflexión sobre IA en el desarrollo de software termina remitiendo, tarde o temprano, a cómo se gestiona esa seguridad continua.
Esa idea de seguridad continua tiene, además, un anclaje normativo preciso. Tanto el propio Real Decreto 311/2022 como, antes que él, el Reglamento General de Protección de Datos, consagran los principios de seguridad desde el diseño y por defecto. Esto significa que la seguridad no se añade al final del desarrollo como un parche, sino que se planifica desde la fase de requisitos y se mantiene como criterio de diseño en todas las fases posteriores. Esta idea resulta clave para entender, ya desde ahora, por qué la IA generativa, cuando se introduce en el ciclo de vida, no puede limitarse a generar código que simplemente funcione: debe generar código que funcione de forma segura, y ese carácter seguro debe poder verificarse en cada fase del proceso, no únicamente al final.
La aplicación de la Inteligencia Artificial al desarrollo de software no es, en realidad, un fenómeno completamente nuevo: durante años se han empleado sistemas basados en reglas y técnicas de análisis estático para detectar patrones de código defectuoso. Sin embargo, el salto cualitativo se ha producido con la llegada de los grandes modelos de lenguaje, entrenados con enormes volúmenes de texto y código, capaces de generar contenido nuevo —no solo de clasificar o predecir— a partir de instrucciones en lenguaje natural, en lo que se conoce como Inteligencia Artificial generativa. Estos modelos se integran en el flujo de trabajo del desarrollador a través de asistentes de codificación o copilots, incorporados en los propios entornos de desarrollo, capaces de sugerir líneas de código, completar funciones, explicar fragmentos existentes o generar pruebas a partir de las instrucciones del programador o del contexto del proyecto en el que trabajan.
Esa capacidad generativa se manifiesta, en primer lugar, en las fases más tempranas del ciclo de vida. En la planificación y el diseño, la IA puede asistir en la redacción y el refinamiento de requisitos funcionales y no funcionales a partir de descripciones informales del usuario, en la generación de propuestas preliminares de arquitectura o de modelo de datos que después deberá validar un arquitecto o un analista, y en la elaboración de documentación técnica o diagramas a partir de descripciones textuales. En todos estos casos conviene tener presente que la IA actúa como acelerador de un borrador, nunca como decisor final: el principio que debe regir es el de la supervisión humana significativa, especialmente relevante en el sector público, donde las decisiones de diseño pueden tener implicaciones jurídicas, por ejemplo cuando está de por medio el tratamiento de datos personales de la ciudadanía.
Es, no obstante, en la fase de construcción donde el impacto de la IA resulta más visible y donde se concentra buena parte del debate actual. Las herramientas de IA generativa permiten un autocompletado avanzado que va mucho más allá del autocompletado sintáctico tradicional, sugiriendo bloques completos de lógica de negocio; permiten generar código directamente a partir de comentarios o instrucciones en lenguaje natural, como pedir que se genere una función que valide un NIF; facilitan la refactorización asistida, proponiendo mejoras sobre código ya existente sin alterar su funcionalidad; y abren la puerta a la traducción entre lenguajes de programación, lo que resulta especialmente útil en los procesos de modernización de aplicaciones heredadas, muy presentes precisamente en el ámbito de la Administración Local. Conviene retener aquí una idea que recorrerá el resto del tema: el código generado por IA debe tratarse, a todos los efectos de calidad y seguridad, como código de origen externo no verificado, hasta que supere los mismos controles —o controles más exigentes— que el código escrito por una persona. Esta idea es la que conecta de forma natural este bloque con el de la auditoría y con el del Esquema Nacional de Seguridad que se desarrollan más adelante.
Otro de los terrenos donde la IA aporta un valor especialmente maduro es el de las pruebas. A partir de la especificación funcional o de la interfaz del sistema, sin necesidad de conocer su implementación interna, los modelos pueden generar casos de prueba de caja negra que cubran valores límite, particiones de equivalencia y escenarios de error, agilizando notablemente la fase de pruebas de aceptación. Cuando, por el contrario, se tiene acceso al código fuente, esos mismos modelos pueden analizar la lógica interna del programa y proponer casos de prueba de caja blanca orientados a maximizar la cobertura de código —de sentencias, de decisión, de condición—, detectando ramas de ejecución que no estaban siendo probadas o fragmentos de código muerto. A ello se suman las pruebas de regresión y de mutación, en las que la IA puede generar variantes del código para comprobar la robustez de la batería de pruebas existente, así como mantener actualizados los conjuntos de pruebas de regresión a medida que el código cambia. Todo ello no elimina, en ningún caso, la necesidad de pruebas funcionales validadas por personas, especialmente en sistemas que afectan a derechos de la ciudadanía, como el cálculo de tasas, los plazos administrativos o las notificaciones; lo que sí permite es ampliar de forma muy significativa la cobertura de pruebas con el mismo esfuerzo humano que antes.
Dentro ya de las canalizaciones de integración y despliegue continuo, la IA se aplica al análisis predictivo de fallos en los procesos de construcción del software, anticipando qué cambios tienen mayor probabilidad de romper el sistema; a la generación automática de scripts de infraestructura como código y de configuración de contenedores; a la detección de anomalías en registros y métricas de producción mediante modelos de aprendizaje automático, lo que mejora la observabilidad del sistema; y a la respuesta asistida ante incidentes, proponiendo causas probables y posibles acciones de remediación, en lo que suele denominarse AIOps. Finalmente, en la fase de mantenimiento, la IA asiste en la generación automática de documentación técnica a partir del código existente, en la explicación de código heredado especialmente complejo, y, de forma muy relevante para el hilo de este tema, en el análisis de seguridad del propio código mediante el reconocimiento de patrones asociados a vulnerabilidades conocidas, como la inyección SQL, los desbordamientos de buffer o el uso de funciones criptográficas débiles, lo que anticipa ya el contenido del siguiente bloque.
El uso de Inteligencia Artificial generativa introduce, junto a sus indudables ventajas, una serie de riesgos específicos que justifican someter el código resultante a una auditoría más exigente que la que tradicionalmente se aplicaba al código escrito íntegramente por personas. El primero de estos riesgos son las llamadas alucinaciones: el modelo puede generar código sintácticamente correcto pero funcionalmente erróneo, o referenciar librerías, funciones o interfaces que en realidad no existen. El segundo es el sesgo de entrenamiento, de modo que si el modelo se ha entrenado con código de baja calidad o con prácticas inseguras —por ejemplo, ejemplos públicos con vulnerabilidades ya conocidas— tiende a reproducir esos mismos patrones inseguros en sus sugerencias. El tercero es el riesgo de fuga de información, derivado de que los datos sensibles introducidos como contexto en una instrucción o prompt, como credenciales o datos personales contenidos en un expediente, puedan ser retenidos o expuestos por el proveedor del modelo, en particular cuando se trata de servicios de IA alojados en la nube. El cuarto riesgo tiene que ver con las dependencias inseguras, ya que los modelos muestran cierta tendencia a sugerir librerías de terceros sin verificar su mantenimiento, su licencia o sus vulnerabilidades conocidas, lo que reabre el problema más amplio de la seguridad en la cadena de suministro de software. Y, por último, está la falta de explicabilidad, esto es, la dificultad de conocer con precisión por qué el modelo ha generado una solución concreta, lo que complica notablemente la atribución de responsabilidad cuando se produce un incidente. Frente a todo ello, el principio que debe regir la actuación de cualquier Administración es que toda incorporación de código generado por IA a un repositorio pase por un proceso de auditoría equivalente —o superior— al exigido al código de desarrollo propio, y nunca inferior a él.
Esa auditoría se apoya, en la práctica, en un conjunto de técnicas complementarias entre sí. El análisis estático de código, conocido habitualmente por su sigla en inglés SAST, examina el código fuente sin necesidad de ejecutarlo, buscando patrones inseguros, y resulta especialmente útil para detectar vulnerabilidades introducidas por sugerencias automáticas antes de que el sistema llegue a desplegarse. El análisis dinámico, o DAST, examina en cambio la aplicación ya en ejecución, simulando ataques reales, lo que permite verificar el comportamiento efectivo del código más allá de su apariencia sintáctica. El análisis de composición de software, conocido como SCA, inventaría las dependencias y librerías de terceros empleadas y sus vulnerabilidades conocidas, controlando así el riesgo de que la propia IA haya sugerido una librería vulnerable o sin mantenimiento activo. Junto a estas técnicas automatizadas resulta imprescindible la revisión por pares o revisión humana, en la que un segundo desarrollador examina y aprueba el código antes de integrarlo en el repositorio principal mediante una solicitud de incorporación de cambios, aportando precisamente el juicio crítico que la máquina no tiene y que permite detectar las alucinaciones funcionales que un análisis puramente automático podría pasar por alto. A todo ello se suman, en sistemas de mayor criticidad, las pruebas de penetración realizadas por equipos expertos que intentan explotar el sistema de forma controlada, validando de manera realista el conjunto de la aplicación, incluidas aquellas partes que se hayan generado con asistencia de IA.
Existe, sin embargo, un elemento de auditoría que resulta específico del código generado por IA y que no tiene un equivalente exacto en el código tradicional: la necesidad de mantener una cadena de trazabilidad completa que permita saber qué modelo se utilizó, en qué versión, con qué instrucción concreta, qué proporción del fichero final procede de la sugerencia automática, y qué persona física ha revisado y aprobado finalmente su incorporación. Esta trazabilidad, que podría resumirse como la capacidad de reconstruir el camino que va del prompt al commit, es precisamente la que permite, ante un incidente de seguridad, reconstruir el origen del código afectado, y resulta plenamente coherente con el principio de responsabilidad proactiva que exigen tanto el Reglamento General de Protección de Datos como el propio Esquema Nacional de Seguridad. Esta exigencia de trazabilidad enlaza, de hecho, de manera directa con el bloque normativo que se desarrolla a continuación, puesto que el ENS no se limita a exigir que un sistema sea seguro, sino que además pueda demostrarse que lo es, mediante el correspondiente registro de actividad y las auditorías periódicas que la propia norma impone.
El Esquema Nacional de Seguridad se regula actualmente en el Real Decreto 311/2022, de 3 de mayo, que deroga al anterior Real Decreto 3/2010 y desarrolla el artículo 156.2 de la Ley 40/2015, de Régimen Jurídico del Sector Público. Su finalidad consiste en establecer la política de seguridad en la utilización de medios electrónicos por parte de las Administraciones Públicas, incluida la Administración Local, garantizando el acceso, la integridad, la disponibilidad, la autenticidad, la confidencialidad, la trazabilidad y la conservación de los datos, las informaciones y los servicios. El artículo 4 de dicho Real Decreto recoge los principios básicos de la seguridad, entre los que figuran la seguridad integral, la gestión de riesgos, la prevención, la reacción y la recuperación, la existencia de líneas de defensa, la reevaluación periódica y la diferenciación de responsabilidades. De entre todos ellos, dos resultan particularmente pertinentes para el objeto de este tema: por un lado, la idea de que la seguridad debe entenderse como un proceso integral que contempla todos los elementos técnicos, humanos y organizativos del sistema, lo que obliga a incluir expresamente las herramientas de Inteligencia Artificial empleadas en el desarrollo dentro del perímetro del análisis de riesgos; y, por otro, el principio de líneas de defensa, conforme al cual, si una medida concreta falla —por ejemplo, si un asistente de IA sugiere código vulnerable—, deben existir medidas adicionales capaces de detener esa amenaza antes de que se materialice, función que cumple precisamente la auditoría descrita en el bloque anterior.
El propio Esquema Nacional de Seguridad exige categorizar cada sistema de información en alguno de los niveles básico, medio o alto, en función del impacto que tendría sobre las dimensiones de seguridad un incidente que afecte a la confidencialidad, la integridad, la trazabilidad, la autenticidad y la disponibilidad de la información que maneja. Esta categorización es la que determina qué medidas concretas del Anexo II resultan exigibles en cada caso. Entre esas medidas, varias guardan una relación directa con el ciclo de vida del software y, por extensión, con el uso de la IA en su desarrollo. Así, dentro del marco de planificación, el análisis de riesgos del sistema debe incorporar de forma expresa el riesgo derivado del uso de IA generativa, ya sea en forma de alucinaciones, de fuga de información a través de los prompts o de dependencias inseguras sugeridas por el propio modelo. Dentro del marco operacional, la gestión de la configuración y de los cambios exige que toda incorporación de código generado por IA se tramite como un cambio controlado, con un registro de quién lo generó, cuándo y con qué herramienta, integrándose así en la gestión de configuración del repositorio correspondiente. Cuando se recurre a un proveedor externo de IA, como suele ocurrir con los servicios de copilots ofrecidos como software como servicio, deben aplicarse las mismas garantías que el ENS exige frente a cualquier recurso externo contratado, lo que obliga a conocer dónde se procesan los prompts enviados, si esos prompts se emplean para reentrenar el modelo, o dónde se ubican los servidores que prestan el servicio. La propia monitorización continua del sistema debe, además, ser capaz de distinguir comportamientos anómalos derivados de componentes generados por IA, y no solo de ataques externos clásicos. Y, en el marco de protección de las aplicaciones informáticas, la norma exige que toda aplicación se someta a un ciclo de desarrollo seguro, con especificación de requisitos de seguridad y con un control de calidad y aceptación previo a su paso a producción, ciclo que el código de origen IA debe superar exactamente en los mismos términos que cualquier otro código.
Todo este conjunto de exigencias se articula, además, a través de un ciclo de mejora continua que el propio Esquema Nacional de Seguridad adopta de la familia de normas ISO 27000: el conocido ciclo PDCA, que distingue entre planificar, hacer, verificar y actuar. Aplicado al desarrollo de software asistido por IA, ese ciclo se traduce, en la fase de planificación, en definir la política de uso de herramientas de IA en el desarrollo, determinando qué herramientas están autorizadas y qué tipo de información puede introducirse en los prompts; en la fase de ejecución, en aplicar efectivamente esa política integrando los controles de auditoría —de análisis estático, de composición de software y de revisión humana— en la propia canalización de integración y despliegue continuo; en la fase de verificación, en comprobar mediante auditorías internas y externas, y mediante indicadores como el porcentaje de código de origen IA o el número de vulnerabilidades detectadas en ese código frente al código tradicional, que la política se cumple y resulta eficaz; y, finalmente, en la fase de actuación, en corregir las desviaciones detectadas, actualizar la política a medida que aparecen nuevas versiones de los modelos de IA o nuevas amenazas, y formar al personal en consecuencia. Este enfoque cíclico resulta plenamente coherente con el principio de reevaluación periódica del propio Esquema Nacional de Seguridad, y permite entender que la incorporación de la IA al desarrollo de software no debe concebirse como una decisión puntual, sino como un proceso de mejora continua y permanentemente auditable.
Llegados a este punto, conviene poner en relación todo lo expuesto y aterrizarlo en una propuesta concreta para una entidad local. Los riesgos que se han ido describiendo a lo largo del tema —el riesgo funcional de un código que parece correcto pero no responde al requisito real, el riesgo de seguridad técnica derivado de vulnerabilidades heredadas del entrenamiento del modelo o de las dependencias que este sugiere, el riesgo de protección de datos que se materializa cuando se introducen datos personales de la ciudadanía en prompts enviados a servicios externos, el riesgo de dependencia tecnológica que surge cuando la propia organización pierde la capacidad de mantener un código que ya no comprende del todo porque fue generado por un tercero automatizado, y el riesgo reputacional y de responsabilidad que aparece cuando resulta difícil justificar ante la ciudadanía o ante un órgano de control quién responde de un fallo originado por una sugerencia de IA no auditada— no son compartimentos estancos, sino que se refuerzan entre sí, y solo pueden abordarse de manera conjunta.
De ahí que cualquier entidad local que decida incorporar la Inteligencia Artificial a su proceso de desarrollo deba dotarse de un modelo de gobernanza mínimo, coherente con los principios del Esquema Nacional de Seguridad. Ese modelo pasa, en primer lugar, por aprobar una política de uso de IA en el desarrollo al nivel adecuado dentro de la organización, que delimite con claridad qué herramientas están autorizadas y qué tipos de datos no pueden en ningún caso incluirse en un prompt. Pasa, también, por que las figuras del Responsable de Seguridad y del Responsable del Sistema, ya previstas en el propio ENS, extiendan de forma expresa su función de supervisión al uso de la IA en el desarrollo, de modo que no queden al margen de su ámbito de control. Exige, además, integrar los controles automáticos de análisis estático y de composición de software como una puerta de entrada obligatoria dentro de la canalización de integración y despliegue continuo, de manera que ningún código, esté o no generado por IA, pueda llegar a producción sin haber superado ese filtro. Requiere igualmente que toda incorporación de código de origen IA sea objeto de una revisión humana obligatoria antes de fusionarse con el repositorio principal, revisión que debe quedar documentada en el propio sistema de control de versiones. Necesita, asimismo, un registro de trazabilidad que recoja la herramienta empleada, su versión, el prompt utilizado y la persona que finalmente aprobó el cambio, integrado dentro de la gestión de la configuración que exige el ENS. Demanda, también, que las auditorías periódicas —tanto las ordinarias, con la periodicidad que corresponda según la categoría del sistema, como las extraordinarias que puedan derivarse de un incidente— incluyan de forma expresa una muestra de código de origen IA, y no solo del código desarrollado de manera tradicional. Y exige, por último, una formación continua del personal desarrollador que no se limite al uso técnico de las herramientas de IA, sino que alcance también a sus riesgos y a la normativa de protección de datos y de seguridad que resulta aplicable.
Un modelo así construido permite que la entidad local pueda beneficiarse de las ganancias de productividad que ofrece la IA generativa —más código producido, más pruebas generadas, despliegues más frecuentes— sin renunciar por ello a las garantías de calidad que exige el ciclo de vida del software ni a las garantías de seguridad que exige el Esquema Nacional de Seguridad, demostrando así que ambos marcos no constituyen un freno a la innovación, sino precisamente la condición que la hace sostenible en el tiempo dentro del sector público.
La Inteligencia Artificial generativa ha pasado, en muy pocos años, de ser una curiosidad experimental a convertirse en una herramienta presente en prácticamente todas las fases del ciclo de vida del software: ayuda a definir requisitos, genera código, propone pruebas de caja blanca y caja negra, automatiza canalizaciones DevOps y asiste en el mantenimiento. Esta capacidad de aceleración es real y debe aprovecharse también en el ámbito de la Administración Local, donde los recursos técnicos suelen ser limitados. Ahora bien, esa misma capacidad de generar grandes volúmenes de código de forma rápida, no determinista y sin garantía intrínseca de corrección obliga a reforzar exactamente los mismos mecanismos que ya existían: las metodologías de ciclo de vida que estructuran el desarrollo, las técnicas de auditoría informática que garantizan la calidad y la trazabilidad del código, y el marco del Esquema Nacional de Seguridad, que exige que toda esa actividad sea, además de eficiente, demostrablemente segura. En definitiva, la Inteligencia Artificial no resuelve por sí sola el reto de construir software seguro en la Administración; lo que hace, en realidad, es desplazar el foco del esfuerzo humano: menos tiempo escribiendo código línea a línea, y más tiempo auditando, supervisando y garantizando que ese código —venga de quien venga— cumple con los principios de seguridad desde el diseño que toda Administración Pública debe a la ciudadanía a la que sirve.