Manual de uso

Guía práctica para sacar el máximo provecho de AltLegal AI: chat, proyectos, adjuntos, casos de uso y herramientas del agente.

Visión general

AltLegal AI es la plataforma interna del estudio para trabajo asistido por IA con acceso al corpus legal chileno (BCN), documentos del cliente y el archivo histórico de causas. Tres conceptos básicos:

• Chat — conversación con el agente. Una sesión es independiente y puede ser libre o anclada a un caso de uso específico.
• Proyecto — un encargo con un cliente. Agrupa sesiones, documentos, entregables y una trayectoria de pasos.
• Caso de uso — receta pre-configurada (prompt + herramientas + restricciones) para tareas recurrentes (ej. redactar política, revisar contrato).

Flujo de trabajo típico

1. Decide el contexto. ¿Es una pregunta puntual? Usa Nuevo chat. ¿Es trabajo continuo con un cliente? Crea o abre un Proyecto.
2. Activa el caso de uso correcto si aplica (ej. pdp-redaccion-politica). Esto carga el prompt y restringe las herramientas a las relevantes.
3. Adjunta los documentos del turno si necesitas que el agente razone sobre material concreto.
4. Conversa. El agente puede invocar herramientas (buscar leyes, anonimizar, generar Doc).
5. Registra el entregable cuando llegues a un draft que quieras conservar (botón "Guardar como entregable" o pidiéndoselo al agente).
6. Aprueba (admin) y exporta a Google Doc para entregar al cliente.

Chat

El chat es la interfaz principal. Cada sesión tiene su propio contexto (mensajes, adjuntos, configuración del modelo) y queda guardada en Historial.

Crear una sesión

Tres formas:

• Nuevo chat en la barra lateral → sesión libre, sin caso de uso ni proyecto. Útil para preguntas puntuales o exploración.
• Casos de uso → seleccionar uno → crea sesión con ese caso de uso activo. El agente recibe el prompt master y solo puede usar las herramientas permitidas.
• Desde un Proyecto → click en un paso de la trayectoria abre o reusa una sesión asociada al paso.

Retomar y marcar como favorito

• Retomar: Historial (en TRABAJO) lista todas tus sesiones agrupadas por cliente / caso. Click para volver al estado exacto.
• Renombrar: ícono de lápiz junto al título cuando estás dentro de la sesión (solo el creador o un admin).
• Favorito: ícono de estrella ⭐ en la cabecera del chat o en el listado del Historial. Aparece luego en Favoritos.
• Eliminar: ícono de basura en el Historial. Si la sesión produjo un entregable aprobado, no se puede eliminar (auditoría).

Asociar una sesión a un proyecto

Las sesiones que creaste con Nuevo chat caen en el grupo Otras sesiones del Historial — sin proyecto, sin cliente. Si después decides agruparlas bajo un proyecto, no necesitas re-crearlas: las puedes asociar post-hoc sin perder mensajes ni adjuntos.

1. Abre la sesión que quieres mover (entrarás a la vista de chat).
2. En la barra superior aparece el botón Asociar a proyecto. Solo se ve cuando la sesión no tiene proyecto asignado.
3. Click → modal con los proyectos genéricos existentes (filtrables por nombre o cliente).
4. Selecciona uno (barra lateral roja confirma la elección) y presiona Asociar.
5. La sesión deja de aparecer en Otras sesiones y queda agrupada bajo el proyecto. El botón Ver proyecto reemplaza al de Asociar.

Vincular una causa judicial (Seguimiento de Causas — PJUD/JPL)

El módulo de Seguimiento de Causas Judiciales del estudio extrae diariamente la información de causas activas desde el Poder Judicial (PJUD) y los Juzgados de Policía Local (JPL). Cuando le preguntas al agente por una causa concreta (ej. "¿cuál fue la última causa fallada para Porsche en JPL Lo Barnechea?") la respuesta incluye los datos canónicos: Rol, Tribunal, Caratulado, Estado, Fallo, Fechas, Cliente, Actuario y Partes. El número de Rol queda como un link clickeable.

