Todos los proveedores de LLM dicen que sus datos están "cifrados". Casi ninguno le dice frente a quién. TLS cifra su prompt frente al wifi de la cafetería, no frente al proveedor. "Cifrado en reposo" protege contra un disco robado, no contra la plataforma que lee su propia base de datos. Si envía contratos, notas médicas o código fuente sin publicar a través de una API de inferencia, la pregunta que importa es más concreta: ¿quién, en algún momento de la vida del trabajo, tiene a la vez sus datos y la clave que los abre?
Este artículo responde a esa pregunta para los trabajos cifrados de MicroDC.ai, con precisión. Sin vaguedades y sin afirmaciones que no podamos respaldar con las rutas de código reales.
Algo que ningún proveedor puede evitar.
Aclaremos esto primero, porque es la idea equivocada más común que escuchamos: el modelo tiene que ver el texto en claro. Un LLM calcula sobre tokens; no existe ningún esquema de cifrado homomórfico que ejecute un transformer de 70 mil millones de parámetros sobre texto cifrado a una velocidad práctica. Quien insinúe que su modelo lee prompts cifrados le está vendiendo algo que no existe.
Así que la verdadera pregunta de diseño no es "¿puede el modelo evitar ver los datos?" (no puede, en ningún sitio, en ninguna plataforma), sino "¿qué tan pequeño podemos hacer el círculo de máquinas que alguna vez tienen el texto en claro, y cómo mantenemos todo lo que está fuera de ese círculo criptográficamente ciego?" Nuestra respuesta: el círculo son exactamente dos máquinas. La suya, y un worker gestionado por MicroDC sin ninguna ruta de red externa para sus datos.
El reparto de claves.
Un trabajo cifrado involucra tres claves. Tenerlas claras hace que todo lo demás resulte evidente.
- Su par de claves RSA. Generado por el cliente de Python en su máquina, de 4096 bits por convención de la plataforma. La clave pública viaja con el trabajo; la clave privada nunca sale de su máquina. Nunca. No tenemos ningún endpoint que pueda recibirla.
- La clave de carga. Una clave AES-256, generada en su máquina, usada con AES-256-GCM (IV de 96 bits) para cifrar la carga de la solicitud antes de transmitirla.
- La clave de resultado. Una clave AES-256 completamente nueva generada en el worker, por cada trabajo, usada una sola vez para cifrar el resultado, luego envuelta con su clave pública RSA mediante OAEP (SHA-256) y descartada.
Paso a paso: la vida de un trabajo cifrado.
1. Su máquina cifra.
Antes de que la solicitud salga de su proceso, el cliente cifra la carga (mensajes, documentos, todo lo sensible) con la clave de carga bajo AES-256-GCM. GCM es cifrado autenticado: cualquier manipulación del texto cifrado en tránsito o en reposo es detectable, no solo ilegible. El envío del trabajo lleva el texto cifrado, el IV y su clave pública RSA.
2. El servidor almacena texto cifrado y enruta a ciegas.
La plataforma almacena la carga cifrada como un blob opaco. No inspecciona su contenido para enrutar, y por diseño no podría hacerlo de forma útil: los trabajos cifrados se enrutan automáticamente al nivel de contexto más alto porque el servidor ni siquiera puede ver la longitud de su prompt. El contenido de los trabajos nunca se escribe en los registros; nuestras rutas de registro omiten explícitamente los campos de carga cuando un trabajo está marcado como cifrado.
La clave de carga se custodia en el servidor junto al trabajo, con un único propósito: entregarla al worker que reclame el trabajo. Volveremos sobre esto, porque es la parte del diseño que merece escrutinio.
3. Solo los workers gestionados pueden reclamar.
MicroDC.ai es un mercado distribuido: operadores de la comunidad ejecutan la mayor parte de la flota. Los trabajos cifrados nunca tocan ese grupo. Un worker solo es elegible para trabajo cifrado cuando su capacidad encryption ha sido tanto aprobada por un administrador de la plataforma como confirmada por el worker en tiempo de ejecución. Se requieren ambos indicadores; cualquiera de ellos por sí solo enruta cero trabajos cifrados. En la práctica, esta capacidad se concede exclusivamente a workers que MicroDC opera de extremo a extremo: hardware que controlamos, imágenes que construimos, nodos que supervisamos.
Los workers sin la capacidad no es solo que no logren reclamar trabajos cifrados: el programador filtra por completo los trabajos cifrados de su lista de trabajos disponibles. Nunca ven que el trabajo existe. Y si un worker no aprobado intenta reclamar uno de todos modos, la reclamación se rechaza en el servidor: la comprobación de elegibilidad se ejecuta de nuevo en el momento de reclamar, no solo al listar.
4. El worker descifra en memoria y ejecuta localmente.
Al reclamar, el worker recibe la clave de carga y el IV, descifra la carga en memoria y ejecuta la inferencia contra un modelo alojado en esa máquina; los motores de inferencia en sí no saben nada del cifrado: ven un prompt normal en texto claro que nunca existió fuera de la RAM. El prompt descifrado nunca se envía a una API de terceros, nunca pasa por otro servicio intermedio, nunca se escribe en disco en texto claro. Los registros del worker guardan solo tamaños y metadatos, nunca material de claves, cargas descifradas ni resultados en claro. El modelo que lee su prompt es silicio que gestionamos nosotros, en la misma máquina que hizo el descifrado.
5. El resultado se cifra para usted, y solo para usted.
Este es el eslabón más fuerte de la cadena. El worker genera una clave AES-256 nueva de un solo uso y un IV aleatorio de 96 bits, cifra el resultado con ellos, envuelve esa clave con su clave pública RSA (RSA-OAEP, MGF1 + SHA-256) y envía el paquete. Desde ese momento, el resultado es legible por exactamente una clave en el mundo: la clave privada que está en su máquina.
La construcción híbrida no es una preferencia de diseño: es obligatoria. RSA no puede cifrar datos en volumen: una clave de 4096 bits tiene un límite de 446 bytes por operación OAEP-SHA-256. Así que RSA sella únicamente la clave de resultado de 32 bytes, y esa clave cifra el resultado de tamaño arbitrario. La clave envuelta viaja dentro del propio blob del resultado:
encrypted_output = base64(
<4-byte big-endian uint: length of wrapped_key>
<wrapped_key: RSA-OAEP(MGF1+SHA-256) of the 32-byte AES key>
<ciphertext: AES-256-GCM(result JSON), 16-byte GCM tag appended>
)
result_iv = base64(<12-byte GCM IV>)
Su cliente replica el empaquetado para descifrar: lee el prefijo de longitud, separa la clave envuelta, la desenvuelve con su clave privada RSA y luego descifra el resto con AES-256-GCM. El SDK hace todo esto por usted; el formato está documentado para que su equipo de seguridad pueda verificarlo de forma independiente.
No el worker (descarta la clave de resultado). No la plataforma (nunca tuvimos su clave privada). No MicroDC bajo una orden judicial, no un empleado malintencionado, no un atacante con una copia completa de nuestra base de datos. Esto no es política: es aritmética. Nosotros mismos dependemos de ello: nuestra canalización de facturación no puede inspeccionar los resultados cifrados ni siquiera para su propia contabilidad, y por eso tiene una ruta de código dedicada.
6. La confirmación de recepción destruye la evidencia.
Cuando su cliente recupera el resultado y confirma la recepción del trabajo, la plataforma elimina el registro de la clave custodiada y purga los blobs cifrados de carga y resultado. Lo que queda son metadatos de facturación: recuentos de tokens, marcas de tiempo, nombre del modelo. Esos metadatos están en claro por diseño: el servidor no puede contar tokens en texto cifrado, así que el worker informa recuentos estimados de tokens junto con el resultado cifrado, y el tipo de trabajo, el modelo y los tiempos permanecen legibles para que la programación, el enrutamiento y la facturación funcionen sin descifrar nunca el contenido. El contenido en sí, y todo medio de recuperarlo, desaparece.
La parte honesta: criptografía frente a confianza operativa.
Esta es la sección que la mayoría de los proveedores no escribiría, y la razón por la que puede confiar en el resto de este artículo.
La ruta del resultado es de conocimiento cero en sentido estricto: la plataforma es criptográficamente incapaz de leer los resultados, porque el descifrado requiere una clave privada que nunca poseemos.
La ruta de la solicitud no lo es, y no vamos a fingir lo contrario. La clave de carga transita por el servidor y permanece en custodia hasta que se confirma la recepción del trabajo; así es como la obtiene el worker que lo reclama. Durante esa ventana, un hipotético MicroDC que violara su propio diseño podría combinar la clave custodiada con el texto cifrado almacenado y leer su prompt. No lo hacemos: ninguna ruta de código lo hace, el contenido nunca se registra y la clave se destruye al confirmar la recepción. Pero para la carga de la solicitud, "no podemos" es en realidad "no lo hacemos, con una ventana verificablemente estrecha, eliminada al confirmar": una garantía operativa, no matemática.
| Etapa | Quién podría leerlo | Tipo de garantía |
|---|---|---|
| Prompt en tránsito | Nadie (AES-256-GCM + TLS 1.3) | Criptográfica |
| Prompt en reposo, antes de reclamar | Usted; la plataforma si rompiera su diseño (clave custodiada) | Operativa |
| Prompt durante la inferencia | El único worker gestionado que ejecuta su trabajo | Operativa (hardware gestionado, sin salida externa) |
| Resultado, en todas partes después del worker | Usted, y nadie más | Criptográfica |
| Todo después de la confirmación de recepción | Nadie (claves y blobs purgados) | Criptográfica (los datos ya no existen) |
¿Por qué la clave de la solicitud toca el servidor en absoluto? Porque la alternativa, un intercambio de claves directo entre su cliente y un worker que todavía no ha sido elegido, exige que los workers mantengan pares de claves de identidad de larga duración y que los clientes los verifiquen, lo cual es una superficie de confianza significativamente mayor para hardware a escala comunitaria. El envoltorio de claves directo de cliente a worker está en nuestra hoja de ruta; convertirá la única celda operativa de esa tabla en una criptográfica. Preferimos publicar la versión honesta de la tabla de hoy antes que una descripción favorecedora de un sistema que no hemos construido.
Cómo usarlo.
Un solo indicador. El SDK se encarga de la generación de claves, el cifrado y el descifrado del resultado de forma transparente:
from microdc import Client
client = Client(api_key=os.environ["MDC_KEY"])
job = client.jobs.create(
model="llama-3.3-70b",
messages=[{"role": "user", "content": confidential_prompt}],
encrypt=True,
)
result = client.jobs.wait(job.id) # descifrado localmente con su clave privada
client.jobs.acknowledge(job.id) # purga claves y blobs en el servidor
Los trabajos cifrados requieren el permiso de cifrado en su cuenta; se habilita bajo solicitud para que podamos asegurarnos de que la capacidad de workers gestionados cubra la demanda. Pídanos que lo activemos.
La conclusión.
El modelo de todo proveedor de inferencia ve su texto en claro; eso es física, no una decisión del proveedor. Lo que cambia es todo lo que hay alrededor. En MicroDC.ai, el texto en claro existe exactamente en dos lugares: su máquina y un worker gestionado por MicroDC sin ninguna ruta externa para sus datos. La plataforma intermedia enruta texto cifrado, conserva la clave de carga solo en una custodia limitada por su eliminación y recibe resultados que es matemáticamente incapaz de leer. Y cuando usted confirma la recepción del trabajo, incluso el texto cifrado deja de existir.
Si su equipo de seguridad quiere profundizar (tamaños de clave, restricciones al reclamar, semántica de purga), envíeles este artículo y luego póngalos en una sala con nuestros ingenieros. Lo construimos para superar esa conversación.
Cifrado en la guía para desarrolladores → Pruébelo con créditos gratis →