¿La IA está sobrescribiendo tus notas? Tres capas de ownership para proteger tu conocimiento

¿Alguna vez refinaste una nota durante horas — redactando, puliendo, dándole estructura — y un ingest posterior la sobrescribió silenciosamente, como si tus horas nunca hubieran existido?

Si usas LLMs para mantener una base de conocimiento, probablemente ya sentiste ese dolor: la IA genera contenido excelente, pero cuando tú lo mejoras a mano, no siempre respeta tus ediciones. Este artículo te muestra cómo resolvimos ese problema en agnosticBrain, un vault de conocimiento basado en el patrón LLM Wiki de Andrej Karpathy, al que agregamos tres capas de ownership en lugar de las dos originales.

El contexto: LLM Wiki, la propuesta de Karpathy

En abril de 2026, Andrej Karpathy publicó su gist sobre LLM Wiki, una idea elegante para bases de conocimiento personales:

The wiki is a persistent, compounding artifact. The cross-references are already there. The contradictions have already been flagged. The synthesis already reflects everything you've read.

La idea: en lugar de RAG clásico (recuperar fragmentos crudos en cada consulta), el LLM compila y mantiene una wiki persistente — un conjunto de notas markdown interconectadas que vive entre tú y tus fuentes. Obsidian es el IDE, el LLM es el programador, y la wiki es el código.

La arquitectura tiene dos capas:

• raw/ — Tus fuentes crudas. Inmutables. El LLM solo lee.
• wiki/ — Conocimiento compilado. El LLM lo escribe y mantiene todo. Tú lo lees.

Suena perfecto, ¿no? El LLM hace todo el trabajo pesado. Pero hay un punto ciego.

El GAP: el conocimiento refinado a mano no estaba protegido

El patrón de Karpathy asume que tú nunca escribes en la wiki — el LLM la mantiene por completo. En la práctica, eso no se sostiene. Eventualmente quieres intervenir: corregir una síntesis, afinar una conclusión, documentar algo que aprendiste por experiencia y que ninguna fuente captura.

¿Y qué pasa entonces?

Los sistemas de conocimiento con IA tienen un punto ciego: no distinguen entre conocimiento generado automáticamente y conocimiento refinado por el humano. El LLM, durante un ingest o lint, puede sobrescribir silenciosamente ediciones manuales que costaron horas construir.

Si editas wiki/ a mano, estás editando un archivo que el LLM considera suyo. El próximo ingest puede sobrescribirlo, exactamente como tu compilador regeneraría un archivo generado.

Ese es el único GAP que reconocemos en la propuesta de Karpathy, y es justo el que resolvimos en agnosticBrain.

La solución: tres capas de ownership

En lugar de dos capas, agnosticBrain define cuatro directorios con dueños explícitos y reglas no-negociables:

La clave es la tercera capa: curated/ — notas refinadas manualmente, sagradas, de solo lectura para cualquier agente. La regla es contundente:

REGLA 1 — El contenido de curated/ es inviolable. NUNCA editar, sobrescribir ni alterar el contenido de una nota que reside en curated/. Esta prohibición de contenido no tiene excepción: no se negocia en ingest, lint, ni ninguna otra operación de conocimiento.

Si lo editaste a mano y no quieres perderlo → va en curated/, no en wiki/.

Cómo congelar una nota: /curate

Para proteger una nota que refinaste, el flujo es simple. La mueves de wiki/ a curated/ con la operación /curate, y a partir de ese momento el LLM no la puede modificar:

1. Verificar que la nota está en wiki/ y confirmar que quieres congelar su estado actual.
2. En tus propias palabras — única fricción intencional del pipeline: el humano escribe la idea central de la nota. El LLM nunca redacta ni sugiere esta línea. Es una firma de propiedad humana.
3. Reescribir el frontmatter al schema de curated/: status: human-canonical, llm_action: read-only, human_curated: true.
4. Mover la nota a curated/.
5. Actualizar wiki/index.md (la entrada pasa a marcarse como [CURATED]).
6. Registrar en wiki/log.md.
7. Confirmar al humano: "✅ La nota [[curated/…]] está ahora protegida. El LLM no la modificará en futuros ingest ni lint."

