Referencia del objeto response — POST /analyze

El endpoint POST /analyze retorna un objeto JSON con el resultado del análisis de riesgo. El objeto es stateless: refleja exclusivamente el análisis de esa llamada específica. vario no almacena el texto enviado ni el resultado — el objeto response es el único producto de la llamada.

Tabla de campos

Cómo interpretar combined_score

combined_score es un número de punto flotante en el rango 0 a 10:

• 0 — sin señal detectada para la conducta analizada.
• 10 — señal máxima; la comunicación presenta indicadores muy fuertes de la conducta.

La escala es ordinal, no lineal: la distancia entre 7 y 8 no es equivalente a la distancia entre 3 y 4. No compares scores de llamadas distintas como si fueran magnitudes absolutas; úsalos para priorizar dentro de un corpus.

El campo severity expresa el mismo resultado en categorías cualitativas, más útiles para tomar decisiones de triaje. El campo should_alert es el indicador binario recomendado para integrar en flujos automáticos.

Cómo interpretar severity

severity categoriza el nivel de riesgo de la comunicación:

La determinación de severity es responsabilidad del sistema; la decisión de actuar sobre ella es siempre responsabilidad del revisor humano.

Cómo usar reasoning y key_phrases

reasoning es una explicación narrativa generada en el idioma del texto analizado. Describe qué elementos de la comunicación contribuyeron al resultado. Su propósito es dar contexto al revisor humano — no es un dictamen legal ni una conclusión definitiva.

key_phrases es un array de fragmentos extraídos del texto que el sistema identificó como relevantes para la conducta analizada. Pueden usarse para localizar rápidamente las partes del mensaje que motivaron el score.

Consideraciones importantes:

• Tanto reasoning como key_phrases son herramientas de orientación para el revisor, no sustitutos del análisis legal.
• Cuando bedrock_available es false, reasoning puede estar vacío o ser menos detallado.
• key_phrases puede ser un array vacío ([]) si el sistema no identificó fragmentos específicos con suficiente confianza.

Cómo usar regulatory_frameworks

regulatory_frameworks lista los marcos regulatorios que el sistema identificó como potencialmente relevantes para la comunicación analizada. Ejemplos de valores posibles: "FCPA", "DL 211", "MAR", "Lei Anticorrupção 12.846/2013", "CADE", "COFECE".

Consideraciones importantes:

• Esta lista refleja los marcos que el sistema asoció con la señal detectada. No es una opinión jurídica.
• No reemplaza asesoría legal especializada.
• El array puede estar vacío ([]) si el sistema no identificó marcos con suficiente confianza.

Privacidad

vario no almacena ni retiene el texto analizado. El pipeline es completamente stateless: ningún dato del campo text ni de thread_context persiste en la base de datos de vario.

Degradación: cuando bedrock_available es false

Si el análisis profundo no estuvo disponible en el momento de la llamada, el endpoint retorna 200 con bedrock_available: false. En este caso:

• reasoning puede estar vacío.
• confidence puede ser "low". Para recibir un error explícito en lugar de un response parcial, incluye el header Prefer: deep-analysis-required. En ese caso, el endpoint retorna 503 DEEP_ANALYSIS_UNAVAILABLE cuando el análisis profundo no está disponible.

Ejemplo de response completo

Señal alta de coordinación de precios, analizada en modo full:

{
  "combined_score": 8.4,
  "should_alert": true,
  "severity": "critical",
  "reasoning": "El mensaje contiene una indicación explícita de coordinar el precio mínimo de venta con un competidor. La referencia directa a un valor de precio y la expectativa de que otros actores del mercado lo respetarán son indicadores consistentes con coordinación horizontal de precios.",
  "key_phrases": [
    "no bajamos de $450 la unidad",
    "los demás van a hacer lo mismo",
    "acordamos no competir por precio"
  ],
  "regulatory_frameworks": [
    "DL 211 (Chile)",
    "Lei Anticorrupção 12.846/2013 (Brasil)",
    "COFECE — Ley Federal de Competencia Económica"
  ],
  "recommended_action": "legal_review",
  "confidence": "high",
  "mode_used": "full",
  "analyzed_at": "2026-06-02T14:32:00Z",
  "pipeline_version": "1.0",
  "bedrock_available": true
}

Ejemplo en modo fast con señal baja

{
  "combined_score": 1.2,
  "should_alert": false,
  "severity": "low",
  "reasoning": "No se identificaron indicadores relevantes de la conducta analizada en el texto proporcionado.",
  "key_phrases": [],
  "regulatory_frameworks": [],
  "recommended_action": "no_action",
  "confidence": "high",
  "mode_used": "fast",
  "analyzed_at": "2026-06-02T14:33:10Z",
  "pipeline_version": "1.0",
  "bedrock_available": true
}

Ejemplo con degradación (bedrock_available: false)

{
  "combined_score": 3.1,
  "should_alert": false,
  "severity": "medium",
  "reasoning": "",
  "key_phrases": [],
  "regulatory_frameworks": [],
  "recommended_action": "monitoring",
  "confidence": "low",
  "mode_used": "fast",
  "analyzed_at": "2026-06-02T15:01:42Z",
  "pipeline_version": "1.0",
  "bedrock_available": false
}

Response en modo screening

Cuando mode_used es "screening", el objeto response tiene un schema distinto al de los modos fast y full. Solo incluye resultados de la capa L1 (keyword + embedding). Los campos combined_score, should_alert, severity, reasoning, key_phrases, regulatory_frameworks, recommended_action, confidence y bedrock_available no están presentes.

Ejemplo de response en modo screening:

{
  "mode_used": "screening",
  "l1_score": 0.82,
  "l1_keyword_score": 0.75,
  "l1_embedding_score": 0.82,
  "l1_matched_terms": ["acordamos no movernos del precio", "precio"],
  "l1_embedding_available": true,
  "playbook": "price_fixing",
  "playbook_version": "1.0",
  "pipeline_version": "1.0",
  "analyzed_at": "2026-06-04T10:15:00Z",
  "external_id": "email-msg-00842"
}

Notas finales

• El output de POST /analyze es una señal de riesgo, no una determinación legal. No sustituye la revisión por parte de un abogado ni constituye evidencia ante reguladores.
• vario alerta; el CCO decide. El principio de revisión humana es parte del diseño del sistema.