Tu sistema registra todo: actor, entrada, herramienta invocada, acción, aprobación, resultado, hora. Siete campos impecables, exportables, con timestamps. El área de TI los muestra con orgullo cuando alguien pregunta por trazabilidad.
Y el día del incidente descubrís que esos siete campos responden una sola pregunta, qué pasó, y que la pregunta del incidente es otra: por qué. El día que necesités la diferencia será el peor día para descubrir que no la tenías.
Auditar sistemas de IA no es acumular registros. Es poder reconstruir las causas de una decisión, con la profundidad que el riesgo del puesto exige. Esa disciplina tiene nombre en el libro, capítulo 7: auditar no es registrar.
El porqué vive en los determinantes
Los determinantes de una decisión son las condiciones que la produjeron: qué política estaba vigente cuando se ejecutó la acción, qué conocimiento consultó el sistema, qué le devolvieron las herramientas, qué autoridad tenía en ese momento y qué versiones de todo lo anterior operaban.
Sin los determinantes, una falla no puede atribuirse a su causa. Y las causas posibles son al menos cinco, cada una con un remedio distinto: una política mal escrita, un conocimiento que envejeció sin que nadie lo actualizara, una herramienta que devolvió datos malos, un modelo que erró, o un rol que nunca debió asignarse a un recurso artificial. Corregir la primera es reescribir un documento. Corregir la última es devolver el puesto a manos humanas. No se parecen en nada.
El problema es que bajo un registro de solo-qué, esas cinco causas dejan huellas idénticas. El postmortem elige una al azar, la organización «corrige» la equivocada, y la falla real queda intacta esperando su segunda oportunidad. Con la misma política, el mismo dato viejo o la misma herramienta rota en su lugar.
Cuatro historias, un solo registro
El libro lo aterriza con el hilo de cobranza que recorre sus capítulos. El rol envió un recordatorio de pago a una cuenta en disputa: exactamente lo que su contrato de rol prohíbe. ¿Por qué?
Quizá la marca de disputa no existía en el sistema cuando consultó: un problema de datos. Quizá existía, pero la política que define «disputa» cambió la semana pasada y su contexto tenía la versión vieja: un problema de conocimiento. Quizá la herramienta de consulta devolvió el estado desactualizado: un problema de integración. Quizá todo estaba bien y el modelo lo ignoró: un problema del modelo. Cuatro historias, cuatro culpables, cuatro remedios distintos.
Y un solo registro: «mensaje enviado a las 9:14». La auditoría de determinantes es lo que separa esas cuatro historias. El log, por impecable que sea, no puede.
La razón profunda para reconstruir determinantes no es técnica sino administrativa: cada causa apunta a un responsable distinto. La política mal escrita es del que la redactó. El conocimiento viejo es del que debía actualizarlo. La herramienta rota es del que la integra. Sin determinantes, la culpa cae sobre quien esté más cerca del incidente. El libro cierra el capítulo con la regla exacta: la culpa sigue a los determinantes, no a la proximidad.
El relato del modelo no es la auditoría
Hay una tentación moderna que merece advertencia específica: preguntarle al modelo por qué lo hizo. Los modelos actuales narran su razonamiento con una elocuencia encantadora. Piden disculpas, señalan el paso donde «se confundieron», proponen cómo evitarlo. Es convincente. Y es inadmisible como prueba.
La razón es incómoda pero está bien establecida: lo que un sistema reporta haber pensado puede no ser lo que produjo su salida. La narración es una salida más del mismo modelo, generada después, no una ventana a su mecanismo. El libro la admite como apoyo, nunca como prueba. Una organización que toma el relato del modelo como el porqué va a escribir postmortems confiados y equivocados, que son los más caros de todos: cierran la investigación con la causa incorrecta y la seguridad de haberla encontrado.
La respuesta del auditor serio no cambia con la tecnología: no le preguntés al sospechoso, reconstruí la escena. Política vigente, conocimiento consultado, respuesta de herramientas, autoridad concedida, versiones operando. Eso no lo narra nadie. Se evidencia o no existe.
El manifiesto de versiones
La pieza que vuelve todo esto operable es humilde: el manifiesto de versiones. Modelo, políticas, herramientas y base de conocimiento, cada uno con versión identificable en todo momento. Sin él es imposible decir qué autoridad existía en un momento dado, ni qué cambio produjo una mejora o un deterioro. El estándar lo exige en la cláusula HWF-43, que cabe en una línea: «Un AI Employee debe tener una versión identificable de modelo, políticas, herramientas y knowledge base.»
Y acá viene un alivio para el operador pequeño, porque la carga es proporcional al riesgo. En puestos de riesgo Bajo y Moderado, correlacionar los registros de eventos contra el manifiesto de versiones es reconstrucción suficiente y conforme. Solo de Alto hacia arriba los determinantes se atan uno por uno a cada acción. El estándar no te pide instrumentación de laboratorio para un rol que envía recordatorios; te pide saber qué versión de qué cosa estaba viva cuando algo importante pasó.
La obligación completa vive en HWF-41: toda acción material debe ser auditable, y la auditoría debe poder reconstruir la política, el conocimiento, los resultados de herramientas, la autoridad y las versiones vigentes al momento de ejecutarse la acción. No es burocracia. Es la diferencia entre corregir la causa y corregir al azar.
Lo que funciona también puede dejar de funcionar
La auditoría no existe solo para el día del incidente. Existe porque el desempeño no es una propiedad eterna del sistema: es una relación entre el recurso, el puesto y el contexto. Y el contexto no firma contratos de estabilidad. Cambian productos, clientes, políticas, datos, costos y proveedores. Una actualización técnica puede mejorar una capacidad y afectar otra.
Por eso la evaluación no termina cuando el piloto sale bien. Conviene vigilar tendencias: una tasa de intervención humana que sube lentamente puede revelar degradación antes del incidente visible, porque el drift, la deriva gradual del comportamiento respecto de su desempeño validado, rara vez anuncia su llegada con un error espectacular. Un costo por resultado que sube puede volver insensata una configuración que conserva su precisión.
Y cuando cambia algo material (el modelo, las herramientas, las políticas, el conocimiento, la autoridad), el rol se revalida antes de operar, a la profundidad que su clase de riesgo exige. Documentar el cambio no demuestra que funciona: demostrarlo es un acto separado, y el orden importa. Primero la evidencia, después la operación.
Una versión es un registro, no una prueba.
Una prueba que podés hacer hoy
Elegí una acción real que tu automatización más importante ejecutó la semana pasada. Una concreta. ¿Podés decir qué versión de qué política estaba vigente en ese momento? ¿Qué datos consultó y qué le devolvieron? ¿Qué autoridad tenía?
Si la respuesta es «tendría que preguntarle al proveedor», tu auditoría vive en las manos de alguien que no responde por tus consecuencias. El proveedor no firma tus postmortems, no enfrenta a tu cliente dañado y no le explica al board por qué la falla se repitió. Vos sí. La capacidad de reconstruir el porqué tiene que vivir de tu lado del mostrador, dimensionada al riesgo de cada puesto.
Registrar es barato y por eso todos lo hacen. Auditar es reconstruir. Y se diseña antes.
Preguntas frecuentes
Auditar es poder reconstruir los determinantes de una decisión, no solo su resultado: qué política estaba vigente cuando se ejecutó la acción, qué conocimiento consultó el sistema, qué devolvieron las herramientas, qué autoridad tenía y qué versiones de todo lo anterior operaban. Un registro tradicional (actor, acción, resultado, hora) solo responde qué pasó; la auditoría responde por qué, que es la pregunta del día del incidente. Sin esa capacidad, causas distintas dejan huellas idénticas, el postmortem elige una al azar y la organización corrige la equivocada mientras la falla real espera su segunda oportunidad.
Son las condiciones que produjeron la decisión: la política vigente al momento de ejecutar la acción, el conocimiento que el sistema consultó, los resultados que le devolvieron sus herramientas, la autoridad que tenía concedida y las versiones de modelo, políticas, herramientas y base de conocimiento que operaban. Importan porque las causas posibles de una falla son al menos cinco (política mal escrita, conocimiento envejecido, herramienta con datos malos, error del modelo, o un rol que nunca debió asignarse a un recurso artificial) y cada una tiene un remedio y un responsable distintos. Los determinantes son lo que permite atribuir la falla a su causa real.
Como apoyo, sí; como prueba, nunca. Los modelos actuales narran su razonamiento con elocuencia, pero lo que un sistema reporta haber pensado puede no ser lo que produjo su salida: la explicación es una salida más del mismo modelo, generada después, no una ventana a su mecanismo. Una organización que toma esa narración como el porqué escribe postmortems confiados y equivocados, los más caros de todos, porque cierran la investigación con la causa incorrecta. La alternativa es reconstruir la escena con evidencia: política vigente, conocimiento consultado, respuestas de herramientas, autoridad y versiones al momento de la acción.
Es el registro que mantiene identificable, en todo momento, la versión del modelo, de las políticas, de las herramientas y de la base de conocimiento con las que opera un Empleado IA. Sin él es imposible decir qué autoridad existía en un momento dado ni qué cambio produjo una mejora o un deterioro. Vuelve operable la auditoría con carga proporcional al riesgo: en puestos de riesgo Bajo y Moderado basta correlacionar los registros de eventos contra el manifiesto; de Alto hacia arriba, los determinantes se atan uno por uno a cada acción. El estándar lo exige en una línea: modelo, políticas, herramientas y knowledge base con versión identificable.
Las escalaciones perdidas que la auditoría descubre alimentan el scorecard del Empleado IA. Y cuando los determinantes muestran que el puesto ya no se justifica en manos artificiales, aplica la regla siguiente: nada merece el puesto para siempre.
¿Querés el método completo? Leé Empleado IA. Para consultoría ejecutiva en IA o conferencias y talleres.
Profundizar
¿Querés llevar tu equipo al siguiente cinturón?
Reservá una llamada de descubrimiento o explorá el libro completo.