Saltar al contenido principal
No eliges un framework para leer una lista de marketing. Eliges uno para demostrar — a un auditor, un cliente, un regulador — que el control que pide está realmente ejecutándose en la ruta que usan tus agentes. OrcaRouter envía un catálogo de frameworks como packs instalables, y cada framework en ese catálogo se mapea a la misma maquinaria de guardrail y firewall que ejecuta el resto de tu espacio de trabajo, más un reporte firmado que captura lo que se atrapó. Esta página lista el registro real de frameworks y muestra cómo cada uno se convierte en evidencia. Para el arco de instalar-y-poner-en-marcha, empieza en la Visión general de cumplimiento. El catálogo es el registro en vivo — navégalo en Compliance → Catalog en vez de codificar un conteo a mano, ya que se agregan packs con el tiempo. Al momento de escribir esto abarca estándares generales de seguridad y gobernanza de IA, regímenes sectoriales y un amplio conjunto de leyes regionales de privacidad. La consola los agrupa en cinco pestañas de categoría: ai, privacy, security, financial y healthcare.
eu_ai_act · nist_ai_rmf · iso_42001 · owasp_llm · colorado_ai. El OWASP LLM Top 10 se envía como un pack instalable real (owasp_llm), no solo una vista de mapeo de controles — ver OWASP LLM Top 10.
soc2 · iso_27001 · nist_800_53 · cmmc. Estándares generales de confianza y seguridad de la información mapeados a los planos de contenido y acción.
pci_dss · glba · dora_eu. Regímenes de pagos, banca y resiliencia operativa — enmascarado de PAN, higiene de secretos, controles de herramientas peligrosas y evidencia de egress.
hipaa · hitrust. Redacción de PHI, desidentificación y guardas de egress de seguridad de transmisión.
gdpr · uk_gdpr · ccpa · china_pipl · appi_jp · pipa_kr · lgpd_br · pipeda_ca · dpdp_in · privacy_au · pdpa_sg · vcdpa_va · cpa_co · ctdpa_ct · ucpa_ut · tdpsa_tx · ferpa · coppa. Cada uno lleva controles de minimización de datos, manejo de categorías especiales y registros de procesamiento afinados a la jurisdicción.
Cada pack lleva una fecha de vigencia y el mes en que su mapeo de controles se revisó por última vez, ambos expuestos en el catálogo y el reporte — así que un auditor puede ver qué tan actual es el mapeo, no solo que existe.

​
2. Qué significa “evidencia” para un framework

Instalar un pack materializa dos objetos reales y editables en tu espacio de trabajo, y son los que lee el reporte:
  • un Guardrail — los controles del plano de contenido (PII, PHI, secretos, salida insegura) que el framework espera en las solicitudes y respuestas;
  • una o más reglas de política de Firewall — los controles del plano de acción (qué llamadas a herramienta, despachos MCP y destinos de egress se permiten o auditan).
Como los objetos son reales, la evidencia del framework no es una autoatestación — es el estado vivo y el historial de coincidencias de controles que tu tráfico ya cruza. Un reporte captura ese estado en el momento de la generación a través de ocho secciones de evidencia (cobertura, aplicación, consentimiento, registro de cambios, acceso de admin, huecos, subprocesadores y revisiones de acceso), así que el artefacto sigue siendo autocontenido incluso después de que los registros caduquen.
Sección de evidenciaQué captura
CoberturaQué controles en alcance están satisfechos por un pack instalado
AplicaciónSi cada control está en vivo o aún en modo observe
Registro de cambiosEl historial versionado de ediciones de política detrás de los controles
Los reportes también capturan secciones de consentimiento, acceso-de-admin y huecos; ver Contenido del pack para el mapa completo de controles que un pack establece.
La lista de verificación en alcance de un framework es la unión de los controles cubiertos por el pack y las cláusulas organizativas (capacitación del personal, BAAs, DPIAs, acceso físico) que nunca pueden automatizarse en el gateway. Esos elementos organizativos siempre se renderizan como un ⚠ Hueco divulgado con orientación — así que la completitud es honesta, nunca silenciosamente del 100%.

