M3 · Responsible AI, Safety & Risk for Architects — Resumen de estudio

Curso 3 de 5 · 21 pantallas, 5 secciones, 7 checkpoints, ~114 min

Pregunta central: ¿qué controles impiden que el sistema rechace una petición válida, produzca un resultado injusto o ejecute una acción que nadie aprobó?

La seguridad es una pila de controles: cada uno cubre una parte del camino y tiene un punto ciego que el siguiente debe cubrir.

Las 5 decisiones encadenadas:

1. Frontera de alignment.
2. Ubicación de los guardrails.
3. Fairness y transparencia.
4. Enrutamiento a revisión humana.
5. Control register de compliance.

Cada una alimenta a la siguiente: el logging de fairness es el mismo que usa el revisor y el que respalda el register.

1. Alignment: lo que hace el entrenamiento vs lo que te toca a ti

• Anthropic entrena a Claude con una constitution (versión publicada en enero de 2026).
  • Orden de prioridad: broadly safe → ethical → cumplir guidelines → genuinely helpful.
  • El orden es holístico, no estricto: el modelo pondera las prioridades en conjunto.
• Training-time alignment: reduce clases amplias de daño y es general por diseño. No conoce la política de dominio, las reglas de datos ni el modelo de autorización del partner.
• Inference-time control: system instructions + screening de input/output + permisos de tools + gates humanos. Las instrucciones no son enforcement: necesitan controles en runtime.

"Claude no puede hacer cumplir una regla que nunca recibió."

4 capas:

⚠️ Watch out: como Claude rechazaba todo lo dañino en las pruebas, se asumió que también cumplía la política de no ver registros de otras unidades de negocio. Una petición normal pidió un registro prohibido y Claude respondió. La regla no existía en ninguna capa.

Checkpoint:

• Trained = armas peligrosas, contenido claramente de odio.
• Application layer = datos de otro tenant, consejos fuera del guion aprobado, aprobación antes de un reembolso.

2. Riesgos y guardrails

Categorías de riesgo recurrentes:

• Direct prompt injection: el usuario anula las instrucciones.
• Indirect prompt injection: instrucciones que llegan dentro del contenido recuperado o de los outputs de tools. Es el vector dominante en empresas.
• Token-budget exhaustion: inputs inflados que truncan el trabajo o disparan el costo.
• Tool/action abuse: inducir una tool con efectos secundarios fuera de la política.
• Data exposure: datos sensibles en el contexto o en los logs.

Evaluación de vulnerabilidades: recorre juntos el camino del request y el de los datos (input del usuario, contenido recuperado, outputs de tools, salida del modelo, logs) y pregunta qué control hay en cada punto. Entregable escrito: categoría, componente, probabilidad × impacto, mitigación, dueño y evidencia.

Checkpoint, soporte con KB + tool de reembolsos + log:

• Indirect injection vía KB → screening del contenido recuperado.
• Abuso de la tool de reembolso → autorización determinista antes de ejecutarla.
• Token exhaustion → chunking, límites y monitoreo.
• Exposición en el log → redacción del lado del servidor.

Los 3 puntos de control del camino

1. Input screening: antes de llamar al modelo.
2. Output screening: antes de responder al usuario.
3. Tool-call authorization: antes de cualquier acción con efectos secundarios.

Un control en un punto no cubre los otros.

• El control model-based se puede evadir y el determinista es frágil. Por eso se encadenan.
• Contenido recuperado y outputs de tools: aplícales el mismo clasificador antes de añadirlos al contexto.
• Refusals en la API:
  • stop_reason: "refusal" + stop_details (desde Opus 4.7) con categoría y explicación. Categorías: cyber, bio, frontier_llm, reasoning_extraction (verificar la lista vigente).
  • Enruta según la categoría y tolera que stop_details falte en modelos que no lo devuelven.
  • Tras un refusal, resetea el contexto (quita o reformula el turno, o limpia el historial).
• Fail open vs fail closed: decídelo tú. Si no, el código decide, y casi siempre deja pasar.
  • Un guardrail propio que deja pasar el tráfico al fallar es peor que uno que bloquea: aparenta protección sin darla.
  • Los controles de seguridad de Anthropic no son configurables y no fallan abiertos.
• Camino completo: request → input screening (fail closed) → modelo → output screening (fail closed) → authorization determinista antes de los efectos → respuesta. Se loguea cada gate que bloquea o falla.

Seguridad de la cadena de suministro de Skills

• Un Skill es código + instrucciones distribuibles. Puede traer un exploit que tus filtros de conversación no ven.
• Audita antes de confiar: llamadas anómalas (red, shell, archivos, credenciales) y operaciones fuera de alcance (un formateador que "llama a casa"). El propósito declarado es la línea base.
• Runtime: least privilege + sandbox (archivos y red limitados, sin credenciales permanentes). Un Skill limpio puede descargar código en runtime.
• Origen confiable: registro interno verificado, publishers verificados, releases firmados. No asumas que la plataforma los revisa por ti.
• Veredicto registrado: approve / reject / remediate (y re-auditar).

