De una instrucción a una capacidad

Por qué un template deja de ser suficiente cuando una organización necesita estabilizar no sólo una instrucción, sino una forma de realizar una tarea profesional.

En la última página de la sección anterior llegamos a un punto importante. Ya no necesitábamos escribir una instrucción completamente nueva cada vez que aparecía una tarea semejante. Podíamos construir una template: mantener fija una estructura y sustituir solamente aquello que cambiaba de un asunto a otro.

Por ejemplo:

Compara [CLAUSULA] con [ESTANDAR]
desde la posición de [PARTE].

Identifica las diferencias materiales y entrégalas en [FORMATO].

La plantilla resuelve un problema real. Reduce repetición, disminuye variaciones accidentales y permite que una instrucción que funciona vuelva a utilizarse.

Pero imaginemos ahora que la revisión de una cláusula no consiste simplemente en completar tres variables.

El abogado debe saber qué disposiciones relacionadas buscar, qué excepciones revisar, cuándo un precedente es comparable, qué debe tratarse como evidencia, cómo separar una desviación de una preferencia negociadora, cuándo falta información y qué condiciones obligan a escalar el asunto.

En ese momento aparece un límite.

La organización no quiere reutilizar solamente la redacción de un encargo.

Quiere reutilizar una manera de hacer el trabajo.

Ese es el salto que abre esta sección.

Idea central

Un prompt formula una instrucción para una ejecución.

Una template hace reutilizable esa instrucción mediante partes variables.

Una skill, en el marco pedagógico de este handbook, hace reutilizable una capacidad o metodología delimitada.

La pregunta cambia de:

“¿Qué prompt debo escribir?”

A:

“¿Qué capacidad necesita este proceso?”

La palabra skill se utiliza de formas distintas en productos y arquitecturas concretas. Aquí no intentaremos imponer una definición universal. La utilizaremos como una categoría funcional para comprender el paso desde instrucciones reutilizables hacia capacidades profesionales más estables.

El límite de una plantilla

Consideremos una tarea recurrente: revisar cláusulas de limitación de responsabilidad en contratos tecnológicos.

Una template podría decir:

Analiza la cláusula de [MATERIA]
desde la posición de [PARTE]
aplicando [ESTANDAR].

Para cada hallazgo indica:
- texto relevante;
- diferencia;
- riesgo;
- recomendación.

La plantilla contiene una estructura razonable. Pero todavía deja ocultas preguntas metodológicas importantes.

¿Qué debe buscar exactamente el sistema cuando la materia es responsabilidad?

¿Debe revisar solamente la cláusula titulada “Limitación de responsabilidad”?

¿Debe mirar indemnidades?

¿Debe buscar excepciones en otras secciones?

¿Debe comprobar si un anexo modifica el cap?

¿Debe tratar un contrato anterior como estándar o solamente como precedente?

¿Qué hace si no encuentra la política vigente?

¿Puede concluir que la cláusula es aceptable?

Una template puede contener todas esas instrucciones. Podríamos seguir agregándolas hasta construir un documento enorme.

Pero entonces aparece una señal de diseño: quizás aquello que estamos intentando conservar ya no es simplemente una plantilla lingüística.

Estamos intentando conservar una metodología.

Tres niveles, tres preguntas

Conviene observar la progresión sin pensar todavía en detalles técnicos.

Nivel Pregunta principal Ejemplo
Prompt ¿Qué quiero que hagas ahora? “Compara esta cláusula con el estándar.”
Template ¿Cómo reutilizo esta instrucción? “Compara [CLÁUSULA] con [ESTÁNDAR].”
Skill ¿Cómo se realiza correctamente esta clase de tarea? Metodología de revisión de responsabilidad contractual

No se trata de que cada nivel elimine al anterior.

Una skill puede contener prompts.

Puede utilizar templates.

Puede recibir parámetros.

La progresión es acumulativa.

flowchart LR
    A[Prompt<br/>instrucción puntual] --> B[Template<br/>instrucción parametrizable]
    B --> C[Skill<br/>metodología reutilizable]

La diferencia importante es qué intentamos estabilizar.

Con el prompt estabilizamos poco: una instrucción concreta.