1. Click en el Rol (aparece subrayado, color rojo del brand).
2. La sesión se vincula a la causa: cliente_scope, tribunal_scope y un objeto causa_meta con todos los demás campos quedan guardados.
3. El sidebar derecho cambia automáticamente a la variante "Causa judicial" y muestra todos los datos en bloques (Cliente, Rol, Tribunal, Caratulado, Estado, Fallo, Fechas, Actuario, Partes).
4. El Rol queda marcado como vinculado (verde) — clickearlo de nuevo no hace nada hasta que cambies de sesión.

Inyección automática de artefactos al contexto clave

Cuando una sesión de chat está vinculada a un proyecto PDP y al paso correspondiente, los artefactos aprobados que ese paso declara como inputs_requeridos se inyectan automáticamente al system prompt del agente. El abogado no necesita pegar el contexto entre pasos: la ficha del proyecto, la normativa aplicable, los formularios de levantamiento, el informe diagnóstico — todo lo que el paso N+1 necesita está disponible sin re-cargar.

Esto es lo que diferencia trabajar dentro de un proyecto vs en una sesión libre. En un proyecto, abrir el paso 100 (contexto-cliente) ya lleva la ficha-proyecto y la normativa-aplicable aprobadas; abrir el paso 110 (Sección I del informe) lleva además el contexto-cliente; y así sucesivamente.

Sidebar de contexto de sesión

Al lado derecho del chat hay un panel colapsable que muestra todo lo que la app sabe de la sesión actual. Aparece automáticamente al abrir un chat con scope (proyecto, cliente, causa o caso de uso transversal). El estado abierto/cerrado se recuerda por usuario en localStorage.

El contenido cambia según el tipo de sesión (auto-detectado por el backend):

Acciones disponibles desde el sidebar (variante Proyecto PDP):

• Adjuntar un documento de la biblioteca del matter — botón "+ Adjuntar" junto a cada doc disponible. La cinta de chips del input se actualiza al instante.
• Aprobar un borrador — abogados y admins ven el botón "Aprobar" inline; otros perfiles ven el draft pero sin acción.
• Click en un artefacto (aprobado o borrador) — abre la vista del proyecto y despliega el panel de artefactos enfocado.
• Ver proyecto completo — link al final del header.

Modelo en uso (pill + picker)

Junto al indicador de Contexto en la cabecera del chat aparece un pill con el nombre corto del modelo LLM activo (ej. Sonnet 4.6, 2.5 Pro). El pill cambia de color según el estado:

• Gris (neutro) — está corriendo el modelo preferido del caso de uso.
• Rojo (override) — elegiste manualmente un modelo distinto al preferido. Se aplica solo a esta sesión.
• Amarillo (fallback) — el preferido falló (timeout, sin clave, error 5xx) y la cadena cayó al siguiente modelo. La cabecera del pill muestra el motivo en el tooltip.

Click en el pill abre un menú con la cadena de modelos resuelta para el caso de uso. Cada opción incluye:

• El nombre completo del modelo (ej. Claude Sonnet 4.6).
• Una etiqueta de tier — profundo · más lento (high), balanceado (mid), rápido · económico (low).
• El badge "preferido del caso" sobre el modelo configurado como chain[0] en el frontmatter.

Al elegir uno distinto, el override aplica al siguiente turno (y todos los siguientes en esa misma sesión). Para volver al preferido, simplemente vuélvelo a elegir desde el menú: el override se limpia. Cambiar de sesión también lo limpia automáticamente.

Dictado por voz

Junto al botón de enviar (›) hay un botón con ícono de micrófono que permite redactar el mensaje hablando. La transcripción aparece en tiempo real en el cuadro de texto y queda editable: el dictado nunca envía el mensaje por sí solo — tú decides cuándo presionar Enviar.

