Agente de IA para revisión de contratos: arquitectura y puntos críticos
La revisión de contratos es uno de los casos de uso más claros para agentes de IA en empresas: proceso repetitivo, criterio bien definido, coste alto por hora de abogado. La arquitectura no es compleja, pero hay puntos concretos donde los proyectos fallan.
Equipo IAinsanity
Generado con IA · Revisado por el equipo

El cuello de botella en revisión de contratos casi nunca es el modelo de IA. Es la calidad del texto de entrada y la falta de un esquema de salida definido desde el día uno.
Cuándo tiene sentido un agente de revisión
No todos los flujos de contratos justifican un agente. Tiene sentido cuando se dan tres condiciones: volumen alto (más de 20-30 contratos por semana), criterio de revisión explícito (lista de cláusulas a verificar, plantillas aprobadas), y coste de revisión manual significativo.
Si el criterio de revisión es ambiguo o cambia caso a caso, el agente no va a dar resultados consistentes. El agente aplica criterio. No lo crea.
Arquitectura en tres capas
La estructura que funciona en la mayoría de implementaciones tiene tres partes diferenciadas.
Capa 1. Extracción: el PDF entra y sale como texto estructurado por secciones. La calidad de esta capa determina todo lo que viene después. Contratos escaneados con OCR pobre generan texto ruidoso que confunde al modelo. Hay que añadir una capa de limpieza antes del análisis.
Capa 2. Análisis: el LLM recibe cada sección con el criterio de revisión explícito. Aquí el error más frecuente es intentar hacer demasiado en una sola llamada: extraer, evaluar y resumir a la vez produce resultados inconsistentes. Dos llamadas separadas (extracción estructurada + evaluación) dan más control.
Capa 3. Salida: el formato importa tanto como el análisis. Un resumen en lenguaje natural es útil para el abogado que revisa, pero si el resultado tiene que integrarse en un sistema de gestión, necesita ser JSON con esquema fijo. Definir ese esquema antes de escribir el primer prompt evita reescrituras costosas.
Errores frecuentes en este tipo de proyectos
No definir el esquema de salida desde el inicio. Cualquier cambio en el JSON a mitad de proyecto obliga a reescribir el prompt de evaluación y revalidar todos los contratos de prueba.
Saltarse la fase de evaluación. Antes de poner en producción hay que medir la precisión del agente con un conjunto de contratos ya revisados por humanos. Sin esa medición no sabes si el agente funciona o simplemente parece que funciona.
Ignorar los casos edge. Los contratos que no siguen el formato estándar (escaneados, con tablas, con cláusulas manuscritas) aparecen en producción tarde o temprano. Hay que cubrirlos antes de que lleguen.
Qué esperar en términos de precisión
Un agente bien configurado puede hacer la primera revisión con una tasa de error (cláusulas de riesgo no detectadas) por debajo del 5% en contratos estándar. En contratos atípicos esa tasa sube.
El objetivo no es eliminar al abogado. El agente hace la revisión inicial y el abogado invierta su tiempo en los puntos marcados como problemáticos y en los casos fuera de lo estándar. El ROI viene de esa redistribución del tiempo, no de la sustitución.
Lectura relacionada
¿QUIERES HACER ESTO EN TU EMPRESA?
Cuéntanos el caso en 5 minutos.
El Sprint de Diagnóstico (990€, 1 semana) identifica exactamente qué puedes automatizar y cuánto te costaría. Si continúas, los 990€ se descuentan.