Cuando el LLM encuentra información nueva: /propose

Aquí está la parte interesante. ¿Qué pasa si el LLM procesa una nueva fuente que debería actualizar una nota curada? ¿Ignora el conocimiento? ¿Lo aplica en secreto?

Ninguna de las dos. La REGLA 6 lo resuelve:

REGLA 6 — Proponer, no imponer, sobre curated/. Si información nueva actualiza o contradice curated/<nota>: → Crear wiki/_proposed/YYYY-MM-DD-<nombre-nota>.md con el diff propuesto. → Nunca tocar la nota curada.

El flujo, definido en SKILLS/propose.md, es el siguiente:

1. Identificar la nota curada afectada y leerla completa.
2. Construir el diff propuesto — solo la sección afectada, no el archivo completo. Formato: sección actual (cita verbatim) → propuesta de cambio (solo el delta) → justificación.
3. Crear la propuesta en wiki/_proposed/YYYY-MM-DD-<nota>.md.
4. Actualizar el index (sección "Propuestas pendientes").
5. Registrar en wiki/log.md.
6. Notificar al humano: "⚠️ Información nueva relevante para curated/. Creé una propuesta. Cuando quieras, te muestro el diff o lo aplico si lo apruebas."

El nombre del directorio lo dice todo:

El LLM propone. El humano decide. Nadie sobreescribe curated/ sin aprobación humana.

Esto es lo que llamamos el mecanismo que cierra el loop de aprendizaje sin sacrificar la protección del conocimiento curado. El LLM puede seguir aprendiendo de nuevas fuentes, pero nunca actúa unilateralmente sobre lo que tú construiste.

Cómo se cierra el loop: la aprobación humana

Cuando quieres aceptar una propuesta, solo dices algo como:

"Aplica la propuesta de _proposed/YYYY-MM-DD-<nota>.md"

Y el LLM:

1. Lee la propuesta completa.
2. Lee la nota curada completa.
3. Aplica SOLO el delta propuesto — nada más.
4. Actualiza last_human_edit (aunque fue el LLM quien lo aplicó, es una edición aprobada por el humano).
5. Marca la propuesta como aplicada y actualiza el index.
6. Registra proposal-applied en el log.

Incluso en la aprobación, la protección no es un candado: es un límite de permisos donde solo una decisión humana explícita puede abrir la escritura.

El resto del sistema

agnosticBrain no es solo ownership. Tiene nueve operaciones definidas en el kernel (AGENTS.md):

Y un principio de diseño que nos gusta especialmente (REGLA 8): una nota = un átomo; el cerebro es una red, no un archivador. Cada /ingest mejora el grafo — más nodos, mejores enlaces, menos centralización — en vez de engordar pocas notas gigantes. El cerebro compone, no acumula.

Todo en texto plano: markdown puro, sin dependencias de apps. Solo necesitas Obsidian (con Templater) y el kernel en AGENTS.md — un archivo que leen sin transformación los agentes (Claude Code, Codex, Cursor).

En resumen

Karpathy nos dio un patrón brillante para que el LLM compile tu conocimiento en una wiki persistente. Pero le faltaba responder una pregunta: ¿qué pasa cuando tú también escribes?

Nuestra respuesta fue una tercera capa de ownership + un mecanismo de propuesta que respeta la jerarquía natural: el LLM propone, el humano decide. Con eso el conocimiento refinado a mano se vuelve inviolable, y el aprendizaje no se detiene — simplemente pasa por aprobación humana.

Si quieres ver la implementación completa — con los 9 skills, los scripts de verificación y las reglas del kernel — está todo en github.com/Macorreag/agnosticBrain. Y la propuesta original que extendemos, en el gist de LLM Wiki de Karpathy.

Esperamos que este patrón te sea de gran utilidad en tu flujo de conocimiento. ¿tu LLM ha sobrescrito alguna vez una nota que cuidaste a mano?