1. Posiciona el cursor en el cuadro de chat (si ya hay texto, el dictado se concatena al final).
2. Click en el botón micrófono. La primera vez el navegador pedirá permiso para usar el micrófono — concede acceso al sitio.
3. El botón se vuelve rojo y pulsa: estás grabando. Habla con normalidad; las pausas cortas no detienen la captura.
4. A medida que hablas, las palabras aparecen en el textarea (primero como hipótesis tentativas, luego se confirman).
5. Click en el micrófono otra vez para detener. Revisa, corrige lo que haga falta y presiona Enviar.

Compatibilidad de navegador

Si tu navegador no soporta dictado, el botón de micrófono no aparece: la app lo detecta y oculta el botón automáticamente.

Buenas prácticas

• Revisa siempre antes de enviar. El motor STT puede confundir nombres propios, citas legales y siglas (ej. "EIPD", "RUT", "Ley 21.719"). Corrige a mano antes de presionar Enviar.
• Dicta con puntuación implícita. Pausa al final de cada idea para ayudar al motor a colocar puntos y comas. Algunos navegadores aceptan dictado explícito ("punto", "coma", "nueva línea") en español.
• Ambiente silencioso. Ruido de fondo degrada la accuracy considerablemente, sobre todo para términos jurídicos poco comunes.
• Sesiones cortas. Para mensajes largos conviene dictar en tramos de 1-2 minutos: si pierdes red en medio, no se trunca todo.
• Lenguaje técnico. Para artículos y números ("artículo 24 letra b"), conviene dictar y luego ajustar a mano — el formato exacto rara vez sale perfecto.

Errores frecuentes

• "Permiso de micrófono denegado" — click en el ícono del candado de la URL → Microphone → Allow. Recarga la página.
• "No se detectó voz" — el motor cortó por silencio. Vuelve a presionar el micrófono y habla más cerca.
• "Servicio de transcripción no disponible" — estás en Brave/Firefox o sin conexión. Cambia a Chrome o Safari.

Mensajes iniciales y de seguimiento

El primer mensaje sienta el tono. Sé específico sobre contexto, objetivo y formato esperado.

Buenos mensajes iniciales

Estoy preparando una EIPD para Empresa Modelo (sector retail, ~5.000
clientes activos). El tratamiento de riesgo es geolocalización por
fidelización. Ayúdame a identificar los riesgos inherentes y proponer
medidas mitigadoras según Ley 21.719.

Necesito redactar la cláusula de transferencia internacional para la
política de privacidad de un cliente que usa AWS (us-east-1). El cliente
ya nos firmó un acuerdo marco. Devuelve 2 alternativas: una conservadora
y otra estándar.

Buenos mensajes de seguimiento

• Pide concreción: "Reescríbelo en lenguaje plano, máximo 120 palabras."
• Pide alternativas: "Dame una segunda versión más cauta."
• Apunta al output: "Genérame el resultado en formato tabla con columnas Riesgo / Probabilidad / Mitigación."
• Cita fuentes: "Indica el artículo específico de la Ley 21.719 que respalda cada punto."

Anti-patrones

• Demasiado vago: "Ayúdame con privacidad" → el agente preguntará de vuelta. Da contexto mínimo en el primer mensaje.
• Asumir memoria entre sesiones: cada sesión es independiente. Si abres una nueva, no recuerda lo de ayer.
• Pedir demasiado de una vez: "Hazme la política completa, el RAT, la EIPD y el manual" → mejor un paso a la vez.
• Pedirle IDs: nunca le des IDs de documentos al agente, él los descubre por su cuenta. Si necesitas referirte a un doc, di su nombre o adjúntalo.

Pasos multi-turno

Algunos casos de uso producen entregables muy extensos (Sección III de un Informe PDP, por ejemplo). En lugar de pedirle al agente todo de una vez y obtener una respuesta truncada, la plataforma divide el trabajo en sub-turnos automáticos: el agente ejecuta secuencialmente N prompts internos, acumula los outputs y al final emite un solo entregable consolidado.

