Alcance editorial de la línea

Qué cubre esta línea y qué queda fuera de su alcance

Antes de profundizar en cualquier eje conviene tener claro el perímetro. Lo que sigue detalla qué temas se tratan, qué temas no se abordan y qué datos hacen falta para orientar una lectura útil del material.

Dentro del alcance

Separación física de la inferencia: traslado del reconocimiento facial y de voz desde la CPU general hacia aceleradores dedicados como NPU, con memoria propia y canal acotado hacia el resto del sistema. Custodia de claves, sellos de integridad y atestación mediante módulos HSM, aclarando en cada caso qué operaciones realiza realmente un HSM y cuáles no. Atestación remota como mecanismo para verificar firmware, modelo cargado y estado del entorno en dispositivos de borde. Análisis de vectores de fuga que no terminan en el chip: DMA, memoria unificada y buffers intermedios entre etapas de inferencia.

Fuera del alcance

No se ofrecen implementaciones, licencias, soporte ni acompañamiento técnico. Tampoco se publican precios, planes ni niveles de servicio. No se emiten dictámenes de cumplimiento normativo ni se repiten criterios de auditoría que corresponden a otras secciones del proyecto. No se afirman capacidades de hardware que no estén documentadas por el fabricante, ni se prometen resultados numéricos de rendimiento o de reducción de incidentes.

Límites que conviene asumir

Un HSM custodia claves y firma atestaciones, pero no ejecuta redes neuronales completas. Aislar el acelerador no elimina por sí solo las rutas de fuga: el bus, los controladores DMA y la memoria compartida siguen siendo superficies relevantes. La atestación remota aporta evidencia verificable, no garantías absolutas sobre el dispositivo en campo. Cada eje se presenta como material de estudio y no como recomendación cerrada para un despliegue concreto.

Datos a precisar antes de consultar

Para orientar una consulta técnica resulta útil indicar si el interés está en servidor, en cliente o en ambos entornos, y qué componente se quiere revisar primero: NPU, HSM, aislamiento de memoria o la cadena completa. También ayuda describir el escenario de despliegue y las restricciones de hardware ya definidas. Con ese contexto se puede señalar qué material de la línea conviene leer antes y qué preguntas quedan abiertas.

Las consultas sobre el alcance editorial se reciben por correo en info@sandtdesignstudio.com o por teléfono en +54 351 490-1818. La sede del proyecto está en Av. Colón 530, Centro Empresarial, X5000 Córdoba, Argentina.

Recorrido editorial

De la consulta inicial al material de estudio: cómo se recorre un eje temático

1. Encauzar la consulta por el tema correcto

El primer paso es ubicar el interés dentro de uno de los cuatro ejes: separación física de la inferencia, custodia de claves y sellos, atestación remota o vectores de fuga fuera del chip. Una consulta sobre DMA y memoria unificada no se responde con material sobre HSM, y al revés. Definir el eje evita mezclar mecanismos que resuelven problemas distintos dentro de la misma arquitectura.

2. Precisar el entorno: servidor, borde o ambos

Un despliegue en servidor concentra el análisis en aceleradores dedicados, IOMMU y políticas de asignación de memoria. Un despliegue de borde agrega atestación remota, rotación de claves y compatibilidad entre generaciones de hardware. Cuando el escenario es mixto, conviene describir primero qué se ejecuta en cada extremo y qué canal transporta las entradas desde la cámara o el micrófono hasta el acelerador.

3. Identificar qué componente se quiere revisar

NPU, HSM, aislamiento de memoria o cadena completa. Cada opción tiene un alcance acotado: un HSM custodia claves, sellos de integridad y atestación, pero no ejecuta redes neuronales completas. Un NPU aislado ofrece cómputo especializado y memoria separada, aunque su modelo de seguridad depende del fabricante. Nombrar el componente con precisión es lo que permite que la respuesta editorial sea útil y no una descripción genérica.

4. Describir el escenario sin datos sensibles

Alcanza con explicar la arquitectura, los límites observados y las dudas concretas. No hace falta adjuntar capturas, registros ni identificadores de personas: el material es conceptual y se apoya en conceptos verificables de arquitectura, atestación y gestión de claves. Si el escenario incluye hardware propietario, basta con mencionar la familia y las primitivas que expone.

5. Recibir una respuesta orientada a lectura

La devolución llega como material de estudio: notas, referencias cruzadas y aclaraciones sobre qué garantiza cada mecanismo y qué no. No se promete implementación, soporte ni acompañamiento técnico, y tampoco se afirman capacidades no documentadas del hardware. El objetivo es que quien evalúa un despliegue tenga criterios claros antes de comprometer un diseño.

6. Seguir el eje por los recursos publicados

Después de la primera respuesta, el eje temático se profundiza en las notas del proyecto. Ahí se amplían los puntos que quedaron abiertos: fugas por DMA, memoria unificada, buffers intermedios y el ciclo de vida de la atestación. Para ver cómo se organiza el conjunto, conviene revisar los recursos publicados y, si interesa el enfoque editorial detrás de los ejes, la página sobre el proyecto.

