Mentor dos Nerds Inicio Una hipótesis no se vuelve un hecho porque la IA la repitió
Entrada

Artículo Inteligencia Artificial

Una hipótesis no se vuelve un hecho porque la IA la repitió

Una estructura ámbar incompleta pasa por un punto de confirmación, se convierte en una decisión azul y alimenta una síntesis violeta conectada con aplicaciones y revisión
Una estructura ámbar incompleta pasa por un punto de confirmación, se convierte en una decisión azul y alimenta una síntesis violeta conectada con aplicaciones y revisión

No tengo ningún problema en permitir que un agente de IA trabaje con hipótesis.

Exigir certeza antes de cada paso sonaría responsable. También sería una excelente manera de no volver a hacer nada.

Casi toda ejecución real empieza con algo incompleto: una intención que todavía necesita límites, un dato que no llegó, una preferencia que apareció en tres conversaciones pero nunca fue confirmada, una causa probable que aún necesita una prueba.

Mi problema comienza cuando la hipótesis pierde la etiqueta.

Un agente encuentra una explicación plausible. Actúa a partir de ella. Otro agente recibe el resultado. Un tercero resume el contexto. Cuando me doy cuenta, “parece que” se convirtió en “sabemos que” sin que nadie haya tomado esa decisión.

Es un teléfono descompuesto con persistencia: cada repetición parece darle más autoridad a la frase, cuando solo aumentó su distancia de la evidencia original. El rastro verificable expone esa distancia antes de que la hipótesis se convierta en regla.

No fue una gran alucinación cinematográfica. Fue peor: una inferencia razonable recibió una credencial de hecho y empezó a gobernar el sistema en silencio.

Por eso, dentro de mi harness, una hipótesis aplicada debe dejar recibo.

TL;DR

Los agentes necesitan actuar bajo incertidumbre, pero no pueden promover una hipótesis a hecho solo porque fue repetida, resumida o usada con éxito una vez. Cuando una hipótesis influye en una acción, registro su origen, evidencias favorables y contrarias, confianza y límites, alcance, consumidores afectados, acción provisional y condición de revisión. Mi wiki separa tres objetos mínimos: las hipótesis guardan posibilidades todavía no confirmadas; las decisiones registran el veredicto adoptado y su alcance; las síntesis preservan razonamiento, fuentes y divergencias. Los archivos de texto en Markdown y el historial de versiones de Git hacen que el rastro sea legible y revisable, pero no crean verdad por arte de magia. La dirección y el veredicto siguen siendo míos.

La incertidumbre no es el defecto. Su desaparición sí

Un buen agente no necesita detenerlo todo ante la primera laguna.

Si el impacto es pequeño, reversible y local, puede declarar una premisa y avanzar. Si existen dos interpretaciones plausibles, puede elegir una para producir una versión de trabajo. Si la elección cambia precio, seguridad, publicación, datos personales u otra decisión de alto riesgo, debe devolver la pregunta antes de actuar.

El error no está en formular hipótesis.

El error está en ocultar que la ejecución dependió de una.

Existe una diferencia enorme entre estas dos frases:

El cliente prefiere recibir un resumen semanal por correo electrónico.

y:

Estoy suponiendo, con confianza baja, que el resumen semanal debe enviarse por correo electrónico porque ese canal apareció en las dos últimas conversaciones. No encontré una confirmación explícita. Usaré esta premisa solo para preparar el borrador; no configuraré el envío hasta que la persona responsable lo confirme.

La segunda frase es más larga porque carga con lo que la primera borró: origen, incertidumbre, alcance y límite de acción.

También permite corregir.

Si el cliente dice “no, es por el canal de mensajería del equipo”, sé qué debe cambiar. Sin ese rastro, tengo que buscar todos los lugares donde la falsa certeza ya se propagó.

Toda hipótesis aplicada necesita un recibo

En mi sistema, una hipótesis útil no es solo una frase que contiene la palabra “quizá”. Debe responder preguntas operativas.

Campo Lo que debe permanecer visible
Origen Qué laguna, conversación, archivo u observación generó la hipótesis
Hipótesis Qué estoy suponiendo exactamente, sin lenguaje que finja confirmación
Evidencias a favor Señales que hacen plausible la lectura
Evidencias en contra Contradicciones, excepciones y datos ausentes
Confianza y límites Qué tan frágil es la lectura y qué no permite concluir
Alcance Dónde se permite el uso provisional y dónde está prohibido
Consumidores afectados Qué textos, decisiones, agentes, automatizaciones o archivos dependen de ella
Acción tomada Qué hizo el agente bajo esa premisa
Revisar si Qué confirmación, negación, plazo o evidencia exige reabrir el asunto

