IA local y privacidad: cómo comprobar qué datos salen de tu equipo

Qué significa realmente «local»

«Local» puede describir varias cosas distintas: dónde se guardan los pesos del modelo, dónde se calcula una respuesta o qué partes del flujo de trabajo ocurren en el equipo. Esas condiciones no son equivalentes. Un modelo puede estar descargado y ejecutarse en el ordenador mientras la aplicación consulta un servicio externo para una función opcional, comprueba si hay actualizaciones o busca modelos disponibles. También puede ocurrir que una aplicación envíe una solicitud a un servidor de inferencia que se ejecuta en el mismo equipo, pero guarde conversaciones o registros en archivos accesibles para otros usuarios del sistema.

Por eso, la pregunta útil no es solo «¿el modelo es local?», sino «¿qué componentes intervienen en esta tarea, qué datos recibe cada uno y qué evidencia tengo de su comportamiento?». El límite que se debe revisar abarca la interfaz de chat, el proceso que carga el modelo, las herramientas activadas, las extensiones, las conexiones de red, el almacenamiento y las copias de seguridad. La evaluación se refiere a una configuración concreta: versión de la aplicación, ajustes, sistema operativo, modelo instalado y acciones realizadas.

Ejecutar la inferencia en el dispositivo puede reducir la necesidad de enviar el prompt a un proveedor remoto para esa operación, pero no demuestra por sí mismo que la aplicación completa esté desconectada. Tampoco protege automáticamente la información frente a otras cuentas con acceso al equipo, programas maliciosos, permisos amplios o archivos conservados después de cerrar la aplicación. Es una diferencia entre ubicación del cálculo, recorrido de los datos y seguridad del dispositivo.

Dibuja el recorrido antes de probar

Haz un inventario de las piezas que participan, no solo del modelo. Incluye la aplicación que presenta el chat, el servidor de inferencia, el modelo y su gestor de descargas; después añade búsqueda web, herramientas, extensiones, complementos, verificaciones de actualizaciones y opciones que puedan usar servicios en la nube. Si una aplicación permite alternar entre modos locales y remotos, anota qué modo está activo en cada ensayo. La etiqueta de una pantalla no sustituye la comprobación de la configuración efectiva.

Para cada pieza, registra qué información podría recibir. Un prompt puede contener texto sensible; un documento adjunto puede ser leído por una herramienta; una búsqueda puede transmitir una consulta; un registro puede conservar entradas y salidas. No des por hecho que todos esos datos se manejan igual. Un servicio que calcula la respuesta, una función que consulta internet y un archivo de historial son destinos y superficies de exposición diferentes.

El inventario debe distinguir actividades. Descargar un modelo, instalar una extensión, escribir un prompt, adjuntar un archivo, invocar una búsqueda y consultar actualizaciones son acciones separadas. Si se hacen todas a la vez, un cambio en el tráfico no permitirá atribuirlo con claridad. La metodología de caracterización de redes de NIST ofrece una base para organizar observaciones en torno a actividades predeterminadas; su informe se refiere a dispositivos IoT, por lo que aquí se adapta como método de ensayo, no como certificación de aplicaciones de IA.

Prueba controlada sin conexión

Una prueba sin internet permite averiguar qué funciones siguen disponibles después de preparar el entorno, pero no demuestra que nunca haya habido transmisión. Antes de desconectar, instala la aplicación, descarga el modelo que vas a evaluar y prepara los documentos de prueba. Anota qué recursos se obtuvieron durante esa fase. Si el producto ofrece búsqueda, descargas bajo demanda o herramientas remotas, déjalas identificadas como funciones distintas del chat básico.

Desconecta el equipo de internet mediante un método verificable y registra el estado de la conexión. Prueba por separado una conversación sencilla con el modelo ya cargado, una consulta con un documento local y cada función opcional que te interese. Anota si la tarea termina, falla con un mensaje, queda esperando o produce un resultado parcial. Repite cada prueba en condiciones parecidas y evita cambiar varias opciones entre ensayos.

