
Fine-Tuning vs. Prompt Engineering para la Revisión de Documentos Legales
¿Cuándo el prompt engineering alcanza su techo en tareas legales de IA? Una comparación práctica entre prompt engineering y fine-tuning para revisión de contratos, con un marco de decisión para agencias.
Toda agencia de IA que construye herramientas legales empieza con prompt engineering. Es rápido, no requiere datos de entrenamiento y funciona sorprendentemente bien para tareas genéricas. Pero a medida que los clientes exigen mayor precisión en sus tipos de documentos específicos, el prompt engineering alcanza un techo que ninguna cantidad de prompts ingeniosos puede superar.
Este artículo compara ambos enfoques cara a cara en la revisión de contratos — uno de los casos de uso legales de IA más comunes — y proporciona un marco para decidir cuándo dar el salto al fine-tuning.
Dónde funciona el Prompt Engineering
El prompt engineering es el punto de partida correcto. Para tareas legales generales con salidas bien definidas, un prompt cuidadosamente diseñado con un modelo de frontera (GPT-4o, Claude Sonnet) entrega buenos resultados:
Buenos casos de uso para prompt engineering:
- Resumir jurisprudencia disponible públicamente
- Generar borradores iniciales de documentos legales estándar a partir de plantillas
- Responder preguntas legales generales (no específicas de un caso)
- Clasificar documentos en categorías amplias (contrato, moción, escrito, correspondencia)
Para estas tareas, el conocimiento de preentrenamiento del modelo cubre bien el dominio. El prompt proporciona estructura y restricciones. Los resultados son aceptables para una primera revisión que un abogado luego examina.
Dónde el Prompt Engineering alcanza su techo
La revisión de documentos legales — el análisis detallado de contratos, arrendamientos, presentaciones regulatorias y documentos similares en busca de problemas específicos — es donde el prompting falla.
La prueba de revisión de contratos
Considera una prueba práctica: revisar un contrato de arrendamiento comercial para un cliente específico, verificando 25 factores de riesgo comunes (cláusulas de indemnización, restricciones de cesión, disparadores de terminación, requisitos de seguro, etc.).
Con prompt engineering (GPT-4o):
System: You are a legal document analyst specialising in commercial leases.
Review the following lease agreement and identify all instances of the
following risk factors: [list of 25 risk factors with descriptions]
For each, provide the relevant clause, your assessment, and a risk rating.
Resultados en un conjunto de referencia de 50 arrendamientos:
| Métrica | Puntuación |
|---|---|
| Factores de riesgo correctamente identificados | 72% |
| Falsos positivos (problemas señalados incorrectamente) | 18% |
| Cláusulas críticas omitidas | 15% |
| Calificaciones de riesgo consistentes | 61% |
72% de identificación es impresionante para un modelo de propósito general. Pero para un bufete de abogados, significa omitir aproximadamente 1 de cada 4 cláusulas relevantes. Eso no es una herramienta — es un riesgo.
Por qué el prompting no puede cerrar la brecha
Lenguaje específico de jurisdicción. El lenguaje legal varía significativamente según la jurisdicción. Una cláusula de "quiet enjoyment" en Nueva Gales del Sur se lee diferente a una en Nueva York. El prompt engineering no puede codificar estas diferencias sin hacer que el prompt sea tan largo que degrade el rendimiento.
Tolerancia al riesgo específica del cliente. Un cliente considera aceptable un aviso de terminación de 30 días. Otro requiere un mínimo de 90 días. Estos umbrales específicos del cliente no pueden codificarse de manera confiable en prompts.
Variación en la estructura del documento. Los arrendamientos de diferentes contrapartes usan diferentes estructuras, sistemas de numeración y convenciones de referencias cruzadas. Un modelo de propósito general tiene dificultades para rastrear referencias a lo largo de un documento de 60 páginas con formato inconsistente.
Consistencia. El mismo arrendamiento revisado dos veces con el mismo prompt produce resultados diferentes. Para el trabajo legal, la inconsistencia es inaceptable — el bufete necesita que la misma cláusula sea señalada de la misma manera siempre.
Qué cambia el Fine-Tuning
El fine-tuning enseña al modelo los patrones específicos, la terminología y los criterios de juicio que el prompting no puede transmitir. La misma tarea de revisión de contratos con un modelo ajustado:
Datos de entrenamiento: 2,000 revisiones de arrendamientos anotadas del trabajo histórico del bufete — cláusulas etiquetadas con factores de riesgo, evaluaciones y calificaciones por abogados experimentados.
Modelo ajustado (Llama 3.1 8B + LoRA):
| Métrica | Prompt Engineering (GPT-4o) | Fine-Tuned (8B) |
|---|---|---|
| Factores de riesgo correctamente identificados | 72% | 94% |
| Falsos positivos | 18% | 6% |
| Cláusulas críticas omitidas | 15% | 3% |
| Calificaciones de riesgo consistentes | 61% | 92% |
| Tiempo promedio de revisión | 45 seg | 12 seg |
| Costo por revisión | $0.15-0.40 | ~$0 (local) |
El modelo 8B ajustado supera al GPT-4o con prompts en cada métrica. Es más rápido porque es más pequeño y se ejecuta localmente. Es más barato porque no hay cargos de API. Y es más preciso porque ha aprendido los patrones específicos que le importan a este bufete.
Por qué el Fine-Tuning funciona para tareas legales
Impresión de patrones. El fine-tuning incrusta los patrones de análisis del bufete directamente en los pesos del modelo. El modelo no necesita que le digan cómo luce una cláusula de indemnización problemática — ha visto cientos de ejemplos.
Consistencia por construcción. Un modelo ajustado produce salidas más consistentes porque los datos de entrenamiento le enseñan un marco analítico específico. La misma cláusula dispara la misma evaluación.
Velocidad por compresión. Un modelo 8B ajustado reemplaza a un modelo de más de 175B con prompts. El conocimiento se ha comprimido en una arquitectura más pequeña y rápida que sobresale en la tarea específica.
Costo a escala. La inferencia local en un modelo ajustado cuesta esencialmente nada por documento. Para un bufete que revisa miles de contratos por año, esto transforma la economía de la revisión asistida por IA.
El marco de decisión
Usa este marco para decidir si el fine-tuning vale la inversión para un caso de uso legal específico:
Quédate con Prompt Engineering si:
- La tarea es de propósito general (no específica de cliente o jurisdicción)
- El volumen es bajo (menos de 100 documentos por mes)
- Los requisitos de precisión son moderados (filtrado inicial, no revisión final)
- No tienes ejemplos históricos para entrenar
- El cliente está en modo exploración y no está listo para comprometerse con un flujo de trabajo específico
Pasa al Fine-Tuning si:
- La tarea es repetitiva y específica del dominio (mismo tipo de documento, mismo análisis)
- El volumen justifica la inversión (más de 100 documentos por mes)
- Los requisitos de precisión son altos (la salida influye en decisiones legales)
- Tienes más de 1,000 ejemplos históricos con anotaciones de calidad
- La consistencia importa (la misma cláusula debe señalarse siempre de la misma manera)
- El costo importa a escala (los cargos de API se están convirtiendo en un gasto significativo)
- La privacidad de datos requiere inferencia local
El enfoque híbrido
Muchas agencias empiezan con prompt engineering para validar el caso de uso y luego transicionan a fine-tuning una vez que el cliente está comprometido:
- Mes 1-2: Desplegar solución con prompt engineering, recopilar retroalimentación del cliente
- Mes 3: Usar las interacciones acumuladas como datos de entrenamiento para fine-tuning
- Mes 4: Desplegar modelo ajustado, comparar contra la línea base con prompts
- Continuo: Reentrenar periódicamente a medida que los estándares de revisión del bufete evolucionan
Este enfoque reduce el riesgo de la inversión en fine-tuning al validar la demanda antes de comprometer recursos.
Implementación práctica
Para agencias listas para ajustar modelos legales de IA:
- Preparación de datos: Exportar las revisiones históricas de documentos del bufete. Estandarizar el formato de anotación. Limpiar y deduplicar.
- Selección del modelo base: Llama 3.1 8B para tareas estándar, 13B para análisis complejo de múltiples pasos. Los modelos más pequeños se ajustan más rápido y se ejecutan más barato.
- Fine-tuning: Usar Ertas Studio para fine-tuning sin código, o entrenamiento LoRA si prefieres control manual.
- Evaluación: Probar en un conjunto reservado de documentos que el modelo nunca ha visto. Comparar contra la línea base con prompts en los mismos documentos.
- Despliegue: Exportar a GGUF, desplegar vía Ollama en el hardware del bufete.
Todo el proceso desde la preparación de datos hasta el modelo desplegado típicamente toma 1-2 semanas para una agencia experimentada.
Ship AI that runs on your users' devices.
Ertas early bird pricing starts at $14.50/mo — locked in for life. Plans for builders and agencies.
Lectura adicional
- Fine-Tuning vs. RAG: Cuándo usar cada uno — Entendiendo los roles complementarios del fine-tuning y la generación aumentada por recuperación
- Cómo ajustar un LLM — Guía técnica paso a paso para fine-tuning con LoRA
Ship AI that runs on your users' devices.
Early bird pricing starts at $14.50/mo — locked in for life. Plans for builders and agencies.
Keep reading

From Prompt Engineering to Fine-Tuning: The Migration Playbook
A practical playbook for teams migrating from prompt engineering to fine-tuning — when to make the switch, how to convert prompts into training data, and the step-by-step migration process.

Prompt Engineering Has a Ceiling. Here's What Comes After.
Prompt engineering can take you far — but every agency and developer hits the wall eventually. Here's what the ceiling looks like, why it exists, and what techniques come after.

Model Distillation Explained: Run Sonnet-Quality Output on a $0 Inference Bill
A complete guide to model distillation — how to transfer capabilities from large frontier models like Claude Sonnet into small local models, achieving comparable quality at zero ongoing inference cost.