Saltar al contenido principal
Si ejecutas un agente de soporte de pagos, un bot de triaje de contracargos, o cualquier flujo de LLM que esté cerca de un Número de Cuenta Primaria, la pregunta no es “¿está mi modelo certificado para PCI?” — ningún modelo lo está. La pregunta es si el plano de datos entre tu app y el modelo puede evitar que un PAN, un secreto de tarjeta o una llamada a herramienta destructiva llegue al modelo o se ejecute contra tu entorno de datos de titulares de tarjeta. Eso es lo que te da el pack de PCI DSS: un conjunto de controles del gateway mapeados a PCI DSS 4.0, instalados en una llamada, produciendo evidencia firmada — con la frontera organizativa declarada claramente por adelantado.
Tu entorno de datos de titulares de tarjeta (CDE) — segmentación, acceso físico y tu política de seguridad de la información — es responsabilidad de tu organización, no un control que el gateway pueda aplicar. OrcaRouter puede enmascarar PANs, bloquear secretos de tarjeta, denegar herramientas peligrosas y firmar evidencia — pero el programa de CDE es tuyo. El pack divulga esas cláusulas como controles organizativos que atestas, nunca como cobertura automatizada. Ver la frontera más abajo.

​
1. Qué significa la gobernanza “pci dss ai” en el gateway

El pack de PCI DSS (pci_dss, PCI DSS 4.0) mapea los requisitos del estándar a controles vivos del gateway. Como cada pack de cumplimiento, instalarlo materializa políticas reales y editables de Guardrail y Firewall en tu espacio de trabajo — no agrega un nuevo motor de runtime. Tres controles aplicables hacen el trabajo de datos de titulares de tarjeta:
pci.pan_block (PCI DSS Req 3.4, hacer el PAN ilegible) bloquea los números de tarjeta validados por Luhn en los prompts antes de que lleguen al modelo, y los empareja con instrumentos de enrutamiento bancario — IBANs y códigos SWIFT/BIC — protegidos por su palabra de contexto literal para que una factura o id de seguimiento en mayúsculas que solo comparte la forma estructural no se rechace falsamente. La detección de PAN cabalga sobre la entidad de PII credit_card, así que la verificación Luhn está integrada.
pci.secret_hygiene (PCI DSS Req 8.3, criptografía fuerte para credenciales) bloquea las claves API y privadas para que no transiten el gateway, así que una credencial no puede filtrarse en un prompt o respuesta. Este es el guardrail Secrets Blocker — el mismo control que atrapa secretos en cada solicitud.
pci.dangerous_tools (PCI DSS Req 2.2, configuraciones seguras) es una regla de firewall que deniega las llamadas a herramienta de clase shell y exec en cada convención de nombres — tanto en las superficies inbound como MCP — así que un agente no puede ejecutar un comando destructivo que toque datos de titulares de tarjeta. Todo lo demás se queda en el valor audit por defecto de la política.
Los primeros dos controles viven en el plano de contenido (Guardrails); el tercero vive en el plano de llamada a herramienta (Firewall). La instalación los fusiona en un guardrail y una política de firewall que posees y puedes ajustar.
Dos cláusulas más se envían con el framework pero están marcadas como organizativas: mantener una política de seguridad de la información (Req 12.1) y restringir el acceso físico a los datos de titulares de tarjeta (Req 9). Esos son controles de personas-y-procesos que un proxy nunca puede aplicar — el reporte las divulga como atestadas o como huecos, no como cobertura automatizada. La honestidad es el punto.

​
2. Instala el pack de PCI DSS — un ejemplo concreto

La configuración de cumplimiento usa tu sesión de consola, nunca una clave de relay sk-orca-…. Navegar el catálogo y revisar la preparación son gratis para cualquier Member del espacio de trabajo; instalar es una acción de Admin del espacio de trabajo en un plan de pago, restringida del lado del servidor en ambos sentidos.
1

Abre el pack de PCI DSS

En la consola del espacio de trabajo, ve a Compliance → Catalog y abre PCI DSS 4.0 (vive bajo la categoría financial). Cada control lista su plano, su requisito y un enlace profundo a la biblioteca oficial de documentos del PCI SSC.
2

Instala en modo observe

Como Admin del espacio de trabajo en un plan de pago, haz clic en Install. El pack se materializa de inmediato en modo observe — el guardrail marca en vez de bloquear, el firewall se ejecuta en shadow — así que recopilas evidencia de “lo-habría-bloqueado” contra el tráfico real primero.
3

Observa, luego ponlo en marcha