Visualmente verás aparecer separadores con ▍ Turno N/total entre los bloques. La sesión queda como un solo mensaje del usuario y un solo mensaje del asistente — los sub-turnos no aparecen como entradas separadas en el historial.

• Duración esperada: el paso 130 (Sección III) toma 7–11 minutos. El paso 140 (Sección IV) toma 4–6 minutos. Los pasos single-turn suelen ser instantáneos (segundos) o medianos (1–2 min con multi-search).
• No interrumpas el stream: dejar la pestaña abierta hasta que termine. Si cierras la pestaña a media corrida, los sub-turnos completados quedan en el contexto del agente pero el entregable consolidado se pierde.
• Si necesitas ajustar después de que terminó, pide la corrección como mensaje normal — el agente vuelve a generar el entregable completo, esta vez en single-turn (o repite el multi-turn si así está configurado).

Para entender qué pasos son multi-turno y por qué, mira la guía Consultoría PDP.

Adjuntos

Puedes adjuntar documentos a una sesión para que el agente los considere en su contexto. Hay dos niveles de scope:

Tipos soportados

• PDF — máximo 25 MB. El agente extrae texto y los procesa como contexto.
• DOCX — solo con Gemini. Claude rechaza DOCX (limitación del proveedor); convierte a PDF si necesitas Claude.
• Google Doc nativo — vía "Importar desde Drive". Se preserva el formato nativo.

Token budget

Cada provider tiene un límite de contexto. La pill Contexto en el header del chat muestra cuánto del presupuesto consumen los adjuntos. Si te acercas al límite, el sistema te avisa antes de enviar y puedes desadjuntar lo no esencial.

Proyectos

Un Proyecto (también llamado matter en el código) es un encargo concreto con un cliente. Es el contenedor de todo el trabajo asociado: sesiones de chat, documentos, entregables versionados, y opcionalmente una carpeta Drive.

Diferencia con un chat libre

Carpeta Drive — recomendación

Cada proyecto debe vincularse a una carpeta Drive del estudio. Recomendamos esta organización:

📁 AltLegal — Clientes
   └─ 📁 Empresa Modelo SA
       ├─ 📁 PDP 2026
       │   ├─ 📁 Insumos del cliente   (entrevistas, contratos, políticas)
       │   ├─ 📁 Entregables           (Mapa, RAT, EIPD, Política, Manual)
       │   └─ 📁 Comunicaciones        (correos, actas)
       └─ 📁 Compliance Laboral 2026
           └─ ...

Una carpeta por proyecto, no compartida entre proyectos del mismo cliente. Esto mantiene los entregables auditables y facilita el sync incremental.

Trayectorias y casos de uso

Cada proyecto sigue una trayectoria (hoy: consultoria-pdp-21719, otras vendrán). La trayectoria es una secuencia ordenada de pasos; cada paso ejecuta un caso de uso específico que produce un entregable.

Empty state — proyecto recién creado

Al abrir un proyecto PDP nuevo (sin sesiones con mensajes ni entregables aprobados), aparece un banner sobre el listado de pasos con un CTA al primer paso disponible. Para Consultoría PDP — Ley 21.719 ese paso es siempre el 10 — Onboarding del Cliente, porque es el único sin inputs requeridos previos.

Click en el botón "Iniciar paso 10" abre directamente la sesión del paso, equivalente a clickear el paso "Disponible" en el stepper. El banner desaparece tan pronto como cualquier paso registra actividad (mensaje en sesión o artefacto aprobado). No vuelve a aparecer en el resto de la vida del proyecto.

Ejemplo: proyecto PDP completo

Cliente: Empresa Modelo SA. Encargo: cumplimiento Ley 21.719. Trayectoria de 11 pasos:

Plus tres casos transversales (no parte del flujo lineal): pdp-eipd, pdp-redaccion-politica, pdp-respuesta-brecha, pdp-consulta-normativa. Y para fase post-implementación: pdp-tramitacion-autoridad, pdp-soporte-continuo, pdp-manual-procedimientos-internos.

Iterar un paso (v2, v3…) sin perder la versión anterior

