Saltar al contenido principal
Cuando un auditor pide “demuestra que estos controles se aplicaron de verdad”, una captura de pantalla de tu consola no sobrevivirá al escrutinio — no está firmada, es tuya y es editable. OrcaRouter genera un reporte de cumplimiento firmado: un pack de evidencia autocontenido capturado desde tus controles vivos del gateway, hasheado con SHA256 y firmado con Ed25519 para que cualquiera que tenga el reporte pueda verificar que fue producido por OrcaRouter y no ha sido alterado desde entonces. Esta página recorre el caso de uso de principio a fin — generar el reporte, entregarlo y dejar que el auditor lo verifique de forma independiente. Para el catálogo de frameworks y a qué se mapea cada pack, ver Frameworks y Contenido del pack.

​
1. Qué contiene el reporte de cumplimiento de ia firmado

Un reporte se genera por framework sobre una ventana de tiempo que eliges, y captura ocho secciones de evidencia en el momento de la generación para que el artefacto siga siendo válido incluso después de que los registros subyacentes caduquen bajo tu política de retención.
Cada reporte cubre las mismas secciones ordenadas para que dos reportes sean comparables:
  • Cobertura — a qué controles del framework se mapean tus packs instalados, cada uno etiquetado covered / observe / gap / attested.
  • Aplicación — las coincidencias de guardrail y los veredictos de firewall (permitidos / bloqueados / auditados) realmente registrados en la ventana.
  • Consentimiento — el estado de consentimiento registrado del período, clasificado válido / obsoleto / revocado / ninguno.
  • Registro de cambios — el historial de guardrail y las filas de auditoría del espacio de trabajo durante la ventana.
  • Acceso de admin — quién tuvo admin y qué acciones privilegiadas se ejecutaron.
  • Huecos — controles no cubiertos, incluyendo cláusulas organizativas (personas/procesos) que nunca pueden automatizarse en el gateway. El reporte las divulga como huecos honestos en vez de implicar un cumplimiento automatizado del 100%.
  • Cadena de suministro de IA — los proveedores upstream (subprocesadores) y modelos alcanzables por el espacio de trabajo, para evidenciar frente a tus DPAs.
  • Revisiones de acceso — las claves API del espacio de trabajo y el listado de miembros privilegiados para la higiene de rotación de claves.
El JSON canónico de evidencia se hashea con SHA256 (hex en minúsculas). Ese hash de contenido se firma con Ed25519, y la firma más un id de clave corto (p. ej. orca-…) se incrustan en el artefacto. Cambia un byte de evidencia y el hash deja de coincidir; falsifica el hash y la firma deja de verificar contra la clave pública de OrcaRouter.
  • PDF — la entrega legible para el auditor, con la firma y el id de clave impresos en él.
  • JSON — la exportación de evidencia legible por máquina. (La firma se computa sobre una forma canónica de la evidencia, no los bytes crudos del archivo, así que verifícala a través del endpoint público de verificación en vez de re-hashear el artefacto tú mismo — ver Verificar un reporte.)
  • CSV — exportación tabular plana para hojas de cálculo y herramientas GRC.
Por defecto, los correos de miembros y actores se enmascaran en cada exportación. Opta por PII sin redactar explícitamente por reporte cuando tu auditor lo necesite.
Los reportes están estampados por región. Cada artefacto se almacena y se sirve bajo la región de residencia de datos declarada de tu espacio de trabajo (us / eu / uk / ap / cn / global); un reporte producido para una región no se sirve bajo otra. Establece la residencia antes de generar si importa para tus obligaciones.

​
2. Quién puede generar uno

Navegar el catálogo de frameworks, los packs instalados y la preparación está abierto a cada miembro del espacio de trabajo y es gratis. Generar un reporte requiere Admin del espacio de trabajo, y la exportación está restringida por plan:
  • El plan gratuito incluye un PDF de reporte, para que puedas demostrar el artefacto.
  • La exportación CSV / JSON y los reportes adicionales requieren un plan de pago.