No exijo un porcentaje inventado para que el registro parezca científico.

“Confianza media”, con dos evidencias y una contradicción descritas, es más honesto que un “82 %” que salió de la nada.

El objetivo del registro no es decorar la hipótesis. Es permitir actuar sin borrar la incertidumbre y deshacer la propagación si la premisa cae.

Cuando confirmo o niego, el sistema debe saber qué reaprender

Una hipótesis aislada es fácil de corregir.

El problema es la hipótesis que ya alimentó un post, un prompt —las instrucciones dadas a la IA—, una recomendación, una regla de enrutamiento —el criterio que elige qué agente o flujo recibe el caso— y tres agentes especializados.

Por eso registro consumidores: los lugares donde esa conclusión fue usada o puede cambiar comportamientos.

Cuando confirmo una hipótesis, no recibe solamente un sello verde. El contenido confirmado debe ir al dueño correcto: una decisión, un contrato, una especificación, una orientación editorial u otra fuente vigente.

Cuando la niego, el trabajo tampoco termina escribiendo “refutada”. El agente debe proponer la actualización de los dependientes:

  • qué texto quedó incorrecto;
  • qué decisión usó una premisa que cayó;
  • qué agente debe dejar de aplicar la regla;
  • qué síntesis debe registrar la divergencia;
  • qué acción ya tomada necesita revisión o reversión.

Eso preserva la procedencia —el camino entre origen, interpretación, aplicación y cambio— sin fingir que nunca nos equivocamos.

Prefiero un sistema capaz de mostrar por qué cambió de opinión a otro que reescribe el pasado cada vez que recibe una corrección.

Mi wiki no es memoria mágica

Uso una wiki porque necesito consolidar conocimiento que merezca ser encontrado y revisado por personas y agentes.

Eso no significa guardar toda conversación ni volcar todo lo que ocurrió dentro de una carpeta.

Memoria y wiki cumplen funciones diferentes en mi sistema.

La memoria ayuda a retomar continuidad: qué ocurrió, dónde se detuvo el trabajo, qué señales pueden ser relevantes ahora.

La wiki organiza conocimiento que ya fue trabajado: hipótesis explícitas, decisiones vigentes, síntesis, patrones, límites y relaciones con sus fuentes y aplicaciones.

Ninguna está por encima del archivo que gobierna el asunto hoy. Si una especificación actual contradice una síntesis antigua, gana la especificación. Si corrijo una interpretación sobre mí, la corrección no necesita pedir permiso a un resumen producido por un agente.

La misma distinción apareció cuando la IA olvidó justamente lo que yo ya había decidido. Recuperar contexto es importante. Saber qué archivo tiene autoridad sobre cada decisión es otra cosa.

Una wiki reduce el redescubrimiento.

No convierte un texto bien organizado en verdad.

Tres objetos son suficientes para empezar

Una primera wiki para agentes no necesita nacer con una taxonomía —un esquema organizado de clasificación— digna de la Biblioteca de Alejandría.

Yo empezaría con tres objetos.

1. Hipótesis

Guardan posibilidades aún no confirmadas.

Una hipótesis registra la laguna, su origen, evidencias a favor y en contra, uso provisional permitido, dependientes, condición de promoción y condición de descarte.

Puede ayudar al agente a formular una pregunta mejor o avanzar en un borrador reversible. No puede eliminar silenciosamente una duda ni convertirse en fuente de verdad por repetición.

2. Decisiones

Guardan direcciones realmente adoptadas por la persona responsable.

Una decisión registra el veredicto, las razones relevantes, el alcance, las excepciones, a quién o qué afecta y cuándo necesita ser revisada.

Decisión no es sinónimo de recomendación. Que tres agentes estén de acuerdo sigue produciendo una recomendación. La dirección cambia cuando el decision owner —la persona responsable del veredicto— adopta, corrige o rechaza la propuesta.

3. Síntesis

Guardan el razonamiento que no cabe en un veredicto corto.

Una buena síntesis preserva fuentes, convergencias, divergencias, hipótesis abiertas, recomendación y riesgo residual —el riesgo que continúa existiendo después de los controles o decisiones adoptados. No necesita reproducir la conversación entera. Necesita conservar lo que explica por qué esa dirección parecía razonable y qué continuó sin respuesta.

Cuando una síntesis conduce a una decisión, ambas deben apuntar una a la otra.

La decisión muestra qué gobierna ahora.

