Principios de diseño
Diseñar software LegalTech es traducir un deber jurídico (proteger un derecho, dejar rastro, ser auditable) en una estructura técnica que resista el paso del tiempo y el cambio de personas. Los principios que siguen son independientes del lenguaje, del framework y del proveedor: funcionan en cualquier stack y son el primer filtro antes de escoger uno.
Separación de preocupaciones
Cada módulo debe hacer una sola cosa y hacerla bien. Si la descripción de lo que hace un módulo exige conjunciones, probablemente debe partirse en dos.
La separación de preocupaciones (Separation of Concerns) es el principio madre: aísla la interfaz del dominio, el dominio de la persistencia, la persistencia de la integración externa. Cada frontera que se traza hoy reduce el costo del cambio mañana.
En un producto LegalTech traducimos este principio a tres capas mínimas: la capa de interacción con el usuario (humano o sistema), la capa de reglas del negocio (donde vive el derecho codificado), y la capa de acceso a datos y servicios externos. Cada capa depende solo de la abstracción de la siguiente, nunca de su implementación concreta.
Principio
Prueba de la servilleta
Un arquitecto debe poder dibujar su sistema en una servilleta y explicarlo en dos minutos. Si necesita más, el sistema tiene demasiadas preocupaciones mezcladas.
SOLID como contrato de evolución
SOLID no es una moda; es un contrato con quien mantendrá el sistema cuando ya no estemos nosotros. En LegalTech, esa persona también es auditora.
DRY, KISS y YAGNI en clave pragmática
Tres reglas cortas que evitan el 80 % de los sobrecostos en LegalTech.
- DRY: si la regla de cálculo de un término procesal aparece en dos sitios, pronto aparecerán dos verdades contradictorias en el sistema. Centraliza la regla, cita la norma en el código y prueba una sola vez.
- KISS: la simplicidad es una decisión, no un accidente. Entre dos soluciones que cumplen, escoge la que un ingeniero nuevo entienda en media hora.
- YAGNI: no construyas mañana lo que el producto no necesita hoy. Cada capacidad especulativa es una superficie de ataque adicional, un costo de mantenimiento adicional y un riesgo de compliance adicional.
Error frecuente
Anti-patrón frecuente
Equipos que escriben un motor genérico para soportar 'cualquier norma futura' terminan con un DSL que nadie domina y que bloquea todo cambio real.
Diseño dirigido por el dominio jurídico
El lenguaje del código debe ser el lenguaje del abogado, no el lenguaje del framework.
En LegalTech, el dominio es el derecho. Usar nombres como 'Demanda', 'Prueba', 'Plazo de caducidad', 'Responsable de tratamiento' acerca al equipo jurídico al sistema y reduce la distancia entre el requerimiento y la implementación. Cuando el código habla en terminología jurídica, los abogados pueden revisarlo y los desarrolladores leen la norma con criterio.
Los límites (bounded contexts) del sistema deben corresponder a las fronteras reales del ejercicio jurídico: contratación, litigio, compliance, notificación. Mezclar contextos en un mismo módulo produce el mismo acoplamiento que mezclar áreas de práctica en un mismo memorial.
Arquitectura: capas, hexágonos y fronteras
Una arquitectura honesta separa lo que cambia a menudo de lo que casi nunca cambia, y protege el núcleo jurídico de los vaivenes tecnológicos. Dos estilos sirven especialmente bien al LegalTech: la arquitectura por capas y la hexagonal. No son religiones; son mapas de fronteras.
Arquitectura por capas
Tres fronteras básicas, cada una con una sola dirección de dependencia.
La regla inviolable: las capas superiores dependen de las inferiores, nunca al revés. El dominio (donde vive el derecho) no debe saber cómo se persiste ni cómo se envía un correo; expone contratos y la infraestructura los implementa.
Esta disciplina permite cambiar el motor de almacenamiento, el proveedor de notificaciones o la interfaz de usuario sin tocar la lógica jurídica. La norma permanece estable; la tecnología alrededor respira.
Hexagonal (puertos y adaptadores)
Cada interacción con el mundo exterior pasa por un puerto y un adaptador. Lo externo queda intercambiable; lo interno queda defendido.
La arquitectura hexagonal generaliza la idea anterior: el núcleo expone puertos (contratos) y delega en adaptadores (implementaciones). Así, un caso de uso 'validar identidad' declara el puerto VerificadorIdentidad y el sistema puede enchufar hoy un proveedor biométrico y mañana otro, sin reescribir el caso de uso.
El beneficio real se siente cuando cambia la regulación: si la SIC exige que la verificación deje trazabilidad adicional, se modifica el adaptador, no el núcleo. El derecho codificado permanece idéntico, solo cambia quién cumple el contrato.
Principio
Regla del contrato
Todo servicio externo entra y sale por un puerto nombrado en lenguaje jurídico. Si el nombre del puerto se parece al nombre del proveedor, el núcleo ya perdió independencia.
Monolito, modular o servicios: una decisión informada
No hay una respuesta universal. Hay un marco para escogerla con argumentos.
Atención
Cuidado con la moda
Empezar con microservicios 'porque escalan' antes de tener usuarios es una de las trampas más frecuentes. Es preferible un monolito bien modulado que una red de servicios mal gobernada.
Conectividad e integración
Un sistema LegalTech rara vez vive solo: habla con entidades públicas, proveedores de identidad, centrales de información, firma digital, canales de notificación y motores analíticos. La disciplina de cómo se conectan esas piezas define si el sistema es frágil o resiliente.
Contratos primero, implementación después
Antes de escribir código, se escribe el contrato. El contrato es la promesa jurídica del sistema hacia quien lo consume.
Toda integración —interna o externa— debe empezar por un contrato explícito: entradas, salidas, errores, códigos de estado, políticas de reintento, límites de uso. Este contrato se versiona, se documenta y se firma entre equipos antes de que la primera línea de código se escriba.
En LegalTech, el contrato técnico refleja obligaciones reales. Un endpoint que expone información personal cita la base legal del tratamiento en su documentación; un endpoint que valida una firma cita la Ley 527 y Decretos 2364/2012 y 333/2014. La documentación técnica es, a la vez, evidencia de cumplimiento.
Idempotencia y reintentos
En un entorno jurídico, repetir un mensaje nunca debe duplicar un efecto legal.
- Cada operación que modifica estado declara un identificador único de petición. Procesar dos veces la misma petición produce el mismo resultado, nunca dos.
- Los errores transitorios (red, picos de carga) se reintentan con política de retroceso exponencial y límite máximo; los errores lógicos (autorización insuficiente, dato inválido) no se reintentan.
- Las respuestas de servicios externos se registran con su identificador correlacionable para poder reconstruir la línea de tiempo de una transacción ante una auditoría.
Buena práctica
Regla práctica
Si la operación es 'notificar la audiencia', reintentarla dos veces no debe producir dos notificaciones. La idempotencia es la diferencia entre un sistema serio y uno peligroso.
Sincronía vs. asincronía
No toda integración necesita respuesta inmediata. Saber cuándo elegir cola y cuándo elegir llamada directa define la estabilidad del sistema.
La comunicación sincrónica (petición-respuesta) encaja cuando el usuario espera al otro lado de la pantalla y la latencia debe ser baja. Es frágil porque acopla la disponibilidad del llamador a la del llamado.
La comunicación asincrónica (colas, eventos, pub/sub conceptual) encaja cuando el proceso tolera espera y se beneficia de desacoplamiento: notificaciones, reprocesos, auditoría, generación de reportes. Añade complejidad operativa pero aísla fallas.
Un sistema LegalTech maduro combina ambas: lo que el usuario ve en tiempo real va por canal sincrónico; lo que el sistema procesa en segundo plano va por canal asincrónico con garantías de entrega y orden explícitas.
Volumen, concurrencia y capacidad
Diseñar para cien usuarios no es lo mismo que diseñar para cien mil. La escala no se improvisa; se anticipa con cifras honestas y se entrega con pruebas.
Modelo de capacidad
Antes del primer despliegue, el equipo responde por escrito: ¿cuántos usuarios activos?, ¿qué pico?, ¿qué tiempo de respuesta toleramos?
El modelo de capacidad se construye con tres cifras mínimas: usuarios concurrentes estimados, peticiones por segundo esperadas y percentiles de latencia aceptables. Sin estos tres números, cualquier decisión de infraestructura es adivinanza.
Estas cifras se validan con pruebas de carga sintéticas antes de producción y se vigilan con métricas reales en producción. La diferencia entre lo estimado y lo observado es información para la siguiente iteración del diseño.
Escalado vertical vs. horizontal
Dos estrategias complementarias, no rivales.
Componentes sin estado
Un componente sin estado puede apagarse y nacer en otra parte sin pérdida. Es la condición para escalar en horizontal con tranquilidad.
El estado se concentra en capas dedicadas: base de datos, caché explícito, almacenamiento de sesiones. Las capas de aplicación son sin estado por diseño.
Eso impone una regla fuerte: nada se guarda 'en memoria del proceso' con la ilusión de persistirlo. Si la información debe sobrevivir al reinicio, vive en una capa persistente con contrato explícito de durabilidad.
Caché disciplinado
El caché es una optimización poderosa y peligrosa. Sin disciplina, se convierte en la principal fuente de inconsistencias jurídicas.
- Se cachea lo que es costoso y estable. Reglas, tablas normativas y metadatos se prestan al caché; decisiones en curso y datos financieros del cliente, rara vez.
- Todo valor en caché lleva política de invalidación escrita. Si no se sabe cuándo expirar un dato, no debe estar en caché.
- En materia de datos personales, el caché es una copia: está sujeto al mismo régimen de protección (Ley 1581) que el dato original. Olvidarlo es fuente habitual de incumplimiento.
Tránsito de información
Cada dato que viaja por el sistema cruza fronteras —entre capas, entre procesos, entre organizaciones—. Cómo viaja, con qué garantías y con qué huella, define la seguridad y la auditabilidad del producto.
Cifrado en tránsito y en reposo
Dos cifrados distintos para dos momentos distintos del dato.
El cifrado en tránsito protege la información mientras se mueve entre componentes y entre organizaciones. Se implementa con protocolos modernos (capa de transporte segura estándar), configuraciones conservadoras de cifrado y rotación regular de certificados.
El cifrado en reposo protege la información almacenada. Aplica a bases de datos, copias de seguridad, colas de mensajes persistentes, volúmenes de archivo y caché duradero. Las claves se gestionan fuera del sistema protegido y su acceso queda registrado.
Para datos sensibles (Ley 1581 art. 5) y datos financieros (Ley 1266), ambos cifrados son el mínimo, no la aspiración. Operar sin ellos es operar en infracción.
Serialización segura
El formato en que viaja un dato importa tanto como el dato mismo.
- Usar formatos de serialización autodescriptivos y estrictos. Se valida cada campo que entra y se escapa cada campo que sale.
- Nunca deserializar datos no confiables con formatos que ejecutan código implícito. Es una de las vías más antiguas y vigentes de comprometer un sistema.
- La información mínima necesaria viaja en el mensaje; el resto se referencia por identificador para minimizar exposición.
Minimización en el viaje
El dato que no viaja no se pierde, no se filtra, no se expone.
Antes de enviar, se pregunta: ¿necesita el destinatario este dato? ¿Puede reemplazarse por un identificador? ¿Puede agregarse? ¿Puede anonimizarse? Aplicar esta disciplina reduce la superficie de ataque y honra el principio de minimización de la Ley 1581.
Un ejemplo cotidiano: enviar 'el usuario con cédula X tiene edad Y' es más invasivo que enviar 'el usuario con identificador interno 123 es mayor de edad'. Cuando el destinatario solo necesita el booleano, la cédula no tiene por qué salir.
Buena práctica
Regla del dato mínimo
Si la función puede cumplirse con menos datos, usar menos datos. La norma no lo exige con esa literalidad; la auditoría sí lo espera con esa severidad.
Trazabilidad del tránsito
Cada movimiento importante del dato deja un registro inmutable y correlacionable.
Un sistema LegalTech serio mantiene una bitácora inmutable de los eventos significativos: alta de datos, cambio de finalidad, acceso por terceros, entrega a un encargado, supresión. La bitácora es la cadena de custodia interna del producto.
Esa bitácora no guarda el dato sensible, solo el hecho y su contexto (quién, cuándo, qué operación, bajo qué autorización). Es la pieza que permite responder en 10 días hábiles una petición de habeas data sin improvisar.
Prevención de vulnerabilidades por planificación
La seguridad no se añade al final; se planea al inicio. Un producto LegalTech que llega a auditoría con su modelo de amenazas documentado y sus controles probados se defiende solo. Uno que llega con 'pero lo desplegamos seguro' no se defiende en lo absoluto.
Modelado de amenazas
Antes de escribir un módulo sensible, se responde por escrito: ¿qué se defiende?, ¿de quién?, ¿cómo?
El modelado de amenazas es un ritual sencillo: se dibuja el diagrama de flujo del dato, se identifican las fronteras de confianza, se anotan las amenazas en cada frontera (suplantación, alteración, repudio, divulgación, denegación, elevación de privilegio), y se decide qué control las mitiga.
El resultado cabe en dos páginas por dominio. Se actualiza cuando cambia el diseño. Es la primera pregunta que una auditoría bien llevada hace al equipo técnico.
Principio
Regla del adversario nombrado
Un modelo de amenazas sin adversario es una meditación. El adversario debe ser concreto: un usuario interno curioso, un atacante oportunista, un actor organizado, un sujeto con acceso físico.
Reducción de la superficie de ataque
Todo lo que se expone puede ser atacado. Lo que no existe no se puede comprometer.
- Exponer solo las operaciones que el producto realmente necesita. Cada endpoint adicional es una puerta más que mantener cerrada.
- Cerrar por defecto y abrir por excepción: ni puertos, ni servicios, ni permisos, ni rutas deben estar activas 'por si acaso'.
- Eliminar módulos y dependencias que ya no se usan. El código muerto es, a menudo, el vector de ataque vivo.
Las diez fallas clásicas (conceptualmente)
La lista canónica de fallas en aplicaciones web se lee como una checklist de prevención.
Plan de respuesta a incidentes
El mejor sistema preparado para no fallar tiene, de todas formas, un plan escrito para cuando falle.
El plan define: quién detecta, quién decide, quién contiene, quién comunica, quién remedia y quién aprende. Se escribe antes del incidente, se ensaya en simulacro y se actualiza cuando cambia el sistema.
Para productos LegalTech bajo la Ley 1581, el plan incluye la obligación de reportar a la SIC los incidentes que afectan datos personales y, cuando haya riesgo alto para el titular, la notificación directa al titular. El plazo y la evidencia de esta notificación son parte del expediente de cumplimiento.
Integridad y auditabilidad
La integridad es la garantía de que un dato no ha sido alterado silenciosamente. En un producto LegalTech, la integridad no es confort: es la diferencia entre una prueba válida y un proceso caído por falta de cadena de custodia.
Huellas digitales y firmas
Hashes y firmas son dos herramientas conceptuales para dos preguntas distintas: ¿este dato cambió?, ¿este dato lo firmó quien dice?
Una huella digital (hash) de un documento detecta cualquier cambio posterior: un byte modificado produce una huella completamente distinta. La huella se calcula al momento de recibir o producir el documento, se registra junto al documento y se vuelve a verificar cada vez que el documento se presenta.
Una firma digital añade identidad: vincula el documento a un firmante con un certificado emitido por una autoridad reconocida. En Colombia, los Decretos 2364/2012 y 333/2014 definen los requisitos. Para un producto LegalTech, distinguir firma electrónica de firma digital es una decisión de diseño, no de marketing.
Norma aplicable
Ley 527/1999 y reglamentación
La equivalencia funcional exige que el soporte técnico de la firma sea consistente con el propósito probatorio pretendido. El sistema debe poder explicar ante un juez qué mecanismo usó y por qué es suficiente para el acto jurídico en cuestión.
Bitácora inmutable
Un registro que puede editarse no es un registro; es un borrador con pretensiones.
Los eventos críticos (autorizaciones, accesos, decisiones automatizadas, entregas, supresiones) se registran en una bitácora append-only: los eventos se agregan pero no se modifican. Cuando se descubre un error, se añade un evento correctivo; no se reescribe el pasado.
La bitácora usa identificadores correlacionables entre capas. Ante una investigación, el equipo debe poder reconstruir la línea de tiempo de un caso en minutos, no en días.
Reproducibilidad de decisiones
Una decisión que no se puede reproducir no se puede defender.
Toda decisión automatizada que afecta a una persona debe poder reproducirse: los mismos datos, la misma versión del modelo o reglas, el mismo resultado. Esto exige versionar las reglas, versionar los modelos, registrar qué versión se usó en cada decisión y conservar el contexto por el tiempo que imponga la norma aplicable.
Bajo la Circular SIC 002/2024, un titular puede pedir explicación de la decisión que lo afectó. La reproducibilidad es la base técnica de esa explicación.
Privacidad por diseño
La privacidad por diseño (privacy by design) no es un eslogan: es un conjunto de decisiones concretas que se toman en la hoja en blanco, no en la hoja firmada. Un producto LegalTech que incorpora estas decisiones puede escalar sin multiplicar su deuda de cumplimiento.
Minimización de datos
Recolectar solo lo necesario. Conservar solo lo indispensable. Compartir solo lo proporcional.
El principio de minimización del art. 4 de la Ley 1581 se traduce a tres decisiones concretas: el formulario pide lo mínimo, la base guarda lo mínimo, el integrador comparte lo mínimo. Cada campo adicional debe justificar su existencia con una finalidad escrita.
En la práctica, el equipo revisa cada campo al menos una vez al año y pregunta: ¿sigue siendo necesario? ¿hay una finalidad vigente? ¿podríamos cumplir sin él? Los campos que no superan este examen se retiran.
Finalidad y consentimiento granulares
Un consentimiento genérico no es consentimiento; es un trámite disfrazado.
- Cada finalidad del tratamiento se describe por separado, en lenguaje claro, y se solicita autorización específica para cada una.
- El consentimiento es revocable por el mismo canal por el que se otorgó y con la misma facilidad. La asimetría entre 'aceptar' y 'revocar' es un patrón oscuro y una infracción probable.
- La prueba del consentimiento se conserva con contexto: versión del aviso vigente al momento, marca de tiempo, canal, finalidades aceptadas y rechazadas.
Seudonimización y anonimización
Dos técnicas distintas, con efectos legales distintos.
Error frecuente
Trampa común
Llamar 'anónimo' a lo que es solo seudonimizado es una de las fuentes más comunes de sanción. La diferencia no es técnica: es jurídica. Con duda, se asume seudonimización y se mantiene el régimen.
Retención y supresión
Conservar para siempre no es seguridad: es riesgo acumulado.
Cada categoría de dato tiene un plazo de retención escrito, justificado en la finalidad o en una obligación legal. Cumplido el plazo, el dato se suprime o se anonimiza. La decisión se ejecuta de forma automática y se registra en la bitácora.
Bajo la Ley 1266, el dato negativo financiero tiene plazos de caducidad específicos contados desde el pago. Un LegalTech que conserva indefinidamente 'por si acaso' infringe la ley y alimenta demandas.
Transferencias y transmisiones
Dos figuras jurídicas con contratos distintos.
La transferencia envía datos a un tercero que los tratará por cuenta propia; exige autorización del titular y, si es internacional, cumplir requisitos adicionales (nivel adecuado de protección o cláusulas específicas).
La transmisión delega el tratamiento a un encargado que actúa por cuenta del responsable; exige contrato de transmisión con obligaciones equivalentes (Decreto 1377 art. 25). Toda integración con un proveedor que procese datos pasa por este contrato firmado antes de intercambiar el primer dato.
Seguridad operativa
La seguridad operativa es la parte aburrida y definitoria: lo que se hace todos los días para que el sistema amanezca igual de seguro que se acostó.
Principio de menor privilegio
Cada identidad (humana o de máquina) recibe solo los permisos que necesita para cumplir su rol. Ni uno más.
El menor privilegio se aplica a usuarios del sistema, a procesos, a servicios y a integraciones. Los permisos se otorgan por rol, se revisan periódicamente y se revocan cuando cambia la función. El ex-empleado que mantiene acceso 'por si vuelve' es un incidente en espera.
Se evita el uso de identidades compartidas. Si una cuenta la usan cinco personas, la trazabilidad se convierte en ficción. Cada persona con acceso es una identidad con nombre, y cada acceso queda asociado a esa identidad.
Defensa en profundidad
Ningún control es infalible. Se construyen varias capas para que, cuando una falle, otra sostenga.
La defensa en profundidad combina controles preventivos (autenticación, autorización, cifrado), controles de detección (monitoreo, alertas, bitácoras) y controles de respuesta (contención, remediación, comunicación). La pérdida de uno no compromete al conjunto.
Esta filosofía se opone a la 'seguridad perimetral' que confía todo a un único punto fuerte. Los puntos fuertes caen. Las capas se apoyan entre sí.
Gestión de secretos
Contraseñas, llaves y certificados nunca viven en el código. Viven en un almacén dedicado con trazabilidad de acceso.
- Los secretos se leen en tiempo de ejecución desde un almacén seguro y con acceso auditable. Si aparecen en un repositorio de código, se consideran comprometidos y se rotan.
- Los secretos tienen fecha de rotación. Cada 90 días, como mínimo; con política más estricta para secretos con mayor alcance.
- El acceso a secretos queda registrado. Si nadie puede decir quién leyó qué clave y cuándo, se perdió el control.
Observabilidad y alertas
Un sistema que no se ve, no se defiende.
Tres dimensiones conforman la observabilidad: métricas (cuánto y qué tan rápido), registros (qué ocurrió) y trazas (cómo fluyó la petición entre capas). Las tres se combinan para diagnosticar en minutos lo que, sin ellas, tomaría días.
Las alertas se configuran sobre síntomas de usuario (latencia, errores visibles), no solo sobre síntomas de sistema (CPU, memoria). Despertar a alguien a las 3 a.m. por una CPU alta que no afecta a nadie es erosionar la confianza del equipo.
Respaldos y continuidad
Un respaldo no probado no existe. Se prueba restaurándolo.
Los respaldos son regulares, cifrados, separados del sistema primario y probados con un ejercicio periódico de restauración completa. El tiempo de recuperación objetivo y el punto de recuperación objetivo se declaran por sistema y se miden contra la realidad.
El plan de continuidad contempla escenarios concretos: pérdida de una región de infraestructura, pérdida de un proveedor externo crítico, compromiso interno. Para cada escenario hay un procedimiento ensayado.
Planificación y ciclo de vida
Las decisiones que cuestan más caro en LegalTech rara vez se toman por accidente técnico: se toman por descuido de planificación. Planear no ralentiza; protege.
Requerimientos funcionales y no funcionales
Los requerimientos no funcionales (seguridad, privacidad, desempeño, auditabilidad) tienen la misma dignidad que los funcionales.
Cada historia de usuario viene acompañada de sus requerimientos no funcionales: tiempo de respuesta aceptable, datos que se recolectan, base legal del tratamiento, obligaciones de registro, perfil que puede acceder. Sin eso, el requerimiento funcional queda incompleto.
Los criterios de aceptación incluyen, para operaciones sensibles, evidencia de cumplimiento: la cita a la norma, el tipo de autorización requerida, el evento de bitácora que se dispara. La auditoría futura se alimenta de lo que se escribió en estas tarjetas.
Pruebas automáticas
La prueba automática es la única promesa creíble de que el comportamiento de ayer sigue vigente hoy.
- Pruebas unitarias sobre reglas jurídicas críticas (cálculos, plazos, prescripciones). Un cambio que rompe una prueba bloquea el despliegue.
- Pruebas de integración sobre los contratos con servicios externos. Cuando un proveedor cambia su contrato, se detecta en pruebas, no en producción.
- Pruebas de seguridad automatizadas sobre las dependencias y la configuración. Las amenazas conocidas se cazan por hábito, no por heroísmo.
Revisión de código y pares
Dos ojos ven lo que uno no quiere ver.
Todo cambio relevante pasa por revisión de al menos una persona distinta al autor. La revisión no busca elegancia, busca entendibilidad, corrección y riesgo. En módulos con impacto jurídico, la revisión incluye una mirada del área legal o de cumplimiento.
La cultura de revisión sana premia las preguntas sobre las correcciones. La pregunta 'por qué así y no de otra forma' vale más que la corrección cosmética.
Despliegue y reversibilidad
Un despliegue que no se puede revertir es un salto al vacío.
Se prefiere desplegar en pequeños incrementos, con la posibilidad de activar y desactivar capacidades con banderas. La reversibilidad no es un lujo: es la condición para moverse rápido con seguridad.
Los cambios en el esquema de datos se hacen en pasos compatibles hacia atrás. Un cambio de esquema incompatible con la versión anterior exige una ventana de convivencia y un plan de migración verificado antes del despliegue final.
Tip
Regla del botón rojo
Antes de desplegar, el equipo responde: si algo sale mal, ¿en cuánto tiempo podemos volver al estado anterior y quién aprieta el botón? Si no hay respuesta clara, el despliegue se aplaza.
Mantenimiento y deuda técnica
La deuda técnica es como la procesal: si no se atiende en tiempo, prescribe contra el equipo.
Se reserva una porción honesta del tiempo de cada ciclo al mantenimiento: actualización de dependencias, limpieza de código muerto, mejora de pruebas, refactorización guiada. El equipo que corre solo detrás de requerimientos nuevos termina atrapado por su propio sistema.
La deuda técnica se hace visible: se registra, se prioriza y se paga. Un backlog de deuda sin dueño es un boleto a la crisis.
Cumplimiento y auditoría
El cumplimiento no es un anexo al manual: es el criterio último de calidad en LegalTech. Todo lo anterior se ordena para que el sistema pueda ser explicado y defendido cuando la SIC, un juez o un cliente lo pidan.
Expediente de cumplimiento
Seis documentos que siempre deben estar vivos, fechados y firmados.
- Aviso de privacidad y política de tratamiento vigentes y publicados.
- Registro de bases de datos ante la SIC cuando corresponda.
- Contratos de transmisión o transferencia con cada encargado.
- Modelo de amenazas por dominio, actualizado al último cambio de diseño.
- Plan de respuesta a incidentes con responsables y canales definidos.
- Bitácora de auditoría con trazabilidad de accesos, decisiones y eventos significativos.
Revisión periódica
El cumplimiento no es un estado: es una disciplina.
Al menos una vez al año el equipo somete el producto a una revisión integral: brecha frente a la Ley 1581, el Decreto 1377 y la Circular SIC 002/2024; verificación de los plazos de respuesta; pruebas de restauración de respaldos; ejercicio de incidente; revisión de dependencias y secretos.
La revisión produce un plan de remediación con responsables y plazos. Sin plan de remediación, la revisión es teatro.
Defensa argumentada del diseño
El equipo debe poder defender cada decisión técnica con una razón jurídica o de riesgo, no con 'lo hicimos así porque sí'.
En una auditoría seria, la pregunta habitual no es '¿está cifrado?' sino '¿por qué eligieron este esquema y no otro?'. La respuesta del equipo revela si hay pensamiento o improvisación detrás del sistema.
El manual, el modelo de amenazas, el expediente y la bitácora se convierten, juntos, en la narrativa del sistema. Esa narrativa es la que gana o pierde la auditoría.
Principio
Criterio último
Un sistema LegalTech bien construido se puede explicar en voz alta, se puede auditar en silencio, y se puede defender ante un juez con los papeles en la mano.
Cierre
La ingeniería de software LegalTech no se define por el stack elegido: se define por la disciplina con la que se honran los principios. Un equipo que entiende separación de preocupaciones, privacidad por diseño, integridad verificable y defensa en profundidad puede construir en cualquier tecnología. Uno que ignora estos principios fallará con cualquiera.
Continúa con el otro manual
Manual de ejercicio legal en LegalTech
Cómo ejercer la abogacía cuando la tecnología es el medio
Material de apoyo educativo. No constituye asesoría legal. Consulte con un profesional habilitado para decisiones jurídicas. Normativa vigente al 01/03/2026.