flowchart LR
A[Problema profesional] --> B[Prompt]
B --> C[Modelo / sistema]
C --> D[Salida]
D --> E[Uso profesional]
Qué es un prompt
Cómo pasar de tener acceso a un modelo capaz a darle una instrucción suficientemente clara para realizar una tarea concreta.
Hasta aquí el problema principal era entender qué estamos utilizando. Vimos que un modelo no es lo mismo que un sistema y que una aplicación de IA puede incorporar varias capas además del modelo: interfaz, datos, reglas, controles, almacenamiento y otros componentes. Esa distinción era necesaria porque evita atribuir al modelo capacidades que en realidad pertenecen al sistema completo.
Ahora aparece una pregunta distinta y más operativa: ¿cómo le encargamos trabajo a ese sistema?
Imaginemos que llega un contrato de un proveedor tecnológico y escribimos:
Revisa este contrato.Es perfectamente posible que la aplicación produzca una respuesta útil. Pero todavía no sabemos si la respuesta útil para el modelo coincide con la respuesta que necesitaba el abogado. ¿Debe resumir? ¿Detectar riesgos? ¿Comparar con un modelo interno? ¿Revisar desde la posición del cliente o del proveedor? ¿Debe mirar todo el contrato o sólo las cláusulas sobre datos? ¿Debe explicar, clasificar o recomendar? ¿Debe citar el texto que respalda cada hallazgo?
El punto de partida para resolver ese problema es el prompt.
Idea central
En el marco pedagógico de este sitio, un prompt es una instrucción mediante la cual encargamos al modelo una tarea.
Puede ser una frase breve o una especificación extensa. Lo decisivo no es su longitud, sino si permite comprender qué trabajo debe realizarse y qué decisiones relevantes quedan todavía abiertas.
El prompt como interfaz de trabajo
Una manera útil de comenzar es pensar el prompt como la interfaz lingüística entre lo que una persona necesita y lo que el modelo debe producir.
La persona tiene un problema en su propio dominio:
“Necesito saber si este contrato puede avanzar a aprobación.”
El modelo, en cambio, recibe texto y otros contenidos dentro del contexto disponible y genera una salida. Entre ambos mundos necesitamos una especificación que traduzca el problema profesional en una tarea ejecutable.
La función del prompt consiste precisamente en esa traducción. No convierte automáticamente el problema jurídico en una solución correcta, pero permite indicar qué operación queremos que realice el sistema sobre qué objeto y con qué condiciones.
Berryman y Ziegler desarrollan una intuición cercana al describir el diseño de aplicaciones con LLM como un proceso de convertir el problema del usuario al dominio en que puede operar el modelo y luego transformar la salida nuevamente al dominio del usuario. Para un lector no técnico, la idea puede expresarse de manera sencilla: antes de pedir una respuesta, debemos convertir nuestra necesidad profesional en una instrucción que el sistema pueda seguir.
Una instrucción para una tarea
La forma más elemental de un prompt puede pensarse como:
acción + objetoPor ejemplo:
Resume esta sentencia.Compara estos dos contratos.Extrae las obligaciones del proveedor.Clasifica estas cláusulas por materia.Cada ejemplo contiene al menos una operación y un objeto. Esa combinación ya permite distinguir tareas diferentes.
No es equivalente resumir que extraer. Tampoco es equivalente comparar que evaluar. Los verbos importan porque orientan transformaciones distintas de la información.
Consideremos una cláusula contractual:
“El proveedor podrá modificar las condiciones del servicio mediante aviso previo de treinta días.”
Podemos pedir cosas muy diferentes sobre exactamente el mismo texto:
Resume la cláusula.Resultado esperado: una versión más breve.
Extrae la facultad que recibe el proveedor.Resultado esperado: identificar qué puede hacer el proveedor.
Evalúa la cláusula desde la posición del cliente.Resultado esperado: una apreciación respecto de sus consecuencias.
Compara esta cláusula con la cláusula equivalente del contrato modelo.Resultado esperado: identificar semejanzas y diferencias.
La calidad de una respuesta depende, entre otras cosas, de haber especificado correctamente la operación que necesitamos.
Prompt no significa necesariamente “mensaje del usuario”
En una interfaz de chat, normalmente vemos una caja donde escribimos un mensaje. Es natural llamar prompt a aquello que introducimos allí.
Sin embargo, en sistemas reales puede haber más contenido que el mensaje visible del usuario. La aplicación puede incorporar instrucciones del sistema, historial de conversación, fragmentos recuperados, documentos, resultados de herramientas u otra información antes de realizar una llamada al modelo.
Por eso conviene conservar dos niveles de lenguaje:
En este handbook, cuando enseñamos a un usuario a trabajar con IA, utilizaremos prompt principalmente como la instrucción que formula la tarea.
En una arquitectura técnica, el input efectivo del modelo puede ser una composición más amplia de instrucciones y contexto.
No necesitamos desarrollar todavía esa arquitectura. La aclaración importa sólo para evitar una confusión temprana: lo que el modelo recibe puede ser más amplio que la frase que una persona acaba de escribir.
Prompt mínimo
Un prompt mínimo contiene lo indispensable para que el sistema pueda intentar una tarea.
Revisa este contrato.No es necesariamente un mal prompt.
Para una exploración preliminar puede ser suficiente. Si el usuario quiere orientarse, todavía no sabe qué preguntar o sólo busca una primera impresión, una instrucción breve tiene ventajas: es rápida, flexible y permite iniciar una conversación.
El problema comienza cuando confundimos dos afirmaciones diferentes:
- el sistema puede generar una respuesta;
- el sistema conoce exactamente el encargo que el usuario tenía en mente.
La primera puede ser verdadera y la segunda falsa.
Supongamos que tres personas utilizan el mismo prompt:
Revisa este contrato.La primera representa al proveedor y quiere identificar compromisos excesivos. La segunda representa al cliente y quiere detectar riesgos de continuidad. La tercera trabaja en privacidad y sólo necesita revisar tratamiento de datos.
El prompt no contiene esas diferencias. Para producir una salida, el sistema deberá completar de alguna manera aquello que no se especificó.
Por eso los prompts mínimos funcionan mejor cuando la tarea es sencilla, el contexto compartido es suficiente, las consecuencias de una interpretación equivocada son bajas o el usuario piensa continuar mediante conversación iterativa.
Prompt avanzado
Un prompt avanzado no es simplemente un prompt largo. Es una instrucción que hace explícitas más decisiones relevantes del encargo.
Partamos nuevamente de:
Revisa este contrato.Podemos agregar una tarea más precisa:
Revisa este contrato e identifica cláusulas que puedan generar riesgos relevantes.Luego una perspectiva:
Revisa este contrato desde la posición del cliente e identifica cláusulas que puedan generar riesgos relevantes antes de la firma.Luego alcance y evidencia:
Revisa este contrato desde la posición del cliente e identifica cláusulas que puedan generar riesgos relevantes antes de la firma.
Prioriza:
- uso de datos;
- confidencialidad;
- propiedad intelectual;
- cambios unilaterales;
- niveles de servicio;
- responsabilidad;
- terminación.
Para cada hallazgo, indica la cláusula y el fragmento que lo sustenta.Finalmente podemos agregar restricciones y formato:
Revisa este contrato desde la posición del cliente e identifica cláusulas que puedan generar riesgos relevantes antes de la firma.
Prioriza:
- uso de datos;
- confidencialidad;
- propiedad intelectual;
- cambios unilaterales;
- niveles de servicio;
- responsabilidad;
- terminación.
Para cada hallazgo:
1. identifica la cláusula;
2. copia sólo el fragmento estrictamente necesario;
3. explica la consecuencia práctica;
4. distingue texto contractual de interpretación;
5. indica la información faltante cuando no sea posible concluir.
No inventes cláusulas ni antecedentes.
Devuelve una tabla y, después, una síntesis de las cinco prioridades principales.La operación básica sigue siendo “revisar un contrato”. Lo que cambió fue el grado de especificación del trabajo.
La diferencia no está en usar “palabras de IA”
Un prompt avanzado tampoco necesita vocabulario técnico.
Podemos comparar:
Actúa como el mejor experto jurídico del mundo. Piensa profundamente, sé extremadamente riguroso y usa todo tu potencial para revisar este contrato.con:
Identifica exclusivamente las cláusulas que permitan al proveedor:
- modificar unilateralmente el servicio;
- aumentar precios;
- suspender prestaciones;
- incorporar subcontratistas.
Para cada una indica:
- ubicación;
- facultad concedida;
- condiciones para ejercerla;
- aviso requerido;
- derecho del cliente a terminar.
No analices otros temas.La segunda instrucción ofrece mucho más control porque describe el trabajo de forma verificable. El sistema puede todavía equivocarse, pero sabemos qué debía hacer y podemos evaluar si lo hizo.
Ese será un principio transversal de esta sección: especificar trabajo es más importante que coleccionar fórmulas retóricas.
El prompt orienta; no crea capacidades inexistentes
Otra frontera importante consiste en no atribuir al prompt poderes que no tiene.
Un prompt puede orientar el uso de capacidades disponibles. No convierte mágicamente al sistema en algo que no es.
Escribir:
Eres un especialista infalible en derecho tributario chileno.no garantiza que el modelo tenga información correcta, actualizada y suficiente sobre una cuestión tributaria concreta.
Escribir:
No alucines.no crea por sí solo un mecanismo de verificación factual.
Escribir:
Busca el contrato en nuestro SharePoint.no concede acceso a SharePoint si la aplicación no tiene una herramienta o integración que permita hacerlo.
Esta distinción anticipa una arquitectura que desarrollaremos mucho más adelante:
instrucción ≠ conocimiento ≠ acceso ≠ permisoPor ahora basta con conservar la primera frontera: un prompt instruye. No reemplaza el resto del sistema.
El prompt tampoco garantiza verdad
Un prompt puede exigir:
Cita la cláusula exacta.Eso es útil porque hace la respuesta más verificable. Pero no demuestra que la cita sea correcta.
Puede exigir:
Devuelve JSON válido.Eso puede controlar la forma. No demuestra que el contenido del JSON sea verdadero.
Puede exigir:
Clasifica el riesgo como alto, medio o bajo.Eso crea una categoría. No demuestra que la clasificación esté bien fundada.
El trabajo profesional requiere mantener separadas tres preguntas:
¿Siguió la instrucción?
¿La respuesta está respaldada?
¿La evaluación es correcta?Una buena ingeniería de prompts ayuda sobre todo con la primera y puede facilitar la segunda. No elimina la necesidad de revisión.
El prompt como especificación observable
Existe una razón adicional para desarrollar prompts más claros: permiten auditar el encargo.
Si escribimos:
Sé riguroso.es difícil decidir después si el sistema cumplió.
Si escribimos:
Para cada hallazgo indica el documento, la cláusula y el fragmento que lo sustenta. Si no puedes localizar el fundamento, marca el punto como no confirmado.podemos revisar la salida y verificar si esa regla se respetó.
En otras palabras, una buena instrucción transforma expectativas implícitas en criterios observables.
Eso es especialmente importante en entornos jurídicos, donde una respuesta puede circular entre personas, incorporarse a un expediente de trabajo o apoyar una decisión. Cuanto más importante sea el uso posterior, mayor es el valor de saber qué se le pidió realmente al sistema.
Un caso completo: “¿podemos aprobar este proveedor?”
Retomemos el caso conductor del sitio.
Llega un contrato de un proveedor de IA. El abogado recibe la pregunta:
“¿Puede aprobarse?”
Primer intento
Revisa este contrato.Puede generar una lista genérica de observaciones.
Segundo intento
Revisa este contrato de proveedor de IA desde la posición del cliente.Ahora la perspectiva está más clara.
Tercer intento
Revisa este contrato de proveedor de IA desde la posición del cliente.
El objetivo es preparar una decisión interna sobre si el contrato puede avanzar a aprobación.Ahora sabemos para qué se utilizará la respuesta.
Cuarto intento
Revisa este contrato de proveedor de IA desde la posición del cliente.
El objetivo es preparar una decisión interna sobre si el contrato puede avanzar a aprobación.
Identifica únicamente hallazgos que puedan afectar:
- uso y reutilización de datos;
- confidencialidad;
- subcontratación;
- continuidad del servicio;
- propiedad intelectual;
- responsabilidad;
- terminación y salida.
Para cada hallazgo, separa:
- texto contractual;
- interpretación;
- información faltante.
No adoptes todavía la decisión final de aprobación.Este prompt no hace al modelo más inteligente. Hace el trabajo esperado más explícito.
Ese cambio será el eje de todo lo que sigue.
Cuándo basta un prompt breve
No debemos aprender la lección equivocada y convertir toda interacción en una página de instrucciones.
Para algunas tareas, esto es suficiente:
Corrige sólo ortografía y puntuación del siguiente párrafo.También:
Traduce al inglés conservando la numeración de las cláusulas.O:
Extrae todas las fechas que aparecen en este documento.La pregunta útil no es “¿es suficientemente largo?”, sino:
¿quedan abiertas decisiones capaces de cambiar materialmente el resultado?
Si la respuesta es no, agregar instrucciones puede ser innecesario.
Qué debes recordar
En este recorrido, prompt significa principalmente instrucción para una tarea.
Un prompt mínimo puede ser suficiente cuando la tarea es simple o exploratoria. Un prompt avanzado hace explícitas más decisiones relevantes: qué hacer, para qué, desde qué perspectiva, con qué materiales, bajo qué criterios, con qué límites y cómo entregar la respuesta.
La mejora no consiste en encontrar una frase secreta. Consiste en convertir un encargo profesional implícito en una especificación suficientemente clara para que pueda ejecutarse y revisarse.
El problema que todavía queda abierto
Todo aquello que no especificamos no desaparece.
Si escribimos:
Revisa este contrato.el sistema todavía debe producir alguna respuesta. Eso significa que deberá completar de alguna manera decisiones que el prompt no resolvió: alcance, perspectiva, prioridad, evidencia, nivel de detalle o formato.
Por eso el siguiente problema no es todavía cómo escribir un prompt perfecto. Es comprender qué ocurre cuando dejamos demasiado trabajo en la zona implícita.
El siguiente nodo estudia precisamente el problema de la ambigüedad.