La síntesis preserva el camino, incluidas las divergencias que el resumen más conveniente intentaría borrar.

El conocimiento que no llega a la aplicación se convierte en museo

Una página puede ser impecable y aun así no cambiar nada.

Si el sistema no sabe quién consume esa información, la wiki se convierte en un lugar bonito donde las decisiones van a descansar después de morir.

Por eso conecto conocimiento y aplicación.

Una hipótesis sobre mi estilo puede afectar a los agentes que escriben, traducen y revisan la voz. Una decisión sobre privacidad puede afectar herramientas, registros técnicos de eventos (logs), publicación y retención. Una síntesis sobre un cliente puede sostener una propuesta, pero no debería filtrarse a otro contexto.

El mismo principio aparece en mi CHARACTER.md. Un punto ciego solo adquiere valor cuando produce un contrapeso observable en el sistema.

En la wiki, el equivalente es preguntar:

Si esta información cambia mañana, ¿quién necesita saberlo?

Si la respuesta es “nadie”, quizá todavía sea solo una nota.

No toda observación merece una página

La gobernanza también puede convertirse en escondite.

Es perfectamente posible pasar más tiempo creando campos, índices y relaciones que tomando la decisión que justificaría todo eso.

No quiero convertir cada frase provisional en un proceso administrativo.

Vale la pena promover una observación a la wiki cuando aparece al menos una de estas condiciones:

  • será reutilizada en más de una sesión o por más de un agente;
  • cambia comportamiento, permiso, prioridad, arquitectura o comunicación;
  • supone un riesgo relevante si está equivocada;
  • ya fue redescubierta o discutida más de una vez;
  • tiene varios consumidores que necesitarán actualizarse juntos;
  • perder su origen volvería costosa o ambigua la corrección.

Una duda local, barata y descartable puede permanecer en el trabajo actual.

El registro debe ser proporcional al costo de olvidar, distorsionar o repetir el error.

Un bloque de instrucciones inicial para crear esta wiki

El bloque siguiente es un prompt —un conjunto de instrucciones para orientar la tarea— intencionalmente pequeño e independiente de herramientas. Puede usarse con Codex, Claude u otro agente capaz de trabajar con archivos y Git.

No copia mi harness. Es una primera estructura para que la pruebes y la adaptes a tu contexto.

AGENTS.md es el archivo de entrada: presenta propósito, autoridad, reglas, validaciones y navegación antes de que el agente abra el resto. Las estructuras reutilizables de archivo —las plantillas— definen la forma mínima que cada hipótesis, decisión o síntesis debe completar.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
Crea una wiki inicial y revisable usando archivos Markdown versionados en Git.
Debe ser legible por personas y agentes, sin depender de memoria mágica.

Empieza con:
- AGENTS.md como punto de entrada: explica propósito, autoridad, navegación,
  reglas de privacidad y validaciones;
- hypotheses/ para posibilidades todavía no confirmadas;
- decisions/ para direcciones adoptadas por la persona responsable;
- syntheses/ para fuentes, razonamiento, convergencias, divergencias y límites.

Define estructuras reutilizables de archivo (plantillas) mínimas.

Para cada hipótesis, registra: estado, origen de la laguna, formulación explícita,
evidencias a favor y en contra, confianza y límites, alcance de uso provisional,
consumidores o impactos, acción tomada, condición de revisión, promover si y
descartar si.

Para cada decisión, registra: responsable del veredicto, decisión adoptada,
razones y evidencias relevantes, alcance, excepciones, consumidores afectados,
hipótesis y síntesis relacionadas y condición de revisión.

Para cada síntesis, registra: pregunta, fuentes, puntos de convergencia,
divergencias preservadas, hipótesis abiertas, decisiones relacionadas, límites y
la siguiente aplicación posible.

Reglas obligatorias:
1. la repetición no promueve una hipótesis a hecho;
2. la confirmación o negación debe generar una propuesta para actualizar a los
   consumidores afectados;
3. las fuentes actuales y las decisiones humanas explícitas prevalecen sobre
   las síntesis;
4. no registres secretos, credenciales, datos personales ni contenido sensible
   innecesario;
5. no ejecutes una publicación, eliminación o acción externa solo porque cambió
   la wiki;
6. mantén una fuente canónica por decisión y usa el historial de Git para revisar
   cambios, sin crear archivos "final-v2".

Antes de crear archivos, muestra el árbol mínimo propuesto, las plantillas y lo
que quedará deliberadamente fuera de esta primera versión. Esta es una wiki
incipiente, no una copia de otro harness ni una promesa de arquitectura universal.

