BITÁCORA DIGITAL DE UN CIBERNAUTA

—Hola, quiero un implante que mejore mi visión.

—Ha llegado usted al lugar correcto, somos especialistas en hipervisión desde 2023 y miles de intervenciones nos avalan.

—Pero oiga, no necesito gran cosa, tengo un presupuesto bajo.

—No se preocupe por eso, nuestros planes de financiación se adaptan a todas las economías. Los créditos no serán un problema.

—Me alegra escuchar eso. ¿Qué me recomienda usted?

—Acaba de llegar la nueva colección primavera-verano 2040...

—Pero lo veo un poco recargado, ¿no cree?

—Es la última moda. Su capacidad visual mejorará un 300% y con el objetivo COMPUR de nueva generación podrá observar objetos a más de tres kilómetros con total nitidez. La tecnología alemana más puntera al servicio del consumidor de a pie.

—¿Y son necesarios todos estos engranajes?

—Bien, si desea aprovechar al 100% el zoom físico es necesario el addon pero es opcional en el diseño final. Aunque está cubierto por una piel sintética que disimula todo el hardware óptico que añadamos, no debe preocuparse por el aspecto estético.

—¿Alguna otra cosa que añadir?

—También disponemos de un módulo lacrimal pero aumenta bastante el precio final, además de incorporar un depósito de residuos y reciclaje.

—¿Y qué me permite ese módulo que encarece tanto?

—Llorar. Conseguimos dar sentimientos y en esta empresa eso se paga.

En la entrega anterior describía el algoritmo de análisis documental automatizado ejecutándose en local mediante agentes de IA de código abierto y afirmaba que modelos cuantizados de 7B o 14B parámetros funcionaban "aceptablemente" en hardware doméstico, un mes despues es momento de matizar esa afirmación porque la distancia entre "aceptable" y "usable en producción" es considerable. La realidad del procesamiento documental con agentes locales sobre una estación de trabajo domestica dista mucho de ser rapida: un único documento que en apariencia es simple pero que debe cruzarse con decenas de entidades preexistentes en el grafo, verificar consistencia temporal, extraer relaciones semánticas y asignar puntuaciones de verificación puede tardar varias horas en completar la primera capa de comprobación. Y esa es solo la primera de tres capas. El proceso completo de ingesta de un documento con todas sus verificaciones puede extenderse a días. La experiencia de supervisar un agente de IA trabajando es, dicho sin rodeos, extraordinariamente aburrido... Vas viendo un flujo de razonamiento en tiempo real, token a token, y cuando detectas una equivocación en el razonamiento del agente (una entidad mal clasificada, una fecha mal interpretada, una relación semántica incorrecta) te enfrentas a una decisión desagradable: interrumpir el proceso implica descartar todo el trabajo acumulado y reiniciar desde el principio, porque el estado intermedio del agente no es recuperable sin comprometer la integridad del resultado: Dejar que continúe con el error significa que las capas posteriores de verificación heredarán una premisa falsa y el resultado final será inservible. No existe un punto intermedio aceptable. Esto revela que el entrenamiento y la configuración de los agentes es tan importante como la calidad de los datos que procesan y la forma en que esos datos se les presentan. Un documento PDF escaneado con OCR imperfecto genera errores de extracción que se propagan en cascada. Un prompt de sistema mal calibrado produce clasificaciones inconsistentes. Una estructura de datos demasiado anidada confunde al modelo. La preparación del entorno de trabajo del agente consume tanto tiempo como el procesamiento en sí y cada iteración de mejora requiere volver a procesar los documentos anteriores para verificar que los ajustes no han introducido regresiones.