Con la template estabilizamos una estructura de instrucción.

Con la skill intentamos estabilizar una forma de ejecutar una tarea.

Del texto de la instrucción al método profesional

Veamos la misma revisión en tres versiones.

Prompt

Revisa esta cláusula de responsabilidad.

El sistema debe completar una gran cantidad de decisiones.

Template

Revisa [CLAUSULA] desde la posición de [PARTE]
y compárala con [ESTANDAR].

Ahora algunas decisiones se convierten en parámetros.

Skill

La capacidad podría describirse así:

CAPACIDAD

Evaluar una cláusula de limitación de responsabilidad
desde la posición del cliente.

MÉTODO

1. Identificar el cap general.
2. Identificar la base de cálculo.
3. Identificar excepciones y carve-outs.
4. Revisar indemnidades y disposiciones relacionadas.
5. Revisar anexos que puedan modificar el régimen.
6. Obtener el estándar vigente.
7. Comparar cada componente por separado.
8. Identificar precedentes comparables cuando exista desviación.
9. Distinguir política, estándar, precedente y excepción.
10. Señalar información faltante.
11. Mantener evidencia para cada hallazgo.
12. Producir una salida uniforme para revisión humana.

Aquí la diferencia se vuelve visible.

La organización ya no conserva solamente una frase.

Conserva una secuencia de operaciones y controles que representa una manera de trabajar.

Una capacidad no es “conocimiento jurídico general”

La palabra capacidad podría producir otra confusión.

Podría parecer que estamos intentando construir una especie de “abogado digital” que contenga todo el conocimiento y realice cualquier tarea.

El curso adopta la dirección contraria.

Una skill debería ser delimitada.

Por ejemplo:

extraer obligaciones del proveedor

es una capacidad.

comparar dos versiones de una cláusula

es otra.

verificar si un hallazgo está respaldado por un documento

es otra.

En cambio:

hacer Derecho

no constituye una capacidad útil para diseño.

Tampoco:

revisar cualquier asunto jurídico

La utilidad aparece cuando podemos identificar:

  • qué entra;
  • qué transformación se espera;
  • qué reglas gobiernan la tarea;
  • qué resultado debería producir;
  • cómo reconocer si falló.

Eso permite convertir una práctica profesional en algo más observable.

La skill como explicitación de conocimiento práctico

Mucho trabajo jurídico funciona mediante conocimiento práctico que no siempre está formalizado.

Un abogado experimentado puede saber que, al revisar una cláusula de responsabilidad, debe mirar inmediatamente la definición de daños, las indemnidades, las excepciones, el SLA, el régimen de seguridad, las disposiciones de confidencialidad y ciertos anexos.

Puede hacerlo sin recitar conscientemente un checklist.

Pero si queremos reutilizar esa capacidad en una aplicación, compartirla entre equipos o evaluarla sistemáticamente, necesitamos hacer explícitas al menos las partes relevantes del método.

La skill funciona entonces como una unidad de conocimiento procedimental: no contiene solamente una posible respuesta; contiene instrucciones sobre cómo llegar a una clase de resultado.

Esta distinción será crucial más adelante.

Cuándo vale la pena convertir una tarea en skill

No toda interacción necesita transformarse en una capacidad formalizada.

Si una persona pide una única vez:

Corrige la redacción de este párrafo.

puede ser innecesario construir algo más.

En cambio, vale la pena pensar en una skill cuando aparecen varias señales: la tarea se repite, varias personas necesitan realizarla de forma semejante, existe una metodología reconocible, hay errores recurrentes que conviene controlar, la salida debe mantener cierta consistencia, queremos evaluar la capacidad separadamente o necesitamos saber qué reglas produjo cada resultado.

La lógica es parecida a crear una buena plantilla, pero el objeto de reutilización es más rico.

Un ejemplo: comparación de versiones contractuales

Supongamos que todos los días recibimos nuevas versiones de contratos.

Podríamos conservar esta template:

Compara [VERSION_A] y [VERSION_B].
Indica los cambios importantes.

Sin embargo, distintos usuarios pueden entender “importante” de manera diferente.

Una skill de comparación contractual podría establecer:

