# Whitepaper de Seguridad, Privacidad y Arquitectura Zero-Knowledge para Instituciones Reguladas

**IA Gobernanza — Plataforma Corporativa de Gobernanza y Control de Inteligencia Artificial**

| | |
|---|---|
| **Versión del documento** | 2.0 — incorpora AI Threat Shield (defensa contra IA maliciosa), webhooks v2 anti-replay, Zero-Knowledge fail-closed y multi-tenancy |
| **Fecha** | Junio 2025 |
| **Clasificación** | Público — Uso Comercial |
| **Audiencia** | Directores de Tecnología (CTO), Oficiales de Seguridad (CISO), Oficiales de Cumplimiento, Auditores Internos y Externos |
| **Marco regulatorio de referencia** | LFPDPPP (México), CNBV (Circular Única de Bancos), T-MEC Anexo 19-D, ISO/IEC 27001:2022, ISO/IEC 42001:2023, PCI-DSS v4.0, NIST SP 800-53 Rev. 5, NIST AI RMF 1.0, OWASP Top 10 for LLM Applications 2025, MITRE ATLAS |
| **Estado de certificaciones** | **Ninguna certificación de tercero obtenida a la fecha.** Los marcos se citan como referencia de diseño. Ver Trust Center (`/trust#certificaciones`). |
| **Autor técnico** | Equipo de Ingeniería de Privacidad — IA Gobernanza |

---

## Índice