Un caso de referencia: inferencia facial en un servidor de acceso compartido

Escenario de estudio, sin cliente identificado ni datos reales. Un equipo de infraestructura ejecutaba reconocimiento facial sobre la CPU general de un servidor que también atendía otras tareas internas. Los tensores del modelo y los buffers intermedios convivían con procesos ajenos en la misma memoria, y cualquier servicio con privilegios podía, en teoría, inspeccionar fragmentos de activaciones antes de que se liberaran. La pregunta que abrió el análisis no fue de rendimiento, sino de superficie de ataque: cuántos puntos del sistema podían leer un rostro en claro.

Contexto de partida. El modelo vivía en disco cifrado, pero se descifraba completo en memoria al arrancar el servicio. La clave estaba en un archivo de configuración con permisos de grupo, y no existía verificación de integridad del binario antes de cargarlo. La cámara enviaba cuadros por un socket local, sin canal dedicado.
Tarea planteada. Reducir los lugares donde un proceso ajeno pudiera observar pesos, entradas o activaciones. El objetivo no era eliminar todo riesgo, sino acotar el conjunto de componentes que necesitan acceso legítimo a esos datos y hacer verificable ese acceso.
Restricciones del entorno. El servidor no admitía reemplazo de placa ni firmware alternativo. La latencia de respuesta frente a la puerta no podía degradarse de forma perceptible. El equipo de operaciones no tenía experiencia previa con módulos de seguridad de hardware, así que cualquier diseño debía ser mantenible con la documentación disponible del fabricante.
Enfoque explorado. Se separó la inferencia hacia un acelerador dedicado con memoria propia, dejando a la CPU solo el intercambio de descriptores y resultados. La clave de descifrado del modelo pasó a un módulo de seguridad que además firmaba la medición del binario cargado. Se activó IOMMU para contener el DMA y se añadió borrado explícito de buffers tras cada inferencia. La atestación remota se usó para comprobar firmware y modelo en cada arranque del servicio.
Límites reconocidos. El módulo de seguridad no ejecuta la red neuronal: solo custodia claves y sellos. La memoria unificada del acelerador sigue siendo un vector si el kernel no reserva regiones correctamente. Y la atestación depende de que el fabricante exponga primitivas compatibles entre generaciones de hardware, algo que no siempre ocurre.

Lectura del caso

El aislamiento útil no proviene de un solo componente, sino de combinar custodia de claves, cómputo separado y verificación remota. Ninguno de los tres resuelve el problema por sí solo, y cada uno introduce compromisos de mantenimiento que conviene evaluar antes de comprometer un despliegue. Este material es descriptivo y conceptual: no constituye una implementación ni un servicio contratable.

Qué cambia cuando la inferencia biométrica sale de la CPU general

El modelo deja de compartir memoria con el sistema operativo

Cuando los pesos y las activaciones intermedias viven en la CPU general, cualquier proceso con los permisos adecuados puede alcanzar esos buffers. Al trasladar la inferencia a un NPU dedicado, el modelo ocupa un espacio propio y la CPU solo intercambia descriptores y resultados. Se reducen los puntos donde un proceso ajeno podría leer tensores en claro, aunque la orquestación sigue siendo el eslabón crítico.

El HSM custodia claves y sellos, no ejecuta la red neuronal

Un módulo de seguridad de hardware guarda la clave que descifra el modelo en el momento de la carga, el sello que verifica su integridad y la identidad del dispositivo. Los pesos descifrados se alojan en el NPU o en un enclave asociado, nunca dentro del HSM. Confundir ambos roles lleva a dos errores frecuentes: esperar que el HSM haga inferencia y creer que cifrar el archivo alcanza sin controlar quién puede descifrarlo.

Las fugas no terminan en el chip

Un controlador DMA mal configurado puede leer regiones que el acelerador ya no usa pero que todavía contienen activaciones. En plataformas de borde, la memoria unificada difumina la frontera entre lo que pertenece al NPU y lo que pertenece al kernel. Las mitigaciones habituales pasan por IOMMU activa, regiones reservadas, borrado explícito de buffers tras cada inferencia y políticas de asignación que impidan reutilizar páginas con residuos del modelo.

La atestación remota vuelve verificable lo que ocurre en campo

Un lector de acceso instalado en una sucursal opera fuera del control físico del equipo central. La atestación remota permite que ese dispositivo demuestre, mediante mediciones firmadas, qué firmware cargó, qué modelo tiene en memoria y en qué estado se encuentra el entorno. Sin ese mecanismo, una actualización legítima y una manipulación se ven igual desde el servidor. El trabajo difícil está en el ciclo de vida: rotación de claves, revocación de equipos comprometidos y compatibilidad entre generaciones de hardware.

Cada eje se publica como material descriptivo. El alcance es conceptual: no incluye implementaciones, licencias ni acompañamiento técnico.

Para revisar los criterios de arquitectura que atraviesan estos temas, conviene empezar por los recursos técnicos y, si hace falta contexto sobre el enfoque editorial, por la sección sobre el proyecto.