flowchart LR
A["ENTENDER<br/>qué sistema tenemos"]
B["INSTRUIR<br/>qué debe hacer"]
C["SABER HACER<br/>cómo ejecutar bien la tarea"]
D["ACTUAR<br/>cómo obtiene y modifica cosas"]
E["ORGANIZAR<br/>cómo avanza el trabajo"]
F["DECIDIR<br/>cómo selecciona el siguiente paso"]
A --> B
B --> C
C --> D
D --> E
E --> F
Inteligencia artificial aplicada al trabajo jurídico
Cómo pasar de entender un sistema de IA a instruirlo, dotarlo de capacidades, conectarlo con información y herramientas, organizar su trabajo y gobernar formas limitadas de agencia.
Un abogado abre una aplicación de inteligencia artificial, adjunta un contrato y escribe:
“Revísalo y dime si podemos firmarlo.”
Pocos segundos después recibe un texto ordenado, aparentemente razonable y redactado con seguridad. Identifica algunas cláusulas problemáticas, propone cambios e incluso concluye que el contrato podría aprobarse sujeto a determinadas observaciones.
A primera vista, el problema parece resuelto.
Pero para utilizar esa respuesta profesionalmente necesitamos hacer preguntas que ya no son preguntas sobre redacción.
¿Desde qué posición contractual se hizo la revisión? ¿Qué documentos fueron efectivamente considerados? ¿El sistema distingue lo que está escrito en el contrato de aquello que está infiriendo? ¿Conoce los criterios internos de la organización? ¿Puede comprobar si falta un anexo? ¿Puede consultar una política corporativa? ¿Sabe qué materias requieren revisión de privacidad o seguridad? ¿Puede acceder al gestor documental? ¿Puede guardar el informe? ¿Puede enviar una consulta al proveedor? ¿Quién decide qué ocurre después? ¿Qué acciones requieren aprobación? ¿Cómo queda constancia de lo realizado? ¿Quién responde por la decisión final?
La diferencia entre la primera pregunta y todas las siguientes resume el propósito de este sitio.
La inteligencia artificial aplicada al trabajo jurídico no consiste solamente en obtener mejores respuestas de un modelo. A medida que una tarea se vuelve relevante, repetible o integrada en una organización, aparece un problema más amplio: cómo construir alrededor de los modelos sistemas de trabajo que sean útiles, verificables, controlables y gobernables.
Ese desplazamiento organiza todo el recorrido.
Comenzaremos preguntando qué tenemos realmente delante cuando hablamos de un sistema de IA. Después aprenderemos a instruirlo. Veremos cómo una instrucción puede convertirse en una capacidad reutilizable; cómo esa capacidad puede disponer de conocimiento; cómo un sistema puede recuperar información y utilizar herramientas; cómo distintas capacidades pueden ordenarse dentro de procesos; y, finalmente, qué cambia cuando permitimos que el propio sistema seleccione dinámicamente algunas de las acciones necesarias para perseguir un objetivo.
La secuencia puede expresarse de dos maneras complementarias.
Una describe lo que aprendemos a hacer:
Entender → Instruir → Saber hacer → Actuar → Organizar → Decidir
La otra muestra algunas de las piezas que iremos incorporando:
Prompt → Template → Skill → Knowledge/RAG → Tool/API/Connector/MCP → Workflow → Playbook → Agent
Ninguna de las dos debe leerse como una taxonomía universal de la industria. Son mapas pedagógicos. Su función es permitirnos construir complejidad sin introducir todas las abstracciones al mismo tiempo.
La idea que organiza todo el handbook
Cada nuevo concepto aparecerá porque el sistema anterior deja un problema sin resolver.
No estudiaremos skill, RAG, API, MCP, workflow, playbook o agent como palabras que deban memorizarse.
Preguntaremos, en cambio:
¿qué necesitamos añadir ahora al sistema para poder hacer algo que antes todavía dependía del usuario?
Qué es este sitio
Este sitio es un handbook docente navegable sobre inteligencia artificial aplicada al trabajo jurídico.
Está pensado principalmente para abogados, estudiantes de Derecho y profesionales que trabajan en áreas como compliance, contratación, privacidad, políticas públicas, regulación, litigación, investigación jurídica o gestión corporativa. No presupone conocimientos de programación ni experiencia previa diseñando sistemas de inteligencia artificial.
Eso no significa reducir los conceptos técnicos hasta volverlos imprecisos.
El propósito es distinto: construir gradualmente un modelo mental suficientemente exacto para que una persona no técnica pueda comprender qué ocurre dentro de estas aplicaciones, distinguir componentes que suelen confundirse y formular las preguntas correctas cuando deba utilizarlas, evaluarlas, contratarlas o gobernarlas.
Una persona puede utilizar satisfactoriamente un automóvil sin saber fabricar un motor. Pero si debe comprar una flota, negociar garantías, determinar responsabilidades por fallas o decidir qué mantenimiento necesita, requiere un nivel de comprensión distinto del usuario ocasional.
Con los sistemas de inteligencia artificial ocurre algo parecido.
Para utilizar ocasionalmente una interfaz conversacional puede bastar con aprender a formular mejores instrucciones. Para introducir esa tecnología en trabajo profesional aparecen cuestiones adicionales: qué sistema se está utilizando, qué datos procesa, de qué proveedores depende, qué información puede consultar, qué acciones puede ejecutar, qué procedimiento sigue, qué evidencia conserva, qué controles existen y qué decisiones permanecen reservadas a personas.
Este handbook se ocupa de ese segundo nivel.
No es un manual de una herramienta
Las interfaces cambian con rapidez.
Un proveedor puede llamar skill a una funcionalidad que otro denomina de otra manera. Una aplicación puede incorporar memoria, búsqueda, herramientas o automatizaciones mediante botones específicos que desaparezcan o cambien de nombre meses después. Incluso términos técnicamente importantes como agent pueden emplearse con alcances diferentes entre literatura académica, documentación de proveedores y productos comerciales.
Por eso no organizaremos el aprendizaje alrededor de una interfaz particular.
Cuando sea útil examinar una implementación concreta, distinguiremos entre dos niveles:
el concepto, relativamente estable, y la implementación, dependiente de un producto, proveedor o versión.
Aprender qué es una API resulta más duradero que memorizar dónde se encuentra determinado botón para crear una integración. Comprender qué función cumple la recuperación de información es más útil que asociar RAG a un producto específico. Entender la diferencia entre seguir una secuencia predefinida y seleccionar dinámicamente el siguiente paso sigue siendo útil aunque cambien las plataformas que permiten construir workflows o agentes.
El sitio intenta, por tanto, enseñar una arquitectura conceptual suficientemente estable como para sobrevivir a las interfaces.
Tampoco es solamente un curso de prompting
Los prompts ocuparán una parte importante del recorrido porque constituyen una de las formas principales de especificar qué queremos que haga un modelo.
Pero constituyen solamente una parte del problema.
Un prompt puede describir con gran precisión cómo revisar un contrato y seguir dependiendo de que una persona:
- vuelva a utilizar la instrucción correcta;
- entregue los documentos necesarios;
- busque la información pertinente;
- abra otros sistemas;
- ejecute acciones externas;
- decida qué etapa corresponde después;
- detecte excepciones;
- obtenga autorizaciones;
- conserve evidencia sobre el proceso.
La clase que sirve de base a esta arquitectura formula precisamente ese cambio de perspectiva: el prompt avanzado funciona, pero empieza a revelar carencias de sistema.
Por eso el recorrido continúa después del prompting.
No porque el prompt deje de importar, sino porque una buena instrucción necesita integrarse progresivamente con metodología, conocimiento, recuperación, herramientas, procesos y controles.
No es un proyecto para “automatizar al abogado”
Existe otra frontera importante.
La finalidad de este handbook no es reconstruir un supuesto “abogado artificial” que reciba asuntos y sustituya íntegramente la actividad profesional.
La arquitectura del curso sigue una estrategia prácticamente opuesta: identificar capacidades pequeñas, delimitadas, evaluables, reutilizables y combinables. Las clases utilizan ejemplos como extraer cláusulas, comparar versiones, detectar materias de privacidad, evaluar una cláusula de responsabilidad o formular preguntas faltantes precisamente porque esas tareas pueden definirse y controlarse con mayor claridad que la instrucción genérica “actúa como abogado”.
Esta decisión de diseño tiene consecuencias importantes.
Una capacidad delimitada puede evaluarse con mayor precisión. Puede modificarse sin rehacer todo el sistema. Puede tener permisos diferentes de otras capacidades. Permite registrar qué componente produjo determinado hallazgo. Y, sobre todo, permite reservar explícitamente determinados juicios y decisiones a personas.
El objetivo no es maximizar autonomía.
El objetivo es determinar qué grado de capacidad, coordinación y autonomía resulta adecuado para cada tarea.
Una regla que aparecerá muchas veces
Más autonomía no equivale automáticamente a mejor tecnología.
Un prompt bien diseñado puede ser suficiente para una tarea ocasional.
Una skill puede ser mejor para una metodología estable.
Un workflow puede ser preferible cuando el orden del trabajo debe permanecer predefinido.
Un agente solo añade valor cuando existe una razón para permitir que el sistema seleccione dinámicamente acciones o próximos pasos.
La arquitectura correcta es la mínima arquitectura suficiente para resolver bien el problema.
Por qué este recorrido importa para el Derecho
La relación entre Derecho y tecnología no comenzó con los modelos generativos.
La informática jurídica lleva décadas trabajando sobre cuestiones como representación de información jurídica, búsqueda documental, automatización de documentos, sistemas de apoyo a decisiones, gestión de procesos, análisis contractual, due diligence, compliance, investigación jurídica y resolución de disputas. Legal Informatics, por ejemplo, organiza buena parte del campo combinando fundamentos técnicos, procesos de trabajo y casos jurídicos concretos.
Los modelos fundacionales y los LLM han modificado significativamente las posibilidades técnicas de esas tareas. Permiten utilizar lenguaje natural como interfaz, producir salidas abiertas y adaptar capacidades mediante instrucciones y contexto sin necesariamente entrenar un modelo desde cero. Pero esa flexibilidad también hace que la construcción de aplicaciones sea un problema diferente de simplemente disponer de un modelo potente.
Chip Huyen distingue precisamente entre el desarrollo del modelo y la construcción de aplicaciones alrededor de modelos disponibles: en la capa de aplicación aparecen instrucciones, contexto, interfaces y evaluación, mientras que infraestructura y desarrollo del modelo continúan siendo componentes diferentes del stack.
Para un profesional del Derecho esta diferencia resulta especialmente relevante.
Una respuesta jurídicamente incorrecta puede provenir del modelo, pero también de haber recuperado el documento equivocado. Una filtración de información puede depender de la configuración del servicio y no de la generación lingüística. Una revisión contractual puede fallar porque el sistema no recibió el anexo correcto. Una recomendación correcta puede ser inutilizable si no puede reconstruirse qué fuentes la respaldaron. Una aplicación puede utilizar un modelo excelente y, al mismo tiempo, integrar mal los permisos, las actualizaciones o la supervisión humana.
Por eso las preguntas jurídicas y las preguntas técnicas no pueden mantenerse completamente separadas.
La revisión profesional de sistemas de IA exige aprender a reconocer dónde ocurre cada cosa.
Ese conocimiento permite preguntar, por ejemplo, no simplemente “¿es segura esta IA?”, sino qué información recibe, dónde se procesa, qué otros servicios intervienen, qué permisos posee, qué registros conserva y qué ocurre cuando cambia un componente.
Permite preguntar no simplemente “¿qué tan preciso es el modelo?”, sino preciso para qué tarea, respecto de qué criterio, sobre qué documentos, en qué jurisdicción y con qué consecuencias cuando se equivoca.
Permite preguntar no simplemente “¿el agente puede enviar correos?”, sino bajo qué identidad, con qué autorización, a qué destinatarios, respecto de qué materias, dejando qué trazabilidad y con qué mecanismo para impedir determinadas acciones.
Las guías profesionales contemporáneas sobre IA generativa reflejan precisamente esta necesidad de comprender capacidades y limitaciones, proteger información, revisar outputs y conservar la responsabilidad profesional. La ABA, por ejemplo, señala que la competencia exigible no requiere que cada abogado se convierta en experto en IA generativa, pero sí una comprensión razonable de las capacidades y riesgos de las herramientas empleadas.
El objetivo de este handbook puede formularse entonces con cierta precisión:
adquirir suficiente alfabetización técnica para formular mejores decisiones jurídicas, profesionales, organizacionales y contractuales sobre sistemas de IA.
Cómo utilizar este sitio
La estructura del sitio permite dos formas distintas de lectura, pero no son igualmente recomendables para quien comienza desde cero.
La primera lectura debería ser secuencial.
La razón no es editorial, sino conceptual. Las páginas posteriores presuponen distinciones ganadas anteriormente. Cuando lleguemos a una API, por ejemplo, no volveremos a explicar desde cero la diferencia entre modelo, sistema y aplicación. Cuando lleguemos a RAG, podremos utilizar el concepto de contexto ya introducido. Cuando lleguemos a agentes, las páginas supondrán que el lector comprende qué son herramientas, workflows, estado, permisos y recuperación.
Una lectura fragmentaria desde el comienzo obligaría a introducir todas esas nociones dentro de cada página y destruiría justamente la progresión que este sitio intenta construir.
Después de esa primera lectura, el handbook puede utilizarse como documentación de consulta.
Si aparece el término MCP durante una evaluación de proveedor, puede regresarse a esa página. Si una organización está diseñando un flujo de revisión contractual, puede consultarse workflow y playbook. Si un equipo discute qué significa que determinado producto tenga “memoria”, será posible volver a las distinciones correspondientes sin reconstruir todo el curso.
La regla del concepto ganado
Existe una mecánica pedagógica que conviene reconocer desde el comienzo.
Cada concepto principal seguirá aproximadamente el mismo razonamiento:
| Momento | Pregunta |
|---|---|
| Estado actual | ¿Qué podemos hacer hasta ahora? |
| Limitación | ¿Qué problema todavía no podemos resolver? |
| Nueva pieza | ¿Qué concepto necesitamos incorporar? |
| Cambio | ¿Qué permite hacer que antes no podíamos? |
| Aplicación | ¿Cómo se manifiesta en una tarea jurídica concreta? |
| Frontera | ¿Qué no debemos confundir con este concepto? |
| Problema abierto | ¿Qué limitación permanece y obliga a avanzar? |
Las clases denominan esta estructura “regla del concepto ganado”: un concepto solo aparece cuando el sistema lo necesita.
Este mecanismo explica por qué algunas páginas terminarán dejando deliberadamente una dificultad sin resolver.
No se trata de una omisión.
La limitación pendiente es precisamente el puente hacia el siguiente concepto.
Si acabamos de aprender a construir una metodología reutilizable, por ejemplo, puede quedar pendiente cómo darle acceso a información que cambia entre asuntos. Cuando resolvamos la disponibilidad de información, aparecerá el problema de localizar únicamente la parte pertinente. Cuando podamos obtener información, descubriremos que obtenerla no es lo mismo que actuar sobre otro sistema.
El sitio avanzará mediante esos pequeños desplazamientos.
Qué hacer cuando aparezca vocabulario técnico
No es necesario memorizar cada palabra en la primera lectura.
Resulta más útil poder contestar tres preguntas:
¿qué problema resuelve este concepto?
¿en qué se diferencia de lo que ya teníamos?
¿qué problema todavía deja abierto?
Si esas tres preguntas pueden contestarse, el término técnico deja de ser una etiqueta y empieza a integrarse en un modelo mental.
Por la misma razón, una definición no será normalmente el comienzo de una página.
Primero intentaremos mostrar el problema que obliga a necesitar la nueva abstracción. Después construiremos una intuición. Solo entonces introduciremos la definición técnica, sus componentes, sus fronteras y sus consecuencias.
No necesitas programar, pero sí aprender a leer sistemas
Algunas páginas mostrarán fragmentos de JSON, llamadas a APIs, estructuras de datos o diagramas de procesos.
Su función no será convertir al lector en programador.
Se utilizarán cuando observar la estructura técnica permita comprender una cuestión que de otro modo permanecería invisible.
Ver una petición y una respuesta de una API, por ejemplo, puede ayudar a entender qué información sale de un sistema y qué recibe a cambio. Observar un JSON puede mostrar por qué una salida estructurada facilita procesamiento posterior. Examinar un diagrama de workflow puede hacer visible qué etapas dependen de otras y dónde existe una aprobación humana.
Siempre distinguiremos entre comprender un mecanismo y saber implementarlo profesionalmente.
El primer objetivo forma parte de este sitio.
El segundo puede requerir conocimientos y roles técnicos adicionales.
Mapa general del curso
El curso puede entenderse como seis grandes movimientos.
Cada movimiento modifica una pregunta.
Entender
Antes de pedirle algo a una tecnología necesitamos saber qué tecnología estamos observando.
La palabra “IA” es demasiado amplia para realizar análisis técnico o jurídico serio. Las clases parten de una distinción que luego desarrollaremos detenidamente: modelo, sistema y aplicación son objetos diferentes. El producto visible puede combinar modelo, datos, infraestructura, interfaz, controles, integraciones y procesos humanos.
En esta primera etapa aprenderemos a mirar detrás de la interfaz.
No para reconstruir todos los detalles de ingeniería, sino para poder localizar dependencias, actores, datos, controles y riesgos.
La pregunta deja de ser:
“¿Qué IA estamos usando?”
y comienza a transformarse en:
“¿Qué sistema opera realmente para producir esta funcionalidad?”
Ese desplazamiento resulta crucial cuando compramos tecnología. Las clases sintetizan la idea señalando que no se contrata “inteligencia artificial” como un objeto simple, sino una combinación de software, modelos, datos, infraestructura, interfaces, documentación, soporte, cambios y controles.
Lo que todavía no podemos hacer al terminar esta etapa: haber entendido el sistema no significa saber especificar correctamente una tarea para él.
Ahí comienza el segundo movimiento.
Instruir
Una vez que sabemos con qué clase de sistema estamos interactuando podemos preguntarnos cómo comunicar correctamente el trabajo que necesitamos.
El problema inicial será la ambigüedad.
Una petición como “revisa este contrato” deja muchas decisiones implícitas. El sistema debe inferir qué significa revisar, desde qué perspectiva, qué cuestiones priorizar, qué evidencia utilizar, qué constituye un riesgo y cómo entregar el resultado.
El prompting permite reducir parte de esa indeterminación.
El aprendizaje irá desde instrucciones mínimas hacia especificaciones de trabajo más completas: tarea, objetivo, contexto, evidencia, criterios, restricciones, ejemplos y formato de salida.
Pero existe un límite importante.
Incluso un prompt avanzado que diga:
“Revisa este contrato desde la posición del cliente, identifica desviaciones, clasifica riesgos, cita evidencia y produce una matriz”
continúa dependiendo de que alguien recuerde esa metodología, introduzca la información correcta y coordine lo que ocurrirá después. Esa es precisamente la frontera identificada en las clases.
Lo que todavía no podemos hacer: convertir automáticamente una buena instrucción puntual en una capacidad estable y reutilizable.
Ese será el siguiente paso.
Saber hacer
Aquí aparece un cambio cualitativo.
Ya no preguntamos solamente:
“¿Qué quiero que haga ahora?”
sino:
“¿Cómo represento de manera estable la forma correcta de realizar esta clase de tareas?”
Surgen entonces nociones como template, skill, knowledge y resources.
Más adelante distinguiremos cuidadosamente cada una. Por ahora basta observar la transformación.
La metodología puede dejar de depender de que un usuario reconstruya la instrucción en cada asunto. Además, comenzaremos a separar dos cosas que suelen mezclarse:
saber cómo realizar una tarea y disponer de la información necesaria para realizarla.
Un sistema puede conocer perfectamente el método para revisar limitaciones de responsabilidad y no disponer del playbook contractual de la organización.
Puede saber cómo comparar dos textos y no tener acceso a la versión anterior del contrato.
Puede saber qué campos debe extraer y no tener el documento desde el cual extraerlos.
Por eso aparecerá también el problema de knowledge y, posteriormente, el de recuperar selectivamente información mediante RAG.
Lo que todavía no podemos hacer: disponer de una metodología y de conocimiento no significa tener capacidad para interactuar con el mundo exterior.
El sistema puede saber qué necesita, pero todavía alguien puede tener que conseguirlo o ejecutar la acción.
Ahí comienza el nivel de actuación.
Actuar
Hasta este punto hemos trabajado principalmente con información disponible dentro de la interacción o incorporada al sistema.
Pero el trabajo profesional ocurre en entornos más amplios.
Los contratos están en gestores documentales. Las políticas pueden residir en SharePoint. La información de clientes puede encontrarse en sistemas corporativos. Los estados de aprobación pueden estar en plataformas de gestión. Determinados cálculos pueden requerir programas especializados. Una tarea puede necesitar enviar o recibir información mediante otros servicios.
Aquí aparecen tools, APIs, connectors y MCP.
La pregunta cambia nuevamente:
“¿Cómo puede el sistema obtener información, ejecutar una función o producir un efecto fuera de la generación de texto?”
La diferencia es especialmente importante porque comenzar a actuar introduce una dimensión que antes podía mantenerse en segundo plano: los permisos.
Leer un documento no tiene el mismo impacto que modificarlo.
Preparar un borrador no equivale a enviarlo.
Consultar un registro no equivale a cambiarlo.
El hecho de que una integración permita técnicamente realizar una acción no determina si el sistema debe estar autorizado a ejecutarla.
Lo que todavía no podemos hacer: tener múltiples capacidades y herramientas no nos dice por sí mismo en qué orden deben utilizarse ni quién coordina el trabajo.
Necesitamos organización.
Organizar
Supongamos que ya contamos con una metodología de revisión, documentos, conocimiento recuperable y herramientas.
Todavía queda una pregunta elemental:
¿qué ocurre primero, qué ocurre después y bajo qué condiciones avanza el asunto?
El trabajo jurídico profesional está lleno de estados y transiciones.
Un contrato puede recibirse, clasificarse, asignarse, analizarse, enviarse a otra especialidad, devolverse por antecedentes faltantes, escalarse por riesgo, aprobarse sujeto a condiciones y finalmente registrarse.
No basta con poseer las capacidades necesarias. Debemos ordenarlas.
Aquí aparecen workflow y playbook.
El primero permitirá representar secuencias, estados y condiciones de avance. El segundo incorporará criterios, ramas, excepciones y reglas de escalamiento. Las clases resumen la diferencia de manera útil: una skill responde cómo hacer bien una tarea; un workflow, en qué orden ocurre el trabajo; y un playbook, qué estrategia o ruta corresponde según el caso.
Lo que todavía no podemos hacer: un proceso puede estar automatizado y, sin embargo, seguir una ruta completamente determinada de antemano.
La automatización no implica todavía que el sistema pueda decidir contextualmente qué paso corresponde.
Esa será la frontera final.
Decidir
El último movimiento introduce la forma de agencia que estudiaremos en este handbook.
Una de las ideas centrales de la clase final es que un agente no debe entenderse simplemente como “un modelo más inteligente”. Describe una arquitectura de trabajo diferente: un modelo opera dentro de un ciclo en el que observa un estado, selecciona un próximo paso, utiliza recursos, examina el resultado y decide cómo continuar dentro de determinados límites.
La diferencia fundamental ya no consiste solamente en ejecutar una tarea, sino en poder seleccionar dinámicamente entre acciones permitidas.
Esto no elimina los elementos anteriores.
Un agente puede depender de prompts, skills, knowledge, RAG, tools, workflows y playbooks. De hecho, la arquitectura final de las clases enfatiza exactamente esa acumulación: la autonomía no surge del modelo aislado, sino de una combinación gobernada de capacidades, conocimiento, herramientas, procesos, permisos y criterios de cierre.
Tampoco elimina el gobierno.
Cuanto mayor sea la capacidad de decidir y actuar, mayor importancia adquieren preguntas sobre identidad, permisos, trazabilidad, revisión, límites y condiciones de detención.
Por eso la última etapa no es simplemente “autonomía”.
Es decisión dentro de una arquitectura gobernada.
De prompts a agentes
El mapa anterior describe el recorrido desde la perspectiva del aprendizaje.
Podemos observarlo ahora desde una segunda perspectiva: qué pieza gana el sistema en cada etapa.
flowchart TB
P["PROMPT<br/>instrucción"]
T["TEMPLATE<br/>reutilización"]
S["SKILL<br/>metodología"]
K["KNOWLEDGE / RAG<br/>información pertinente"]
X["TOOL / API / CONNECTOR / MCP<br/>acceso y acción"]
W["WORKFLOW<br/>secuencia y estados"]
PB["PLAYBOOK<br/>criterios y ramas"]
A["AGENT<br/>selección dinámica de acciones"]
P --> T
T --> S
S --> K
K --> X
X --> W
W --> PB
PB --> A
El diagrama parece una sucesión de términos.
No debe leerse de esa manera.
Cada flecha representa un problema nuevo.
Prompt → Template
Un prompt permite entregar una instrucción.
El problema aparece cuando una buena instrucción debe utilizarse una y otra vez.
No queremos reconstruir manualmente cada elemento cada vez que llega un nuevo contrato.
Un template permite conservar una estructura y variar determinados datos.
El cambio principal es reutilización.
Pero una instrucción parametrizable todavía no necesariamente constituye una metodología completa.
Template → Skill
Una skill representa, dentro del modelo pedagógico del curso, una capacidad o metodología delimitada y reutilizable.
El cambio ya no consiste solamente en rellenar variables.
Consiste en estabilizar cómo debe realizarse correctamente una tarea.
Por ejemplo, no simplemente:
“analiza esta cláusula”
sino una metodología reutilizable para revisar cláusulas de limitación de responsabilidad desde una determinada posición, identificar excepciones, contrastar criterios y producir determinados hallazgos.
El cambio principal es saber hacer.
Pero saber hacer no significa disponer de toda la información que cada caso necesita.
Skill → Knowledge
Una metodología puede estar perfectamente definida y carecer de los materiales que debe aplicar.
Aquí debemos separar:
cómo trabajo
de
con qué información trabajo.
Las políticas internas, contratos anteriores, criterios de negociación, manuales, legislación, jurisprudencia o documentos del expediente pertenecen al segundo problema.
El cambio principal es disponibilidad de conocimiento.
Pero disponer de una biblioteca no garantiza que toda ella pueda colocarse frente al modelo en cada interacción.
Knowledge → RAG
Cuando la información relevante supera lo que conviene entregar directamente, surge el problema de localizar e incorporar solamente aquello que resulta pertinente para la tarea concreta.
RAG resolverá una parte de ese problema mediante recuperación.
Todavía no desarrollaremos aquí embeddings, chunking, ranking ni bases vectoriales. Corresponden a las páginas específicas.
En este mapa inicial basta con reconocer el delta:
knowledge responde principalmente a qué información existe para trabajar.
RAG introduce un mecanismo para localizar e incorporar información pertinente cuando se necesita.
El cambio principal es recuperación contextual.
Pero recuperar información sigue siendo distinto de ejecutar acciones.
RAG → Tool
Un sistema puede encontrar una política y continuar siendo incapaz de abrir un expediente corporativo, realizar un cálculo externo, crear un registro o interactuar con otro servicio.
Una tool amplía lo que el sistema puede hacer más allá de generar texto.
Puede proporcionar información, ejecutar una función o producir un efecto.
El cambio principal es capacidad externa.
Pero una herramienta necesita alguna forma de conexión.
Tool → API → Connector → MCP
Estas piezas se encuentran próximas, pero no son equivalentes.
Una tool expresa una capacidad que el sistema puede utilizar.
Una API constituye una interfaz mediante la cual sistemas de software pueden comunicarse de manera definida.
Un connector empaqueta o facilita una integración concreta.
MCP introduce un protocolo estandarizado para determinados tipos de interacción entre aplicaciones de IA y recursos externos.
Cada concepto tendrá su propia página porque comprimirlos ahora produciría precisamente el tipo de salto técnico que este sitio intenta evitar.
En el mapa general cumplen una función común:
hacer posible que una aplicación deje de operar únicamente sobre el texto inmediatamente disponible y pueda relacionarse controladamente con otros recursos o sistemas.
El cambio principal es conectividad y acción.
Pero conectar diez herramientas no determina cómo deben combinarse.
Tools → Workflow
Aquí aparece la necesidad de orden.
Un workflow fija una secuencia de actividades, estados y condiciones de avance.
La coordinación ya no depende necesariamente de que una persona recuerde cada paso.
El cambio principal es orquestación de una ruta conocida.
Pero algunos asuntos no siguen una única ruta.
Workflow → Playbook
Un playbook incorpora algo adicional: criterios para escoger ramas, tratar excepciones y escalar determinados asuntos.
Si el contrato implica datos personales, puede requerir una revisión específica.
Si existe un subprocesador crítico, puede activarse una ruta adicional.
Si una cláusula supera determinado nivel de riesgo, puede exigirse autorización de una persona distinta.
El cambio principal es estrategia procedimental.
Pero incluso un playbook puede dejar todas sus ramas completamente predefinidas.
Playbook → Agent
Finalmente aparece la pregunta:
¿puede el sistema seleccionar dinámicamente qué acción permitida corresponde realizar a continuación atendiendo al objetivo, al contexto y al resultado del paso anterior?
Aquí comienza la agencia en el sentido utilizado por este curso.
Google describe actualmente una arquitectura de agentes que combina modelo, herramientas, una capa de orquestación y servicios de ejecución, usando el modelo dentro de un ciclo orientado a un objetivo.
Las clases utilizan una formulación deliberadamente sencilla para abogados: un agente es una aplicación que utiliza un modelo de IA en un ciclo para perseguir un objetivo, disponiendo de contexto, medios y controles.
El cambio principal es selección dinámica del siguiente paso.
Y allí aparece inmediatamente una última pregunta:
¿qué está autorizado a decidir?
Por eso el recorrido termina necesariamente en gobierno.
La escalera es pedagógica, no ontológica
Conviene detenerse aquí porque esta es una fuente frecuente de confusión.
El diagrama anterior no afirma que todos los sistemas reales contengan ocho cajas independientes denominadas exactamente prompt, template, skill, knowledge, RAG, tool, workflow, playbook y agent.
Tampoco afirma que deba construirse primero una y luego otra técnicamente.
En un producto concreto varias funciones pueden superponerse.
Una plataforma puede llamar agent a algo que en nuestro esquema se parece más a un workflow con herramientas. Otra puede utilizar skill para denominar una integración. Algunas aplicaciones pueden ocultar completamente los mecanismos de recuperación. Un framework puede tratar herramientas y conectores mediante una abstracción unificada.
No intentaremos resolver esta diversidad escogiendo arbitrariamente al proveedor cuya terminología deba considerarse “correcta”.
Haremos otra cosa.
Utilizaremos categorías estables para distinguir funciones.
La pregunta será siempre qué problema está resolviendo la pieza:
| Función | Pregunta |
|---|---|
| Instrucción | ¿Qué debe hacer? |
| Reutilización | ¿Cómo evitamos reconstruir la misma instrucción? |
| Metodología | ¿Cómo se ejecuta correctamente esta tarea? |
| Información | ¿Con qué conocimiento debe trabajar? |
| Recuperación | ¿Cómo encuentra la información pertinente? |
| Actuación | ¿Qué puede consultar, calcular, crear o modificar? |
| Proceso | ¿Cómo se ordenan las etapas? |
| Estrategia | ¿Qué ruta corresponde según el caso? |
| Agencia | ¿Qué puede seleccionar dinámicamente? |
| Gobierno | ¿Con qué permisos, límites y supervisión? |
Este cambio desde nombres hacia funciones resulta particularmente útil al evaluar productos.
Si un proveedor afirma que su solución incluye “agentes jurídicos”, la palabra comercial por sí sola informa poco.
Nuestro mapa permite reformular la conversación:
¿qué objetivo puede mantener?
¿qué información puede utilizar?
¿qué herramientas posee?
¿qué puede leer?
¿qué puede escribir?
¿qué decisiones toma sobre la ruta?
¿qué acciones requieren aprobación?
¿qué evidencia deja?
¿cuándo se detiene?
Esas preguntas son mucho más difíciles de responder mediante marketing.
Tres brújulas que utilizaremos durante todo el recorrido
Además de los dos mapas anteriores, existen tres distinciones transversales que conviene conservar desde ahora.
No constituyen nuevas etapas. Funcionan como brújulas para evaluar cualquier sistema que aparezca después.
Capacidad, permiso, decisión y responsabilidad
Imaginemos que una aplicación está técnicamente conectada al correo electrónico de la organización.
Podemos formular cuatro preguntas diferentes.
| Dimensión | Pregunta |
|---|---|
| Capacidad técnica | ¿Puede enviar un correo? |
| Permiso | ¿Está autorizado a enviarlo? |
| Decisión | ¿Puede determinar por sí mismo cuándo corresponde enviarlo? |
| Responsabilidad | ¿Quién responde por el contenido y por el envío? |
Nada obliga a que las cuatro respuestas sean iguales.
Puede existir capacidad sin permiso.
Puede existir permiso para preparar un borrador, pero no para enviarlo.
Puede permitirse el envío solo después de una aprobación humana.
Puede permitirse autonomía para mensajes de bajo impacto y exigir doble aprobación en materias críticas.
Esta separación será central cuando estudiemos herramientas y agentes.
Poder hacer algo no equivale a estar autorizado para hacerlo
En sistemas conectados, uno de los errores de diseño más peligrosos consiste en confundir capacidad técnica con autoridad.
Una integración puede hacer posible una acción.
La política de permisos determina si esa acción está autorizada.
La orquestación determina cuándo se propone o selecciona.
La organización determina quién conserva la responsabilidad.
Forma, contenido y evidencia
Existe una segunda separación.
Un sistema puede producir una salida perfectamente estructurada:
{
"riesgo": "alto",
"clausula": "12.3",
"recomendacion": "negociar"
}Eso demuestra que la forma es correcta.
No demuestra que la clasificación sea correcta.
Y tampoco demuestra que exista evidencia suficiente para sostenerla.
Por eso distinguiremos durante todo el curso:
forma correcta
de
contenido correcto
y de
evidencia suficiente.
Esta diferencia parece pequeña mientras utilizamos IA para tareas informales. Se vuelve fundamental cuando los outputs alimentan matrices, dashboards, workflows, decisiones o sistemas posteriores.
Una afirmación equivocada dentro de un párrafo puede ser detectada durante la lectura.
Una afirmación equivocada dentro de un objeto estructurado puede pasar directamente a otra etapa y adquirir apariencia de dato.
Por eso la estructuración facilita el procesamiento, pero no sustituye la verificación.
Automatización y autonomía
La tercera brújula será especialmente importante al final.
Un sistema puede estar altamente automatizado sin tener mucha autonomía.
Un workflow podría ejecutar automáticamente:
recibir contrato
↓
extraer metadatos
↓
ejecutar revisión
↓
crear matriz
↓
enviar a aprobaciónLa secuencia puede funcionar sin intervención manual y, sin embargo, estar completamente definida de antemano.
Un agente introduce otra propiedad:
objetivo
↓
observar situación
↓
seleccionar acción permitida
↓
ejecutar
↓
examinar resultado
↓
seleccionar siguiente acciónLa diferencia no es simplemente “manual frente a automático”.
Es ruta predeterminada frente a selección contextual de próximos pasos.
Las clases expresan la distinción señalando que workflow y agente no son enemigos: los agentes jurídicos pueden operar dentro de workflows gobernados.
Caso conductor: “Llegó un contrato de proveedor de IA. ¿Puede aprobarse?”
Todo el recorrido se volvería demasiado abstracto si cada concepto se explicara mediante un ejemplo diferente.
Por eso utilizaremos un único problema que irá creciendo con el sistema.
El caso es deliberadamente cotidiano:
“Llegó un contrato de proveedor de IA. ¿Puede aprobarse?”
Imaginemos una organización que está evaluando una nueva aplicación para apoyar determinadas tareas profesionales.
El proveedor envía un contrato principal. Existe además documentación técnica, condiciones de uso, un anexo de tratamiento de datos, información sobre seguridad y materiales comerciales. El equipo interno tiene políticas de contratación, criterios de privacidad, precedentes de negociaciones anteriores y distintos niveles de aprobación según el riesgo.
Al comienzo, una persona podría simplemente cargar el contrato principal en una aplicación de IA.
Su instrucción podría ser:
“Revisa este contrato.”
La respuesta puede resultar útil como primera aproximación.
Pero todavía existe una enorme cantidad de trabajo fuera del sistema.
El usuario seleccionó el archivo.
El usuario decidió que ese era el documento relevante.
El usuario no necesariamente incorporó los anexos.
El usuario debe recordar qué criterios internos existen.
El usuario deberá verificar las citas.
El usuario decidirá qué especialistas deben intervenir.
El usuario realizará cualquier búsqueda adicional.
El usuario copiará los resultados a otra plataforma.
El usuario coordinará aprobaciones.
Y el usuario tendrá que reconstruir posteriormente qué ocurrió si alguien pregunta cómo se llegó a la conclusión.
La historia del curso consiste en desplazar, de manera selectiva y controlada, algunas de esas funciones desde la coordinación manual hacia una arquitectura explícita.
El mismo contrato, ocho veces
El caso no cambia.
Lo que cambia es la capacidad del sistema.
| Etapa | Qué puede hacer ahora | Qué problema sigue abierto |
|---|---|---|
| Prompt | Recibe una instrucción sobre cómo revisar el contrato. | La instrucción debe reconstruirse y mucha información permanece implícita. |
| Template | Conserva una estructura reutilizable para distintos contratos. | Reutilizar una instrucción no garantiza una metodología completa. |
| Skill | Aplica una metodología delimitada de revisión. | La metodología no contiene necesariamente los documentos o criterios específicos del asunto. |
| Knowledge / RAG | Puede trabajar con políticas, precedentes y documentación pertinente. | Tener acceso a información no permite necesariamente interactuar con otros sistemas o producir efectos externos. |
| Tool / API / Connector / MCP | Puede consultar recursos y ejecutar determinadas acciones. | Varias capacidades conectadas todavía necesitan coordinación. |
| Workflow | Sigue una secuencia explícita de recepción, revisión, aprobación y registro. | Una secuencia fija no resuelve bien todos los casos y excepciones. |
| Playbook | Aplica rutas diferentes según criterios, riesgos y excepciones. | Las ramas pueden seguir dependiendo de reglas completamente predeterminadas. |
| Agent | Puede seleccionar algunos próximos pasos de manera dinámica dentro de límites. | Más capacidad de decisión exige más gobierno, evidencia, permisos y supervisión. |
Observemos con mayor detalle cómo cambia la misma situación.
Al comienzo
Llega un documento denominado Contrato_ProveedorIA_v7.docx.
Una persona lo abre, decide que debe revisarse, lo adjunta y formula una instrucción.
El sistema responde.
La inteligencia artificial participa principalmente como generador o analizador dentro de una interacción puntual.
Después de aprender prompting
La instrucción mejora.
Ahora especificamos posición contractual, objetivo, contexto, materias prioritarias, evidencia que debe citarse y forma de salida.
La respuesta probablemente será más fácil de revisar.
Pero seguimos dependiendo de una persona para activar correctamente la metodología.
Después de construir capacidades reutilizables
La organización podría disponer de skills especializadas:
revisar tratamiento de datos
evaluar limitación de responsabilidad
identificar subcontratación
comparar cláusulas con estándar interno
detectar información contractual faltante
No estamos creando un “abogado general”.
Estamos componiendo capacidades más pequeñas.
Cuando añadimos conocimiento
Las mismas skills pueden trabajar con materiales distintos según el asunto.
El sistema podría utilizar:
- política interna de contratación;
- matriz corporativa de riesgos;
- posiciones contractuales preferidas;
- contratos previamente aprobados;
- documentación específica del proveedor.
Pero no toda esa información debe introducirse indiscriminadamente en cada interacción.
Necesitamos recuperación.
Cuando añadimos RAG
La revisión de la cláusula de seguridad puede recuperar la parte pertinente de la política de seguridad.
La revisión de subprocesadores puede recuperar el criterio aplicable a terceros.
La comparación contractual puede localizar precedentes cercanos.
La información necesaria puede comenzar a incorporarse según la tarea.
Pero todavía es posible que alguien deba localizar manualmente el expediente original o guardar el resultado.
Cuando añadimos herramientas
El sistema puede, dependiendo de sus permisos, consultar el gestor documental, abrir determinados archivos, realizar búsquedas, registrar resultados o interactuar con servicios externos.
Por primera vez aparece claramente la diferencia entre producir texto y actuar sobre un entorno.
Aquí el diseño de permisos deja de ser accesorio.
Cuando añadimos workflow
Podemos representar el proceso:
flowchart LR
A["Recibir"] --> B["Clasificar"]
B --> C["Reunir antecedentes"]
C --> D["Revisar"]
D --> E["Consolidar hallazgos"]
E --> F["Aprobar / escalar"]
F --> G["Registrar"]
Ahora existe una ruta institucional visible.
Podemos identificar estados.
Podemos saber qué debe ocurrir antes de qué.
Podemos insertar puntos de control.
Cuando añadimos playbook
La ruta deja de ser completamente uniforme.
Un contrato que implique categorías especiales de datos podría activar revisión de privacidad.
Un proveedor con acceso a sistemas críticos podría activar revisión de seguridad.
Una desviación grave en responsabilidad podría exigir escalamiento.
La lógica se aproxima más a la práctica real:
flowchart TD
A["Contrato recibido"] --> B{"¿Procesa datos personales?"}
B -- "Sí" --> C["Ruta de privacidad"]
B -- "No" --> D["Revisión contractual general"]
C --> E{"¿Riesgo crítico?"}
D --> E
E -- "Sí" --> F["Escalar"]
E -- "No" --> G["Preparar aprobación"]
Todavía conocemos las ramas.
Lo que hemos ganado son criterios y excepciones explícitas.
Cuando introducimos agencia
Finalmente podemos permitir que el sistema seleccione dinámicamente algunas acciones.
Puede detectar que falta información y decidir buscarla en una fuente autorizada.
Puede determinar qué skill especializada corresponde ejecutar.
Puede volver a revisar un aspecto cuando encuentra una inconsistencia.
Puede decidir que los antecedentes son insuficientes y pedir ayuda.
Puede preparar la ruta de aprobación correspondiente.
Pero su capacidad se encuentra delimitada.
Quizá pueda leer contratos sin aprobación.
Quizá pueda redactar una minuta.
Quizá necesite autorización antes de enviar información a terceros.
Quizá tenga prohibido modificar determinados registros.
Quizá deba detenerse cuando existe información contradictoria o cuando el riesgo supera cierto umbral.
Ese es el punto en que la arquitectura deja de ser solamente una colección de capacidades y se convierte en un sistema parcialmente capaz de encargarse de una tarea.
La clase final formula precisamente esta diferencia:
responder significa producir una salida cuando se solicita; encargarse significa mantener un objetivo, elegir pasos y utilizar recursos; gobernarse exige además rastros, autorizaciones y posibilidad de revisión.
La arquitectura final ya está contenida en el caso inicial
Podemos anticipar el destino del recorrido sin desarrollar todavía sus componentes.
Al final, el sistema del caso podría:
recibir un contrato
↓
identificar el expediente
↓
comprobar antecedentes
↓
detectar información faltante
↓
ejecutar capacidades jurídicas especializadas
↓
recuperar políticas y criterios pertinentes
↓
clasificar hallazgos
↓
seleccionar la ruta procedimental aplicable
↓
preparar una matriz de revisión
↓
solicitar aprobaciones cuando corresponda
↓
registrar resultado y evidenciaEso se aproxima a la arquitectura acumulada de las clases: prompts y templates aportan instrucciones reutilizables; skills, capacidades delimitadas; knowledge y RAG, fuentes pertinentes; tools y protocolos de integración, acceso y acción; workflows, secuencia y estados; playbooks, criterios y ramas; y agentes, selección y corrección dinámica de la ruta.
Lo importante es observar qué no aparece en esa arquitectura.
No existe un momento en que entreguemos simplemente “todo el trabajo jurídico” a un modelo y esperemos que lo resuelva.
La capacidad surge mediante composición.
El control también.
El sistema no debe evaluarse solamente por su respuesta final
Existe una consecuencia importante de todo lo anterior.
Cuando utilizamos un modelo mediante una conversación aislada es natural concentrarnos en el output:
“¿La respuesta parece correcta?”
A medida que el sistema adquiere más componentes, esa pregunta deja de ser suficiente.
Supongamos que la conclusión final dice:
“Riesgo medio. Puede aprobarse sujeto a modificación de las cláusulas 8.2 y 14.”
Para evaluar profesionalmente esa conclusión podemos necesitar saber además:
¿Qué versión del contrato examinó?
¿Qué anexos encontró?
¿Qué documentos no pudo localizar?
¿Qué política interna recuperó?
¿Qué fragmentos utilizó como evidencia?
¿Qué skill ejecutó?
¿Qué herramienta consultó?
¿Qué información descartó?
¿Qué ruta siguió?
¿Dónde encontró incertidumbre?
¿Quién aprobó el resultado?
Las clases sintetizan esta transformación indicando que, en sistemas agentic, no basta observar la salida final: también importa la trayectoria completa del trabajo. Logs, traces y métricas permiten reconstruir qué ocurrió y cómo se llegó al resultado.
No desarrollaremos todavía observabilidad.
Pero conviene conservar desde ahora la intuición:
cuanto más trabajo delegamos al sistema, más importante resulta poder reconstruir qué hizo.
El Derecho aparece en la arquitectura, no solamente al final
Una última idea ayuda a comprender por qué este sitio mezcla conceptos técnicos y jurídicos.
Puede parecer que primero construimos una arquitectura tecnológica y después, en una etapa final, “agregamos” cuestiones legales.
No es así.
La dimensión jurídica aparece en cada capa.
Si existe infraestructura, aparecen preguntas de disponibilidad y continuidad.
Si existen datos, aparecen confidencialidad, privacidad, seguridad, retención y localización.
Si existe un modelo de tercero, aparecen dependencias, cambios de versión y condiciones de uso.
Si existe recuperación documental, importa qué fuentes puede consultar y con qué autorización.
Si existen herramientas, importa qué acciones pueden ejecutar.
Si existe workflow, importa dónde se sitúan los controles.
Si existe agencia, importan especialmente permisos, identidad, trazabilidad, delegación y responsabilidad.
Las clases expresan la misma idea desde la contratación: cada capa tecnológica puede activar tipos diferentes de control contractual, y la revisión jurídica correcta comienza por comprender qué componente genera qué riesgo.
La arquitectura técnica y la arquitectura jurídica no son idénticas.
Pero tampoco son independientes.
Qué deberíamos haber ganado al terminar el recorrido
Al final de este handbook no será necesario saber entrenar un modelo, administrar infraestructura cloud o programar un framework de agentes.
Sí deberíamos haber adquirido un criterio más exigente para observar estos sistemas.
Ante una aplicación de IA, deberíamos poder dejar de preguntar únicamente:
“¿Qué hace?”
y comenzar a preguntar:
“¿Qué componentes necesita para hacerlo?”
Ante una funcionalidad atractiva:
“¿Funciona?”
debería convertirse en:
“¿Para qué tarea, sobre qué información, bajo qué condiciones y cómo lo evaluamos?”
Ante una integración:
“¿Puede conectarse?”
debería convertirse en:
“¿Qué puede leer, qué puede escribir y con qué permisos?”
Ante un proceso automatizado:
“¿Está automatizado?”
debería convertirse en:
“¿La ruta está predefinida o el sistema puede seleccionar próximos pasos?”
Y ante un “agente”:
“¿Es autónomo?”
debería convertirse en preguntas más precisas:
¿qué objetivo mantiene, qué observa, qué decisiones puede adoptar, qué acciones tiene disponibles, cuáles requieren autorización, cuándo debe detenerse y qué evidencia deja?
Ese cambio de preguntas es uno de los principales resultados buscados por el sitio.
Dónde estamos en el recorrido
Todavía no hemos aprendido ninguno de los componentes en profundidad.
Eso es deliberado.
Esta página solo ha construido el mapa necesario para que, cuando aparezcan las piezas, podamos entender por qué aparecen.
Tenemos ahora dos representaciones complementarias:
ENTENDER
↓
INSTRUIR
↓
SABER HACER
↓
ACTUAR
↓
ORGANIZAR
↓
DECIDIRy:
PROMPT
↓
TEMPLATE
↓
SKILL
↓
KNOWLEDGE / RAG
↓
TOOL / API / CONNECTOR / MCP
↓
WORKFLOW
↓
PLAYBOOK
↓
AGENTTambién tenemos tres brújulas:
CAPACIDAD ≠ PERMISO ≠ DECISIÓN ≠ RESPONSABILIDAD
FORMA ≠ CONTENIDO ≠ EVIDENCIA
AUTOMATIZACIÓN ≠ AUTONOMÍAY tenemos un problema que nos acompañará durante todo el recorrido:
“Llegó un contrato de proveedor de IA. ¿Puede aprobarse?”
A partir de ahora no cambiaremos de ejemplo cada vez que aparezca una palabra nueva.
Veremos cómo el mismo caso adquiere propiedades.
Primero comprenderemos qué sistema estamos observando.
Después aprenderemos a instruirlo.
Luego estabilizaremos formas de trabajar.
Le proporcionaremos información.
Le permitiremos recuperar aquello que necesita.
Lo conectaremos con capacidades externas.
Ordenaremos esas capacidades dentro de procesos.
Incorporaremos criterios y excepciones.
Y solo entonces preguntaremos cuándo tiene sentido permitir que el sistema seleccione dinámicamente qué hacer después.
Una frase para conservar
El recorrido no consiste en pasar de una IA “simple” a una IA “mágica”.
Consiste en pasar de una respuesta aislada a un sistema de trabajo explícitamente diseñado.
El problema que todavía queda abierto
Tenemos el mapa.
Pero todavía utilizamos una palabra demasiado amplia:
IA.
¿Qué es exactamente lo que estamos describiendo cuando decimos que una organización “usa IA”?
¿Un modelo?
¿Una aplicación?
¿Un servicio completo?
¿Qué hace realmente un modelo por sí solo?
¿Qué elementos pertenecen al sistema que lo rodea?
¿Dónde terminan las capacidades del modelo y comienzan las de la aplicación?
¿Quién proporciona los datos, la infraestructura, la recuperación, las interfaces y los controles?
Antes de aprender a instruir un sistema, necesitamos aprender a verlo.
Por eso el recorrido comienza en Entender el sistema.
El siguiente paso será desmontar la expresión “inteligencia artificial” hasta poder responder una pregunta mucho más precisa:
¿qué puede hacer un modelo, qué no puede hacer por sí solo y qué tenemos que añadir alrededor para convertirlo en un sistema capaz de realizar trabajo útil?