Saltar al contenido principal
Estás poniendo un agente de IA frente a datos de clientes y tu auditor quiere saber qué cláusulas de los Trust Services puedes evidenciar realmente. En un gateway alojado, la respuesta honesta es: las cláusulas que se mapean a un control que se ejecuta en la ruta de la solicitud — acceso lógico, monitoreo y auditoría de llamadas a herramienta — más las cláusulas organizativas que un proxy nunca puede aplicar y debe divulgar como huecos. Esta página es el recorrido de soc 2 ai: qué cláusulas TSC cubre el pack de SOC 2, el único control que materializa para confidencialidad, y cómo se firma la evidencia resultante. Para el flujo de instalación y el formato del reporte en profundidad, sigue los enlaces al final — esta página es el mapa específico de SOC 2, no la referencia completa de Cumplimiento.

1. Qué cubre el pack de soc 2 ai

El pack de SOC 2 mapea los Trust Services Criteria del AICPA a controles que se ejecutan en cada solicitud que cruza el gateway. Tres cláusulas se mapean a aplicación en vivo; dos son organizativas y se divulgan como huecos en vez de afirmarse.
Cláusula TSCPlanoControl
CC6.1 Controles de acceso lógicoguardrailbloquear PII confidencial en los prompts
CC7.2 Monitoreo del sistemaguardrailregistrar cada decisión de guardrail como evidencia
CC7.2 Detección de anomalíasfirewallauditar cada despacho de herramienta
CC8.1 Gestión de cambios y CC3.1 Evaluación de riesgos son cláusulas de personas-y-procesos. Un proxy no puede aplicarlas, así que el pack las expone como huecos divulgados (o filas atestadas por el dueño) tanto en la consola como en el reporte — nunca como cobertura automatizada. Los huecos honestos son lo que hace confiable el resto de la evidencia. Ver la matriz de controles.
Los dos planos de aplicación son la misma maquinaria de Guardrails y Firewall que configuras a mano. El pack es el mapeo autorado que dice qué control existente satisface qué cláusula — no incluye ningún motor de runtime nuevo. Ver Contenido del pack para la anatomía completa.

2. Instala el pack — un ejemplo concreto

Instalar materializa el mapeo en una política de guardrail y una política de firewall en tu espacio de trabajo, cada una etiquetada con la procedencia del pack. Haces esto desde la consola, no una clave de relay: Compliance → Catalog → SOC 2 → Install Esa es una acción de Admin del espacio de trabajo en un plan de pago, y el servidor aplica ambas. Bajo el capó tu sesión de consola llama:
POST /api/compliance/packs/soc2/install
Nunca entregues una clave de relay sk-orca-… a una ruta de configuración. Las rutas /api/compliance/* se autentican con tu sesión de consola, no la clave de relay — solo las llamadas a modelo /v1/* usan sk-orca-…. Navegar el catálogo, los packs instalados y la preparación es gratis y está abierto a cada miembro del espacio de trabajo; instalar, poner en marcha, reportar y la residencia son las acciones restringidas de Admin.
Tras la instalación, la fila CC6.1 deja de ser prosa. El control de confidencialidad se vuelve una regla de guardrail pii real — acción block, etapa input — que puedes abrir, leer y ajustar como cualquier otra regla. El control de monitoreo CC7.2 registra cada decisión de guardrail como evidencia, y el control de firewall establece cada despacho de herramienta al veredicto audit.
Este control actúa sobre la solicitud: la PII confidencial se bloquea en la etapa de entrada antes de que el modelo la vea. El manejo de PII en salida / streaming en vivo está en la hoja de ruta, así que para el lado de salida la evidencia de monitoreo es lo que un auditor lee para CC7.2 durante el período del reporte.

3. Observa primero, luego ponlo en marcha

Una instalación de SOC 2 no empieza a bloquear tráfico el primer día. Las instalaciones aterrizan en modo observe: las acciones de guardrail se fuerzan a flag y la política de firewall se ejecuta en shadow (solo registro). Obtienes evidencia de “lo-habría-bloqueado” contra el tráfico real antes de que nada aplique. Cuando la evidencia se ve bien, un Admin del espacio de trabajo promueve el pack a la activación, que restaura las acciones declaradas — el control CC6.1 empieza a bloquear, el control de firewall sigue auditando — y opcionalmente promueve las políticas materializadas a valor por defecto del espacio de trabajo. Esta es la misma disciplina descrita en Observar vs aplicar.

4. Evidencia firmada que tu auditor puede verificar

El punto del pack es el reporte. La evidencia de SOC 2 se genera como un reporte firmado con Ed25519 con un hash de contenido SHA256, exportable como CSV, JSON o PDF, y verificable públicamente — tu auditor verifica la firma sin un inicio de sesión de OrcaRouter.
Cada fila TSC lleva su estado — covered, observe, gap o attested — y cuántas veces el control realmente se disparó durante el período. Un control CC6.1 que bloqueó 4.000 solicitudes se lee diferente para un auditor que uno con cero coincidencias, y el reporte muestra ambos.
Cada control materializado registra su control_id (p. ej. soc2.confidentiality), la cláusula literal (TSC CC6.1 Logical access controls), el plano y el id del objeto de política vivo que la aplica — así que el auditor recorre cláusula → control → política que la aplica → coincidencias, sin paso inferido.
Obtén la clave pública de firma en GET /api/public/compliance/pubkey, envía el reporte a POST /api/public/compliance/verify, o abre un enlace de compartición para el auditor acotado en GET /api/public/compliance/share/:token. Sin cuenta requerida.
Ver el reporte firmado para el diseño completo de portada-a-pie y Verificar un reporte para el recorrido de verificación.

5. Estampa por región tu evidencia de SOC 2

Los reportes de SOC 2 se almacenan y se sirven bajo tu región de residencia declarada — us / eu / uk / ap / cn / global — y un reporte solo se sirve bajo una región coincidente; las lecturas entre regiones se retienen. Un Admin del espacio de trabajo la establece vía PUT /api/compliance/residency.
La residencia aquí es la región del artefacto de evidencia — dónde viven y se sirven los reportes firmados. No es geo-fijación de datos de inferencia. Ver Residencia de datos y Entre regiones para la frontera.
Los registros de solicitud por defecto tienen una retención de 30 días (recortada en el servidor a un máximo estricto de 180 días), y una eliminación de usuario ejecuta una ventana de gracia de 30 días luego una limpieza de PII — ambas relevantes cuando un auditor pregunta por tu postura de retención. Ver Retención y Derecho al borrado.

6. Dónde ir a continuación

Contenido del pack

La anatomía completa de un pack — ambos planos, estados y procedencia.

Instalar un pack

El flujo de instalación de principio a fin, modo observe y activación.

Reporte firmado

Qué contiene el reporte de evidencia firmado con Ed25519.

Matriz de controles

Cada cláusula, su plano y si está cubierta, observada o es un hueco.

Frameworks

El catálogo completo — HIPAA, GDPR, el EU AI Act, ISO 27001 y más.

Guardrails vs Firewall

Los dos planos a los que escribe un pack de SOC 2, ejecutados por un resolutor.
SOC 2 en un gateway alojado es la disciplina de ser preciso: mapea las cláusulas que un proxy puede aplicar a controles vivos, divulga las que no puede, y firma la evidencia para que la línea entre las dos resista la auditoría.