Chat con tu Despacho: Cómo Crear un Asistente Interno con IA
Un despacho puede tener 20 años de conocimiento acumulado y seguir respondiendo la misma pregunta desde cero cada semana.
El problema no es que falte información.
Es que está repartida entre:
- carpetas;
- emails;
- contratos;
- informes;
- precedentes;
- memorandos;
- SharePoint;
- sistemas documentales;
- y la memoria de determinados abogados.
Un asistente interno con inteligencia artificial intenta resolver precisamente ese problema.
En lugar de preguntar a un chatbot abierto:
“¿Cómo solemos redactar esta cláusula?”
el abogado podría preguntar:
“¿Cómo hemos tratado esta cláusula en nuestros contratos tecnológicos durante los últimos dos años?”
La segunda pregunta exige algo que un modelo generalista no posee: conocimiento privado del despacho.
Para proporcionárselo no siempre es necesario entrenar un modelo propio.
En muchos casos, la arquitectura adecuada es mucho más sencilla: RAG, Retrieval-Augmented Generation.
La diferencia entre un chatbot y un asistente del despacho
Imagina esta pregunta:
¿Cuál es nuestra posición habitual sobre limitación de responsabilidad en contratos SaaS?
Un modelo generalista podría explicar qué es una cláusula de limitación de responsabilidad.
Incluso podría proponer una cláusula razonable.
Pero no sabe necesariamente:
- qué acepta tu despacho;
- qué rechazaron tus clientes;
- qué precedentes están aprobados;
- qué socio autorizó una excepción;
- qué modelo contractual está vigente.
Un asistente interno intenta añadir precisamente ese contexto.
La diferencia puede representarse así:
Chatbot general
Pregunta → modelo → respuesta
Asistente interno
Pregunta → búsqueda interna → documentos relevantes → modelo → respuesta con fuentes
La segunda arquitectura introduce una capa crítica:
recuperación de información.
¿Qué es RAG sin lenguaje técnico?
RAG significa Retrieval-Augmented Generation.
El concepto es más sencillo que el nombre.
Supongamos que preguntas:
¿Qué política seguimos para aceptar jurisdicción extranjera?
El sistema no debería esperar que el modelo «recuerde» la política.
Primero busca dentro de documentos autorizados:
- playbook contractual;
- política interna;
- contratos anteriores;
- memorandos;
- excepciones aprobadas.
Encuentra los fragmentos más relacionados con la pregunta.
Después entrega esos fragmentos al modelo junto con la consulta.
El modelo genera la respuesta utilizando ese contexto.
Por eso, RAG se parece menos a enseñar Derecho al modelo y más a ponerle los documentos correctos sobre la mesa antes de responder.
¿Por qué no simplemente entrenar ChatGPT con todos los documentos?
Porque entrenamiento y recuperación resuelven problemas diferentes.
Supongamos que mañana cambia una política interna.
Con un sistema RAG, podemos sustituir el documento antiguo por la versión nueva.
La siguiente consulta puede recuperar la nueva política.
Si dependemos de conocimiento incorporado mediante entrenamiento, actualizarlo puede ser considerablemente más complejo.
Para información que cambia frecuentemente, RAG tiene una ventaja fundamental:
el conocimiento puede actualizarse sin volver a entrenar el modelo.
El verdadero problema es encontrar el fragmento correcto
Aquí aparece una sorpresa.
Construir el chatbot puede ser relativamente fácil.
Construir un sistema que encuentre el documento correcto, la versión correcta y el párrafo correcto es bastante más difícil.
Imagina que existen cuatro documentos:
- Política de contratos 2024
- Política de contratos 2025
- Política de contratos 2026
- Borrador política contratos 2027
Todos contienen la expresión «limitación de responsabilidad».
Una búsqueda semántica puede recuperar los cuatro.
Pero el asistente debería saber que el documento de 2026 es el vigente.
Esto significa que un buen RAG jurídico necesita algo más que embeddings.
Necesita metadata.
Metadata: la parte aburrida que puede decidir si el sistema funciona
Cada documento puede almacenar información adicional:
Tipo: playbook
Área: contratos tecnológicos
Jurisdicción: España
Estado: aprobado
Versión: 4.2
Fecha: 15/05/2026
Responsable: departamento jurídico
Confidencialidad: interna
Vigente: sí
Ahora una consulta puede buscar:
documentos sobre contratos tecnológicos + España + aprobados + vigentes.
La precisión aumenta antes incluso de preguntar al modelo.
En sistemas jurídicos, esta capa puede ser más importante que cambiar de un modelo de lenguaje a otro ligeramente mejor.
¿Qué es una vector database?
Para entender RAG aparece otro término frecuente: base de datos vectorial.
Una búsqueda tradicional intenta encontrar coincidencias entre palabras.
Una búsqueda semántica intenta encontrar similitud entre significados.
Por ejemplo, un abogado pregunta:
¿Cuándo podemos terminar anticipadamente un contrato?
El documento interno quizá diga:
«Supuestos de resolución antes del vencimiento.»
Las palabras son distintas.
El concepto es parecido.
Los modelos de embeddings convierten fragmentos de texto en representaciones matemáticas —vectores— que permiten medir esa similitud.
Una vector database almacena y recupera esas representaciones.
Entre las tecnologías utilizadas para este tipo de arquitectura se encuentran sistemas como Pinecone, Weaviate y Qdrant, además de bases de datos tradicionales que han incorporado capacidades vectoriales.
Pero elegir la base de datos antes de definir el problema suele ser empezar por el final.
El primer asistente interno no debería saberlo todo
Un error común sería intentar conectar desde el primer día:
«Todos los documentos del despacho.»
Eso introduce ruido, conflictos de permisos y versiones antiguas.
Un primer proyecto más inteligente podría responder únicamente:
preguntas sobre contratos SaaS aprobados.
Corpus inicial:
- playbook vigente;
- 30 cláusulas aprobadas;
- 15 contratos modelo;
- FAQ interna;
- políticas relacionadas.
Eso permite medir precisión.
Después se amplía.
La restricción inicial no es una debilidad.
Es un mecanismo de control.
Caso de uso 1: encontrar precedentes
Un abogado recibe una cláusula poco habitual.
En lugar de preguntar por email:
«¿Alguien ha visto esto antes?»
consulta:
Busca precedentes internos donde aceptamos una cláusula de propiedad intelectual similar.
Devuelve únicamente documentos a los que tengo permiso de acceso.
Para cada resultado indica cliente anonimizado, fecha, tipo de contrato, cláusula relevante y enlace al documento original.
La IA no necesita decidir si la cláusula es aceptable.
Primero resuelve un problema más simple:
¿ya hicimos algo parecido?
Caso de uso 2: consultar el playbook
Pregunta:
El proveedor propone responsabilidad ilimitada por cualquier incumplimiento. ¿Qué dice nuestro playbook?
Una buena respuesta sería:
El playbook establece un límite preferido equivalente a 12 meses de honorarios. La responsabilidad ilimitada requiere escalación, salvo determinadas excepciones relacionadas con [X]. Fuente: Playbook SaaS v4.2, sección 8.3.
Observa lo que hace útil la respuesta:
afirmación + regla + fuente + ubicación.
Sin los dos últimos elementos, tenemos nuevamente un chatbot que habla con confianza.
Caso de uso 3: descubrir conocimiento escondido
Los despachos producen una enorme cantidad de conocimiento que rara vez vuelve a utilizarse.
Un memorando excelente preparado hace cuatro años puede estar perdido en una carpeta de un asunto cerrado.
Un asistente interno puede permitir preguntas como:
¿Hemos analizado anteriormente la aplicabilidad de esta excepción?
Eso puede recuperar:
- memorandos;
- informes;
- opiniones internas;
- research previo.
El ahorro potencial no está en generar nuevo contenido.
Está en evitar pagar dos veces por crear conocimiento que ya existe.
Caso de uso 4: onboarding de abogados
Un abogado nuevo podría preguntar:
¿Cómo se abre un nuevo asunto?
¿Qué aprobación necesito para contratar un perito?
¿Cuál es nuestro proceso para conflictos de interés?
¿Dónde está el modelo actualizado de NDA?
Actualmente, muchas de esas preguntas terminan en otra persona.
Un asistente interno puede convertir políticas y procedimientos en una interfaz conversacional.
Aquí el riesgo jurídico suele ser menor y el resultado es fácil de verificar.
Por eso, onboarding y conocimiento operativo pueden ser mejores proyectos iniciales que asesoramiento jurídico sustantivo.
Caso de uso 5: preparar un asunto sin sustituir la investigación
El asistente también puede funcionar como punto de partida.
Pregunta:
Busca en nuestros memorandos internos todas las ocasiones en que analizamos [CUESTIÓN].
Resume las posiciones adoptadas y muestra las fuentes originales.
No determines cuál sigue siendo jurídicamente correcta.
La última instrucción importa.
Un memorando interno de 2022 puede haber sido excelente en 2022.
Eso no significa que la ley siga igual en 2026.
El asistente recupera conocimiento.
La vigencia jurídica necesita verificarse.
Para investigación actual, puede conectarse con el enfoque explicado en IA para Investigación Jurídica: Vincent AI, GenIA y Alternativas Gratuitas.
La arquitectura mínima
Un asistente RAG puede entenderse como seis capas.
1. Fuentes
Los documentos originales:
- Word;
- PDF;
- email;
- SharePoint;
- Google Drive;
- DMS;
- bases internas.
2. Procesamiento
Los documentos se:
- extraen;
- limpian;
- dividen;
- clasifican;
- enriquecen con metadata.
3. Embeddings
Los fragmentos se convierten en representaciones que permiten búsqueda semántica.
4. Almacenamiento
Los vectores y metadata se guardan en un sistema preparado para recuperación.
5. Retrieval
Cuando llega una pregunta, el sistema busca los fragmentos más relevantes.
6. Generación
El modelo recibe:
pregunta + fragmentos recuperados + instrucciones
y produce una respuesta.
Pero falta una séptima capa.
Para un despacho puede ser la más importante.
7. Permisos
El sistema debe decidir qué información puede recuperar para cada usuario.
El error de seguridad que puede convertir un buen RAG en un desastre
Imagina dos equipos del mismo despacho.
Equipo A representa a una empresa en una adquisición.
Equipo B representa a otra parte en un asunto separado y sujeto a restricciones internas.
Si el asistente indexa todo sin respetar permisos, un abogado podría preguntar inocentemente:
¿Tenemos información sobre Empresa X?
y recuperar documentos que nunca debería ver.
La IA no creó la filtración.
El sistema de retrieval la creó.
Por eso, los controles de acceso deben aplicarse antes de entregar los documentos al modelo.
No basta con escribir en el prompt:
«No muestres información confidencial.»
El modelo no debería recibir información que el usuario no está autorizado a consultar.
«Chinese walls» también deben existir en la búsqueda
Los despachos que utilizan barreras éticas o restricciones por asunto necesitan trasladar esas reglas al sistema de conocimiento.
Eso puede significar filtros por:
- usuario;
- grupo;
- cliente;
- matter;
- departamento;
- nivel de confidencialidad.
La arquitectura correcta sería:
usuario → permisos → búsqueda autorizada → contexto → modelo
y no:
usuario → buscar todo → pedir al modelo que oculte lo prohibido.
La diferencia es fundamental.
¿Qué documentos no deberían entrar automáticamente?
Antes de indexar todo, conviene crear exclusiones.
Por ejemplo:
- documentos sujetos a barreras específicas;
- datos altamente sensibles;
- borradores no aprobados;
- información personal innecesaria;
- documentos cuya licencia no permite determinado uso;
- versiones antiguas sin identificar;
- archivos sin propietario o contexto.
Un corpus más pequeño y limpio puede producir respuestas mejores que millones de páginas desorganizadas.
Garbage in, confident answer out
RAG reduce algunos tipos de alucinación.
No elimina la calidad de los datos como problema.
Si el repositorio contiene:
- políticas contradictorias;
- precedentes antiguos;
- borradores;
- documentos duplicados;
- OCR defectuoso;
la IA puede encontrar precisamente la información equivocada.
Y presentarla de manera muy convincente.
Por eso, antes de preguntar:
«¿Qué modelo utilizaremos?»
conviene preguntar:
«¿Confiamos en nuestro repositorio?»
Chunking: por qué dividir mal un contrato puede cambiar una respuesta
Los sistemas RAG normalmente no envían documentos completos al modelo en cada consulta.
Los dividen en fragmentos o chunks.
Pero los contratos tienen estructura.
Supongamos que una cláusula dice:
El proveedor no será responsable por daños indirectos…
y en el párrafo siguiente:
…excepto en casos de dolo, vulneración de confidencialidad y determinadas obligaciones de propiedad intelectual.
Si el sistema recupera únicamente el primer fragmento, puede responder:
«La responsabilidad por daños indirectos está excluida.»
Ha encontrado texto real.
Pero incompleto.
Por eso, el chunking jurídico debería respetar cuando sea posible:
- cláusulas;
- subsecciones;
- encabezados;
- anexos;
- referencias.
No simplemente cortar cada 500 palabras.
Las citas son una función, no decoración
Un asistente interno debería permitir que el abogado pase de:
respuesta
a:
fragmento
y finalmente:
documento original.
Si responde:
«Nuestro playbook permite 30 días de preaviso.»
debería poder mostrar inmediatamente:
Playbook Comercial v5.1 → Terminación → 7.2.
Esto permite revisar.
También genera un efecto interesante: el usuario aprende cuándo no confiar.
Si la fuente recuperada no parece adecuada, puede detenerse antes de utilizar la respuesta.
Cómo medir si el retrieval funciona
No empieces preguntando a los abogados si «les gusta».
Crea 50 preguntas cuya respuesta ya conoces.
Para cada una registra:
- documento correcto;
- fragmento correcto;
- respuesta esperada.
Después ejecuta el sistema.
Separa dos problemas:
Retrieval failure
El sistema no encontró la información correcta.
Generation failure
Encontró la fuente correcta, pero el modelo interpretó mal el contenido.
Esta separación es esencial.
Cambiar de GPT a otro modelo no arregla necesariamente un sistema que recupera los documentos equivocados.
Una métrica muy útil: Recall@K
Supongamos que para una pregunta existe un documento correcto.
Pedimos al sistema sus cinco fragmentos más relevantes.
Si el fragmento correcto aparece entre esos cinco, tenemos éxito para esa consulta en Recall@5.
Repetimos con 100 preguntas.
Si aparece en 92:
Recall@5 = 92%.
No necesitas convertir el despacho en un laboratorio de machine learning.
Pero una métrica sencilla como esta permite saber si una modificación realmente mejoró el sistema.
Otra prueba más difícil: preguntas sin respuesta
Incluye deliberadamente preguntas cuya respuesta no existe en los documentos.
Por ejemplo:
¿Cuál es nuestra política aprobada para contratos de minería en Bolivia?
si el despacho nunca creó esa política.
La respuesta correcta podría ser:
«No encontré una política aprobada que responda esta pregunta.»
Un asistente que inventa una política plausible ha fallado.
Por eso, una métrica crítica es:
capacidad de abstención.
El mejor asistente interno sabe decir «no sé»
Podemos configurar una regla:
Responde únicamente cuando las fuentes recuperadas sean suficientes.
Si no existe evidencia suficiente, indica claramente que no puedes responder utilizando la documentación disponible.
Nunca completes una política interna utilizando conocimiento general.
Esto no garantiza abstención perfecta.
Pero define el comportamiento deseado.
En un entorno jurídico, una ausencia visible de respuesta puede ser más segura que una respuesta elegante sin fundamento.
¿Qué modelo utilizar?
GPT, Claude, Gemini y otros modelos avanzados pueden formar parte de arquitecturas RAG.
Pero la elección no debería realizarse únicamente con benchmarks públicos.
Prueba tus propias tareas:
- documentos largos;
- español jurídico;
- extracción;
- comparación;
- seguimiento de instrucciones;
- citas;
- coste;
- latencia.
Una diferencia pequeña en calidad del modelo puede importar menos que una diferencia grande en retrieval.
¿Necesitas una vector database desde el primer día?
No necesariamente.
Para un piloto con 100 documentos, muchas plataformas y frameworks actuales ya proporcionan mecanismos de búsqueda y recuperación sin necesidad de construir toda la infraestructura manualmente.
La arquitectura propia empieza a tener más sentido cuando necesitas:
- millones de documentos;
- permisos complejos;
- integraciones internas;
- control de infraestructura;
- filtros avanzados;
- requisitos específicos de seguridad;
- observabilidad detallada.
No construyas una plataforma empresarial para demostrar una hipótesis que puede probarse con 200 documentos.
La alternativa sin código: empezar con un corpus controlado
Para experimentar con el concepto, herramientas que permiten consultar documentos proporcionados por el usuario pueden ayudar a validar casos de uso.
Por ejemplo, NotebookLM permite trabajar sobre fuentes seleccionadas.
No sustituye automáticamente un RAG empresarial con permisos, auditoría y gobernanza.
Pero puede responder una pregunta importante antes de invertir:
¿Nuestros abogados realmente encuentran valor en conversar con este conjunto de conocimiento?
Si la respuesta es no, una arquitectura diez veces más sofisticada probablemente no resuelva el problema.
Privacidad: la pregunta no es solamente «¿entrena con mis datos?»
Esa es una pregunta importante.
No es la única.
También debemos conocer:
- dónde se almacenan;
- cuánto tiempo;
- qué proveedores intervienen;
- qué logs se conservan;
- quién puede acceder;
- qué ocurre con archivos eliminados;
- si existen transferencias internacionales;
- cómo funcionan los backups;
- qué datos llegan al modelo;
- qué datos aparecen en telemetría.
Para proyectos empresariales, los proveedores publican documentación específica sobre tratamiento y controles de datos que debería revisarse durante la evaluación.
El asistente también puede revelar un problema organizativo
Después de lanzar el sistema, analiza las preguntas sin respuesta.
Supongamos que durante un mes aparecen repetidamente:
«¿Cuál es nuestra posición sobre X?»
y el sistema responde:
«No existe una política aprobada.»
Eso no es únicamente un fallo del chatbot.
Es información sobre el despacho.
La IA acaba de descubrir conocimiento que todo el mundo esperaba que existiera, pero nunca fue formalizado.
Este puede ser uno de los efectos más interesantes de un asistente interno.
No solo recupera conocimiento.
También revela dónde no existe.
Conecta el asistente con el playbook contractual
En Revisión de Contratos con IA: Herramientas, Precios y Lo Que Debes Saber vimos por qué los playbooks transforman preferencias jurídicas en reglas reutilizables.
Un asistente interno puede convertir ese playbook en una interfaz:
«¿Podemos aceptar esta cláusula?»
Respuesta:
«La posición preferida es X. El fallback aprobado es Y. Si supera Z, debe escalarse al responsable correspondiente.»
Ahora el conocimiento deja de depender de que alguien recuerde dónde está el PDF.
Un proyecto piloto de cuatro semanas
Semana 1: una sola pregunta
Define un caso de uso.
Ejemplo:
«Encontrar precedentes contractuales aprobados.»
No «crear la IA del despacho».
Semana 2: corpus
Selecciona 100–500 documentos de calidad.
Añade:
- metadata;
- permisos;
- versiones;
- estado.
Semana 3: evaluación
Crea 50 preguntas conocidas y 10 preguntas sin respuesta.
Mide:
- recuperación;
- precisión;
- citas;
- abstención.
Semana 4: abogados reales
Permite que un grupo pequeño lo utilice.
Registra:
- preguntas;
- errores;
- documentos no encontrados;
- respuestas reutilizadas;
- tiempo ahorrado.
Solo después decide si merece ampliarse.
La pregunta final no es «¿qué tan inteligente es nuestro chatbot?»
Una demo impresionante puede responder una pregunta compleja en diez segundos.
Eso no demuestra que el sistema sea útil.
Un asistente jurídico interno debería medirse por preguntas diferentes:
¿Encontró el documento correcto?
¿Respetó los permisos?
¿Utilizó la versión vigente?
¿Mostró la fuente?
¿Se abstuvo cuando no sabía?
¿Redujo el tiempo necesario para llegar a información verificable?
Si las respuestas son positivas, quizá hayas construido algo más valioso que otro chatbot.
Has creado una capa de acceso al conocimiento institucional.
Y para muchos despachos, ese conocimiento acumulado puede ser un activo mucho más difícil de replicar que el propio modelo de inteligencia artificial.
Importante: La implementación de sistemas RAG en entornos jurídicos requiere evaluar confidencialidad, secreto profesional, protección de datos, seguridad, permisos y obligaciones contractuales. No deben incorporarse documentos confidenciales a servicios externos sin verificar previamente que su uso está autorizado y que existen controles adecuados.