El resultado debe expresarse con límites. Si una conversación funciona sin conexión, puedes concluir que esa tarea concreta funcionó en esa configuración durante la prueba. No puedes concluir que la aplicación nunca transmite datos, que no realizará conexiones al reconectarse o que otro modo de uso se comporte igual. Si una función falla, eso indica que la operación probada no estuvo disponible sin red en esas condiciones; no identifica por sí solo qué dato habría enviado ni a qué destino.

La documentación de LM Studio, por ejemplo, distingue tareas que declara disponibles sin conexión, como el chat y el trabajo con documentos, de acciones que generan solicitudes de red, como buscar o descargar modelos y comprobar actualizaciones. Esto sirve como referencia de cómo una aplicación puede describir sus modos, pero no reemplaza la comprobación del equipo, la versión y los ajustes concretos que se están evaluando.

Observa el tráfico por actividad

La prueba más informativa separa eventos y toma notas antes, durante y después de cada uno. Registra conexiones en reposo; luego inicia el programa; carga el modelo; envía un prompt de prueba; adjunta un documento inocuo; activa una búsqueda; instala una extensión y consulta actualizaciones. No mezcles todos los pasos en una sola sesión si necesitas atribuir conexiones. Repite las acciones relevantes para saber si el patrón observado aparece de nuevo.

Documenta el momento, la acción, el proceso asociado si puedes identificarlo, el destino visible y la duración aproximada. Conserva también la configuración exacta y cualquier mensaje de error. La observación de una conexión no basta para afirmar qué contenido circuló; el nombre de un destino tampoco prueba por sí solo qué tratamiento se hizo de los datos. Si no puedes inspeccionar el contenido, deja constancia de esa limitación y evita completar el vacío con una suposición.

Compara tres situaciones: la aplicación inactiva, el uso básico y cada función opcional. Si aparece una conexión durante una actualización o descarga, sepárala del ensayo del prompt. Si no observas tráfico durante una prueba, limita la conclusión a esa prueba y a las herramientas de observación utilizadas: una captura puntual puede no detectar conexiones intermitentes, retrasadas o iniciadas por otro componente. Para una revisión de mayor impacto, pide a una persona técnica que documente el método y repita el protocolo.

Revisa historiales, registros y permisos

La privacidad no termina cuando se genera la respuesta. Busca dónde se guardan conversaciones, documentos temporales, cachés y registros. Revisa tanto la configuración de la aplicación como los archivos que genera, y comprueba qué cuentas del sistema pueden leerlos. Considera también sincronización de carpetas, copias de seguridad y herramientas de diagnóstico, si se usan en ese equipo. No presupongas que cerrar una ventana equivale a borrar los datos ni que una opción de limpieza cubre todos los componentes.

Como ejemplo específico, la documentación de LM Studio indica que sus conversaciones se guardan en archivos JSON y describe ubicaciones para distintos sistemas operativos. Su documentación del comando de flujo de registros señala que estos pueden mostrar el texto de entrada y salida del modelo y del servidor. Son detalles relevantes para revisar esa aplicación y su configuración; no se deben extrapolar automáticamente a otros runtimes.

Antes de introducir información sensible, prueba el borrado con datos ficticios: localiza los archivos antes y después, usa el mecanismo documentado y comprueba qué queda. Si el producto no explica dónde se guardan los datos o cómo se eliminan, anótalo como incertidumbre y solicita aclaración al proveedor o a quien administre el sistema. Limitar los permisos de la cuenta que ejecuta la aplicación puede reducir quién accede a los archivos, pero no sustituye controles del sistema, cifrado cuando corresponda ni una política de conservación.

Un servidor en el equipo puede ser accesible desde la red