Como punto de entrada, ese archivo no necesita cargar toda la wiki. Debe enseñar al sistema a encontrar la menor fuente suficiente.

Markdown y Git ayudan porque hacen visible el cambio

Prefiero que este conocimiento viva en archivos de texto simples con Markdown e historial en Git.

No porque sean las únicas tecnologías posibles.

Sino porque puedo leer el material sin una herramienta propietaria, comparar cambios, revisar una propuesta, volver a una versión anterior y descubrir cuándo una hipótesis ganó o perdió alcance.

El control de versiones registra cambios a lo largo del tiempo y permite comparar o recuperar estados. Eso sostiene el rastro técnico.

No sostiene la verdad del contenido.

Git puede demostrar que una frase cambió. No puede demostrar que la nueva frase es correcta.

Para eso todavía necesito fuentes, pruebas, una persona responsable y revisión.

La dirección sigue siendo mía

Construí agentes para buscar evidencia contraria, recordar decisiones anteriores y señalar cuándo una respuesta demasiado agradable puede estar ocultando un problema. Eso se conecta directamente con el principio de que la mejor respuesta no es la que más me agrada.

Aun así, el agente no se convierte en árbitro de la verdad solo porque obtuvo una wiki.

Puede registrar que existe una hipótesis.

Puede mostrar dónde fue aplicada.

Puede preparar la actualización de los consumidores si la confirmo o la niego.

Puede evitar que “no sé” desaparezca cuando una conversación larga se resume para caber en el espacio disponible, un proceso llamado compactación de contexto.

El veredicto sigue dependiendo de quien responde por la decisión y sus consecuencias.

Este es el tipo de sistema que construyo en i-9.ai: no una memoria infinita que promete saberlo todo, sino una operación capaz de mostrar qué sabe, qué supone, quién decidió y qué debe revisarse cuando la realidad responde de otro modo.

Si tu empresa ya usa IA, pero decisiones, premisas y correcciones siguen perdiéndose entre chats, documentos y personas, ponte en contacto. Podemos empezar por la decisión que más se repite y por el error que sería costoso si una hipótesis silenciosa empezara a gobernarla.

Una hipótesis no necesita estar prohibida.

Necesita seguir siendo reconocible como hipótesis hasta que alguien con autoridad y evidencia suficientes decida en qué se convierte.

Continúa leyendo

Para profundizar

Referencias y límites de uso

  • AGENTS.md describe un formato abierto y legible para orientar agentes sobre contexto e instrucciones. No garantiza que toda herramienta interprete de la misma manera precedencia, comandos o archivos anidados; valida el comportamiento del agente elegido.
  • La guía de prompt engineering de OpenAI sustenta únicamente la explicación de que los prompts orientan el comportamiento del modelo y pueden refinarse. Es documentación de un proveedor, no un estándar universal de enrutamiento o calidad.
  • El glosario de OpenTelemetry, las entradas del NIST para taxonomía y riesgo residual, y la familia PROV del W3C sustentan definiciones puntuales. El glosario del NIST está orientado a seguridad; este artículo usa solo las definiciones generales de esquema de clasificación y riesgo remanente, simplifica los conceptos para la gobernanza editorial y no afirma cumplimiento integral con esos estándares.
  • Pro Git, “Acerca del control de versiones” sostiene la explicación de que el control de versiones registra cambios y permite recuperar estados anteriores. No valida el contenido de una decisión ni reemplaza copias de seguridad, políticas de acceso o revisión humana.
  • La documentación de compactación de OpenAI sustenta el ejemplo de reducir el contexto de una conversación conservando estado útil. Describe una implementación específica de la API de OpenAI; no demuestra que toda herramienta compacte, resuma o descarte contexto de la misma manera.

La separación entre hipótesis, decisiones y síntesis, los campos sugeridos y el flujo de actualización de consumidores son una síntesis autoral de mi forma de operar agentes. No constituyen una norma universal, garantía de acierto ni copia completa de la arquitectura privada que uso. La versión propuesta en el prompt es deliberadamente inicial y debe reducirse, ampliarse o descartarse según el contexto y el riesgo reales.

La imagen de portada es una ilustración editorial sintética, independiente del idioma, sobre una hipótesis incompleta que pasa por confirmación, decisión, síntesis, aplicación y revisión.

Esta entrada está licenciada bajo CC BY 4.0 por el autor.

Conversación abierta

Continúa la conversación

¿No estás de acuerdo, encontraste una laguna o tienes una experiencia que amplía el tema? Comenta con tu cuenta de GitHub. No publiques datos personales, credenciales ni información sensible.