Un second brain para litigio: expedientes y agentes bajo revisión

En 60 segundos: El second brain de un despacho de litigio es un registro operativo que conecta cliente, número de expediente, documentos, estado observado, próxima actuación, responsable y evidencia. Se construye por etapas: ordenar el repositorio; añadir conectores autorizados a los portales disponibles; monitorear, comparar y archivar sin duplicados; y recién entonces permitir consultas y borradores con fuentes visibles. La IA puede leer, clasificar, resumir y preparar. El abogado decide estrategia, comprueba hechos y citas y aprueba cualquier actuación. Si un portal no ofrece un acceso permitido, ese tramo sigue siendo manual.

En litigio, una pregunta aparentemente sencilla puede exigir revisar cuatro lugares. El nombre del cliente vive en el gestor; el número de expediente, en una hoja; la última resolución, en una descarga local; y la próxima actuación, en el calendario de una persona. Buscar solo por cliente falla cuando hay varios asuntos, razones sociales parecidas o documentos guardados con nombres distintos.

El problema no se arregla añadiendo otra caja de búsqueda. Hace falta una relación estable entre las piezas y una forma visible de saber qué se observó, cuándo, de dónde vino y quién debe actuar. Esa es la función del second brain operativo: reducir la pérdida de contexto sin fingir que el sistema puede ejercer el criterio profesional del abogado.

Estas notas describen un patrón de proceso, no un caso real ni una recomendación jurídica. Cada despacho debe adaptar plazos, controles y responsabilidades a su jurisdicción, materias y obligaciones profesionales.

El expediente, no el chat, es la unidad de trabajo

Una consulta útil no debería depender de recordar cómo se nombró una carpeta. El registro mínimo necesita una clave interna estable para el asunto y relaciones explícitas con:

• cliente y parte representada, con los permisos que correspondan;
• número de expediente y órgano o jurisdicción;
• partes y roles necesarios para distinguir asuntos;
• documentos, su origen, versión, fecha y huella para deduplicación;
• último estado observado y la evidencia que lo respalda;
• próxima actuación propuesta, responsable, fecha candidata, fuente del plazo y estado de revisión;
• historial de consultas, cambios, aprobaciones y excepciones.

El nombre del cliente sirve para encontrar candidatos, no como llave única. Una búsqueda por nombre debería devolver los asuntos compatibles y pedir una selección cuando exista ambigüedad. El sistema no debe mezclar expedientes porque comparten apellido, empresa o abogado.

También conviene separar cuatro cosas que suelen confundirse: documento recibido, estado procesal interpretado, próxima actuación propuesta y tarea aprobada. Una resolución nueva puede disparar revisión. No convierte por sí sola una inferencia del modelo en una instrucción procesal.

Un plazo merece el mismo tratamiento. El registro separa la fecha observada o calculada, su fuente, zona horaria, regla aplicada, persona que la verificó y calendario donde quedó confirmada. Hasta esa revisión, se muestra como dato pendiente, no como vencimiento definitivo.

Los riesgos aparecen en los cruces entre sistemas

Los fallos más costosos no siempre nacen en el razonamiento jurídico. A menudo aparecen en el traspaso:

• una notificación llega, pero nadie la vincula con el asunto correcto;
• una promoción o escrito existe, pero queda bajo un nombre que la búsqueda no recupera;
• dos personas descargan el mismo documento y trabajan sobre copias distintas;
• el portal cambia, pero el gestor conserva el estado anterior;
• una fecha se copia sin zona horaria, fuente o responsable;
• un borrador parece definitivo porque no muestra su estado de revisión;
• una consulta sin resultados se interpreta como “no hubo movimiento”.

Son patrones operativos, no cifras ni incidentes atribuidos a un despacho. Su control exige trazabilidad, idempotencia y una cola de excepciones. La guía sobre el coste de copiar datos entre sistemas desarrolla el mismo problema desde otras operaciones: cuando cada traspaso pierde contexto, la organización termina verificando todo de nuevo.