Cuando el primer entregable de un paso no satisface y se quiere generar una versión alternativa sin perder la original, cada paso del stepper en la vista de detalle del proyecto tiene un menú kebab (⋯) con la opción "Iniciar nueva sesión para iterar este paso". Esto crea una sesión adicional asociada al mismo paso, dejando intacta la sesión y los entregables previos.

El service create_artifact auto-bumpea la versión, así que múltiples sesiones del mismo paso producen distintas versiones del mismo entregable (v1, v2, v3…). Útil cuando:

• El primer draft tiene un enfoque que no funciona y se quiere intentar de cero con otra estrategia (sin contaminar la nueva sesión con la conversación anterior).
• Se quiere comparar dos alternativas antes de aprobar (ej. una redacción más conservadora vs. más amplia).
• Se está iterando sobre instrucciones del cliente que llegan en oleadas.

La vista de artefactos del proyecto muestra todas las versiones; aprobar la última es la convención, pero técnicamente cualquier versión puede ser la aprobada.

Crear un proyecto

1. En el menú izquierdo, ir a Proyectos (sección TRABAJO).
2. Click en Nuevo proyecto. Selecciona o crea el cliente, asigna nombre al proyecto, opcional Rol.
3. Una vez creado, vincula la carpeta Drive con el botón Vincular Drive.
4. Click en Sincronizar para indexar los archivos existentes en la carpeta como documentos del proyecto.
5. Empieza la trayectoria desde el paso 10 (siempre disponible inicialmente).

Casos de uso

Un caso de uso es una configuración pre-empaquetada para una tarea recurrente. Define:

• Prompt master — instrucciones detalladas que recibe el agente.
• Herramientas permitidas — whitelist de tools que puede invocar.
• Modelo preferido — Claude / Gemini / auto.
• Posición en una trayectoria — número de paso y outputs/inputs.
• Sugerencias — chips de "primer mensaje" que aparecen al abrir la sesión.

Para qué sirven

Sin un caso de uso, el agente es genérico y necesita que le repitas el contexto cada vez. Con un caso de uso bien definido:

• El agente sabe inmediatamente qué tarea está realizando.
• Solo puede usar las herramientas relevantes (no buscará en causas judiciales si estás haciendo PDP).
• Garantiza consistencia entre proyectos del mismo tipo.
• El editor de prompts permite mejorar el caso de uso una vez y todos los proyectos heredan la mejora.

Vista general

En el menú izquierdo → Casos de uso. Catálogo filtrable por categoría. Cada tarjeta muestra ícono, nombre, descripción corta y el modelo preferido. Click → crea sesión nueva con ese caso activo.

El modelo default para casos PDP analíticos es gemini-2.5-pro con thinking_budget=8192 tokens, configurado en src/permissions/llm_models_manifest.yaml. Esa combinación da el mejor balance entre razonamiento extendido y latencia tolerable para los pasos del informe diagnóstico (Secciones I–IV) y el ensamblado final.

Ejemplo: pdp-redaccion-politica

• Categoría: Protección de Datos
• Paso en trayectoria: transversal (no parte del flujo lineal)
• Inputs requeridos: mapa_datos aprobado del proyecto
• Output: politica_privacidad
• Herramientas permitidas: search_documents, search_laws, acquire_norma, fetch_url, generate_google_doc, submit_artifact
• Sugerencias iniciales: "Redacta la primera sección — Quiénes somos", "Genera la cláusula de cookies", "Lista los derechos del titular según Ley 21.719"

Cuando lo abres, el agente ya sabe que su rol es redactor de políticas conforme a Ley 21.719, tiene acceso al Mapa de Datos del proyecto, y puede generar un Google Doc con el draft. No necesitas explicarle el contexto cada vez.

Ejemplo: prompt-builder (Constructor de Prompts)

