Problema
Muchas empresas dicen que estan aprendiendo con IA, pero no registran las decisiones que toman con IA. Guardan prompts, dashboards, actas y tickets. No guardan el razonamiento operativo que explica por que una decision se tomo, que criterio se uso y que cambio despues.
El resultado es fragil: cada equipo aprende en privado, cada piloto reinventa sus criterios y cada error vuelve disfrazado de caso nuevo.
Tesis
Un AI Decision Ledger es la memoria minima de una organizacion que gobierna IA en serio. No sirve para documentarlo todo. Sirve para que las decisiones importantes dejen rastro, puedan auditarse y mejoren con cada ciclo.
Sin ledger, no hay aprendizaje compuesto. Hay opinion acumulada.
Framework
Un decision ledger registra cinco cosas:
- Contexto: que sabia el sistema o el equipo cuando decidio.
- Criterio: que regla, threshold o politica se aplico.
- Owner: quien podia aceptar, corregir o parar la decision.
- Resultado: que paso despues de ejecutar.
- Aprendizaje: que debe cambiar en el sistema.
No es un repositorio de documentos. Es una capa de gobierno sobre decisiones repetibles.
Mini-caso: un equipo comercial usa IA para priorizar cuentas. Durante seis semanas, el modelo recomienda leads que parecen buenos pero consumen mucho tiempo de preventa. Sin ledger, el debate se convierte en “el modelo falla” contra “ventas no lo usa bien”. Con ledger, se ve el patron: el criterio de priorizacion premia intencion declarada, pero no penaliza complejidad operativa. La correccion no es cambiar de modelo. Es cambiar el criterio.
Senal medible: porcentaje de decisiones criticas que tienen contexto, criterio, owner y resultado registrado.
Postura: si una decision no deja rastro, no pertenece todavia a un sistema autonomo.
Respiracion: la trazabilidad no es burocracia cuando evita discutir el mismo error tres veces.
Que debe entrar en el ledger
No todas las decisiones merecen registro. El ledger debe cubrir decisiones que cumplan al menos una de estas condiciones:
- afectan margen, riesgo, cliente o cumplimiento
- pueden repetirse muchas veces
- dependen de un modelo, agente o workflow automatizado
- requieren excepcion humana
- fueron revertidas o escaladas
Una buena regla: si el equipo podria necesitar explicar la decision dentro de tres meses, entra en el ledger.
Que no debe entrar
El anti-ejemplo es convertir el ledger en una base documental imposible de mantener. Si cada prompt menor, cada comentario y cada ajuste entra, el sistema se abandona.
El ledger no registra actividad. Registra decisiones que cambian la operacion.
Protocolo (3 pasos)
- Define las decisiones ledger-worthy. Empieza con 5-10 tipos de decision: pricing, priorizacion, escalado, aprobacion, rechazo, pausa o excepcion.
- Estandariza el registro. Contexto, criterio, owner, resultado y aprendizaje. Nada mas al principio.
- Revisa por patrones, no por casos sueltos. Cada semana busca criterios rotos, owners ambiguos y decisiones que se revierten demasiado.
| Campo | Pregunta | Error comun |
|---|---|---|
| Contexto | Que sabia el sistema al decidir | guardar solo el output |
| Criterio | Que regla hizo valida la decision | confundir preferencia con policy |
| Owner | Quien podia corregir o parar | dejarlo en “el equipo” |
| Resultado | Que ocurrio despues | medir solo velocidad |
| Aprendizaje | Que cambia en el sistema | cerrar el caso sin modificar nada |
Cuando no necesitas un decision ledger
Si el workflow es exploratorio, de bajo riesgo y no se repite, un ledger puede ser exceso. En esa fase basta con notas claras y revision ligera.
El ledger empieza a importar cuando la decision se repite, impacta el negocio o empieza a moverse fuera del control directo de una persona.
Relacionado
- Decision Quality KPI: el indicador que reemplaza velocidad
- Decision Rights Map: quien decide que en un sistema IA
- Executive Review Stack for AI: que debe mirar un CEO cada semana para gobernar sin teatro
Proximo paso
Si tus decisiones de IA no pueden reconstruirse desde contexto, criterio y owner, todavia no tienes governance. Tienes confianza informal. Podemos convertirlo en un sistema durante un diagnostico.