---
title: "Cómo organicé 200.000 archivos y 40 años de trabajo con IA: la metodología que aplicamos para nuestros clientes"
date: 2026-05-07
author: "Alex Borrás"
version: "2.0 - Cliente HiDrive nativo"
source: https://alexborras.com/como-organice-200-000-archivos-y-40-anos-de-trabajo-con-ia-la-metodologia-que-aplicamos-para-nuestros-clientes/
site: "El Blog de Alex Borrás"
---

# Cómo organicé 200.000 archivos y 40 años de trabajo con IA: la metodología que aplicamos para nuestros clientes

Por qué una guía de organización e indexación de 200.000 archivos y 40 años de trabajo. Ayudamos a profesionales veteranos a organizar e indexar décadas de archivos acumulados. La pregunta inevitable es: ¿hacéis lo mismo con vuestro propio archivo? La respuesta corta es sí. Después de cuarenta años en el sector informático, con cerca de 200.000 archivos repartidos entre Google Drive, Dropbox, varios discos duros y unas 20.000 notas de Evernote, decidí aplicarme la misma metodología que aplicamos a nuestros clientes. Esta guía documenta esa arquitectura paso a paso.

Esta guía documenta la metodología que he diseñado para organizar, proteger e indexar todo ese conocimiento. No es una propuesta teórica: es la arquitectura que estoy aplicando, pensada para resistir el paso del tiempo, los cambios de proveedor y los riesgos a los que se enfrenta cualquier persona que produce contenido sensible (en mi caso, comunicación política aunque también aplicable a temas médicos y estudios sociales personales).

La guía sigue un orden lógico de capas, de la más fundamental a la más avanzada. Cada decisión está razonada, no es estética.

Índice de contenidos