La atomización de variables, es decir, descomponer cada documento en unidades mínimas de información independientes antes de alimentar al agente, reduce la carga computacional por operación individual y mejora la precisión del análisis. Pero la contrapartida es directa: multiplicar las variables multiplica las relaciones potenciales entre ellas, y el coste de cruzar cada nueva variable con todas las existentes crece de forma no lineal. Un grafo de setenta entidades con cincuenta relaciones es manejable. Un grafo de setecientas entidades atómicas con las relaciones derivadas de su descomposición se convierte en un problema computacional que una GPU doméstica no puede resolver en tiempos razonables. Todo esto, en el fondo, se reduce a un problema simple: tiempo o dinero. Las tres vías de solución son evidentes y cada una tiene sus compromisos. La primera es usar modelos en la nube, donde proveedores como Anthropic, Google u OpenAI ofrecen capacidad de cómputo que supera en varios órdenes de magnitud lo que una estación de trabajo doméstica puede proporcionar, a cambio de que tus datos transiten por servidores de terceros, lo cual para documentación sensible puede ser inaceptable. La segunda es alquilar computación dedicada en servicios de GPU bajo demanda, que preserva algo más de control sobre los datos pero introduce costes recurrentes que escalan con el volumen de procesamiento. La tercera es esperar. La Ley de Moore, aunque matizada en los últimos años en CPUs, sigue vigente en el rendimiento por vatio de las GPU y en la eficiencia de los modelos cuantizados. Lo que hoy tarda días tardará horas en la siguiente generación y minutos en la posterior. El hardware doméstico alcanzará el umbral de usabilidad para este tipo de cargas de trabajo, la pregunta es simplemente cuándo. Mientras tanto, la paciencia es el recurso más barato y el más difícil de escalar...

En 2014, durante un curso de SEO, había una actividad consistía en crear una página corporativa en redes sociales y aproveché para exponer públicamente una idea que llevaba tiempo usando en mi entorno personal. La llamaba WiFiMesh y la premisa era sencilla: una Raspberry Pi, varias antenas WiFi y toda la potencia del software libre para construir una infraestructura de red doméstica autónoma, privada y replicable. El nombre no era casual: una de sus capacidades era formar redes libres malladas (mesh) con otros dispositivos cercanos si la conexión principal a internet se caía, manteniendo una funcionalidad limitada en modo isla.

La propuesta era sencilla un servidor para el hogar de bajo consumo con LAMP, DNS, Samba, VPN, TOR, backups, proxy-cache, firewall y herramientas de red. Una nube personal con correo cifrado por defecto, capaz de crear nodos WAN y facilitar conexiones privadas entre pares. En esencia, una capa de protección sobre tu conexión a internet que interponía tu propia infraestructura entre tus datos y el mundo exterior. Una especie de capa élfica TCP/IP: invisible para quien no sabe que existe, impenetrable para quien la busca. Y la idea funcionaba, la usaba a diario. Además era fácilmente replicable: una Raspberry Pi costaba treinta y cinco euros, las antenas WiFi USB se conseguían por menos de diez, y el software era íntegramente libre. Cualquier persona con conocimientos básicos de GNU/Linux podía montar su propio nodo en una tarde. La democratización de la infraestructura de red privada estaba al alcance de la mano. Pero la realidad técnica de la década impuso sus límites y empezaron los problemas...

El primero fue arquitectónico. La Raspberry Pi de primera y segunda generación compartía el bus de datos entre los puertos USB y la conexión Ethernet. Esto significaba que el ancho de banda total disponible se repartía entre el almacenamiento externo (conectado por USB), las antenas WiFi (USB) y la salida a internet (Ethernet). En la práctica, si estabas accediendo a tu nube privada por WiFi mientras el sistema hacía un backup al disco externo, la conexión a internet se degradaba hasta resultar inutilizable. El cuello de botella no era el software sino el silicio: un bus compartido a 480 Mbps teóricos que en la práctica no pasaba de 200, dividido entre todos los periféricos. Para un servidor que debía gestionar simultáneamente tráfico de red, almacenamiento y servicios cifrados, era insuficiente. Si escalabas el hardware, comenzaba a distanciarse de una solución económica...

El segundo fue político, o más precisamente, de gobernanza de internet. Montar tu propio servidor de correo electrónico en una dirección IP residencial te convertía automáticamente en sospechoso de spam. Los grandes proveedores (Gmail, Outlook, Yahoo) rechazaban por defecto cualquier correo procedente de ellas. No importaba que tu servidor estuviera correctamente configurado con SPF, DKIM y DMARC. No importaba que tu correo fuera legítimo y no contuviera un solo enlace, script o imagen: tus correos iban directos a spam o eran rechazados sin más. El correo electrónico autohospedado era técnicamente posible pero socialmente inviable: los grandes servicios centralizados habían construido un oligopolio de facto donde solo los servidores alojados en centros de datos reconocidos eran considerados legítimos.