​
3. Un flujo concreto: SOC 2

Supón que necesitas evidencia de SOC 2. Como Admin del espacio de trabajo en un plan de pago, instala el pack desde la consola en Compliance → Catalog. La consola conduce la ruta de gestión por ti usando tu sesión (no una clave de relay): 
POST /api/compliance/packs/soc2/install
Authorization: Bearer <your console session>
El pack soc2 materializa un guardrail que enmascara PII confidencial y registra las decisiones de guardrail, más una regla de firewall que audita cada despacho de herramienta — mapeados a TSC CC6.1, CC7.2. Aterriza en modo observe, así que nada de lo que hacen tus agentes se interrumpe mientras observas los feeds de coincidencias y eventos. Cuando los feeds se ven limpios, ponlo en marcha y genera el reporte: 
POST /api/compliance/packs/soc2/golive
El reporte sale firmado con Ed25519 y hasheado con SHA-256, exportable como CSV, JSON o PDF, y verificable públicamente — tu auditor lo confirma con la clave pública de OrcaRouter, sin necesidad de cuenta. Las cláusulas organizativas de SOC 2 (gestión de cambios, evaluación de riesgos) aparecen como huecos divulgados con orientación, porque viven en tu proceso, no en el gateway.
Navegar el catálogo, los packs instalados y la preparación está abierto a cada Member del espacio de trabajo y es gratis. Solo el Admin que es dueño del despliegue necesita la instalación, la activación y la residencia — así que tus revisores de auditoría pueden observar la preparación sin acceso de escritura.

​
4. Leer el registro programáticamente

Las lecturas de catálogo y preparación están abiertas a los Members, así que un revisor o un trabajo de CI puede extraer la lista actual de frameworks y el estado por control sin acceso de escritura. La consola usa tu sesión para estas rutas de gestión: 
GET /api/compliance/catalog      # the live framework registry
GET /api/compliance/readiness    # per-control satisfied / gap status
No codifiques un conteo o lista de frameworks en tu propia herramienta. El catálogo es la fuente de verdad y crece con el tiempo. Lee /api/compliance/catalog y basa tu lógica en la key del framework (soc2, hipaa, eu_ai_act, …) en vez de una cadena de nombre.

​
5. Del framework a los controles subyacentes

Un framework es una vista de controles que también puedes configurar directamente. Si quieres entender o ajustar lo que un pack establece — o construir la misma cobertura a mano — las referencias profundas son:

Guardrails

La referencia del plano de contenido — entidades de PII y PHI, secretos, salida insegura y las acciones block / mask / flag que usa un pack.

Agent Firewall

La referencia del plano de acción — reglas de herramienta, MCP y egress y los veredictos audit / deny / sanitize detrás de la política de firewall de un pack.

Qué contiene un pack

Los objetos exactos de guardrail y firewall que materializa cada framework.

Matriz de controles

Cada control mapeado a través de los frameworks en una sola cuadrícula.

​
6. Páginas por framework

Los frameworks con su propia página enfocada:

SOC 2

HIPAA

GDPR

EU AI Act

ISO 27001

ISO 42001

NIST AI RMF

OWASP LLM Top 10

PCI DSS

CCPA

​
7. Dónde encaja esto

Observar vs aplicar

Aterriza cada pack en modo observe primero; lee la señal antes de la activación.

Reporte firmado

Cómo se hashea y firma un reporte, y qué verifica un auditor.

Responsabilidad compartida

Qué asegura el gateway frente a qué sigue siendo tuyo — la frontera honesta detrás de cualquier afirmación de framework.

Modos de aplicación

Observar, auditar y aplicar — el vocabulario compartido detrás de la activación.
El catálogo crece, pero la forma nunca cambia: elige un framework, instala su pack, observa qué captura, ponlo en marcha y entrega a tu auditor un reporte firmado mapeado cláusula por cláusula a controles que tu tráfico realmente cruzó.