Serie PRYMA · Del trabajo real a la IA útil · Artículo 3 de 5 · Caso de estudio anonimizado
Una operación corporativa puede requerir decenas de documentos. Pero eso no significa que cada uno deba prepararse desde cero.
En una firma legal, el desafío no siempre consiste en escribir algo nuevo. Muchas veces el conocimiento ya existe: hay precedentes, estructuras aprobadas, cláusulas conocidas y criterios que los abogados aplican según las particularidades de cada asunto. El trabajo consiste en reunir esos elementos, decidir cuáles corresponden y materializarlos correctamente.
Ahí encontramos una oportunidad de ingeniería: separar el razonamiento que exige especialización jurídica de la ejecución documental que puede realizarse mediante herramientas y reglas bien definidas.
En el proyecto desarrollamos agentes especializados y capacidades compartidas para coordinar encargos, trabajar con un corpus documental, transformar archivos Word y gestionar estados de revisión. Además, el responsable de la implementación reportó una experiencia concreta: un lote aproximado de 80–100 documentos procesado en unas 2–3 horas de ejecución del sistema, frente a una estimación de 1–2 jornadas de preparación manual para un trabajo comparable.
No presentamos esos tiempos como un ahorro neto ya auditado. Son una experiencia operativa reportada y una buena forma de explicar qué aporta una arquitectura donde los agentes no solo analizan información: también disponen de herramientas para actuar sobre documentos.
En el primer capítulo mostramos cómo partimos del trabajo real. En el segundo, cómo transformamos fuentes dispersas en evidencia revisable. Hoy llegamos al tercer paso: del análisis al entregable.
1. El mismo encargo contiene dos problemas de ingeniería diferentes
Tomemos una reestructuración societaria como ejemplo de la lógica observada en las sesiones con abogados.
Primero hay que estudiar las entidades involucradas, revisar instrumentos y restricciones, evaluar alternativas y definir una estructura jurídica. Ese trabajo requiere experiencia, interpretación y decisiones responsables.
Después, la solución acordada debe expresarse en documentos. Se preparan instrumentos, se incorporan datos específicos, se mantienen determinadas cláusulas y se coordinan versiones para revisión. Parte de esa producción utiliza formatos y reglas ya conocidos.
El criterio experto define qué corresponde hacer. Las capacidades de ejecución ayudan a materializar lo definido.
La diferencia se aprecia en una pregunta sencilla: ¿el sistema está decidiendo qué cláusula corresponde o está aplicando, en una plantilla autorizada, una decisión que ya fue tomada?
Ambas actividades pueden beneficiarse de IA, pero tienen riesgos y criterios de comprobación diferentes. En una, importa la calidad del análisis jurídico y de la evidencia. En la otra, importa que el documento conserve su estructura, que los datos sean correctos y que ningún cambio supere el alcance autorizado.
Figura 1 · Separar el criterio de la producción
flowchart TB
A["ENCARGO CORPORATIVO<br/>Asunto, alcance y responsable"] --> B["FUENTES Y CONTEXTO<br/>Antecedentes, versiones e instrucciones"]
B --> C["ANÁLISIS ESPECIALIZADO<br/>Determinar opciones y condiciones"]
C --> D{"¿Hay decisiones jurídicas<br/>que requieren confirmación?"}
D -->|Sí| E["ABOGADO RESPONSABLE<br/>Resuelve criterios y excepciones"]
D -->|No| F["PLAN DOCUMENTAL DEFINIDO<br/>Instrumentos, plantillas y datos"]
E --> F
F --> G{"¿La tarea exige criterio<br/>o una operación reproducible?"}
G -->|Criterio| H["ASISTENCIA DE ESPECIALIDAD<br/>Propuesta y revisión jurídica"]
G -->|Regla definida| I["HERRAMIENTA DOCUMENTAL<br/>Aplicar cambios autorizados"]
H --> J["DOCUMENTOS PREPARADOS<br/>Con cambios y pendientes identificados"]
I --> J
J --> K["REVISIÓN Y CONFORMIDAD<br/>Contenido, datos y formato"]
K --> L["SALIDA UTILIZABLE<br/>Versión aceptada para su propósito"]
classDef base fill:#F5F4EE,stroke:#242424,color:#242424,stroke-width:1.5px;
classDef decision fill:#F2B7EF,stroke:#242424,color:#242424,stroke-width:2px;
classDef tool fill:#EBDCF8,stroke:#242424,color:#242424,stroke-width:1.5px;
classDef result fill:#EEFF20,stroke:#242424,color:#242424,stroke-width:2px;
class A,B,C,E,F,J,K base;
class D,G decision;
class H,I tool;
class L result;
Figura 1. Separación funcional de un encargo documental. Rosa: decisiones; lila: capacidades de asistencia y ejecución; amarillo lima: resultado aceptado. El ejemplo societario sirve para explicar el método, no identifica necesariamente el tipo documental del lote de 80–100 archivos reportado más adelante.
La consultoría del lunes y la investigación del martes hacen posible esta distinción. Sin entender las fuentes, las excepciones y el resultado esperado, no hay una buena especificación para la herramienta que producirá el archivo.
2. Siete especialidades, capacidades compartidas
En lugar de concentrar todo el trabajo en un único asistente genérico, configuramos siete agentes jurídicos especializados, orientados a due diligence, financiamiento convertible, equity financing, M&A, revisión de documentación NVCA, reestructuraciones societarias y contratos corporativos o comerciales.
Cada especialidad tiene su propio objeto de análisis. Un agente de due diligence necesita ordenar fuentes, cobertura, hallazgos y pendientes. Uno de instrumentos convertibles debe distinguir condiciones de un SAFE, una nota convertible o una side letter. Una revisión de documentación NVCA compara términos y apartados dentro de un contexto específico. Y una reestructuración exige comprender entidades, actos y secuencias jurídicas.
Lo que cambia es el criterio. Lo que puede reutilizarse es parte de la ingeniería para ejecutar el trabajo.
En el proyecto desarrollamos cuatro capacidades jurídicas compartidas, vinculadas a los agentes de esa familia:
| Capacidad | Para qué se diseñó | Por qué importa |
|---|---|---|
| Coordinación del trabajo jurídico | Representar el encargo, su alcance, sus tareas y estados. | Conservar contexto entre una solicitud y las acciones necesarias para resolverla. |
| Corpus documental | Organizar fuentes, versiones, inventarios y unidades documentales. | Trabajar con entradas identificables y antecedentes que puedan verificarse. |
| Herramientas Word | Aplicar operaciones sobre DOCX, apoyadas en anclas y transformaciones delimitadas. | Pasar de una instrucción a un archivo real sobre el que el equipo puede trabajar. |
| Ciclo documental | Distinguir preparación, revisión, aprobación y entrega. | Mantener responsables y estados separados a lo largo del proceso. |
En este contexto, una skill es una capacidad reutilizable que puede incluir instrucciones, reglas y herramientas. No implica entrenar un nuevo modelo por cada función. Los agentes utilizan esas capacidades según el encargo; que estén disponibles no significa que todas se invoquen en cada tarea.
La orquestación coordina cuándo intervenir, qué entradas usar, cómo interpretar la salida de una herramienta y qué hacer ante una excepción. Su valor no está en multiplicar llamadas entre agentes, sino en mantener el trabajo conectado con un objetivo y unas condiciones de cierre.
Figura 2 · Arquitectura compuesta para ejecutar trabajo documental
flowchart TB
A["USUARIO Y ENCARGO<br/>Especialidad, objetivo y alcance"] --> B["AGENTE JURÍDICO<br/>Interpreta la solicitud y organiza el plan"]
B --> C["COORDINACIÓN<br/>Asunto, tareas y estado del trabajo"]
C --> D["CORPUS DOCUMENTAL<br/>Fuentes, plantillas, versiones y variables"]
D --> E{"¿Los insumos son suficientes<br/>y están autorizados?"}
E -->|No| F["EXCEPCIÓN EXPLÍCITA<br/>Dato, fuente o aprobación pendiente"]
F -.-> C
E -->|Sí| G["CONTRATO DE TRANSFORMACIÓN<br/>Qué cambiar, conservar y verificar"]
G --> H["CAPACIDAD WORD<br/>Edición delimitada sobre DOCX"]
H --> I["COMPROBACIÓN TÉCNICA<br/>Datos, estructura y cambios permitidos"]
I --> J{"¿Cumple la especificación<br/>de esta unidad?"}
J -->|No| K["CORREGIR Y REINTENTAR<br/>Sin perder la identidad documental"]
K -.-> G
J -->|Sí| L["CICLO DOCUMENTAL<br/>Estado: preparado para revisión"]
L --> M["ABOGADO RESPONSABLE<br/>Revisa contenido y autoriza"]
M --> N["VERSIÓN ACEPTADA<br/>Destino y uso autorizados"]
classDef base fill:#F5F4EE,stroke:#242424,color:#242424,stroke-width:1.5px;
classDef decision fill:#F2B7EF,stroke:#242424,color:#242424,stroke-width:2px;
classDef tool fill:#EBDCF8,stroke:#242424,color:#242424,stroke-width:1.5px;
classDef result fill:#EEFF20,stroke:#242424,color:#242424,stroke-width:2px;
class A,B,C,D,G,I,L,M base;
class E,J decision;
class F,H,K tool;
class N result;
Figura 2. Arquitectura lógica independiente del proveedor. Los agentes y las cuatro skills son componentes desarrollados; los puntos de control y rutas de aceptación representan el contrato de calidad que debe demostrarse por caso. El dibujo no acredita que todos los recorridos estén certificados de extremo a extremo.
Este es uno de los aprendizajes más transferibles del caso. Podemos especializar los agentes por materia sin reinventar cada vez cómo se busca una fuente, se manipula un documento o se conserva el estado de un trabajo. Cambiar de tecnología exige adaptar y probar integraciones, pero no elimina esta distinción de responsabilidades.
3. El detalle técnico: un Word no es simplemente una respuesta de texto
Trabajar sobre documentos de Microsoft Word introduce un problema distinto al de generar una respuesta en pantalla.
Un .docx es un paquete estructurado basado en Office Open XML (OOXML). Contiene texto, estilos y elementos que pueden incluir tablas, encabezados, numeración, secciones y otros componentes. Dos archivos con las mismas palabras pueden no ser equivalentes si cambió su estructura o se perdió un formato que el cliente necesitaba conservar.
En la familia de herramientas documentales del proyecto desarrollamos una capacidad Word que contempla anclas de edición, tratamiento de diferencias (redline) y manipulación XML que preserva espacios de nombres (namespaces). Esto expresa una decisión técnica: cuando una modificación está bien especificada, debe poder aplicarse a un artefacto identificable y comprobarse sobre el resultado.
La existencia de ese backend es evidencia de desarrollo; la fidelidad de todas las transformaciones, especialmente en DOCX complejos, exige pruebas específicas sobre los archivos generados. Conviene distinguir ambas cosas sin perder de vista el beneficio que buscamos: producir material que el abogado pueda abrir y continuar usando.
Un contrato de transformación, no una instrucción abierta
Imaginemos una plantilla societaria aprobada y una serie de documentos que deben adaptarse a distintas entidades. El ejemplo sirve para ilustrar el mecanismo; no reproduce datos del cliente.
| Tipo de contenido | Qué puede hacer el sistema | Control de calidad previsto |
|---|---|---|
| Partes y entidades | Completar nombres y datos desde una fuente autorizada. | Correspondencia con el asunto y las entidades involucradas. |
| Fechas y referencias | Aplicar formatos y reglas previamente acordadas. | Consistencia entre campos y documentos del mismo paquete. |
| Cláusulas protegidas | Conservar lo aprobado, sin ediciones fuera del alcance. | Comparación con la plantilla o versión base. |
| Condiciones que requieren interpretación | Preparar una propuesta o marcar una excepción. | Validación explícita del abogado responsable. |
| Tablas, numeración y estilos | Mantener la presentación exigida por el documento. | Inspección técnica y visual del archivo resultante. |
Este contrato de transformación tiene tres entradas esenciales: una plantilla identificada, datos verificables y reglas sobre qué puede modificarse. También define qué hacer si falta un dato crítico: detener esa unidad o solicitar aclaración, en lugar de completar un vacío con una suposición.
La ventaja de este enfoque no se limita a la velocidad. Hace posible separar transformaciones reproducibles de decisiones jurídicas, reutilizar herramientas entre especialidades y revisar con mayor precisión qué cambió en cada archivo.
4. Del documento individual al procesamiento por lotes
Cuando hablamos de decenas de documentos, la unidad de control deja de ser «una respuesta» y pasa a ser cada archivo solicitado dentro de un lote.
Para que un procesamiento por lotes sea gobernable, conviene acordar antes de ejecutarlo un contrato del lote. No es una especificación extensa por obligación: es la mínima información necesaria para que cada unidad documental tenga entradas conocidas y una condición clara de salida.
| Componente del contrato | Definición necesaria |
|---|---|
| Alcance y unidades | Qué documentos se solicitan, para qué asunto y cuáles quedan fuera. |
| Plantilla y versión | Sobre qué documento autorizado se trabajará y qué partes deben conservarse. |
| Variables y procedencia | Qué campo se completa, de qué fuente se obtiene y cómo se verifica. |
| Identidad de la unidad | Un identificador estable por documento, distinto de cada intento o versión. |
| Excepciones | Qué ocurre cuando falta un dato, hay contradicción o una regla no aplica. |
| Verificación técnica | Cómo se comprueban contenido, apertura, estructura y modificaciones permitidas. |
| Revisión profesional | Quién acepta el documento y qué asuntos se escalan al abogado. |
| Estado y destino | Cómo se registra si está preparado, requiere ajustes o fue aprobado. |
Además, hay una propiedad de ingeniería especialmente importante: la idempotencia. Significa que reintentar una operación, bajo la misma identidad documental, no debería crear un segundo entregable válido por accidente ni modificar silenciosamente uno ya aprobado.
Esto no es una garantía automática que se obtiene por usar agentes. Es un criterio de diseño que ayuda a contar correctamente las unidades, conservar el historial y evitar que una corrección vuelva confuso el estado del lote.
Figura 3 · Estados de un lote documental controlado
flowchart TB
A["LOTE DEFINIDO<br/>Alcance, plantilla y unidades esperadas"] --> B["MANIFIESTO<br/>Identificador único por documento"]
B --> C["INSUMOS DE LA UNIDAD<br/>Fuentes, variables y reglas"]
C --> D{"¿Entradas completas<br/>y verificables?"}
D -->|No| E["UNIDAD CON PENDIENTES<br/>Registrar causa y responsable"]
E -.-> C
D -->|Sí| F["GENERAR VERSIÓN DOCX<br/>Transformación delimitada"]
F --> G["CONTROL TÉCNICO<br/>Datos, estructura y cambios"]
G --> H{"¿Archivo conforme<br/>al contrato definido?"}
H -->|No| I["REINTENTO CONTROLADO<br/>Conservar identidad y registro"]
I -.-> C
H -->|Sí| J["ESTADO: PREPARADO<br/>Entregar para revisión"]
J --> K["REVISIÓN JURÍDICA<br/>Contenido y excepciones"]
K --> L{"¿Documento aprobado<br/>para su propósito?"}
L -->|Ajustes| M["NUEVA VERSIÓN<br/>Mantener historial de la unidad"]
M -.-> C
L -->|Sí| N["ESTADO: ACEPTADO<br/>Versión y destino autorizados"]
N --> O["EVALUACIÓN DEL LOTE<br/>Unidades aceptadas, esfuerzo y calidad"]
classDef base fill:#F5F4EE,stroke:#242424,color:#242424,stroke-width:1.5px;
classDef decision fill:#F2B7EF,stroke:#242424,color:#242424,stroke-width:2px;
classDef tool fill:#EBDCF8,stroke:#242424,color:#242424,stroke-width:1.5px;
classDef result fill:#EEFF20,stroke:#242424,color:#242424,stroke-width:2px;
class A,B,C,F,G,J,K,O base;
class D,H,L decision;
class E,I,M tool;
class N result;
Figura 3. Patrón propuesto para distinguir generación, revisión y aceptación, con rutas de corrección que conservan la identidad de cada unidad. No representa un registro certificado de la corrida reportada.
El resultado del diseño es simple de explicar: el sistema puede preparar los documentos y el profesional puede concentrarse en revisar los puntos que requieren su criterio, manteniendo identificado qué está listo y qué sigue pendiente.
5. El resultado observado: aproximadamente 80–100 documentos
Durante una etapa posterior del desarrollo, el responsable de la implementación reportó el procesamiento de un lote de aproximadamente 80–100 documentos Word en unas 2–3 horas de ejecución del sistema. Para una tarea manual comparable, el equipo estimaba 1–2 jornadas de preparación.
| Dimensión | Dato comunicado | Lectura correcta |
|---|---|---|
| Volumen del lote | Aproximadamente 80–100 documentos | Cantidad procesada reportada; no inventariada públicamente aquí. |
| Procesamiento del sistema | Aproximadamente 2–3 horas | Tiempo de ejecución reportado para el pipeline. |
| Referencia manual | Aproximadamente 1–2 jornadas | Estimación testimonial de preparación para una tarea comparable. |
La divulgación de este resultado fue autorizada. Es un antecedente prometedor de capacidad de procesamiento documental, no una comparación experimental de ahorro neto: todavía no contamos con mediciones consolidadas del tiempo de supervisión, correcciones, aprobación final y costo total del lote.
Importan también dos precisiones. No afirmamos aquí que ese lote corresponda a la reestructuración usada como ejemplo al comienzo; ese ejemplo explica la separación entre criterio y producción. Tampoco mezclamos este resultado con otro episodio de alto volumen relatado durante las entrevistas iniciales. Son antecedentes distintos.
Lo que sí ilustra el reporte es un avance relevante: el sistema no se limita a sugerir cómo preparar un archivo; dispone de capacidades para trabajar sobre los documentos y procesar unidades en lote.
Ese procesamiento ya tiene una duración reportada y convive con seguimiento operativo del uso de los agentes en la firma. Para expresar el ahorro neto por unidad, la siguiente capa de análisis consiste en reunir la versión del documento, su resultado de revisión, las correcciones y el esfuerzo humano de supervisión. No es una ausencia de resultados: es la diferencia entre medir la ejecución del sistema y medir todo el ciclo hasta una entrega aceptada.
6. Medir trabajo útil, no solo archivos producidos
La pregunta de negocio no termina al obtener una carpeta llena de archivos. Termina cuando la organización puede comprobar que la salida cumple el propósito previsto y cuánto esfuerzo necesitó para conseguirlo.
Por eso, proponemos evaluar la ejecución documental en dos niveles complementarios:
Calidad técnica. ¿El DOCX abre correctamente? ¿Contiene los datos esperados? ¿Se conservaron las partes protegidas? ¿Su estructura y formato corresponden a la plantilla aprobada?
Conformidad profesional. ¿El documento corresponde a la operación? ¿Las cláusulas y excepciones reflejan las decisiones tomadas? ¿El abogado puede aceptarlo para el uso previsto?
Estas comprobaciones son criterios de evaluación, no una afirmación de que ya se hayan registrado resultados completos para todas las especialidades o lotes.
Para medir impacto, distinguiríamos cuatro indicadores:
| Indicador | Qué permite responder |
|---|---|
| Tiempo de procesamiento | ¿Cuánto tarda el sistema en preparar el lote? |
| Unidades aceptadas | ¿Cuántos documentos únicos fueron aprobados, sin contar reintentos como nuevas entregas? |
| Esfuerzo humano por unidad aceptada | ¿Cuánto tiempo demandaron preparación, supervisión, correcciones y revisión? |
| Costo completo por unidad aceptada | ¿Qué recursos humanos y tecnológicos fueron necesarios para producir la salida aprobada? |
El seguimiento de adopción nos permite ver qué agentes y capacidades empiezan a formar parte de la jornada. Los controles específicos de Word responden otra pregunta: qué documentos se producen correctamente y cuánto trabajo profesional requieren hasta su aceptación. Ambas observaciones se complementan: una orienta dónde invertir en la experiencia de uso; la otra, dónde perfeccionar reglas, plantillas y verificaciones.
Con estos datos se puede evaluar si conviene ampliar la automatización, corregir una regla, mejorar una plantilla o añadir una herramienta. El objetivo no es atribuir valor a cada llamada de un modelo: es aumentar la capacidad del equipo para entregar trabajo verificable con su estándar profesional.
7. El aprendizaje transferible: especializar el criterio, reutilizar la ejecución
Este proyecto parte de abogados corporativos, pero el patrón también aparece donde se producen propuestas, licitaciones, informes técnicos y contratos a partir de documentos y estructuras reutilizables.
Lo que no debe copiarse entre clientes es el criterio jurídico, el contenido confidencial ni los permisos de una firma. Lo que sí puede reutilizarse es el método y parte de la ingeniería: identificar el encargo, verificar entradas, distinguir interpretación de transformación, coordinar herramientas, mantener estados y validar entregables.
No implica que cualquier plataforma sea idéntica. Significa que la arquitectura se explica por las responsabilidades que debe cumplir y no por el nombre de un producto.
En PRYMA esa capacidad se construye combinando especialidad jurídica e ingeniería reutilizable, sin convertir cada nuevo documento en un proyecto independiente.
El agente aporta razonamiento especializado. Las herramientas le dan capacidad de actuar. La orquestación mantiene continuidad. Y el profesional confirma que la salida cumple el estándar que necesita.
No se trata solamente de que la IA sepa qué hacer. Se trata de darle capacidades para ayudar a hacerlo.
Próxima entrega: el documento no termina el proceso
Ya entendimos el trabajo, construimos evidencia y comenzamos a convertirla en documentos utilizables. Pero completar un archivo no siempre significa que el proceso empresarial haya avanzado: el siguiente responsable necesita saber qué recibió, qué estado tiene y qué falta para continuar.
En el cuarto artículo hablaremos de continuidad operativa, traspasos y estados verificables, sin confundir la entrega de un archivo con el cierre de un proceso.
¿Hablamos de tu caso?
Diseñamos, construimos y evaluamos capacidades de IA que se incorporan al trabajo real.
Hablar con un ingeniero
