IA en Dispositivo vs On-Premise: Diferentes Problemas de Privacidad, Diferente Preparación de Datos

Los equipos de IA empresarial reconocen cada vez más que enviar datos sensibles a APIs de terceros en la nube es un riesgo. Pero la respuesta a ese reconocimiento se bifurca en dos caminos distintos — IA en dispositivo e IA on-premise — y la mayoría de las organizaciones los confunden.

Resuelven problemas diferentes. Imponen restricciones diferentes. Y requieren enfoques fundamentalmente diferentes para la preparación de datos.

Dos Modelos, Dos Garantías de Privacidad

La IA en dispositivo ejecuta modelos directamente en el hardware del usuario final: smartphones con NPUs, laptops con motores neuronales, dispositivos edge con aceleradores dedicados. Los modelos típicamente son de 0.5B–8B parámetros, cuantizados para caber dentro de los presupuestos de memoria y cómputo del dispositivo. La garantía de privacidad: los datos del usuario nunca salen del hardware. Sin llamada de red, sin servidor, sin tercero.

Una aplicación de salud que procesa notas de voz en el teléfono de un clínico. Una herramienta de inspección en campo que clasifica defectos en una tablet ruggedizada. Un asistente de investigación legal que se ejecuta en la laptop de un abogado. En cada caso, la entrada sensible permanece en el dispositivo donde fue generada.

La IA on-premise ejecuta modelos en el propio centro de datos o nube privada de la empresa. Los modelos pueden ser de cualquier tamaño — 7B a 70B+ — porque la empresa controla la infraestructura de cómputo. La garantía de privacidad: los datos de entrenamiento y los registros de inferencia nunca salen del perímetro de la organización. Sin proveedor de nube, sin acuerdo de procesamiento de datos requerido para cargas de trabajo de IA.

Un hospital que ajusta modelos de NLP clínico con registros de pacientes. Un bufete de abogados entrenando modelos de análisis de contratos con documentos privilegiados. Una institución financiera construyendo modelos de detección de fraude con historial de transacciones. Los datos sensibles se quedan dentro del edificio en cada etapa.

Por Qué Esta Distinción Importa para la Preparación de Datos

Aquí es donde la mayoría de los equipos se confunden. Asumen que la preparación de datos es la misma independientemente de dónde se ejecute el modelo. No lo es.

Como lo expresó recientemente un ingeniero líder de machine learning trabajando en IA en dispositivo: "La mayoría de los datasets de fine-tuning hoy están optimizados para modelos grandes. Pero cuando destilamos a modelos de ~0.5B–1B para NPUs móviles, la distribución de datos importa mucho."

Los requisitos divergen en cada dimensión.

Preparación de Datos para IA en Dispositivo

Cuando tu objetivo es un modelo de 0.5B–1B ejecutándose en un NPU Snapdragon o Apple Neural Engine, el pipeline de datos debe considerar restricciones severas de capacidad.

Tamaño y distribución del dataset. Un modelo de 70B puede absorber millones de ejemplos de entrenamiento en temas diversos. Un modelo de 0.5B tiene aproximadamente 140 veces menos parámetros. Cada ejemplo de entrenamiento debe ganarse su lugar. El dataset debe ser estrecho y profundo — enfocado estrictamente en la tarea específica que el modelo del dispositivo realizará — en lugar de amplio y superficial.

Calibración de datos sintéticos. El enfoque estándar es usar un modelo teacher grande (70B+) para generar datos sintéticos de entrenamiento, y luego usar esos datos para entrenar el modelo student más pequeño. Pero el teacher genera texto a un nivel de complejidad que el student no puede reproducir. Los ejemplos sintéticos deben filtrarse por longitud, complejidad de vocabulario y profundidad de razonamiento de los que el modelo student realmente pueda aprender.

Coincidencia de ventana de contexto. Si tu despliegue en producción tiene una ventana de contexto de 512 tokens en móvil, pero tus datos de entrenamiento contienen ejemplos de 4,000 tokens, el modelo aprende patrones que nunca usará. La distribución de longitud de los datos de entrenamiento debe coincidir con el entorno de inferencia en producción.

Conciencia de cuantización. Los modelos en dispositivo típicamente se cuantizan a Q4 o Q5 (4 bits o 5 bits). La cuantización degrada el rendimiento en casos extremos. Los datos de entrenamiento deben sobrerrepresentar los casos límite que la cuantización es más probable que rompa.

