Cómo evaluar un convertidor de archivos para la empresa: lista de seguridad y privacidad en Windows

«Funciona sin conexión», «privado» y «seguro» suenan tranquilizadores en una página de producto. Ninguna de estas expresiones responde por sí sola a una revisión de TI.

Una empresa necesita saber qué hace realmente la aplicación: por dónde viajan los bytes del original, qué procesos los manejan, qué permanece en el dispositivo, qué servicios reciben telemetría, cómo llegan las actualizaciones, qué ocurre cuando falla un trabajo y si el modelo de compra y administración encaja en la organización.

Esta lista está pensada para responsables de pequeñas empresas, generalistas de TI, revisores de seguridad y personal de compras que evalúen un conversor para Windows. Es neutral respecto al proveedor. LocalFlux aparece como ejemplo práctico porque su límite de procesamiento y sus limitaciones están documentados públicamente.

Respuesta breve: empieza por el recorrido del archivo, no por la etiqueta comercial. Exige evidencias del procesamiento normal, las excepciones de red, la conservación de los originales, las rutas compatibles, los diagnósticos, los fallos, los componentes incluidos, las actualizaciones y el despliegue comercial. Después, reproduce las afirmaciones importantes con archivos sintéticos.

Por qué una utilidad pequeña merece una revisión proporcionada

Puede que un conversor no acceda a la plataforma de identidad ni a la base de datos de la organización, pero recibe los archivos que elige el usuario. Estos pueden contener información de clientes, contratos, material aún no publicado, exportaciones de nómina, presentaciones, investigación o planes internos.

La guía de cadena de suministro del NIST Cybersecurity Framework 2.0 incluye la diligencia debida y los requisitos del proveedor en la adquisición de productos y servicios tecnológicos. No significa que cada utilidad de escritorio exija una evaluación de nivel empresarial. La profundidad debe ajustarse a los datos, el despliegue y el impacto empresarial.

Para una utilidad de puesto autogestionado, a menudo basta con documentación pública, un piloto controlado y una decisión clara sobre las clasificaciones permitidas.

1. Dibuja el recorrido normal del archivo

Pide al proveedor que describa la ruta habitual desde el original hasta el resultado. Una respuesta útil identifica cada límite:

Ubicación de origen → aplicación → componente de conversión → ubicación temporal → ubicación de salida

En un servicio remoto, identifica la organización receptora, la región, el almacenamiento, la eliminación, los registros y los subencargados. En software local, identifica los procesos ejecutables, motores incluidos, carpetas temporales, carpetas de salida y procesos secundarios.

No aceptes «local» como sustituto del mapa. Un producto puede convertir localmente y seguir enviando analítica, comprobando licencias, abriendo ayuda web, descargando componentes o usando una función exclusiva de la nube. Estas actividades pueden ser legítimas, pero deben separarse del recorrido principal del archivo.

Evidencia que debes solicitar: diagrama de flujo de datos, política de privacidad, página de confianza, documentación técnica o procedimiento reproducible de observación.

2. Separa el tráfico de conversión del tráfico de la plataforma

Una afirmación honesta sobre el funcionamiento sin conexión necesita límites. La instalación, la validación del pago, las licencias y las actualizaciones de Microsoft Store pueden usar servicios de Microsoft. Windows, el antivirus, los navegadores y otras aplicaciones en segundo plano generan su propio tráfico. Un enlace web abierto desde la aplicación contacta con su destino.

La pregunta importante es más concreta: durante un trabajo compatible, ¿envía la aplicación el original o el resultado seleccionado a un servicio de conversión del proveedor?

Atribuye las observaciones al proceso. Un gráfico de red vacío no basta si no se sabe qué proceso se estaba observando. Una ruta correcta tampoco demuestra el comportamiento de todas las rutas o versiones futuras.

Evidencia que debes solicitar: procesos identificados, excepciones documentadas, una prueba sin conexión y la versión exacta de la aplicación.

Incluye los procesos secundarios del conversor en la observación de red. Prueba por separado el envío opcional de comentarios: LocalFlux transmite el mensaje escrito y el correo de respuesta opcional cuando se solicita, sin adjuntar automáticamente archivos ni registros. Registra aparte el tráfico de Store y navegador y comprueba si la carpeta de trabajo se sincroniza. La política de privacidad explica estos límites.

3. Inventaría cuentas, analítica, fallos y diagnósticos

Formula cuatro preguntas independientes:

1. ¿Hace falta una cuenta para procesar archivos?
2. ¿Envía la aplicación analítica de uso o identificadores publicitarios?
3. ¿Se suben automáticamente informes de bloqueo o fallo?
4. ¿Qué ajustes, registros o diagnósticos permanecen en el equipo?

