IA aplicada al trabajo jurídico
  • Inicio
  • Acerca de
  1. Inicio
  • Inicio
  • Cómo recorrer este sitio
  • I. Entender el sistema
    • 1. Inteligencia artificial: antes de usarla
    • 2. Modelo, sistema y aplicación
    • 3. La IA como sistema sociotécnico
    • 4. El AI Stack
    • 5. Dependencias
    • 6. Comprar y gobernar IA
  • II. Instruir
    • 1. Qué es un prompt
    • 2. El problema de la ambigüedad
    • 3. Anatomía de un prompt sólido
    • 4. Escalera de complejidad
    • 5. Zero-shot, one-shot y few-shot
    • 6. Trabajar por etapas
    • 7. Salidas estructuradas
    • 8. Meta-prompts
    • 9. Templates
  • III. Saber hacer
    • 1. De una instrucción a una capacidad
    • 2. Qué es una skill
    • 3. Diseñar skills pequeñas
    • 4. Skill no es knowledge
    • 5. Context, knowledge y resources
    • 6. Recuperación de información
    • 7. RAG
    • 8. Caso: skill, estándar y precedentes
  • IV. Poder actuar
    • 1. Del conocimiento a la acción
    • 2. Skill versus tool
    • 3. Qué es una tool
    • 4. Familias de herramientas
    • 5. Tool calling
    • 6. APIs
    • 7. Connectors
    • 8. MCP
    • 9. Permisos
  • V. Organizar
    • 1. De acciones aisladas a procesos
    • 2. Workflow
    • 3. Tipos de workflow
    • 4. Human-in-the-loop
    • 5. Del checklist al playbook
    • 6. Qué contiene un playbook
    • 7. Playbook jurídico
  • VI. Decidir y gobernar
    • 1. De responder a encargarse de una tarea
    • 2. Qué es un agente
    • 3. Qué no es un agente
    • 4. El bucle del agente
    • 5. Anatomía de un agente
    • 6. La escala de autonomía
    • 7. Tipos de agentes por capacidad
    • 8. Agentes por función profesional
    • 9. Agente conversacional
    • 10. Agente de recuperación
    • 11. Agente con herramientas
    • 12. Agente de workflow
    • 13. Agente planificador
    • 14. Sistemas multiagente
    • 15. Patrones de diseño
    • 16. Context engineering
    • 17. RAG, sesión y memoria
    • 18. Permisos y autonomía
    • 19. Workflow versus agent
    • 20. Calidad
    • 21. Observabilidad
    • 22. Riesgos
    • 23. Cuándo NO utilizar un agente
    • 24. Cuándo SÍ considerar un agente
    • 25. Diseñar un agente jurídico
    • 26. Cinco preguntas de control
  • VII. La arquitectura completa
    • 1. Del prompt al sistema
    • 2. Qué aporta cada capa
    • 3. Qué riesgo introduce cada capa
    • 4. Idea final: autonomía como arquitectura

IA aplicada al trabajo jurídico

De comprender un sistema de inteligencia artificial a instruirlo, dotarlo de capacidades, conectarlo con información y herramientas, organizar su trabajo y gobernar formas limitadas de agencia.

Inteligencia artificial aplicada al trabajo jurídico

De los modelos a los agentes

Este sitio desarrolla progresivamente los conceptos necesarios para comprender cómo se construyen, utilizan y gobiernan sistemas de inteligencia artificial aplicados al trabajo jurídico.

El recorrido no está organizado como un catálogo de tecnologías. Cada sección incorpora una capacidad que permite resolver una limitación de la anterior.

Entender → Instruir → Saber hacer → Poder actuar → Organizar → Decidir y gobernar

La pregunta que acompaña todo el recorrido es:

¿Qué capacidad estamos incorporando al sistema, qué problema permite resolver y qué nuevos controles exige?


El recorrido

I. Entender el sistema

Antes de utilizar inteligencia artificial necesitamos distinguir qué estamos utilizando.

Partimos por separar modelo, sistema y aplicación, y luego examinamos las distintas capas que permiten que una herramienta de IA funcione realmente: datos, infraestructura, modelos, adaptación, orquestación, interfaces y mecanismos de gobierno.

Comenzar: Inteligencia artificial antes de usarla →

Conceptos principales: modelo · sistema de IA · aplicación · sistema sociotécnico · AI stack · dependencias · gobernanza


II. Instruir

Tener acceso a un modelo capaz no significa que el modelo sepa qué trabajo queremos realizar.

En esta sección aprendemos a transformar una petición general en una especificación de trabajo: tarea, objetivo, perspectiva, contexto, documentos, evidencia, criterios, restricciones y formato de salida.

El recorrido avanza desde un prompt mínimo hasta prompts maestros, templates, trabajo por etapas y salidas estructuradas.

Continuar: Qué es un prompt →