- [1 Fase 1. IONOS HiDrive como repositorio central](#Fase_1_IONOS_HiDrive_como_repositorio_central)
    - [1.1 Por qué uso el cliente nativo HiDrive](#Por_que_uso_el_cliente_nativo_HiDrive)
- [2 Fase 2. Drive y Dropbox solo para el día a día](#Fase_2_Drive_y_Dropbox_solo_para_el_dia_a_dia)
- [3 Fase 3. Backup en frío como tercera capa](#Fase_3_Backup_en_frio_como_tercera_capa)
- [4 Fase 4. Migración progresiva a Markdown](#Fase_4_Migracion_progresiva_a_Markdown)
- [5 Fase 5. Herramientas de IA gratuitas para indexar el conocimiento](#Fase_5_Herramientas_de_IA_gratuitas_para_indexar_el_conocimiento)
- [6 Fase 6. El futuro: una IA propia que lo conozca todo](#Fase_6_El_futuro_una_IA_propia_que_lo_conozca_todo)
- [7 Fase 7. Aspectos complementarios a considerar](#Fase_7_Aspectos_complementarios_a_considerar)
- [8 Conclusión](#Conclusion)
- [9 Anexos](#Anexos)
    - [9.1 Anexo 1: Tabla de referencias](#Anexo_1_Tabla_de_referencias)
    - [9.2 Anexo 2: Checklist](#Anexo_2_Checklist)
    - [9.3 Anexo 3: Log](#Anexo_3_Log)

## Fase 1. IONOS HiDrive como repositorio central

La primera decisión, y la más contraintuitiva para quien trabaja a diario con Google, es **no dejar el archivo histórico en Google Drive**. Drive es excelente para trabajo activo, pero presenta dos vulnerabilidades estructurales que afectan a cualquier persona que produzca contenido susceptible de polémica: política, periodismo, opinión, investigación.

**El riesgo real del bloqueo de cuenta**. Google ha bloqueado cuentas de usuarios por algoritmos automáticos sin revisión humana, y la recuperación puede tardar semanas o no producirse nunca. No es un escenario hipotético: hay casos documentados de profesionales que han perdido años de trabajo de un día para otro. Para alguien con perfil político, comunicación electoral o análisis crítico, la diversificación geográfica y jurisdiccional no es paranoia: es prudencia profesional.

**Por qué IONOS y no otro proveedor europeo**. Existen alternativas robustas como Hetzner, pCloud o Infomaniak, todas con jurisdicción europea. He elegido [IONOS HiDrive](https://www.ionos.es/soluciones-oficina/hidrive-almacenamiento-en-la-nube) Business 1 TB por tres razones: ya era cliente, los centros de datos están certificados ISO 27001 y operan exclusivamente en Europa, y el soporte está en español. El precio post-promoción (7 €/mes por 1 TB) es competitivo a largo plazo. El cumplimiento del RGPD está garantizado y los datos no se monetizan, a diferencia de las plataformas estadounidenses.

**La arquitectura es invertida respecto al uso habitual**. La mayoría de la gente usa Drive como almacén principal y otros servicios como espejo. Mi arquitectura hace lo contrario: **IONOS es el repositorio histórico principal**, y Drive y Dropbox quedan reservados para trabajo activo del día a día. Si Google bloquea la cuenta mañana, pierdo trabajo en curso, no archivo histórico. Es una distinción cualitativamente distinta.

### Por qué uso el cliente nativo HiDrive

Tras evaluar las opciones disponibles, he optado por el **cliente nativo HiDrive de IONOS** para la sincronización entre mi PC y el almacenamiento en la nube. La decisión es deliberada y se basa en cuatro criterios:

**1. Operativa visual y familiar**. El cliente HiDrive integra el almacenamiento en el explorador de Windows con iconos de estado tipo Dropbox. Esto reduce la fricción operativa diaria a cero: no hay que aprender comandos, no hay que abrir terminales, no hay que escribir scripts. Para alguien que lleva décadas trabajando con clientes de sincronización gráficos (Drive, Dropbox), el modelo mental es idéntico.

**2. Notificaciones nativas de errores**. El cliente HiDrive notifica visualmente conflictos y errores de sincronización en tiempo real, igual que Drive o Dropbox. No hay que mirar logs ni configurar alertas externas. Si algo va mal, te enteras al instante.

**3. Velocidad no es restricción operativa**. Sí, el cliente HiDrive es más lento que rclone para uploads masivos. Pero la migración inicial de 200.000 archivos no tiene prisa: se puede ejecutar progresivamente por las noches y en momentos en que el PC no está en uso intensivo. El "patient architecture" que defiendo aplica también a la migración: si tarda dos semanas en lugar de tres días, no es un problema real.

**4. rclone queda como herramienta de bolsillo**. Mantengo rclone instalado y configurado en `C:\Tools\rclone` para tareas puntuales especializadas: backup en frío trimestral automatizable, verificación de integridad bit a bit con `rclone check` cuando dude de algo, o operaciones masivas concretas. No es la pieza central, pero está disponible cuando hace falta.

La guía de configuración detallada de rclone, por si decido recuperarlo como herramienta principal en el futuro, está documentada en un anexo aparte: **Configuración de Rclone para IONOS HiDrive.md**.

## Fase 2. Drive y Dropbox solo para el día a día

Una vez IONOS ocupa el papel de repositorio histórico, los servicios estadounidenses recuperan su mejor uso: trabajo activo y colaboración.

[Google Drive](https://drive.google.com) cumple aquí muy bien. Tengo contratados 5 TB de los que uso aproximadamente 105 GB. La velocidad es excelente, la integración con el ecosistema Google Workspace es difícil de igualar, y la colaboración en tiempo real sobre Google Docs sigue siendo superior a cualquier alternativa. Lo uso para trabajo en curso: artículos en redacción, documentos compartidos con clientes, materiales de proyectos vivos.

[Dropbox](https://www.dropbox.com) tiene un papel específico y distinto: alberga el vault de [Obsidian](https://obsidian.md) en el que estoy migrando 20.000 notas desde Evernote. La razón es una técnica concreta. Obsidian escribe muchos archivos pequeños muy rápido (cada vez que editas una nota, mueve archivos cuando reorganizas, los plugins escriben metadatos). Drive maneja mal este patrón y genera archivos duplicados con sufijos tipo «(1)» o «(conflicto)». Dropbox sincroniza fichero a fichero con menor latencia y resulta más fiable para este patrón de uso intensivo.

**La metodología es generalizable**. Aunque uso Drive y Dropbox, el principio aplica a cualquier combinación: OneDrive, iCloud, Box. La regla operativa es la misma: el servicio rápido y colaborativo se usa para trabajo activo; el servicio europeo independiente se usa para archivo histórico; los dos están separados deliberadamente.

**El movimiento entre capas es manual y consciente**. Cuando un proyecto pasa de «activo» a «histórico», lo muevo a IONOS. No hay sincronización automática que propague todo el contenido de Drive a IONOS, porque eso desvirtuaría el papel de cada capa. La transición de un documento de «vivo» a «archivado» es una decisión informada que tomo yo.

## Fase 3. Backup en frío como tercera capa

La regla 3-2-1 del backup profesional dice que cualquier información crítica debe existir en tres copias, en dos soportes distintos, con una de ellas fuera de línea. Mi arquitectura cumple esta regla:

- COPIA 1: Disco local del PC
- COPIA 2: IONOS (jurisdicción UE) + Google Drive (trabajo activo)
- COPIA 3: Disco duro externo desconectado físicamente

El backup en frío trimestral en disco duro externo cubre un riesgo que ninguna copia online puede cubrir: la **corrupción silenciosa**. Si un archivo se corrompe en local por un fallo de disco, malware o error humano, esa corrupción se propaga a Drive e IONOS en la siguiente sincronización. La protección real ante ese escenario la da una copia desconectada físicamente, no presente en ninguna red.

**La frecuencia trimestral es deliberada**. Un backup mensual sería innecesariamente frecuente para mi volumen de cambios; uno anual dejaría una ventana de pérdida demasiado amplia. Cada tres meses conecto el disco externo, copio el contenido relevante, verifico que el conteo de archivos coincide con lo esperado, y vuelvo a desconectar el disco. La operación dura menos de una hora.

**Para la copia en frío uso rclone**. Es una de las pocas tareas en las que el cliente nativo HiDrive no encaja: necesito una operación scriptable, ejecutable bajo demanda, con verificación de integridad bit a bit (`rclone check`). rclone está perfecto para esto. La configuración está documentada en la guía complementaria.

**Importante**: el disco externo no se usa nunca para nada más. No es disco de trabajo, no es disco de transporte. Vive guardado en un cajón y solo sale para la operación trimestral. Esta disciplina es la que garantiza que el snapshot capturado representa fielmente el estado del corpus en el momento del backup.

## Fase 4. Migración progresiva a Markdown

Una decisión funcional crucial en la arquitectura es que **todo lo que llega al archivo histórico entra en formato abierto**. Inicialmente planteé la conversión automática de Google Docs (.gdoc, .gsheet) a Office (.docx, .xlsx) durante la sincronización. Después de analizarlo en detalle, he optado por una estrategia más radical y mejor alineada con mi visión a largo plazo: **migración progresiva a Markdown**.

**¿Por qué Markdown y no Office?** Tres razones que se refuerzan entre sí:

**1. Durabilidad máxima a 40 años**. Markdown es texto plano legible por cualquier programa, sin formatos propietarios, sin dependencias de software. Dentro de cuatro décadas seguirá siendo perfectamente legible. Office tiene mejores garantías que .gdoc, pero no las de Markdown.

**2. Convergencia con Obsidian**. Estoy migrando 20.000 notas de Evernote a Obsidian, que usa Markdown nativamente. Si todo el corpus histórico textual también vive en Markdown, el conjunto queda **unificado en un único sistema** con búsqueda, enlaces internos, y luego indexación semántica futura con Khoj o AnythingLLM (que precisamente brillan con Markdown).

**3. Eliminación de un problema operativo**. La conversión gdoc→docx era un punto de complejidad recurrente: qué herramienta usar, qué se preserva, qué se pierde, cuándo ejecutar, cómo mantenerla. Adoptando Markdown, ese problema desaparece estructuralmente. La conversión a Markdown se hace una vez, manualmente, en el momento en que decido archivar un documento.

**Pero no todo va a Markdown**. La regla útil es: si lo que importa del documento es el **texto y las ideas**, va a Markdown. Si lo que importa es la **forma visual final**, mejor `.docx` o PDF.

| Tipo de contenido | Formato destino | Razón |
|---|---|---|
| Notas, artículos, ensayos, ideas, documentación | Markdown (.md) | Texto puro con estructura básica |
| Hojas de cálculo (Excel, gsheet) | .xlsx | Markdown no maneja celdas, fórmulas, gráficos |
| Presentaciones | .pptx | Markdown no es visual |
| Contratos, propuestas formales, cartas oficiales | .docx o .pdf | Formato profesional para enviar |
| Material gráfico, fotos, vídeos | Formato original | No aplica conversión |

**El patrón de migración**. No convierto todo de golpe. Aplico **migración progresiva por valor**: cuando toco un documento (lo consulto, lo edito, lo reviso), lo convierto a Markdown si encaja en el perfil. Si un documento lleva 5 años sin abrirse, no urge: se queda en su formato original dentro del archivo. Esto se alinea con el principio de "patient architecture": la migración que importa es la del material **vivo**, no la del 90% que probablemente nunca volveré a tocar.

**Las herramientas de conversión**:

- **Conversión manual**: Google Docs tiene desde 2024 una opción nativa de descarga en Markdown. Archivo → Descargar → "Markdown (.md)". Para conversión documento por documento, es la vía más limpia.
- **Conversión semi-automática**: [Pandoc](https://pandoc.org/) en local, ejecutado sobre archivos `.docx` previamente descargados. Útil cuando hay un lote de varios documentos relacionados.
- **Conversión masiva** (raramente necesaria con esta estrategia): Google Takeout para exportar todo Drive como ZIP de archivos `.docx`, después script en PowerShell o Python ejecutando Pandoc por lotes.

**Misma lógica para Evernote**. Las 20.000 notas que estoy migrando desde [Evernote a Obsidian](https://alexborras.com/obsidian-y-gtd-potencia-tu-productividad-con-la-herramienta-definitiva-para-la-gestion-del-conocimiento/) siguen el mismo principio: dejar el formato propietario (.enex) y pasar a Markdown plano.

**La regla universal**: cuanto más sensible es un dato y más larga su vida útil esperada, más importante es que viva en formato abierto. Para un archivo histórico de cuatro décadas de trabajo, esta regla no admite excepciones.

## Fase 5. Herramientas de IA gratuitas para indexar el conocimiento

Tener 200.000 archivos bien organizados resuelve la mitad del problema. La otra mitad es **encontrar lo que necesitas cuando lo necesitas**. La búsqueda tradicional por nombre de archivo o palabra clave funciona mal a esta escala: requiere recordar exactamente cómo escribiste algo hace diez años. La solución es la búsqueda semántica con IA, que entiende el significado y no solo las palabras.

Las opciones disponibles cubren todo el espectro entre privacidad total y máxima potencia.

[**AnythingLLM**](https://anythingllm.com) es una de las herramientas más completas. Apunta la aplicación a una carpeta y procesa todos los archivos generando embeddings (representaciones matemáticas del significado) que se almacenan en una base vectorial local. Cuando haces una pregunta, AnythingLLM recupera los fragmentos relevantes y se los pasa al modelo de IA que elijas. Soporta Claude, GPT, Gemini y modelos locales. Es la opción más versátil.

[**Khoj**](https://khoj.dev) es un asistente personal open source que indexa Obsidian, Notion, GitHub y carpetas locales. Su integración con Obsidian es especialmente cuidada, lo cual lo hace muy interesante para usuarios que ya tienen su conocimiento estructurado en Markdown. La búsqueda semántica más el chat sobre tus propios documentos cubren la mayoría de necesidades de un trabajador del conocimiento. **Para quien adopta la estrategia de migración a Markdown, Khoj es la opción natural.**

[**NotebookLM**](https://notebooklm.google.com) es la propuesta de Google para esta categoría. Su limitación es que el corpus se sube a servidores de Google, lo cual contradice la lógica de toda esta arquitectura. Útil para experimentar, no para indexación seria del archivo histórico.

[**Paperless-ngx**](https://docs.paperless-ngx.com) es la referencia open source para gestión documental personal con OCR automático, etiquetado con machine learning y full-text search, todo en local. Especialmente recomendable si tienes mucho material escaneado en PDF que necesita reconocimiento de texto.

**Modelos locales con [Ollama](https://ollama.com) o [LM Studio](https://lmstudio.ai)**. Esta es la opción que más respeta la privacidad. Ejecutas el modelo de IA completamente en tu propia máquina, sin que ningún fragmento del corpus salga de tu PC. La calidad de los modelos abiertos (Llama 3.3, Qwen 2.5, Mistral) ha mejorado dramáticamente en 2025 y 2026, hasta el punto de ser comparables a modelos comerciales para muchas tareas. Requiere hardware decente (preferiblemente con GPU) pero el coste operativo es cero una vez instalado.

**La estrategia escalonada que estoy aplicando**. No utilizo todas estas herramientas a la vez. La búsqueda semántica entrará en juego cuando el corpus consolidado en IONOS esté completo. Hasta entonces, sigo trabajando con búsqueda tradicional, que para el volumen de archivos verdaderamente activos sigue siendo suficiente.

## Fase 6. El futuro: una IA propia que lo conozca todo

Si las cinco fases anteriores son arquitectura presente, la sexta es horizonte. Estamos en un punto de inflexión tecnológico que cambia la forma de pensar sobre el conocimiento personal.

**Las IA locales están madurando rápidamente**. Lo que en 2024 requería conocimiento técnico avanzado y hardware caro, hoy se instala con un par de clics. Modelos como Llama 3.3 y Qwen 2.5 corren en hardware doméstico con calidad cada vez más cercana a los modelos cloud. La trayectoria es clara: en 12-24 meses tendremos asistentes personales completamente locales con capacidades comparables a los productos comerciales actuales.

**El modelo de «contexto persistente» está llegando**. Los grandes laboratorios de IA (Anthropic, OpenAI, Google) trabajan en formas de que el modelo «recuerde» un corpus completo sin necesidad de recuperación fragmento a fragmento. Cuando esto madure, el patrón de uso cambiará: en lugar de hacer preguntas puntuales y recibir respuestas con fragmentos recuperados, podrás dialogar con un asistente que conoce tu trabajo completo de forma global, como conoce un colaborador veterano que lleva veinte años contigo.

**Mi visión del futuro inmediato es construir esa IA propia**. Una entidad digital que:

- Conozca todo mi corpus profesional y personal.
- Entienda los patrones de mi pensamiento y de mis intereses.
- Pueda razonar sobre conexiones entre proyectos lejanos en el tiempo.
- Funcione en local sin que ninguna información salga de mi infraestructura.
- Sea propiedad mía, no producto de un proveedor externo que pueda cambiar las reglas del juego.

**Por qué esperar es la decisión correcta**. La paciencia tiene fundamento empírico para alguien que arrancó en informática en los 80 con minicomputadores VAX y ha visto pasar cuarenta años de tecnología. He visto demasiadas veces cómo la solución óptima de hoy es el legacy doloroso de mañana. Construir hoy una infraestructura RAG compleja sería trabajo desperdiciado si en doce meses los modelos con contexto persistente la dejan obsoleta.

**Mientras tanto, capitalizo trabajo**. Cada archivo que consolido en IONOS, cada nota migrada de Evernote a Obsidian, cada documento convertido a Markdown, es trabajo que **sirve para cualquier futuro tecnológico**. Independientemente de qué herramienta de IA termine adoptando, todo este material estará listo para ser indexado, procesado y comprendido por ese sistema futuro.

## Fase 7. Aspectos complementarios a considerar

Esta sección recoge cuestiones que surgen al implementar la arquitectura y que conviene tener resueltas.

**Estructura de carpetas**. La reorganización completa de 200.000 archivos no se hace en una semana. La aproximación realista es por fases: primero consolidar físicamente todo en IONOS respetando las estructuras de origen (con prefijos identificativos del origen), después definir una taxonomía maestra coherente con áreas reales de trabajo, y finalmente migrar progresivamente desde la estructura de origen a la nueva. La búsqueda semántica funciona bien independientemente de la estructura de carpetas, lo cual permite empezar a aprovechar el corpus consolidado mucho antes de tener la reorganización terminada.

**Privacidad por capas**. No todo el contenido tiene la misma sensibilidad. Material profesional ordinario, material político, material bajo NDA, material personal íntimo: cada categoría puede requerir un trato distinto. La arquitectura aquí descrita permite segmentar: la IA local procesa lo más sensible sin que salga de la máquina; las IA cloud procesan lo no sensible cuando se requiere mayor potencia.

**Verificación periódica**. Una arquitectura de backup que nadie verifica es una arquitectura que no funciona el día que se necesita. Cada seis meses ejecuto una restauración de prueba: tomo un archivo aleatorio de IONOS y otro del backup en frío y compruebo que se abren correctamente. Detectar un problema en una verificación rutinaria es muy distinto a descubrirlo el día que se necesita el archivo de verdad. **Para verificación de integridad masiva uso rclone check**, que compara checksums bit a bit entre origen y destino.

**Caracteres inválidos en nombres de archivo**. Con 200.000 archivos de 40 años, vas a encontrarte con nombres que HiDrive no acepta (caracteres especiales, longitudes excesivas, ñ y tildes en algunos casos). El cliente nativo HiDrive avisa de estos casos en una "carpeta de conflictos" durante la migración inicial. Conviene revisar esa carpeta periódicamente y renombrar los problemáticos.

**Documentar la propia metodología**. Este artículo es, en sí mismo, parte de la arquitectura. Si en cinco años tengo que reconfigurar todo desde cero, este documento es la referencia que me explica las decisiones tomadas y por qué. Documentar las decisiones es tan importante como tomarlas.

**Evolución continua**. Esta no es una arquitectura definitiva. Cada año reviso si las herramientas elegidas siguen siendo las mejores opciones disponibles, si los proveedores mantienen sus condiciones, si han aparecido alternativas superiores. La metodología es estable; las herramientas concretas son sustituibles.

## Conclusión

Cuarenta años de trabajo no se organizan en una semana ni en un mes. Esta arquitectura es paciente por diseño: respeta el ritmo real al que se mueve el trabajo profesional y al que se mueve la tecnología. Combina prudencia (jurisdicción europea, formatos abiertos, backup en frío) con ambición (búsqueda semántica con IA, horizonte de asistente personal completo).

La pregunta no es si vale la pena hacer todo esto. La pregunta es qué se pierde si no se hace. Mi respuesta personal: demasiado. Los archivos que acumulamos son la materia prima de nuestro trabajo futuro. Tratarlos como activo estratégico, no como acumulación accidental, es la diferencia entre seguir creciendo profesionalmente o quedar atrapado en un caos de información imposible de recuperar.

## Anexos

### Anexo 1: Tabla de referencias

| **Herramienta** | **Categoría** | **Enlace** |
| --- | --- | --- |
| IONOS HiDrive | Almacenamiento europeo | [https://www.ionos.es/soluciones-oficina/hidrive-almacenamiento-en-la-nube](https://www.ionos.es/soluciones-oficina/hidrive-almacenamiento-en-la-nube) |
| Cliente HiDrive Windows | Sincronización principal | Descarga desde el web de IONOS HiDrive |
| rclone | Herramienta complementaria (backup, verificación) | [https://rclone.org](https://rclone.org) |
| Pandoc | Conversión .docx → .md | [https://pandoc.org](https://pandoc.org) |
| Google Drive | Almacenamiento de trabajo activo | [https://drive.google.com](https://drive.google.com) |
| Google Takeout | Exportación masiva de Google | [https://takeout.google.com](https://takeout.google.com) |
| Dropbox | Almacenamiento para vault Obsidian | [https://www.dropbox.com](https://www.dropbox.com) |
| Obsidian | Sistema de notas en Markdown | [https://obsidian.md](https://obsidian.md) |
| AnythingLLM | RAG local con múltiples IA | [https://anythingllm.com](https://anythingllm.com) |
| Khoj | Asistente personal open source | [https://khoj.dev](https://khoj.dev) |
| NotebookLM | RAG cloud de Google | [https://notebooklm.google.com](https://notebooklm.google.com) |
| Paperless-ngx | Gestión documental con OCR | [https://docs.paperless-ngx.com](https://docs.paperless-ngx.com) |
| Ollama | IA local | [https://ollama.com](https://ollama.com) |
| LM Studio | IA local con interfaz gráfica | [https://lmstudio.ai](https://lmstudio.ai) |

### Anexo 2: Checklist

Esta es una tarea compleja que requiere ir haciendo paso a paso de forma tranquila y documentada. Por ello es imprescindible una lista de tareas o checklist. En mi caso me he decidido por Obsidian y forma md: [Checklist Implementación Indexación de Archivos.md](https://alexborras.com/wp-content/uploads/2026/05/Checklist-Implementacion-Indexacion-Archivos.md).

**Nota**: **md** hace referencia al sistema [Markdown](https://es.wikipedia.org/wiki/Markdown). Markdown (.md) es un lenguaje de marcado ligero creado por John Gruber en 2004 para escribir texto formateado usando solo caracteres comunes del teclado. En lugar de menús o botones, se aplican estilos mediante símbolos: almohadillas para títulos (`#`), asteriscos para negritas (`**texto**`), guiones para listas. El archivo resultante es texto plano legible incluso sin procesar, compatible con cualquier editor y a prueba de obsolescencia. Es el formato estándar en GitHub, Obsidian, Notion y la mayoría de aplicaciones de notas modernas, ideal para escritura técnica y documentación duradera.

### Anexo 3: Log

En este anexo voy a documentar paso a paso el avance que se ha ido realizando en el proyecto.

1. **Proyecto Claude**. Imprescindible empezar con un proyecto monográfico en la IA para desarrollar todo lo que vamos a hacer. El proceso requerirá muchas consultas y que mejor que tenerlas todas en un chat del mismo proyecto con un contexto completo. La misma función podemos tener en ChatGPT.

2. **Evaluación de herramientas de sincronización (mayo 2026)**. Inicialmente se planteó rclone como motor de sincronización. Tras la configuración y pruebas iniciales se identificaron dos puntos de fricción: la operativa por línea de comandos resulta menos cómoda que un cliente gráfico tipo Dropbox, y la falta de notificaciones nativas exige montar logs y alertas externas. Se decidió cambiar al **cliente nativo HiDrive** como herramienta principal, manteniendo rclone instalado como herramienta complementaria para tareas puntuales (backup en frío, verificación de integridad). La configuración detallada de rclone se documentó en una guía complementaria por si se decide retomarlo en el futuro.

3. **Cambio de estrategia en formato de archivo (mayo 2026)**. La planificación inicial contemplaba conversión automática gdoc → docx durante la sincronización. Tras analizarlo en profundidad, se cambió a una estrategia de **migración progresiva a Markdown**, mejor alineada con el ecosistema Obsidian que ya se está construyendo y con el horizonte de indexación semántica futura. La conversión deja de ser una operación de sincronización continua y pasa a ser una decisión consciente documento por documento, ejecutada en el momento del archivado.