Deja que los controles en shadow acumulen coincidencias, revísalas, luego pon el pack en marcha para activar las acciones declaradas de block / deny. Ver Observar vs aplicar.
La consola conduce un endpoint bajo tu token de sesión de Admin — mostrado aquí para que lo audites o automatices, no como algo que llamas con una clave de relay: 
POST /api/compliance/packs/pci_dss/install
Authorization: Bearer <your-console-session-token>
Content-Type: application/json

{ }
Un cuerpo vacío instala cada control del pack. La respuesta es el registro de instalación — la versión fijada, mode: observe, y los guardrail_id y firewall_policy_id de las dos políticas materializadas para que puedas abrirlas de inmediato.
Como la instalación produce objetos estándar de guardrail y firewall, puedes adjuntar la política de firewall materializada a una clave de agente por firewall_policy_id, adjuntar el guardrail a una clave por guardrail_id (o establecerlo como valor por defecto del espacio de trabajo), y ajustar la regla de PAN entidad por entidad — exactamente como una política que autoraste a mano.

​
3. La frontera honesta — el CDE es tuyo

Un programa de PCI es mucho más que un filtro de redacción. El gateway cubre los controles que un plano de datos puede aplicar realmente; todo lo demás se queda con tu organización. Aquí está la división, trazada de la misma manera que el mapa de responsabilidad compartida:
Área de controlEl gateway aplicaTu organización posee
PAN en el tráficoBloquear PANs verificados por Luhn, IBAN, SWIFT/BIC en promptsAcotar qué campos son datos de titulares de tarjeta
Secretos de tarjetaBloquear claves API / privadas que transitan el gatewayCustodia de claves fuera de la ruta del gateway
Herramientas peligrosasDenegar llamadas shell / exec cerca del CDEAsegurar las herramientas que saltan el gateway
CDE y política— (divulgado como atestado / hueco)Segmentación; acceso físico; la política de InfoSec
El gateway es la ruta auditada, no un interceptor a nivel de kernel. Una herramienta que tu agente ejecuta enteramente en proceso — una que nunca cruza https://api.orcarouter.ai y nunca reporta un destino de egress — está fuera de la vista del firewall. Enruta las herramientas y llamadas MCP que tocan datos de titulares de tarjeta a través del gateway (vía el gateway MCP del Firewall) para que el control de herramientas peligrosas pueda verlas, o asegúralas tú mismo dentro de tu CDE.

​
4. Demuéstralo — evidencia firmada y estampada por región

Una vez que el pack está en marcha, genera un reporte de PCI DSS. Los reportes están firmados con Ed25519 y estampados con SHA-256, exportables como CSV / JSON / PDF, y verificables públicamente — un evaluador puede confirmar la autenticidad de un reporte sin un inicio de sesión. Cada fila rastrea un requisito hasta la política exacta de guardrail o firewall que la aplica y las coincidencias que produjo durante el período; las dos cláusulas organizativas se renderizan como huecos divulgados o atestaciones del dueño. También declaras una región de residencia de datos para el artefacto del reporte (us / eu / uk / ap / cn / global) — los reportes firmados se almacenan y se sirven solo bajo tu región declarada, y una lectura entre regiones se retiene. Esto estampa el artefacto de evidencia, no la geografía de la inferencia.
Instalar un pack y ponerlo en marcha requieren Admin del espacio de trabajo en un plan de pago, aplicado del lado del servidor. La generación de reportes es de Admin (plan gratuito: un PDF; CSV/JSON y reportes adicionales son de pago); establecer la residencia está restringido a Admin. Navegar el catálogo y revisar la preparación siguen siendo gratis. Ver Restricciones por plan.

​
5. Dónde ir a continuación

Instalar un pack

El flujo de instalación completo — selección de controles, modo observe y activación.

Reporte firmado

Qué contiene el reporte de evidencia de PCI DSS firmado con Ed25519.

Verificar un reporte

Cómo un evaluador confirma que un reporte es auténtico sin un inicio de sesión.

Referencia de Guardrails

El plano de contenido que el pack materializa — entidades de PII, Secrets Blocker, acciones.

Llamadas a herramienta peligrosas

La amenaza contra la que defiende el control de firewall.

Residencia de datos

Declarar la región bajo la que se almacena y sirve tu evidencia firmada.
El pack de PCI DSS convierte los requisitos de 4.0 que puedes poner en un plano de datos en enmascarado de PAN, bloqueo de secretos, denegación de herramientas peligrosas y evidencia firmada que puedes entregar a un evaluador — mientras dice claramente que el CDE, la segmentación y tu política de seguridad de la información siguen siendo tuyos. Para el resto del catálogo, ver Frameworks.