← Henry Nawrocki · AUDITORÍA DE EJEMPLO
Explorar el caso interactivo →
Tu sistema cuenta una historia. Yo la mido.
Auditoría de afirmaciones frente a evidencia, realizada en mi propia plataforma. Resumen público de los hallazgos y sus límites. Traducción del relato original en inglés.
Un sistema en producción puede funcionar aunque la información utilizada para operarlo sea incorrecta. Estos tres casos de DiTrack muestran cómo comparo una afirmación con una observación, separo hallazgos de hipótesis e identifico un control capaz de detectar discrepancias futuras.
Este es un resumen público, no un expediente completo de evidencia para un cliente. Ilustra el método sin publicar registros operativos ni identificadores de dispositivos.
Resumen de hallazgos
Son observaciones históricas de mi propia plataforma, resumidas para su revisión pública. Aquí no se publican los registros originales, las consultas ni los identificadores de dispositivos, y las observaciones no se han vuelto a verificar de forma independiente. La entrega a un cliente incluye evidencia reproducible dentro de los límites de acceso y confidencialidad acordados.
| Afirmación | Observación reportada | Base de la evidencia | Confianza y límites | Consecuencia | Control de seguimiento |
|---|---|---|---|---|---|
| El rastreador se apaga al indicar cierto porcentaje de batería | La transmisión se detuvo entre 3596 y 3632 mV mientras continuaba el almacenamiento local | 14 episodios de silencio en seis dispositivos; lecturas de parámetros | Observado en esta muestra; la causa interna y el estado de la batería siguen sin demostrarse | Revisar la interpretación de la batería antes de reemplazar equipos | Alerta de voltaje, con validación del umbral y de la entrega |
| La copia de la referencia de parámetros está completa | Recuentos sin conexión de 388/388/398 frente a 558/573/599 en la fuente en línea | Comparación de la expansión de parámetros en la copia y en la fuente para tres modelos | Demuestra una diferencia entre estas versiones, no en todas las referencias del proveedor | Reconstruir la referencia afectada desde una fuente actual | Comprobar la revisión de la fuente antes de usarla |
| La documentación de arquitectura coincide con producción | Destino eliminado, columnas inexistentes, mecanismo de conexión incorrecto y estado desactualizado | Comandos citados en seis documentos comparados con producción | Abarca solo los documentos y comandos inspeccionados | Corregir los documentos antes de usarlos para realizar cambios | Volver a ejecutar controles de evidencia seleccionados y revisar los cambios |
Caso 1. El rastreador que «se apaga con 26 % de batería»
La afirmación. Nuestra propia documentación interna contenía una línea: «a02 = porcentaje de batería mediante AVL 113». Los equipos con batería interna dejaban de transmitir mientras informaban alrededor del 30 %. La interpretación era la misma para todos: la batería se agota antes de tiempo, el equipo es deficiente y hay que reemplazarlo.
La medición. Extraje 14 episodios de silencio de 6 dispositivos, a partir de sus registros almacenados y de parámetros leídos en los propios equipos.
Sin alimentación externa, una unidad transmite entre 78 y 97 minutos. Entre 3596 y 3632 mV, el módem deja de transmitir. El apagado real ocurre mucho después, a 3401 mV, y un dispositivo aportó evidencia: su última trama fue a 3401 mV y una consulta de versión 68 minutos después indicó una inicialización. Un reinicio. Entre ambos umbrales, la unidad sigue guardando datos con la misma cadencia. En estas observaciones, la pérdida de transmisión precedió al apagado final registrado. La plataforma dejó de recibir datos de un dispositivo que seguía almacenándolos.
AVL 113 no representaba carga: era voltaje cuantizado en pasos de 10 y con dos curvas distintas. A 3757 mV indica 70 durante la descarga y 10 durante la carga. Por encima de unos 3950 mV permanece en 100. Ese «30 %» al perder la transmisión era una lectura de voltaje presentada como porcentaje.
Explicaciones alternativas y límites. El parámetro 102 indicaba 0 (suspensión desactivada); la cadencia registrada pasó de 50,5 a 55,4 segundos. Los voltajes de carga de 4069 a 4125 mV no demuestran la capacidad de la batería ni descartan su degradación. Las temperaturas oscilaron entre 27 y 43 °C; esta muestra por sí sola no descarta efectos de temperatura. Se necesitarían pruebas de descarga controlada para separar estas causas.
Una segunda vía. Revisé el historial de cambios de firmware del proveedor, desde la revisión 112907 (abril) hasta la 116488 (agosto), que abarca las versiones 3.7.0 a 3.7.3. Ninguna menciona un umbral de batería baja o un corte del módem por voltaje. Tanto las unidades con 3.7.0 como las que usan 3.7.3 dejan de transmitir en la misma franja. Esto es compatible con un comportamiento asociado a un umbral que no aparece en el historial revisado; no demuestra su causa interna. El historial también aclaró otra idea equivocada: un fallo de «DOUT1 bloqueado» que atribuíamos a 3.7.0 ya estaba corregido en esa versión y solo se activa en un proceso que no usamos.
La diferencia. Una línea incorrecta en nuestra documentación y un comportamiento no documentado en el firmware de un tercero produjeron un plan de reemplazo de equipos para un problema que requería una decisión de configuración y una alerta.
Control implementado. Un proceso de consulta de solo lectura registra milivoltios reales y genera una alerta cuando una unidad con batería interna cruza los 3650 mV. El umbral busca advertir antes de la franja de silencio observada. Hay que probar los intervalos de muestreo, la conectividad y la entrega de alertas; no se garantiza el aviso.
Caso 2. La referencia a la que le faltaba un 30 % y parecía completa
La afirmación. Nuestra base de parámetros de una familia de dispositivos estaba completa. La había construido yo a partir de una copia de la wiki del proveedor y no tenía motivos para dudar de ella.
La medición. La plantilla copiada era la revisión 109672, de diciembre. La página en línea era la revisión 117278, editada esa misma mañana. Los identificadores y las fechas mostraban que eran versiones distintas; restar los identificadores no indica cuántas veces cambió esa página.
Expandí la lista de parámetros de tres modelos por ambas vías: sin conexión desde la copia y en el servidor desde la wiki actual. La copia dio 388, 388 y 398 parámetros; la fuente en línea dio 558, 573 y 599. Ninguno de los parámetros obtenidos sin conexión era inventado: todos existían. Simplemente faltaba alrededor del 30 %, y dos modelos resultaban idénticos aunque uno tiene parámetros Bluetooth que el otro no incluye. Otros 26 valores diferían por cambios en la fuente, no por el método. Nueve meses de ediciones de la wiki: un máximo pasó de 1 a 2 y un mínimo de 0 a 1.
Además, 776 parámetros de la familia nunca habían entrado en el índice. No era un fallo de extracción: la lista de prefijos del indexador no incluía la familia, por lo que el analizador nunca la buscó.
La lección, en una línea. Un método correcto aplicado a una fuente desactualizada produce datos incompletos que parecen completos.
La diferencia. El proveedor también había cambiado el mecanismo. La plantilla ahora se resuelve mediante 251 condiciones en un módulo Lua del servidor, y la tabla de pines que antes consultaba ya no existe. Nuestra expansión sin conexión dejó de reproducir el resultado en línea; una implementación alternativa tendría que validarse contra las dependencias actuales del servidor. Lo incorporé a la documentación para evitar que alguien repitiera el proceso a mano.
Control implementado. Comprobar la revisión de la página en línea antes de confiar en un parámetro de la copia. Un control sencillo que se ejecuta antes del trabajo.
Caso 3. Seis documentos de arquitectura contrastados con producción
La afirmación. La documentación de arquitectura estaba actualizada. La mayor parte era mía y reciente.
La medición. Volví a ejecutar cada comando citado en cada documento y comparé su resultado con el texto.
Un documento del flujo de alertas apuntaba a un servidor eliminado meses antes. Un documento de contratos declaraba 7 columnas que la tabla no tiene. Un diagrama dibujaba una conexión TCP entre dos servicios cuando el mecanismo real era la inserción de una fila en una tabla que consulta un proceso periódico. Y un documento de monitoreo describía como «sin conectar» un servicio que estaba activo desde abril.
Seis documentos. Cuatro tipos de discrepancia: destino eliminado, esquema inexistente, mecanismo incorrecto y estado desactualizado.
La diferencia. No eran fallos de los servicios: todos funcionaban. El mapa era incorrecto, y un mapa equivocado de cuatro formas distintas prepara al siguiente ingeniero para modificar producción con una confianza injustificada.
Control implementado. Un detector de discrepancias calcula diariamente la huella de un comando verificable por documento. No lee el texto: solo indica CHANGE y el documento afectado. Además, una cola de verificación vuelve a ejecutar cada comando citado y rechaza el documento si la evidencia no se reproduce.
El patrón
Busco cuatro fuentes recurrentes de discrepancias:
- Intención presentada como medición. Un campo escrito (
cut = true) mostrado como un estado observado (el relé está cortado). Es frecuente en los paneles. - Documentos que describen un sistema del pasado. Correctos el día en que se escribieron, pero nunca actualizados.
- Referencias que cambiaron sin aviso. Wikis de proveedores, documentación de API e historiales de cambios. Tu copia era correcta; la fuente cambió.
- Resultados convincentes que nadie verificó. Código, documentación y respuestas de agentes de IA que parecen terminados. En 2026, muchos equipos acumulan ese material sin mecanismos para comprobarlo.
El cuarto punto explica esta página. Uso a diario un asistente de IA en mis propios sistemas. Al principio produjo un análisis seguro de sí mismo, pero ficticio. Por eso definí las reglas de su trabajo: tres clases de afirmación (inferencia, condicional y evidencia), ningún «terminado» sin un resultado verificable, correcciones que prevalecen sobre los datos anteriores de su memoria y un registro de verificación para cada cifra que puede cambiar. Uso ese sistema a diario. Podría construir uno más acotado para tu equipo.
Henry Nawrocki. Fundador de DiTrack, un negocio de seguimiento de flotas en Perú, con trabajo directo de ingeniería de plataforma desde 2025. Anteriormente VP de IA e Ingeniería en Target Test Prep. Ruby on Rails, Python, PostgreSQL, integraciones GPS y operaciones de producción. Lima, Perú.
La propuesta
Auditoría de afirmaciones frente a evidencia. Dos semanas, un responsable, un sistema. Alcance y precio fijo acordados después de una llamada de 20 minutos.
- Una tabla que compara las afirmaciones de alto riesgo acordadas con observaciones, evidencia y nivel de confianza
- Las mediciones de cada hallazgo: el comando, la consulta o la lectura que lo produjo
- Un control automatizado acordado, instalado y probado con tu equipo, con instrucciones de mantenimiento y un responsable asignado
- Una lista de acciones para 90 días, priorizada por impacto operativo
Alcance: Un sistema en producción y un conjunto escrito de afirmaciones de alto riesgo acordado antes de comenzar. Las dos semanas empiezan cuando están disponibles el acceso de solo lectura, la evidencia y el contacto técnico necesarios. Los cambios en controles de producción requieren tu aprobación. El monitoreo y mantenimiento continuos se contratan por separado.
Para quién es: Equipos con un sistema en producción y una decisión importante bloqueada por paneles contradictorios, documentación desactualizada o resultados de IA sin verificar.
Fuera de alcance: Desarrollo continuo de tareas pendientes, reescritura completa del código o auditoría integral de seguridad o cumplimiento.