Gobernanza de IA

OWASP Top 10 para un AI Sales Copilot B2B: guía de auditoría

Un recorrido de extremo a extremo para delimitar el sistema, probar los diez riesgos, reunir evidencia y priorizar correcciones sin confundir una taxonomía con una certificación.

Respuesta directa

En pocas palabras

Para auditar OWASP Top 10 en un AI Sales Copilot, delimita primero usuarios, datos, modelos, RAG, memoria, herramientas, salidas y proveedores; después traduce cada categoría LLM01–LLM10 a escenarios comerciales reproducibles, con precondición, acción, resultado esperado y evidencia. Prueba tanto el bloqueo como el uso legítimo, registra severidad según impacto y alcance reales, corrige la causa técnica y repite la prueba antes de cerrar. OWASP sirve para organizar riesgos conocidos: no es una certificación, no garantiza cobertura completa y no sustituye un modelo de amenazas, requisitos legales ni controles específicos del negocio.

Usa OWASP como mapa de riesgos, no como sello de seguridad

OWASP Top 10 for Large Language Model Applications reúne categorías frecuentes de riesgo en aplicaciones que usan modelos de lenguaje. Ayuda a compartir vocabulario y a no olvidar rutas conocidas, pero no convierte diez casillas marcadas en una garantía. Un sistema puede superar los ejemplos publicados y seguir expuesto por una integración propia, una mala autorización, una regla comercial incorrecta o un cambio posterior al ensayo.

En un AI Sales Copilot, la unidad de análisis no es solamente el modelo. Incluye identidad, CRM, archivos, correo, RAG, embeddings, memoria, prompts, orquestador, herramientas, colas, renderers, exports, Buyer Rooms, proveedores y revisión humana. Declara versión de cada componente y fecha del ejercicio. Si el alcance cambia, la conclusión deja de describir el sistema actual aunque el reporte siga siendo reciente.

Dibuja el recorrido comercial antes de diseñar ataques

Empieza con una transacción concreta: un vendedor pide preparar una propuesta, resumir una llamada, consultar una cuenta o redactar seguimiento. Sigue el dato desde la sesión hasta la salida final. Registra qué recupera el sistema, qué transforma, qué envía al proveedor, qué herramientas puede invocar, dónde conserva memoria, quién revisa y qué canal recibe el resultado. Añade fronteras de tenant, ambientes, regiones y organizaciones externas.

Separa contenido confiable de contenido no confiable. Un correo del comprador, un PDF, una página web, un campo libre del CRM y un resultado de búsqueda pueden contener instrucciones hostiles aunque provengan de una fuente autorizada. Distingue también decisión y ejecución: proponer un correo no equivale a enviarlo; sugerir una etapa no equivale a cambiarla; calcular un total no autoriza un precio inexistente.

Convierte cada riesgo en una prueba reproducible

Cada caso necesita objetivo, activo, actor, precondición, entrada, secuencia, resultado esperado, evidencia y criterio de aprobación. Usa datos sintéticos o canarios para no convertir la auditoría en una fuga real. Conserva IDs, versiones, decisiones de política y hashes; evita copiar secretos o datos personales completos al reporte. Una captura aislada rara vez permite repetir el resultado.

Incluye un control positivo. Si un usuario autorizado no puede realizar la tarea normal, el sistema puede estar bloqueando demasiado y el equipo terminará buscando atajos. Incluye también variantes: otro idioma, conversación larga, contenido indirecto, archivo, caché, concurrencia, cambio de destinatario y reintento. La cobertura se expresa como escenarios ejecutados y fronteras observadas, no como número de prompts lanzados.

Estructura de un caso que produce evidencia útil
CriterioDebe indicarNo basta con
AlcanceFunción, actor, dato, versión y destinoNombre general del producto
EjecuciónPasos, entrada y precondicionesUna captura sin contexto
ResultadoEsperado, observado y criterioDecir que se ve seguro
EvidenciaIDs, políticas, logs mínimos y fechaCopiar todo el contenido sensible

LLM01 y LLM02: corta la ruta entre instrucción hostil y dato sensible

Para LLM01 Prompt Injection, coloca instrucciones directas e indirectas en chat, correo, documentos, sitios, resultados de retrieval y memoria. Intenta cambiar el objetivo, extraer contexto, alterar herramientas o convencer al sistema de ignorar una aprobación. El resultado seguro conserva la intención autorizada, trata el contenido recuperado como datos y exige controles externos al prompt para cualquier consecuencia.

