Un equipo de gestión de riesgos recibe un nuevo chatbot de asistencia para afiliados de servicios de salud dos días antes de su lanzamiento. En una prueba realizada a última hora, el bot ofrece a un afiliado instrucciones paso a paso sobre la dosis de un medicamento recetado, a pesar de que los requisitos del producto estipulan que debe rechazar cualquier consejo médico y derivar al afiliado a una línea de atención de enfermería. Nadie puede responder a la primera pregunta necesaria para evaluar el riesgo: en qué punto del sistema se podría haber prevenido, detectado o contenido este comportamiento.
El resto de esta lección desarrolla un modelo de amenazas para resultados perjudiciales recorriendo la cadena del incidente de principio a fin y transformando dicha cadena en puntos de control concretos que se pueden medir y gestionar.
En este curso, un modelo de amenazas se define como una descripción estructurada de cómo puede producirse un daño específico en su aplicación de LLM, qué componentes intervienen, qué condiciones deben cumplirse y qué evidencias se pueden recopilar para confirmar o refutar dicha trayectoria. En el caso de resultados perjudiciales, esto implica tratar el resultado como el estado de fallo y realizar un seguimiento inverso a través de las etapas de prompt (instrucción), recuperación, generación, moderación y entrega, hasta identificar los puntos de la cadena donde es posible ejercer control.
Simulación: extracto de la narrativa del incidente:
Un afiliado pregunta al chatbot si puede duplicar la dosis para compensar un día en que olvidó tomarla. El chatbot recupera información de preguntas frecuentes generales sobre medicamentos y un fragmento de un foro comunitario que contiene conversaciones informales sobre dosis. El modelo responde ofreciendo pautas condicionales de dosificación y una advertencia; la interfaz de usuario muestra la respuesta sin filtros adicionales. No se activa ningún mensaje de rechazo ni se realiza una revisión humana.
El paso clave consiste en desglosar el fallo en eventos observables del sistema. Se recibe una solicitud del usuario, la fase de recuperación devuelve una mezcla de contexto aceptable y no seguro, el modelo genera consejos sobre medicación regulada, la etapa de moderación no bloquea ni deriva la respuesta, y el canal de entrega la presenta como contenido de ayuda habitual. Buscamos un modelo de amenazas porque cada etapa del proceso implica telemetría y límites de control diferentes.
Podemos materializar esta cadena en el diagrama del sistema. Al revisarlo, céntrese en qué componente transformó un riesgo latente en una respuesta efectivamente entregada. Ahora, identifique los puntos de fallo en la arquitectura:
Un punto de control es un lugar en la ruta desde la solicitud hasta la respuesta donde se puede aplicar una decisión de seguridad o protección utilizando una entrada, una política y una acción de cumplimiento. Para las salidas perjudiciales, resulta útil agrupar los puntos de control en fases de pregeneración, durante la generación y posgeneración, ya que cada grupo ofrece garantías distintas y conlleva diferentes costos asociados a los falsos positivos.
Los controles de pregeneración moldean lo que el modelo percibe. Incluyen el filtrado de las entradas del usuario, restricciones de recuperación de información y plantillas de prompts. Pueden reducir la probabilidad de obtener salidas perjudiciales, pero no garantizan la seguridad, ya que entradas aparentemente seguras pueden generar respuestas inseguras, y la recuperación de información aún puede exponer textos limítrofes que resultan peligrosos según el contexto.
Los controles durante la generación determinan qué se le permite producir al modelo. Aquí es donde se emplean instrucciones del sistema, políticas de herramientas para agentes y funciones de seguridad propias del modelo (cuando están disponibles). Pueden acotar los comportamientos, pero dependen de que el modelo siga las instrucciones ante entradas adversarias o ambiguas, además de ser difíciles de verificar sin pruebas sistemáticas.
Los controles de posgeneración deciden qué se entrega y qué se redirige. Esto abarca clasificadores de moderación de salidas, listas de permitidos y denegados para temas de alto riesgo, y colas de revisión humana. A menudo representan el único punto donde se puede garantizar que el texto prohibido no llegue al usuario; sin embargo, pueden añadir latencia, generar una experiencia de usuario inconsistente y requerir un registro riguroso para demostrar su eficacia cuando se necesiten pruebas.
Las garantías requieren mecanismos de cumplimientoUna declaración de política no constituye un control por sí misma. Un punto de control solo existe cuando hay una decisión ejecutable y un registro de auditoría que se pueda revisar.
Un error común es pensar que el riesgo de salidas perjudiciales es únicamente un problema de calidad del modelo. En la práctica, el modelo es solo un componente dentro de un sistema distribuido. Un mismo modelo base puede resultar aceptable en un flujo de trabajo de triaje telefónico de enfermería con un enrutamiento estricto en la posgeneración, pero inaceptable en una interfaz de chat de autoservicio sin filtros de acceso, ya que la ruta de entrega modifica tanto el impacto como la capacidad de detección.
Para hacer operativos los puntos de control, incorporamos evidencias. En cada punto, debemos ser capaces de responder qué señal se registra, dónde se almacena y cómo se revisa. Analicemos los puntos de intervención y los registros que cabría esperar: