¿Y si cruzas la línea? · Límites éticos y legales en blockchain

🏠 Programa · 📚 Currículo · 📁 Casos reales · 📖 Glosario

Una blockchain puede mostrar movimientos, pero no explica por sí sola quién actuó, por qué lo hizo ni si estaba autorizado. Esta guía enseña a investigar incidentes de activos digitales sin convertir una señal técnica en una acusación ni una investigación defensiva en una intervención ilegítima.

No es asesoría jurídica. La organización debe determinar la jurisdicción, el contrato, la autoridad competente y las obligaciones aplicables con sus responsables legales y de cumplimiento. En el aula se trabaja exclusivamente con datos ficticios, redes locales, regtest, signet o fuentes públicas de solo lectura; nunca con fondos reales.

Revisión documental: 8 de septiembre de 2026. Las normas cambian y los casos judiciales avanzan. Comprueba siempre la fuente oficial y distingue acusación, condena y sentencia.

La línea que no se cruza

Investigar significa preservar y analizar evidencia dentro de una autorización. No autoriza a entrar en cuentas, obtener secretos, hacerse pasar por otra persona, explotar un sistema, mover activos, «devolver el golpe», congelar fondos ni publicar identidades. Que una acción parezca técnicamente posible o moralmente intuitiva no la vuelve legítima.

flowchart LR
  A[Observar una señal] --> B[Preservar sin alterar]
  B --> C[Analizar y contrastar]
  C --> D[Expresar certeza y límites]
  D --> E[Escalar por canal autorizado]
  E --> F[Decisión humana documentada]
  C -. línea roja .-> X[Acceder, explotar o suplantar]
  D -. línea roja .-> Y[Atribuir o publicar sin evidencia]
  E -. línea roja .-> Z[Mover o congelar fondos sin autoridad]

La regla de trabajo es sencilla: observar no es intervenir; inferir no es atribuir; reportar no es condenar. Ante una duda sobre autoridad o alcance, se detiene la acción, se conserva lo ya obtenido legítimamente y se escala.

El espejo de capacidades: la misma técnica, otra intención

Una capacidad no es buena o mala por sí sola. Lo decisivo es quién autoriza, qué alcance existe, qué datos se usan, qué acción se ejecuta y cómo se rinde cuenta. Este mapa ayuda a reconocer cuándo una práctica profesional empieza a cruzar la línea.

Prueba de los cinco permisos. Antes de actuar, el equipo debe contestar por escrito: (1) quién autorizó, (2) qué sistema y datos cubre, (3) durante qué periodo, (4) qué acciones permite y (5) cómo se detiene y reporta. Una respuesta vaga no amplía el permiso: obliga a detenerse.

Conductas y daños que el equipo debe saber reconocer

Esta sección describe qué proteger y por qué, no cómo ejecutar un delito. Se estudia con escenarios ficticios, evidencia ya provista y redes de prueba.

Apropiación de claves o fondos

Una private key, seed phrase, sesión de firma o fragmento MPC permite ejercer control técnico, pero no demuestra propiedad ni autorización. Extraerla mediante engaño, acceso indebido o abuso interno puede causar pérdida irreversible, exposición de clientes y una investigación penal. El profesional protege secretos, aplica doble control y preserva logs; nunca «prueba» una clave moviendo fondos ajenos.

Phishing, suplantación y aprobaciones engañosas

Una firma válida puede haber sido obtenida con una interfaz falsa, una dirección envenenada o una autorización que la persona no comprendió. La cadena prueba la firma y el cambio de estado, no el consentimiento informado. La prevención revisa dominio, contrato, red, destinatario, monto y allowance antes de aprobar.

Explotación no autorizada de contratos

Encontrar una vulnerabilidad no concede permiso para explotarla. La ruta profesional es reproducir el defecto localmente, reducir la prueba al mínimo, conservar evidencia y usar el canal de divulgación o bug bounty aplicable. «Code is law» no reemplaza contratos, deberes ni legislación.

Abuso de custodia y falsificación de registros

Un operador puede tener acceso legítimo y aun así actuar fuera de su mandato. Cambiar un ledger, omitir retiros, aprobarse a sí mismo o usar activos de clientes para trading transforma un fallo de control en daño patrimonial y posible evidencia de fraude o administración desleal, según la jurisdicción y los hechos. Acceso no equivale a autoridad.

PoR engañoso y pasivos incompletos

