flowchart LR
U[Encargo] --> S[Skill<br/>metodología]
S --> T1[Tool<br/>buscar]
S --> T2[Tool<br/>recuperar]
S --> T3[Tool<br/>calcular]
T1 --> S
T2 --> S
T3 --> S
S --> R[Resultado]
Skill versus Tool
Cómo distinguir una capacidad metodológica que enseña al sistema a realizar una tarea de una capacidad operacional que le permite consultar, calcular o actuar.
Ya sabemos por qué aparece una nueva necesidad: un sistema puede tener una metodología correcta y disponer de conocimiento pertinente, pero seguir siendo incapaz de interactuar con los recursos donde ocurre el trabajo.
Ahora debemos evitar una confusión muy común.
Supongamos que tenemos una capacidad denominada:
evaluar_clausula_responsabilidady otra denominada:
buscar_contrato_en_DMSLas dos pueden ser “capacidades reutilizables”. Las dos pueden formar parte del mismo sistema. Las dos pueden activarse durante una revisión contractual.
Pero no son el mismo tipo de cosa.
La primera describe cómo realizar un análisis.
La segunda permite ejecutar una operación.
Ésta es la frontera entre skill y tool.
Idea central
En el marco pedagógico de este sitio:
Skill = capacidad metodológica: cómo realizar correctamente una clase de tarea.
Tool = capacidad operacional: qué operación concreta puede ejecutar la aplicación sobre información, funciones o sistemas.
La skill organiza el trabajo intelectual.
La tool extiende el alcance operacional.
Dos problemas diferentes
La distinción se vuelve más clara si comenzamos por el problema que resuelve cada pieza.
Problema metodológico
Tenemos el contrato y todos los antecedentes, pero distintos usuarios lo revisan de manera inconsistente.
Uno mira responsabilidad.
Otro se concentra en datos.
Otro no distingue texto contractual de inferencia.
Necesitamos estabilizar cómo se realiza la revisión.
Respuesta:
SKILLProblema operacional
La metodología dice que debemos comparar el contrato con el anexo de seguridad vigente, pero el anexo está en un repositorio externo a la conversación.
Necesitamos que la aplicación pueda obtenerlo.
Respuesta:
TOOLEl hecho de que ambas piezas puedan participar en una misma tarea no borra la diferencia.
Capacidad metodológica: qué aporta una skill
Una skill puede contener o coordinar elementos como:
- instrucciones;
- criterios;
- checklists;
- ejemplos;
- secuencias de análisis;
- formatos;
- reglas sobre evidencia;
- condiciones para identificar información faltante.
Por ejemplo, una skill para revisar cláusulas de terminación podría establecer:
1. Identifica todos los derechos de terminación.
2. Distingue terminación por causa y por conveniencia.
3. Extrae plazos de aviso.
4. Identifica obligaciones posteriores al término.
5. Verifica mecanismos de devolución o eliminación de datos.
6. Separa texto contractual, interpretación e información faltante.La skill no necesita tener acceso directo al DMS.
Puede funcionar perfectamente si el usuario le entrega manualmente los documentos.
Su valor está en la metodología.
Capacidad operacional: qué aporta una tool
Una tool resuelve otro tipo de necesidad.
Por ejemplo:
buscar_documentos(proveedor, tipo)puede permitir localizar archivos.
calcular_ratio(numerador, denominador)puede ejecutar un cálculo.
crear_ticket(asunto, descripcion)puede registrar una tarea en un sistema.
La tool no necesita contener una metodología jurídica compleja.
Su valor está en proporcionar una operación invocable.
Comparación directa
| Pregunta | Skill | Tool |
|---|---|---|
| ¿Qué problema resuelve? | Inconsistencia en cómo se realiza la tarea | Falta de capacidad para consultar, computar o actuar |
| ¿Qué aporta? | Método | Operación |
| ¿Dónde actúa principalmente? | Sobre la forma de analizar o producir | Sobre información, funciones o sistemas |
| Ejemplo contractual | Evaluar cláusula de responsabilidad | Buscar contrato en DMS |
| Otro ejemplo | Clasificar riesgos según criterios | Calcular exposición |
| Otro ejemplo | Preparar metodología de due diligence | Crear registro de hallazgo |
| Riesgo típico | Criterio incorrecto o metodología incompleta | Operación equivocada, datos incorrectos o falta de permiso |
La tabla simplifica, pero permite construir una frontera suficientemente sólida para continuar.
El mismo caso visto con skill y tool
Supongamos esta cláusula:
La responsabilidad agregada del proveedor no excederá los fees pagados durante los tres meses anteriores al evento.Una skill puede decir:
Para evaluar la limitación de responsabilidad:
1. identifica el período utilizado para calcular el cap;
2. identifica exclusiones;
3. revisa indemnidades;
4. compara con el estándar interno;
5. considera la exposición estimada;
6. clasifica la desviación.Perfecto.
Pero la skill necesita información para ejecutar algunos pasos.
El estándar interno podría estar en un repositorio.
Los fees podrían estar en el sistema financiero.
La exposición podría requerir un cálculo.
Aparecen entonces tools distintas:
obtener_estandar_contractual()
consultar_fees(proveedor, periodo)
calcular_ratio(cap, exposicion)La skill organiza qué necesitamos hacer con esos datos.
Las tools permiten obtener o procesar esos datos.
Una analogía útil: oficio y herramientas
Podemos utilizar una analogía profesional.
Un abogado puede saber perfectamente cómo realizar una due diligence.
Ese conocimiento metodológico incluye qué revisar, en qué orden, qué evidencia pedir, cómo clasificar hallazgos y cuándo escalar.
Eso se parece a una skill.
Pero para ejecutar la due diligence necesita medios concretos:
- acceso al data room;
- buscador documental;
- planilla;
- sistema de gestión;
- correo.
Eso se parece a tools.
La analogía ayuda porque separa saber trabajar de disponer de medios.
Pero deja de servir cuando imaginamos que una skill es solamente conocimiento humano documentado o que una tool debe ser necesariamente un objeto físico. Aquí ambos conceptos se implementan dentro de sistemas de software.
Una skill puede utilizar tools
La distinción no significa aislamiento.
Una skill puede depender de tools para ejecutarse de manera más completa.
Por ejemplo:
SKILL
revisar cláusulas de privacidad
NECESITA
contrato + DPA + política interna
UTILIZA
buscar_documentos
obtener_documento
comparar_versionesLa skill define el método.
Las tools proporcionan capacidades operacionales necesarias para completar ese método.
Podemos representarlo así:
El diagrama no implica todavía que la skill decida autónomamente cuándo utilizar cada tool. La orquestación puede estar fijada por reglas, por un workflow o por una aplicación. Esa decisión pertenece a capas posteriores.
Una tool también puede utilizarse sin skill
La relación funciona en ambos sentidos.
Podemos tener una aplicación muy simple con un botón:
[Buscar contrato]El botón utiliza una tool.
No necesita una metodología jurídica encapsulada.
También podemos tener:
[Convertir DOCX a PDF]La operación es útil, pero no exige una skill jurídica.
Esto confirma que tool y skill son componentes independientes aunque puedan combinarse.
Una mala arquitectura: esconder todo dentro de una “tool”
Supongamos que alguien define:
hacer_revision_juridica_completa()La función:
- busca documentos;
- decide qué revisar;
- aplica criterios;
- genera conclusiones;
- registra resultados;
- envía alertas.
Desde el punto de vista del usuario puede parecer cómodo.
Desde el punto de vista de control, hemos mezclado demasiadas cosas.
Si el resultado sale mal, será difícil responder:
¿falló la búsqueda?
¿se recuperó el documento incorrecto?
¿el criterio jurídico era defectuoso?
¿el cálculo estaba mal?
¿la comunicación se envió sin autorización?Separar skill y tools mejora la capacidad de inspeccionar el sistema.
Un nombre no determina la arquitectura
Que una función comercial se llame “skill” o “tool” no demuestra que corresponda exactamente a la taxonomía utilizada en este handbook.
Los proveedores emplean estas palabras de maneras diferentes.
Aquí mantenemos una distinción pedagógica: metodología versus operación.
El problema de las fronteras híbridas
En sistemas reales existen componentes que mezclan varias funciones.
Supongamos una herramienta denominada:
comparar_con_estandar_contractualInternamente podría:
- recuperar el estándar;
- extraer la cláusula;
- comparar textos;
- devolver una diferencia.
¿Es skill o tool?
La respuesta depende del nivel de análisis.
Como capacidad invocable por la aplicación puede tratarse operacionalmente como una tool.
Pero puede encapsular dentro de sí una metodología.
La existencia de casos híbridos no elimina la utilidad de la distinción. Simplemente exige preguntar:
¿Qué estamos intentando gobernar en este nivel?
Si nos interesa revisar el método de comparación, debemos abrir la caja.
Si sólo necesitamos utilizar una operación bien definida y validada, puede bastar tratarla como capacidad operacional.
Método correcto, operación incorrecta
Separar las capas también permite comprender tipos diferentes de error.
Error metodológico
La skill indica que cualquier limitación de responsabilidad inferior a doce meses es automáticamente “riesgo alto”.
El criterio puede ser demasiado rígido.
La tool de búsqueda funcionó perfectamente.
Error operacional
La skill está bien diseñada, pero obtener_estandar_contractual() recupera la versión 2023 en vez de la vigente.
El método es correcto.
La información utilizada no lo es.
Error de autorización
La tool encuentra correctamente un contrato de otro matter para el que el usuario no tiene acceso.
La operación técnica funciona.
El sistema falla en permisos.
Estas tres situaciones necesitan correcciones distintas.
Diseño de capacidades pequeñas
Las clases UDD utilizan una idea que conviene conservar: el objetivo no es construir desde el comienzo una gran “IA que haga todo”, sino capacidades pequeñas, evaluables, gobernables y combinables.
La separación skill/tool encaja directamente con ese principio.
Podemos tener:
SKILLS
- revisar responsabilidad
- revisar datos
- revisar continuidad
TOOLS
- buscar documento
- recuperar archivo
- consultar proveedor
- calcular exposición
- guardar borradorCada pieza tiene una función relativamente clara.
Podemos probarla.
Podemos limitarla.
Podemos reemplazarla.
Podemos decidir quién puede usarla.
La modularidad no es sólo una preferencia técnica. También facilita gobernanza.
Por qué importa en trabajo jurídico
La distinción ayuda a formular preguntas más precisas al evaluar una solución.
Si un proveedor dice:
“Nuestra plataforma tiene una skill para revisar contratos”
queremos saber qué significa.
¿Se refiere a:
- un prompt reutilizable;
- una metodología;
- una función que además busca documentos;
- un workflow completo;
- una integración con sistemas?
Si dice:
“La plataforma tiene una tool para Salesforce”
queremos saber:
- qué operaciones expone;
- qué datos puede leer;
- si puede escribir;
- con qué identidad;
- con qué permisos.
El vocabulario técnico se vuelve útil cuando permite descomponer la prestación.
El caso conductor, ahora con las piezas separadas
Nuestro sistema de revisión de proveedor de IA podría quedar así:
SKILL
Revisión contractual de proveedor tecnológico
KNOWLEDGE
Política contractual + criterios de riesgo
TOOLS
buscar_documentos
obtener_documento
consultar_excepciones
calcular_ratio
crear_borrador_revisionLa pregunta de cada capa es diferente.
SKILL
¿está bien diseñada la metodología?
KNOWLEDGE
¿la información relevante está disponible?
TOOL
¿la operación existe y funciona?
PERMISO
¿puede utilizarse en este caso?Ésta es una arquitectura mucho más comprensible que una única función denominada “revisa y aprueba el contrato”.
Una prueba práctica para distinguirlas
Cuando la frontera no sea evidente, puede utilizarse una prueba sencilla.
Pregunte:
Si desconecto todos los sistemas externos, ¿esta pieza todavía describe cómo debería hacerse la tarea?
Si la respuesta es sí, probablemente estamos mirando una capacidad metodológica.
Después pregunte:
¿Esta pieza necesita ejecutar una operación concreta para producir su resultado?
Si la respuesta es sí, probablemente estamos mirando una capacidad operacional o una combinación que incluye tools.
Por ejemplo:
“Para revisar responsabilidad, identifica cap, exclusiones e indemnidades”sigue teniendo sentido aunque trabajemos con documentos impresos. Es metodología.
En cambio:
“Recupera la última versión firmada desde el DMS”sólo puede ejecutarse si existe un medio operacional de acceso.
La prueba no resuelve todos los casos híbridos, pero obliga a identificar qué propiedad queremos describir.
Skill y tool también se mantienen de manera distinta
La separación tiene una consecuencia práctica de mantenimiento.
Una skill puede cambiar porque cambia:
- la metodología jurídica;
- el criterio de riesgo;
- la política interna;
- la forma de documentar evidencia.
Una tool puede cambiar porque cambia:
- la API subyacente;
- el sistema conectado;
- la autenticación;
- el esquema de parámetros;
- la operación disponible.
Podemos entonces tener una situación como ésta:
la metodología jurídica sigue vigente
pero
el connector del DMS cambióo la contraria:
la tool sigue funcionando
pero
la política contractual cambióSi skill y tool están separadas, podemos actualizar una sin reescribir necesariamente la otra.
Eso también ayuda a versionar y probar.
La misma tool puede servir a varias skills
Una tool bien diseñada suele ser reutilizable.
Por ejemplo:
obtener_documento(id)puede ser utilizada por:
skill de revisión contractual
skill de due diligence
skill de análisis regulatorio
skill de comparación documentalLa operación de recuperar un documento no necesita conocer todo el propósito jurídico para el cual será utilizado.
Esto favorece una arquitectura modular:
muchas metodologías
↓
conjunto común de capacidades operacionalesLa modularidad reduce duplicación y permite aplicar controles consistentes sobre las operaciones sensibles.
Qué debes recordar
Skill y tool amplían capacidades diferentes.
Una skill hace reutilizable una forma de trabajar.
Una tool hace invocable una operación.
La skill puede decir:
compara la cláusula con el estándar vigenteLa tool puede hacer posible:
obtener_estandar_vigente()La skill puede indicar:
calcula la relación entre cap y exposiciónLa tool puede ejecutar:
calcular_ratio()La metodología y la operación colaboran, pero no deben confundirse.
El problema que todavía queda abierto
Ya sabemos qué distingue una tool de una skill.
Pero “tool” sigue siendo una categoría demasiado abstracta.
¿Qué clase de cosas puede hacer una herramienta?
¿Es lo mismo leer un documento que enviar un correo?
¿Buscar, recuperar, calcular, transformar, escribir y ejecutar pertenecen realmente al mismo nivel de riesgo?
El siguiente nodo responde esas preguntas entrando en detalle en qué es una tool y en las operaciones básicas que puede exponer.