⚠️ Watch out: solo había un filtro de output. El modelo llamó issue_refund, el dinero se movió y después el filtro revisó el texto y lo aprobó. El output screening juzga texto, no acciones.

Checkpoint (grid): A, jailbreak/injection = model-based · input · B, blocklist = deterministic · input · C, toxicidad = model-based · output · D, autorización de reembolso = deterministic · action.

3. Fairness y transparencia

Los resultados desiguales entran por 4 puntos que controlas tú:

1. Corpus de retrieval (sobre o sub-representación).
2. Framing del prompt.
3. Ejemplos de few-shot.
4. Routing downstream.

Qué hay que explicar y a quién:

• Decision logging: la misma instrumentación de observabilidad apuntada a "¿por qué pasó esta decisión?". Cambian la retención y la vía de consulta.
• Checklist (ej. crédito): ¿cada punto de entrada está instrumentado? ¿Puedo explicar un rechazo? ¿Puedo demostrar trato comparable? ¿Puedo sacar la traza completa? Un "no" = brecha de diseño.
• Discernment aplicado a fairness: reconocer un resultado sesgado, no solo confirmar que se produjo un valor.
• Riesgo: la métrica global se ve bien mientras el daño se concentra en un subgrupo.
• El log de decisiones entra en el compliance register: minimización, retención y control de acceso (HIPAA/GDPR).

⚠️ Watch out: "la fairness es cosa del proveedor del modelo". El sesgo estaba en su corpus, y con tan poco logging no podían probarlo ni descartarlo.

Checkpoint (gaps):

• Gaps: routing sin log, contexto recuperado sin capturar, output guardado sin sus inputs, dashboard sin desglose por subgrupo.
• Adecuados: inputs/outputs/routing ligados a un session ID, log consultable por decisión con 90 días de retención.

4. Revisión humana por stakes, no por volumen

• Stakes = reversibilidad + costo del error. La confianza (útil solo si está calibrada) estima la probabilidad de error y regula cuánto volumen pasa sin revisión.
• Regla: a revisión humana lo que tiene baja confianza Y (es irreversible O de alto costo). Pasa directo lo confiable, reversible y barato.
• Si las variables chocan, pesan más el costo y la reversibilidad.

• El revisor necesita ver: inputs + output + razón del flag.
• Consent fatigue: aprobar todo sin leer. Anthropic recomienda menos aprobaciones paso a paso y revisión en checkpoints de alto valor (p. ej. aprobar el plan en Claude Code).
• Diligence (competencia 4D): checkpoints de responsabilidad humana explícitos y detectar cuándo la presión por automatizar erosiona la supervisión.
• En agentes: gate antes de toda acción irreversible o de alto riesgo y muestreo para lo de bajo riesgo.

⚠️ Watch out: 400 ítems al día, solo el output y un botón de aprobar → se aprueba todo. Fallan dos cosas independientes: el volumen (se arregla con routing por stakes) y la falta de contexto (se arregla con la vista del revisor). Arreglar solo una no basta.

Checkpoint: B. El control decisivo es la reversibilidad y el costo, no la confianza: un caso confiable pero irreversible o caro igual puede ir a un humano.

5. Compliance: obligación → control + dueño + evidencia

Las regulaciones fijan resultados, no implementaciones. Cada obligación se convierte en control técnico + dueño + evidence artifact. El artefacto de evidencia es lo que más se olvida.

• Uso para entrenamiento ≠ retención: que los datos no se usen para entrenar no significa que no se retengan (logging, abuso, legal, auditoría).
• Un revisor acepta pruebas de que el control está vivo, no un documento de diseño.
• El register se revalida periódicamente, porque las configuraciones derivan.

⚠️ Watch out: ruta correcta y mapeo hecho una vez en un documento, sin dueño ni evidencia. Meses después, un cambio de logging escribía metadatos en otra región y nadie lo notó hasta la auditoría. Una ruta compatible es un prerrequisito, no una prueba.

Checkpoint: A. BAA firmado + configuración habilitada = artefacto inspeccionable.

Ejercicio acumulativo (asistente de beneficios, FedRAMP)

1. Las reglas de elegibilidad van en la capa de aplicación (el entrenamiento no las conoce).
2. Input, output y authorization, cada uno con su tipo de check. Fail closed (un screening abierto deja pasar una denegación no revisada).
3. Nombrar los puntos de inyección (corpus, framing, ejemplos, routing) y un solo decision log que sirve al solicitante, al regulador, al equipo y al register.
4. Una denegación con baja confianza y difícil de revertir va a pre-action approval; la regla se basa en stakes.
5. Cada obligación FedRAMP → control + dueño + evidencia.

Para recordar

1. La seguridad es una pila de capas; el fallo peligroso es silencioso (suponer una regla que no vive en ninguna capa).
2. 3 puntos de control + dirección de fallo elegida (fail closed donde un error causa daño).
3. Fairness y transparencia se instrumentan; no vienen con el modelo.
4. Revisión por stakes (confianza, reversibilidad, costo) con inputs y razón del flag a la vista.
5. Una entry point compatible es el prerrequisito; controles con dueño y evidencia viva son la prueba.