El tercero fue de adopción. En 2014, la privacidad digital era una preocupación de nicho. Y eso que Assange estaba retenido en Londres y Snowden había publicado sus revelaciones apenas un año antes pero el público general aún no había interiorizado las implicaciones. Proponer a alguien que montara un servidor en su casa para proteger su intimidad era como proponer que fabricara su propio pan para evitar los aditivos industriales: técnicamente correcto, prácticamente inviable para la mayoría, y socialmente percibido como una excentricidad paranoica. ¿Para qué necesitas un bunker si no eres consciente de la guerra nuclear?

Hoy, en 2026, el panorama ha cambiado en casi todos los frentes. La Raspberry Pi 5 tiene Ethernet gigabit nativo en un bus dedicado, PCIe para almacenamiento NVMe y USB 3.0 separado. El cuello de botella de hardware ha desaparecido. Proyectos como FreedomBox, YunoHost o Umbrel han empaquetado exactamente la misma idea de WiFiMesh en distribuciones listas para instalar, con interfaces web que eliminan la barrera de conocimientos de GNU/Linux. La conciencia sobre privacidad digital se ha generalizado tras una década de escándalos de datos, legislaciones como el RGPD y la normalización del cifrado extremo a extremo... Aunque el problema del correo autohospedado sigue sin resolverse. Los oligopolios del email siguen siendo los mismos y las barreras de entrada para un servidor de correo legítimo siguen siendo prohibitivas. Pero el correo electrónico ha dejado de ser el centro de la comunicación digital: la mensajería cifrada ha ocupado ese espacio sin necesitar de una infraestructura centralizada, existen redes libres como guifi.net, WiFiMesh no llegó a ser un producto, fue una prueba de concepto adelantada a su tiempo, como tantas, limitada por el hardware disponible y por un ecosistema de internet que penalizaba la descentralización. Pero la idea subyacente, que cada persona debería controlar su propia infraestructura digital, sigue siendo tan válida hoy como lo era entonces. Quizá más si cabe.

GNUine Solutions (wifimesh.ljpaez.es)

En los dos post anteriores compartía el proceso de armonización documental en el que me hallaba inmerso y la publicación de Grafotrama como herramienta de análisis temporal. Ahora abordo la siguiente pregunta natural: ¿cómo convertir estas herramientas en un sistema integral que cualquier persona pueda desplegar, sin depender de infraestructura en la nube ni de servicios propietarios? La respuesta pasa por tres capas complementarias: un motor documental basado en MediaWiki, un grafo de conocimiento temporal con Grafotrama y una capa de automatización mediante agentes de IA de código abierto. Juntos conforman lo que podríamos denominar una radiografía verificable de hechos digitales.

MediaWiki no necesita presentación: es el motor que sustenta Wikipedia y millones de wikis especializadas en todo el mundo. Su elección para este proyecto no es casual. Cada página funciona como una ficha documental independiente: un correo, un contrato, una comunicación, una persona, un activo, un hecho... Cada una con su historial de revisiones, sus categorías y sus enlaces internos a otras fichas. La clave reside en que el relato se construye solo. No existe un documento maestro que haya que reescribir cada vez que aparece nueva información. Cuando un nuevo dato aparece, se analiza, si contradice lo anterior, entonces se crea o se actualiza una página y los enlaces cruzados revelan la contradicción automáticamente. Texto plano, exportable, auditable y resistente al paso del tiempo. Para un caso de uso, donde cada respuesta institucional genera nuevos datos que a su vez modifican el contexto de los anteriores, esta arquitectura es superior a cualquier documento lineal. La wiki absorbe la complejidad sin exigir reestructuración. Y el despliegue es accesible: PHP 8.2, una base de datos MySQL o MariaDB y un servidor web estándar. Cualquier hosting compartido de gama básica lo soporta. En local, una instalación en GNU/Linux se resuelve con un único comando. El coste de entrada es prácticamente cero.

Donde MediaWiki organiza documentos, Grafotrama organiza relaciones en el tiempo. La herramienta implementa un modelo de datos donde cada entidad posee un intervalo temporal. El motor incorpora el Álgebra de Intervalos de Allen, un marco formal que define relaciones entre dos intervalos de tiempo y sus inversas. La implementación crítica es que estas relaciones temporales se calculan automáticamente a partir de las fechas de cada entidad, no se declaran manualmente. ¿Por qué es esto relevante? Porque permite detectar inconsistencias sin emitir juicios de valor. El sistema no afirma que "A causó B". El sistema detecta que "A ocurrió DURANTE el periodo de B" y deja que el hecho hable por sí mismo. Un hecho verificable con fecha es infinitamente más poderoso que una inferencia causal. Esta filosofía, inspirada directamente en el proyecto Lifespan de Richard Northover y en su aplicación del álgebra de Allen a la representación de todo lo que existe en el tiempo, supone un cambio de paradigma: de la narrativa subjetiva al dato temporal objetivo.