«Sin cuenta» no implica «sin telemetría». «Sin telemetría» tampoco implica «sin registros locales». Los diagnósticos locales pueden ser útiles y respetuosos con la privacidad si la persona controla cuándo compartirlos, pero deben documentarse su ubicación y limpieza.

Las capturas de la interfaz se renovaron en octubre de 2026 con una compilación reconstruida a partir del código documentado de LocalFlux 1.0.10.0. Las mediciones y descargas históricas conservan el alcance de sus pruebas originales. Registros de captura: 1

Evidencias comprobadas el 13 de octubre de 2026: el Centro de confianza público identifica la compilación 1.0.7.0. Las pruebas editoriales anteriores usaron un paquete x64 1.0.8.0 conservado. Las capturas renovadas usan muestras sintéticas nuevas y una compilación reconstruida a partir del código documentado de la versión x64 1.0.10.0; los registros están enlazados junto a las imágenes. Estas observaciones funcionales no son certificación de Store, autorización de publicación, evidencias en VM limpia o ARM64, ni una prueba de red. Antes de comprar, vuelve a consultar la ficha actual y las evidencias.

Revisa qué guarda la aplicación en el equipo y qué transmite, si transmite algo. La captura solo contiene datos editoriales sintéticos y rutas neutras.

Evidencia que debes solicitar: ajustes, documentación de privacidad, arquitectura de red o telemetría, ubicaciones de registros e instrucciones de eliminación.

4. Confirma las rutas exactas que admite

«Convierte cientos de formatos» es menos útil que una matriz explícita de origen a destino. El nombre de un formato puede ocultar límites importantes:

• un contenedor puede incluir códecs no compatibles;
• convertir una hoja puede afectar a fórmulas, fechas o ceros iniciales;
• pasar un documento a PDF puede cambiar fuentes o diseño;
• una imagen animada exige conservar fotogramas y tiempos;
• un archivo cifrado o firmado puede requerir rechazo, no reescritura;
• algunos archivos quizá solo se acepten para extraer o comprimir, no para cualquier conversión.

Elige rutas representativas del trabajo real de la organización. No utilices una prueba PNG a JPG para inferir el comportamiento de documentos, audio o vídeo.

Evidencia que debes solicitar: matriz actual de rutas, limitaciones relevantes, muestras de prueba versionadas y orientación para revisar en la aplicación de destino.

5. Verifica la conservación del original y los nombres de salida

La opción predeterminada más segura para una herramienta de transformación es dejar el original en su lugar y crear un resultado aparte. Confírmalo en condiciones normales y cuando ya exista un archivo con el nombre previsto.

Prueba qué ocurre en esa colisión. Una aplicación segura no debe sobrescribir en silencio el original ni un resultado anterior. Debe elegir otro nombre, pedir una decisión consciente o fallar de forma clara.

Los resultados independientes reducen el riesgo de sobrescritura accidental. No sustituyen a una copia de seguridad. La organización aún necesita protección separada para los originales irreemplazables.

La revisión debe probar los comportamientos reales que exponga el producto: misma carpeta, carpeta fija y preguntar cada vez.

Evidencia que debes solicitar: reglas de nombre, ajustes de destino, comportamiento ante colisiones y hashes del original antes y después.

6. Prueba los fallos, no solo los resultados correctos

Los fallos de conversión son normales. Un archivo puede estar dañado, cifrado, firmado, mal formado, mal etiquetado, codificado con un códec no compatible o fuera de la ruta declarada.

Pregunta qué hace el producto cuando no puede producir un resultado fiable:

• ¿Crea un resultado parcial?
• ¿Deja archivos temporales?
• ¿Conserva intacto el original?
• ¿El error orienta a la persona?
• ¿Pueden revisarse los diagnósticos sin transmitir automáticamente el original?
• ¿Continúa un lote de forma segura cuando falla una fila?

Una pantalla de éxito bien diseñada dice poco sobre estos límites. Incluye al menos una muestra inválida o no compatible.

Evidencia que debes solicitar: mensajes de fallo, ausencia de resultados imprevistos, gestión de temporales y registros de diagnóstico locales.

7. Inspecciona los componentes incluidos y los avisos

Los convertidores de escritorio suelen apoyarse en motores establecidos de medios y documentos. Esto ofrece funciones amplias y conocidas, pero también crea una responsabilidad de mantenimiento.

Identifica cada componente empaquetado, su función, versión, avisos de licencia y vía de actualización. Pregunta cómo responde el proveedor a las correcciones de seguridad relevantes del proyecto original. Un componente respetado no es una vulnerabilidad por sí mismo ni sustituye la revisión del producto completo.

