# What we prove

```json
{"@context":"https://schema.org","@type":"WebPage","name":"Lo que demostramos \u2014 Mnemom","description":"Las Alignment Cards son la especificaci\u00f3n de intenci\u00f3n. La proof chain es el enlace de ejecuci\u00f3n. Firmadas con Ed25519, encadenadas por hash, agn\u00f3sticas al modelo \u2014 la respuesta zona-neutra a \u00ab\u00bfdemostrar qu\u00e9, exactamente?\u00bb.","url":"https://www.mnemom.ai/es/what-we-prove","inLanguage":"es-ES","dateModified":"2026-06-08","publisher":{"@type":"Organization","@id":"https://www.mnemom.ai#organization","name":"Mnemom","url":"https://www.mnemom.ai"}}
```

```json
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://www.mnemom.ai/es"},{"@type":"ListItem","position":2,"name":"\u00bfDemostrar qu\u00e9, exactamente?","item":"https://www.mnemom.ai/es/what-we-prove"}]}
```

Para equipos regulados

# ¿Demostrar qué, exactamente?

Los logs de auditoría demuestran que un agente hizo algo. Eso no basta cuando un solo tropiezo cuesta 10 M$ y un regulador pide evidencia. Mnemom vincula lo que el agente estaba autorizado a hacer a lo que realmente hizo — criptográficamente, a través de cada modelo, en cada llamada.

