Command R 08-2024 y sus modos de seguridad: qué control ofrecen y qué debes probar

Qué controla safety_mode —y qué no—

Command R 08-2024 es una versión del modelo de Cohere que se identifica mediante el nombre de modelo command-r-08-2024. Al llamar a los endpoints de chat de Cohere, el parámetro safety_mode permite escoger entre modos que cambian las instrucciones de seguridad incorporadas a la solicitud. En otras palabras, es una configuración de cómo se orienta al modelo durante la interacción, no una certificación independiente del modelo ni una garantía de que una aplicación sea segura.

La distinción importa en la práctica. Un resultado aceptable en una prueba con una solicitud sencilla solo describe esa combinación de modelo, endpoint, parámetros e instrucciones. No permite concluir por sí solo que la aplicación resistirá entradas adversariales, que tratará correctamente documentos no confiables o que bloqueará todas las salidas perjudiciales. Esas propiedades requieren pruebas del sistema completo y controles de producto adecuados al riesgo.

La documentación disponible del proveedor no debe interpretarse como evidencia de que un modo elimina todo contenido problemático. La tarjeta del modelo aporta contexto sobre evaluaciones y limitaciones de seguridad, pero no demuestra la eficacia de cada modo para command-r-08-2024. Por tanto, conviene describir los modos como una opción de configuración que se debe evaluar, no como una defensa completa.

STRICT, CONTEXTUAL y NONE: diferencias y nombres por endpoint

En la referencia de Chat V1, los valores documentados son STRICT, CONTEXTUAL y NONE; allí safety_mode aparece marcado como beta. La referencia actual de Chat V2 enumera STRICT, CONTEXTUAL y OFF. Así que NONE y OFF son nombres que aparecen en referencias distintas, no valores que deban suponerse intercambiables en una misma llamada: antes de configurar una integración, hay que comprobar la especificación del endpoint utilizado.

Cohere presentó históricamente los modos como niveles distintos de orientación de seguridad. STRICT prioriza una aplicación más estricta de esas instrucciones; CONTEXTUAL las aplica atendiendo al contexto de la solicitud; y NONE representa la opción sin ese conjunto de instrucciones añadido por el modo. Esta descripción no significa que NONE convierta al modelo en un sistema sin ninguna protección: el anuncio del proveedor señala que ciertas protecciones no se pueden desactivar.

El propósito de CONTEXTUAL es evitar que la seguridad se reduzca a una respuesta mecánica ante palabras aisladas. Sin embargo, que el nombre sugiera una interpretación contextual no demuestra que el modelo acierte siempre al distinguir una petición legítima de una dañina. Un equipo debe comprobarlo con ejemplos de su dominio, incluidos los que plantean dudas razonables.

La etiqueta beta de V1 es un dato relevante para la gestión de cambios: aconseja revisar la documentación y repetir pruebas antes de actualizar la integración. La referencia V2 presenta su propio conjunto de valores, pero las fuentes aportadas no aclaran de forma suficiente si el estado beta de V1 se mantiene, ni si los detalles de disponibilidad son idénticos en todos los canales de despliegue. No conviene trasladar automáticamente el estado de un endpoint al otro.

La limitación con tools y documents cambia lo que una prueba demuestra

La referencia de Chat V1 documenta que safety_mode no se puede combinar con tools, tool_results y documents. La de Chat V2 también indica una limitación de combinación con tools y documents. Para un equipo que utiliza generación aumentada por recuperación (RAG) o llamadas a herramientas, esto es un límite operativo: no se debe presentar una prueba aislada del modo como evidencia directa del comportamiento del flujo completo.

La incompatibilidad documentada tampoco permite concluir que las herramientas o los documentos sean inseguros, ni que el modelo no pueda emplearlos en ninguna configuración. Indica que los parámetros enumerados no se pueden combinar en la llamada tal como está descrita por esas referencias. La integración debe respetar la forma admitida por el endpoint y validar por separado los componentes y su interacción.

Una evaluación útil separa al menos dos preguntas. Primero: ¿cómo responde el modelo con safety_mode en una llamada compatible y controlada? Segundo: ¿qué ocurre en la aplicación real cuando se recuperan documentos, se envían resultados de herramientas o se incorporan instrucciones propias? La primera respuesta no sustituye a la segunda. Además, un texto recuperado puede contener instrucciones, información incorrecta o material dañino; la aplicación debe tratarlo como contenido que se evalúa, no como una política de seguridad.

Las fuentes aportadas describen las restricciones de parámetros en las referencias de Chat V1 y Chat V2. No detallan todas las combinaciones disponibles en cada canal de despliegue ni permiten afirmar que cada servicio compatible con Cohere ofrezca idénticas capacidades. Confirma la especificación aplicable al entorno concreto antes de diseñar el ensayo.

Un protocolo reproducible de evaluación