Para LLM02 Sensitive Information Disclosure, usa canarios por tenant y clase de dato. Prueba búsqueda, resumen, inferencia, caché, error, log, exportación y cambio de destinatario. La defensa empieza antes del modelo: minimización, autorización previa al retrieval, aislamiento, secretos fuera del contexto y política de salida. Revisa las guías detalladas de prompt injection y divulgación para construir la suite completa.

  • LLM01: /guias/como-prevenir-prompt-injection-instrucciones-indirectas-agentes-ia-b2b
  • LLM02: /guias/como-prevenir-divulgacion-informacion-sensible-ai-sales-copilot-b2b
  • Evidencia clave: objetivo autorizado, filtros aplicados, tool calls negados y canarios ausentes de destinos prohibidos.

LLM03 y LLM04: verifica procedencia antes de confiar en artefactos o datos

LLM03 Supply Chain exige inventariar modelos, adaptadores, datasets, paquetes, imágenes, builders, APIs y servicios mutables. Verifica procedencia, digest, firma cuando exista, licencia, evaluación, admisión y capacidad de sustitución. Un nombre de versión no demuestra que el proveedor mantuvo el mismo comportamiento. Simula una dependencia retirada, una respuesta externa alterada y un rollback.

LLM04 Data and Model Poisoning busca degradación, backdoors o sesgo introducido por fuentes, feedback, entrenamiento, fine-tuning, índices o actualizaciones. Inserta triggers sintéticos, separa holdouts del pipeline de construcción y compara comportamiento por segmentos. La limpieza superficial no sustituye cuarentena, lineage y criterios de promoción. Documenta qué datos pueden influir en producción y quién los admite.

  • LLM03: /guias/como-proteger-cadena-suministro-ai-sales-copilot-b2b
  • LLM04: /guias/como-prevenir-envenenamiento-datos-modelos-ai-sales-copilot-b2b
  • Evidencia clave: inventario por release, procedencia verificable, evaluación independiente, canary y rollback ensayado.

LLM05 y LLM06: separa texto generado, autoridad y ejecución

LLM05 Improper Output Handling aparece cuando una salida se interpreta como HTML, SQL, comando, ruta, plantilla, parámetro o autorización sin validación adecuada. Prueba payloads en propuestas, correos, nombres de archivo, documentos y tool arguments. Exige esquema, validación semántica, codificación para el destino y autorización antes de mostrar, guardar o ejecutar. El resultado del modelo sigue siendo no confiable aunque el prompt sea interno.

LLM06 Excessive Agency evalúa cuánto daño puede causar una decisión equivocada. Intenta cambiar etapa, destinatario, precio, permiso, archivo o mensaje fuera de la tarea. Limita herramientas, parámetros, alcance temporal, tenant, volumen y presupuesto; usa credenciales por capacidad y aprobación para consecuencias relevantes. Prueba revocación, expiración, idempotencia y kill switch, no solo el camino feliz.

  • LLM05: /guias/como-validar-salidas-modelos-ia-antes-ejecutarlas-b2b
  • LLM06: /guias/como-limitar-herramientas-permisos-acciones-agentes-ia-b2b
  • Evidencia clave: contratos de salida, parámetros rechazados, aprobación vinculada al artefacto y acción detenida sin efecto parcial.

LLM07 y LLM08: reduce autoridad oculta y protege la capa de retrieval

LLM07 System Prompt Leakage no se resuelve tratando el prompt como una contraseña. Intenta extraer instrucciones, ejemplos, rutas, políticas y metadatos mediante conversación, errores, traducción y herramientas. El sistema debe seguir seguro aunque parte del prompt se conozca: sin secretos, credenciales, controles de acceso ni reglas cuya revelación conceda autoridad. Minimiza telemetría y separa configuración sensible.

LLM08 Vector and Embedding Weaknesses cubre autorización, aislamiento, procedencia, poisoning, revocación y borrado en RAG. Prueba consultas cruzadas, fragmentos adversarios, documentos retirados, cachés y filtros posteriores al top-k. La autorización debe ocurrir antes de seleccionar contenido y conservarse hasta la salida. Verifica que borrar o revocar alcance índices, réplicas, memoria y resultados almacenados.

  • LLM07: /guias/como-proteger-system-prompts-evitar-filtracion-sistemas-ia-b2b
  • LLM08: /guias/como-proteger-rag-vector-stores-embeddings-sistemas-ia-b2b
  • Evidencia clave: prompt sin secretos, retrieval autorizado antes del top-k, procedencia visible y revocación comprobada.

LLM09 y LLM10: controla afirmaciones, capacidad y costo