• Categoría: Productividad
• Paso en trayectoria: transversal (no parte de ningún flujo)
• Inputs requeridos: ninguno — describes tu necesidad en texto libre
• Output: un prompt copy-paste, listo para pegar en cualquier LLM
• Herramientas permitidas: ninguna (el output es el prompt mismo, no requiere corpus legal ni herramientas)
• Sugerencias iniciales: "Quiero un prompt para resumir contratos largos manteniendo cláusulas clave", "Necesito un prompt para extraer obligaciones de una sentencia judicial", "Dame un prompt para revisar una política de privacidad contra Ley 21.719"

Es una herramienta de meta-productividad: en vez de redactar manualmente un prompt cada vez que quieres usar otro modelo (Claude, GPT, DeepSeek, o el mismo Gemini con un caso distinto), describes la tarea y el constructor te entrega un bloque listo para copiar y pegar. El prompt resultante incluye instrucciones de anonimización si la tarea procesa documentos del cliente, y usa marcadores tipo {{TEXTO_DEL_CONTRATO}} cuando hay que pegar contenido después.

Documentos

La biblioteca de Documentos es compartida entre todo el estudio por default. Cada documento queda disponible para adjuntar a sesiones de chat o referenciar desde proyectos. Si subes algo confidencial, puedes restringir el acceso (ver Compartir).

Estrategia para ser efectivo

1. No subas dos veces el mismo archivo. El sistema deduplica por hash, pero si renombras el PDF, no detecta la duplicación. Antes de subir, busca si ya existe.
2. Asocia al proyecto cuando corresponda. Si subes un documento dentro de una sesión que pertenece a un proyecto, hereda el matter_id automáticamente. Para uploads aislados, edita el documento y asigna el matter manualmente o usa el filtro "Huérfanos" para encontrarlos.
3. Anonimiza antes de procesar PII. Si vas a razonar sobre una entrevista con nombres y RUTs, anonimiza primero (ver herramienta). El documento original queda guardado, el anonimizado es uno nuevo que el agente puede ver sin riesgo.
4. Nombre descriptivo. "Entrevista_Empresa_Modelo_2026-04-15.pdf" es mejor que "doc1.pdf". Facilita la búsqueda y el reconocimiento en el listado.

Evitar duplicar el corpus BCN

Próximamente Una vista Buscar en BCN que te permitirá explorar el corpus oficial sin tener que subirlo. Por ahora, si necesitas ver el texto de una ley, puedes usar el agente: "Muéstrame el texto del art. 14 de la Ley 21.719".

Eliminación

Filtros útiles

• Por proyecto — listar solo los documentos asociados a un matter.
• Huérfanos — documentos sin matter asignado. Útil para limpiar uploads sueltos.
• Por etiqueta — si etiquetaste documentos al subirlos.
• Búsqueda por nombre — autocompleta a medida que escribes.

Compartir un documento (acceso restringido)

Por default todo documento subido es visible para cualquier persona del estudio que tenga sesión iniciada. Para documentos confidenciales puedes restringir el acceso a equipos, perfiles o personas específicas. Hay dos puntos donde configurarlo:

Al subir: el modal de upload pregunta "¿Restringir acceso?" antes de mandar el archivo. Marca el toggle y el doc sube ya restringido (solo tú y admins lo ven inicialmente). Luego completas los equipos/perfiles/personas desde el menú ⋯.

Post-upload (o si quieres cambiar permisos después):

1. En la tabla de Documentos, click en el menú ⋯ de la fila → Compartir…
2. Activa el toggle Restringir acceso.
3. Elige equipos, perfiles (Abogado / Paralegal) y/o personas que tendrán acceso desde los selectores. Cada selección aparece como chip; click en la × del chip para quitar.
4. Click en Guardar. Aparece un badge 🔒 Restringido junto al nombre del documento.

Para dejar de restringir: abre Compartir…, desactiva el toggle, click en Guardar. El documento vuelve a ser visible globalmente y el badge desaparece.

Próximamente Contador "Esto será visible para N personas" que resuelve equipos y perfiles a sus miembros reales antes de guardar.

Permisos visibles en la app