Arquitectura por etapas

Etapa 1: un repositorio organizado y un índice común

Empezá con Drive o un repositorio equivalente que el despacho ya tenga autorizado. Definí una estructura por asunto, una convención de nombres y un índice que conecte cada archivo con la clave interna del expediente. No hace falta mover todo el archivo histórico para aprender.

El piloto puede cubrir una materia, un equipo y un conjunto acotado de expedientes activos. Inventariá fuentes, permisos, propietarios y reglas de retención. Marcá qué copia es oficial y qué materiales son notas de trabajo. Una carpeta ordenada ayuda; el índice común es lo que permite consultar sin depender de la memoria de quien la creó.

Antes de incorporar IA, comprobá que una persona pueda abrir un asunto y responder: qué documento llegó, de dónde, si ya existía, quién lo revisa y cuál es el próximo paso pendiente.

Etapa 2: conectores a portales autorizados

Cada portal debe tratarse como una integración independiente. Usá una API, exportación, bandeja o método automatizado solo cuando el acceso, las credenciales y los términos lo permitan. Registrá identidad consultada, momento, criterio de búsqueda, resultado y cualquier limitación.

No construyas el flujo suponiendo que todos los portales ofrecen las mismas capacidades. Algunos podrán entregar documentos; otros, solo un estado; otros requerirán consulta manual. La ausencia de un conector no autoriza el scraping ni convierte un resultado incompleto en confirmación de que no hubo cambios.

Cuando el portal esté caído, la sesión expire o el expediente no coincida de forma inequívoca, el sistema abre una excepción. Una persona resuelve la identidad o realiza la consulta y deja la misma evidencia mínima que habría producido el conector.

Etapa 3: agente de monitoreo y archivo

El agente de monitoreo consulta únicamente las fuentes y expedientes autorizados. Compara el resultado con la última observación, descarga cuando corresponde y propone el vínculo con el asunto. Antes de archivar, calcula una huella del contenido y revisa identificadores, nombre, fecha y origen para evitar duplicados.

Su salida necesita más detalle que “expediente actualizado”. Debe ser un evento revisable:

Campo	Ejemplo de estado, no de contenido real
Expediente	Coincidencia exacta / ambigua / no encontrada
Fuente	Portal o bandeja autorizada y hora de consulta
Cambio	Documento nuevo / metadato modificado / sin cambio observable
Archivo	Guardado / duplicado detectado / en cuarentena
Revisión	Pendiente, aprobada o rechazada por una persona
Próximo paso	Sin proponer / borrador pendiente / tarea aprobada

La escritura debe ser idempotente: repetir una ejecución no crea otra copia ni otra tarea. Si dos documentos tienen nombres iguales y contenido distinto, ninguno reemplaza al otro en silencio. Si tienen contenido idéntico, el sistema conserva la procedencia sin multiplicar archivos.

Etapa 4: agente de consulta y borradores

Solo después de confiar en el índice y el archivo conviene habilitar preguntas en lenguaje natural. El agente recupera asuntos por identificadores y permisos, muestra las fuentes utilizadas y distingue hechos documentados de inferencias.

Puede responder “estos son los últimos documentos asociados y esta es la tarea pendiente registrada”. No debería afirmar que un estado procesal es definitivo cuando la fuente no lo confirma. Tampoco debe calcular o prometer un plazo jurídico como si fuera una regla universal.

Para borradores, el flujo seguro es recuperar → citar la fuente interna → preparar → revisar → aprobar. El agente puede ordenar antecedentes y producir una primera versión de un correo, resumen o escrito dentro de una plantilla aprobada. El abogado comprueba el expediente completo, las citas legales, la vigencia de la jurisprudencia, la estrategia y el texto final antes de usarlo.

La separación entre copiloto y piloto automático resulta especialmente útil aquí: consultar y preparar no concede permiso para presentar, enviar o decidir.

Permisos y guardarraíles que deben existir desde el inicio

