# Deja de defender tu ventaja competitiva con políticas (3/5)

Source: https://lodos.md/es/blog/deja-de-defender-tu-ventaja-competitiva-con-politicas
Published: 2026-08-11 · Author: Samet Samyeli · Language: es · Reading time: 10 min

Una ventaja escrita en un documento se pudre en cuanto llega un ingeniero junior o una refactorización de madrugada. En cada commit se ejecutan dos comprobaciones: una rompe el build si reaparece algo que juré no construir, otra rompe la wiki si se pierde una lección. Las dos, selladas en la misma cadena HMAC.

---

> Casi todos los productos de IA defienden su ventaja con documentos de políticas que se pudren en silencio en cuanto aparece un ingeniero junior o una refactorización de madrugada. Yo defiendo la mía con dos comprobaciones duras que se ejecutan en cada commit: una rompe el build si algún día publico aquello que juré no construir jamás; la otra rompe la wiki si dejo que una lección cara se vuelva imposible de consultar o acabe contradiciendo a otra página. Las dos quedan selladas en la misma cadena HMAC. El resultado es la única ventaja que funciona como un trinquete: gira siempre en el mismo sentido, porque cada negativa y cada lección solo pueden dejar el sistema más difícil de estropear y más útil, nunca al revés.

Cada commit dispara dos scripts.

El primero recorre todo el repositorio con grep buscando lo que juré no publicar nunca: evaluadores dinámicos, herramientas que devuelven el valor de un secreto, módulos que hablan directamente con el proveedor, el trío letal que le abre la puerta a un agente para exfiltrar datos. Si aparece cualquiera de esas cosas, el build se cae en seco.

![Dos columnas simétricas sobre una misma cadena HMAC: en el lado de las negativas, el código pasa por grep en busca de lo que no debe existir, y el build se cae si algo aparece; en el lado del conocimiento, la wiki pasa por lint en busca de lo que falta, y la integridad se rompe si algo falta. Los dos lados escriben sus eventos en el mismo registro, que delata cualquier manipulación.](/blog/make-your-moat-a-ratchet/2a.webp)

El segundo recorre la wiki y hace la pregunta contraria: ¿qué debería estar aquí y no está? Una afirmación sin fuente. Una página de concepto a la que no apunta ningún enlace. Dos páginas escritas con meses de diferencia que se contradicen. El primer script evita que el sistema acabe convertido en un CVE. El segundo evita que olvide lo que ya aprendió.

Construí lodos sobre una sola regla: toda negativa que importa es un grep dentro del build, y todo conocimiento que importa es una página versionada y consultable.

Las dos cosas viven dentro de una cadena HMAC que salta a gritos en cuanto alguien manipula algo. Escribe lo que te niegas a añadir. Escribe lo que te niegas a olvidar. Y haz que el build se niegue a publicar si falta cualquiera de las dos cosas. Casi todos los productos de IA escriben lo que quieren llegar a ser y lo defienden con políticas. Un grupo más pequeño escribe en qué se niega a convertirse y lo defiende con código. El grupo más raro escribe además lo que se niega a olvidar y lo defiende con una wiki que no pasa su propia comprobación de integridad en cuanto una página se desvía. Ese último grupo es el único que construye una ventaja que se acumula como el interés compuesto.

![Ventaja de papel frente a ventaja de trinquete: a la izquierda, una promesa escrita pasa por un ingeniero junior, una refactorización y una deriva silenciosa sin que nadie se entere, y su curva de confianza cae hacia cero; a la derecha, el grep y el lint de la wiki fallan a gritos en cada commit, y la curva de confianza sube a saltos a lo largo de los mismos doce meses.](/blog/make-your-moat-a-ratchet/3a.webp)

## Lo que se pudre y lo que no

Las ventajas escritas en documentos mueren en silencio. «Nunca registramos secretos». «Aislamos la salida de cada herramienta». «Validamos antes de que el LLM lo vea». Frases así viven en la documentación de SOC 2 y son ciertas el día en que se escriben. Luego un ingeniero junior añade un log de depuración. Una refactorización esconde el sanitizador detrás de un feature flag. La frase sigue en el documento; el sistema ya no se comporta como la frase. No falla nada. No se entera nadie.

