Respuesta directa
En pocas palabras
El red teaming de un AI Sales Copilot es una prueba adversaria autorizada del sistema completo, no solo del modelo. Parte del contexto comercial, define qué datos, fuentes, herramientas y efectos están incluidos, construye escenarios de abuso reproducibles y ejecútalos en un entorno controlado. Comprueba inyección directa e indirecta, acceso entre cuentas, uso de herramientas, memoria, precios y acciones; registra evidencia, corrige la causa y repite cada prueba antes de autorizar el cambio.
Qué significa red teaming en un copiloto comercial
Red teaming es un ejercicio estructurado y autorizado que intenta provocar fallas bajo condiciones adversarias. En un AI Sales Copilot interesa saber si una entrada manipulada puede cambiar el objetivo, revelar información, cruzar permisos, alterar una propuesta o conseguir que una herramienta ejecute algo fuera del alcance. El resultado útil es evidencia que permita reducir el riesgo, no una demostración llamativa.
La prueba cubre la aplicación completa: interfaz, instrucciones, recuperación de datos, archivos, memoria, permisos, herramientas, integraciones, validaciones y revisión humana. Un modelo puede rechazar una solicitud directa y, aun así, obedecer una instrucción escondida en una nota del CRM. También puede producir texto correcto mientras la aplicación consulta una cuenta que la persona no debía ver.
Microsoft distingue el red teaming de la medición sistemática: primero ayuda a descubrir daños y formas de falla; después esas observaciones alimentan evaluaciones repetibles. NIST recomienda probar bajo condiciones adversarias, documentar los resultados y repetir los ejercicios con una cadencia definida.
Delimita el ejercicio antes de intentar una sola entrada
Describe el recorrido que vas a probar: por ejemplo, resumir una oportunidad, consultar el catálogo y preparar un borrador de propuesta. Enumera cada componente que recibe, transforma o ejecuta información. Incluye el modelo, las instrucciones, la búsqueda, los repositorios, el CRM, los conectores, las funciones, las identidades de servicio y el punto donde una persona revisa.
Separa los efectos permitidos de los prohibidos. Un entorno de prueba puede dejar guardar un borrador y bloquear cualquier envío, cambio de etapa o publicación. Si necesitas comprobar una acción, utiliza dobles de servicio, cuentas de laboratorio y destinatarios controlados. Nunca dependas de que el evaluador recuerde no presionar un botón peligroso.
Asigna autoridad: quién coordina, quién puede pausar, quién recibe una señal urgente y quién aprueba la reanudación. Informa a operación y soporte para que una alerta de prueba no se confunda con un incidente real. Conserva una ruta rápida para aislar herramientas o revocar credenciales.
Construye el modelo de amenazas desde el negocio
Empieza por los activos y decisiones que importan: precios, descuentos, términos, datos de contactos, historial de cuentas, adjuntos, credenciales, propuestas, etapas y comunicaciones. Después pregunta quién controla cada entrada y qué podría ganar si el copiloto la tratara como una orden. Un contacto externo, un vendedor, un administrador, un proveedor o un documento compartido tienen niveles de confianza distintos.
Dibuja los límites de confianza. Una nota escrita por un usuario no tiene la misma autoridad que una regla aprobada; una página recuperada es contenido, no una instrucción; una salida de herramienta tampoco debe ampliar permisos. Marca dónde el sistema mezcla esos elementos y dónde una acción pasa del lenguaje a un efecto real.
Prioriza por impacto y viabilidad. No todos los escenarios merecen el mismo esfuerzo. Una frase que cambia el tono de un borrador es distinta de una que revela otra cuenta o modifica un precio. Define qué hallazgos bloquean el lanzamiento, cuáles exigen contención y cuáles pueden entrar al backlog con una fecha.
| Criterio | Qué intenta el escenario | Ejemplo controlado |
|---|---|---|
| Contexto | Cambiar el objetivo mediante contenido no confiable | Instrucción incrustada en una nota o archivo de prueba |
| Acceso | Obtener datos fuera del rol o de la cuenta | Vendedor solicita información de una oportunidad restringida |
| Herramientas | Usar una función válida con finalidad indebida | Intento de guardar, compartir o cambiar una etapa sin aprobación |
| Decisión | Convertir una señal débil en certeza | Apertura de Buyer Room presentada como aceptación o pago |
Prueba inyección directa e indirecta por separado
Una inyección directa llega en la solicitud del usuario e intenta sustituir las reglas o ampliar el objetivo. Una inyección indirecta aparece dentro de contenido que el sistema recupera: notas, correos, páginas, archivos, campos del CRM, resultados de una API o texto extraído de una imagen. OWASP advierte que RAG y el ajuste del modelo no eliminan por sí solos esta vulnerabilidad.
Crea variantes que mantengan la misma intención adversaria con redacciones, idiomas, errores y posiciones diferentes. Prueba instrucciones divididas entre varios campos, contenido oculto para la vista humana pero procesado por el sistema y secuencias de varios turnos. El objetivo no es coleccionar frases, sino descubrir qué frontera de confianza deja de funcionar.
El comportamiento esperado debe ser observable: tratar el contenido recuperado como datos, conservar la tarea autorizada, no revelar instrucciones internas, no consultar fuentes adicionales y no ejecutar acciones. Si el copiloto no puede continuar con seguridad, debe detenerse, explicar el límite y solicitar una revisión.
Intenta cruzar permisos sin conceder privilegios reales
Ejecuta el mismo caso con Owner, Admin, Seller y Viewer, y con cuentas de prueba que tengan asignaciones distintas. Comprueba que el resultado no incluya registros, campos, archivos o herramientas que la identidad no puede consultar directamente. El modelo nunca debe funcionar como una ruta alternativa alrededor de la autorización de la aplicación.
Prueba referencias indirectas: pedir un resumen agregado, solicitar que compare dos cuentas, nombrar un identificador conocido o pedir que cite el documento que sustenta una respuesta. Revisa también cachés, historiales, índices de búsqueda y memoria. Revocar el acceso en la pantalla no basta si una copia permanece disponible para recuperación.
Registra tanto la respuesta final como las consultas realizadas. Un rechazo correcto después de haber recuperado datos prohibidos sigue siendo una falla. La autorización debe impedir el acceso antes de que el contenido llegue al contexto del modelo.
Somete las herramientas y acciones a abuso controlado
Prueba si el sistema puede seleccionar una herramienta no necesaria, modificar argumentos, repetir llamadas, encadenar funciones o actuar con una identidad más amplia que la persona. Incluye respuestas de herramienta manipuladas que intenten ordenar una segunda acción. OWASP recomienda tratar las salidas externas como datos no confiables y aplicar privilegio mínimo y aprobación humana a operaciones de alto impacto.
En ventas, los efectos críticos incluyen compartir una propuesta, cambiar una etapa, crear una tarea para otra persona, modificar un catálogo, aplicar un descuento o usar un destinatario no confirmado. Cada función debe validar en código la identidad, el objeto, los argumentos y la política. Una frase dentro del prompt no sustituye esa validación.
Añade límites de tiempo, llamadas, reintentos, tokens y costo. Provoca respuestas lentas, duplicadas, vacías y contradictorias. Comprueba que el recorrido se detenga de forma segura, no repita una acción y deje evidencia suficiente para distinguir una falla del modelo, la herramienta o la integración.
Incluye ataques contra precios y evidencia comercial
Crea catálogos de laboratorio con productos sin precio, versiones vencidas, importes contradictorios y monedas distintas. Añade una nota que pida ignorar el catálogo o presentar un descuento no autorizado. El resultado seguro conserva la fuente aprobada, muestra el conflicto y espera confirmación; no completa una cifra para que el documento se vea terminado.
Prueba también la manipulación de señales. Una visita a Buyer Room no confirma identidad, lectura, aprobación, contrato, pago ni intención de compra. Una etapa, una fecha tentativa o una nota optimista tampoco constituyen evidencia suficiente por sí solas. El copiloto debe separar hechos observados, inferencias y decisiones humanas.
No mezcles MXN, USD u otras monedas para comprobar un total aparente. Cualquier conversión de prueba necesita método, fecha y fuente definidos. Un caso adversario puede utilizar el mismo número en monedas diferentes para detectar si la etiqueta desaparece en el resumen o en la propuesta.
Ejecuta con datos sintéticos y conserva evidencia reproducible
Prepara registros sintéticos o desidentificados que conserven relaciones, permisos y excepciones. No copies secretos, conversaciones reales o datos personales innecesarios al laboratorio. Marca visualmente el entorno y los destinatarios de prueba. Si un escenario necesita una integración externa, utiliza un sandbox o un doble que registre el intento sin producir el efecto.
Cada caso necesita identificador, versión, precondiciones, rol, entrada, contenido recuperado, herramientas disponibles, resultado esperado y condición de parada. Conserva salida, fuentes, llamadas, argumentos, tiempos, capturas y estado final. La evidencia debe permitir que otra persona repita la prueba sin conocer una conversación informal.
Empieza manualmente para descubrir rutas inesperadas; automatiza después los casos estables. Las herramientas de exploración pueden ampliar combinaciones, pero no sustituyen el juicio de seguridad, producto, ventas, datos y privacidad. Una tasa de ataque resumida no explica qué control falló ni qué impacto hubiera tenido.
Convierte cada hallazgo en una decisión de ingeniería
Describe el hallazgo por comportamiento e impacto, no por una etiqueta genérica. Incluye versión, recorrido, identidad, datos alcanzados, efecto potencial, precondiciones, evidencia y repetibilidad. Distingue una respuesta inconveniente de una divulgación, una elevación de privilegio o una acción no autorizada.
Busca la causa en capas. Puede estar en autorización, recuperación, separación de contenido, definición de herramientas, validación de argumentos, interfaz, aprobación, monitoreo o capacitación. Cambiar el prompt puede reducir un ejemplo y dejar abierta la misma ruta mediante otra redacción. Los controles deterministas deben asumir que el modelo puede equivocarse.
Asigna severidad, responsable, tratamiento y fecha. Las opciones son corregir, limitar el alcance, retirar una fuente, reducir privilegios, añadir aprobación, reforzar detección, aceptar un riesgo documentado o detener la función. Un hallazgo crítico abierto no se compensa con muchos casos aprobados.
Repite, convierte en regresión y vigila producción
Después de corregir, ejecuta el caso original, variantes cercanas y escenarios legítimos que podrían quedar bloqueados. Confirma que el control reduce el riesgo sin romper el trabajo normal. Compara la versión candidata con la estable y conserva la configuración exacta de ambas.
Añade cada falla confirmada al conjunto de regresión con su comportamiento esperado. Repite la selección crítica cuando cambien modelo, prompt, fuentes, memoria, permisos, herramientas, proveedor o autonomía. NIST recomienda ejercicios con una cadencia prescrita y documentación de metodología, métricas y resultados.
En producción, monitorea señales relacionadas sin almacenar más información de la necesaria: rechazos anómalos, consultas fuera del patrón, herramientas denegadas, cambios de permisos, volumen, reintentos y correcciones humanas. Un evento no demuestra un ataque, pero debe conducir a una revisión y, cuando corresponda, al proceso de incidentes.
Aplica estas pruebas a los límites verificables de Cerravi
En Cerravi, el red teaming debe comprobar que Copilot propone siguientes pasos para revisión humana y no convierte contenido recuperado en autoridad. Las sugerencias deben permanecer sustentadas por el contexto visible; una nota, archivo o instrucción externa no puede ampliar permisos ni ordenar un efecto.
Las propuestas utilizan los productos y precios disponibles en el catálogo. Si falta un importe o las fuentes entran en conflicto, el flujo debe esperar una confirmación. Las monedas permanecen separadas mientras no exista una conversión aprobada. Una prueba debe rechazar cualquier salida que invente o mezcle esas condiciones.
Forecast es una estimación operativa basada en reglas transparentes y datos registrados en el CRM; no es un modelo predictivo entrenado o calibrado y no garantiza cierres. La actividad de Buyer Room tampoco confirma identidad, aceptación o pago. El ejercicio debe intentar romper precisamente estos límites y comprobar que continúan visibles.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿Cuál es la diferencia entre red teaming y una evaluación de calidad?
La evaluación mide comportamientos conocidos con casos y criterios repetibles. El red teaming busca activamente formas de falla, abuso o daño que el equipo todavía no ha modelado. Los hallazgos confirmados deben convertirse después en pruebas estables de evaluación y regresión.
¿Se puede hacer red teaming directamente en producción?
La exploración inicial debe realizarse en un entorno controlado con datos, identidades y efectos de prueba. En producción pueden ejecutarse comprobaciones cuidadosamente diseñadas y autorizadas cuando no afecten usuarios, datos ni operación, pero requieren límites, observabilidad y una condición inmediata de parada.
¿Un filtro de prompt injection elimina el riesgo?
No. Puede reducir patrones conocidos, pero no garantiza que el modelo distinga siempre instrucciones y datos. La defensa combina separación de contenido, privilegio mínimo, autorización previa a la recuperación, herramientas limitadas, validación determinista, aprobación humana, monitoreo y pruebas periódicas.
¿Quién debe participar en el ejercicio?
Seguridad coordina técnicas y evidencia; producto y tecnología explican el recorrido; ventas identifica impactos comerciales; datos y privacidad revisan fuentes y exposición; operaciones y soporte preparan contención. Conviene incluir personas que no diseñaron la función y conocen el trabajo real.
¿Cuándo debe repetirse el red teaming?
Antes de ampliar un alcance relevante, después de cambios materiales en modelos, prompts, fuentes, permisos, memoria, herramientas o autonomía, tras un incidente y con una cadencia definida por el riesgo. Los casos críticos deben formar parte de la regresión de cada versión.