El estudio configuró un sistema de equipos, perfiles y políticas que decide qué puede ver y usar cada persona. Lo que esto significa para ti como usuario final:

• Tu menú lateral puede mostrar menos opciones que las de un colega — los administradores deciden, por equipo, qué secciones se ven (Investigación, Documentos, PDP, etc.).
• Tu catálogo de casos de uso puede tener menos entradas. Si un caso de uso no aparece, es porque tu equipo o tu perfil (abogado / paralegal / sin perfil) no tiene acceso.
• El agente puede negarse a usar herramientas que tu equipo no tiene permitidas. Verás un mensaje claro indicando que la herramienta no está autorizada.
• El agente elige qué modelo LLM usar según el caso de uso + lo que tu equipo / perfil tiene permitido. Cada turno te muestra al final qué modelo respondió (en el evento done; visible en DevTools).

Si crees que te falta acceso a algo que necesitas, contacta a un administrador del estudio (en Configuración → Equipos y permisos puede revisar y ajustar tus políticas, o usar la pestaña Políticas por usuario para depurar exactamente qué tienes y qué no).

Notificaciones nuevo

La app te avisa cuando hay movimiento relevante en tu workspace: sesiones creadas en proyectos que te interesan, artefactos aprobados, archivos compartidos contigo, cambios en equipos a los que perteneces. La campana vive como primera opción en la sección CUENTA del sidebar con un badge accent que cuenta las no-leídas (se muestra 99+ si superas 99).

El polling de no-leídas corre cada 45 segundos en segundo plano. Cuando otra persona dispara un evento que te concierne, el badge se actualiza solo — no necesitas recargar la página. Click en la campana abre la bandeja con todas las notificaciones, las no-leídas resaltadas con fondo accent.

Eventos cubiertos hoy

El sistema cubre tres familias de eventos. La primera familia (matter) solo dispara notificaciones si el proyecto está marcado como favorito (toggle ⭐ en el header del proyecto):

Movimiento en un proyecto favorito

• Sesión creada. Un colega creó una nueva sesión de chat asociada al proyecto. Click en la notificación abre esa sesión.
• Artefacto generado. Un colega produjo un nuevo borrador de entregable (Política, EIPD, Mapa de Datos, etc.). Incluye tipo y versión en el detalle.
• Artefacto aprobado. Un colega aprobó un artefacto. En proyectos PDP esto típicamente equivale a avance de etapa — la trayectoria desbloquea el siguiente paso al aprobar el artefacto que cierra el actual.
• Archivo agregado. Un colega subió un documento al proyecto (vía upload directo o Drive). El detalle muestra el nombre del archivo.
• Archivo anonimizado. Un colega corrió DLP sobre un documento del proyecto. Incluye el modo del pipeline (CLEAN, MINIMAL).

Cambios en equipos

• Te agregaron a un equipo. Un admin te incorporó como miembro. Click abre Configuración para que revises políticas y permisos heredados.
• Te removieron de un equipo. Un admin te quitó del equipo. Los permisos asociados ya no aplican (puede afectar visibilidad de casos de uso, documentos, etc.).

Documentos compartidos

• Te compartieron un documento. Otro usuario restringió un documento y agregó tu usuario, tu equipo o tu perfil al alcance. Click abre la sección Documentos. Las remociones de acceso no notifican — son silenciosas a propósito (consistente con la política de no filtrar información negativa).

Bandeja y marcado masivo

La vista de detalle permite filtrar por Todas o No leídas con el toggle del encabezado. Cada fila tiene un checkbox: seleccionar varias y luego presionar Marcar N como leídas aplica la acción en bloque. El botón Marcar todas como leídas hace lo mismo sobre las no-leídas sin necesidad de seleccionarlas (pide confirmación). Click en el cuerpo de una notificación la marca como leída automáticamente y navega al recurso relacionado (sesión, proyecto, documento, configuración).

El timestamp es relativo en español (hace 5 min, hace 2 h, hace 3 d); pasado un mes la fecha pasa a formato local.

