flowchart TD
T[Tools] --> I[Información]
T --> C[Computación]
T --> A[Acción]
I --> I1[Buscar]
I --> I2[Leer]
I --> I3[Recuperar]
C --> C1[Calcular]
C --> C2[Comparar]
C --> C3[Transformar / validar]
A --> A1[Escribir]
A --> A2[Comunicar]
A --> A3[Modificar / ejecutar]
Familias de herramientas
Cómo ordenar las tools según la capacidad que añaden al sistema: obtener información, ejecutar computación o producir acciones.
Ya sabemos que una tool puede leer, buscar, recuperar, calcular, transformar, escribir o ejecutar.
Esa lista es útil para reconocer operaciones concretas, pero empieza a resultar difícil de manejar cuando una aplicación dispone de muchas herramientas.
Imaginemos un sistema jurídico con estas capacidades:
buscar_contrato
obtener_anexo
consultar_proveedor
leer_correo
comparar_versiones
calcular_exposicion
validar_json
crear_ticket
guardar_informe
enviar_alerta
actualizar_estadoNo todas hacen lo mismo.
Y, más importante, no introducen el mismo tipo de riesgo.
Para construir un modelo mental simple, las clases UDD las agrupan en tres grandes familias:
información, computación y acción.
Idea central
Una tool puede ampliar el sistema de tres maneras principales:
Información → obtiene datos o documentos.
Computación → calcula, valida o transforma.
Acción → modifica estado o produce una comunicación.
La clasificación no es universal ni excluyente. Su utilidad es obligarnos a preguntar qué clase de poder operacional estamos agregando.
Una clasificación funcional, no comercial
Los proveedores pueden agrupar herramientas de muchas maneras.
Algunos hablan de búsqueda, código, navegación, conectores, actions, plugins o integrations.
Aquí utilizamos una clasificación distinta porque queremos responder una pregunta pedagógica:
¿qué cambia en el sistema cuando añado esta tool?
Si lo principal que cambia es la información disponible, estamos cerca de la familia de información.
Si lo principal es la posibilidad de ejecutar una operación sobre datos, hablamos de computación.
Si lo principal es producir un efecto sobre otro sistema, hablamos de acción.
1. Herramientas de información
Las herramientas de información permiten obtener datos, documentos o estados que no estaban ya disponibles en el contexto.
Ejemplos:
buscar_contrato(...)
obtener_documento(...)
consultar_proveedor(...)
leer_correo(...)
consultar_jurisprudencia(...)
obtener_estado_ticket(...)Su función principal es responder:
¿qué información necesitamos traer al trabajo?
Información pública
Una tool puede consultar fuentes públicas.
Por ejemplo:
buscar_web("nueva regulación IA Chile")El problema principal puede ser actualidad, procedencia o calidad de la fuente.
Información privada
También puede acceder a información interna:
buscar_contrato("ACME")Aquí la pregunta cambia.
No basta con que el documento exista.
Necesitamos saber si la identidad que realiza la consulta tiene permiso para verlo.
En el entorno jurídico esta diferencia es especialmente importante porque la información puede estar segregada por cliente, matter, equipo o función.
Información estructurada
Una tool no tiene que recuperar documentos completos.
Puede consultar un sistema y devolver un dato preciso:
consultar_proveedor("ACME")Salida:
{
"estado": "aprobado_condicionalmente",
"criticidad": "alta",
"responsable": "Procurement"
}Eso puede ser mucho más eficiente que entregar al modelo una base de datos completa.
Herramientas de información y grounding
Google describe la recuperación de información como una de las formas más fundamentales de ampliar un sistema: permite consultar fuentes actuales, privadas o estructuradas antes de producir una respuesta.
La intuición es sencilla.
En vez de pedir:
¿Qué estado tiene este proveedor?y confiar en que el modelo lo sepa, el sistema puede hacer:
consultar_proveedor("ACME")obtener el dato y recién entonces responder.
Eso no garantiza verdad absoluta, pero mejora la procedencia de la información utilizada.
2. Herramientas de computación
La segunda familia ejecuta operaciones sobre información.
Ejemplos:
calcular_ratio(...)
comparar_versiones(...)
validar_json(...)
convertir_archivo(...)
ejecutar_codigo(...)
extraer_tabla(...)La pregunta principal es:
¿qué operación conviene delegar a una función especializada?
Cálculo
Un ejemplo sencillo:
calcular_ratio(800000, 2400000)Resultado:
0.333333La tool garantiza mejor la operación matemática que pedir al modelo que improvise el cálculo en lenguaje natural.
Validación
También podemos utilizar una función para comprobar estructura.
Por ejemplo:
validar_json(resultado)Puede devolver:
VALIDOPero aquí reaparece una distinción transversal del curso:
JSON VÁLIDO
≠
CONTENIDO VERDADEROLa herramienta puede confirmar la estructura sin confirmar la sustancia.
Transformación
Otra posibilidad es transformar un recurso:
comparar_versiones(contrato_v1, contrato_v2)La salida podría identificar qué bloques cambiaron.
Después el modelo puede interpretar cuáles de esas diferencias tienen relevancia jurídica.
Esta división es útil porque permite reservar al modelo la tarea de evaluación y entregar a software determinista las operaciones que pueden realizarse mejor de esa manera.
Computación no significa necesariamente “IA”
Ésta es una enseñanza importante.
Una tool puede ser extremadamente útil precisamente porque no es generativa.
Puede ser una función tradicional que:
suma
compara
ordena
convierte
valida
buscaEl sistema completo puede combinar componentes probabilísticos y deterministas.
No hay ninguna ventaja automática en pedir al LLM que haga todo.
El mejor componente depende de la operación
Si una tarea puede resolverse mediante una regla simple, una consulta estructurada o una función determinista, utilizar esa capacidad puede aumentar control y verificabilidad.
El modelo puede concentrarse en aquello que requiere interpretación, lenguaje o selección contextual.
3. Herramientas de acción
La tercera familia produce efectos sobre el entorno.
Ejemplos:
guardar_informe(...)
crear_ticket(...)
actualizar_estado(...)
enviar_correo(...)
crear_evento(...)
modificar_registro(...)Ahora la pregunta principal es:
¿qué puede cambiar si esta operación se ejecuta?
Acción interna
Una tool puede crear un objeto dentro de la organización:
crear_borrador_revision(...)El efecto puede ser moderado si el registro queda claramente marcado como borrador.
Acción comunicativa
Otra tool puede enviar información:
enviar_alerta(...)Aquí el efecto ya cruza la frontera del espacio de trabajo del modelo.
Acción decisoria o crítica
Más sensible todavía sería:
aprobar_proveedor(...)
modificar_permisos(...)
eliminar_documento(...)La existencia técnica de una función así no significa que deba exponerse al sistema ni que el modelo deba poder seleccionarla.
El mismo sistema puede tener las tres familias
Una revisión contractual conectada podría utilizar:
INFORMACIÓN
buscar_documentos
consultar_excepciones
leer_registro_proveedor
COMPUTACIÓN
comparar_versiones
calcular_exposicion
validar_salida
ACCIÓN
crear_borrador_revision
actualizar_estado
enviar_alertaLas tres familias se combinan para una misma tarea, pero cumplen funciones distintas.
La clasificación también ayuda a diseñar permisos
Supongamos que una persona puede usar el sistema de revisión contractual.
No necesitamos concederle automáticamente todas las herramientas disponibles.
Podríamos tener:
PERMITIDAS
buscar_documentos
obtener_documento
calcular_exposicion
crear_borrador_revision
NO DISPONIBLES
eliminar_documento
modificar_permisos
aprobar_proveedorLa clasificación por familias permite comenzar a construir una política más granular.
Pero el riesgo no depende sólo de la familia
Sería un error convertir la clasificación en una escala fija como:
información = bajo riesgo
computación = medio
acción = altoNo siempre funciona así.
Pensemos en estas dos operaciones:
leer 500.000 fichas clínicas identificablesversus:
crear un borrador de nota interna en entorno de pruebaLa primera es “información”.
La segunda es “acción”.
Sin embargo, la primera puede ser muchísimo más sensible.
Necesitamos considerar otras variables.
Seis variables de riesgo
Una forma práctica de analizar una tool es mirar:
1. Sensibilidad
¿Qué clase de información toca?
2. Alcance
¿Sobre cuántos objetos o sistemas puede operar?
3. Exterioridad
¿El efecto permanece dentro del entorno o llega a terceros?
4. Reversibilidad
¿Puede deshacerse fácilmente?
5. Autoridad
¿La operación representa una decisión institucional?
6. Trazabilidad
¿Puede reconstruirse qué ocurrió?
Con estas variables podemos comparar herramientas de manera mucho más útil que mirando sólo su nombre.
Una matriz aplicada al caso contractual
| Tool | Familia | Sensibilidad | Efecto | Reversibilidad | Control razonable |
|---|---|---|---|---|---|
buscar_contrato |
Información | alta | lectura | alta | acceso por matter |
calcular_ratio |
Computación | baja | interno | alta | validación de inputs |
crear_borrador_revision |
Acción | media | escritura interna | alta | revisión posterior |
enviar_correo_proveedor |
Acción | alta | externo | baja | autorización humana |
modificar_permisos_DMS |
Acción | crítica | sistémico | variable | normalmente fuera de alcance |
La tabla no es una política universal.
Muestra el tipo de análisis que la clasificación permite iniciar.
Familias y arquitectura jurídica
La clasificación también mejora la conversación entre abogados y equipos técnicos.
Si alguien dice:
“Queremos conectar la IA con el correo”
podemos preguntar:
¿para información?
→ leer mensajes
¿para computación?
→ clasificar o resumir
¿para acción?
→ enviar respuestasSon arquitecturas muy distintas.
Lo mismo con un DMS:
buscar
leer
crear borrador
reemplazar documento
eliminar
cambiar permisosDecir solamente “integración con DMS” oculta demasiado.
Herramientas de información y privacidad
En una práctica jurídica, muchas tools de información operan sobre material sensible.
Eso exige preguntas como:
¿qué identidad realiza la consulta?
¿qué carpetas puede ver?
¿se respetan los permisos existentes?
¿el resultado queda en el contexto del modelo?
¿se registra la operación?La herramienta puede ser read-only y seguir requiriendo controles fuertes.
Herramientas de acción y responsabilidad
Las tools de acción introducen otra clase de preguntas:
¿quién autoriza?
¿puede ejecutarse automáticamente?
¿qué ocurre si el modelo se equivoca?
¿hay confirmación?
¿puede revertirse?
¿queda evidencia de quién aprobó?Estas preguntas preparan el último nodo de la sección, dedicado específicamente a permisos.
El caso conductor
Nuestro sistema analiza el contrato ACME.
Primero utiliza tools de información:
buscar_documentos("ACME")
consultar_excepciones("ACME")Después tools de computación:
comparar_versiones(...)
calcular_ratio(...)Finalmente podría proponer una tool de acción:
crear_borrador_revision(...)La secuencia parece natural.
Pero todavía falta explicar algo esencial.
¿Cómo llega el sistema desde una instrucción como:
“Busca el anexo vigente”
hasta una llamada concreta a:
buscar_documentos(
proveedor = "ACME",
tipo = "anexo_seguridad"
)Ese mecanismo es el tema de la siguiente página.
Una misma fuente puede dar origen a tools de familias distintas
La clasificación no depende del nombre del sistema conectado.
Un mismo correo electrónico puede dar lugar a:
INFORMACIÓN
leer_correo
COMPUTACIÓN
clasificar_correo
ACCIÓN
enviar_respuestaUn mismo DMS puede dar lugar a:
INFORMACIÓN
buscar_documento
COMPUTACIÓN
comparar_versiones
ACCIÓN
reemplazar_documentoY un mismo sistema de procurement puede ofrecer:
INFORMACIÓN
consultar_estado_proveedor
COMPUTACIÓN
calcular_score
ACCIÓN
actualizar_estado_proveedorPor eso no debemos clasificar herramientas diciendo “correo”, “DMS” o “CRM”. Esas palabras identifican sistemas. La familia describe qué operación se realiza sobre ellos.
La familia ayuda a construir un inventario de tools
Cuando una organización empieza a conectar capacidades, resulta útil mantener un inventario comprensible.
Por ejemplo:
| Tool | Sistema | Familia | Entrada principal | Efecto |
|---|---|---|---|---|
buscar_contrato |
DMS | Información | proveedor | devuelve candidatos |
leer_hilo |
correo | Información | id del hilo | devuelve mensajes |
comparar_versiones |
local | Computación | dos archivos | devuelve diferencias |
calcular_exposicion |
función | Computación | montos | devuelve ratio |
crear_ticket |
Legal Ops | Acción | hallazgo | crea registro |
enviar_alerta |
correo | Acción | destinatario + mensaje | comunica |
Este inventario permite responder una pregunta que será cada vez más importante:
¿Qué puede hacer realmente esta aplicación?
No qué promete comercialmente, sino qué operaciones tiene disponibles.
La tool inventory es también un objeto de gobierno
Huyen utiliza la expresión tool inventory para referirse al conjunto de herramientas a disposición de un agente. La idea también es útil antes de llegar a agentes.
Si el sistema dispone de veinte tools, podemos auditar:
cuáles son de lectura
cuáles escriben
cuáles acceden a información sensible
cuáles producen efectos externos
cuáles son necesarias
cuáles están duplicadasEsto permite evitar una arquitectura donde las capacidades se agregan indefinidamente sin revisar si siguen siendo necesarias.
No todas las tools de acción deberían exponerse al modelo
Una aplicación puede necesitar una operación internamente sin hacerla seleccionable por el modelo.
Por ejemplo, el software puede tener técnicamente una función:
eliminar_cache_temporal()que forma parte del funcionamiento del sistema, pero que no tiene sentido ofrecer como tool al modelo.
La categoría “tool” en este curso se refiere a capacidades expuestas para participar en la tarea. Eso obliga a elegir deliberadamente el inventario.
Una buena pregunta de diseño es:
¿qué ganamos al permitir que esta capacidad sea invocada dentro del flujo de trabajo?
Si no existe una respuesta clara, quizás no debe formar parte del inventario disponible.
Familias y errores característicos
Cada familia tiende a producir preguntas diferentes cuando algo sale mal.
INFORMACIÓN
¿trajo la fuente correcta?
¿respetó el alcance?
¿el dato estaba actualizado?
COMPUTACIÓN
¿la operación fue correcta?
¿los inputs eran correctos?
¿la transformación perdió información?
ACCIÓN
¿debía ejecutarse?
¿estaba autorizada?
¿el efecto puede revertirse?Esta clasificación de errores es más útil que una advertencia genérica de que “la IA puede equivocarse”.
Nos permite localizar el tipo de control necesario.
Qué debes recordar
Las tools pueden agruparse pedagógicamente en tres familias:
INFORMACIÓN
traer datos o documentos
COMPUTACIÓN
calcular, validar o transformar
ACCIÓN
escribir, comunicar o modificarLa clasificación ayuda a comprender qué capacidad estamos agregando y qué controles pueden ser necesarios.
Pero no debe confundirse con una escala rígida de riesgo.
El riesgo depende también de sensibilidad, alcance, exterioridad, reversibilidad, autoridad y trazabilidad.
El problema que todavía queda abierto
Sabemos qué tipos de herramientas existen.
Todavía no sabemos cómo una aplicación basada en modelos puede seleccionar una herramienta, completar sus argumentos, ejecutarla y utilizar el resultado.
Eso es precisamente lo que estudiaremos a continuación mediante el concepto de tool calling.