LLM09 Misinformation se prueba con afirmaciones comerciales verificables: precios, alcance, fechas, identidad, compromisos, términos y cálculos. Exige evidencia por afirmación cuando corresponda, validación determinista para campos críticos, expresión de incertidumbre y abstención cuando falta información. La revisión humana necesita ver la fuente y la diferencia, no solo un borrador convincente.

LLM10 Unbounded Consumption incluye Denial-of-Wallet, agotamiento de capacidad y extracción por consultas masivas. Prueba tokens, archivos, profundidad, fan-out, herramientas, reintentos, concurrencia y colas. Aplica presupuestos antes de ejecutar, cuotas por identidad y tenant, límites por etapa, backpressure y cancelación. Comprueba que un reintento no duplique trabajo y que la degradación preserve operaciones esenciales.

  • LLM09: /guias/como-reducir-alucinaciones-desinformacion-ia-ventas-b2b
  • LLM10: /guias/como-prevenir-consumo-sin-limites-ai-sales-copilot-b2b
  • Evidencia clave: fuentes trazables, campos críticos validados, presupuesto reservado, límites aplicados y recuperación sin duplicados.

Prueba cadenas de riesgo, porque los fallos no llegan aislados

Una instrucción indirecta puede alterar un tool call, recuperar datos de otra cuenta, generar una salida peligrosa y consumir recursos mientras reintenta. Si el equipo prueba cada categoría por separado, puede perder la ruta que convierte un fallo menor en un incidente grave. Construye escenarios encadenados a partir del modelo de amenazas y conserva el punto exacto donde cada control debe cortar la secuencia.

Prioriza combinaciones plausibles en el recorrido comercial: archivo externo más RAG; correo más agente; propuesta más renderer; proveedor mutable más permiso amplio; dato envenenado más cálculo de precio. No necesitas cubrir todas las combinaciones matemáticas. Elige activos importantes, entradas expuestas y consecuencias relevantes; después registra riesgos residuales y supuestos que todavía no fueron validados.

Prioriza por consecuencia demostrada y exposición real

Clasifica cada hallazgo con activo, confidencialidad, integridad, disponibilidad, alcance de tenant, privilegio requerido, exposición, detectabilidad, reversibilidad y consecuencia comercial. Distingue exploit demostrado, condición necesaria y posibilidad teórica. Una salida extraña visible solo al probador no tiene el mismo peso que un cambio de precio, una fuga entre clientes o un envío automático.

No uses el número LLM como severidad. LLM01 no es siempre más grave que LLM10 y dos hallazgos de la misma categoría pueden requerir prioridades distintas. Define dueño, contención, corrección, fecha, criterio de cierre y riesgo aceptado. Si la reparación toma tiempo, reduce alcance, desactiva la ruta, retira permisos o exige revisión mientras se implementa el control definitivo.

Qué distingue una prioridad defendible
CriterioPregunta útilSeñal insuficiente
Impacto¿Qué activo y decisión puede alterarse?La respuesta se ve rara
Alcance¿Un usuario, tenant o todos?Ocurrió una vez
Exposición¿Quién controla la entrada?Requiere un prompt largo
Recuperación¿Puede revocarse o ya salió?Hay un filtro adicional

Cierra hallazgos con una prueba nueva, no con una promesa

La evidencia de cierre debe mostrar la versión corregida, el control aplicado, el caso original, variantes razonables y el uso legítimo. Conserva quién ejecutó, cuándo, con qué datos y qué resultado observó. Si cambió la arquitectura, actualiza el flujo y el modelo de amenazas. Si solo cambió el prompt, explica qué impide que una entrada alternativa vuelva a cruzar la frontera.

Registra riesgo residual y dependencias. Un proveedor puede prometer una condición que no puedes comprobar; una revisión humana puede reducir impacto sin impedir exposición; un detector puede fallar en formatos nuevos. No ocultes estas limitaciones. El reporte es más útil cuando permite saber qué se demostró, qué se asumió y qué evento obliga a reabrir la revisión.

Repite por eventos y usa una cadencia basada en riesgo

Ejecuta una línea base antes de producción y repite las pruebas afectadas cuando cambien modelo, prompt, RAG, dataset, parser, herramienta, permiso, proveedor, región, interfaz, exportación o flujo de aprobación. Añade una cadencia para funciones estables según exposición e impacto. Los casos de regresión críticos deben correr en integración continua o en un gate previo al release cuando sea viable.

