# Qué revisa tu cliente antes de mandarte sus datos

> Un despliegue confidencial que nadie verifica es un despliegue común con costo extra. Esta es la lista que corre una contraparte seria, lo que tu lado tiene que publicar para pasarla, y los límites que conviene decir vos antes de que los pregunten.

2026-09-20 · https://synsema.com/es/blog/que-revisa-tu-cliente-antes-de-mandarte-sus-datos


"Lo corremos en un TEE" es una afirmación. Del otro lado de la mesa hay alguien cuyo trabajo es convertir afirmaciones en comprobaciones, y va a hacer tres preguntas: *qué código está corriendo, quién lo dice, y qué hace ese código con mis datos.*

La buena noticia es que las tres tienen respuesta mecánica. El trabajo es publicarlas antes de la reunión y no durante.

## La lista que corren

**1. Traer la identidad.** Un servicio atestiguado publica `GET /.well-known/attestation`: el documento firmado por la plataforma, la clave pública, el hash del programa y el hash de la configuración bajo la que corre.

**2. Verificar el documento.** Firma, cadena de certificados hasta la raíz de la plataforma, ventana de validez — fallando cerrado en la primera duda. Con Synsema en el cliente es una sola llamada, con el reloj pasado explícitamente en vez de leído del anfitrión:

```synsema
let v be attestation_verify(bytes(seen["document"], "base64"),
    {"format": seen["format"], "now": floor(now()),
     "expect": {"measurements": {"pcr0": PINNED}}})
```

**3. Recalcular la atadura.** El documento se compromete con `sha256(clave_pública ‖ program_sha ‖ config_sha)`. Un documento que verifica pero ata *otra* clave u otro programa no vale nada; una clave que coincide pero no tiene documento es apenas una clave. El orden importa: verificar, recalcular, comparar y **recién ahí** mandar.

**4. Leer la configuración.** `config` lleva el techo bajo el que corrió el programa, si las etiquetas de flujo de información estaban prendidas, el perfil, y si la clave anunciada es la que termina el TLS. Su hash está dentro del payload firmado, así que no se puede atestiguar una configuración endurecida y servir una floja.

**5. Preguntar qué sale.** Esta es la pregunta que el hardware no responde, y la que decide el trato. `synsema code check --json` lista cada `declassify` del programa con su línea y la oración que escribió quien lo programó:

```json
"declassify": [
  {"line": 11, "reason": "the yes/no is what the lender asked for; the score stays inside"}
]
```

Una entrada, una oración, aplicada en tiempo de ejecución: todo lo demás que sea privado se rechaza en la respuesta, en el log y en el archivo — antes de que el efecto ocurra.

## Qué publica tu lado

Poné estas cuatro cosas donde un desconocido pueda encontrarlas sin preguntarte:

- **El `program_sha`** de la versión, y la **medición esperada de la plataforma** (PCR0 en Nitro, MRTD/RTMRs en TDX, `measurement` en SEV-SNP) tomada del propio paso de construcción de la plataforma.
- **La procedencia del motor.** `gh attestation verify synsema-linux-x86_64 --repo kitecosmic/synsema` responde con el workflow, el commit y el tag que produjeron esos bytes exactos. Atestiguar un programa ejecutado por un intérprete de origen desconocido atestigua la mitad equivocada, y quien revisa bien lo sabe.
- **La lista de desclasificaciones** de la versión que estás corriendo, en palabras.
- **Un verificador que puedan correr** — veinte líneas, sin SDK, sin cuenta.

Una página con esas cuatro cosas vale más en una conversación de compras que cualquier cantidad de prosa sobre aislamiento por hardware.

## Los límites — decilos primero

Marcar vos mismo el borde es lo que separa una afirmación de ingeniería de una de marketing, y quien revisa lo nota:

- **Una atestación prueba qué código corre, no que el código sea bueno.** Por eso mismo la lista de desclasificaciones va al lado.
- **No impide que el operador niegue el servicio, descarte un pedido o apague la máquina.** Confidencialidad y disponibilidad son propiedades distintas.
- **Los canales laterales no los cubre una firma.** Tiempos, tamaños y la cantidad de líneas que imprime un programa filtran, y por eso el lenguaje trata un print dentro de una rama que dependió de datos privados como una violación en vez de redactarlo — pero nadie debería afirmar que la clase está cerrada.
- **El soporte de verificación varía por plataforma.** Hoy Synsema verifica documentos de Nitro contra la raíz de AWS fijada; los quotes de TDX y SEV-SNP los produce el motor y se verifican con el material del fabricante del lado del cliente. Decile a la contraparte cuál de los dos le toca.

## Quién pide esto

El patrón se repite en industrias que no se parecen en nada:

- **Salas limpias de datos** — dos empresas cruzan sus listas de clientes y cada una ve solamente la intersección.
- **IA confidencial** — un hospital corre el modelo de un tercero sobre registros que el proveedor no debe retener, y los pesos del proveedor tampoco quedan legibles.
- **Custodia y firma** — una clave que puede usarse y nunca exportarse, con cada uso registrado.
- **Matching privado** — órdenes que se cruzan sin que nadie vea el libro antes del cruce.

Son la misma arquitectura: un programa chico, datos que nadie de afuera puede leer, y un valor que sale con un motivo adosado.

## Por dónde empezar

Construí primero la versión chica: una ruta, una decisión, las etiquetas prendidas, un documento de identidad y el verificador en manos de un cliente amigo. Todo lo demás — el sitio, el alta, el panel, los jobs, la facturación — es trabajo de producto común que va afuera de la caja, y se despliega acá con un comando.

La referencia del lado del motor es [Atestación](https://synsema.dev/es/0.6.x/24-attestation) y [Etiquetas de flujo de información](https://synsema.dev/es/0.6.x/23-labels).