Un freno no es un rumbo
El debate sobre el riesgo de la IA discute quién pone los frenos. Para quien usa estas herramientas cada día la pregunta es más sencilla y menos cómoda: ¿es gobernable lo que estoy usando, conozco su territorio y sé hacia dónde va?
El 10 de septiembre de 2026, IBTimes publicó «AI Researcher Warns Humanity Could Be at Risk by 2030». Jacob Coxon, tras tres años investigando en preentrenamiento de modelos en OpenAI y Anthropic, dejaba Anthropic con esta frase: «Neither company is acting responsibly. They are racing straight to self-improving superintelligence and gambling with our lives.» Evan Hubinger, también de Anthropic, le dio la razón y admitió: «we do not yet have a plan to solve alignment for superintelligence and are not clearly on track to.»
La respuesta que recoge la pieza gira en torno a una pregunta: quién frena. Una ley para prohibir la superinteligencia y pausar el resto del desarrollo avanzado «until a federal regulator creates safety rules». Otra para un botón de apagado. Una sesión especial en el Congreso. Y, en contra, el secretario del Tesoro: Estados Unidos no puede pausar «because the Chinese won’t pause».
Todo eso es legítimo y probablemente necesario. Pero fíjate en quién aparece: empresas, legisladores, un regulador futuro, un país rival. Unos pocos, discutiendo quién es el responsable, quién tiene la llave y quién pulsa el botón.
Mientras tanto, cada día más gente usa estas herramientas para trabajar. Una organización coordina proyectos con agentes que abren cambios, redactan decisiones y cierran tareas. Un equipo mantiene servidores con un agente que cambia configuraciones. Alguien escribe un libro con un agente que le propone notas y citas. Para toda esa gente, que no firma leyes ni entrena modelos, la pregunta útil es otra, y es de sentido común:
¿Es gobernable lo que estoy usando? ¿Conozco su territorio? ¿Sé hacia dónde va, y qué hay que ajustar cuando cambia?
Este artículo es para esa mayoría. No discute si la IA es peligrosa. Cuenta por qué ontoref decidió lo que decidió ante esas tres preguntas. ontoref es un protocolo: una forma de que un proyecto declare qué es, qué ha decidido y hacia dónde va, de manera que personas y agentes puedan comprobarlo. Sirve para cualquier proyecto, y se especializa mediante dominios: extensiones a medida para un uso y un contexto concretos. Hay dominios para el gobierno de proyectos, la infraestructura, la autoría de obras, las fuentes citables o la vida profesional de una persona, entre otros. Este artículo se detiene en tres de ellos, por este orden: el gobierno de proyectos, la infraestructura y la autoría.
No es quién gobierna, es si se deja gobernar
Puedes poner al frente de algo a la persona más sabia y más responsable del mundo. Si eso que dirige no dice qué es, no deja ver lo que hace y no admite que se compruebe, no hay gobierno posible. Habrá autoridad, habrá propiedad, habrá alguien a quien culpar. No habrá gobierno.
ontoref separa esas cosas a propósito, y lo deja escrito en su glosario. Distingue tres palabras que en el uso diario se mezclan:
| Palabra | Qué nombra | La pregunta que responde |
|---|---|---|
| Gobernanza | El arreglo: las fronteras, quién es miembro y qué se publica. | ¿Cómo está organizado? |
| Gobierno | El ejercicio: quién actúa y con qué procedimientos. | ¿Quién actúa, y cómo? |
| Gobernabilidad | La capacidad: «si el sujeto admite gobierno». | ¿Se deja gobernar? |
Y declara que la gobernabilidad es una propiedad del protocolo, no de un dominio concreto: tiene que estar antes que cualquier arreglo y que cualquier ejercicio. Sin ella, las otras dos se quedan en forma.
No es una idea nueva. En 1970, Roger C. Conant y W. Ross Ashby demostraron un teorema cuyo título lo dice todo: «Every Good Regulator of a System Must Be a Model of That System». Todo buen regulador de un sistema tiene que ser un modelo de ese sistema. Según los propios autores, el teorema cambia el estatus de hacer modelos «from optional to compulsory». Dicho en llano: no se gobierna lo que no está descrito. Por eso lo primero que pide ontoref es que el proyecto se describa a sí mismo. Y la literatura reciente sobre los arneses de los agentes usa la misma palabra: Birgitta Böckeler escribe que las decisiones de tecnología y de arquitectura «determine how governable the codebase will be».
Y ontoref no se construye como un organismo que manda, sino para que cualquiera pueda comprobar. Uno de sus principios invariables lo dice así: cualquier actor, humano o agente, puede verificar que una parte es coherente con lo declarado sin tener el conocimiento del todo. No hace falta ser el experto, ni el dueño, ni el que llegó primero. Y en la escalera que usa para ordenar lo comprobable, el quinto peldaño (Acreditación) termina con una frase que resume la decisión: «responsabilidad con nombre, no principio de autoridad».
Esto no es una declaración de buenas intenciones: se puede comprobar. A ontoref se le puede preguntar qué reglas gobiernan cualquier fichero de un proyecto. Y también responde a lo contrario, la parte incómoda: qué reglas no sabe señalar sobre ningún sitio. No las esconde, las nombra. Un sistema gobernable es el que te dice dónde no lo es.
Para comprobarlo: cómo se ve en la herramienta
ontoref governs <ruta> responde qué decisiones de arquitectura (los ADR) gobiernan un fichero y por qué vía. ontoref governs coverage hace el recuento inverso sobre el propio ontoref:
CONSTRAINT ROUTING COVERAGE
accepted ADRs 104
constraints 468
routable 441
declared non-path 21 ← say what they are; not a blind spot
STALE TYPED 0 ← declared a path, none of them resolves
UNTYPED 6 ← neither addressable nor declared. THIS is the blind spot.
of which ungated 6 ← the real blind spot: nothing addresses them AND nothing checks them
De 468 restricciones, 6 no se pueden dirigir a ningún fichero y ninguna comprobación las mira. La herramienta no lo resuelve: lo nombra.
Lo que no está escrito, alguien lo inventa
Hay una segunda cosa de sentido común que el debate público casi no toca.
A un compilador no le das instrucciones de arquitectura en prosa. No le escribes «por favor, procura que esto sea seguro». Un lenguaje de programación tiene sintaxis, semántica y gramática: lo que no encaja, no entra. Con los agentes de IA hacemos lo contrario. Les escribimos en lenguaje natural, a menudo en un idioma que luego se traduce, una prosa de buenos deseos: sé cuidadoso, no inventes, respeta las convenciones. Esa prosa se puede leer o no, y cuando se lee, se interpreta. El terreno es, como poco, movedizo.
Y además hay huecos. Toda obra, todo sistema y todo proyecto dan por supuestas cosas que no están escritas en ningún sitio. Una persona nueva en un equipo pregunta o se equivoca despacio. Un agente no se detiene: rellena lo que falta con algo plausible para completar la tarea, con la inercia de responder rápido y de complacer. No puede producir algo coherente sin rellenar el hueco. El resultado es deriva, divergencia y, a veces, alucinación sobre premisas que nadie comprobó.
Lo vimos de cerca hace unos días. Un agente tenía la regla delante y aun así rellenó un hueco con una referencia inventada y atribuyó al autor palabras que no dijo. El caso completo está en «Mover la regla no basta» y en su expediente 2/26. De él importa una cosa: la letra de la regla no nombraba el sitio donde escribió el agente, y la razón de la regla sí lo cubría.
De ahí salen dos decisiones de ontoref:
Decisión 1 Las decisiones se escriben como datos con tipo, no como prosa
Cada decisión de arquitectura es un fichero que se valida, con restricciones marcadas como duras o blandas y, cuando se puede, una comprobación asociada. Lo que no encaja en el tipo no entra, igual que con un compilador.
Decisión 2 Una regla vale donde se ejecuta, no donde se lee
El caso dejó tres preguntas para cualquier regla: ¿dónde se ejecuta?, ¿comprueba el sentido o sólo una grafía?, ¿alguien la ha visto rechazar lo que prohíbe y aceptar lo que permite? Una regla que no pasa esas tres es una intención, no un mecanismo.
Frenar no es orientar
Las salvaguardas y los arneses que envuelven a los agentes hacen algo necesario: limitan, filtran y cortan. Actúan en negativo, evitando lo indeseable. Es lo mismo que proponen las leyes de la noticia, a otra escala.
Esa forma de regular, la que reacciona cuando el error ya se ha producido, también tiene nombre desde hace medio siglo. Conant y Ashby la llamaron «a primitive and demonstrably inferior method of regulation», porque con ella «its success can only be partial».
Pero un coche con muy buenos frenos y sin volante no llega a ningún sitio. Lo que falta es el modo positivo: recordar por qué y para qué se hace algo, confirmar que lo que está en marcha sigue siendo lo que se declaró y verificar sabiendo qué se ha mirado y qué no. El porqué y el para qué son los cimientos del qué, el cómo, el cuándo y el dónde. No se trata de ir más despacio ni sólo de fijar reglas del juego, aunque también. Se trata de no perder el rumbo mientras se avanza.
Chris Argyris lo explicó en 1977 con un termostato. Corregir la temperatura cuando se desvía es aprender en un solo bucle. Si el termostato pudiera preguntarse «whether it should be set at 68 degrees», sería capaz de cuestionar también los objetivos: es lo que Argyris llamó aprendizaje de doble bucle. Recordar el porqué es ese segundo bucle.
ontoref ordena lo que se puede comprobar de un proyecto en una escalera de siete peldaños. Cada uno se apoya en el anterior, y cada uno es una pregunta que cualquiera entiende:
| Peldaño | La pregunta que plantea | |
|---|---|---|
| 1 | Razón de ser | ¿Sigue siendo cierto lo que el proyecto dice que es, o es una frase que nadie ha vuelto a leer? |
| 2 | Reflexión | Lo que el proyecto sabe de sí mismo, ¿se ejecuta y deja rastro, o sólo está escrito? |
| 3 | Categorías y relaciones | ¿Está dicho en un vocabulario cerrado que una máquina pueda validar? |
| 4 | Territorio y criterio | ¿Está declarado hasta dónde llega lo gobernado y con qué se mide que lo sigue estando? |
| 5 | Acreditación | ¿Se verifica la evidencia de lo que se hizo, o sólo el informe de quien lo hizo? |
| 6 | Observabilidad | ¿Hay una pregunta que devuelva la distancia entre lo declarado y lo que hay? |
| 7 | Linaje del saber | ¿Está registrado de dónde viene lo que el proyecto sabe? |
Cada peldaño, con lo que presupone, lo que lo comprueba y por qué importa, se explica en detalle en la escalera y sus peldaños. El mismo recorrido, con la salida real de cada comando, está en las diapositivas del mecanismo.
Cada peldaño declara unas condiciones que una máquina puede comprobar: que un fichero existe, que un patrón aparece. Pasar esas condiciones es necesario, pero no suficiente. Por eso, cuando ontoref revisa la escalera entera, bajo cada peldaño muestra, junto a lo que se cumple, la pregunta que ninguna comprobación puede contestar. Y termina con una frase que no deja lugar a dudas: ningún peldaño se da por sostenido.
La máquina confirma lo que puede. La pregunta que decide queda, cada vez, delante de una persona. No hay receta binaria de aprobado o suspenso; como recuerdan David J. Snowden y Mary E. Boone, «best practice is, by definition, past practice». Hay más estados: se cumple, falla, no se ha podido ver (y entonces la herramienta dice qué parte no pudo mirar), y queda una pregunta para el juicio de alguien. Resumir la escalera con una nota, siete sobre siete, sería justo el error que ontoref se prohíbe cometer.
Para comprobarlo: cómo se ve en la herramienta
La revisión es ontoref ladder audit. Así sale el primer peldaño (Razón de ser); la línea ? not read es la pregunta que ninguna comprobación contesta:
[Pass ] ladder reason-for-being:conditions
2 of 2 necessary condition(s) met — necessary, never sufficient: this is a verdict about the conditions, not about the rung
+ read: FileExists .ontoref/ontology/core.ncl [exists]
+ read: FileExists .ontoref/ontology/state.ncl [exists]
? not read: what settles the rung: Whether what the file answers is still the project's actual reason for being, or a sentence that stopped being true and nobody re-read. …
Y así cierra la revisión completa:
No rung is reported as HOLDING. Every verdict above is about a rung's
necessary conditions; what would settle the rung itself is the line
marked `? not read` under it, and no check answers that one.
Hoy se cumplen las catorce condiciones de los siete peldaños: once comprueban que un fichero existe y tres buscan un patrón. Presentar el resultado como «N of 7 rungs passing» está nombrado como antipatrón en ADR-111.
Y hay una razón más para no convertirla en una nota. Una misma medida puede ser mucho en un plano y nada en otro. Si se generaliza fuera de contexto, polariza o jerarquiza. Por eso la vista general de la escalera no lleva cifras: cada medida se lee dentro del plano donde se usa.
Tres dominios donde se juega
Esto no es teoría. Son tres casos que ya ocurrieron y quedaron medidos, uno por dominio. En los tres pasa lo mismo: algo parecía estar bien, y no lo estaba.
Gobierno de proyectos: quien declara las reglas también está dentro
El primero es el dominio del propio ontoref: cómo se organiza un conjunto de proyectos y con qué procedimientos se actúa sobre ellos.
El primer caso es el más incómodo. El 24 de agosto de 2026 se midió que el tipo de repositorio del propio ontoref no aparecía en ningún dominio. La herramienta que da reglas a los demás proyectos era el único proyecto sin dominio propio. Estaba fuera de su propio gobierno. De esa medida salió el dominio de gobierno de proyectos. No hay excepción para quien escribe las reglas, y es la aplicación más directa de «responsabilidad con nombre, no principio de autoridad».
El segundo es más discreto. Ese dominio declara siete procedimientos. Medido el 14 de agosto de 2026, uno de ellos, el de entrega gobernada, se había ejecutado dos veces en seis semanas, mientras otro se ejecutaba veintiséis, y los dos estaban igual de presentes en disco. Una comprobación que sólo mira lo declarado no distingue un procedimiento en reposo de uno abandonado. Lo que quedó escrito: esa medida está anotada bajo el segundo peldaño (Reflexión), y cada revisión de la escalera la vuelve a imprimir. Verlo no hace que el procedimiento se use. Pero sin verlo no hay nada que decidir.
Para comprobarlo: la medida, tal como la imprime cada revisión
Bajo el segundo peldaño (Reflexión), ontoref ladder audit imprime en cada ejecución:
measured 2026-08-14, governed-delivery ran twice in six weeks while generate-article ran twenty-six times, and both were equally present on disk.
Infraestructura: un silencio
En el dominio de la infraestructura (provisioning), un proyecto sufrió esto el 29 de junio de 2026. El componente que conecta los discos de almacenamiento buscaba los datos en un directorio, y el sistema que ejecuta los servicios los guardaba en otro. Todos los servicios que guardan datos escribieron en el disco del sistema en lugar de en su volumen. Se perdieron los datos del registro de imágenes, el disco se llenó y el sistema empezó a desalojar servicios en cascada. El registro del caso lo resume en una línea: ningún componente informó de un fallo en ningún momento; el fallo era el silencio.
Lo declarado decía una cosa y el territorio hacía otra. Nadie mentía. Nadie miraba.
Lo que quedó escrito. Del incidente salió una comprobación, y la comprobación también tuvo que corregirse. Su primera versión sólo miraba los componentes que declaraban el directorio. Pasó en verde sobre una configuración que tenía otra instancia del mismo fallo, porque el componente que no declaraba nada se le escapaba. La versión actual:
- falla si no encuentra nada que comprobar, porque un verde sin sujeto es el primer paso del incidente;
- tiene dos mitades: una compara lo declarado y otra mira lo que el sistema ejecuta de verdad;
- cuando no puede llegar al sistema en marcha, responde «desconocido», no «correcto»;
- dice su propio límite: si todo lo declarado está mal de la misma forma, esta mitad pasa y la otra falla.
Leído con la escalera, y otra vez es lectura mía, aquí pesan el cuarto peldaño (Territorio y criterio), un criterio que mire a todo su territorio, y el sexto (Observabilidad), un verde que diga qué ha cubierto.
Para comprobarlo: el caso tal como quedó registrado
El controlador de volúmenes trabajaba con /var/lib/kubelet, el directorio por defecto de kubeadm, mientras la distribución de Kubernetes (k0s) guardaba el kubelet en /var/lib/data/k0s/kubelet. El registro del caso, en su original:
No component reported a failure at any point — the failure mode IS the silence.
La comprobación que salió de ahí declara su límite con estas palabras:
A workspace where BOTH are wrong in the same way passes here and fails live.
Su mitad declarada, ejecutada el 14 de septiembre de 2026, terminó con código 0: los tres componentes de volúmenes declaran /var/lib/data/k0s/kubelet.
Autoría: una cita que parece correcta
En el dominio de las obras de autoría (su identificador es librosys), la unidad es la obra como un todo coherente: un libro, por ejemplo.
Un proyecto de autoría que lo usa declara tres puertas de calidad para su contenido: que el glosario no defina la misma palabra de dos formas, que ninguna sección se quede sin ejercicio, reflexión o concepto, y que cada paso retome el concepto del anterior. Las tres miran coherencia y completitud. Ninguna mira de dónde viene un dato que un agente inserta.
Una cita promete que el lector puede ir a la fuente. Una cita que no resuelve a nada pasa la revisión precisamente porque parece correcta. Es el hueco rellenado con algo plausible, y aquí hace más daño que en un documento técnico: atribuye, cita y habla en nombre del autor.
Lo que quedó escrito. El dominio registró la pregunta sin darla por resuelta: ninguna puerta rechaza hoy una cita insertada por un agente que no lleve a una fuente conservada o accesible. Y escribió al lado qué haría falta para cerrarla: una puerta que compruebe la capacidad y no la forma, y que alguien haya visto rechazar una cita mala y aceptar una buena antes de fiarse de ella. El modelo existe en el otro lado: ontoref ya registra de dónde viene lo que sabe, separando la custodia de sus fuentes del juicio sobre ellas (ADR-080). Leído con la escalera, es la pregunta del séptimo peldaño (Linaje del saber) llevada a una obra. Es una lectura mía: ontoref todavía no ordena los peldaños por dominio.
Un territorio que cambia
Los tres casos tienen algo en común: en ninguno falló una regla escrita. Falló que el mapa y el terreno se separaron sin que nadie lo notara. Una herramienta que da reglas no estaba dentro de ellas. Un procedimiento declarado apenas se ejecutaba. El directorio declarado no era el que se usaba.
Conocer el territorio no es hacer un mapa una vez. Los proyectos cambian, las herramientas cambian y los agentes aceleran los cambios. Un mapa que no se vuelve a leer deja de describir el terreno sin avisar. Conant y Ashby también lo previeron: cuando el sistema cambia, el regulador tiene que cambiar con él, y hace falta «a time-varying model» para regular algo que varía con el tiempo. Argyris lo encontró en las personas: pocas saben que no usan las teorías que dicen seguir, y así acaban siendo «prisoners of their own theories». Por eso las respuestas de los tres casos no fueron más reglas, sino maneras de volver a mirar: un dominio creado cuando la medida lo pidió, una medida que cada revisión reimprime, una comprobación con una mitad que mira lo que se ejecuta.
ontoref lleva esa idea al proyecto entero. No declara sólo lo que un proyecto es, sino hacia dónde va. Cada dimensión tiene un estado actual y un estado deseado, y la transición entre ambos declara qué la bloquea y qué la impulsa. Hoy, en el propio ontoref, tres de sus dimensiones han llegado a su estado deseado: la madurez del protocolo, la cobertura de su autodescripción y su integración en el ecosistema. La cuarta, el modo de operación, no es una meta sino un modo: pasa de local a daemon según el daemon esté en marcha, y lo que queda es mantenerlo como servicio. El rumbo está escrito, se puede preguntar en qué punto está y se puede ajustar cuando el terreno se mueve. Eso es lo que permite transformarse y evolucionar sin perderse: no un destino fijo, sino una distancia que se puede medir.
Para comprobarlo: el rumbo declarado del propio ontoref
ontoref describe state muestra cada dimensión con su estado actual y el deseado:
FSM Dimensions 4 total
protocol-maturity ✓ reached
Protocol Maturity horizon: Months
current: protocol-stable desired: protocol-stable
self-description-coverage ✓ reached
Self-Description Coverage horizon: Weeks
current: fully-self-described desired: fully-self-described
ecosystem-integration ✓ reached
Ecosystem Integration horizon: Months
current: multi-project desired: multi-project
operational-mode → in progress
Operational Mode horizon: Continuous
current: local desired: daemon
La cuarta sale «in progress» porque su estado se detecta al ejecutar el comando: sin el daemon en marcha, sale local. Su transición declara, además, qué la bloquea y qué la impulsaría.
Una postura, no un mecanismo
Lo que sigue no tiene comando. Es la parte ética, y conviene decirlo así.
Estamos ante paradigmas nuevos que piden roles y mecánicas de seguridad distintas. Pero los papeles que vemos en el debate no son nuevos: el salvador del mundo, el que no quiere mancharse las manos, el más listo y más rápido, capaz de resolver cualquier cálculo aunque para ello invierta lo que haga falta. A eso se suman la polarización de la verdad, la simplificación para no sentir miedo, la inercia de querer más y cuanto más rápido mejor, y el protagonismo.
Siempre habrá riesgos y errores. Pero el riesgo no lo sufren sólo unos pocos, y el beneficio tampoco debería ser sólo de unos pocos. Si la comprobación queda en manos de quien tiene la autoridad, la mayoría sólo puede confiar o desconfiar. Si lo que se usa es gobernable, cualquiera puede comprobar su parte. Detrás de lo que hacemos hay fundamentos ontológicos y una ética que se manifiesta en cada paso: en un modo de estar y de usar. Es lo que da color, dimensión y evolución a un proyecto, y es lo que hace más fuertes a propuestas como ontoref.
¿Sabemos cuáles son los logros?
El riesgo es alto, pero lo que se aspira a lograr también. ¿Sabemos cuáles son esos logros y cómo mantener y validar el rumbo de forma precisa, reconocible e inequívoca?
La respuesta honesta tiene tres partes.
Lo que se sabe. En cada peldaño se conocen las condiciones necesarias, y hoy se cumplen. Se conoce la pregunta que ninguna máquina contesta, porque está escrita. Se sabe por qué reglas no puede responder la herramienta, porque las nombra.
Lo que no se afirma. Ningún peldaño se da por sostenido, porque verificar siempre es local y parcial. Tampoco existe todavía una forma de ordenar los peldaños según el plano de cada dominio, y no se finge que exista.
Lo que ya se puede señalar. En los tres casos hay algo escrito que antes no estaba: una herramienta que dejó de estar fuera de sus propias reglas, un silencio convertido en una comprobación que dice lo que no ve y una cita sin procedencia convertida en una pregunta con criterio de cierre.
Un freno se acciona una vez. Un rumbo se sostiene preguntando: por qué empezamos, si lo que está en marcha sigue siendo lo que declaramos, qué parte de este verde se ha mirado de verdad. Esas preguntas no son de unos pocos. ontoref no las responde por nadie: las pone delante, en orden, para quien quiera hacérselas, y cuando encuentra un hueco lo deja escrito donde se puede volver a mirar.