Analizar documentos y contratos en bloque

De todos los usos que monto en una empresa, este es el que produce el «ah, vale» más rápido. No exige cambiar cómo trabaja nadie. Solo quita las horas de lectura mecánica que hay antes de cada decisión: comparar catorce ofertas, revisar sesenta contratos, extraer los vencimientos de una cartera.

Por qué este caso tiene el mejor retorno

El trabajo documental tiene una forma muy concreta: alguien cualificado y caro dedica horas a localizar quince datos repartidos por cientos de páginas, los pasa a una hoja y entonces —solo entonces— empieza a pensar. La parte que aporta valor es la última; las anteriores son transcripción.

Un ejemplo de compras: catorce ofertas de proveedores, de ocho a cuarenta páginas cada una y con formatos distintos. Un responsable tarda una jornada larga en dejarlas comparables. Con el método de esta lección la tabla sale en veinte minutos y la jornada se dedica a negociar. El trabajo no desaparece, se desplaza hacia arriba.

Tres razones por las que este caso funciona mejor que otros:

• El resultado es verificable. Cada celda se contrasta contra su página de origen en diez segundos. No es una opinión, es una extracción.
• No hay que integrar nada. Arrastras los archivos a una conversación y trabajas. Los conectores ayudan si los documentos viven en una unidad compartida, pero no hacen falta para empezar.
• El ahorro se mide solo. Horas antes, horas después. Es el único caso donde no tengo que discutir el retorno con un director financiero.

Qué hace posible el millón de tokens

La ventana de contexto es cuánta información puede tener Claude presente a la vez. Los modelos actuales de la familia —Fable 5, Opus 5 y Sonnet 5— manejan un millón de tokens, que en la práctica son varios cientos de páginas. Haiku 4.5, el rápido, se queda en 200.000: suficiente para un puñado de contratos, no para una cartera entera.

La diferencia con trocear el material no es de comodidad, es de calidad. Analizando de cinco en cinco, cada tanda se examina sin memoria de las anteriores y se pierden las comparaciones transversales: quién es el único que no cubre este riesgo, qué cláusula se repite idéntica en once contratos. Con todo dentro a la vez, esas preguntas se pueden hacer.

Aun así, más contexto no es siempre mejor. Con volúmenes muy grandes conviene trabajar por lotes temáticos —arrendamientos por un lado, servicios por otro— porque la rejilla de extracción cambia y las respuestas salen más precisas. Para elegir modelo según tarea y coste, tienes la lección de modelos.

El método en cuatro fases

El error de casi todo el mundo es subir los documentos y preguntar «¿qué te parece?». La respuesta será un resumen correcto y absolutamente inútil. El orden correcto invierte los dos primeros pasos.

1. Define la rejilla de extracción antes de leer nada

   Escribe la lista exacta de datos que quieres de cada documento, con su formato. No «las condiciones de pago», sino «días de pago desde factura, como número entero». Esta fase se hace en papel y sin abrir Claude. Si no sabes qué buscas, ninguna herramienta lo va a saber por ti.

2. Carga el material completo

   Todos los documentos en una conversación, o en un Proyecto si vas a volver sobre ellos. Nómbralos de forma reconocible antes de subirlos: ese nombre es el que aparecerá en la columna de origen.

3. Extrae a tabla, una fila por documento

   Las columnas de la rejilla, más una obligatoria de página de origen y otra de nivel de confianza. Lo que no aparezca se marca como «no consta»: nunca se deduce, nunca se deja en blanco.

4. Verifica antes de usar

   Comprueba contra la página citada las celdas que mueven dinero o riesgo. Es la fase que la gente se salta y la única que no se puede saltar.

Este es el prompt de rejilla completo. Entre un uso y otro solo cambia la lista de campos; el resto del andamiaje se queda igual.

Las tres listas del final son la parte más útil del prompt. La tercera —lo que no habías pensado preguntar— es la que en compras descubre la cláusula de renovación automática que nadie había mirado.

Tres casos desarrollados

Comparar ofertas de proveedores