Conceptos principales: prompt · ambigüedad · contexto · criterios · evidencia · few-shot · structured outputs · meta-prompts · templates


III. Saber hacer

Una buena instrucción todavía depende de que alguien recuerde cómo formularla.

El siguiente paso consiste en transformar metodologías recurrentes en capacidades delimitadas y reutilizables.

Aquí distinguimos además entre saber cómo realizar una tarea y disponer de la información necesaria para realizarla. Esa separación permite introducir skills, knowledge, resources y mecanismos de recuperación como RAG.

Continuar: De una instrucción a una capacidad →

Conceptos principales: skill · knowledge · context · resources · recuperación · RAG


IV. Poder actuar

Hasta este punto el sistema puede recibir instrucciones, aplicar metodologías y trabajar con información.

Pero todavía necesitamos resolver otra limitación:

¿Cómo puede interactuar con información, servicios o sistemas externos?

Esta sección introduce las herramientas que permiten buscar documentos, realizar cálculos, consultar aplicaciones o ejecutar acciones: tools, tool calling, APIs, connectors y MCP.

Continuar: Del conocimiento a la acción →

Conceptos principales: tool · tool calling · API · connector · MCP · permisos


V. Organizar el trabajo

Una tarea profesional rara vez consiste en ejecutar una única acción.

Normalmente existen documentos de entrada, varias etapas, condiciones, responsables, revisiones, excepciones y decisiones.

Los workflows permiten representar esa secuencia. Los playbooks agregan criterios, umbrales, ramas, excepciones y mecanismos de escalamiento.

Continuar: De acciones aisladas a procesos →

Conceptos principales: workflow · estado · condiciones · human-in-the-loop · checklist · playbook · escalamiento


VI. Decidir y gobernar

El último paso consiste en comprender qué cambia cuando el sistema deja de limitarse a ejecutar una ruta completamente predeterminada y puede seleccionar qué paso realizar a continuación dentro de ciertos límites.

Aquí aparecen los agentes de IA.

Un agente no es simplemente un modelo más inteligente. Es una arquitectura de trabajo en la que un modelo puede observar un estado, seleccionar acciones, utilizar herramientas, evaluar resultados y continuar hasta alcanzar un objetivo o requerir intervención humana.

Esta sección desarrolla: agentes · autonomía · planificación · memoria · context engineering · permisos · observabilidad · patrones de diseño · sistemas multiagente


VII. La arquitectura completa

Al final podemos volver a mirar todas las piezas juntas.

Prompt → Template → Skill → Knowledge / RAG → Tool / API / Connector / MCP → Workflow → Playbook → Agent

Cada elemento cumple una función diferente:

Capa Pregunta principal
Prompt ¿Qué quiero que haga ahora?
Template ¿Cómo reutilizo esta instrucción?
Skill ¿Cómo debe saber hacer esta tarea?
Knowledge / RAG ¿Qué información necesita?
Tool ¿Con qué puede interactuar o actuar?
Workflow ¿En qué secuencia debe trabajar?
Playbook ¿Qué criterios, ramas y excepciones aplican?
Agent ¿Cómo selecciona el siguiente paso dentro de sus límites?

Ver la arquitectura completa →


Un caso que crece con el sitio

Para conectar los conceptos utilizaremos recurrentemente un mismo tipo de problema profesional:

Llegó un contrato de un proveedor tecnológico o de inteligencia artificial. Debemos revisarlo y preparar la información necesaria para decidir si puede aprobarse.

El mismo encargo puede resolverse de maneras progresivamente más sofisticadas.

Primero podemos darle una instrucción a un modelo.

Después podemos convertir la metodología de revisión en una skill.

Podemos conectarla con estándares internos y antecedentes mediante knowledge y RAG.

Podemos darle herramientas para localizar documentos, consultar sistemas o registrar resultados.

Podemos organizar esas operaciones dentro de un workflow y codificar criterios institucionales en un playbook.

Finalmente podemos analizar cuándo tendría sentido permitir que un agente seleccione dinámicamente qué acciones ejecutar y cuándo debe solicitar intervención humana.


Una idea para conservar durante todo el recorrido

A medida que incorporamos nuevas capacidades, también introducimos nuevos riesgos y nuevas exigencias de gobierno.

Por eso, una arquitectura de IA aplicada al trabajo jurídico no puede evaluarse solamente preguntando:

¿Qué tan bueno es el modelo?

También necesitamos preguntar:

qué información utiliza · qué puede hacer · qué herramientas puede invocar · qué decisiones puede adoptar · qué queda registrado · cuándo debe detenerse · cuándo debe intervenir una persona


Explorar el sitio

Puedes recorrer el contenido secuencialmente utilizando la navegación lateral o consultar directamente una sección específica.

Comenzar el recorrido →

Acerca de este sitio →

Back to top
Cómo recorrer este sitio