Capítulo 14 — Ingeniería de software
Mapa de la lección
Lección 14 publicada. Mapa, ejemplo, EX040.
flowchart TD
N0["Resultados de aprendizaje"]
N1["14.1 Un ciclo de vida para el software de IA"]
N2["14.2 Gestión de la configuración de modelos y prompt"]
N3["14.3 Revisión e integración continua"]
N4["14.4 Publicación y reversión"]
N5["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX040"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje"]
N1["14.1 Un ciclo de vida para el software de IA"]
N2["14.2 Gestión de la configuración de modelos y prompt"]
N3["14.3 Revisión e integración continua"]
N4["14.4 Publicación y reversión"]
N5["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX040"]
[Resultados de aprendizaje]
|
v
[14.1 Un ciclo de vida para el software de IA]
|
v
[14.2 Gestión de la configuración de modelos y prompt]
|
v
[14.3 Revisión e integración continua]
|
v
[14.4 Publicación y reversión]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX040]
Resultados de aprendizaje
Usted será capaz de (1) aplicar un ciclo de vida de desarrollo seguro al software con IA; (2) gestionar requisitos, versiones y cambios de modelos y prompts además del código; (3) realizar revisión de código e integración continua con controles de seguridad y de evaluación; y (4) planificar publicaciones y reversiones de componentes de IA.
14.1 Un ciclo de vida para el software de IA
Un ciclo de vida de desarrollo seguro añade actividades de seguridad a cada fase: requisitos (casos de abuso), diseño (modelado de amenazas), implementación (codificación segura, control de dependencias), verificación (pruebas, evaluaciones, ejercicios de equipo rojo) y publicación (aprobación formal, monitorización). En la IA, los artefactos se multiplican: código, pesos del modelo, datos de entrenamiento, prompts, índices de recuperación y conjuntos de evaluación. Cada uno debe versionarse y revisarse; un cambio en el prompt del sistema puede alterar el comportamiento de seguridad tanto como un cambio de código. Los casos de abuso se escriben junto a los requisitos normales, por ejemplo «un boletín de un proveedor intenta que Wrench cree una orden de trabajo».
14.2 Gestión de la configuración de modelos y prompts
Guarde los prompts en el control de versiones, no en una consola web. Dé a cada modelo una entrada en el registro con su hash, la versión de los datos de entrenamiento, los resultados de evaluación y el estado de aprobación. Despliegue haciendo referencia a una versión del registro, de modo que la producción siempre pueda rastrearse y revertirse. Un prompt editado en una consola web no tiene revisión, ni historial, ni vínculo con la evaluación que lo aprobó. En el control de versiones, cada cambio tiene un autor y un diff, y el control de CI se ejecuta sobre él como sobre cualquier cambio de código. La entrada del registro vincula un modelo desplegado con los datos y las pruebas que lo respaldan, de modo que un auditor puede preguntar qué se está ejecutando y obtener una respuesta exacta.
14.3 Revisión e integración continua
La revisión de código detecta errores de diseño y de lógica; en los componentes de IA, revise también los cambios de prompts y de datos. La integración continua debe ejecutar las pruebas unitarias, las comprobaciones de dependencias y un control de evaluación de seguridad: un conjunto fijo de pruebas de inyección, de jailbreak y de mal uso con umbrales que bloquean la publicación si se superan. El control debe usar pruebas reservadas, no los ejemplos con los que ajustaron los desarrolladores. Las pruebas reservadas las custodia un responsable distinto y se renuevan con nuevos patrones de ataque, de modo que el control mide la generalización y no la memoria.
14.4 Publicación y reversión
Publique de forma gradual (despliegue canario a una pequeña parte del tráfico), vigile las métricas y tenga lista la versión anterior. En los modelos, revertir significa cambiar la referencia del registro, algo fácil solo si se planificó. Un canario expone una versión nueva a una pequeña parte del tráfico real mientras la versión antigua atiende al resto. Entre las métricas vigiladas hay señales de seguridad, como las propuestas de herramientas rechazadas y las alertas del detector, no solo la latencia y los errores. La reversión debe ensayarse: el equipo de Sam vuelve cada mes a la versión anterior del registro en preproducción para confirmar que sigue funcionando, ya que una reversión nunca probada puede fallar el día en que se necesite.
14.5 Ejemplo resuelto (caso sintético de NRS)
Un desarrollador cambió el prompt del sistema de Wrench para que las respuestas fueran más amables. El control de seguridad de la CI ejecutó 300 casos de inyección reservados y observó que las propuestas de llamadas a herramientas no autorizadas subían del 1,0 % al 4,3 % (la capa de política seguía bloqueándolas, pero el umbral del control para las propuestas era del 2 %). La publicación quedó bloqueada; el equipo descubrió que una frase nueva, «intenta siempre cumplir el objetivo del usuario», fomentaba seguir las instrucciones del texto recuperado. La reformularon y la tasa volvió al 1,1 %. La capa de política hizo que ningún daño llegara a producción, pero el control detectó el debilitamiento de una capa anterior antes de su publicación.
14.6 Errores y límites
- Prompts editados directamente en producción.
- Pruebas de seguridad que los desarrolladores han visto y para las que han ajustado.
- Ninguna vía de reversión para los modelos.
Las ediciones de prompts en producción se saltan la revisión y no dejan constancia de por qué cambió el comportamiento. Las pruebas con las que han ajustado los desarrolladores muestran que el sistema puede superar esas pruebas, no que resista ataques nuevos. Los modelos sin vía de reversión obligan a los equipos a corregir los problemas hacia delante y bajo presión. Cada laguna tiene un remedio directo: prompts en el control de versiones, un control con pruebas reservadas custodiado por separado y un retorno ensayado a la última versión aprobada del registro.
Ejercicios — capítulo 14
- EX040 — Artefactos. Enumere seis artefactos de una aplicación basada en LLM que necesitan control de versiones. Rúbrica: 3 = código, pesos/ID del modelo, prompts, índice/datos de recuperación, conjuntos de evaluación, configuraciones/políticas; 2 = cuatro; 1 = dos; 0 = nada.
- EX041 — Control de seguridad. Diseñe un control de CI para Wrench (pruebas, métrica, umbral, acción). Rúbrica: 3 = conjunto reservado, métrica de tasa con umbral, bloquea la publicación; 2 = falta uno; 1 = vago; 0 = nada.
- EX042 — Cambio de prompt. ¿Por qué afectó a la seguridad un cambio para ganar amabilidad? Rúbrica: 3 = la redacción del prompt cambia las prioridades al seguir instrucciones, también hacia el texto inyectado; 2 = parcial; 1 = vago; 0 = incorrecto.
Síntesis del capítulo
La ingeniería de software de IA trata los modelos, los prompts y los datos como artefactos versionados y revisados, sometidos a controles de evaluación de seguridad con pruebas reservadas y publicados con una vía de reversión.
Siga estudiando — capítulo 14 de 50
← Capítulo 13 (borrador) · Índice de capítulos del curso · Capítulo 15 (borrador) →