Capítulo 44 — Proyecto final de ingeniería I
Mapa de la lección
Lección 44 publicada. Mapa, ejemplo, EX130.
flowchart TD
N0["Resultados de aprendizaje"]
N1["44.1 Elección del proyecto"]
N2["44.2 Plan del proyecto"]
N3["44.3 Aprobación de la línea base"]
N4["44.4 Trabajo en equipo"]
N5["44.4b Ética y autorización del proyecto final"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX130"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje"]
N1["44.1 Elección del proyecto"]
N2["44.2 Plan del proyecto"]
N3["44.3 Aprobación de la línea base"]
N4["44.4 Trabajo en equipo"]
N5["44.4b Ética y autorización del proyecto final"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX130"]
[Resultados de aprendizaje]
|
v
[44.1 Elección del proyecto]
|
v
[44.2 Plan del proyecto]
|
v
[44.3 Aprobación de la línea base]
|
v
[44.4 Trabajo en equipo]
|
v
[44.4b Ética y autorización del proyecto final]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX130]
Resultados de aprendizaje
Usted será capaz de (1) definir un proyecto final de ingeniería de seguridad de la IA con un cliente, requisitos y restricciones; (2) planificarlo con hitos, riesgos y verificación; (3) elaborar la línea base de requisitos del sistema y de arquitectura; y (4) obtener la aprobación para construirlo.
44.1 Elección del proyecto
Un buen proyecto final tiene un cliente real (o un cliente sintético realista), un componente de IA con un riesgo de seguridad significativo, un entregable que pueda construirse y verificarse en dos semestres y una evaluación clara. Ejemplos: un asistente RAG protegido con aplicación de políticas y entorno de evaluación; una canalización de datos resistente al envenenamiento; un servicio de monitorización de la extracción y el abuso. Dos semestres pasan rápido, así que un proyecto que necesita meses de recogida de datos antes de poder construir nada suele ser demasiado grande. Los ejemplos comparten un patrón: una amenaza clara, un componente que el equipo puede construir y controlar, y una medición que mostrará si funciona. Un cliente aporta al proyecto requisitos reales y un revisor ajeno a la universidad.
44.2 Plan del proyecto
Incluya: planteamiento del problema; partes interesadas; alcance y exclusiones; requisitos (funcionales, de seguridad, estadísticos, operativos) con métodos de verificación; arquitectura con fronteras de confianza; modelo de amenazas; plan de verificación; registro de riesgos del propio proyecto (acceso a los datos, cómputo, disponibilidad del equipo); hitos y entregables; ética y autorización. El registro de riesgos del plan cubre el proyecto, no el sistema: un acuerdo de datos que se retrasa, un presupuesto de nube que se agota o un miembro del equipo que cae enfermo. Cada riesgo tiene una mitigación, como datos sintéticos preparados con antelación. Los hitos se espacian de modo que cada uno produzca algo que el panel pueda inspeccionar, lo que mantiene visible el avance y hace aflorar pronto los problemas.
44.3 Aprobación de la línea base
Un panel de revisión aprueba la línea base: requisitos, arquitectura y plan. Tras la aprobación, los cambios pasan por el control de cambios, de modo que la ampliación del alcance sea visible y esté justificada. El control de cambios no prohíbe cambiar. Pide que cada cambio indique qué añade, qué cuesta y a qué requisitos o pruebas afecta, y que el panel o el cliente estén de acuerdo. Un equipo que añade adjuntos de imagen a Bulletin Gate a mitad del proyecto debe demostrar que el calendario sigue siendo viable y que las nuevas amenazas están cubiertas, o aplazar la funcionalidad como estaba previsto inicialmente.
44.4 Trabajo en equipo
Asigne roles (responsable, arquitecto de seguridad, ingeniero de ML, responsable de pruebas), pero rote las tareas de revisión para que todos entiendan el conjunto. Deje constancia de las decisiones en ADR y mantenga reuniones breves con acciones registradas. Los roles fijos dejan clara la responsabilidad, pero rotar las revisiones reparte la comprensión, de modo que el proyecto sobrevive si falta un miembro. Un arquitecto de seguridad que revisa la canalización de datos del ingeniero de ML, y a la inversa, detecta problemas que ninguno de los dos vería por separado. Las reuniones breves con acciones escritas evitan decisiones que solo existen en la memoria de alguien, y los registros de decisiones explican más tarde las elecciones al panel.
44.4b Ética y autorización del proyecto final
Incluso los proyectos sintéticos necesitan una nota de autorización: qué entornos, datos y cuentas puede usar el equipo, y qué está prohibido (sistemas de producción, datos personales reales, servicios públicos de IA más allá de sus condiciones). Si un cliente proporciona datos reales, acuerde por escrito las condiciones de protección de datos antes de recibirlos. Para Bulletin Gate, la nota nombraba las copias de preproducción de Wrench y del almacén de boletines, solo boletines sintéticos o autorizados por los proveedores, y ninguna conexión con el sistema de órdenes de trabajo de producción. También recogía la condición del panel: el otro equipo que redactaba los ataques adaptativos estaba autorizado a atacar solo la instancia de preproducción de Bulletin Gate, y sus cadenas de ataque se guardaban con la evidencia en lugar de compartirse fuera del curso.
44.5 Ejemplo resuelto (caso sintético de NRS)
El equipo de Sam eligió «Bulletin Gate»: un servicio que ingiere los boletines de proveedores, extrae hechos de mantenimiento estructurados con un modelo en cuarentena, señala el contenido con apariencia de instrucción y solo pasa registros estructurados a Wrench. Los requisitos incluían: exactitud de extracción ≥ 95 % en 500 boletines reservados; ningún texto de instrucción en los registros de salida (impuesto por el esquema); latencia mediana ≤ 2 s; procedencia completa. Exclusiones: adjuntos de imagen (aplazados). El panel lo aprobó con una condición: añadir un conjunto de pruebas de ataques adaptativos redactado por otro equipo.
El requisito impuesto por el esquema es notable porque es absoluto y no estadístico: el formato de salida no tiene ningún campo que pueda contener texto libre de instrucciones.
44.6 Errores y límites
- Proyectos finales demasiado grandes para verificarlos.
- Requisitos sin métodos de verificación.
- Ningún control de cambios tras la aprobación.
Un proyecto final sobredimensionado termina con un sistema construido a medias y apenas probado, lo que da un expediente débil. No puede demostrarse que se cumplen los requisitos sin métodos de verificación, y estos invitan a discusiones en la revisión final. Sin control de cambios, el alcance deriva sin hacer ruido, los plazos se retrasan y el panel no puede saber qué se aprobó. El equipo de Sam revisó el alcance frente al esfuerzo de verificación en cada hito. Recortar el alcance pronto costó menos que recortar pruebas tarde.
Ejercicios — capítulo 44
- EX130 — Alcance. Redacte el alcance y las exclusiones de un proyecto final que protege un asistente RAG. Rúbrica: 3 = elementos claros dentro del alcance y exclusiones justificadas; 2 = una parte débil; 1 = vago; 0 = nada.
- EX131 — Registro de riesgos. Enumere tres riesgos del proyecto y sus mitigaciones. Rúbrica: 3 = tres pertinentes con mitigaciones; 2 = dos; 1 = uno; 0 = ninguno.
- EX132 — Condición del panel. ¿Por qué exigió el panel que otro equipo redactara los ataques adaptativos? Rúbrica: 3 = independencia; quienes construyen no ven sus propias suposiciones; 2 = parcial; 1 = vago; 0 = incorrecto.
Síntesis del capítulo
El proyecto final I fija una línea base verificable: un problema realista, requisitos medibles, una arquitectura defendible, un plan de proyecto con sus riesgos y pruebas adversariales independientes incorporadas.
Siga estudiando — capítulo 44 de 50
← Capítulo 43 (borrador) · Índice de capítulos del curso · Capítulo 45 (borrador) →