Herramientas del agente

Lo siguiente es la lista completa de herramientas (tools) que el agente puede invocar. La mayoría se activan automáticamente cuando el caso de uso lo permite y el contexto lo requiere; tú no las llamas directamente, pero entender qué hacen te ayuda a redactar mejores prompts.

Búsqueda y referencias

Causas judiciales

Estas tools son para el módulo de Seguimiento de Causas Judiciales (PJUD/JPL) y no se usan en proyectos PDP.

Estado del proyecto y clientes

Producción de entregables PDP

Lifecycle de entregables

Anonimizar (DLP)

Cuándo usarla

• Siempre que vayas a procesar entrevistas, contratos firmados, o cualquier documento con PII real del cliente o sus titulares.
• El LLM nunca debe ver PII directa: la anonimización corre antes del razonamiento, no después.
• Si vas a generar un entregable público o externo, asegúrate que las fuentes de razonamiento estén anonimizadas.

Modos de pipeline

El parámetro pipeline_mode tiene tres valores: MINIMAL, BALANCED y CLEAN. Los detectores son acumulativos: todo lo que se redacta en MINIMAL también se redacta en BALANCED y CLEAN. Default: CLEAN.

Cómo elegir el modo

El modo es una decisión semántica sobre quién leerá el output y qué se le permite saber, no una palanca de costo o velocidad. Los tres tiers usan la misma pipeline y tienen el mismo costo por llamada.

1. ¿El documento anonimizado saldrá de la organización? (regulador, auditor, contraparte, autoridad pública, terceros)
   → CLEAN. Sin excepciones. La narrativa de comparecencia (nacionalidad, estado civil, profesión, fechas, direcciones) se elimina porque el riesgo de re-identificación combinada no es trivial.
2. ¿Lo consumirá un LLM, una pipeline de embeddings, o un agente interno que necesita razonar sobre la estructura del documento sin saber quiénes son las partes?
   → BALANCED. Identidades y canales directos de contacto se redactan, pero la estructura narrativa (fechas, estado civil, profesión, nacionalidad) se preserva para que el modelo pueda razonar sobre tipologías, plazos y roles. Default recomendado para el flujo PDP "asistente de formulario".
3. ¿Quedará dentro del equipo que ya conoce a las partes (el abogado que redactó el documento y su equipo directo), y la redacción solo busca limpiar identificadores y credenciales antes de almacenar o indexar?
   → MINIMAL. Nombres + RUT + tarjetas + cuentas bancarias se redactan; el resto pasa para que el lector humano conserve contexto operacional completo.

Atajos de decisión

Pregunta: "¿Podría este output aparecer en una captura de pantalla pegada en un canal con colaboradores externos?"

Ejemplos concretos (PDP)

• Contrato anonimizado adjunto a un informe regulatorio → CLEAN.
• Contrato anonimizado pasado al agente para redactar resumen cláusula por cláusula → BALANCED.
• Contrato anonimizado guardado en la carpeta del abogado para búsqueda histórica → MINIMAL.

En la duda, usa CLEAN. Elegir un tier más permisivo del que la audiencia justifica es un incidente de sobre-divulgación; elegir uno más estricto del necesario es, en el peor caso, inconveniente.

Idempotencia

Si anonimizas el mismo documento dos veces con el mismo modo, no se procesa de nuevo: el sistema reusa el resultado anterior. Si pides un modo distinto (ej. CLEAN sobre algo ya anonimizado en modo BALANCED), sí lo reprocesa con la nueva configuración.

Adopción de huérfanos

Si subiste el original sin asignar a un proyecto (huérfano), pero luego lo anonimizas desde dentro de una sesión que sí pertenece a un proyecto, el sistema "adopta" automáticamente el matter del original y mueve los archivos a la carpeta correcta del cliente. No tienes que hacer manualmente la asignación.

¿Falta algo o algo está desactualizado? Avisa al equipo de tecnología (tecnologia@altlegal.cl) o abre un ticket en el chat #IA-team.