LocalFlux documenta ImageMagick para imágenes compatibles, FFmpeg para audio y vídeo, LibreOffice para documentos y qpdf para compresión PDF. Incluye avisos de terceros. El directorio de formatos de LocalFlux sigue definiendo el límite del producto; los motores subyacentes pueden realizar más operaciones de las que promete la interfaz.

Evidencia que debes solicitar: avisos de terceros, inventario y versiones de componentes, y mecanismo de actualización del producto.

Asigna a alguien la revisión de avisos de seguridad relevantes, el inventario de versiones instaladas y la obtención de actualizaciones por el canal aprobado. Un motor incluido también necesita mantenimiento. Documenta qué cambios exigen repetir el piloto, en vez de convertir una prueba antigua en una aprobación permanente.

8. Verifica el paquete, el editor y el canal de actualización

Registra identidad, versión, arquitectura, editor y fuente de distribución del paquete instalado. En software empaquetado para Store, diferencia la certificación y firma de Store de una auditoría de seguridad independiente. No son equivalentes.

Microsoft documenta sus directivas de Store y las opciones de distribución de aplicaciones Windows. Utiliza estas fuentes para comprender la plataforma y después evalúa al proveedor y paquete concretos.

Confirma cómo se entregan las actualizaciones y si la organización puede probar los cambios importantes antes de desplegarlos. Registra la versión en cada piloto para que las conclusiones no queden separadas de la compilación que las produjo.

Evidencia que debes solicitar: identidad, editor, estado de firma, versión, arquitecturas, documentación de actualización y contacto de vulnerabilidades.

9. Comprueba permisos y capacidades de la aplicación

Revisa las capacidades declaradas por el paquete y compáralas con la tarea del producto. Microsoft proporciona documentación sobre las declaraciones de capacidades de las aplicaciones Windows.

Una declaración no demuestra que se haya producido todo acceso posible. Es un dato más. Combínalo con observación durante la ejecución, documentación de código o arquitectura cuando exista y pruebas representativas.

Presta atención al acceso amplio a archivos, red, almacenamiento extraíble, bibliotecas del usuario, micrófono, cámara, ubicación, ejecución en segundo plano y procesos secundarios. El conjunto esperado depende del diseño.

Evidencia que debes solicitar: capacidades del manifiesto y explicación de por qué se necesita cada una.

Microsoft indica que las aplicaciones de escritorio de plena confianza pueden acceder a la red sin declarar internetClient. Su ausencia no implica aislamiento. Documentación de Microsoft

10. Revisa almacenamiento local, temporales y limpieza

Una conversión puede crear archivos de trabajo, cachés, vistas previas, registros, resultados y candidatos abandonados. Determina:

• dónde se almacena cada categoría;
• si los nombres revelan clientes o proyectos;
• qué queda tras éxito, fallo, cancelación, restablecimiento y desinstalación;
• qué puede eliminar el usuario;
• si la retención o la eliminación segura deben resolverse fuera del producto.

No describas el almacenamiento local como privado por defecto. Otros usuarios, administradores, malware, copias de seguridad, indexadores o el acceso físico pueden alcanzar los datos según los controles de Windows y la organización.

Evidencia que debes solicitar: ubicaciones de almacenamiento, controles de limpieza y pruebas de fallo o cancelación.

11. Define comprobaciones para aceptar el resultado

Una conversión completada no equivale a una salida aceptada. Define controles por familia:

Familia	Revisión mínima
Imágenes	Dimensiones, orientación, transparencia, animación, calidad visible y política de metadatos
Audio	Duración, reproducción al inicio, centro y final, canales, frecuencia de muestreo y contenido esperado
Vídeo	Duración, reproducción, audio, sincronización, rotación, dimensiones, fotogramas por segundo y calidad visible
Documentos	Número de páginas, diapositivas u hojas, fuentes, diseño, enlaces, notas, tablas, gráficos, fórmulas, fechas y contenido oculto

Revisa el archivo en la aplicación de destino siempre que sea posible. Conserva el original hasta que el resultado haya superado los controles y el periodo de retención exigidos.

Evidencia que debes solicitar: pasos documentados y resultados esperados y observados de muestras representativas.

12. Evalúa el modelo comercial y de administración

Una aplicación puede superar la prueba de procesamiento local y seguir siendo inadecuada para la organización. Pregunta por:

• derechos de uso comercial;
• licencia por persona o por dispositivo;
• compra de varias licencias;
• facturas y documentos fiscales;
• reasignación de licencias;
• despliegue administrado;
• instalación y actualización silenciosas;
• configuración central;
• canales de soporte y compromisos de respuesta;
• fin de vida y exportación de datos.

