Resumen
Los procesos complejos suelen comenzar con una narrativa y terminar exigiendo una respuesta técnica. Entre ambos extremos existe un trabajo de ingeniería de la prueba: descomponer alegaciones en cuestiones verificables, preservar datos, seleccionar documentos, formular preguntas, definir métodos, acompañar diligencias y evaluar si el informe realmente sostiene sus conclusiones. Este artículo presenta un framework integrado aplicable a ingeniería, sistemas, evidencia digital y blockchain, alineado con buenas prácticas internacionales de evidencia digital e informes periciales. El objetivo es reducir el riesgo de que una controversia técnica se convierta en una mera disputa de opiniones y aumentar la trazabilidad entre hecho, método y conclusión.
Palabras clave: prueba pericial; metodología; preguntas periciales; asistencia técnica; evidencia; informe pericial.
1. El proceso comienza con una narrativa; el peritaje debe llegar a observables
Una demanda puede afirmar:
“hubo fraude”;
“el sistema falló”;
“la red dañó el equipo”;
“los criptoactivos fueron desviados”;
“el servicio fue inadecuado”.
Estas frases organizan la controversia jurídica, pero todavía no constituyen objetos técnicos suficientemente definidos.
El trabajo pericial empieza con una pregunta: ¿qué hechos mensurables tendrían que ser verdaderos para respaldar o debilitar esa afirmación?
2. Primer paso: construir un árbol de la controversia
Un método útil consiste en descomponer la cuestión por niveles.
Nivel 1 — cuestión principal
Ejemplo: ¿la falla del equipo es compatible con una perturbación eléctrica externa?
Nivel 2 — subcuestiones
¿hubo una perturbación?;
¿cuál fue su magnitud y duración?;
¿el equipo estaba operando?;
¿existe un mecanismo físico compatible?;
¿había degradación previa?;
¿actuaron las protecciones?
Nivel 3 — evidencia
power quality logs;
relés;
mantenimiento;
inspección;
ensayos;
documentación del fabricante.
Este mapa impide saltar directamente de la narrativa a la conclusión.
3. Segundo paso: formular hipótesis competidoras
El enfoque científico mejora cuando se construyen explicaciones alternativas.
En fraude digital:
H1 — operación realizada por el titular;
H2 — credencial comprometida;
H3 — cuenta recuperada por un tercero;
H4 — dispositivo legítimo controlado indebidamente;
H5 — error operacional o sistémico.
En ingeniería:
H1 — evento externo;
H2 — falla interna;
H3 — mantenimiento deficiente;
H4 — sobrecarga;
H5 — combinación de factores.
El objetivo de la prueba es obtener datos capaces de discriminar entre hipótesis, no simplemente acumular material favorable a una sola narrativa.
4. Tercer paso: crear una matriz de evidencia
Una matriz sencilla puede incluir:
Cuestión | Evidencia necesaria | Fuente | ¿Existe? | Riesgo de pérdida | Acción
|
|---|---|---|---|---|---|
Autenticación | log de MFA | banco | desconocido | alto | solicitar/preservar |
Evento eléctrico | oscilografía | relé | sí | medio | exportar original |
Wallet | txid + withdrawal log | exchange | parcial | medio | correlacionar |
Esta herramienta conecta la estrategia jurídica con la realidad técnica.
5. La evidencia debe preservarse antes de interpretarse
En datos digitales, integridad y procedencia son prerrequisitos.
ISO/IEC 27037 ofrece orientaciones para identificación, recolección, adquisición y preservación de evidencia digital.[1] NIST SP 800-86 estructura el trabajo forense en recolección, examen, análisis e informe.[2]
Una evidencia debería permitir responder:
¿de dónde provino?;
¿quién la recolectó?;
¿cuándo?;
¿mediante qué procedimiento?;
¿en qué formato?;
¿hubo transformación?;
¿existe hash?;
¿el original sigue disponible?
La preservación debe preceder a la discusión sobre significado.
6. Un screenshot es una representación, no necesariamente la fuente primaria
Las capturas de pantalla son útiles para comunicar, pero con frecuencia pierden metadatos, estructura y capacidad de reproducción.
En blockchain, conviene preservar txid, bloque y datos brutos. En logs, exportar registros nativos. En equipos, conservar archivos y configuraciones. En sistemas, mantener documentación del schema y de los filtros utilizados.
ISO/IEC 27042 enfatiza el análisis y la interpretación documentados de forma que puedan evaluarse validez, reproducibilidad y repetibilidad en el trabajo con evidencia digital.[3]
7. Cuarto paso: definir el método antes de examinar el resultado
ASTM E3176-24 ofrece orientación sobre propósito, contenido y limitaciones de los informes de ingeniería forense, reforzando la necesidad de alcance claro, base técnica y metodología explícita.[4]
Un método debería aclarar:
fuentes;
criterios;
instrumentos;
versiones de software;
normas;
procedimientos de medición;
tratamiento de datos;
incertidumbre;
limitaciones.
La metodología debe ser adecuada al objeto. No existe un “método pericial universal”.
8. Quinto paso: transformar la matriz en preguntas periciales
Cada laguna o hipótesis puede convertirse en una pregunta.
Una buena pregunta:
es técnica;
es específica;
no presupone hechos no demostrados;
no exige una valoración jurídica;
apunta a un dato o método;
ayuda a discriminar hipótesis.
Ejemplo deficiente:
“¿Hubo fraude?”
Mejor:
“¿Qué mecanismos de autenticación fueron utilizados, qué registros los demuestran y hubo cambios de dispositivo o credencial durante el período anterior a la transacción?”
La segunda pregunta produce información auditable.
9. Sexto paso: preparar la diligencia como un experimento observacional
Una diligencia debería contar con un plan.
Antes:
¿qué será observado?;
¿qué instrumentos se utilizarán?;
¿qué condiciones deben permanecer constantes?;
¿qué fotografías son necesarias?;
¿qué datos serán copiados?;
¿quién estará presente?;
¿qué modificaciones del lugar deben registrarse?
Durante:
documentar la secuencia;
registrar configuraciones;
identificar equipos;
anotar imprevistos;
preservar muestras cuando corresponda.
Después:
organizar datos;
generar hashes;
mantener copias originales;
registrar transformaciones.
10. Séptimo paso: distinguir dato, interpretación y conclusión
Un informe claro debería permitir separar:
Dato: tensión registrada de X en el horario Y.
Interpretación: el evento se encuadra en determinada categoría técnica.
Conclusión: el evento es o no compatible con el mecanismo de falla analizado.
En blockchain:
Dato: la transacción X transfirió el token Y.
Interpretación: la llamada corresponde a un bridge deposit.
Conclusión: el flujo es compatible con una transferencia cross-chain.
Esta estructura muestra dónde hay medición y dónde comienza la inferencia.
11. Octavo paso: exigir trazabilidad de la conclusión
Para cada conclusión relevante, conviene preguntar:
¿qué datos la respaldan?;
¿qué premisas fueron adoptadas?;
¿qué método conecta los datos con la conclusión?;
¿se probaron hipótesis alternativas?;
¿existe evidencia contradictoria?;
¿qué incertidumbre permanece?
Este proceso se asemeja a una revisión de ingeniería: la conclusión debe tener un camino auditable de vuelta a la evidencia.
12. Noveno paso: analizar el informe sin limitarse a buscar “errores”
El análisis crítico no es una cacería de fallas. Puede haber acuerdo parcial o total.
El asistente debe evaluar:
alcance;
completitud;
método;
datos;
normas;
causalidad;
reproducibilidad;
coherencia lógica;
limitaciones;
respuestas a las preguntas.
Un informe técnico robusto debe preservar la trazabilidad lógica entre evidencia y conclusión y mantenerse dentro del alcance técnico definido.[4]
13. Décimo paso: traducir tecnología para la decisión
Un informe no debería ser un manual técnico incomprensible. Su función es esclarecer el proceso.
Una buena comunicación puede utilizar:
cronología;
diagramas;
tabla de hipótesis;
mapa de evidencia;
flujos;
fotografías anotadas;
gráficos con unidades y escalas;
glosario.
Simplificar el lenguaje no significa simplificar el método.
14. Un framework integrado
El proceso puede resumirse en diez verbos:
Delimitar → Hipotetizar → Mapear → Preservar → Metodizar → Preguntar → Observar → Correlacionar → Probar → Comunicar.
Este flujo es aplicable, con adaptaciones, a:
ingeniería eléctrica;
fallas de equipos;
telecomunicaciones;
software;
fraude bancario;
evidencia digital;
blockchain;
autenticación;
análisis documental técnico.
15. Conclusión
La prueba técnica de calidad no comienza cuando el perito abre el informe. Comienza cuando la controversia se convierte en preguntas verificables y se identifica qué evidencia puede responderlas.
Documentos, preguntas, diligencia y análisis del informe no son etapas independientes. Forman un sistema.
Cuanto más trazable sea el camino alegación → hipótesis → evidencia → método → resultado → conclusión, menor será el espacio para conclusiones intuitivas o técnicamente opacas.
En procesos complejos, esa puede ser una de las principales funciones de la ingeniería aplicada a la prueba: transformar una disputa de narrativas en una estructura de hechos que pueda ser examinada, reproducida y criticada.
15A. Una cadena explícita de razonamiento probatorio
Una conclusión técnica robusta debe poder rastrearse hacia atrás desde la conclusión a la interpretación, desde ésta al dato observable y desde el dato a su procedencia y preservación. Como síntesis editorial de esta serie, el flujo puede expresarse así: Delimitar → Hipotetizar → Mapear → Preservar → Metodizar → Preguntar → Observar → Correlacionar → Probar → Comunicar. Es un flujo propuesto, no una norma técnica independiente.
Referencias
ISO/IEC.
ISO/IEC 27037:2012 — Guidelines for identification, collection, acquisition and preservation of digital evidence
. https://www.iso.org/standard/44381.html
NIST.
SP 800-86: Guide to Integrating Forensic Techniques into Incident Response
. https://doi.org/10.6028/NIST.SP.800-86
ISO/IEC. ISO/IEC 27042:2015 — Guidelines for the analysis and interpretation of digital evidence. https://www.iso.org/standard/44406.html
ASTM International. ASTM E3176-24 — Standard Guide for Forensic Engineering Expert Reports. https://store.astm.org/e3176-24.html
ISO.
ISO 31000:2018 — Risk management — Guidelines
. https://www.iso.org/standard/65694.html
ISO/IEC.
ISO/IEC 27042:2015 — Guidelines for the analysis and interpretation of digital evidence
. https://www.iso.org/standard/44406.html
ISO/IEC.
ISO/IEC 27043:2015 — Incident investigation principles and processes
. https://www.iso.org/standard/44407.html
Nota editorial: el framework debe adaptarse al objeto y a las reglas procesales aplicables al caso concreto. Es una estructura metodológica, no un sustituto de la estrategia jurídica.