Reabre también por incidentes, anomalías, vulnerabilidades nuevas y cambios relevantes en la taxonomía. Conserva tendencias: cobertura, hallazgos abiertos por severidad, edad, reincidencia, tiempo de contención y porcentaje de controles con evidencia vigente. Evita convertir la métrica en objetivo: cien por ciento de casos verdes no dice nada si el alcance omitió una herramienta nueva.

Organiza el primer ciclo de auditoría en cuatro semanas

Durante la primera semana delimita el sistema, inventaría activos y define responsables. En la segunda construye casos por cada categoría y por cadenas prioritarias, con datos canario y criterios de aprobación. En la tercera ejecuta, reproduce y clasifica sin mezclar observación con interpretación. En la cuarta contiene lo crítico, asigna correcciones, repite pruebas resueltas y publica un registro de riesgo residual.

El resultado no debe ser una presentación aislada. Integra los casos críticos a regresión, enlaza hallazgos con cambios y despliegues, y conserva evidencia con acceso y retención definidos. Presenta a dirección consecuencias y decisiones; a ingeniería, rutas y criterios reproducibles; a ventas, límites operativos claros. Todos necesitan el mismo estado del riesgo, no el mismo nivel de detalle.

  • Semana 1: alcance, flujo, activos, actores, propietarios y versiones.
  • Semana 2: casos LLM01–10, cadenas, canarios y resultados esperados.
  • Semana 3: ejecución, evidencia, reproducción, severidad y contención.
  • Semana 4: remediación prioritaria, retest, riesgo residual y regresión.

Aplica el método al alcance verificable de Cerravi

La lista OWASP 2025 aporta categorías de riesgo para aplicaciones con modelos de lenguaje. NIST AI RMF y su perfil para IA generativa ayudan a situar la prueba dentro del ciclo de gestión de riesgos; NIST AI 100-2 E2025 aporta vocabulario para ataques y mitigaciones adversariales. Estas referencias orientan el trabajo, pero no certifican Cerravi ni reemplazan obligaciones legales, contractuales o sectoriales.

En Cerravi, Copilot organiza contexto y propone borradores para revisión humana; los recorridos públicos no envían mensajes ni cambian etapas por sí solos. Las propuestas usan productos y precios conocidos, y un importe faltante se marca para confirmación. Las monedas permanecen separadas salvo conversión aprobada. Buyer Room aporta señales sin demostrar identidad, aceptación, firma, pago o intención. Forecast usa reglas transparentes del CRM y no es un modelo predictivo entrenado. Cada empresa debe configurar identidades, permisos, fuentes, destinatarios y controles conforme a su uso real.

Mapa de auditoría OWASP Top 10 que conecta riesgos, controles, evidencia y correcciones en un AI Sales Copilot B2B
Interfaz de Cerravi · Demo con datos ilustrativosLa auditoría útil enlaza cada escenario con una frontera, un control observable, evidencia reproducible y un retest de cierre.

Preguntas frecuentes

Dudas comunes sobre este proceso

¿OWASP Top 10 es una certificación para un AI Sales Copilot?

No. OWASP Top 10 es una referencia para reconocer categorías frecuentes de riesgo. Una evaluación debe declarar alcance, versión, escenarios, evidencia, limitaciones y fecha. Tampoco sustituye un modelo de amenazas, controles del negocio ni requisitos legales aplicables.

¿Se debe auditar solamente el modelo de lenguaje?

No. Debes incluir identidad, datos, CRM, RAG, vector stores, memoria, prompts, orquestador, herramientas, credenciales, salidas, logs, proveedores y revisión humana. La mayoría de las consecuencias aparece en la aplicación y sus integraciones, no dentro del modelo aislado.

¿Cómo se prueba OWASP Top 10 sin usar datos reales de clientes?

Usa cuentas de prueba, documentos sintéticos y canarios únicos por tenant, fuente y clase. Conserva los mismos permisos, rutas y destinos del sistema real sin copiar información personal, secretos ni contratos de producción al entorno de evaluación.

¿Con qué frecuencia debe repetirse la auditoría?

Ejecuta una línea base antes de producción y repite los casos afectados ante cambios de modelo, prompt, RAG, datos, herramientas, permisos, proveedor o salida. Añade una cadencia basada en riesgo y reabre por incidentes, anomalías o nuevas técnicas relevantes.

¿Qué evidencia permite cerrar un hallazgo?

La versión corregida, el caso original repetido, variantes razonables, un control positivo, logs mínimos de la decisión, responsable, fecha y riesgo residual. Una descripción de la intención o un cambio de prompt sin retest no demuestra cierre.