1. Alinear cláusulas equivalentes aunque cambie su numeración.
2. Detectar adiciones, eliminaciones y modificaciones.
3. Separar cambios puramente formales de cambios sustantivos.
4. Identificar si cambia:
   - una obligación;
   - un derecho;
   - un plazo;
   - un monto;
   - una condición;
   - una excepción;
   - un remedio.
5. Mantener referencia a ambas versiones.
6. No inferir impacto jurídico cuando falten antecedentes.
7. Entregar una matriz de diferencias.

La template decía qué encargo formular.

La skill describe cómo ejecutar la comparación.

De la improvisación a una capacidad nombrable

Una ventaja práctica de esta separación es que podemos empezar a hablar de capacidades con nombres estables:

skill: extraer obligaciones
skill: comparar cláusulas
skill: revisar responsabilidad
skill: verificar evidencia

Eso permite que una organización discuta su sistema de manera diferente.

En vez de preguntar:

“¿Cuál era el prompt que usábamos?”

puede preguntar:

“¿Qué versión de la skill de responsabilidad utilizamos?”

O:

“¿La skill de verificación comprobó esta afirmación?”

La conversación cambia desde frases hacia componentes funcionales.

Skill no significa tool

Todavía debemos proteger una frontera importante.

Una skill puede decir:

Busca el estándar interno vigente.

Pero esa instrucción no significa que el sistema posea automáticamente acceso al repositorio donde se encuentra.

La skill expresa cómo debería realizarse la tarea.

Una tool, que estudiaremos en la sección siguiente, aporta un medio para consultar, calcular o actuar sobre sistemas externos.

Por ahora:

Skill = capacidad metodológica
Tool  = medio operacional

No adelantaremos la arquitectura de tools. Basta comprender que saber qué debería hacerse y tener medios para hacerlo son problemas distintos.

Skill tampoco significa workflow

Podemos representar dentro de una skill una secuencia metodológica.

Eso no convierte automáticamente la skill en un workflow.

Más adelante utilizaremos workflow para tratar explícitamente estados, secuencias, condiciones de avance, transiciones y responsables.

En esta sección nos interesa algo previo: identificar qué capacidades existen antes de organizarlas en un proceso mayor.

El caso conductor

Retomemos la pregunta que acompaña el handbook:

Llegó un contrato de proveedor de IA. ¿Puede aprobarse?

En la sección anterior aprendimos a especificar la tarea.

Podíamos utilizar una template como:

Revisa [TIPO_DE_CONTRATO]
desde la posición de [PARTE]
priorizando [MATERIAS].

Distingue texto, inferencia e información faltante.

Ahora damos un paso adicional.

En vez de depender de que el usuario describa cada vez toda la metodología, queremos disponer de capacidades reutilizables:

extraer cláusulas relevantes
        ↓
comparar con estándar
        ↓
clasificar desviaciones
        ↓
verificar evidencia

Todavía no estamos organizando automáticamente el proceso completo.

Tampoco hemos conectado repositorios.

Ni hemos introducido agentes.

Estamos construyendo los bloques de saber hacer.

Qué debes recordar

Un prompt y una skill no son sinónimos.

El prompt formula una instrucción.

La template hace esa instrucción reutilizable mediante variables y parámetros.

La skill intenta encapsular una capacidad profesional delimitada.

El cambio importante no es de longitud.

Una skill no es simplemente un prompt más largo.

El cambio es de función:

instrucción
    ↓
instrucción reutilizable
    ↓
metodología reutilizable

Una skill puede contener prompts y templates, pero su unidad conceptual es la capacidad.

Tampoco debemos confundir capacidad metodológica con capacidad operacional. Saber que hay que consultar una política no significa todavía poder acceder al repositorio que la contiene.

El problema que todavía queda abierto

Ya podemos decir que necesitamos una skill para revisar una cláusula.

Pero todavía no sabemos qué significa diseñarla bien.

¿Qué elementos debe contener?

¿Cómo se define su alcance?

¿Dónde se ubican instrucciones, criterios, ejemplos y controles?

¿Cómo especificamos el output?

¿Y cómo indicamos cuándo una skill debe o no debe utilizarse?

La siguiente página abre esa caja y estudia la anatomía de una skill.

Back to top