Hasta ahora las dos capas anteriores requerían trabajo manual: alguien debe crear las páginas wiki, alguien debe introducir las entidades en el grafo. Para un caso puntual esto es manejable. Para una radiografía completa de una vida digital con miles de documentos, fotos, mensajes y transacciones, no lo es. Aquí entran los modelos de lenguaje de código abierto como Gemma (Google) o Qwen (Alibaba), ejecutables en local con requerimientos de hardware modestos. Un agente de IA puede realizar el análisis documental automatizado: recibe un documento, lo clasifica, extrae entidades (personas, fechas, importes, referencias, hechos, correos, formato, etc.), identifica relaciones con entidades ya existentes en el grafo y genera tanto la página wiki correspondiente como la entrada en el grafo de conocimiento. El aspecto más relevante de esta automatización es el sistema de puntuación de verificación. No toda información tiene el mismo peso probatorio. Un hecho afirmado por el titular sin constancia documental no posee la misma credibilidad que un hecho verificable por terceros confiables: un certificado administrativo, un sello de tiempo criptográfico, etc. El agente de IA asigna a cada entidad una puntuación de veracidad basada en la cadena de verificación disponible, permitiendo distinguir visualmente entre hechos consolidados y afirmaciones pendientes de corroboración, no dando nada por hecho. Otro requisito es la ejecución en local: los datos de una vida personal no deben transitar por servidores de terceros para ser procesados. Modelos cuantizados de 7B o 14B parámetros funcionan aceptablemente en hardware doméstico con 16GB de RAM, democratizando el acceso a esta capacidad analítica sin comprometer la privacidad.

Actualmente se encuentra en desarrollo un sistema que integra estas tres capas en un flujo unificado: ingesta documental automatizada, generación de páginas wiki, alimentación del grafo temporal y detección de inconsistencias mediante álgebra de Allen, todo orquestado por agentes de IA ejecutándose en local. El software, aún en fase de prueba de concepto, se construye sobre principios de código abierto, ejecución local, propiedad total del usuario sobre sus datos y transparencia metodológica. Las primeras pruebas con un caso real de análisis han validado la viabilidad del enfoque. Queda trabajo por delante: la interfaz de ingesta necesita pulirse, el sistema de puntuación de credibilidad requiere calibración con más casos de uso y la integración entre MediaWiki y el grafo debe ser bidireccional y transparente. Pero los cimientos están puestos.

Comienzo diciendo que, después de todo, no es ningún regalo ser inmortal; más bien diría que es una desgracia. O digamos que al final tampoco importa mucho. Si tienes literalmente todo el tiempo del mundo, las palabras «antes», «después» o «final» pierden su valor, se relativizan. Si solo dispones de un principio y, gracias a las flaquezas de la naturaleza, tu humanidad percibe que no tiene futuro, pues poco se puede hacer cuando tu presente es infinito…

Yo era una persona normal que fue ralentizando su reloj biológico hasta pararlo completamente. No ocurrió de forma consciente, solo sucedía. Los demás envejecían, yo me conservaba exactamente igual. Dejé de comer y descubrí que no me hacía falta alimentarme para sobrevivir. Al principio todavía lo hacía por hábito, pero rápidamente lo dejé de hacer, al igual que el resto de funciones corporales. Pasé de vivir a existir.

Siento nostalgia pues aún sigo en el páramo que es la Tierra. Siento melancolía, añoranza de tiempos pasados, cuando era. Ya solo soy. Siento tristeza en esta soledad mientras observo la gigante roja que un día fue el Sol. El resto del género humano hace eones que se extinguió, presa de su propia hoguera de vanidades. Soy el último... o el primero, qué más da ahora... Y todavía pienso en marcos temporales que ya no existen para mí, que siempre soy el mismo. Siempre. Para siempre. Ser inmortal no es un don, es una maldición...