[Leer la spec de la card](https://docs.mnemom.ai/concepts/alignment-cards)[Ver lo que filtramos](/es/security)

Especificación de intención

### Alignment Cards

Una Alignment Card es un contrato firmado: el alcance dentro del cual un agente está autorizado a operar, expresado de manera lo bastante estructural para que una máquina lo aplique y lo bastante clara para que un CISO lo firme.

-   Intención declarada
    
    Lo que este agente está autorizado a hacer, en lenguaje claro y en forma estructurada firmada.
    
-   Herramientas y scopes permitidos
    
    Superficie callable exacta. Nada fuera de la card es alcanzable en runtime.
    
-   Límites de datos
    
    Lo que el agente puede leer, lo que nunca debe escribir y qué zonas están fuera de alcance.
    
-   Contrato de escalado
    
    Cuándo el agente debe ceder a un humano — y qué evidencia debe aportar.
    
-   Obligaciones de cumplimiento
    
    Vínculos con artículos del EU AI Act, roles HIPAA, cláusulas de retención sectoriales.
    
-   Presupuesto de drift
    
    Cuánto se permite al agente desviarse del comportamiento base antes de que AIP dispare.
    

Enlace de ejecución

### La proof chain

Cada ejecución produce una cadena de evidencias firmadas. Cada eslabón atestigua una parte distinta de la ejecución del agente, vinculada al hash de la card y provista de pruebas de inclusión Merkle para verificación por terceros.

1.  1
    
    Hash de la card
    
    La intención declarada, huellada y firmada.
    
2.  2
    
    Atestación de entrada
    
    Cada mensaje, resultado de herramienta y documento recuperado que alcanzó al agente.
    
3.  3
    
    Traza de decisión
    
    Checkpoints de razonamiento, evaluaciones de política y veredictos front-door — secuenciados y firmados.
    
4.  4
    
    Ledger de llamadas a herramientas
    
    Cada invocación de herramienta, argumentos y respuesta — vinculados al scope permitido por la card.
    
5.  5
    
    Certificado de salida
    
    La respuesta final del agente, filtrada por back-door, firmada con Ed25519, vinculada al árbol Merkle de la ejecución.
    

## Card en entrada. Prueba en salida.

La card es la pregunta que hace el regulador. La prueba es la respuesta que su agente ya produjo — firmada, con marca de tiempo, verificable de forma independiente.

Paso 1

Hash de la card

Paso 2

Atestación de entrada

Paso 3

Traza de decisión

Paso 4

Ledger de llamadas a herramientas

Paso 5

Certificado de salida

Cada eslabón firmado con Ed25519 · vinculado al árbol Merkle con pruebas de inclusión · exportable como evidencia para reguladores, auditores y underwriters.

## Cuatro pruebas que los reguladores piden de verdad.

«Lo logueamos» no es una prueba. Estas sí.

### Demuestre que el agente hizo lo que la card declaraba.

Cada respuesta está vinculada criptográficamente al hash de la card. Si la ejecución diverge de la intención, la prueba no se verifica.

### Demuestre que no se llamó a ninguna herramienta no autorizada.

Cada intento de llamada a herramienta del agente queda registrado frente al scope declarado de la Alignment Card. Las llamadas fuera de alcance producen una violación de frontera en la traza firmada.

### Demuestre que no se filtraron datos regulados.

El filtrado back-door evalúa cada salida contra patrones de PII/PHI/secretos; el veredicto se firma junto con la salida. Una fuga sin redactar no puede producir un certificado válido.

### Demuestre que al agente no se le indujo por prompt injection a cumplir.

Los veredictos front-door sobre cada mensaje entrante forman parte de la traza de decisión. Una injection que el agente siguió es visible en la cadena; una que bloqueó, también.

Postura zona-neutra

## Por qué los proveedores de modelos no pueden demostrárselo.

La confianza en agentes es un problema transversal a proveedores. Un plano de confianza construido dentro de un laboratorio frontera está estructuralmente en conflicto — y estructuralmente incompleto.

### La confianza tiene que cruzar proveedores.

Una Fortune 500 no corre sobre un solo modelo. Claude, GPT, Gemini, Llama open-weights — todos en producción, muchas veces en el mismo workflow. Un plano de confianza construido por un solo vendor de modelos es estructuralmente incapaz de atestiguar a los demás.

### Los incumbentes no pueden arbitrar.

Los proveedores de modelos tienen interés en cada veredicto. La verificación zona-neutra — el mismo estándar de evidencia aplicado a cada modelo, por una parte sin modelo propio — es la única postura que un regulador acreditará.

### Las cards son portables; los modelos no.

Una Alignment Card viaja con el agente a través de proveedor, versión y runtime. La proof chain es válida tanto si el modelo subyacente se reemplaza mañana, dentro de seis meses o nunca.

Enforcement en runtime

## Mnemom AEGIS es el runtime que convierte estas pruebas criptográficas en decisiones de enforcement.

La proof chain produce evidencia firmada. AEGIS es la capa de protección que actúa sobre ella — en cuatro checkpoints, por cada gateway de la red, con Managed Rules firmadas que portan un objetivo SLO de propagación multi-tenant P95 por debajo de 30 segundos.

1

### AAP — Alignment Card

Declara la identidad del agente, los límites de autonomía y los compromisos de auditoría. Pública en /.well-known/alignment-card.json.

2

### AIP — IntegrityCheckpoint

Verifica el razonamiento del agente en vuelo. Verdict: clear, review-needed o boundary-violation, con evidencia thinking-block hasheada SHA-256.

3

### CLPI — Gobernanza + recibo

Gobierna el ciclo de vida de la card a lo largo de cinco fases y ancla los Trust Ratings en Base L2 para verificación independiente.

4

### Mnemom AEGIS — Cadena de evaluación

Filtra cada transacción en cuatro checkpoints × cuatro modes; firma las Managed Rules multi-tenant que actúan sobre la imagen integrada. El runtime, la red y el recibo.

Construcción honesta: AAP lo declara. AIP lo verifica en vuelo. CLPI gobierna su ciclo de vida y ancla la evidencia on-chain. AEGIS firma las defensas multi-tenant que actúan sobre ella.

[Ver el learning network](/es/learning-network)

## La card es el contrato. La cadena es el recibo.

Conecte sus agentes a Mnemom. Pase una card firmada. Obtenga una respuesta verificable cada vez que actúan.

[Empezar en el tier base](/es/pricing)[Quickstart](https://docs.mnemom.ai/quickstart)[Ver el flywheel](/es/learning-network)

---
_Source: /es/what-we-prove/index.html · Generated by build-markdown-mirrors.mjs · For agent-readability commitment #4 see https://www.mnemom.ai/for-agents_