Una raíz Merkle correcta solo prueba la relación matemática con el dataset entregado. No prueba que todos los pasivos estén incluidos, que las wallets pertenezcan a la entidad, que los activos no estén gravados ni que existan después del corte. Ocultar cuentas, duplicar activos o presentar PoR como auditoría completa induce a decisiones erróneas.

Fraude de inversión y manipulación

Prometer retornos, ocultar conflictos, usar información falsa o simular actividad de mercado no se vuelve legítimo por usar un token, una DAO o una blockchain. El equipo debe separar diseño económico, divulgación verificable, custodia y autorización de cada comunicación.

Extorsión, lavado y evasión de controles

Mixers, swaps, bridges, monedas de privacidad y P2P tienen usos legítimos. Su presencia es un indicador contextual, no una condena. Importa la conducta completa: origen y destino, control, propósito, conocimiento, jurisdicción y evidencia corroborada. El analista no enseña a ocultar trazas ni evade controles; documenta riesgos y escala.

Destrucción o fabricación de evidencia

Borrar logs, reconstruir exports después del hecho o inventar una captura impide conocer lo ocurrido y puede agravar responsabilidades. Se preserva el original, se calcula su hash, se trabaja sobre copias y se registra cada transformación. Una tabla sin procedencia no es evidencia confiable.

Cinco niveles que no deben mezclarse

Esta separación es crucial en casos como Orionx: una diferencia entre libros y blockchain merece investigación, pero el informe debe distinguir cifras verificadas, afirmaciones de las partes, hipótesis y conclusiones de una autoridad.

El ruido de los instrumentos digitales

Una alerta puede tener explicaciones incompatibles entre sí. Un retiro no reconocido podría provenir de phishing, abuso interno, una integración defectuosa, una clave comprometida o una conciliación tardía. Una dirección compartida podría pertenecer a un exchange; una ruta indirecta podría ser cambio UTXO, un bridge o un contrato; un saldo contable «compensado» podría ocultar una salida real aunque el neto del libro sea cero.

Antes de elevar la gravedad, plantea al menos una explicación benigna y otra adversarial, y escribe qué evidencia distinguiría ambas. La calidad forense no se mide por cuántas direcciones colorea un grafo, sino por cuánto reduce la incertidumbre sin ocultar lo que no puede saberse.

Ocho mitos que hacen daño

¿De verdad nadie podrá relacionar la operación contigo?

La atribución seria no nace de una flecha en un explorador. Surge al correlacionar fuentes obtenidas legítimamente y someterlas a contradicción.

flowchart LR
  O[Hechos on-chain<br/>txid, bloque, contrato] --> C[Corroboración]
  X[Exchange<br/>cuenta, retiros, KYC] --> C
  I[IAM y dispositivo<br/>sesión, MFA, logs] --> C
  F[Banco y comercio<br/>fuentes financieras] --> C
  T[Contratos e instrucciones] --> C
  C --> H[Hipótesis con confianza<br/>y alternativas]
  H --> J[Decisión de autoridad<br/>con debido proceso]

Una dirección reutilizada, un retiro hacia un servicio regulado, el horario de una sesión, un dispositivo o una instrucción interna pueden adquirir significado al combinarse. Aun así, correlación no es sentencia: la adquisición debe ser lícita, la cadena de custodia íntegra y la interpretación revisable.

Consecuencias: no termina cuando termina la transacción

Según la conducta y la jurisdicción, pueden coexistir investigación penal, incautación o comiso, restitución, multas, prisión, demandas civiles, despido, pérdida de licencias, inhabilitaciones y daño profesional. El carácter transfronterizo tampoco crea inmunidad: exchanges, bancos, proveedores cloud y autoridades pueden conservar registros y cooperar mediante los procedimientos legales aplicables.

En Chile, la Ley 21.459 tipifica, entre otras conductas, ataques a sistemas y datos, acceso ilícito, falsificación informática y fraude informático. Que un hecho involucre criptoactivos no reemplaza el análisis de elementos, prueba, competencia y garantías; el equipo técnico describe hechos y preserva evidencia, no improvisa conclusiones jurídicas.

Casos documentados para estudiar decisiones, no para celebrar el daño

El estado procesal importa. Una denuncia o acusación contiene alegaciones; una declaración de culpabilidad, un veredicto y una sentencia son actos diferentes. Citar un caso exige fecha, tribunal, fuente y estado, y nunca autoriza a extrapolar culpabilidad a otra persona por similitud de patrón.

Casos que exigen respuestas diferentes