El acceso sigue el asunto y el rol. Un agente no recibe visibilidad global solo porque la búsqueda centralizada la haga técnicamente posible. Aplicá mínimo privilegio a repositorio, portal, modelo, logs y personas. Separá credenciales por conector y evitá incluir secretos en prompts o documentos.

Cada salida debe conservar:

1. asunto e identidad usados para la consulta;
2. fuentes y versiones recuperadas;
3. momento de observación;
4. transformación o resumen realizado;
5. nivel de confianza o motivo de excepción;
6. persona que revisó y decisión tomada;
7. resultado de cualquier escritura autorizada.

El sistema se detiene cuando hay identidad ambigua, fuentes contradictorias, documento ilegible, permiso insuficiente, portal no disponible o una decisión que exige criterio jurídico. “No pude comprobarlo” es una salida válida. Completar el hueco con una respuesta plausible no lo es.

Qué no automatizar

No delegues al agente la estrategia procesal, la selección final de argumentos, la comprobación de citas legales, el cómputo definitivo de plazos ni la decisión de presentar o comunicar una actuación. Tampoco debe firmar, enviar a un tribunal, aceptar una notificación en nombre de una persona ni prometer al cliente un resultado sin un flujo expreso, autorizado y revisado.

Una aprobación humana tampoco sirve si la pantalla oculta el contenido ejecutable. La revisión debe enseñar documento, expediente, fuentes, cambios respecto de la versión anterior, destino y acción exacta. El abogado aprueba aquello que realmente ocurrirá, no solo un resumen fluido.

Verificar el día D

Antes de publicar una promesa comercial o activar el piloto, verificá ese mismo día con el despacho y las fuentes oficiales:

• si el portal permite el método de acceso previsto y bajo qué términos;
• qué API, exportación, conector, webhook o notificación existe realmente;
• qué campos, documentos e historial entrega y con qué latencia;
• cómo funcionan identidad, sesiones, MFA, límites y disponibilidad regional;
• qué retención, residencia, cifrado, auditoría y uso de datos ofrecen cada repositorio, proveedor y modelo;
• qué acciones pueden ejecutarse y cuáles solo pueden prepararse para revisión.

Estas capacidades cambian por portal, cuenta, jurisdicción y proveedor. Una observación de discovery o una demo no es evidencia suficiente para publicarlas como función disponible. Si un punto no está confirmado, describilo como requisito de diseño o mantenelo manual.

Después del archivo: jurisprudencia y trabajo corporativo

Una segunda etapa opcional puede vigilar jurisprudencia potencialmente aplicable. Debe conservar tribunal, fecha, identificador, texto fuente y criterio de inclusión. El agente puede señalar una coincidencia para revisar; el abogado decide su vigencia, jerarquía, pertinencia y uso. Una alerta no es una recomendación jurídica.

Contratos y plantillas corporativas pueden incorporarse más adelante como otro dominio, con permisos, taxonomía y aprobadores propios. Mezclarlos desde el primer piloto amplía el alcance antes de demostrar que el núcleo de litigio relaciona expedientes, documentos y próximas actuaciones de forma confiable.

Un piloto que produzca evidencia

Elegí una población pequeña de expedientes activos y medí calidad operativa: coincidencias correctas, duplicados evitados, cambios detectados, excepciones, correcciones humanas, tareas con responsable y tiempo desde observación hasta revisión. No prometas ROI ni autonomía con una demo.

Durante el piloto, compará el índice con el repositorio y la fuente autorizada. Revisá cada borrador. Probá expedientes con nombres parecidos, documentos repetidos, sesiones vencidas, portales sin cambios y resultados ambiguos. La ampliación llega cuando el equipo confía en la evidencia y sabe resolver las excepciones, no cuando el agente produce más texto.

Kiia puede ayudar a convertir este mapa en un piloto con permisos, conectores y revisión profesional. El primer entregable es un expediente operativo que permite encontrar el contexto correcto antes de decidir.