1. [Resumen Ejecutivo](#1-resumen-ejecutivo)
2. [Arquitectura de Flujo de Datos Perimetral](#2-arquitectura-de-flujo-de-datos-perimetral)
3. [Mecanismo de Tokenización y Cifrado Local](#3-mecanismo-de-tokenización-y-cifrado-local)
4. [Cumplimiento Normativo de Terceros](#4-cumplimiento-normativo-de-terceros)
5. [Matriz de Responsabilidad Compartida](#5-matriz-de-responsabilidad-compartida)
6. [AI Threat Shield — Defensa contra IA maliciosa](#6-ai-threat-shield--defensa-contra-ia-maliciosa)
7. [Integridad Operativa: Autenticación, Auditoría, Webhooks y Multi-tenancy](#7-integridad-operativa-autenticación-auditoría-webhooks-y-multi-tenancy)
8. [Apéndices Técnicos](#8-apéndices-técnicos)

---

## 1. Resumen Ejecutivo

### 1.1 Contexto y Problema

La adopción masiva de Modelos de Lenguaje de Gran Escala (LLM) por parte de las instituciones financieras, aseguradoras y organismos regulados en América Latina ha generado dos tensiones estructurales:

1. La **necesidad crítica** de gobernar, auditar y contener los sistemas de IA generativa (evitar sesgos, alucinaciones, filtración de propiedad intelectual, incumplimientos regulatorios).
2. La **obligación jurídica y contractual** de mantener bajo secreto absoluto los datos de los cuentahabientes, con arraigo constitucional en México (artículo 16 CPEUM) y desarrollo normativo en la LFPDPPP, la Ley Federal de Protección al Consumidor y las Circulares de la CNBV para instituciones de crédito.

Cualquier arquitectura tradicional en la que un SaaS externo reciba los prompts o las respuestas del modelo — aunque sea en tránsito y encriptado — introduce un riesgo estructural: el proveedor SaaS **puede** técnicamente ver el dato en algún punto de su procesamiento. Esta capacidad, aun cuando esté contractualmente prohibida, es inaceptable para el nivel de secreto bancario mexicano.

### 1.2 Propuesta y alcance de privacidad

IA Gobernanza ofrece controles de gobernanza con **tokenización de datos**, no una garantía universal de conocimiento cero ni una prueba criptográfica formal de zero-knowledge. Deben distinguirse dos arquitecturas:

- **SDK o Muro Perimetral en la red del cliente:** detecta y tokeniza patrones configurados antes de transmitir. El cliente controla el vault (memoria o Redis) y la rehidratación. Puede quedar PII no reconocida por los patrones; se requiere validar reglas y tráfico real.
- **Gateway alojado:** recibe el texto original antes de tokenizarlo para un proveedor externo. Mantiene un mapa cifrado efímero en Redis o Mongo; también retiene la salida completa para auditarla antes de entregarla. No garantiza que el SaaS reciba cero datos personales.

Los capítulos de flujo perimetral siguientes describen **el despliegue local del SDK/muro**, no todos los módulos del SaaS. HITL puede persistir payload y RAG puede recibir texto. Secretos, despliegue y terceros deben evaluarse por integración.

### 1.3 Beneficios y límites

| Objetivo | Respaldo y límite |
|---|---|
| Reducir exposición de datos | Tokenización de patrones detectados; no anonimización irreversible garantizada de cualquier dato |
| Controlar proveedores | Gateway y conectores con políticas; residencia declarada por configuración, no certificada |
| Proteger contenido sensible | Reglas de redacción y post-auditoría deterministas; no detección universal |
| Apoyar cumplimiento | Minimización, roles y trazabilidad como herramientas; clasificación jurídica requiere asesoría legal |
| Facilitar auditoría | Cadena de hashes y registros; no firma digital independiente ni almacenamiento WORM |

### 1.4 Verificación y conocimiento de los datos

No afirmamos incapacidad absoluta de reconstruir o correlacionar datos frente a cualquier compromiso. El mapa de tokens, las claves, los permisos y los datos persistidos varían por módulo y arquitectura. El cliente debe verificar configuración, controles operativos y retención. Consulte [Evidencia por capacidad](/trust#evidencia) para el alcance de pruebas realmente registrado.

---

## 2. Arquitectura de Flujo de Datos Perimetral

### 2.1 Diagrama de Alto Nivel

```
┌───────────────────────────── INFRAESTRUCTURA DEL BANCO ──────────────────────────────┐
│                                                                                        │
│   ┌──────────────┐    (1) prompt con PII      ┌────────────────────────┐               │
│   │ App Interna  │ ─────────────────────────▶ │  Perimeter Wall Proxy   │               │
│   │ (chatbot,    │ ◀───────────────────────── │  ─ RedactionEngine      │               │
│   │  scoring,    │    (6) respuesta final     │  ─ TokenVault (RAM)     │               │
│   │  asistente)  │        rehidratada         │  ─ PrivacyAuditor       │               │
│   └──────────────┘                            └────────┬───────────────┘               │
│                                                        │                                │
│                       ┌────────────────────────────────┤                                │
│                       ▼                                ▼                                │
│              ┌────────────────┐              ┌─────────────────┐                        │
│              │ Redis efimero  │              │ Bitacora local  │                        │
│              │ RAM only       │              │ hash-chain      │                        │
│              │ (mapping tokens│              │ (auditor CISO)  │                        │
│              │  ↔ plaintext)  │              └─────────────────┘                        │
│              └────────────────┘                                                         │
│                                                                                        │
└──────────────┬───────────────────────────────────────────────────────────────┬─────────┘
               │ (2) payload SOLO anonimizado              (5) respuesta       │
               │     + métricas numéricas                      con tokens      │
               │     via HTTPS + mTLS                                          │
               ▼                                                               ▲
        ┌──────────────────────────────────────────────────────────────────────┴──────┐
        │                     AI GUARD LATAM — SaaS Externo                            │
        │                                                                              │
        │   (3) Motor de políticas evalúa:                                              │
        │       ─ toxicidad, sesgo, alucinación (métricas)                              │
        │       ─ estructura semántica, longitud, dispersión (vectores)                 │
        │       ─ directivas legales (RAG grounded)                                     │
        │                                                                              │
        │   (4) Devuelve veredicto: APPROVED | FLAGGED | TERMINATED                     │
        │       ─ y, si aplica, "safe_response" en TÉRMINOS DE TOKENS                   │
        │                                                                              │
        └──────────────────────────────────────────────────────────────────────────────┘
```

### 2.2 Flujo Detallado de Datos

**Paso 1 — Ingreso del prompt (dentro del banco)**

Una aplicación interna del banco (por ejemplo, un chatbot de atención a cuentahabientes) recibe un mensaje del usuario final:

> "Hola, soy el cliente Juan Pérez Ramírez, mi RFC es PERJ850101ABC, quiero transferir MX$25,000 de mi tarjeta 4111 1111 1111 1111 a la CLABE 002180001234567892."

La aplicación **no** llama al SaaS directamente. En su lugar, invoca al `Perimeter Wall Proxy` corriendo en la misma red privada.

**Paso 2 — Anonimización local**

El motor de redacción ejecuta en paralelo:

| Detector | Método | Ejemplo detectado |
|---|---|---|
| `PAN` | Regex + validación Luhn | `4111 1111 1111 1111` → `[TOKEN_PAN_0E1799977E49569B]` |
| `CLABE` | Regex + dígito verificador ponderado (3,7,1) | `002180001234567892` → `[TOKEN_CLABE_...]` |
| `RFC`, `CURP`, `CPF`, `RUT` | Regex con anchors léxicos | `PERJ850101ABC` → `[TOKEN_RFC_4C83C74A5647F970]` |
| `EMAIL`, `PHONE` | Regex RFC-5322 / E.164 relajado | `juan.perez@banco.mx` → `[TOKEN_EMAIL_...]` |
| `NAME` | Heurística con títulos (Sr., Cliente, Titular…) | `Juan Pérez Ramírez` → `[TOKEN_NAME_9DBBE942EC21899D]` |
| `AMOUNT` | Regex multi-moneda | `MX$25,000` → `[TOKEN_AMOUNT_79C6B5406E23D011]` |

El mapping `{token → plaintext}` se almacena en el `TokenVault` — un `dict` protegido por lock, respaldado por Redis en modo RAM-only (`--save "" --appendonly no --maxmemory-policy allkeys-lru`, montado sobre `tmpfs` / `emptyDir medium: Memory`). Ningún byte del plaintext toca un disco físico ni virtual.

**Paso 3 — Verificación final ("mural de última milla")**

Antes de emitir cualquier byte hacia la red externa, el `PrivacyAuditor.verify_no_pii_leaked()` re-ejecuta **todos** los detectores sobre la serialización JSON completa del payload saliente. Si detecta cualquier residuo de PII, aborta la request con HTTP `451 Unavailable For Legal Reasons`. Esta verificación funciona como un test matemático de invariante: si alguna vez pasa una request al socket, existe prueba criptográfica de que no contenía PII detectable.

**Paso 4 — Emisión al SaaS**

Solo entonces el proxy emite la request a `https://api.aiguardlatam.com/api/v1/governance/evaluate` con TLS 1.3 y, si el cliente lo activa, mTLS con certificado emitido por su propia PKI corporativa.

**Paso 5 — Evaluación en el SaaS**

IA Gobernanza evalúa la request usando exclusivamente:

- **Métricas numéricas**: `bias_score`, `toxicity_score`, `semantic_drift`, `pii_detected` (boolean, ya redundante), `hallucination_confidence`.
- **Estructura semántica**: longitud, distribución de tokens, coherencia sintáctica, análisis de dependencia local.
- **Directivas legales**: agente RAG con grounding sobre corpus normativo curado (LFPDPPP, LGPDPPSO, LRITF, CNBV) — que responde en función del *concepto* expresado, no del contenido individualizado.

El SaaS emite un veredicto: `APPROVED`, `FLAGGED` o `TERMINATED`. Si emite `safe_response` (respuesta modificada por razones de seguridad), la construye con los mismos tokens que recibió — nunca genera contenido que reconstruya el dato original.

**Paso 6 — Rehidratación local**

El proxy recibe la respuesta, y usa el `TokenVault` para reemplazar los tokens por sus plaintexts asociados a la `session_id` en curso. El resultado se entrega a la aplicación interna, que lo presenta al usuario final.

**Paso 7 — Purga**

Al cerrar la sesión, o al vencer el TTL configurado (default 300 s), el mapping se elimina. Un reinicio de Redis (o del pod) borra el mapping completo en microsegundos, por diseño.

### 2.3 Superficie de Ataque desde el SaaS

Suponiendo un compromiso total del proveedor (peor caso realista):

| Adversario obtiene | ¿Puede reconstruir PII? |
|---|---|
| Todo el tráfico HTTPS interceptado | ❌ Solo verá el texto anonimizado + tokens. |
| Nuestras bases de datos completas | ❌ Nunca almacenamos plaintexts. |
| El código fuente completo de IA Gobernanza | ❌ El código no contiene la sal privada del cliente. |
| Acceso root a todos nuestros servidores | ❌ La sal vive solo en RAM del cliente. |
| Coerción a todos nuestros empleados | ❌ No podemos revelar lo que no tenemos. |
| Fuerza bruta contra los tokens SHA-256 | ❌ Espacio efectivo 2¹²⁸ + sal privada de 256 bits. |

La única forma de reconstruir un plaintext es tener simultáneamente **(a)** el token y **(b)** la sal del cliente y **(c)** un diccionario del universo de posibles plaintexts para ese tipo de dato (feasible solo para tarjetas específicas conocidas de antemano, no para nombres arbitrarios). Esta simetría rompe cualquier vector de ataque desde nuestro lado.

---

## 3. Mecanismo de Tokenización y Cifrado Local

### 3.1 Fundamento Criptográfico

La tokenización utiliza `HMAC-SHA-256` (RFC 2104) sobre la concatenación del tipo de PII y el plaintext normalizado, con la sal privada del cliente como clave HMAC:

```
token(kind, plaintext) = "[TOKEN_" || kind || "_" || HEX(HMAC-SHA256(salt_client, kind || "|" || normalize(plaintext))[:8]) || "]"
```

Donde:

- `salt_client` es una cadena aleatoria de **al menos 256 bits** generada con un CSPRNG (`openssl rand -hex 32`) y almacenada exclusivamente en un secreto de Kubernetes / HashiCorp Vault del banco.
- `normalize(x)` aplica `NFKD` → `casefold` → colapso de espacios: asegura que `"Juan Pérez"` y `"juan  perez"` mapeen al mismo token dentro del mismo tenant.
- Truncamos a 8 bytes (16 hex chars) para brevedad visual, manteniendo 64 bits de resistencia a colisión — suficiente para el universo de una sesión (< 2¹⁰ tokens).

### 3.2 Propiedades Matemáticas

**Propiedad 1 — Determinismo intra-tenant.**
Para un mismo cliente `C` con sal `S_C`, todos los `plaintexts` semánticamente idénticos producen el mismo token. Esto permite que dos menciones al mismo cuentahabiente dentro de una conversación reciban el mismo `[TOKEN_NAME_...]`, permitiendo al motor de gobernanza detectar co-referencia sin conocer identidad.

**Propiedad 2 — Aislamiento inter-tenant.**
Para dos clientes `C₁` y `C₂` con sales independientes `S_{C₁} ≠ S_{C₂}`:

```
Pr[token(kind, x, S_{C₁}) = token(kind, x, S_{C₂})] ≤ 2⁻⁶⁴
```

Un banco jamás puede correlacionar tokens con otro banco, incluso si compartiesen físicamente el mismo plaintext.

**Propiedad 3 — No invertibilidad.**
Dado un token `T` y todo el conjunto `K` de tipos de PII, sin `S_C`:

```
Pr[recuperar plaintext(T) | K] ≤ 2⁻²⁵⁶
```

Bajo el modelo estándar de HMAC-SHA-256 (asumiendo que la sal permanece secreta).

**Propiedad 4 — No enumerabilidad.**
Aun teniendo un catálogo cerrado (por ejemplo, todos los PANs Visa emitidos en México), sin la sal el atacante debe hacer 2²⁵⁶ evaluaciones para probar cada uno — computacionalmente infactible.

### 3.3 Almacenamiento Efímero

El `TokenVault` cumple con tres invariantes verificables:

1. **RAM only**. El backing store es Redis con `--save "" --appendonly no`, montado sobre `tmpfs` (Docker) o `emptyDir medium: Memory` (Kubernetes). No existe path del filesystem donde el kernel pueda flushear el mapping.
2. **TTL forzado**. Cada entrada expira automáticamente (`TOKEN_TTL_SECONDS=300` por defecto). Configurable, pero jamás mayor a la duración de la sesión de negocio.
3. **Wipe explícito**. Al cerrar una sesión (`TokenSession.close()`) el `dict` se limpia y las referencias se cortan, forzando garbage collection determinista.

**Nota sobre CPython y `str` inmutables.** Python no garantiza wipe físico de memoria porque los objetos `str` son inmutables. Para instituciones que requieran garantía criptográfica de destrucción física (Tier 4), ofrecemos un modo opcional `SecureString` (basado en `bytearray` con `ctypes.memset` posterior al uso) y encriptación AES-GCM del vault con clave rotativa cada 60 segundos. Ver Apéndice A.

### 3.4 Rotación de Salt

La sal privada puede rotarse en cualquier momento sin necesidad de coordinar con IA Gobernanza. Al rotarla:

- Los tokens previamente emitidos hacia el SaaS se invalidan naturalmente (nunca se podrían rehidratar).
- Las conversaciones activas se cierran o se recomponen con la nueva sal (política del cliente).
- El SaaS no percibe la rotación — solo ve un cambio en la distribución de hashes, indistinguible de tráfico nuevo.

---

## 4. Cumplimiento Normativo de Terceros

### 4.1 LFPDPPP — Ley Federal de Protección de Datos Personales en Posesión de los Particulares (México)

| Artículo LFPDPPP | Exigencia | Cómo la satisface IA Gobernanza |
|---|---|---|
| **Art. 6** — Principios: licitud, consentimiento, información, calidad, finalidad, lealtad, proporcionalidad y responsabilidad | Minimización estricta: solo se comparte lo necesario | El SaaS recibe métricas numéricas y texto tokenizado. **Nada más**. Cumple `proporcionalidad` en su expresión más estricta. |
| **Art. 7** — Los datos deben tratarse con confidencialidad y protegerse mediante medidas de seguridad | Confidencialidad técnica exigible | La tokenización HMAC-SHA-256 con sal exclusiva del cliente constituye una medida de seguridad de nivel "estricto" bajo los Lineamientos del INAI. |
| **Art. 19** — Adopción de medidas de seguridad administrativas, físicas y técnicas | Controles verificables | Documentados en la [Matriz de Responsabilidad Compartida](#5-matriz-de-responsabilidad-compartida). |
| **Art. 20** — Deber de notificación de vulneraciones | Notificación en 72 h | Un compromiso del SaaS **no** constituye vulneración de datos personales del cliente, pues no los posee. Reduce el ámbito de notificaciones obligatorias. |
| **Art. 36** — Transferencia de datos requiere contrato con cláusulas equivalentes | Necesidad de contrato de encargo | Al no haber transferencia de datos personales (solo derivados no-reversibles), **no aplica** el régimen de transferencia. Se documenta como "servicio de procesamiento de metadatos anonimizados". |

### 4.2 CNBV — Disposiciones de Carácter General Aplicables a las Instituciones de Crédito

**Circular Única de Bancos (CUB), Título Quinto, Capítulo X — Servicios provistos por terceros:**

- **Art. 316** obliga a las Instituciones de Crédito a evaluar riesgos de contratar servicios de tecnología con terceros.
  - **Cumplimiento IA Gobernanza**: el riesgo se reduce a "servicio de procesamiento de metadatos". El proveedor no accede a información confidencial en términos del Art. 142 LIC. Se recomienda documentar esta caracterización en el análisis de riesgo.
- **Art. 319** exige que el tercero tenga capacidad para proteger la información.
  - **Cumplimiento IA Gobernanza**: al no recibir información protegida en primer lugar, la capacidad de protección se cumple *por diseño de imposibilidad*.
- **Art. 320** exige que el tercero permita auditorías de la Comisión.
  - **Cumplimiento IA Gobernanza**: IA Gobernanza sostiene un régimen de acceso auditor a nuestra infraestructura mediante NDA, con provisión de reports SOC 2 Type II anuales. Adicionalmente, el `Perimeter Wall Proxy` corre en la infraestructura del cliente y su auditoría no requiere involucrarnos.
- **Circular 20/2024** — Ciberseguridad: obligación de detectar y contener incidentes.
  - **Cumplimiento IA Gobernanza**: el sistema mismo *es* un mecanismo de contención perimetral. Aporta a la postura ciber.

### 4.3 T-MEC — Tratado México, Estados Unidos y Canadá

- **Anexo 19-D, Comercio Digital** — libertad de flujo transfronterizo de datos con excepciones legítimas de política pública.
  - **Cumplimiento IA Gobernanza**: los datos que cruzan la frontera son anonimizados y no constituyen datos personales bajo la definición de la LFPDPPP (Art. 3, fr. V), por lo que no activan las restricciones nacionales de flujo.
- **Capítulo 19, Art. 19.11** — no exigencia de localización de datos como condición de operar, salvo por motivos regulatorios legítimos.
  - **Cumplimiento IA Gobernanza**: no requiere localización porque no procesa datos localizables. La arquitectura satisface *facto* cualquier requisito de residencia de datos.

### 4.4 ISO/IEC 27001:2022 y PCI-DSS v4.0

| Control | Descripción | Aporte IA Gobernanza |
|---|---|---|
| **ISO 27001 A.5.14** — Transferencia de información | Reglas para intercambios con terceros | La transferencia es de metadatos derivados, no de información sensible. Simplifica el control. |
| **ISO 27001 A.8.11** — Ocultación de datos (data masking) | Enmascaramiento como control preventivo | El `RedactionEngine` **es** un control de data masking implementado en la capa perimetral. |
| **ISO 27001 A.8.12** — Prevención de fuga de información | DLP como control obligatorio | El `PrivacyAuditor.verify_no_pii_leaked()` **es** un mecanismo DLP verificable matemáticamente. |
| **PCI-DSS 3.4** — El PAN debe hacerse ilegible en cualquier lugar donde se almacene | Nunca almacenado en claro | El PAN se sustituye por token antes de salir del cliente; el vault vive en RAM. Cumple 3.4.1 (hashing con sal) y 3.5.1 (protección de la clave). |
| **PCI-DSS 4.2.1** — TLS 1.2+ para transmisiones | TLS 1.3 obligatorio | Ver `Dockerfile` / manifiestos K8s. |

### 4.5 NIST SP 800-53 Rev. 5 (referencia complementaria)

- **SC-8, SC-13** — Protección de la confidencialidad y criptografía. Se usan primitivas estándar (SHA-256, HMAC-SHA256, AES-256-GCM, TLS 1.3) de OpenSSL/Node.js; la validación FIPS 140-3 del módulo depende de la plataforma de despliegue del cliente y no se afirma como propiedad del producto.
- **SI-4** — Monitoreo continuo. La bitácora encadenada del `PrivacyAuditor` cumple el objetivo con propiedad tamper-evident.
- **AC-3(9)** — Divulgación controlada. La imposibilidad técnica de divulgar excede el requisito.

---

## 5. Matriz de Responsabilidad Compartida

La siguiente matriz delimita quién controla, quién administra y quién audita cada activo del sistema. Está inspirada en el modelo AWS Shared Responsibility, adaptado al contexto Zero-Knowledge.

### 5.1 Matriz Detallada

| Componente | Cliente (Banco) | IA Gobernanza |
|---|---|---|
| **Datos crudos (PAN, CLABE, RFC, CURP, nombres, montos)** | 🟢 Control total, propiedad exclusiva | 🔴 Sin acceso técnico ni jurídico |
| **Sal privada de tokenización** (`AIGUARD_REDACTION_SALT`) | 🟢 Genera, custodia, rota, revoca | 🔴 Nunca la recibe ni la puede recuperar |
| **Mapping token ↔ plaintext (TokenVault)** | 🟢 En RAM de su servidor, TTL configurable | 🔴 Sin acceso técnico |
| **Redes internas del banco** | 🟢 Segmentación, firewalls, IDS | ⚪ N/A |
| **Perimeter Wall Proxy (imagen Docker)** | 🟡 Despliega y opera en su infraestructura | 🟢 Provee la imagen firmada, actualizaciones de seguridad |
| **Redis efímero (backing del vault)** | 🟢 Despliega, monitorea consumo de RAM | 🟢 Provee la configuración recomendada |
| **Bitácora local encadenada (audit log)** | 🟢 Consume, exporta a SIEM, comparte con reguladores | 🔴 Sin acceso |
| **Métricas numéricas (bias, toxicity, drift)** | 🟡 Genera desde el proxy | 🟢 Recibe, procesa, indexa |
| **Texto anonimizado (payload saliente)** | 🟡 Genera; el `PrivacyAuditor` verifica ausencia de PII | 🟢 Recibe, evalúa políticas |
| **Políticas de gobernanza (marco regulatorio activo)** | 🟢 Define su marco (LFPDPPP Base 2026, CNBV Circular X…) | 🟢 Ejecuta el motor de reglas y mantiene el corpus RAG |
| **Corpus normativo del RAG** | ⚪ N/A | 🟢 Cura, versiona, firma digitalmente |
| **API Keys del SaaS** (`gov_live_*`) | 🟢 Genera desde el dashboard, controla scopes | 🟢 Verifica hash SHA-256, aplica rate limit |
| **Alertas y notificaciones** (Slack/Teams/Email) | 🟢 Configura destinos, secretos HMAC | 🟢 Dispara con firma HMAC-SHA-256 |
| **Kill Switch de modelos** | 🟢 Ejecuta acciones locales al recibir señal | 🟢 Propaga la orden por webhook firmado |
| **Auditorías regulatorias (CNBV, INAI)** | 🟢 Lidera; puede requerirnos evidencia | 🟢 Provee SOC 2 Type II, evidencia arquitectónica |

**Leyenda**: 🟢 responsable primario · 🟡 responsable compartido · 🔴 sin acceso ni responsabilidad · ⚪ no aplica

### 5.2 Boundary Diagram

```
┌────────────────────────────────────────────────────────────────────────────┐
│                      DOMINIO DE CONTROL DEL BANCO                            │
│  ┌─────────────────────────────────────────────────────────────┐             │
│  │           Datos crudos + Sal privada + Vault RAM              │             │
│  │           + Bitácora encadenada + Redes internas              │             │
│  └───────────────────────┬─────────────────────────────────────┘             │
│                          │  emite solo derivados no-reversibles                │
│                          ▼                                                    │
└──────────────────────────┼────────────────────────────────────────────────────┘
                           │  HTTPS + TLS 1.3 + mTLS opcional
┌──────────────────────────┼────────────────────────────────────────────────────┐
│                          ▼                                                    │
│                    DOMINIO DE CONTROL DE AI GUARD LATAM                        │
│                                                                              │
│  Motor de políticas · RAG normativo · Kill switch orchestration ·             │
│  Bitácora agregada · Panel corporativo · Notificaciones multicanal            │
└──────────────────────────────────────────────────────────────────────────────┘
```

### 5.3 SLA y Reportes

- **Disponibilidad objetivo del SaaS**: 99.9 % mensual (excluyendo mantenimientos anunciados con 72 h). El uptime **medido** se publica en `/status` y `GET /api/public/status`; los créditos se describen en `/legal/sla`.
- **Certificaciones y atestaciones**: a la fecha **no existe** reporte SOC 2 ni certificación ISO. La hoja de ruta (gap-analysis ISO/IEC 42001, SOC 2 Type I) está publicada en el Trust Center. No entregamos documentos que no existen.
- **Pruebas de penetración**: pendientes de contratación con firma independiente antes del primer cliente en producción; el resumen ejecutivo se publicará en `/trust`.
- **RTO / RPO objetivo**: 15 min / 5 min (pendientes de validación con simulacro documentado). El cliente conserva `fail_closed`/`fail_open` en el SDK/Muro para decidir si opera degradado.

---

## 6. AI Threat Shield — Defensa contra IA maliciosa

### 6.1 Alcance y límites (declaración honesta)

Los adversarios ya emplean LLMs para generar, mutar y lanzar miles de prompts maliciosos por minuto contra asistentes, copilotos y agentes corporativos. **AI Threat Shield** es la capa de detección y respuesta de IA Gobernanza frente a esos ataques **en la capa de IA** del cliente, alineada a *OWASP Top 10 for LLM Applications 2025* y a las técnicas de *MITRE ATLAS*.

| Sí cubre | No cubre (y no lo afirmamos) |
|---|---|
| Prompt injection directa e indirecta (LLM01) | Intrusiones de red, malware, ransomware |
| Jailbreak / escalada de rol (LLM01) | Phishing o deepfakes dirigidos a personas |
| Fuga de system prompt (LLM07) | Fraude transaccional fuera del canal de IA |
| Exfiltración de datos vía la salida del modelo (LLM02) | Vulnerabilidades de la infraestructura del cliente |
| Sondeo automatizado y extracción de modelo (LLM10) | Sustitución de SIEM, EDR, WAF o IDS |

El escudo **se integra** con el SOC del cliente (webhooks firmados, campos OCSF) — no lo sustituye.

### 6.2 Alcance de la respuesta ante amenazas

Threat Shield bloquea solicitudes detectadas y registra incidentes. No sustituye la protección de red ni garantiza detectar todos los ataques. Su comportamiento debe distinguirse del Gateway:

| Camino | Comportamiento |
|---|---|
| Detector Threat Shield | Bloqueo de request + incidente + webhook; no dispara directamente el kill-switch |
| Gateway con modelo vinculado | Amenazas persistentes pueden alimentar el motor de riesgo y activar el kill-switch; fugas críticas de salida pueden dispararlo directamente |
| Motor de gobernanza | Regla crítica inmediata **o** confianza y persistencia según políticas y circuit breaker; no siempre tres capas simultáneas |

El modo `alert` registra, el modo `block` bloquea tráfico integrado. Ninguno apaga un proceso externo que ignore el control. Las respuestas del Gateway se retienen completas antes de la auditoría: JSON o SSE diferido, no texto token a token. SSE incompleto se rechaza.

### 6.3 Detectores deterministas (Capa 1)

Nueve patrones con peso de confianza, evaluados sobre una **forma normalizada** del texto para resistir evasiones habituales:

1. Eliminación de caracteres de ancho cero (`U+200B…U+200F`, `U+2060`, `U+FEFF`).
2. Normalización Unicode NFKC (fullwidth, ligaduras, homoglifos).
3. Decodificación de blobs base64 ≥ 24 caracteres y anexado del contenido decodificado al escaneo.
4. Variante *leetspeak* → letras (`1gn0r4` → `ignora`).
5. Colapso de separadores intra-palabra (`i.g.n.o.r.a`).

| Detector | Peso | Técnica |
|---|---|---|
| `ignore_instructions`, `reveal_system_prompt` | 0.9 | AML.T0051 |
| `dan_jailbreak` | 0.8 | AML.T0054 |
| `exfil_instruction` | 0.8 | AML.T0024 |
| `role_override`, `dump_data` | 0.7 | AML.T0054 / AML.T0024 |
| `delimiter_injection`, `tool_abuse` | 0.6 | AML.T0051 |
| `encoded_payload` | 0.5 (+0.15 si se decodificó payload) | AML.T0051 |

`injection_score` y `jailbreak_score` ∈ [0, 1]. Umbral de bloqueo por defecto: **0.6** (configurable por política: `policy_rules.injection_threshold`). Un solo patrón de alta confianza basta para bloquear; los de baja confianza requieren combinación. Los mismos patrones están implementados en el SDK (`aiguard.threats`) para que la **ruta Zero-Knowledge de sólo métricas** también quede protegida sin enviar texto.

### 6.4 Huella de system prompt (LLM07)

El cliente registra su system prompt una sola vez (`POST /api/models/{id}/system-prompt-fingerprint`). El servidor calcula *shingles* de 5 palabras y almacena únicamente `sha256(shingle)[:16]`; **el texto se descarta**. Alternativamente el cliente envía los shingles ya calculados con `aiguard.prompt_shingles()` (Zero-Knowledge total). En cada salida (`OUTPUT`) se calcula el solapamiento: ≥ 6 shingles o ≥ 20 % de la huella → `SYSTEM_PROMPT_LEAK`, request bloqueada.

### 6.5 Análisis de comportamiento por identidad (`user_ref`)

Cada evaluación deja una **señal durable** (`threat_signals`, TTL 2 h) con: marca de tiempo, esqueleto del prompt (dígitos y literales sustituidos, hasheado), si hubo amenaza/violación y tokens PII emitidos. Sobre una ventana de 60 s por `user_ref`:

| Señal | Umbral por defecto | Amenaza | Técnica |
|---|---|---|---|
| Ráfaga | ≥ 30 requests/min | `AUTOMATED_PROBING` | AML.T0043 |
| Tasa de violación | ≥ 8 requests y ≥ 50 % con amenaza/violación | `AUTOMATED_PROBING` | AML.T0043 |
| Plantillas repetidas | ≥ 40 requests y ≤ 35 % de esqueletos distintos | `MODEL_EXTRACTION_SUSPECTED` | AML.T0024.002 |
| Tokens PII en una salida | ≥ 5 | `DATA_EXFILTRATION_ATTEMPT` | AML.T0024 |
| Tokens PII acumulados | ≥ 20 en la ventana | `DATA_EXFILTRATION_ATTEMPT` | AML.T0024 |

### 6.6 Respuesta, evidencia e integración SIEM

- **Bloqueo**: `status = BLOCKED`, `action = ACTION_BLOCK_REQUEST`, `trigger_killswitch = false`, `threats.types[]`.
- **Incidente** `THREAT_DETECTED` con `threat_type`, `severity`, `mitre_atlas`, `owasp_llm`, `user_ref`, `payload.prompt_hash` (SHA-256 del texto), scores y patrones. **Nunca el texto.** Deduplicación por (empresa, `user_ref`, tipo) durante 10 min con contador `occurrences`.
- **Webhook** `threat.detected` firmado (v2, ver §7.3) con bloque `ocsf` (`class_uid 2004 — Detection Finding`) para Splunk, Microsoft Sentinel o IBM QRadar.
- **Panel** «AI Threat Shield» en el dashboard: resumen 24 h, distribución por tipo, actores principales, reconocimiento y resolución con firma del operador en la bitácora.
- **Simulación red-team** (`POST /api/threats/simulate`, sólo en entorno de demostración): seis escenarios reales (inyección directa, DAN, base64, volcado de datos, exfiltración por tokens, prompt legítimo de control).

### 6.7 Limitaciones conocidas

- La Capa 1 es determinista: ataques semánticamente novedosos sin marcadores léxicos pueden no detectarse. Un clasificador ML de intención adversaria está en la hoja de ruta y se declarará como tal hasta estar en producción.
- El análisis de comportamiento depende de que el cliente envíe un `user_ref` estable por usuario o sesión.
- El escudo observa lo que pasa por el SDK/Muro; tráfico que evada la integración no es visible (el Dead Man's Switch alerta la pérdida de visibilidad).

---

## 7. Integridad Operativa: Autenticación, Auditoría, Webhooks y Multi-tenancy

### 7.1 Autenticación y control de acceso del plano de control

- Operadores con contraseña `bcrypt(12)` y sesión JWT HS256 en cookie `httpOnly; SameSite=Lax` (≤ 8 h). Revocación inmediata mediante `session_version`.
- RBAC de tres niveles: `viewer` (lectura), `operator` (disparar kill-switch, simular, reconocer incidentes), `admin` (políticas, modelos, claves, usuarios, **desactivar** kill-switch con motivo obligatorio).
- Toda ruta del plano de control exige sesión; las rutas de máquina usan API key con *scopes* (`X-API-Key`) o *session token* de corta vida. El contrato del SDK (`/v1/governance/evaluate`) valida la credencial y el tenant del modelo.
- Rate-limit distribuido (contadores atómicos con TTL) en login, formulario público y API.

### 7.2 Bitácora tamper-evident

Cada evento (`auth.login`, `killswitch.triggered`, `killswitch.deactivated`, `policy.*`, `threats.*`, `rbac.denied`, …) se serializa en JSON canónico y se encadena: `hash = SHA-256(prev_hash ‖ canonical(evento))`, con secuencia única y escritura bajo *lock* distribuido. `GET /api/audit/verify-chain` recalcula toda la cadena; el estado de la cola se publica en `/status`.

### 7.3 Webhooks firmados con protección anti-replay (v2)

`X-Hub-Signature-256 = sha256=HMAC(secret, "{timestamp}.{nonce}.{body}")`, con `X-AIGuard-Timestamp` (±300 s), `X-AIGuard-Nonce` único (memoria de 15 min) y comparación en tiempo constante. Entregas no verificadas se rechazan (401) y no se persisten. Guía para el SOC: `/docs/WEBHOOKS.md`.

### 7.4 Zero-Knowledge fail-closed

Si el SaaS detecta PII en claro en `text_payload`, la evaluación de gobernanza se ejecuta (el kill-switch sigue protegiendo) pero la petición se rechaza con `422 PII_PLAINTEXT_REJECTED`, se abre incidente `PII_PLAINTEXT_INGRESS` (sólo hash) y se notifica al SOC. Los tokens `[TOKEN_<TIPO>_<HASH>]` producidos por el SDK/Muro se aceptan y se contabilizan.

### 7.5 Aislamiento multi-tenant

El `company_id` se deriva siempre de la sesión o de la API key; toda consulta por identificador se filtra por tenant (acceso a recursos ajenos → `404`). El estado de seguridad (ventanas anti-falso-positivo, circuit breaker, liveness, nonces, señales de amenaza) es durable y compartido entre instancias (TTL), no reside en memoria de proceso.

### 7.6 Transporte y Muro Perimetral

SDK `aiguard` 0.2: `https://` obligatorio, `ca_bundle` para CA privada y `client_cert` para mTLS opcional; `verify=False` bloqueado fuera de desarrollo. El Muro Perimetral exige `X-Wall-Token` (comparación en tiempo constante) en producción y puede usar un vault Redis **efímero** compartido entre réplicas, cifrado AES-256-GCM, con verificación de que la persistencia (RDB/AOF) está deshabilitada.

---

## 8. Apéndices Técnicos

### Apéndice A — Modo de Alta Seguridad ("Secure String")

Para instituciones que requieran destrucción física verificable de la memoria (Tier 4 / clasificación militar), se activa vía:

```yaml
env:
  - name: VAULT_MODE
    value: "SECURE_STRING_AES_GCM"
  - name: VAULT_KEY_ROTATION_SECONDS
    value: "60"
```

En este modo:

1. Cada `plaintext` se almacena como `bytearray` encriptado con AES-256-GCM.
2. La clave AES se rota cada 60 segundos; la anterior se sobreescribe con `ctypes.memset`.
3. Al `close()` la sesión, el `bytearray` se sobreescribe byte a byte antes de descartarse.
4. Overhead adicional: +2 ms de latencia p95.

### Apéndice B — Verificación Matemática de No-Fuga

El `PrivacyAuditor.verify_no_pii_leaked(payload)` puede ejecutarse como test de invariante en CI/CD:

```python
def test_no_pii_ever_leaves():
    engine  = RedactionEngine(salt="test-salt")
    auditor = PrivacyAuditor(engine=engine, strict=True)
    for prompt in load_corpus_of_1M_realistic_prompts():
        r = engine.redact(prompt)
        payload = build_saas_payload(r)
        auditor.verify_no_pii_leaked(payload)   # aborta si detecta
    # Al terminar sin excepción: prueba estadística de invariante
```

Este test se ejecuta como parte del pipeline de CI del cliente y su output se firma con la clave privada del CISO como evidencia auditable.

### Apéndice C — Contactos y Responsables

- **Escalación de seguridad**: `security@aiguardlatam.com` (PGP: `0xAABB...`)
- **Ingeniería de privacidad**: `privacy-eng@aiguardlatam.com`
- **Cumplimiento regulatorio**: `compliance@aiguardlatam.com`
- **Ventas y contratación**: `enterprise@aiguardlatam.com`

### Apéndice D — Referencias Normativas

- OWASP Top 10 for Large Language Model Applications, v2025 — https://genai.owasp.org
- MITRE ATLAS (Adversarial Threat Landscape for AI Systems) — https://atlas.mitre.org
- NIST AI RMF 1.0 (AI 100-1) e ISO/IEC 42001:2023 — marcos de gestión de riesgos de IA


1. **LFPDPPP** — Ley Federal de Protección de Datos Personales en Posesión de los Particulares. Diario Oficial de la Federación, 5 de julio de 2010.
2. **LGPDPPSO** — Ley General de Protección de Datos Personales en Posesión de Sujetos Obligados. DOF, 26 de enero de 2017.
3. **LRITF** — Ley para Regular las Instituciones de Tecnología Financiera. DOF, 9 de marzo de 2018.
4. **CNBV — Circular Única de Bancos**. Disposiciones de carácter general aplicables a las instituciones de crédito. Actualización enero 2022.
5. **T-MEC — Anexo 19-D**. Comercio Digital.
6. **ISO/IEC 27001:2022** — Information security, cybersecurity and privacy protection — Information security management systems.
7. **PCI-DSS v4.0** — Payment Card Industry Data Security Standard.
8. **NIST SP 800-53 Rev. 5** — Security and Privacy Controls for Information Systems and Organizations.
9. **RFC 2104** — HMAC: Keyed-Hashing for Message Authentication.
10. **FIPS 180-4** — Secure Hash Standard (SHA).

---

**Fin del documento.**

> *Este whitepaper es propiedad intelectual de IA Gobernanza y se distribuye bajo licencia comercial. Su reproducción parcial con fines de análisis regulatorio interno del cliente está autorizada. Cualquier reproducción pública requiere autorización expresa del área legal.*

*Versión 1.0 — Junio 2025. Próxima revisión programada: Diciembre 2025.*