flowchart LR
U[Usuario] --> A[Aplicación]
A --> M[Modelo]
M --> A
A --> O[Operación externa]
O --> S[Sistema o recurso]
S --> O
O --> A
A --> M
Del conocimiento a la acción
Por qué un sistema que sabe analizar y recuperar información todavía necesita medios operacionales para consultar, calcular y actuar sobre sistemas externos.
Hasta aquí hemos construido un sistema que puede hacer bastante más que responder una pregunta aislada.
Puede recibir una instrucción bien diseñada. Puede reutilizar una metodología mediante una skill. Puede disponer de conocimiento relevante y recuperar documentos cuando la tarea lo requiere. En otras palabras, ya no depende exclusivamente de lo que el usuario consiga escribir en un único mensaje.
Sin embargo, aparece una limitación nueva.
Supongamos que el sistema está revisando el contrato de un proveedor de inteligencia artificial y concluye:
Necesito comprobar cuál es la última versión firmada del anexo de seguridad.Puede haber razonado correctamente. Puede saber qué documento necesita. Puede incluso describir con precisión qué debería buscar.
Pero si ese anexo está almacenado en el DMS de la organización, saber que debe consultarlo no equivale a poder consultarlo.
Lo mismo ocurre si necesita conocer el estado actual del proveedor en procurement, calcular una exposición financiera, crear un registro o enviar una alerta.
El problema ya no es principalmente de instrucciones ni de conocimiento.
Es de interacción.
Idea central
Un modelo puede analizar información disponible en su contexto.
Para obtener información que no está allí, realizar una operación externa o producir un efecto sobre otro sistema, la aplicación necesita medios de interacción.
Ese cambio marca el paso desde SABER HACER hacia PODER ACTUAR.
Lo que ya tenemos
Conviene recordar brevemente dónde estamos, sin volver a desarrollar las páginas anteriores.
El recorrido ha ido agregando una propiedad por vez:
PROMPT
instrucción para una tarea
TEMPLATE
instrucción parametrizable y reutilizable
SKILL
metodología o capacidad reutilizable
KNOWLEDGE / RAG
información disponible y mecanismos para recuperar lo pertinenteCon estas piezas podemos construir una revisión contractual sofisticada.
La skill puede indicar, por ejemplo, que una cláusula de responsabilidad debe analizarse considerando el cap, sus exclusiones, las indemnidades y la relación entre exposición y remedios.
RAG puede recuperar la política contractual vigente y precedentes comparables.
El modelo puede integrar esa información y producir una evaluación.
Pero todavía existe una frontera.
El modelo puede razonar sobre lo que recibe
En este handbook utilizamos expresiones como “el modelo razona”, “el modelo selecciona” o “el modelo concluye” como abreviaturas pedagógicas. No necesitamos atribuirle comprensión humana para observar una capacidad funcional importante: dado un conjunto de instrucciones y contexto, puede producir inferencias, clasificaciones, comparaciones y propuestas de próximos pasos.
Por ejemplo, puede recibir:
Contrato principal
+
Anexo de tratamiento de datos
+
Política interna de contratación
+
Precedentes recuperadosy generar:
Hallazgo:
La cláusula 14.2 limita la responsabilidad del proveedor a tres meses de fees.
Comparación:
El estándar interno para proveedores críticos utiliza doce meses.
Información faltante:
No se encuentra el anexo de seguridad referido en la cláusula 8.4.Hasta ese punto no necesitamos que el modelo modifique ningún sistema externo.
Está trabajando con aquello que la aplicación ya colocó en su contexto.
Esta capacidad es valiosa. Pero no debemos confundirla con acceso general al entorno digital de la organización.
La mesa de trabajo tiene bordes
Podemos recuperar una analogía utilizada anteriormente: la ventana de contexto funciona como una mesa de trabajo.
Sobre esa mesa pueden colocarse:
- la instrucción;
- el contrato;
- documentos recuperados;
- resultados de operaciones anteriores;
- criterios relevantes.
El modelo puede trabajar con lo que está sobre la mesa.
La analogía ayuda porque permite comprender que un documento puede existir en la organización y, al mismo tiempo, no estar disponible para una ejecución concreta.
Pero la analogía deja de servir si imaginamos que el modelo puede levantarse por sí mismo, caminar por la oficina y abrir cualquier archivador.
Para incorporar algo que está fuera de la mesa necesitamos otra capa del sistema.
Primer límite: el presente
Parte de la información que necesitamos cambia continuamente.
Por ejemplo:
- el estado de una solicitud;
- la versión vigente de un contrato;
- el responsable actual de un proceso;
- el saldo de una cuenta;
- una reunión futura;
- un ticket abierto;
- la última política publicada.
No es suficiente confiar en que el modelo “lo sepa”.
Incluso si durante su entrenamiento encontró información sobre una entidad, eso no garantiza que disponga del estado correcto ahora.
En una aplicación profesional, la solución habitual no consiste en pedirle que adivine mejor, sino en permitir que el sistema consulte una fuente actual.
Chip Huyen trata este punto como una extensión natural de la arquitectura de una aplicación: una vez que la llamada simple al modelo deja de ser suficiente, se añaden mecanismos de construcción de contexto y herramientas capaces de obtener información mediante APIs y otras fuentes externas (Huyen, 2025).
Segundo límite: lo privado
El sistema también puede necesitar información que nunca estuvo disponible públicamente.
En trabajo jurídico esto es normal, no excepcional.
Pensemos en:
contratos anteriores
anexos no públicos
correos
políticas internas
matrices de riesgos
bases de clientes
registros de excepciones
información de procurementLa existencia de esos datos dentro de una organización no implica que un modelo pueda acceder a ellos.
Para utilizarlos deben cumplirse dos condiciones diferentes.
Primero, debe existir un mecanismo técnico de acceso.
Segundo, ese acceso debe estar autorizado.
La diferencia entre ambas condiciones será central durante toda esta sección.
Tercer límite: la computación especializada
Hay operaciones que un modelo podría intentar realizar mediante lenguaje, pero para las cuales resulta mejor utilizar una función especializada.
Supongamos que necesitamos determinar qué proporción representa un límite de responsabilidad de 800.000 respecto de una exposición estimada de 2.400.000.
El modelo puede intentar calcularlo.
Pero una aplicación puede preferir delegar esa operación a una calculadora o función determinista.
La distinción es sencilla:
MODELO
interpreta qué debe calcularse
FUNCIÓN
realiza el cálculo
MODELO
interpreta el resultadoEsto ilustra una propiedad importante de los sistemas modernos: no todo debe resolverse mediante generación probabilística.
Una buena arquitectura puede combinar modelos con software tradicional y reservar a cada componente aquello que hace mejor.
Cuarto límite: producir efectos
El salto más importante aparece cuando la tarea exige cambiar algo fuera de la conversación.
Comparemos:
Redacta una alerta para Legal Operations.con:
Envía la alerta a Legal Operations.La primera instrucción produce contenido.
La segunda exige una acción.
Lo mismo ocurre con estas parejas:
preparar un registro
≠
crear el registro
proponer un cambio
≠
modificar el documento
redactar un correo
≠
enviar el correo
recomendar aprobación
≠
aprobarMientras el resultado permanece como borrador, existe una frontera visible antes de que produzca efectos externos.
Cuando una aplicación puede escribir, comunicar o ejecutar, esa frontera cambia.
De la respuesta a la operación
Podemos representar la transición de forma mínima.
El punto más importante del diagrama es que el modelo no necesita comunicarse directamente con el sistema externo.
La aplicación puede actuar como intermediaria.
Eso permite incorporar controles entre la intención de utilizar una capacidad y su ejecución efectiva.
Más adelante veremos que el modelo puede producir una solicitud estructurada de uso de una herramienta. La aplicación puede entonces validar esa solicitud, comprobar permisos, ejecutar la operación y devolver el resultado.
Todavía no necesitamos estudiar ese mecanismo en detalle.
Por ahora basta comprender que generar la intención de actuar y actuar realmente son eventos diferentes.
Tres fronteras que conviene mantener separadas
Esta sección completa puede entenderse mediante tres fronteras.
Frontera de información
Pregunta:
¿Qué información está disponible para la tarea?
Knowledge y RAG ayudan a resolver parte de este problema.
Frontera operacional
Pregunta:
¿Qué operaciones puede ejecutar la aplicación?
Aquí aparecen las tools.
Frontera de autoridad
Pregunta:
¿Qué operaciones está permitido ejecutar y bajo qué condiciones?
Aquí aparecen permisos, autenticación, autorización y aprobación.
Estas tres fronteras pueden solaparse, pero no deben confundirse.
Capacidad no equivale a autoridad
Que una aplicación pueda técnicamente leer un repositorio no significa que deba leer todo el repositorio.
Que pueda enviar un correo no significa que pueda decidir autónomamente enviarlo.
Que pueda modificar un registro no significa que tenga autoridad institucional para adoptar la decisión que ese registro representa.
Caso conductor: el contrato ya no está solo
Retomemos el caso transversal:
Llegó un contrato de proveedor de IA. ¿Puede aprobarse?
Hasta ahora el usuario podía cargar manualmente el contrato y sus anexos.
Supongamos que el sistema produce este diagnóstico:
1. La limitación de responsabilidad parece inferior al estándar interno.
2. La cláusula de seguridad remite a un anexo que no está disponible.
3. Debe verificarse si existen excepciones aprobadas para proveedores comparables.Una aplicación sin herramientas puede detenerse allí.
Puede decir qué falta.
Puede pedir al usuario que busque los documentos.
Puede esperar que alguien realice el cálculo.
Puede preparar el texto que luego otra persona registrará.
Una aplicación con medios operacionales podría, en cambio, estar habilitada para:
buscar el anexo en el DMS
consultar el registro de excepciones
recuperar la política vigente
calcular la relación entre cap y exposición
guardar un borrador de la revisiónLo que hemos añadido no es “más conocimiento del modelo”.
Hemos añadido capacidad de interacción.
No necesitamos autonomía para tener herramientas
Aquí conviene proteger desde el principio una frontera que será importante más adelante.
Una aplicación puede utilizar herramientas sin convertirse en un agente autónomo.
Por ejemplo, el usuario puede presionar un botón:
[Buscar anexo vigente]y la aplicación ejecutar una función predeterminada.
O un workflow puede establecer siempre:
si falta el anexo de seguridad
→ buscar en el repositorio XEn ninguno de esos casos el modelo necesita elegir libremente la próxima acción.
Por eso:
TOOL
≠
AGENTLas herramientas agregan capacidades.
La pregunta sobre quién elige entre ellas pertenece a una etapa posterior del recorrido.
Un cambio de vocabulario que refleja un cambio de arquitectura
En las páginas anteriores podíamos hablar principalmente de:
instrucción
contexto
metodología
conocimientoA partir de ahora necesitaremos añadir palabras de software:
función
herramienta
llamada
argumento
API
connector
protocolo
permisoNo estamos acumulando terminología por gusto.
Cada palabra aparece porque el sistema anterior encontró un límite concreto.
Las clases UDD expresan precisamente esta progresión como un tránsito desde capacidades internas hacia interacción con sistemas externos: Tool → Tool calling → API → Connector → MCP.
Por qué importa para el trabajo jurídico
La transición desde generación hacia acción cambia las preguntas jurídicas y de gobernanza.
Si una aplicación solamente analiza un documento que el usuario cargó manualmente, debemos preocuparnos, entre otras cosas, de la información enviada, la calidad del resultado y la revisión profesional.
Cuando la aplicación puede interactuar con sistemas internos, aparecen además cuestiones como:
¿qué repositorios puede consultar?
¿con qué identidad se conecta?
¿qué operaciones tiene disponibles?
¿puede escribir?
¿puede enviar información a terceros?
¿qué acciones requieren aprobación?
¿qué queda registrado?La competencia tecnológica necesaria no consiste en que el abogado aprenda a programar cada integración.
Consiste en que pueda distinguir qué poder operacional se está entregando al sistema.
El mismo trabajo puede hacerse manualmente o mediante una capacidad conectada
La existencia de tools no significa que el trabajo anterior fuera imposible.
Un abogado puede buscar manualmente el anexo, descargarlo y subirlo a la aplicación. Puede abrir una calculadora, copiar el resultado y volver a la conversación. Puede redactar un correo y presionar “Enviar” personalmente.
La diferencia está en dónde se encuentra la frontera entre el trabajo humano y el sistema.
Comparemos:
FLUJO MANUAL
modelo detecta que falta un documento
↓
usuario busca el documento
↓
usuario lo incorpora
↓
modelo continúacon:
FLUJO CON TOOL
modelo o aplicación detecta que falta un documento
↓
aplicación invoca una capacidad autorizada
↓
resultado vuelve al contexto
↓
modelo continúaAmbos pueden resolver la misma necesidad. El segundo reduce una transferencia manual y hace posible automatizar parte de la interacción.
Pero también crea una nueva superficie de responsabilidad: ahora debemos gobernar la capacidad que antes ejercía directamente la persona.
Esta comparación evita una conclusión apresurada. Añadir una tool no es siempre una mejora. Tiene sentido cuando el beneficio de integrar la operación justifica el costo adicional de permisos, validación, errores, mantenimiento y trazabilidad.
Poder actuar no significa necesariamente actuar más
También es importante no asociar esta sección con una meta de automatización máxima.
Una aplicación puede ganar capacidad operacional y utilizarla de forma muy conservadora.
Por ejemplo:
buscar documentos
→ automático
recuperar anexos
→ automático
crear borrador
→ automático
enviar a tercero
→ siempre requiere confirmación
aprobar
→ no disponibleEl diseño puede, por tanto, aumentar la capacidad del sistema sin aumentar en la misma medida su autoridad.
Este punto será decisivo más adelante: la pregunta correcta no es “¿cuánto podemos automatizar?”, sino “¿qué combinación de capacidad y control resulta adecuada para esta tarea?”.
Qué debes recordar
Hasta aquí el sistema podía saber cómo realizar una tarea y podía disponer de información para ejecutarla.
Eso todavía no significa que pueda interactuar con el entorno donde ocurre el trabajo.
El modelo trabaja con lo que la aplicación coloca en su contexto. Para consultar información actual o privada, realizar cálculos especializados, escribir en sistemas o ejecutar acciones, necesita medios adicionales.
Ese es el salto desde:
SABER HACER
↓
PODER ACTUARY ese salto introduce una separación que debemos conservar durante toda la sección:
CAPACIDAD TÉCNICA
≠
PERMISO
≠
AUTORIDAD PROFESIONALEl problema que todavía queda abierto
Sabemos ahora por qué necesitamos medios operacionales.
Pero todavía no hemos distinguido con suficiente precisión dos conceptos que pueden parecer similares.
Una skill permite al sistema aplicar una metodología de revisión.
Una tool puede permitirle buscar el contrato, ejecutar un cálculo o crear un registro.
Ambas amplían lo que el sistema puede hacer, pero lo hacen de manera completamente diferente.
El siguiente nodo estudia esa frontera: Skill versus Tool, o la diferencia entre una capacidad metodológica y una capacidad operacional.