Respuesta directa
En pocas palabras
Un modelo de amenazas de AI Sales Copilot describe el sistema que realmente opera, sus activos, personas, componentes, flujos de datos, identidades, herramientas y límites de confianza. Después formula escenarios como causa, acción y efecto; prioriza según impacto y exposición; asigna controles verificables; y conserva supuestos, responsables y cambios. No demuestra seguridad por sí solo: orienta diseño, pruebas, monitoreo y respuesta.
El modelo de amenazas convierte una arquitectura en preguntas comprobables
El objetivo no es elaborar una lista genérica de ataques. Es comprender cómo un sistema concreto puede perder confidencialidad, integridad, disponibilidad, control humano o trazabilidad dentro de su contexto comercial. El resultado debe ayudar a decidir qué cambiar, qué probar, qué observar y quién puede aceptar lo que permanece abierto.
NIST sitúa el contexto, los límites, las personas, las tareas y todos los componentes del sistema dentro de la función Map del AI RMF. Microsoft explica que las amenazas específicas de AI y machine learning complementan, no reemplazan, la seguridad tradicional. Esta guía traduce esos principios a un flujo operativo; no atribuye a esas fuentes una plantilla obligatoria ni afirma que completarla certifica el sistema.
Realiza el ejercicio antes de una PoC con datos reales, antes de producción, cuando amplías permisos o autonomía y después de cambios materiales. También sirve para revisar un sistema existente cuyo diseño creció por partes. Un diagrama perfecto no es requisito: empieza con lo que conoces, marca supuestos y abre responsables para cerrar los vacíos.
Fija versión, recorrido, usuarios y autoridad dentro del alcance
Nombra el caso de uso y la decisión o tarea que recibe asistencia. Especifica versión de aplicación, modelos, prompts, fuentes, herramientas, entorno, grupo de usuarios y sistemas conectados. Una frase como copiloto de ventas es insuficiente: redactar un borrador interno y enviar un mensaje externo presentan superficies y efectos distintos.
Dibuja el inicio y el final del recorrido. Puede comenzar cuando una persona abre una oportunidad y terminar cuando revisa una sugerencia. Si después existe un envío, una actualización del CRM o una llamada a otra herramienta, aclara si forma parte del sistema o queda en otro límite. Documenta también procesos manuales y fallback.
Registra lo que queda fuera: entrenamiento del proveedor, infraestructura no administrada, canales no conectados, otras regiones o funciones todavía no habilitadas. Fuera de alcance no significa sin riesgo. Asigna quién evaluará esa dependencia y qué afirmaciones todavía no han sido verificadas.
Empieza por activos e impactos que importan al negocio
Identifica qué debe protegerse y por qué. En ventas B2B suele incluir precios, descuentos, moneda, contactos, notas, propuestas, archivos, credenciales, contratos, historial, reputación, continuidad del seguimiento y capacidad de demostrar quién autorizó una acción. Incluye personas y organizaciones que podrían verse afectadas, no solo bases de datos.
Describe el impacto con un resultado observable: exposición entre organizaciones, propuesta con precio no confirmado, modificación de una etapa sin autorización, mensaje enviado a la persona equivocada, indisponibilidad durante una negociación o decisión basada en contexto desactualizado. Error, fuga o alucinación son etiquetas demasiado amplias para diseñar un control.
Asigna dueño y criterio de severidad. Impacto financiero, contractual, de privacidad, seguridad, operación y confianza pueden requerir responsables distintos. No conviertas una escala ordinal en una pérdida cuantificada si no existe evidencia. La clasificación organiza atención; no fabrica certeza.
Traza datos e instrucciones desde la entrada hasta el efecto
Representa las entradas humanas, datos recuperados, contexto del CRM, archivos, memoria, reglas, prompt de sistema y respuesta del modelo. Sigue la salida hasta la interfaz, el almacenamiento, la propuesta, el correo, la métrica o la herramienta que pueda consumirla. Marca transformaciones, filtros, cachés y decisiones de aprobación.
Distingue datos de instrucciones. Una nota, página o documento externo puede contener texto que intente dirigir al modelo. El hecho de recuperar ese contenido no le concede autoridad. Señala dónde se delimita, etiqueta, reduce o valida el material y qué componente decide si una instrucción es confiable.
Añade registros, feedback y telemetría. Estos flujos también pueden contener información sensible, ser manipulados o quedar disponibles durante más tiempo del necesario. Para cada flecha registra fuente, destino, identidad, protocolo, finalidad, clasificación, retención y comportamiento cuando el dato falta o entra en conflicto.
Marca límites de confianza e identidades efectivas
Un límite aparece cuando cambian propietario, organización, identidad, política, entorno o nivel de confianza. Márcalo entre navegador y servicio, aplicación y proveedor de modelo, CRM y conector, recuperación y fuente externa, organización y Buyer Room, producción y administración. No asumas que una red interna o una integración aprobada vuelve confiable todo su contenido.
Registra quién llama a quién y con qué credencial. Separa persona, cuenta de servicio, token, clave, webhook y rol administrativo. Anota alcance de lectura, escritura, envío y ejecución. La autorización debe comprobarse en el punto donde se realiza la acción, no deducirse de una frase generada por el modelo.
Busca autoridad acumulada. Un componente puede leer el CRM, otro acceder a archivos y otro enviar mensajes; unidos, crean un efecto que ninguno parecía tener por separado. Microsoft señala que las interacciones entre agentes, herramientas, servicios y fuentes amplían la superficie. El diagrama debe mostrar esa composición.
Modela actores por capacidad, no por una caricatura de atacante
Incluye usuario autorizado que se equivoca, persona interna que abusa de acceso, tercero que controla contenido recuperado, cuenta comprometida, proveedor o componente que cambia, proceso automatizado mal configurado y una persona externa que recibe una salida. También considera fallas no maliciosas: datos obsoletos, permisos heredados, indisponibilidad y colisiones de versión.
Para cada actor pregunta qué puede observar, introducir, modificar, repetir, ocultar o activar. Registra conocimiento y acceso necesarios sin inventar una biografía. Un cliente no necesita controlar el modelo para insertar contenido en un documento que después se recupera. Un usuario legítimo puede provocar daño con una acción permitida pero fuera de contexto.
Separa intención de capacidad. El control debe resistir una ruta plausible aunque no puedas estimar cuántas personas intentarían utilizarla. Si la capacidad depende de una condición desconocida, conserva el supuesto y diseña una prueba antes de asignar una exposición alta o baja.
Escribe escenarios como condición, acción, activo y consecuencia
Utiliza una frase reproducible: dado un actor o condición, mediante una entrada o frontera, el sistema realiza o permite un comportamiento, lo que afecta un activo y produce una consecuencia. Por ejemplo: un archivo externo contiene instrucciones; el recuperador las incorpora sin delimitación; el copiloto solicita una herramienta fuera del propósito; y una persona recibe una propuesta con datos no autorizados.
Cubre confidencialidad, integridad, disponibilidad, identidad, autorización, procedencia, privacidad, seguridad del contenido y supervisión humana. Para sistemas generativos añade inyección directa e indirecta, recuperación indebida, salida insegura, dependencia de proveedor, uso excesivo de herramientas, memoria contaminada y confianza injustificada en una respuesta.
Evita copiar una lista de riesgos sin conectarla al diseño. Dos sistemas con el mismo modelo pueden necesitar escenarios diferentes por sus datos, herramientas y efectos. Mantén un identificador por escenario y relaciónalo con activos, componentes, controles, pruebas, hallazgos e incidentes.
| Criterio | Problema | Redacción útil |
|---|---|---|
| Fuga de datos | No indica ruta ni alcance | Un enlace público permite recuperar un archivo de otra organización y mostrar un fragmento |
| Prompt injection | Nombra una técnica | Una nota externa intenta ampliar la autoridad y activa una herramienta sin aprobación |
| Precio incorrecto | No separa causa y efecto | Un dato faltante se sustituye por una cifra no confirmada y llega a la propuesta |
| Sistema caído | No define continuidad | El proveedor no responde, bloquea el seguimiento y el equipo no puede usar el fallback |
Prioriza con impacto, exposición y fuerza de la evidencia
Evalúa impacto potencial, alcance, accesibilidad, frecuencia, condiciones necesarias, reversibilidad y capacidad de propagación. Distingue el riesgo inherente, antes de controles específicos, del residual después de considerar controles realmente implementados. Si la posibilidad es desconocida, utiliza esa palabra y abre la evidencia necesaria.
Una puntuación ayuda a ordenar si sus criterios son consistentes, pero no convierte incertidumbre en probabilidad. Revisa por separado escenarios de impacto extremo aunque parezcan menos frecuentes. Los casos con acción externa, datos sensibles, acceso entre organizaciones o poca recuperación merecen atención explícita.
Documenta quién priorizó, qué versión observó y qué supuestos utilizó. Una evaluación puede perder vigencia si cambian el modelo, la fuente, el permiso, la herramienta, el grupo de usuarios o el proveedor. La prioridad debe activar decisiones concretas: evitar, reducir, transferir, aceptar con condiciones o retirar.
Asigna controles a la ruta, no a la etiqueta del riesgo
Coloca controles donde interrumpan el escenario. Reduce entradas con fuentes autorizadas y delimitación. Limita acceso con identidad y privilegio mínimo. Restringe herramientas con allowlists, parámetros y autorización determinista. Valida salidas antes de efectos. Conserva revisión humana para decisiones materiales y prepara pausa, reversión y fallback.
Combina prevención, detección, corrección y recuperación. Un prompt que pide prudencia no sustituye un permiso. Un filtro de palabras no contiene todas las variantes. La aprobación humana tampoco sirve si la persona no ve fuente, cambio y consecuencia. Define qué información necesita para revisar y qué acción nunca puede ejecutarse silenciosamente.
Para cada control registra dueño, componente, configuración, cobertura, dependencia, estado, frecuencia y evidencia. Señala controles compartidos: si varios escenarios dependen del mismo proveedor de identidad o validador, una falla común cambia el riesgo de todos ellos.
Convierte escenarios en pruebas y resultados reproducibles
Transforma cada escenario prioritario en pruebas de arquitectura, configuración, permisos, evaluación y red teaming autorizado. Registra precondiciones, versión, rol, datos de prueba, pasos, resultado esperado, resultado observado y evidencia. Utiliza datos sintéticos o protegidos y evita afectar personas, clientes o producción.
Prueba controles positivos y negativos. Confirma que una acción permitida funciona bajo su alcance y que la misma acción se rechaza para otra organización, rol, recurso o condición. Incluye conflicto de fuentes, dato faltante, contenido adversario, proveedor no disponible, token revocado y respuesta fuera de formato.
Un hallazgo observado no reemplaza el escenario, y un escenario sin prueba no es un defecto confirmado. Relaciónalos. Después de corregir, repite el caso original, variantes cercanas y recorridos legítimos que podrían haberse roto. Conserva los casos críticos como regresión de cada cambio material.
Mantén el modelo vivo con cambios, señales e incidentes
Asigna fecha, responsables y disparadores de revisión. Cambios de modelo, prompt, recuperación, memoria, fuente, integración, permiso, herramienta, proveedor, autonomía, usuarios y entorno deben revisar el diagrama y los escenarios relacionados. Una actualización de documentación sin cambio técnico también puede cerrar un supuesto importante.
Conecta señales de producción con escenarios: denegaciones, reintentos, acceso inusual, herramienta bloqueada, corrección humana, fuente desconocida, latencia, error de proveedor o salida descartada. Una señal no demuestra ataque ni impacto, pero ayuda a decidir si investigar, limitar, pausar o iniciar respuesta a incidentes.
Versiona el modelo de amenazas y conserva decisiones. Cierra un escenario cuando la ruta deja de existir o el riesgo se acepta con autoridad y condiciones; no porque dejó de aparecer en una reunión. Revisa dependencias compartidas y riesgos nuevos revelados por feedback, pruebas, proveedores e incidentes.
Modela Cerravi con capacidades y límites verificables
En Cerravi, Copilot organiza contexto y propone siguientes pasos para revisión humana; no envía mensajes ni cambia etapas automáticamente. El modelo de amenazas debe preservar esa frontera: contenido recuperado o una respuesta generada no pueden ampliar permisos ni convertirse por sí solos en una acción externa.
Las propuestas utilizan productos y precios disponibles en el catálogo. Un importe faltante exige confirmación y las monedas permanecen separadas salvo una conversión aprobada. Prueba que una nota, archivo o prompt no pueda inventar, mezclar o sustituir esas condiciones. La actividad de Buyer Room aporta señales, pero no confirma identidad, aceptación, contrato, pago o intención.
Forecast utiliza reglas transparentes y datos registrados en el CRM; no es un modelo predictivo entrenado o calibrado y no garantiza cierres. La empresa sigue siendo responsable de configurar usuarios, datos, permisos, integraciones, controles y respuesta. No atribuyas al producto regiones, certificaciones, retención, proveedores o condiciones contractuales que no estén confirmadas.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿Cuál es la diferencia entre modelo de amenazas y registro de riesgos?
El modelo de amenazas explica activos, arquitectura, flujos, límites, actores y rutas de abuso o falla. El registro de riesgos asigna dueño, impacto, exposición, controles, evidencia, respuesta y riesgo residual. Se relacionan, pero uno describe cómo puede ocurrir y el otro gobierna la decisión resultante.
¿Cuál es la diferencia entre threat modeling y red teaming?
Threat modeling anticipa escenarios a partir del diseño y el contexto. Red teaming intenta encontrar y demostrar rutas adversarias dentro de un alcance autorizado. El modelo orienta las pruebas; los hallazgos del ejercicio actualizan el modelo y se convierten en regresiones.
¿Se necesita conocer la arquitectura completa para empezar?
No. Empieza con el recorrido conocido, marca componentes, flujos y dependencias pendientes, asigna responsables y evita presentar supuestos como hechos. Los vacíos importantes son resultados del ejercicio y deben conducir a descubrimiento, pruebas o límites temporales.
¿Quién debe participar en el ejercicio?
Producto, tecnología, seguridad, datos y la persona responsable del proceso comercial. Según el alcance, también privacidad, legal, compras, soporte y usuarios reales. La diversidad ayuda a detectar impactos y supuestos que un equipo exclusivamente técnico puede pasar por alto.
¿Cuándo debe actualizarse el modelo de amenazas?
Antes de producción, al ampliar alcance o autonomía, después de cambios materiales en modelos, prompts, fuentes, memoria, permisos, herramientas, proveedores o usuarios, tras hallazgos e incidentes y con una cadencia proporcional al riesgo.