Templates
Llegamos al final de la sección INSTRUIR con un problema muy concreto.
Supongamos que ya construimos un prompt sólido para revisar contratos de proveedores tecnológicos. Funciona bien. Separa evidencia e interpretación, define criterios, exige una salida verificable y mantiene la decisión final bajo control humano.
Al día siguiente llega otro contrato.
Y al día siguiente, otro.
Podemos copiar el prompt completo, cambiar algunos nombres y volver a usarlo. Pero cuanto más se repite la tarea, más evidente se vuelve una pregunta:
¿Qué partes de esta instrucción son siempre iguales y qué partes cambian según el caso?
La respuesta conduce a una nueva abstracción: la template o plantilla.
En el marco pedagógico de este sitio, una template es una instrucción parametrizable y reutilizable.
Conserva una estructura relativamente estable y deja determinados elementos como variables que se completan en cada ejecución.
Del prompt puntual a la plantilla
Comencemos con un prompt específico:
Analiza la cláusula de limitación de responsabilidad desde la posición del cliente aplicando la política contractual interna y devuelve una matriz de hallazgos.
Podemos reconocer que algunas partes cambian:
- tipo de cláusula;
- parte representada;
- estándar aplicable;
- formato.
Entonces reescribimos:
Analiza [TIPO_DE_CLAUSULA] desde la posición de [PARTE_REPRESENTADA] aplicando [CRITERIOS] y devuelve [FORMATO_DE_SALIDA].
La estructura base permanece. Los elementos entre corchetes funcionan como lugares reservados.
Podemos visualizarlo así:
INSTRUCCIÓN FIJA
"Analiza ... desde la posición de ... aplicando ..."
+
VALORES VARIABLES
[TIPO_DE_CLAUSULA]
[PARTE_REPRESENTADA]
[CRITERIOS]
[FORMATO_DE_SALIDA]
La plantilla no elimina la necesidad de completar información. La hace explícita y repetible.
Qué es una variable
Una variable representa un elemento que cambia entre ejecuciones.
Por ejemplo:
[TIPO_DE_CONTRATO]
puede tomar distintos valores:
contrato de servicios tecnológicos
acuerdo de confidencialidad
contrato de licencia de software
La variable no es todavía el contenido. Es un nombre para el espacio que deberá completarse.
Por eso un buen nombre de variable importa.
Comparemos:
[INFO]
con:
[HECHOS_RELEVANTES_QUE_NO_APARECEN_EN_EL_CONTRATO]
La segunda opción reduce ambigüedad porque explica qué tipo de información debe insertarse.
Qué es un parámetro
En este nivel introductorio podemos llamar parámetro al valor con el que configuramos una variable para una ejecución concreta.
Template:
Revisa [TIPO_DE_CLAUSULA] desde la posición de [PARTE].
Ejecución:
TIPO_DE_CLAUSULA = limitación de responsabilidad
PARTE = cliente
Resultado conceptual:
Revisa la cláusula de limitación de responsabilidad desde la posición del cliente.
En programación, distintos lenguajes pueden distinguir con mayor precisión entre variable, parámetro y argumento. No necesitamos todavía esas diferencias técnicas.
El modelo mental suficiente es:
plantilla
+ valores de configuración
= instrucción concreta
Qué conviene mantener fijo
Una plantilla resulta útil cuando separa correctamente metodología estable de datos del caso.
Supongamos que la organización siempre exige:
- no inventar cláusulas;
- distinguir texto e interpretación;
- marcar información faltante;
- indicar evidencia verificable;
- no adoptar la decisión final de aprobación.
Esas reglas pueden formar parte fija de la template.
En cambio, suelen variar:
[PARTE_REPRESENTADA]
[JURISDICCION]
[DOCUMENTOS]
[OBJETIVO]
[TEMAS_PRIORITARIOS]
[CRITERIOS_ESPECIFICOS]
[FORMATO_DE_SALIDA]
La pregunta central es:
¿Qué pertenece a nuestra forma recurrente de hacer la tarea y qué pertenece al caso concreto?
Una template contractual desarrollada
Podemos construir una plantilla más completa:
OBJETIVO
Preparar una revisión inicial de [TIPO_DE_CONTRATO] para apoyar [DECISION_POSTERIOR].
PERSPECTIVA
Analiza desde la posición de [PARTE_REPRESENTADA].
AUDIENCIA
El resultado será utilizado por [AUDIENCIA].
CONTEXTO
[CONTEXTO_DEL_CASO]
DOCUMENTOS
[DOCUMENTOS_DISPONIBLES_Y_ROL_DE_CADA_UNO]
TAREA
Revisa el material e identifica hallazgos relacionados con:
[TEMAS_PRIORITARIOS]
EVIDENCIA
Para cada hallazgo indica [REGLA_DE_TRAZABILIDAD].
CRITERIOS
Evalúa utilizando:
[CRITERIOS_DE_EVALUACION]
RESTRICCIONES FIJAS
- No inventes cláusulas ni ubicaciones.
- Distingue texto, contexto, interpretación e información faltante.
- No resuelvas silenciosamente contradicciones entre documentos.
- No adoptes la decisión profesional final.
RESTRICCIONES ADICIONALES
[RESTRICCIONES_ESPECIFICAS]
FORMATO
Devuelve:
[FORMATO_DE_SALIDA]
La plantilla puede reutilizarse en múltiples casos sin reconstruir desde cero la arquitectura de la instrucción.
Ejecución de la plantilla en el caso conductor
Podemos completar:
[TIPO_DE_CONTRATO]
Contrato de proveedor de IA
[DECISION_POSTERIOR]
Decidir si el contrato puede avanzar a aprobación
[PARTE_REPRESENTADA]
Cliente
[AUDIENCIA]
Abogado interno y responsable de compras
[CONTEXTO_DEL_CASO]
El servicio procesará documentación confidencial y será utilizado en un proceso operativo relevante.
[DOCUMENTOS_DISPONIBLES_Y_ROL_DE_CADA_UNO]
- contrato.pdf: documento principal;
- anexo_datos.pdf: anexo vinculante;
- politica_interna.pdf: estándar interno de negociación, no parte del contrato.
[TEMAS_PRIORITARIOS]
Datos, confidencialidad, subcontratación, continuidad, propiedad intelectual, responsabilidad y terminación.
[REGLA_DE_TRAZABILIDAD]
Documento, cláusula o sección y fragmento relevante.
[CRITERIOS_DE_EVALUACION]
Impacto práctico, claridad, dependencia, dificultad de mitigación y necesidad de escalamiento.
[RESTRICCIONES_ESPECIFICAS]
No propongas redacción alternativa en esta etapa.
[FORMATO_DE_SALIDA]
Tabla de hallazgos y síntesis de cinco prioridades.
La estructura fija permanece. Los valores cambian.
Reutilización no significa copiar sin pensar
Una mala práctica consiste en convertir un prompt en “plantilla” simplemente guardándolo y reutilizándolo sin identificar qué debe cambiar.
Por ejemplo:
Revisa el contrato del trabajador desde la posición del trabajador...
copiado para revisar un contrato de proveedor.
El usuario puede olvidar sustituir una parte y terminar con instrucciones contradictorias.
Una template bien diseñada reduce ese riesgo porque hace visible dónde debe intervenir el usuario.
Variables obligatorias y opcionales
No todas las variables tienen la misma importancia.
Podemos distinguir:
OBLIGATORIAS
[PARTE_REPRESENTADA]
[TAREA]
[DOCUMENTOS]
[OBJETIVO]
OPCIONALES
[CONTEXTO_ADICIONAL]
[EJEMPLOS]
[RESTRICCIONES_ESPECIALES]
[NIVEL_DE_DETALLE]
Esta distinción es útil porque algunas variables, si quedan vacías, vuelven imposible interpretar correctamente el encargo.
Por ejemplo, una plantilla de análisis contractual puede exigir siempre:
[PARTE_REPRESENTADA]
si la evaluación depende fuertemente de la posición.
Valores permitidos
También podemos limitar ciertos parámetros.
[NIVEL_DE_RIESGO]
Valores permitidos:
- alto
- medio
- bajo
- no_determinado
[FORMATO]
Valores permitidos:
- tabla_markdown
- informe_narrativo
- json
Esto reduce variabilidad accidental y prepara el terreno para validaciones más formales.
Sin embargo, debemos evitar encerrar artificialmente la tarea en opciones demasiado estrechas.
Si aparece un caso que no cabe en las categorías, la plantilla debería poder evolucionar.
Valores por defecto
Una template puede incluir un valor predeterminado cuando existe una opción normalmente adecuada.
Por ejemplo:
[NIVEL_DE_DETALLE]
Por defecto: medio.
O:
[FORMATO_DE_SALIDA]
Por defecto: tabla Markdown.
Los defaults reducen fricción, pero sólo deben utilizarse cuando la elección realmente sea segura.
No tendría sentido definir:
[PARTE_REPRESENTADA]
Por defecto: cliente.
si analizar desde la parte equivocada puede cambiar todo el resultado.
La regla es:
usa defaults para decisiones de bajo riesgo; exige valores explícitos para decisiones materiales.
Placeholders claros
Los placeholders deben actuar como pequeñas instrucciones para quien completa la template.
Malo:
[OTRO]
Mejor:
[RESTRICCIONES_ADICIONALES_APLICABLES_A_ESTE_CASO]
Malo:
[CRITERIO]
Mejor:
[CRITERIOS_PARA_CLASIFICAR_RIESGO]
Malo:
[DOCS]
Mejor:
[LISTA_DE_DOCUMENTOS_Y_FUNCION_DE_CADA_UNO]
El nombre de la variable forma parte de la usabilidad de la plantilla.
No mezclar valores heterogéneos en una sola variable
Supongamos:
[CONFIGURACION]
Y el usuario escribe:
cliente, Chile, máximo cinco riesgos, usa tabla, no inventes, revisa datos
La template ha perdido gran parte de su utilidad porque un solo parámetro contiene decisiones de naturaleza distinta.
Es preferible separar:
[PARTE]
[JURISDICCION]
[LIMITE_DE_PRIORIDADES]
[FORMATO]
[RESTRICCIONES]
[TEMAS]
La parametrización sirve precisamente para hacer visibles dimensiones distintas.
Reutilización y consistencia
Una buena template reduce variabilidad entre ejecuciones.
Si cinco abogados utilizan la misma estructura base, es menos probable que:
- uno olvide pedir evidencia;
- otro mezcle contexto y contrato;
- otro omita información faltante;
- otro use un formato incompatible.
La template puede estabilizar:
estructura
vocabulario
campos
restricciones
criterios
secuencia
formato
Pero no elimina toda variabilidad del resultado.
Seguimos trabajando con:
- documentos diferentes;
- valores diferentes;
- modelos probabilísticos;
- contextos distintos.
Por eso:
consistencia de la instrucción
≠
identidad de la respuesta
Una template puede ser muy pequeña
No toda plantilla necesita parecer un manual.
Compara [DOCUMENTO_A] con [DOCUMENTO_B].
Identifica únicamente diferencias sobre [MATERIA].
Devuelve [FORMATO].
Puede ser una excelente template si la tarea es simple y recurrente.
La lógica de la escalera sigue vigente: no agregues complejidad que no resuelva un problema.
Una template también puede contener ejemplos
Podemos parametrizar parcialmente ejemplos:
EJEMPLO DE REFERENCIA
Tema: [TEMA_EJEMPLO]
Texto: [TEXTO_EJEMPLO]
Clasificación: [CLASIFICACION_EJEMPLO]
Fundamento: [FUNDAMENTO_EJEMPLO]
Sin embargo, si los ejemplos forman parte del estándar estable, puede ser preferible mantenerlos fijos y versionados.
La decisión depende de qué queremos estabilizar.
Versionar templates
Una plantilla que se utiliza repetidamente se convierte en un artefacto de trabajo.
Si cambiamos:
Distingue texto e interpretación.
por:
Distingue texto, contexto, inferencia, evaluación e información faltante.
la nueva versión produce un output distinto.
Puede ser útil identificar:
revision_proveedor_v1.0
luego:
revision_proveedor_v1.1
Y registrar qué cambió.
Huyen recomienda tratar prompts reutilizados en aplicaciones como artefactos que deben organizarse, documentarse y versionarse. La misma intuición resulta valiosa incluso sin programación: si una respuesta importante fue producida con una template concreta, conviene saber qué versión estaba vigente.
Probar una template antes de estandarizarla
Una plantilla puede parecer excelente en un caso y fallar en otros.
Antes de adoptarla como estándar conviene probarla con:
- un caso típico;
- un caso con información incompleta;
- un caso con documentos contradictorios;
- un caso donde no exista ningún hallazgo relevante;
- un caso frontera para las categorías de riesgo.
El objetivo es detectar si la estructura induce errores sistemáticos.
Por ejemplo, una plantilla que exige:
Identifica cinco riesgos principales.
puede funcionar en contratos complejos, pero empujar al sistema a inventar materialidad cuando sólo existen dos hallazgos reales.
Una formulación más robusta sería:
Identifica hasta cinco riesgos principales. Si existen menos, no completes la cantidad artificialmente.
La reutilización hace más importante el control de calidad porque un error en la template puede repetirse muchas veces.
Template y organización institucional
La plantilla puede convertirse en un punto de coordinación entre personas.
Por ejemplo, un equipo puede acordar que toda primera revisión contractual utilice campos comunes:
parte
objetivo
documentos
hallazgo
evidencia
riesgo
información faltante
pregunta
Esto facilita:
- comparar trabajos;
- entrenar nuevos miembros del equipo;
- revisar calidad;
- transformar salidas;
- mantener una práctica más homogénea.
Pero debemos evitar convertir la template en un sustituto del juicio. La estandarización sirve mejor cuando estructura lo repetible y deja visible lo que requiere decisión profesional.
El límite de una plantilla
Aquí aparece la frontera conceptual que cierra toda la sección.
Una template puede contener:
Aplica [POLITICA_INTERNA].
Pero la plantilla no proporciona automáticamente esa política.
Puede decir:
Compara con precedentes relevantes.
Pero no sabe por sí misma dónde están los precedentes.
Puede describir:
1. extrae;
2. clasifica;
3. compara;
4. evalúa;
5. verifica.
Pero a medida que la metodología se vuelve rica, empieza a ser incómodo tratarla como una simple frase con espacios rellenables.
Podemos seguir agregando instrucciones, ejemplos, checklists, criterios, formatos y reglas de uso hasta que la template se transforme en un documento enorme.
Eso revela que estamos intentando resolver un problema diferente.
Template ≠ skill
El curso preserva deliberadamente esta diferencia:
Template
instrucción parametrizable y reutilizable.
Skill
capacidad o metodología delimitada y reutilizable.
La template responde principalmente:
“¿Cómo reutilizamos una estructura de instrucción?”
La skill comienza a responder:
“¿Cómo encapsulamos una forma estable de realizar bien una tarea?”
Todavía no desarrollaremos la skill aquí. Sólo debemos reconocer por qué aparece.
El primer salto no es tecnológico: es metodológico
La clase “De prompts a agentes” formula una progresión central:
PROMPT
instrucción puntual
↓
TEMPLATE
instrucción reutilizable
↓
SKILL
metodología reutilizable
El paso de prompt a template no requiere necesariamente APIs, herramientas o agentes.
Es una mejora en cómo organizamos el conocimiento procedimental de la tarea.
Eso explica por qué la sección se llama INSTRUIR: todavía estamos trabajando principalmente sobre cómo describir y reutilizar instrucciones.
Caso conductor: qué hemos ganado y qué sigue faltando
Al inicio teníamos:
Revisa este contrato.
Ahora podemos tener una template:
Revisa [TIPO_DE_CONTRATO] desde la posición de [PARTE].
Objetivo: [OBJETIVO].
Utiliza [DOCUMENTOS].
Prioriza [MATERIAS].
Aplica [CRITERIOS].
Exige [EVIDENCIA].
Respeta [RESTRICCIONES].
Devuelve [FORMATO].
Ya no necesitamos reconstruir el encargo desde cero.
Pero todavía persisten límites:
- debemos proporcionar o localizar el conocimiento aplicable;
- la metodología compleja sigue viviendo dentro de instrucciones;
- no existe todavía una capacidad modular separada;
- no hemos conectado herramientas;
- no hemos formalizado procesos institucionales;
- no hemos delegado selección dinámica de próximos pasos.
Esos límites son precisamente los que justifican la siguiente etapa del recorrido.
Qué debes recordar
Una template separa estructura fija de valores variables.
Sus componentes centrales son:
plantilla
variables
parámetros
reutilización
Una buena template:
- hace visibles los elementos que deben completarse;
- mantiene estables reglas importantes;
- reduce variabilidad accidental;
- puede distinguir valores obligatorios y opcionales;
- puede limitar ciertos parámetros;
- puede versionarse y probarse.
Pero no debemos exagerar su alcance.
Una template sigue siendo una instrucción reutilizable. No equivale a conocimiento, herramienta, workflow ni agente.
Dónde estamos en el recorrido
La sección INSTRUIR comenzó con una pregunta muy simple:
¿Cómo le digo al sistema qué quiero que haga?
Ahora sabemos mucho más.
Podemos:
- formular una tarea;
- reducir ambigüedad;
- distinguir componentes del encargo;
- aumentar complejidad de manera gradual;
- enseñar mediante ejemplos;
- dividir trabajo en etapas;
- controlar formatos de salida;
- utilizar meta-prompts;
- reutilizar instrucciones mediante templates.
Eso representa un avance importante, pero todavía tiene un límite estructural.
El problema que todavía queda abierto
Ya no queremos solamente reutilizar palabras.
Queremos reutilizar una forma de hacer trabajo.
Una metodología de revisión contractual puede incluir:
- instrucciones;
- ejemplos;
- criterios;
- checklists;
- formatos;
- reglas de uso;
- controles;
- recursos auxiliares.
Intentar mantener todo eso como una única plantilla puede volverse frágil y difícil de gobernar.
Por eso el recorrido abandona ahora INSTRUIR y entra en SABER HACER.
El siguiente concepto será la skill: una capacidad o metodología delimitada y reutilizable que permite encapsular cómo realizar correctamente una clase de tarea, sin confundir todavía esa metodología con el conocimiento específico o con las herramientas necesarias para ejecutarla.