flowchart LR
A[Documento] --> B[Extraer]
B --> C[Clasificar]
C --> D[Comparar]
D --> E[Evaluar]
E --> F[Verificar]
F --> G[Redactar]
Diseñar skills pequeñas
Por qué conviene descomponer el trabajo profesional en capacidades pequeñas, delimitadas y combinables como extraer, clasificar, comparar, evaluar, redactar y verificar.
Una vez que comprendemos qué puede contener una skill aparece una tentación inmediata.
Si podemos encapsular una metodología, ¿por qué no construir una sola capacidad denominada:
Revisar contratosy poner dentro de ella todo?
Podríamos indicarle que lea el documento, encuentre cláusulas, identifique riesgos, consulte políticas, compare versiones, clasifique desviaciones, redacte alternativas y prepare una recomendación final.
La capacidad parecería muy poderosa.
También sería difícil saber exactamente qué hace bien y qué hace mal.
El curso adopta una regla distinta:
no construir un gran abogado artificial; construir capacidades pequeñas, delimitadas y combinables.
Idea central
Una skill pequeña no es necesariamente una tarea intelectualmente simple.
Es una capacidad con una frontera funcional clara.
Cuanto mejor podemos identificar su entrada, transformación, salida y criterio de éxito, más fácil resulta evaluarla, mantenerla, reutilizarla y gobernarla.
El problema de la capacidad monolítica
Supongamos que una única skill recibe un contrato y devuelve:
“No recomiendo aprobarlo porque la cláusula de responsabilidad es insuficiente y el DPA no cumple el estándar interno.”
La conclusión podría ser correcta.
Si es incorrecta, necesitamos investigar.
¿El sistema no encontró una cláusula?
¿Extrajo mal el PDF?
¿Confundió la obligación del cliente con la del proveedor?
¿Recuperó una política antigua?
¿Comparó mal los textos?
¿Clasificó incorrectamente el riesgo?
¿Redactó una conclusión más fuerte que la evidencia?
En una capacidad monolítica todas esas transformaciones están ocultas dentro del mismo resultado.
Si las separamos, obtenemos puntos de observación.
El orden anterior es solamente ilustrativo. No toda tarea seguirá exactamente esa secuencia.
La lección es modular: operaciones diferentes merecen fronteras diferentes cuando sus errores, criterios o resultados son distintos.
Extraer
Extraer responde una pregunta muy limitada:
¿Qué información aparece en el material?
Por ejemplo:
Extrae todas las obligaciones expresas del proveedor
relativas a seguridad de la información.Una salida podría ser:
Obligación:
Mantener medidas técnicas y organizativas apropiadas.
Ubicación:
Cláusula 8.2.
Condición:
Durante la vigencia del servicio.
Evidencia:
[fragmento correspondiente]La skill no debería decidir todavía si la obligación es suficiente.
Eso sería evaluación.
Qué hace difícil una extracción jurídica
“Extraer” puede sonar mecánico, pero los documentos jurídicos contienen definiciones, referencias cruzadas, excepciones, obligaciones condicionadas, listas, anexos, fórmulas como “salvo que” y disposiciones de prevalencia.
Una buena skill de extracción puede necesitar metodología sofisticada.
Pequeña no significa trivial.
Significa que sabemos qué transformación esperamos:
documento
↓
elementos identificadosQué no debería mezclar
Una extracción no debería convertirse silenciosamente en:
“Esta obligación es insuficiente.”a menos que la skill haya sido diseñada también para evaluar.
Mantener esa frontera permite comprobar primero si la evidencia fue encontrada correctamente.
Clasificar
Clasificar responde:
¿A qué categoría pertenece este elemento?
Por ejemplo, después de extraer una cláusula podemos clasificarla como:
confidencialidad
protección de datos
seguridad
propiedad intelectual
responsabilidad
terminaciónO podemos clasificar una desviación como:
compatible
menor
material
no determinadaUna clasificación necesita categorías definidas
Pedir:
Clasifica el riesgo como alto, medio o bajo.parece sencillo.
Pero si nunca explicamos qué significa cada categoría, la skill tendrá que completar el criterio.
Una clasificación más controlada podría definir:
ALTO
Puede impedir aprobación sin modificación o escalamiento.
MEDIO
Requiere aclaración o negociación, pero no bloquea
necesariamente la aprobación.
BAJO
Debe documentarse, pero normalmente no altera la decisión.Ahora existe un objeto evaluable.
Comparar
Comparar responde:
¿En qué se parecen y en qué difieren dos objetos?
En Derecho esta capacidad aparece constantemente:
- dos versiones de un contrato;
- contrato vs. estándar;
- política antigua vs. nueva;
- propuesta comercial vs. SOW;
- norma nacional vs. estándar internacional.
Una comparación genérica como:
Compara estos textos.puede producir diferencias superficiales.
Una skill contractual puede establecer que debe identificar cambios en sujeto, verbo normativo, alcance, plazo, monto, condición, excepción, remedio y referencias cruzadas.
Por ejemplo:
| Elemento | Versión A | Versión B | Cambio |
|---|---|---|---|
| Cap | 12 meses | 6 meses | reduce límite |
| Fraude | excluido | excluido | sin cambio |
| Confidencialidad | fuera del cap | dentro del cap | cambio sustantivo |
La salida hace visible el delta.
Comparar no es evaluar
Podemos detectar:
12 meses → 6 mesessin afirmar todavía:
el cambio es inaceptablePara eso necesitamos un criterio.
Separar comparación y evaluación puede ser extremadamente útil cuando queremos conservar evidencia del cambio antes de juzgarlo.
Evaluar
Evaluar responde:
¿Qué significa este hallazgo frente a un criterio?
Podemos representarlo así:
hallazgo
+
criterio
↓
evaluaciónEjemplo:
Hallazgo:
cap = 6 meses.
Criterio aplicable:
cap mínimo = 12 meses.
Evaluación:
desviación respecto del estándar.La evaluación es donde muchas respuestas empiezan a adquirir carácter normativo o profesional.
Por eso exige especial cuidado con la fuente del criterio.
El riesgo de evaluar sin criterio visible
Comparemos:
“La cláusula es riesgosa.”
con:
“El cap propuesto es de seis meses; el estándar vigente exige doce; por tanto existe una desviación material según la matriz de aprobación.”
La segunda afirmación permite reconstruir:
hecho
→ criterio
→ conclusiónLa primera oculta el criterio.
Redactar
Redactar responde:
¿Cómo transformamos contenido ya obtenido en un documento o comunicación?
Puede utilizarse para comentario contractual, cláusula alternativa, correo, memo, síntesis ejecutiva o pregunta a la contraparte.
Por ejemplo:
Entrada:
hallazgo validado + posición aprobada.
Salida:
comentario para negociación.Una skill de redacción puede especificar audiencia, tono, terminología, longitud, estructura, elementos que debe preservar y elementos que no debe introducir.
Por qué conviene separar redacción de análisis
La generación de lenguaje fluido puede ocultar errores.
Si pedimos simultáneamente:
analiza y redactaun texto persuasivo puede hacer difícil distinguir qué parte era evidencia y qué parte fue elaboración.
Una arquitectura más controlada puede seguir:
hallazgo
↓
verificación
↓
posición aprobada
↓
redacciónAsí la capacidad de escribir no determina por sí sola qué posición jurídica debe adoptarse.
Verificar
Verificar responde:
¿El resultado anterior cumple una condición comprobable?
Una verificación débil sería:
Revisa si tu respuesta está bien.Una skill de verificación debería tener un objeto más concreto.
Por ejemplo:
Para cada hallazgo:
1. localiza la evidencia citada;
2. comprueba que el fragmento exista;
3. determina si respalda la afirmación;
4. marca cualquier inferencia no sustentada;
5. identifica información faltante.La salida podría ser:
| Hallazgo | Fuente existe | Fuente respalda | Estado |
|---|---|---|---|
| Cap = 6 meses | Sí | Sí | Verificado |
| Confidencialidad fuera del cap | Sí | No | No respaldado |
La verificación no garantiza infalibilidad.
Pero cambia la pregunta desde:
“¿te parece correcto?”
hacia:
“¿puedes demostrar este punto mediante una prueba definida?”
Seis capacidades, seis transformaciones
Podemos resumir:
| Skill | Pregunta | Transformación |
|---|---|---|
| Extraer | ¿Qué aparece? | documento → hallazgos |
| Clasificar | ¿Qué tipo es? | elemento → categoría |
| Comparar | ¿Qué cambió? | objetos → delta |
| Evaluar | ¿Qué significa frente a una regla? | hallazgo + criterio → juicio |
| Redactar | ¿Cómo comunicarlo? | contenido validado → texto |
| Verificar | ¿Está respaldado? | afirmación + evidencia → estado |
Este mapa permite diseñar sistemas más comprensibles.
La granularidad correcta
La recomendación “skills pequeñas” tampoco debe convertirse en dogma.
Podemos fragmentar demasiado.
Imagine que construimos:
skill_detectar_verbo
skill_detectar_sujeto
skill_detectar_numero
skill_detectar_fecha
skill_detectar_puntoQuizás la arquitectura se vuelva más difícil de mantener que una skill de extracción bien definida.
El objetivo no es maximizar el número de piezas.
Es encontrar fronteras útiles.
Una prueba práctica
Pregunte:
¿Esta operación posee un objetivo, una entrada, un resultado y errores suficientemente distintos como para merecer evaluación separada?
Si la respuesta es sí, una skill independiente puede tener sentido.
Otra pregunta:
¿Puedo modificar esta metodología sin tener que cambiar todas las demás?
Si sí, la separación puede mejorar mantenimiento.
Ventajas de diseño modular
Los materiales del curso destacan varias ventajas.
La primera es evaluación más simple. Podemos probar extracción con documentos conocidos, comparación con pares de versiones y clasificación con casos etiquetados. No necesitamos evaluar el sistema completo cada vez.
La segunda es mantenimiento local. Si cambia la metodología para detectar una limitación de responsabilidad, podemos modificar esa skill sin alterar necesariamente todas las demás.
La tercera es reutilización. La misma skill de comparación puede servir para contrato A vs. contrato B, política v3 vs. v4 o cláusula vs. estándar, siempre que su frontera esté bien diseñada.
La cuarta es reducción de contradicciones. Una gran instrucción suele acumular reglas que empiezan a chocar; las skills pequeñas reducen ese espacio.
La quinta es trazabilidad. Podemos registrar qué capacidad produjo un hallazgo y qué versión estaba activa.
Componer no significa perder fronteras
Supongamos un proceso de revisión:
flowchart LR
A[Extraer] --> B[Clasificar]
B --> C[Comparar]
C --> D[Evaluar]
D --> E[Verificar]
E --> F[Redactar]
Cada salida puede transformarse en input de la siguiente operación.
Pero debe mantenerse la procedencia.
Por ejemplo, la evaluación debería poder decir:
hallazgo_base = H-17
criterio = estándar v4 §8.4La redacción final no debería borrar esa cadena.
Un caso de error propagado
Imaginemos que la skill de extracción interpreta erróneamente una excepción y concluye que el contrato no contiene carve-outs.
La comparación puede ser perfectamente correcta respecto de esa extracción defectuosa. La evaluación puede clasificar el riesgo como alto. La redacción final puede ser impecable.
El resultado suena convincente, pero el error comenzó mucho antes.
La modularidad permite volver al origen.
Sin ella, podríamos concluir simplemente:
“la IA se equivocó”.
No confundir skills pequeñas con agentes especializados
Todavía no estamos construyendo un “agente extractor”, un “agente evaluador” y un “agente redactor”.
Una skill es una capacidad.
Un agente implica una arquitectura distinta, con capacidad para seleccionar dinámicamente acciones o próximos pasos dentro de límites.
Convertir cada función en “agente” sería anticipar una capa que todavía no necesitamos.
Primero conviene aprender a distinguir capacidades.
El caso conductor
Para revisar el contrato de proveedor de IA podemos imaginar inicialmente estas skills:
S1 extraer cláusulas relevantes
S2 clasificar por materia
S3 comparar con estándar
S4 evaluar desviación
S5 verificar evidencia
S6 redactar comentarioEl valor de esta lista no está en que sean seis.
Está en que cada una responde una pregunta distinta.
Ahora aparece otra dificultad.
La skill S3 dice:
comparar con estándar¿Pero cuál estándar?
La skill S4 dice:
evaluar desviación¿Con qué política de riesgo?
La metodología ya existe.
La información sustantiva todavía no.
Qué debes recordar
Diseñar skills pequeñas significa separar operaciones con fronteras claras.
Las familias utilizadas en esta página —extraer, clasificar, comparar, evaluar, redactar y verificar— son especialmente útiles porque aparecen repetidamente en trabajo jurídico.
Una skill pequeña puede ser compleja.
Lo importante es que podamos responder:
qué recibe
qué hace
qué produce
cómo se evalúa
qué no debe hacerLa modularidad facilita evaluación, mantenimiento, reutilización y trazabilidad.
Pero descomponer demasiado también puede producir complejidad innecesaria.
La frontera correcta es funcional.
El problema que todavía queda abierto
Ya podemos construir una excelente skill para comparar una cláusula con un estándar.
Puede saber exactamente cómo comparar.
Todavía falta responder:
¿Cuál es el estándar?
Una cosa es saber hacer.
Otra es disponer de la información necesaria para hacerlo.
La página siguiente desarrolla esa diferencia: Skill ≠ Knowledge.