El pipeline: Datos crudos → Limpiar → Filtrar por capacidad del modelo objetivo → Generar datos sintéticos calibrados al modelo student → Validar contra hardware objetivo → Exportar para fine-tuning → Entrenar en la nube → Destilar → Cuantizar → Desplegar al dispositivo.

La perspectiva clave es que el pipeline no es entrenar → desplegar. Para IA en dispositivo, es: modelo teacher → destilación → cuantización → restricciones de runtime. Una capa de herramientas que entienda el runtime objetivo (ExecuTorch, LiteRT, ONNX, Qualcomm AI Hub) durante la preparación del dataset podría ser transformadora.

Preparación de Datos para IA On-Premise

Cuando tu objetivo es un modelo de 7B–70B ejecutándose en tu propio centro de datos, las restricciones son completamente diferentes. La capacidad del modelo no es el cuello de botella. El cumplimiento sí lo es.

Rastros de auditoría. Cada ejemplo de entrenamiento necesita procedencia documentada. ¿De dónde vienen estos datos? ¿Quién autorizó su inclusión? ¿Cuándo se ingirieron? ¿Se ha redactado el PII? El Artículo 30 del EU AI Act requiere documentación técnica de los datos de entrenamiento para sistemas de IA de alto riesgo. Tu pipeline de preparación de datos es donde esa documentación debe generarse.

Redacción de PII y PHI. Antes de que cualquier documento empresarial entre en un pipeline de entrenamiento, la información de identificación personal debe ser detectada y manejada. Nombres de pacientes en notas clínicas. Números de Seguro Social en documentos financieros. Direcciones de correo electrónico en comunicaciones internas. Esto no es opcional — es un requisito de HIPAA, GDPR y leyes estatales de privacidad.

Linaje de datos. Para industrias reguladas, necesitas rastrear cualquier predicción del modelo a través de los datos de entrenamiento hasta el documento fuente original. Si un modelo toma una decisión sobre un paciente, necesitas probar qué ejemplos de entrenamiento influyeron en esa decisión. Esto requiere linaje de extremo a extremo desde el documento crudo hasta el ejemplo de entrenamiento hasta la salida del modelo.

Operación air-gapped. Los entornos on-premise más estrictos — defensa, inteligencia, infraestructura crítica — están air-gapped. Sin conectividad a internet. Tus herramientas de preparación de datos deben ejecutarse completamente offline, sin telemetría, sin callbacks a servidores de licencia, sin dependencias de la nube.

El pipeline: Documentos empresariales crudos → Ingerir (parsear PDFs, Word, documentos escaneados) → Limpiar (puntuación de calidad, deduplicación, redacción de PII) → Etiquetar (expertos de dominio anotan directamente) → Aumentar (generación de datos sintéticos usando LLMs locales) → Exportar (JSONL, texto segmentado, YOLO/COCO) → Entrenar en GPUs locales.

Cada paso debe ocurrir on-premise. Si aunque sea una etapa requiere una herramienta en la nube, toda la garantía de cumplimiento se rompe.

El Marco de Decisión

Muchas empresas necesitan ambas. Un hospital podría necesitar modelos en dispositivo para asistentes clínicos junto a la cama (privacidad de inferencia) Y fine-tuning on-premise de modelos más grandes con registros de pacientes (privacidad de datos de entrenamiento). Los requisitos de preparación de datos para cada uno son distintos, incluso cuando los datos fuente se superponen.

Dónde Encaja Ertas

Ertas Data Suite es una aplicación de escritorio nativa que maneja la preparación de datos para ambos objetivos de despliegue desde una sola plataforma.

Para flujos de trabajo en dispositivo, el módulo Augment genera datos sintéticos de entrenamiento calibrados para tamaños de modelo y objetivos de hardware específicos. El módulo Clean filtra datasets para las características de distribución que los modelos sub-1B requieren.

Para flujos de trabajo on-premise, el pipeline completo (Ingest → Clean → Label → Augment → Export) se ejecuta completamente on-premise sin egreso de datos. Cada transformación se registra con marcas de tiempo e IDs de operador. Los reportes de auditoría se exportan directamente para cumplimiento de GDPR, HIPAA y EU AI Act.

Una plataforma. Dos objetivos de despliegue. Sin datos saliendo del edificio en ninguna etapa.

Agenda una Llamada de Descubrimiento para discutir qué modelo de despliegue se adapta a tu caso de uso y cómo estructurar tu pipeline de preparación de datos en consecuencia.