Una API local permite que una aplicación cliente envíe solicitudes al servidor de inferencia. «Local» puede referirse a que el proceso está en tu ordenador, pero la interfaz de red en la que escucha determina desde dónde se le puede llegar. Un servicio limitado a una interfaz de loopback está pensado para solicitudes del mismo equipo; uno accesible mediante una interfaz de red puede aceptar conexiones desde otros dispositivos, según la configuración y las reglas de la red. Comprueba el comportamiento real en vez de deducirlo de la palabra local.

Revisa la dirección de escucha, el puerto, las opciones de acceso a la red y los controles de autenticación. Confirma si otro dispositivo de la red puede llegar al servicio y si puede enviar solicitudes sin credenciales. Hazlo solo en un entorno autorizado y con un modelo y contenido de prueba. Una respuesta del servidor no demuestra que todas sus herramientas estén aisladas: comprueba por separado qué archivos, funciones o extensiones puede invocar el cliente que realiza las solicitudes.

La documentación de LM Studio describe un servidor API local utilizable en localhost o en la red. Esa posibilidad es una razón para inspeccionar la interfaz y los ajustes activos, no evidencia de que toda instalación escuche en la red o esté expuesta por defecto. Si no necesitas acceso desde otros dispositivos, restringe el servicio al propio equipo mediante las opciones disponibles y las reglas del sistema. Si sí lo necesitas, aplica controles de acceso y limita los permisos del proceso a lo imprescindible.

Separa hechos observados, declaraciones y preguntas abiertas

Un informe útil distingue tres niveles. El primero es lo observado: por ejemplo, una función concreta falló sin conexión o se registró una conexión durante una acción determinada. El segundo es lo que declara el proveedor en documentación o políticas, como las funciones que afirma que trabajan sin conexión o los casos en los que dice que transmite datos. El tercero es lo que todavía no se ha establecido: contenido de una conexión cifrada que no se inspeccionó, comportamiento de otra versión o acceso a archivos por procesos ajenos.

Una política de privacidad es una fuente primaria sobre las declaraciones del proveedor respecto de su producto, pero no verifica de manera independiente lo que hizo una instalación específica. A la inversa, una captura de tráfico describe lo que observó una herramienta en un periodo y configuración concretos, pero no reemplaza una explicación contractual sobre conservación o tratamiento. Combina ambos tipos de evidencia y conserva la fecha, versión y condiciones de cada uno.

La matriz siguiente ayuda a evitar conclusiones más amplias que la prueba. Si el resultado depende de una opción, registra tanto el estado observado como el valor exacto de esa opción. Si no puedes reproducir una observación o no puedes identificar su origen, clasifícala como pendiente. Para decisiones de alto riesgo, una evaluación informal no sustituye la revisión de seguridad, privacidad y requisitos legales aplicables.

Lista de comprobación antes de usar datos sensibles

La decisión final no debería depender de una etiqueta comercial ni de una única prueba. Valora el tipo de dato, el impacto de una divulgación, las funciones realmente necesarias, el acceso físico y lógico al equipo, el nivel de evidencia reunido y la capacidad de borrar o controlar registros. Si no puedes aclarar una cuestión importante, no la conviertas en una suposición favorable: reduce el alcance de uso, elimina la función dudosa o detén la evaluación hasta obtener una respuesta verificable.

Para mantener el control, conserva un registro breve de la configuración y del protocolo. Repite las pruebas después de actualizaciones importantes, cambios de extensiones o modificaciones de red, porque el resultado describe la configuración ensayada y no todas las futuras. Guarda capturas o notas con los datos sensibles retirados y limita quién puede consultar esos materiales. Si se detecta un envío inesperado, suspende el uso de datos reales, preserva evidencia no sensible y solicita una revisión técnica antes de reanudarlo.

Usa esta lista como umbral práctico, no como certificación de privacidad. Para explorar opciones de modelos locales, consultar una comparación o descubrir otras herramientas, puedes partir de las guías de modelos locales, las comparativas y el catálogo de descubrimiento de Inferama; la evaluación de privacidad, sin embargo, debe hacerse sobre la aplicación y configuración que se van a utilizar.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.