Respuesta a un incidente sin contaminar la evidencia

1. Contener mediante controles ya autorizados

Activa el plan de respuesta aprobado: rotación o pausa solo sobre sistemas propios y por las personas facultadas, doble control, preservación previa cuando sea viable y registro de cada cambio. Contener no significa perseguir fondos ni operar infraestructura de terceros.

2. Fijar el corte

Anota fecha, hora, zona temporal, red, altura y hash de bloque, versión del software y alcance. Conserva exports originales del ledger, exchange, IAM, MPC/HSM y monitoreo; calcula sus hashes y trabaja sobre copias. Sin un corte común, dos saldos correctos pueden parecer una discrepancia.

3. Reconstruir las tres realidades

flowchart TB
  L[Internal Ledger<br/>derechos y obligaciones] --> R[Conciliación por activo, red y corte]
  E[Exchange Reality<br/>órdenes, depósitos y retiros] --> R
  B[Blockchain State<br/>UTXO, cuentas y contratos] --> R
  R --> Q{¿Coinciden identidad,<br/>importe, estado y tiempo?}
  Q -->|Sí| C[Conclusión limitada y reproducible]
  Q -->|No| D[Diferencia clasificada + responsable + plazo]

Internal Ledger ≠ Exchange Reality ≠ Blockchain State. Ninguna fuente sustituye a las otras. El trabajo profesional demuestra cómo se relacionan mediante identificadores, timestamps, activos, redes, estados y evidencia de autorización.

4. Trazar solo con fuentes legítimas

Empieza con nodo propio o una API pública de solo lectura, conserva consultas y respuestas, y contrasta resultados relevantes. Una visualización es un derivado: debe poder reconstruirse desde la evidencia preservada. No recopiles datos personales que no sean necesarios para la pregunta autorizada.

5. Comunicar con lenguaje calibrado

Cada hallazgo debe indicar criterio, evidencia, procedimiento, resultado, limitaciones y nivel de confianza. Usa «observamos», «es compatible con» o «no pudimos corroborar» cuando corresponda. No reemplaces una laguna con una historia convincente.

6. Escalar por canales formales

Legal, cumplimiento, dirección, aseguradora, proveedor custodial o autoridad reciben lo que corresponda según el plan y la jurisdicción. La entidad decide si procede solicitar preservación, bloqueo o recuperación por los canales habilitados. El analista no inventa autoridad operativa a partir de su acceso técnico.

Control de falsa atribución y privacidad

Las direcciones son identificadores técnicos, no nombres civiles. CoinJoin, wallets de servicio, cambio UTXO, contratos, proxies, bridges, account abstraction y direcciones de depósito compartidas debilitan inferencias simples. Incluso una etiqueta correcta puede describir al proveedor que custodia la dirección, no al beneficiario económico.

Antes de asociar una identidad, documenta:

1. procedencia y fecha de cada fuente;
2. vínculo exacto entre la fuente off-chain y el identificador on-chain;
3. explicaciones alternativas examinadas;
4. confianza y evidencia que podría refutar la hipótesis;
5. necesidad, acceso, retención y destinatarios de los datos personales.

Una decisión con impacto —bloqueo, reporte, despido o comunicación pública— requiere revisión humana autorizada y evidencia proporcional. El grafo ayuda a preguntar; no dicta la sanción.

Práctica segura · El expediente de la transferencia imposible

Trabaja con el dataset ficticio de Aurora Custody, nunca con personas o fondos reales.

1. Selecciona una diferencia entre ledger, export de exchange y blockchain.
2. Fija el corte y crea un inventario de archivos con SHA-256.
3. Redacta por separado un hecho, un indicador, una inferencia y una hipótesis descartada.
4. Dibuja el flujo sin nombres personales y marca los saltos que no puedes demostrar.
5. Propón una acción de contención autorizada y una acción que quedaría fuera de alcance.
6. Entrega un hallazgo reproducible y un registro de decisiones.

Criterio de aprobación: otra persona reconstruye el resultado con las mismas fuentes; el texto no atribuye identidad o intención sin corroboración; declara límites y corte; y ninguna acción propuesta supone acceso, explotación, suplantación o movimiento de fondos sin autoridad.

Ejercicio de equipo · Detener, preservar, escalar

El instructor entrega tres tarjetas ficticias: una alerta on-chain, un export interno y un mensaje urgente de dirección que pide «recuperar ahora» los fondos. Cada participante asume un rol: operaciones de custodia, seguridad, cumplimiento/legal, auditoría interna o dirección de incidente.