Una evaluación comparativa debe fijar de antemano qué resultado se considera correcto para cada caso. Si el equipo cambia el criterio después de ver las respuestas, puede terminar premiando el modo que confirma expectativas previas. Mantén un conjunto de casos con etiquetas y justificación, y ejecuta cada caso con la misma versión del modelo, endpoint y parámetros, salvo la variable que se desea comparar.

Incluye solicitudes permitidas pero sensibles: por ejemplo, una explicación preventiva sobre seguridad, una consulta educativa sobre un tema de riesgo o una petición de apoyo que requiere tono cuidadoso. Añade solicitudes claramente dañinas según la política del producto y casos ambiguos donde el modelo debería pedir contexto, limitar la respuesta o rechazar una parte. Estos son ejemplos para construir un conjunto de evaluación; las fuentes no publican una batería específica para medir los modos de Command R 08-2024.

Prueba variaciones lingüísticas y de formulación: paráfrasis, errores ortográficos, expresiones indirectas y cambios de idioma relevantes para la audiencia. No basta con traducir literalmente un único caso, ya que la equivalencia de intención puede perderse al cambiar de lengua. Si el producto recibe contenido en varios idiomas, evalúa cada uno con personas competentes o criterios revisados por especialistas.

Repite los casos varias veces. Las respuestas pueden variar entre ejecuciones, y una muestra única no permite medir consistencia. Conserva las entradas exactas, el resultado esperado, la respuesta completa, la decisión de evaluación y el contexto de la llamada. Cuando cambie el modelo, la API o las instrucciones de la aplicación, vuelve a ejecutar el conjunto y compara versiones.

Métricas que ayudan a interpretar los resultados

Cuenta los rechazos correctos: casos que debían rechazarse y recibieron una negativa o una respuesta segura de acuerdo con los criterios definidos. También cuenta los falsos rechazos: solicitudes permitidas que se bloquearon o quedaron inutilizables. Una tasa de rechazo elevada no demuestra por sí sola una mejor seguridad si se obtiene rechazando muchas tareas legítimas.

Registra también las respuestas inseguras: casos que debían rechazarse o limitarse y en los que el sistema proporcionó contenido no permitido. Analiza por separado el cumplimiento de instrucciones del producto, la consistencia entre ejecuciones y las diferencias entre modos. Si una respuesta es parcialmente correcta, usa categorías intermedias definidas con antelación en lugar de forzarla a “aprobada” o “rechazada”.

Segmenta los resultados por tipo de solicitud, idioma, modo y configuración. Un promedio agregado puede ocultar que el sistema funciona de manera distinta en consultas sensibles permitidas que en solicitudes ambiguas. En los flujos con documentos o herramientas, registra además qué contenido se recuperó, qué herramienta se llamó y qué información volvió al modelo, siempre respetando las normas de privacidad y retención de la organización.

Las métricas son evidencia para una decisión, no un certificado universal. Una muestra pequeña, un conjunto demasiado predecible o una política de etiquetado imprecisa puede producir una falsa impresión de fiabilidad. Informa el tamaño y composición del conjunto, las repeticiones y los desacuerdos de evaluación. Cuando los resultados sean ambiguos o impliquen consecuencias importantes para las personas, incorpora revisión humana especializada.

Registra el entorno y conserva controles externos

Para que los resultados sean interpretables, registra el identificador exacto del modelo —incluido command-r-08-2024 cuando corresponda—, el endpoint, el valor de safety_mode y la fecha. Añade los demás parámetros de generación, las instrucciones del sistema y de la aplicación, el idioma de la entrada y si se incluyeron documentos, herramientas o resultados de herramientas. La fecha y la versión de la integración ayudan a detectar que dos ejecuciones aparentemente comparables no usaban el mismo entorno.

La documentación del proveedor no responde todas las preguntas de despliegue planteadas por esta guía. En particular, no hay aquí evidencia suficiente para confirmar que el estado beta de V1 se aplique o no a V2, que la limitación de combinación tenga idéntico alcance en todos los canales, o que un protocolo sea reproducible sin cambios en todos los entornos compatibles. Verifica esos puntos en la referencia vigente de tu endpoint y en la configuración real antes de interpretar resultados.

Mantén controles propios aunque una prueba favorezca un modo. Entre ellos pueden estar la definición de usos permitidos, controles de acceso para herramientas, validación de datos, límites de acciones, monitorización, procedimientos de respuesta a incidentes y revisión humana en decisiones de alto impacto. La selección de controles depende del producto y del riesgo: no se puede deducir una configuración suficiente únicamente a partir del nombre del modo.

Como criterio práctico, elige el modo que cumpla la política de tu aplicación con un equilibrio aceptable entre respuestas inseguras y falsos rechazos, siempre basándote en pruebas representativas. Si el resultado depende del uso de documentos o herramientas, evalúa el flujo de producción por separado y confirma qué parámetros admite. Repite la evaluación cuando cambien el modelo, el endpoint, las instrucciones o la arquitectura. Así, la decisión sobre Command R 08-2024 queda vinculada a evidencia del sistema que realmente se utiliza, en vez de descansar en la etiqueta de un modo.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.