flowchart TB
K[Knowledge<br/>información gobernada]
R1[Resource A<br/>política]
R2[Resource B<br/>precedente]
R3[Resource C<br/>anexo]
C[Context<br/>selección para esta tarea]
K --> R1
K --> R2
K --> R3
R1 --> C
R2 --> C
R3 --> C
Context, Knowledge y Resources
Tres conceptos para distinguir la información disponible en una ejecución, el conocimiento gobernado que un sistema puede consultar y los objetos concretos desde los que puede recuperarlo.
En la página anterior separamos dos cosas:
Skill
cómo hacer
Knowledge
con qué información hacerEsa distinción resuelve un problema importante, pero todavía deja la palabra knowledge demasiado amplia.
Supongamos que una organización afirma:
“Nuestro sistema conoce las políticas contractuales de la empresa.”
¿Qué significa exactamente?
¿Las políticas están copiadas dentro del prompt?
¿Existe un repositorio?
¿El modelo recibe todos los documentos?
¿Solamente algunos fragmentos?
¿Qué versión utiliza?
¿Puede acceder a un contrato almacenado en otra aplicación?
Para responder estas preguntas necesitamos distinguir tres niveles:
Context · Knowledge · Resource.
Idea central
En el modelo pedagógico de este handbook:
Context → ¿qué información está disponible para el modelo en esta ejecución?
Knowledge → ¿qué información gobernada sabe o puede consultar el sistema?
Resource → ¿qué objeto concreto puede recuperarse o utilizarse?
El contexto es transitorio.
El conocimiento debe estar gobernado.
Los resources son objetos recuperables.
Una primera intuición: archivo y mesa de trabajo
Imaginemos una oficina jurídica.
La organización posee un archivo con miles de documentos.
Dentro de ese archivo existen políticas, contratos y precedentes.
Para resolver un asunto concreto, el abogado no coloca todos los documentos sobre su escritorio.
Selecciona algunos.
La analogía permite distinguir:
archivo institucional
↓
documentos concretos
↓
selección para el asunto
↓
mesa de trabajoEn nuestra arquitectura:
Knowledge
↓
Resources
↓
selección
↓
ContextLa analogía ayuda porque muestra que la información disponible para una tarea es sólo una parte de aquello que la organización posee.
Pero deja de servir si imaginamos el contexto como una memoria humana permanente. Técnicamente hablamos de información que una aplicación pone a disposición del modelo durante una ejecución.
Context: la información de la tarea actual
Ya hemos encontrado la palabra contexto en prompting.
En esa etapa la utilizábamos para describir antecedentes relevantes del encargo.
Ahora necesitamos un significado arquitectónico más amplio.
El context es el conjunto de información que el modelo recibe y puede utilizar durante una ejecución determinada.
Puede incluir:
instrucciones de sistema
prompt del usuario
historial de conversación
documento actual
fragmentos recuperados
resultados intermedios
ejemplos
datos adicionalesNo todo tiene el mismo estatus, pero todo puede formar parte de la información disponible durante esa llamada.
Contexto transitorio
Supongamos que hoy una aplicación incluye:
Política de contratación v4, sección 8.4dentro del contexto.
El modelo puede utilizar ese fragmento para responder.
Eso no significa que mañana la política haya quedado incorporada permanentemente al modelo.
Otra ejecución puede no recibirla.
Por eso:
haber estado en el contexto
≠
haber quedado aprendido permanentementeEsta diferencia será importante cuando más adelante aparezca la memoria.
Contexto no es simplemente “todo lo que cabe”
Una ventana de contexto más grande permite incluir más información.
Pero la tarea de diseño no consiste en llenarla.
Podemos imaginarla como una mesa de trabajo.
Una mesa más grande permite abrir más documentos.
No significa que debamos colocar encima todo el archivo.
Cada fragmento adicional consume espacio, puede introducir ruido, puede competir con información más importante, puede aumentar costo y puede alterar qué partes reciben atención.
Por eso una pregunta esencial será:
¿qué información merece entrar al contexto ahora?
Éste es precisamente el problema que llevará a recuperación y RAG.
Knowledge: información disponible y gobernada
Llamaremos knowledge al universo de información que un sistema puede consultar para resolver sus tareas.
En contratación tecnológica puede incluir:
- estándar contractual;
- políticas de seguridad;
- política de datos;
- matriz de riesgo;
- cláusulas aprobadas;
- precedentes;
- historial de excepciones;
- criterios de continuidad;
- manuales internos.
La palabra gobernado es crucial.
Una carpeta con miles de archivos no constituye automáticamente una buena base de conocimiento.
Necesitamos poder responder:
- ¿qué documentos son autorizados?;
- ¿qué versión está vigente?;
- ¿quién es responsable?;
- ¿qué materia cubre?;
- ¿qué reemplaza?;
- ¿para qué unidad aplica?;
- ¿qué nivel de autoridad tiene?;
- ¿desde qué fecha?
Knowledge no significa verdad automática
Una organización puede almacenar información incorrecta.
Puede conservar versiones contradictorias.
Puede tener precedentes mal clasificados.
Puede haber documentos incompletos.
Por eso “estar en knowledge” no significa ser verdadero, vigente, aplicable o suficiente.
La gobernanza intenta aportar atributos que permitan distinguir estas dimensiones.
Resources: objetos concretos
Un resource es un objeto concreto que puede ser recuperado o utilizado.
Por ejemplo:
Contrato_ACME_2025.pdf
Anexo_Datos_ACME.pdf
Estándar_Contratación_v4.pdf
Ficha_Proveedor_2026
Correo_Aprobacion_Excepcion.eml
Manual_Seguridad_v7.pdfEl resource es la fuente material desde la cual obtenemos información.
Puede ser documento, registro, archivo, objeto en una base, correo, página, ficha, dataset o contenido de un sistema.
Knowledge y resource no son lo mismo
Podemos decir:
“El sistema dispone de conocimiento sobre estándares contractuales.”
Eso describe una categoría de información.
Luego podemos identificar:
Resource:
Estándar_Contratación_v4.pdfEl documento es el objeto concreto.
La distinción parece pequeña, pero permite mantener procedencia.
Un mismo knowledge puede estar distribuido
La organización puede considerar que su conocimiento contractual está formado por:
política general
+
anexos
+
matriz de aprobaciones
+
precedentes
+
excepcionesNo existe necesariamente un único documento llamado:
knowledge.txtEl knowledge es una capa lógica.
Los resources son las fuentes concretas que la componen.
Versionado
Supongamos que el repositorio contiene:
Estándar_FINAL.pdf
Estándar_FINAL2.pdf
Estándar_nuevo.pdf
Estándar_aprobado.pdfPara una persona ya es difícil.
Para recuperación automática puede ser peligroso.
Necesitamos información que identifique:
documento: "Estándar de contratación tecnológica"
version: "4.0"
estado: "vigente"
fecha_aprobacion: "2026-03-15"
fecha_vigencia: "2026-04-01"
responsable: "Legal"
sustituye_a: "3.2"
ambito: "proveedores tecnológicos"El formato YAML es sólo ilustrativo.
La idea importante es que la vigencia no debería depender de que el modelo “adivine” cuál archivo parece más reciente.
Procedencia
Supongamos que una respuesta afirma:
“El cap mínimo es de doce meses.”
Para poder revisar necesitamos una cadena:
afirmación
↓
fragmento
↓
sección
↓
resource
↓
versión
↓
autoridadLa procedencia responde:
¿de dónde viene esto?
En Derecho suele ser tan importante como el contenido.
La misma frase puede aparecer en política vigente, borrador, presentación, correo, contrato anterior o minuta informal.
El texto puede coincidir.
Su fuerza no.
Procedencia no es autoridad
Conocer la fuente no resuelve automáticamente su peso.
Comparemos:
Resource A
Política v4
estado = aprobadacon:
Resource B
Contrato ACME
estado = excepción negociadaAmbos pueden ser auténticos.
No cumplen la misma función.
Por eso la metadata puede necesitar representar tipo de fuente, estado, ámbito, jerarquía, vigencia y relación con otros documentos.
Una skill puede entonces aplicar reglas como:
Usa la política vigente como criterio principal.
Utiliza precedentes solamente para ilustrar posiciones negociadas.Aplicabilidad
Incluso una fuente vigente puede no ser aplicable.
Ejemplo:
Política de proveedores de bajo riesgofrente a:
proveedor críticoLa recuperación puede encontrar texto correcto dentro del documento equivocado.
Por eso gobernar conocimiento no es solamente versionar.
También implica representar el ámbito de aplicación.
El triángulo completo
Podemos representar:
El diagrama muestra una idea clave:
no todo resource entra al contexto.
Esa selección será el objeto de la página siguiente.
Ejemplo jurídico
Una skill debe evaluar una cláusula de uso de datos.
La organización posee:
Knowledge:
políticas de privacidad y contratación.Resources relevantes:
Politica_Privacidad_v7.pdf
Estándar_IA_v3.pdf
DPA_Modelo_2026.docx
Contrato_ACME_2025.pdfPara la tarea actual el sistema incorpora al context:
§4.2 de Política_Privacidad_v7
§6 de Estándar_IA_v3
cláusula 8 del contrato nuevoEl modelo no necesita recibir el contrato ACME si no es pertinente.
Tenemos así tres niveles distintos.
Sensibilidad y acceso
La separación también permite formular preguntas de gobernanza.
Puede existir un resource que forma parte del conocimiento institucional, pero cuya consulta está restringida.
Por ejemplo:
investigación interna confidencial
expediente disciplinario
contrato de otro cliente
datos personales sensiblesQue un objeto exista no significa que toda skill deba poder utilizarlo.
Más adelante estudiaremos herramientas y permisos.
Por ahora basta mantener otra diferencia:
existencia del resource
≠
autorización para utilizarloEl caso conductor
Nuestro contrato de proveedor de IA necesita revisión.
La skill sabe:
comparar cap con estándarKnowledge relevante:
estándar de contratación
matriz de aprobaciones
precedentesResources disponibles:
Estándar_v4.pdf
Matriz_v3.xlsx
ACME_2025.pdf
Acta_ACME.pdfContext actual:
cláusula nueva
+
§8.4 del estándar
+
fragmento de la matriz
+
cláusula ACME
+
fragmento del acta que identifica la excepciónYa sabemos describir la arquitectura informacional.
Todavía falta explicar cómo seleccionamos esos fragmentos.
Qué debes recordar
Context es la información disponible para el modelo en una ejecución concreta.
Es transitorio.
Knowledge es el universo de información que el sistema puede consultar.
Debe ser gobernado.
Resources son objetos concretos recuperables.
Pueden contener conocimiento.
Versionado y procedencia permiten saber qué fuente se utilizó y qué estado poseía.
Pero:
procedencia
≠
autoridady:
vigencia
≠
aplicabilidadLa gobernanza del conocimiento debe permitir distinguir esas dimensiones.
El problema que todavía queda abierto
Nuestro sistema puede tener cien mil resources y una gran base de conocimiento.
El modelo no necesita recibirlos todos.
Necesita aquellos que importan para la pregunta actual.
Por eso aparece un problema nuevo:
¿cómo buscar, seleccionar y llevar al contexto sólo la información pertinente?
La página siguiente estudia recuperación de información.