1. Cada rol escribe qué sabe, qué supone y qué no está autorizado a hacer.
2. El equipo construye una línea de tiempo común y marca conflictos entre fuentes.
3. Antes de cualquier acción, completa la prueba de los cinco permisos.
4. Clasifica propuestas en permitida, requiere autorización o prohibida.
5. Redacta un parte de una página que proteja a clientes y preserve debido proceso.

Se reprueba si la rapidez justifica acceder a terceros, mover fondos, ocultar una pérdida o acusar a una persona. Se aprueba si el equipo sabe detenerse, conservar evidencia, contener dentro de sistemas propios y pedir una decisión a quien tiene autoridad.

Salidas profesionales: usar la capacidad para proteger

La madurez no se demuestra mostrando hasta dónde puedes entrar, sino sabiendo por qué, cuándo y ante quién debes detenerte.

Preguntas para comprobar criterio

1. ¿Qué diferencia hay entre controlar una clave y estar autorizado a usarla?
2. ¿Qué dato convertiría una etiqueta de wallet en una atribución más sólida? ¿Qué explicación alternativa seguiría abierta?
3. ¿Por qué una raíz Merkle correcta puede acompañar una representación engañosa?
4. ¿Qué cambia entre detectar una vulnerabilidad, demostrarla localmente y explotarla?
5. Si el ledger registra saldo cero pero la cadena muestra una salida, ¿qué preservas antes de corregir y quién autoriza el ajuste?
6. ¿Qué consecuencias humanas sufren clientes y compañeros cuando fallan custodia, gobierno o comunicación?

Una respuesta competente menciona autorización, evidencia, límites, afectados y canal de escalamiento; no se limita a describir tecnología.

Cómo se integra en las 66 clases

Esta guía no añade una clase 67. Es una lente transversal para seguridad y auditoría (19–20), cumplimiento (55–56), analítica y atribución (57–58) y custodia, conciliación, PoR y forensics (59–66). Vuelve a ella cuando una práctica pase de comprender un sistema a investigar conductas o proponer una respuesta.

Fuentes primarias y de referencia

• NIST SP 800-86 · Guide to Integrating Forensic Techniques into Incident Response — proceso de colección, examen, análisis y reporte; exige coordinar con responsables legales y de gestión.
• FATF/GAFI · Virtual Assets — enfoque basado en riesgo, diligencia debida, registros, reportes y Regla de Viaje.
• FATF/GAFI · Guidance for a Risk-Based Approach to Virtual Assets and VASPs — guía que debe leerse junto con sus actualizaciones posteriores.
• FATF/GAFI · Quick guide on assessing ML risks of virtual assets and VASPs — estructura para identificar, analizar y comprender riesgo sin automatizar conclusiones.
• Europol · The race against time — cooperación, capacidad y prevención frente al uso delictivo de activos digitales.
• FBI IC3 · 2024 Internet Crime Report — tipologías y datos de denuncias; una denuncia es una señal reportada, no una sentencia.
• Biblioteca del Congreso Nacional de Chile · Ley 21.459 — texto oficial de delitos informáticos; debe comprobarse su versión vigente y aplicación al caso.
• FATF/GAFI · Virtual Assets Red Flag Indicators — indicadores para análisis basado en riesgo; no son atribución automática.
• U.S. Department of Justice · sentencia en el caso FTX — comunicado oficial sobre condena y sentencia.
• Segundo Circuito · decisión en United States v. Bankman-Fried y Corte Suprema · expediente 26-349 — confirmación en apelación y petición posterior.
• U.S. Department of Justice · sentencia de Alexander Mashinsky — declaración de culpabilidad, hechos admitidos y sentencia.
• U.S. Department of Justice · expediente United States v. Kwon — declaración de culpabilidad y sentencia.
• U.S. Department of Justice · sentencia de Karl Sebastian Greenwood y FBI · Ruja Ignatova — estados procesales distintos.
• U.S. Department of Justice · caso Bitfinex — cronología y documentos oficiales del caso.
• U.S. Department of Justice · sentencia SafeMoon — comunicado oficial sobre fraude, lavado y sentencia.
• U.S. Department of Justice · sentencia GothFerrari — comunicado oficial sobre ingeniería social, robo de wallets y restitución.

Navegación

⬅️ Casos reales · Clase 58 · límites de atribución · Clase 65 · evidencia reproducible · Clase 66 · gobierno custodial