El libro de Robert Taylor, Legal Engineering: Building AI-Powered Legal Workflows with Multi-Agent Architectures, es la primera guía completa sobre una disciplina que se sitúa en la intersección de la práctica legal, la ingeniería de software y el diseño de sistemas de IA. Este artículo resume el alcance completo del libro — los dieciséis capítulos más la introducción y la conclusión — con foco en el concepto central: la ingeniería legal.
La ingeniería legal no es ingeniería de prompts. Tampoco es tecnología legal en el sentido tradicional. Es la práctica de diseñar, construir e implementar flujos de trabajo impulsados por IA que automatizan el trabajo legal usando arquitecturas de pipeline multiagente. Este resumen cubre los patrones fundacionales, los principios arquitectónicos y los diez flujos de trabajo aplicados que hacen esa definición concreta.
Qué es la ingeniería legal y por qué importa
La ingeniería legal se sitúa en la intersección de tres dominios. La práctica legal aporta el conocimiento sustantivo de lo que es un trabajo legal correcto: las reglas doctrinales, las obligaciones profesionales, las restricciones regulatorias y el juicio práctico que separa el análisis competente de la mala praxis. La ingeniería de software aporta la disciplina de construir sistemas confiables, mantenibles y de calidad de producción: seguridad de tipos, manejo de errores, pruebas, despliegue y monitoreo operativo. El diseño de sistemas de IA aporta los patrones arquitectónicos que hacen que los modelos de lenguaje de gran escala sean útiles a escala: descomposición de prompts, orquestación multiagente, ejecución paralela y síntesis de resultados.
Un ingeniero de prompts optimiza un mensaje para un modelo. Un ingeniero legal diseña un sistema de veinte o treinta llamadas de IA coordinadas, cada una con un rol especializado, orquestadas a través de múltiples rondas secuenciales, produciendo un entregable que cumple con el estándar de cuidado exigido para el trabajo legal.
La característica definitoria de la ingeniería legal es tratar la lógica legal y la lógica computacional como la misma estructura formal expresada en sintaxis diferente. Una fecha en un contrato y un objeto Date en TypeScript son la misma cosa. Una cláusula condicional y una instrucción if son la misma cosa. Una lista de obligaciones y un array de strings son la misma cosa. Esto no es una analogía. Es un isomorfismo estructural, y es lo que hace posible toda la disciplina.
El libro está dirigido a cuatro audiencias: abogados que quieren construir sistemas de IA (no solo consultar chatbots), ingenieros de software que ingresan a la vertical legal, profesionales de operaciones legales que evalúan herramientas de IA, y estudiantes que persiguen carreras en la intersección del derecho y la tecnología.
Parte I: Fundamentos
Capítulo 1: Fundamentos tecnológicos
El primer capítulo establece la pila tecnológica que sustenta todo pipeline de ingeniería legal: TypeScript para desarrollo con seguridad de tipos, la API de Claude de Anthropic para inferencia de IA, OOXML para manipulación de documentos, Express para infraestructura de servidor, y React para interfaces de usuario. Cada tecnología cumple un rol específico en la arquitectura.
TypeScript es el lenguaje de programación del ingeniero legal porque la seguridad de tipos detecta errores antes de que lleguen a los clientes. Un sistema de análisis de contratos que falla porque alguien pasó un string donde se esperaba un número no es un inconveniente menor: es un riesgo de mala praxis. La API de Claude provee la capa de inferencia, soportando respuestas en streaming y ventanas de contexto extendidas necesarias para analizar contratos de cincuenta páginas. OOXML es el formato de documento que permite a los sistemas de ingeniería legal producir Track Changes reales en Microsoft Word — no comentarios, no resaltados, sino cambios rastreados reales indistinguibles del trabajo de un abogado humano.
Capítulo 2: TIRO — el patrón universal de descomposición
TIRO (Trigger, Input, Requirements, Output — Disparador, Entrada, Requisitos, Salida) es el patrón fundacional de la ingeniería legal. Cada cláusula legal, cada disposición regulatoria, cada flujo de cumplimiento y cada etapa de un pipeline de IA sigue esta estructura de cuatro fases. Un estudiante de derecho de primer año lee una cláusula de indemnización y ve prosa impenetrable. Un ingeniero legal lee la misma cláusula y ve una función: tiene un disparador (incumplimiento de una declaración), entradas (la parte incumplidora, el monto de los daños, el tope), requisitos que procesan esas entradas, y una salida (la parte indemnizada recibe el pago).
La fase de Requisitos se descompone en cuatro subcomponentes: Arbitraje (resolver conflictos entre prioridades en competencia), Definiciones (establecer el significado de los términos), Validaciones (imponer restricciones sobre los datos), y Transformaciones (convertir entradas en salidas). Juntos, estos cuatro subcomponentes capturan cualquier operación posible que una cláusula legal o una etapa de un pipeline de IA pueda realizar.
La cláusula de indemnización y la función de TypeScript que la modela contienen los mismos disparadores, aceptan las mismas entradas, imponen las mismas restricciones, realizan las mismas transformaciones y producen las mismas salidas. La única diferencia es la notación.
TIRO no es un marco impuesto sobre las operaciones legales. Es una descripción formal de la estructura que las operaciones legales ya tienen y siempre han tenido. Cada cláusula contractual es una función. No metafóricamente. No de forma laxa. Estructural, formal y completamente. Este isomorfismo es lo que hace posible la ingeniería legal: los documentos legales son datos estructurados escritos en lenguaje natural, y los sistemas de IA pueden analizar esa estructura porque la lógica subyacente es idéntica a la lógica que los sistemas de software ya procesan.
Capítulo 3: Pipelines multipasada
Este capítulo aborda la decisión arquitectónica fundamental en la IA legal: pasada única versus multipasada. Imagina entregarle a un asociado junior un acuerdo SaaS de cincuenta páginas y decirle: léelo, identifica cada riesgo, sugiere correcciones, redacta el lenguaje de reemplazo, formatea tu análisis como un informe estructurado, y redacta un correo de negociación. Tienes una sola pasada. Sin notas, sin esquema, sin revisión. Ningún abogado competente trabajaría así. Sin embargo, así es exactamente como la mayoría de las organizaciones usan la IA.
Los resultados son medibles. En un experimento controlado, el mismo modelo Claude analizando el mismo contrato de M&A de 42,274 palabras produjo 35 cambios rastreados con cero citas legales en una sola pasada. El mismo modelo envuelto en un pipeline de 26 agentes y 6 rondas produjo 138 cambios rastreados con 18 citas legales. Una mejora de 3.9x sin ningún cambio en la capacidad del modelo. La arquitectura fue la única variable.
La pasada única falla de cuatro maneras predecibles: dilución de atención (las cláusulas críticas compiten con el texto estándar por peso de procesamiento), falta de especialización (un solo prompt intenta ser analista de riesgos, redactor legal, estratega de negociación y formateador de documentos a la vez), falta de autocorrección (una definición mal interpretada se propaga silenciosamente por todo el análisis), y falta de auditabilidad (no puedes identificar qué paso produjo una salida defectuosa).
El libro introduce dos patrones fundacionales para resolver esto. El Diplomat es una arquitectura emparejada de prompter-ejecutor: un agente genera el prompt, otro lo ejecuta. Esta separación crea interfaces tipadas y auditables entre etapas. El Backautocrat es el orquestador que encadena múltiples etapas Diplomat en un pipeline completo, gestionando las transiciones de estado, la recuperación de errores y la recolección de métricas a través de todas las rondas.
Capítulo 4: Paralelización
Un acuerdo SaaS típico tiene al menos dieciséis áreas distintas de interés: propiedad intelectual, términos de pago, garantías de SLA, topes de responsabilidad, indemnización, derechos de terminación, protección de datos, y más. Si ejecutas dieciséis analizadores secuencialmente a treinta segundos cada uno, el usuario espera ocho minutos. Ejecútalos en paralelo y el usuario espera treinta segundos. Mismo costo de cómputo. Mismo uso de tokens. Lo único que cambió fue la arquitectura.
El libro enseña la arquitectura fan-out/fan-in: despachar docenas de agentes de IA especializados simultáneamente, recolectar sus resultados a medida que terminan, y agregar todo en un análisis único y coherente. Los sistemas de producción despliegan más de 158 analizadores paralelos contra un solo contrato usando Promise.allSettled() para una ejecución tolerante a fallos. Una idea crítica: los fragmentos paralelos sin síntesis son peores que una sola pasada coherente. Un agente sintetizador obligatorio debe resolver contradicciones y producir un entregable unificado.
Capítulo 5: Integración
Un pipeline de IA que se ejecuta en una terminal e imprime resultados en la consola no es un producto. La integración es la disciplina de ingeniería que conecta un pipeline de IA con cada sistema que debe tocar: un dashboard de React para cargas, un backend de Express para la orquestación, una base de datos para la persistencia, almacenamiento en la nube para los documentos, y un sistema de entrega que produce documentos de Microsoft Word con Track Changes visibles.
El capítulo cubre la cirugía de Track Changes en OOXML (el formato que hace que las líneas rojas generadas por IA sean indistinguibles del trabajo de un abogado humano), Server-Sent Events para el streaming de progreso en tiempo real, el diseño de API para los endpoints del pipeline, y los patrones de despliegue. La idea clave es que la precisión de OOXML importa tanto como la precisión analítica: un análisis legal brillante entregado en el formato equivocado es inútil en la práctica.
Capítulo 6: Privilegio y seguridad
Este capítulo es donde la ingeniería de software cruza la línea hacia la ingeniería legal. Los conceptos aquí no tienen análogo en una base de código SaaS típica. Provienen de siglos de jurisprudencia, reglas de responsabilidad profesional y marcos regulatorios. Y no son opcionales.
Cuando un despacho de abogados envía un acuerdo de adquisición de M&A privilegiado a través de una herramienta SaaS de terceros que procesa los datos en sus propios servidores, con sus propias claves de API, bajo sus propios términos de servicio, ¿se ha renunciado al privilegio? La respuesta depende de la arquitectura. El libro hace referencia a Mata v. Avianca (S.D.N.Y. 2023), donde abogados fueron sancionados por escritos generados por IA con citas fabricadas. Pero las preguntas sobre el privilegio son mucho más consecuentes.
Un pipeline de redacción de contratos que viola el privilegio abogado-cliente es peor que inútil. Es una responsabilidad de mala praxis esperando salir a la luz en el descubrimiento probatorio. Los riesgos no son teóricos.
La ingeniería legal requiere clasificación de datos (categorizar cada pieza de información según su estatus de privilegio y sensibilidad), propiedad de la infraestructura (el despacho debe controlar dónde se procesan los datos), controles de acceso (aislamiento basado en roles y en casos) y registros de auditoría que satisfagan tanto los requisitos regulatorios como las posibles retenciones de litigio.
Parte II: Flujos de trabajo aplicados
La Parte II aplica los patrones fundacionales a diez flujos de trabajo legales distintos. Cada capítulo sigue la misma estructura: definir el flujo de trabajo, descomponerlo usando TIRO, diseñar la arquitectura del pipeline, implementarlo, y evaluar los resultados frente a los estándares profesionales. Lo que emerge es una demostración de que una sola arquitectura se generaliza a través de toda la práctica del derecho.
Capítulo 7: Redacción de contratos
La redacción de contratos es el punto de partida más natural para la ingeniería legal aplicada porque las entradas y salidas son concretas. La entrada es un playbook del cliente: una expresión estructurada de lo que el cliente quiere, lo que aceptará y lo que no tolerará. La salida es un acuerdo completo y exigible que se lee como si lo hubiera redactado un socio senior.
Entre esos dos extremos hay un pipeline de seis etapas: clasificar el trato, generar una hoja de términos, redactar cláusulas individuales (usando redactores especialistas paralelos para cada sección), resolver referencias cruzadas, ensamblar el documento y revisar el producto final. Cada etapa es un Diplomat. Cada transición es una interfaz tipada. El Backautocrat orquesta todo el flujo y captura métricas en cada paso.
Capítulo 8: Revisión de líneas rojas de contratos — la aplicación de IA de mayor valor
La revisión de líneas rojas de contratos destaca como la aplicación de mayor valor de la inteligencia artificial en la práctica legal. La economía es contundente: una revisión de líneas rojas a nivel de socio de un acuerdo SaaS de cincuenta páginas toma entre ocho y doce horas de tiempo enfocado de un abogado. A las tarifas de BigLaw de $800 a $1,500 por hora, eso son entre $6,400 y $18,000 por contrato. Un pipeline de revisión de líneas rojas impulsado por IA produce el mismo entregable en treinta minutos.
No una aproximación de líneas rojas. No comentarios resaltados. Cambios rastreados reales incrustados en la estructura XML del contrato, indistinguibles de los cambios que haría un abogado humano en Microsoft Word. El pipeline de líneas rojas usa análisis adversarial: la IA lee el contrato como si representara al oponente de la contraparte, identifica cada cláusula que favorece al otro lado, cuantifica el riesgo, y genera lenguaje de reemplazo con autoridad legal de respaldo.
Capítulo 9: Analítica de contratos
Un director jurídico con 500 contratos activos enfrenta una pregunta de la junta directiva: ¿cuál es nuestra exposición total de indemnización a través del portafolio de proveedores? En la mayoría de los departamentos legales, esa pregunta desencadena semanas de trabajo. Los asociados abren los contratos uno por uno, escriben números en una hoja de cálculo, y eventualmente producen un rango tan amplio que carece de sentido funcional.
El cambio fundamental: un contrato no es un documento para leer. Es una base de datos para consultar. Cada acuerdo SaaS contiene un porcentaje de tiempo de actividad del SLA, un tope de responsabilidad, una duración del plazo, un indicador de renovación automática, una jurisdicción de ley aplicable, y términos de pago. Eso no es prosa. Son campos. Una vez que los tratas como campos, puedes hacer con 500 contratos lo que una hoja de cálculo hace con 500 filas: filtrar, ordenar, agregar, alertar. El pipeline de analítica usa extracción basada en esquemas con agregación de portafolio para responder preguntas a nivel de junta directiva en minutos.
Prueba HAQQ AI gratis
Experimenta la redacción e investigación legal con IA
Capítulo 10: Comunicaciones reguladas
El 15 de marzo de 2024, una casa de bolsa de tamaño mediano pagó $4.2 millones para resolver cargos de la FINRA por publicaciones en redes sociales que su equipo de cumplimiento había aprobado. Una sola palabra — 'garantizado' — en un tuit desencadenó una acción de cumplimiento que consumió dieciocho meses de honorarios legales. El problema no fue negligencia. El problema fue que ningún ser humano puede sostener simultáneamente en su memoria de trabajo la Regla 156 de la SEC, la Regla 2210 de la FINRA, los requisitos estatales de blue-sky, y las políticas publicitarias internas del despacho mientras lee una publicación de 280 caracteres.
Las comunicaciones reguladas conllevan riesgo directo de aplicación de la ley. Una afirmación engañosa en una carta a inversores es una posible violación de valores. Un correo de marketing farmacéutico que omite las divulgaciones de seguridad requeridas es una infracción regulatoria de la FDA. El pipeline de ingeniería legal aplica capas de cumplimiento multimarco: cada comunicación se examina simultáneamente contra múltiples marcos regulatorios mediante agentes especialistas paralelos, cada uno entrenado en un cuerpo específico de regulaciones.
Capítulo 11: Riesgo de terceros
La brecha de SolarWinds de 2020 expuso a 18,000 clientes a través de una actualización de software comprometida. Target perdió 40 millones de números de tarjetas de crédito a través de un proveedor de HVAC comprometido. Tu perímetro de seguridad es tan fuerte como tu proveedor más débil. La gestión de riesgo de terceros es un flujo de trabajo de ingeniería legal que evalúa proveedores usando evaluación de riesgo por niveles, modelado de madurez y análisis automatizado de cuestionarios.
El pipeline clasifica a los proveedores por nivel de riesgo, despliega analizadores especializados para cada dimensión de riesgo (postura de ciberseguridad, prácticas de manejo de datos, cumplimiento regulatorio, estabilidad financiera), sintetiza los hallazgos en una puntuación de riesgo, y genera recomendaciones accionables. Las organizaciones con cientos de relaciones con proveedores pueden mantener un monitoreo de riesgo continuo en lugar de revisiones puntuales anuales.
Capítulo 12: Triaje de documentos
Un departamento legal corporativo recibe cuarenta documentos en un solo día. Una resolución de junta directiva, contratos de proveedores por renovar, una carta de cese y desista a las 4:47pm, enmiendas, contratos de empleo, una carta de demanda que amenaza con litigio con un período de subsanación de diez días. La mayoría de las organizaciones manejan esto de la misma forma: un paralegal etiqueta cada documento y lo coloca en una carpeta. Si la carta de demanda queda sin atender durante tres días porque el abogado responsable está en declaraciones, el período de subsanación expira silenciosamente.
El triaje de documentos usa clasificación especializada con enrutamiento por urgencia. El pipeline identifica el tipo de documento, extrae los plazos críticos, evalúa la urgencia, determina qué abogado o equipo debe manejar cada documento, y lo enruta en consecuencia con alertas automatizadas. La diferencia entre etiquetar un documento como 'Carta de Demanda' y extraer su plazo de subsanación de diez días es la diferencia entre un sistema de archivo y un sistema de ingeniería legal.
Capítulo 13: Seguimiento de obligaciones
Una empresa de tecnología de tamaño mediano firma su contrato número doscientos con un proveedor y entierra el PDF firmado en una unidad compartida. En algún lugar de la página catorce hay una cláusula que exige noventa días de aviso escrito antes de cualquier renovación automática. En algún lugar de la página veintiuno hay un requisito de mantener una cobertura de seguro mínima certificada anualmente. Nadie lee esas páginas después de firmar. Nueve meses después, el contrato se renueva automáticamente a una tarifa un veinte por ciento por encima del mercado. Cuatro meses después de eso, una auditoría revela que la certificación del seguro venció, desencadenando una cláusula de incumplimiento material.
El seguimiento de obligaciones usa pipelines de extracción con calendarización y alertas. El sistema lee cada contrato, identifica cada obligación (plazos de pago, hitos de entrega, ventanas de aviso, certificaciones de cumplimiento, disparadores de renovación, derechos de auditoría, requisitos de mantenimiento de seguro), crea entradas de calendario estructuradas, y envía alertas antes de que se acerquen los plazos. Dos obligaciones enterradas en doscientas páginas de doscientos contratos ya no cuestan seis cifras en sobrecostos.
Capítulo 14: Debida diligencia de M&A
Una adquisición de mercado medio se cierra después de que tres asociados registran 1,800 horas facturables revisando 2,400 documentos. La factura asciende a $1.2 millones. Seis meses después, el comprador descubre que el producto insignia del objetivo funciona bajo una licencia de propiedad intelectual que se termina automáticamente ante un cambio de control. La licencia era el documento 1,847 de 2,400, revisado el día 31 de un período de debida diligencia de seis semanas, por un asociado cuya capacidad cognitiva para detectar trampas sutiles de referencias cruzadas era funcionalmente nula.
La debida diligencia de M&A usa análisis de riesgo en seis dimensiones con mapeo de cambio de control. El pipeline procesa cada documento en la sala de datos contra una lista de verificación de debida diligencia, con agentes especializados analizando riesgos de propiedad intelectual, obligaciones laborales, cumplimiento regulatorio, disparadores contractuales de cambio de control, exposición a litigios y pasivos financieros. El sistema no reemplaza al asociado: garantiza que el documento 1,847 reciba el mismo rigor analítico que el documento 1.
Capítulo 15: Apoyo al litigio
El litigio moderno genera volúmenes asombrosos de información almacenada electrónicamente. Una sola investigación antimonopolio puede producir diez millones de documentos. La revisión tradicional cuesta entre uno y dos dólares por documento — entre diez y veinte millones de dólares antes de que se tome una sola declaración. La primera generación de revisión asistida por tecnología (TAR) redujo los costos pero requería costosas rondas de entrenamiento humano, tenía dificultades con la clasificación multietiqueta, y trataba el privilegio como una idea tardía.
La ingeniería legal es la segunda ola. Las arquitecturas multiagente clasifican, codifican y examinan documentos con precisión de especialista, a una fracción del costo, y con métricas de defensibilidad que los tribunales ya han aceptado. El pipeline de apoyo al litigio maneja la revisión de e-discovery, el filtrado de privilegio (una preocupación crítica que requiere soluciones arquitectónicas, no solo ingeniería de prompts), y la codificación de temas con registros de auditoría completos.
Capítulo 16: Investigación legal
La investigación legal es el fundamento invisible de la práctica legal. Una pregunta compleja de litigio puede consumir entre 20 y 40 horas de tiempo de un asociado a $400-$800 por hora. La profesión legal gasta miles de millones de horas al año en trabajo que trata fundamentalmente de leer, sintetizar y aplicar información — exactamente el tipo de labor cognitiva en la que sobresalen las arquitecturas de IA multiagente.
El pipeline de investigación legal usa investigación paralela con verificación obligatoria de citas. Múltiples agentes especialistas investigan diferentes aspectos de una pregunta legal simultáneamente (autoridad estatutaria, jurisprudencia, orientación regulatoria, fuentes secundarias), y luego un agente de síntesis ensambla los hallazgos en un memorando estructurado con citas verificadas. La restricción crítica: cada cita debe verificarse contra bases de datos legales reales. Las citas alucinadas no son un defecto menor: son la base para sanciones, como demostró Mata v. Avianca.
La conclusión: la arquitectura como multiplicador permanente
La tesis del libro no es que la IA cambiará la práctica legal. Eso es obvio. La tesis es que la arquitectura es lo que separa a la IA que produce trabajo de nivel socio de la IA que produce resúmenes costosos. El mismo modelo de frontera, dado el mismo contrato, produce 35 cambios rastreados con cero citas cuando se usa como un solo prompt, y 138 cambios rastreados con 18 citas legales cuando se envuelve en un pipeline multiagente. El modelo no se volvió más inteligente. La arquitectura mejoró.
Diez flujos de trabajo. Una arquitectura. Eso no es coincidencia. Eso es una disciplina.
Tres desarrollos moldearán la próxima fase. Primero, la capacidad de los modelos seguirá mejorando, pero la ventaja arquitectónica persistirá. Los mejores modelos elevan el piso de calidad de los sistemas de pasada única, pero también elevan el techo de los pipelines multiagente en el mismo margen. La arquitectura es un multiplicador permanente, no una solución temporal.
Segundo, la integración con bases de datos legales cerrará la brecha de verificación. Cuando los pipelines puedan consultar Westlaw o Lexis de forma programática, la verificación de citas se volverá determinista en lugar de probabilística. Las citas alucinadas se convertirán en un problema resuelto.
Tercero, el mercado se bifurcará. Los despachos y departamentos legales que adopten flujos de trabajo de IA diseñados con ingeniería operarán con estructuras de costos fundamentalmente distintas. Una revisión de contrato que cuesta $15,000 y toma dos semanas sin IA costará $2,000 y tomará dos días con un pipeline correctamente diseñado. Eso no es una mejora marginal. Es una ventaja estructural que se acumula en cada asunto, cada mes, cada año.
Puntos clave
- La ingeniería legal es la práctica de diseñar, construir e implementar flujos de trabajo impulsados por IA que automatizan el trabajo legal usando arquitecturas de pipeline multiagente. No es ingeniería de prompts ni tecnología legal lista para usar.
- El patrón TIRO (Trigger, Input, Requirements, Output) es el modelo universal de descomposición. Cada cláusula legal y cada etapa de un pipeline de IA sigue esta estructura.
- Los pipelines multipasada con agentes especialistas producen resultados medibles mejores que los prompts de pasada única: 3.9x más hallazgos, 18 citas legales frente a cero, con el mismo modelo sobre el mismo contrato.
- La paralelización vía patrones fan-out/fan-in permite análisis en tiempo real desplegando docenas de agentes especialistas simultáneamente, pero requiere un sintetizador obligatorio para producir una salida coherente.
- El privilegio abogado-cliente impone restricciones arquitectónicas que ninguna cantidad de ingeniería de prompts inteligente puede satisfacer. El despacho debe ser dueño de su infraestructura.
- La cirugía de Track Changes en OOXML es lo que hace que las líneas rojas generadas por IA sean indistinguibles del trabajo de un abogado humano. La precisión del formato importa tanto como la precisión analítica.
- La misma arquitectura fundacional se generaliza a través de diez flujos de trabajo legales distintos: redacción de contratos, revisión de líneas rojas, analítica, comunicaciones reguladas, riesgo de terceros, triaje de documentos, seguimiento de obligaciones, debida diligencia de M&A, apoyo al litigio, e investigación legal.
- La arquitectura es un multiplicador permanente. Los mejores modelos elevarán el piso, pero los pipelines correctamente diseñados siempre superarán el uso de pasada única del mismo modelo.
- El mercado se bifurcará entre los despachos que adopten flujos de trabajo de IA diseñados con ingeniería y los que no lo hagan. Las ventajas de costo y velocidad son estructurales, no marginales.
- El juicio del abogado sigue siendo el núcleo irreducible. La ingeniería legal maneja todo excepto el juicio, para que la experiencia del abogado pueda aplicarse a un trabajo que ya es exhaustivo, bien investigado, correctamente formateado e internamente consistente.
