flowchart TB
S[Skill<br/>metodología] --> T[Tarea actual]
K1[Knowledge v3<br/>enero] --> T
K2[Knowledge v4<br/>abril] --> T
Skill ≠ Knowledge
Por qué saber cómo realizar una tarea es distinto de disponer de la información necesaria para realizarla y por qué conviene separar metodología y conocimiento.
Ya podemos diseñar una skill razonablemente sofisticada.
Supongamos que tenemos una capacidad llamada:
comparar_limitacion_responsabilidadLa skill sabe qué componentes identificar, qué excepciones revisar, cómo separar cap general y límites especiales, cómo registrar evidencia, cómo representar una desviación y cuándo abstenerse.
La metodología puede ser excelente.
Ahora le entregamos esta cláusula:
La responsabilidad agregada del proveedor no excederá los pagos efectuados durante los tres meses anteriores.
Y preguntamos:
¿Cumple nuestro estándar?
La skill sabe cómo responder esa pregunta.
Pero todavía puede faltarle la pieza decisiva:
¿cuál es nuestro estándar?
Esta diferencia constituye uno de los puntos centrales de toda la arquitectura.
Idea central
Skill = método.
Knowledge = información sustantiva.
Una cosa es saber cómo hacer una tarea.
Otra es disponer de la información necesaria para hacerla en este asunto.
Saber comparar no es conocer el estándar
Podemos expresar una skill así:
1. Identifica el cap.
2. Obtén el estándar aplicable.
3. Compara ambos.
4. Identifica desviaciones.
5. Explica el resultado.La skill contiene el método.
Pero la regla:
Para proveedores SaaS críticos,
el cap mínimo es equivalente a doce meses de cargos.es información.
La metodología podría permanecer igual aunque el valor cambie a seis meses o aunque existan tres estándares distintos según la categoría de proveedor.
Eso revela una diferencia de ciclo de vida.
La metodología debería cambiar poco
Una buena metodología de revisión contractual puede permanecer relativamente estable:
identificar
→ recuperar criterio
→ comparar
→ evaluar
→ verificarPuede mejorarse, por supuesto.
Pero no debería cambiar cada vez que la organización actualiza un umbral.
El conocimiento puede cambiar mucho
En cambio, la información sustantiva puede variar con frecuencia:
- políticas;
- estándares;
- precedentes;
- versiones;
- excepciones;
- responsables;
- matrices de riesgo;
- anexos;
- documentos regulatorios;
- instrucciones internas.
Por eso los materiales del curso formulan una regla sencilla:
La metodología debe cambiar poco. El conocimiento puede cambiar mucho. Por eso conviene separarlos.
Qué ocurre cuando no los separamos
La confusión produce varios patrones de mal diseño.
Meter toda la documentación dentro de una instrucción gigantesca
Podríamos crear:
SKILL_REVISION_CONTRATOS.txty copiar dentro metodología, política de privacidad, estándar de seguridad, matriz de responsabilidad, quince precedentes, reglas de continuidad y cláusulas aprobadas.
Funciona mientras todo permanece pequeño y estable.
Después aparece una nueva versión.
Ahora debemos editar la skill.
Aparece otro estándar.
La skill crece.
Después cinco skills necesitan la misma política.
La copiamos cinco veces.
Pronto el sistema mezcla método e información en un bloque difícil de mantener.
Tratar información cambiante como metodología permanente
Supongamos que incrustamos:
El cap mínimo siempre es 12 meses.dentro de la skill.
Seis meses después el estándar cambia.
La metodología no cambió.
Cambió la información.
Pero nuestra arquitectura obliga a versionar la capacidad completa.
Duplicar el mismo estándar
Imaginemos:
skill_responsabilidad
skill_due_diligence
skill_revision_saas
skill_negociacionTodas contienen la misma regla.
Actualizamos tres.
Olvidamos una.
Ahora dos ejecuciones pueden utilizar estándares diferentes sin que nadie lo advierta.
No saber qué versión se utilizó
Una revisión realizada en enero puede haber aplicado:
Política v3y una realizada en septiembre:
Política v4Si la política está mezclada dentro de instrucciones sin procedencia clara, reconstruir la decisión se vuelve más difícil.
Confundir “puedo analizar” con “tengo acceso a la información correcta”
Éste es quizá el error más importante.
Un modelo puede ser perfectamente capaz de comparar, resumir, clasificar y argumentar.
Eso no significa que disponga del contrato correcto, la política vigente, el último precedente, el anexo aplicable o la versión actual de un manual.
Capacidad e información son dimensiones distintas.
Una analogía: método y expediente
Podemos utilizar una analogía jurídica.
Un abogado puede saber perfectamente cómo revisar una compraventa.
Ésa es capacidad profesional.
Pero si le entregamos sólo la primera página y omitimos los anexos, no puede conocer aquello que no recibió.
La analogía ayuda porque muestra que:
saber hacer
≠
tener antecedentesPero la analogía deja de servir si imaginamos que una skill “comprende” o “recuerda” como una persona. Estamos describiendo una separación arquitectónica: instrucciones procedimentales por un lado, información disponible por otro.
Qué pertenece a la skill y qué pertenece al knowledge
Consideremos una revisión de responsabilidad.
| Elemento | Skill | Knowledge |
|---|---|---|
| Identificar cap general | ✓ | |
| Revisar carve-outs | ✓ | |
| Comparar con el estándar vigente | ✓ | |
| Definir cómo representar incertidumbre | ✓ | |
| Cap mínimo = 12 meses | ✓ | |
| Lista de excepciones aprobadas | ✓ | |
| Política de datos v7 | ✓ | |
| Precedentes 2025-2026 | ✓ | |
| Matriz de escalamiento | ✓ |
La distinción no siempre es absolutamente nítida.
Por ejemplo, una skill puede contener categorías generales de riesgo y recibir sus umbrales concretos desde knowledge.
Lo importante es utilizar una prueba:
¿Este elemento describe cómo trabajar o proporciona información que puede cambiar independientemente de la metodología?
Criterios: una zona de frontera
La palabra criterio puede aparecer en ambos lados.
Criterio metodológico
Considera incompatible una cláusula cuando contradiga
el estándar vigente.Puede formar parte de la skill.
Criterio sustantivo
El estándar vigente exige 12 meses.Pertenece al knowledge.
Regla de escalamiento
Desviaciones superiores a determinado umbral requieren
aprobación del comité X.Es información organizacional que puede cambiar.
La skill puede saber:
consulta la matriz de aprobaciónsin incrustar toda la matriz.
Esta separación evita transformar la skill en un depósito de políticas.
Knowledge no es “todo lo que el modelo sabe”
En este handbook utilizaremos knowledge en un sentido arquitectónico.
No significa:
todo lo aprendido por el modelo durante entrenamiento.
Significa:
información que el sistema puede consultar o poner a disposición de la tarea.
Esto puede incluir políticas internas, estándares, precedentes, manuales, regulación, contratos anteriores, fichas de proveedor y criterios aprobados.
Algunas fuentes pueden ser privadas.
Otras públicas.
Algunas relativamente estables.
Otras cambiar semanalmente.
La característica importante es que son información sustantiva disponible para el sistema, no la metodología misma.
Actualizar conocimiento sin rediseñar la skill
Imaginemos:
Enero
Estándar v3:
cap mínimo = 6 meses.Abril
Estándar v4:
cap mínimo = 12 meses para proveedores críticos.La skill puede seguir siendo:
1. identificar cap;
2. determinar categoría;
3. recuperar estándar vigente;
4. comparar;
5. clasificar desviación.No necesitamos reescribir el método.
Cambia solamente la fuente consultada.
En distintas fechas, la misma skill puede operar sobre conocimiento diferente.
Eso mejora mantenimiento y trazabilidad.
Separar también permite jerarquías de fuentes
Una organización puede disponer de:
política aprobada
precedente negociado
correo de un abogado
borrador de política
presentación internaTodos contienen información.
No tienen la misma autoridad.
Si los mezclamos dentro de la skill, la jerarquía puede desaparecer.
Si permanecen como knowledge gobernado, podemos asociar metadatos:
tipo = política
estado = vigente
autoridad = aprobadao:
tipo = precedente
estado = excepciónLa skill puede entonces utilizar reglas como:
No tratar un precedente como política general.La metodología interpreta el estatus de la información.
No lo inventa.
Un caso: el precedente engañoso
Supongamos que encontramos un contrato anterior:
ACME 2025
cap = 6 mesesSi la skill sólo recibe ese documento puede concluir:
“La empresa acepta seis meses.”
Pero después aparece un acta:
La desviación a seis meses fue aprobada excepcionalmente.El problema no estaba necesariamente en la capacidad de comparar.
Estaba en el universo de conocimiento disponible y en cómo estaba gobernado.
Esta diferencia será central cuando estudiemos recuperación.
Separar conocimiento también permite restringir acceso
No toda skill necesita consultar todo.
Una capacidad de extracción puede operar únicamente sobre el contrato actual.
Una capacidad de comparación puede necesitar el estándar.
Una capacidad de due diligence puede requerir ficha de proveedor y políticas.
Separar knowledge permite diseñar acceso más granular.
Esto será importante más adelante cuando estudiemos tools y permisos.
Por ahora basta comprender:
una capacidad debería recibir solamente la información que necesita para cumplir su función.
La dimensión jurídica
Separar método e información tiene consecuencias directas para revisión profesional.
Permite identificar qué versión de una política se aplicó, distinguir fuente interna, norma, precedente y borrador, saber qué documento sustentó cada criterio y reconstruir si una conclusión diferente se debe a una nueva metodología o a una nueva política.
También mejora el análisis causal: si el resultado es incorrecto, podemos preguntar si la skill aplicó mal el método o si el sistema suministró información equivocada.
Qué debes recordar
Una skill puede saber perfectamente cómo realizar una tarea y seguir siendo incapaz de responder correctamente porque no posee la información necesaria.
Por eso:
SKILL
método
≠
KNOWLEDGE
información sustantivaLa metodología debería cambiar relativamente poco.
El conocimiento puede cambiar mucho.
Separarlos evita instrucciones gigantescas, duplicación, versiones invisibles, inconsistencias y mezcla entre capacidad y acceso.
Además, permite que una misma skill opere sobre distintas versiones de conocimiento sin reescribir su lógica.
El problema que todavía queda abierto
Decir “knowledge” todavía es demasiado abstracto.
¿Dónde está ese conocimiento?
¿Qué información tiene el modelo en una ejecución concreta?
¿Qué diferencia existe entre una política que forma parte del conocimiento de la organización y el archivo PDF específico que la contiene?
La página siguiente introduce tres términos para mantener precisión:
Context · Knowledge · Resources.