Es el caso más limpio porque la rejilla es objetiva y los documentos son cortos. Sale exactamente lo del prompt anterior. El paso que añado siempre es una segunda pasada a igualdad de condiciones: recalcular el coste total considerando plazos de pago, transporte y pedido mínimo, no solo el precio unitario. Ahí cambia el orden del ranking en la mitad de los casos.

Revisar contratos contra un marco de referencia propio

Aquí el material es doble: los contratos y tu documento de posición, el que dice qué cláusulas aceptáis, cuáles negociáis y cuáles son línea roja. Si no existe, este es el momento de escribirlo: es el activo que hace útil todo lo demás.

Esto es también un caso natural para Cowork, que puede ejecutar la revisión de forma autónoma sobre una carpeta y dejar el resultado escrito, incluso como tarea programada cada semana sobre los contratos nuevos.

Extraer obligaciones y vencimientos de una cartera

El caso menos vistoso y el que más disgustos evita: sacar de todos los contratos vivos las fechas que obligan a hacer algo —fin de vigencia, preaviso de no renovación, revisiones de precio, hitos de entrega—.

La salida no es una tabla, es un calendario. Pide las obligaciones ordenadas por fecha, con la fecha límite real de actuación —la del preaviso, no la del vencimiento— y el responsable si consta. Con eso montas un panel en Artifacts o lo vuelcas a tu hoja de cálculo. La primera vez que se hace este ejercicio en una empresa mediana suelen aparecer dos o tres renovaciones automáticas que ya nadie recordaba.

Verificación: la fase que no se puede saltar

Claude lee bien, pero no lee siempre bien. Los fallos que veo son concretos y repetidos: confundir dos cláusulas parecidas de documentos distintos, tomar una excepción por la regla general, dar por vigente lo que un anexo posterior modificó y —el más peligroso— rellenar un hueco con un valor plausible cuando el dato no consta.

El riesgo no está en el error, está en la presentación. Una tabla bien maquetada transmite una autoridad que el texto suelto no tiene, y un dato equivocado dentro de una tabla limpia pasa cinco comités sin que nadie lo cuestione. Por eso la verificación es parte del método, no un extra de calidad.

Cómo se verifica, en la práctica:

• Exige la cita literal y la página. Un dato sin origen trazable no entra en la tabla. Que la columna exista obliga a que exista la trazabilidad.
• Comprueba a mano las celdas de riesgo. No las 300: las que mueven dinero, plazo o responsabilidad. Suelen ser el 10 % y son las que importan.
• Haz la prueba del dato inexistente. Pregunta por una cláusula que sabes que no está en ninguno. Si te la encuentra, para el proceso y refuerza la instrucción de «no consta».
• Pide la contralectura. En un mensaje nuevo, con la tabla y los documentos delante, pide que busque errores en la propia tabla.

Qué no delegar y hasta dónde llegar

Claude extrae, ordena y señala. No decide. Tres cosas no salen nunca de una conversación: el criterio jurídico —qué significa una cláusula en el contexto de la relación—, la valoración de riesgo con el cliente concreto delante y la decisión final, que tiene un responsable con nombre. El análisis prepara la decisión de un profesional; no la sustituye.

El nivel de revisión no es el mismo para todo. Esta es la tabla que uso para calibrar el esfuerzo:

Queda la confidencialidad, que aquí no es un detalle menor: entran contratos de clientes, precios de proveedores y a veces datos personales. En los planes de pago, Anthropic no entrena sus modelos con el contenido de las conversaciones por defecto, y Team y Enterprise añaden controles de administración y retención, registros de auditoría y control de acceso por roles.

Pero la seguridad no la da solo el proveedor: la da tu gobernanza. Qué documentos se suben, quién accede al Proyecto y qué conectores están autorizados es decisión tuya, y conviene tomarla antes y por escrito. La lección de conectores explica cómo se autoriza cada acceso mediante OAuth y por qué conviene concederlos de uno en uno.

Con el análisis documental resuelto tienes el caso que mejor convence a un comité. Lo que viene después no es técnico: es cómo se lleva esto a un equipo entero sin que se quede en tres entusiastas y veinte licencias sin usar. Eso es introducir la IA en un equipo sin fricción.