Las ventajas basadas en conocimiento mueren todavía más rápido. Un fundador entiende a las dos de la madrugada por qué se le fue un cliente, suelta la conclusión en Slack y la pierde en una semana. La lección no queda en ningún sitio que se pueda consultar. Tres meses después vuelve el mismo patrón y el fundador paga otra vez la misma matrícula. Es la erosión más cara de todas, porque el fundador ni siquiera sabe que le está pasando.

Los dos fallos se curan igual: ata la promesa a una estructura que se rompa cuando la promesa se rompe. Que el build se caiga en cuanto alguien reintroduce lo prohibido. Que la wiki no pase su propio lint cuando una página se queda huérfana, se desvía del tema o se contradice a sí misma. La solución no es un proceso. La solución es una comprobación que el sistema se aplica a sí mismo todas y cada una de las veces.

![El bucle de tres operaciones: la ingesta convierte fuentes en bruto en una página propuesta que se revisa en una ventana de diff antes de volverse canónica; la consulta sintetiza respuestas con citas que se pueden guardar como páginas nuevas; y el lint audita páginas huérfanas, afirmaciones sin fuente y contradicciones. Debajo, las tres desviaciones de lodos: almacenamiento en SQLite cifrado, autonomía limitada a proponer y un registro de auditoría encadenado con HMAC.](/blog/make-your-moat-a-ratchet/4a.webp)

## El patrón de Karpathy, llevado a un producto

El lado del conocimiento no es idea mía. Andrej Karpathy describió una wiki para LLM con tres operaciones y una idea detrás: la wiki es el ejecutable, las fuentes en bruto son el código, el LLM es el compilador, el lint son los tests y las consultas son el tiempo de ejecución.

Copié el patrón y después cambié tres cosas a propósito.

- **Almacenamiento.** Karpathy usa una carpeta de archivos markdown y git. Yo uso SQLite y una caja fuerte cifrada sección por sección. Cambio interoperabilidad por confidencialidad, y una exportación limpia a markdown me deja volver a Obsidian el día que quiera.
- **Autonomía.** Karpathy deja que el LLM escriba directamente. Yo obligo a que cada cambio pase por una ventana de diff donde apruebo o rechazo. El agente nunca toca la página canónica. Me cuesta entre cinco y diez segundos por aprobación y, a cambio, el agente no puede reescribir mi comportamiento a mis espaldas.
- **Auditoría.** Karpathy mantiene un log en markdown corriente. Yo mantengo una cadena HMAC firmada con una subclave derivada de la contraseña maestra. Si alguien manipula el registro, la cadena aparece rota en el siguiente arranque.

No son diferencias filosóficas. Son las adaptaciones que necesita un patrón de conocimiento personal para convertirse en un producto que alguien compra. Mantienen el espíritu y, además, permiten cobrar precios de comprador con obligaciones de cumplimiento.

## Los dos lados solo avanzan, nunca retroceden

El lado de las negativas y el lado del conocimiento tienen exactamente la misma forma. Uno busca cosas que no deben existir jamás; el otro, cosas que no deben faltar jamás. Los dos comprueban ausencias. Los dos fallan a gritos. Y los dos quedan sellados en la misma cadena HMAC.

Cuando le pregunto algo a la wiki y la respuesta es buena, la interfaz me ofrece guardarla como página con un solo clic. Si acepto, esa respuesta pasa a ser duradera: la siguiente sesión la encuentra y esa pregunta ya no hace falta volver a hacerla. La métrica que miro es la tasa de guardado, el porcentaje de respuestas que acaban convertidas en página, y sube con los meses. La wiki es la única parte del sistema que solo puede volverse más fuerte cuanto más la uso.

