Capítulo 45 — Revisión independiente del diseño
Mapa de la lección
Lección 45 publicada. Mapa, ejemplo, EX133.
flowchart TD
N0["Resultados de aprendizaje"]
N1["45.1 Independencia"]
N2["45.2 Método de revisión"]
N3["45.3 Hallazgos"]
N4["45.4 Recibir una revisión"]
N5["45.4b Criterios de gravedad"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX133"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje"]
N1["45.1 Independencia"]
N2["45.2 Método de revisión"]
N3["45.3 Hallazgos"]
N4["45.4 Recibir una revisión"]
N5["45.4b Criterios de gravedad"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX133"]
[Resultados de aprendizaje]
|
v
[45.1 Independencia]
|
v
[45.2 Método de revisión]
|
v
[45.3 Hallazgos]
|
v
[45.4 Recibir una revisión]
|
v
[45.4b Criterios de gravedad]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX133]
Resultados de aprendizaje
Usted será capaz de (1) realizar una revisión independiente de la seguridad del diseño del sistema de IA de otro equipo; (2) usar listas de comprobación estructuradas y preguntas guiadas por las amenazas; (3) redactar hallazgos con gravedad, evidencia y recomendaciones; y (4) responder de forma profesional a una revisión de su propio diseño.
45.1 Independencia
Los revisores no deben haber diseñado el sistema. Necesitan el paquete de diseño, acceso a los diseñadores para hacer preguntas y tiempo suficiente. La independencia revela suposiciones que los diseñadores no pueden ver. Un diseñador lee el diseño sabiendo lo que se pretendía y rellena las lagunas sin darse cuenta. Un revisor lee solo lo que está escrito. Esa diferencia encuentra suposiciones como «la recuperación se filtra en algún sitio» que los diseñadores nunca pusieron por escrito. El acceso a los diseñadores también importa, pero las preguntas y respuestas se registran, de modo que la explicación acaba en el diseño y no en las notas del revisor.
45.2 Método de revisión
Combine una lista de comprobación con una exploración guiada por las amenazas. Elementos de la lista: fronteras de confianza dibujadas; aplicación de políticas fuera del modelo; herramientas con mínimo privilegio; identidad delegada; procedencia y contaminación; tratamiento de las salidas; verificación de la cadena de suministro; protección de datos; monitorización y manuales de operación; controles de evaluación con conjuntos reservados; diseño de la supervisión humana; modos de fallo y estados seguros. Exploración guiada por las amenazas: recorra las entradas de OWASP LLM 2025 y las técnicas pertinentes de MITRE ATLAS frente al diseño y pregunte, para cada una, «¿qué detiene esto y qué pasa si eso falla?».
La lista de comprobación garantiza la cobertura, y el recorrido de las amenazas encuentra los problemas propios del diseño.
45.3 Hallazgos
Cada hallazgo: título; gravedad (con criterios); descripción; evidencia (diagrama, sección del documento); impacto; recomendación; y estado. Separe los hallazgos de las observaciones y de las notas positivas. Sea lo bastante específico para que los diseñadores puedan actuar. Un hallazgo como «la recuperación puede ser insegura» no da a los diseñadores nada sobre lo que actuar. «La recuperación usa una cuenta de servicio con acceso a todos los depósitos; el filtrado solo se hace en el prompt; un usuario podría pedir los documentos de otro depósito» enuncia la evidencia y el impacto, y la corrección se deduce sola. Las notas positivas también importan, porque muestran qué prácticas conservar cuando cambie el diseño.
45.4 Recibir una revisión
Agradezca a los revisores, aclare los malentendidos en los documentos de diseño (si un revisor no lo entendió, otros tampoco lo entenderán), acepte o rebata los hallazgos con evidencia y haga un seguimiento de cada hallazgo hasta su cierre. Rebatir un hallazgo es legítimo cuando la evidencia lo respalda, por ejemplo una prueba que muestra que la vía de ataque del revisor está bloqueada. Hacer el seguimiento de cada hallazgo hasta su cierre, incluidos los rebatidos, impide que la revisión se olvide después de la reunión. Una tabla de respuesta breve con cada hallazgo, la decisión y la evidencia suele bastar, y se incorpora al expediente.
45.4b Criterios de gravedad
Acuerde los criterios de gravedad antes de la revisión. Por ejemplo: crítica, un atacante externo puede causar un impacto en la seguridad funcional o una divulgación a gran escala sin interacción del usuario; alta, el impacto requiere una condición verosímil; media, el impacto es limitado o requiere condiciones inusuales; baja, bastionado. Unos criterios compartidos evitan discusiones sobre las etiquetas y permiten comparar los hallazgos de revisiones distintas. Aplicado a la revisión de Crew Chat de Sam, el hallazgo de la recuperación es alto y no crítico: un técnico de un depósito solo necesita una condición verosímil, una pregunta bien formulada, para revelar los documentos de otro depósito, pero el atacante tiene que ser ya un usuario interno. La falta de escapado de las salidas es media, porque explotarla requiere texto controlado por el atacante en una respuesta representada.
45.5 Ejemplo resuelto (caso sintético de NRS)
Sam revisó el diseño «Crew Chat» de otro equipo (un asistente para las cuadrillas de vía). Hallazgo alto: la recuperación del asistente usaba una cuenta de servicio con acceso a los documentos de todos los depósitos y filtraba los resultados solo en el prompt («responde solo sobre tu depósito»). Recomendación: permisos de recuperación por usuario aplicados en la consulta al almacén vectorial. Medio: ningún escapado de las salidas para una vista web. Positivo: un etiquetado de la procedencia excelente. El equipo corrigió el hallazgo alto antes del siguiente hito.
Filtrar en el prompt es una petición al modelo, no un control de acceso; una pregunta bien formulada podría recuperar y revelar los documentos de otro depósito.
45.6 Errores y límites
- Revisiones hechas por los propios diseñadores.
- Hallazgos vagos sin evidencia.
- Ignorar las revisiones incómodas.
La autorrevisión rara vez encuentra las suposiciones que causaron un problema, porque las hizo la misma persona. Los hallazgos sin evidencia son difíciles de abordar y fáciles de descartar. Ignorar una revisión incómoda desperdicia el esfuerzo invertido en ella y deja el riesgo en su sitio, a menudo para redescubrirlo más tarde en un incidente. El equipo de Sam guardó cada hallazgo en un sistema de seguimiento que el panel podía leer. Los elementos cerrados seguían visibles.
Ejercicios — capítulo 45
- EX133 — Lista de comprobación. Enumere ocho elementos de una lista de comprobación para la revisión del diseño de un agente basado en LLM. Rúbrica: 3 = ocho pertinentes; 2 = seis; 1 = tres; 0 = ninguno.
- EX134 — Hallazgo. Redacte el hallazgo alto de Crew Chat en formato completo. Rúbrica: 3 = todos los campos; 2 = la mayoría; 1 = vago; 0 = nada.
- EX135 — Filtrado en el prompt. ¿Por qué no basta con poner «responde solo sobre tu depósito» en el prompt? Rúbrica: 3 = el modelo puede ser manipulado; los datos ya están en el contexto; la aplicación debe hacerse en la recuperación; 2 = parcial; 1 = vago; 0 = incorrecto.
Síntesis del capítulo
La revisión independiente, con listas de comprobación estructuradas más preguntas guiadas por las amenazas, produce hallazgos específicos y con evidencia a los que se hace seguimiento hasta su cierre.
Siga estudiando — capítulo 45 de 50
← Capítulo 44 (borrador) · Índice de capítulos del curso · Capítulo 46 (borrador) →