No deduzcas preparación empresarial de una ficha de Microsoft Store. La documentación actual de Intune sobre aplicaciones de Store indica que el flujo vigente no admite aplicaciones de pago. Un proveedor puede ofrecer otro método, pero debe verificarse para el producto exacto.

LocalFlux ofrece actualmente una prueba autoservicio en Store y una compra única. No documenta públicamente licencias por volumen, administración central, configuraciones obligatorias de organización, RBAC, SSO, informes para administradores, acuerdo de tratamiento de datos ni SLA empresarial. Por ello encaja hoy mejor con profesionales individuales y equipos pequeños autogestionados que con una flota empresarial centralizada.

Tabla compacta de evaluación

Área	Condición para aprobar	Evidencia
Límite de procesamiento	Recorrido de origen y salida explícito y reproducible	Flujo de datos y prueba sintética
Límite de red	La conversión funciona bajo la condición sin conexión declarada	Observación por proceso y versión
Privacidad	Cuenta, telemetría, diagnósticos y almacenamiento documentados	Páginas de privacidad y ajustes
Alcance de rutas	Parejas de origen y salida necesarias explícitas	Matriz y muestras representativas
Seguridad del original	Originales intactos y colisiones seguras	Hashes y prueba de nombre en conflicto
Seguridad ante fallos	Entrada inválida o no compatible falla con claridad	Muestra límite y revisión de salida
Cadena de suministro	Componentes, editor y actualizaciones conocidos	Avisos, identidad y canal de actualización
Calidad de salida	Supera los controles del destino	Tabla de esperado y observado
Adecuación empresarial	Compra, despliegue, soporte y control encajan	Revisión comercial y de TI

Utiliza Aprobado, Condicional, Fallido o No aplicable. No sometas cada utilidad pequeña al mismo cuestionario que una plataforma crítica en la nube. Tampoco omitas un requisito relevante porque sea barata.

Añade No probado como estado independiente cuando no puedas obtener evidencias. Evita que un control no disponible, una ventana de prueba vencida o una observación inconclusa se conviertan en aprobado. Asigna responsable y fecha a cada elemento no probado que afecte a la decisión, y decide si bloquea el uso o limita su alcance.

Ejemplo: qué puede demostrar LocalFlux y qué no

El Centro de confianza de LocalFlux afirma que los trabajos compatibles procesan el original y el resultado en el dispositivo Windows, sin servidor de conversión de Fuzzysense. Separa el tráfico de Store y navegador del procesamiento, documenta que no se requiere cuenta ni analítica de uso normal, identifica diagnósticos locales, enumera motores incluidos, explica los nombres de salida independientes y proporciona una prueba sin conexión.

El paquete editorial x64 1.0.8.0 conservado se probó con entradas sintéticas DOCX, PNG y WAV. Produjo salidas PDF, JPG y MP3; los originales registrados no cambiaron; y la repetición de PNG creó un nombre distinto y seguro frente a colisiones. Las observaciones solo respaldan esas muestras y esa compilación.

El equipo editorial no tenía permisos de administrador para crear la regla temporal de cortafuegos por proceso prevista. Windows rechazó la regla, no quedó ninguna activa y el criterio sin conexión se registró como No probado. La limitación importa: crear una salida local no demuestra por sí solo que el proceso no pudiera establecer una conexión. Si la organización necesita una prueba de red independiente, debe repetir la ruta con un control aprobado o telemetría fiable del dispositivo.

La nueva prueba DOCX del 13 de octubre repitió la conversión tras reiniciar la aplicación. El primer PDF conservó su SHA-256 y el segundo usó el sufijo (2). La captura muestra el segundo resultado; el registro enlazado documenta ambos archivos.

Una salida independiente reduce la sobrescritura accidental. No proporciona copia de seguridad, aplicación de retención ni auditoría central.

Las evidencias no demuestran cumplimiento normativo, ausencia de malware, borrado seguro, fidelidad perfecta, automatización desatendida, procesamiento en unidades de red, políticas centrales ni despliegue empresarial. Estas conclusiones requieren otras funciones del producto y evidencias de la organización.

Convierte la lista en un piloto controlado

Termina la revisión documental antes de introducir archivos de trabajo reales. Después realiza un piloto pequeño con muestras sintéticas que representen los formatos necesarios y los fallos importantes.

Registra identidad del paquete, entorno, hashes de origen y salida, rutas exactas, condición de red, colisiones y revisión en la aplicación de destino. Decide qué clasificaciones se permiten, quién puede usar la herramienta y qué debe escalarse.

Revisa el límite de procesamiento de LocalFlux, confirma las rutas compatibles y evalúa la prueba de Microsoft Store con datos no sensibles antes de tomar una decisión para la organización.