Cada vez que le mandas un prompt a un modelo de IA, esa información viaja a un servidor que no controlas, se procesa ahí, y tú confías en que nadie la está mirando. Para un chat casual da igual. Pero si dentro de ese prompt va el código propietario de tu empresa, los datos de un cliente, o la lógica de tu producto, esa confianza ciega empieza a pesar.

Acá es donde entra un concepto que vale la pena entender: el TEE, o Trusted Execution Environment.

El problema de la inferencia en la nube

La seguridad informática tradicional protege los datos en dos estados. Cuando están guardados en un disco, se cifran (datos en reposo). Cuando viajan por la red, se cifran también (datos en tránsito, el famoso candado HTTPS).

Pero hay un tercer estado del que casi nadie habla: los datos en uso. En el momento exacto en que el procesador está trabajando con tu información, esa información tiene que estar descifrada para que el chip pueda operar sobre ella. Es física básica: un procesador no puede hacer cálculos sobre datos cifrados sin antes descifrarlos.

Ese instante es la ventana de exposición. Cualquiera con acceso privilegiado a esa máquina (un administrador del sistema, el personal del proveedor de nube, o un atacante que logró entrar) puede en teoría leer la memoria y ver tu prompt en texto plano. No importa cuánto HTTPS le pongas por delante: en el momento del cálculo, está expuesto.

Para la mayoría de las aplicaciones esto es un riesgo aceptable. Para inferencia de IA con datos sensibles, es el punto ciego más grande del stack.

Qué es exactamente un TEE

Un Trusted Execution Environment es una región aislada del procesador, protegida por hardware, donde la memoria se cifra automáticamente mediante mecanismos de hardware y los datos solo son accesibles para el entorno de ejecución autorizado. Es una solución directa al problema de los datos en uso.

La idea es crear una especie de caja fuerte dentro del propio chip. El código y los datos que entran a esa caja quedan protegidos del resto del sistema, incluyendo el sistema operativo del host y el hipervisor que gestiona las máquinas virtuales. El diseño busca impedir que administradores del host, hipervisores y otros componentes privilegiados accedan al contenido protegido.

Lo importante, y lo que hace fuerte a esta tecnología, es que la raíz de confianza está en el silicio. La protección no depende de una promesa de la empresa que opera el servidor ni de una política de privacidad que pueden cambiar mañana. Se basa principalmente en mecanismos criptográficos implementados en hardware y en procesos de atestación verificables.

Esa verificación tiene un nombre: atestación remota (remote attestation). Es un mecanismo criptográfico donde el propio enclave te firma un reporte con los hashes del software que corre adentro (firmware, kernel, tu contenedor), y tú lo verificas contra tus valores de referencia antes de enviarle nada sensible. El aislamiento del hardware es media solución; la atestación es la otra media. Sin ese paso de verificación, seguirías confiando a ciegas en el proveedor.

Vale la aclaración honesta: los TEEs elevan muchísimo el nivel de protección, pero no eliminan todas las clases de ataque. La investigación académica sigue estudiando vectores de canal lateral y otras formas avanzadas de análisis. Ninguna tecnología de seguridad es absoluta, y esta no es la excepción.

Intel TDX y AMD SEV-SNP

Hoy hay dos implementaciones principales que dominan el espacio de confidential computing para servidores.

Intel TDX (Trust Domain Extensions) aísla una máquina virtual completa dentro de lo que llama un Trust Domain. Toda la VM opera de forma segura, y los datos que entran o salen de ese dominio se mantienen cifrados, mitigando ataques de acceso directo a memoria por parte del host.

AMD SEV-SNP (Secure Encrypted Virtualization - Secure Nested Paging) toma un enfoque parecido: cifra la memoria de la máquina virtual a nivel de hardware, de modo que el contenido de esa memoria queda protegido del host.

Las dos llegan al mismo destino por caminos algo distintos: un entorno donde tu carga de trabajo corre aislada del resto, con la memoria cifrada, incluso durante el procesamiento.

¿Esto no hace todo más lento?

Es la primera duda de cualquier desarrollador, y es una duda razonable. Cifrar y aislar suena a overhead, y el overhead suena a latencia.

La respuesta corta, según la investigación reciente, es que el costo es mucho menor de lo que uno esperaría. Los estudios sobre confidential computing en GPUs NVIDIA H100 muestran un overhead de entre 3% y 7% en cargas de buen throughput para inferencia de modelos de lenguaje grandes. En inferencia de muy baja latencia puede ser algo mayor, porque ahí pesa más el cifrado de la comunicación por el bus PCIe entre el CPU y la GPU. Pero sigue siendo un costo razonable.

Ese overhead a cambio de que tus prompts no sean legibles ni siquiera para quien opera el servidor es, para muchos casos de uso, un intercambio que vale la pena. Ya hay benchmarks públicos de Intel ejecutando modelos abiertos como DeepSeek dentro de entornos Intel TDX, lo que confirma que esto no es teoría de laboratorio: funciona.

Por qué esto importa más en LATAM de lo que parece

Si eres un desarrollador o una pyme en la región, hay un par de razones por las que este tema te toca más de cerca.

La primera es regulatoria. Las leyes de protección de datos en la región se están endureciendo. Si manejas datos de clientes y los mandas a un modelo de IA, cada vez más vas a tener que poder responder dónde se procesaron y quién pudo acceder a ellos. "Se los mandé a una API en Estados Unidos y confío en que no los miraron" es una respuesta que envejece mal.

La segunda es de soberanía. Depender de un proveedor cerrado significa aceptar sus términos, sus precios y sus políticas de uso, que pueden cambiar de un día para otro. Esta misma semana (a junio 2026) se vio un caso claro: Anthropic deshabilitó su modelo de frontera Claude Fable 5 para todos los usuarios del mundo tras una orden del gobierno de Estados Unidos, sin previo aviso. Un modelo abierto corriendo en infraestructura que puedes verificar no te deja en esa posición.

Qué hacer con esto

Entender qué es un TEE te da una pregunta nueva para hacerle a cualquier proveedor de inferencia: ¿dónde se procesan mis prompts y quién puede leerlos?

La mayoría no tiene una buena respuesta. Te dirán que usan HTTPS (datos en tránsito, ya resuelto) y que tienen una política de privacidad (una promesa, no una garantía técnica). Pocos pueden decir que la inferencia corre dentro de un enclave de hardware donde ni ellos mismos pueden ver el contenido.

Esa es justamente la diferencia entre privacidad por promesa y privacidad por hardware. Y ahora que sabes que la segunda existe, es difícil volver a conformarse con la primera.

En TEEra construimos exactamente sobre esa diferencia: privacidad por hardware, no por promesa. La inferencia de modelos abiertos (Kimi, DeepSeek, GLM, Qwen y más) corre dentro de enclaves TEE (para los modelos marcados como tales), donde ni nosotros podemos leer tus prompts. Tenemos precios por millón de token procesado a veces incluso más baratos que las propias APIs oficiales de los modelos, y el pago es en tu moneda local vía MercadoPago desde $5 USD. Si quieres hacerle a tu inferencia la pregunta de "¿quién puede acceder a esto?" y que la respuesta esté respaldada por garantías técnicas verificables, puedes conectar OpenCode o cualquier otro entorno de desarrollo en tan solo 2 minutos en teera.io/register.