Ambas reglas se aplican del lado del servidor — no hay forma de saltárselo solo desde el cliente.
Genera desde la consola: abre Compliance → Reports, elige el framework y la ventana de tiempo, escoge un formato y haz clic en generar. La generación es asíncrona — la fila del reporte aparece como pending, pasa a generating, y aterriza en ready (o failed, sin artefacto parcial). Todo esto se ejecuta contra las rutas /api/compliance/* bajo tu sesión de consola — no hay ninguna clave de relay (sk-orca-…) involucrada.

​
3. Un recorrido concreto

Un auditor de SOC 2 quiere evidencia de aplicación para el Q1. El flujo:
1

Instala el framework (una vez)

Como Admin en un plan de pago, instala el pack de SOC 2 desde Compliance → Frameworks. Instalar materializa los guardrails y las políticas de firewall que se mapean a los controles del framework. Ver Instalar un pack.
2

Genera el reporte

En Compliance → Reports, selecciona soc2, establece el período a tu ventana del Q1, escoge PDF y genera. Espera a que la fila llegue a ready, luego descarga.
3

Entrégalo al auditor

Envíales el PDF (o acuña un enlace de compartición de solo lectura para que lo descarguen ellos mismos). La firma y el id de clave están impresos en el reporte.
4

Lo verifican de forma independiente

El auditor nunca tiene que confiar en tu consola. Re-hashean la evidencia, obtienen la clave pública de OrcaRouter y verifican la firma — todo contra endpoints públicos y no autenticados (siguiente sección).

​
4. Cómo lo verifica un auditor

La verificación no necesita cuenta ni clave de relay — se ejecuta contra dos endpoints públicos en api.orcarouter.ai. Primero, obtén la clave pública activa: 
curl https://api.orcarouter.ai/api/public/compliance/pubkey
# => { "algo": "ed25519", "key_id": "orca-…", "public_key": "<base64>" }
Luego envía el hash de contenido, la firma y el id de clave del reporte: 
curl -X POST https://api.orcarouter.ai/api/public/compliance/verify \
  -H "Content-Type: application/json" \
  -d '{
    "content_hash": "<sha256-hex from the report>",
    "signature":    "<base64 Ed25519 signature>",
    "sig_key_id":   "orca-…"
  }'
# => { "valid": true, "key_id": "orca-…" }
Un valid: true significa que el hash de evidencia fue firmado por OrcaRouter y no ha cambiado desde entonces. Un auditor que prefiera no llamar a nuestro endpoint en absoluto puede tomar la clave pública Ed25519 publicada y verificar la firma sobre el hash con cualquier biblioteca criptográfica estándar — el reporte es verificable sin conexión.
¿Prefieres no enviar el PDF como adjunto? Acuña un enlace de compartición de solo lectura para el auditor en su lugar — una URL con token que sirve el reporte (y su firma) directamente, sin inicio de sesión. Ver Exportar evidencia.

​
5. Dónde encaja esto

El reporte firmado es el artefacto al final del flujo de cumplimiento. Las piezas a su alrededor:

Frameworks

El catálogo completo — SOC 2, HIPAA, GDPR, EU AI Act, ISO 27001/42001, NIST AI RMF, PCI DSS, OWASP LLM Top 10 y el conjunto regional.

Instalar un pack

Materializa los guardrails y las políticas de firewall de un framework antes de reportar sobre él.

Residencia de datos

Estampa y fija la región bajo la que se almacena y sirve tu reporte firmado.

Verificar un reporte

El flujo de verificación en profundidad — clave pública, hash y verificaciones sin conexión.
La evidencia dentro del reporte viene de los controles que has configurado. Para fortalecer lo que se reporta, ajusta tus Guardrails y Firewall, y revisa la frontera de lo que el gateway puede y no puede atestar en Responsabilidad compartida.