El lado de las negativas funciona igual. Cada funcionalidad nueva que amenaza un invariante trae consigo un invariante nuevo escrito en el script de verificación. En ocho meses el script pasó de siete comprobaciones a treinta y dos. Cada capacidad entra acompañada del grep que cierra su clase de abuso, así que el código solo puede volverse más restrictivo con cada cosa que publico, nunca menos.

Casi todos los equipos tratan esto como dos asuntos separados. En realidad es la misma disciplina aplicada a dos ausencias distintas: lo que nunca debe existir y lo que nunca debe olvidarse.

## Lo que cuesta y por qué el coste es el objetivo

Pierdo velocidad justo en las funcionalidades que pelean contra las negativas y en las reescrituras que se saltarían la wiki. Un usuario avanzado pide un evaluador de expresiones dentro del editor: denegado. Un cliente pide una herramienta que devuelva el valor de un secreto: denegado. Y el yo del futuro tendrá la tentación de quitar de en medio el bucle de aprobación porque le parecerá lento. El build no se lo va a permitir.

Mis notas de versión no se parecen a las de ningún competidor: nombran las negativas tantas veces como las funcionalidades. No hay forma de contar una historia de crecimiento limpia si omites todo lo que decidiste no construir.

Lo que gano a cambio no cabe en la web de producto. Cabe en una conversación de ventas con un comprador regulado, que no oye igual «no podemos» que «prometemos no hacerlo». Para un responsable de cumplimiento, una cadena HMAC que delata cualquier manipulación no pesa lo mismo que un log en markdown. Y al fundador que hoy escribe en la wiki lo está leyendo el fundador que la va a necesitar dentro de seis meses. A ninguna de esas personas se llega con un mensaje de marketing.

![Las cinco piezas, primero como tarjetas sueltas y luego conectadas entre sí: el repositorio alimenta el script de invariantes en el lado de las negativas, el lint de la wiki cubre el lado del conocimiento, los dos escriben en la cadena HMAC compartida, y cada cambio del bucle de solo propuesta pasa por una ventana de diff antes de volverse canónico.](/blog/make-your-moat-a-ratchet/5a.webp)

## Cinco piezas que puedes robarme

Ninguna depende de las demás. Juntas forman el patrón.

1. Un motor de flujos de trabajo declarativo, sin evaluador de expresiones de ningún tipo.
2. Una caja fuerte de dos almacenes en la que la IA, literalmente, no puede devolver un secreto en texto plano.
3. Un script de invariantes que corre en el build, escrito con la disciplina de la demostración en negativo.
4. Una wiki que implementa las tres operaciones de Karpathy y envuelve su registro en una cadena HMAC.
5. Un bucle de aprendizaje en el que el agente solo propone y nunca escribe su propio comportamiento.

Móntalas en el orden que quieras. Lo único que comparten es la disciplina: escribe lo que te niegas a publicar y lo que te niegas a olvidar, comprueba las dos cosas en el build y demuestra que esas comprobaciones sirven intentando saltártelas a propósito. Todo lo demás es ingeniería.

![El siguiente bucle, en seis pasos: el agente observa la conversación, detecta un hueco en sus habilidades y redacta una propuesta que se detiene en una ventana de diff a doble columna, señalada como el paso obligado, donde una persona aprueba o rechaza antes de que nada se vuelva canónico y salga a producción. Cada propuesta y cada decisión quedan escritas en la cadena HMAC.](/blog/make-your-moat-a-ratchet/6a.webp)

## Lo que viene después

*El último bucle es el que más me costó dejar fino. El agente observa la conversación, se da cuenta de que su propio catálogo de habilidades podría mejorar y propone una edición. Yo apruebo o rechazo. Esa edición viaja por la misma ventana de diff que cualquier propuesta de la wiki, porque el agente nunca escribe su propio comportamiento. El paso obligado entre proponer y aprobar es la ventaja de verdad. El próximo artículo va de ese bucle y de un párrafo corto del prompt de disposición que justificó él solo todo el trabajo de ingeniería.*

[Apúntate a la lista de espera](https://lodos.md/)