Analogía de oficina: políticas de la empresa
Piensa en cómo trabaja un estudio serio.
Cuando entra un ingeniero nuevo, no le pegas el manual de calidad al pie de cada correo. Las políticas viven a nivel de empresa: cómo se nombran los archivos, qué unidades se usan, qué no se inventa si falta un dato, cuándo hay que escalar al senior, qué se puede entregar como borrador y qué exige firma. Esas políticas son persistentes. Están ahí aunque el pedido de hoy sea un pórtico y el de mañana sea un metrado.
El system prompt —o las instructions / rules del cliente— es exactamente eso: políticas de cómo deben resolverse los problemas con ese asistente. Definen el rol, los límites y la forma de trabajar. No son el trabajo del día. Son el marco.
Si cada mañana tienes que reescribir las políticas en el cuerpo del correo porque «si no, el junior se olvida», no tienes políticas de empresa: tienes un recordatorio frágil. Lo mismo pasa cuando pegas las reglas junto al pórtico en cada chat.
Esta nota forma parte de la serie sobre el harness de IA para ingeniería civil. Aquí está H-01 Instrucciones y políticas. Complementa, no reemplaza, el prompt engineering ni el rol del LLM.
Qué es (de verdad) el system prompt
El system prompt —o las instructions persistentes del cliente— es el conjunto de reglas de mayor prioridad que orientan el comportamiento del modelo durante la sesión o la tarea: su rol, alcance, unidades, herramientas disponibles y situaciones en las que debe pedir ayuda o detenerse.
No es el pedido del pórtico. No es el archivo. No es la tool —la acción enchufada a un programa—. No es la firma.
En la industria se habla de system prompts de productos (por ejemplo, lo que documenta Anthropic sobre instrucciones de sistema) y de la distinción entre instructions e input (como en las guías de OpenAI): lo persistente frente al pedido concreto. En Cursor aparecen como rules. En Claude Desktop, como instrucciones del proyecto. El nombre cambia; la tensión de oficina es la misma.
Pegar reglas en cada mensaje vs políticas a nivel empresa
Ilustración de oficina —demo de escritorio, no caso de cliente.
Versión A. Pegas las reglas junto al pórtico en cada mensaje. A la tercera pregunta el historial creció, el modelo compactó contexto y tus reglas quedaron mezcladas con números, supuestos y chistes de la conversación. El chat «olvidó» lo que nunca tuvo fijado a nivel de políticas.
Versión B. Las mismas ocho líneas viven como instrucciones persistentes del cliente —como políticas de empresa—. El pedido del pórtico entra limpio. Las reglas siguen ahí aunque cambies de pregunta. No porque el modelo se volvió ingeniero: porque el harness las reinyecta.
Esa es la diferencia que importa en AEC. No es magia. Es dónde vive el contrato.
Qué va ahí, qué no
Va en el system / instructions (políticas)
- Rol concreto: «asistente de revisión estructural en oficina; no emites verificación firmada».
- Unidades y convenciones: kN, m, grados, criterio de redondeo.
- Qué está prohibido inventar: IDs, cargas, resultados de motor, cláusulas normativas.
- Cuándo debe parar y preguntar: falta de archivo, ambigüedad de versión, tool caída.
- Qué tools existen y para qué (si el harness las expone).
Va en el pedido (user)
- El pórtico de hoy, el nivel, el archivo, la pregunta concreta.
- Datos del proyecto que cambian en cada tarea.
- El entregable que necesitas ahora.
Va en una tool / motor
- Abrir el modelo, leer parámetros, correr OpenSees o CalculiX, validar esquemas.
- Cualquier número que pretenda ser resultado de ingeniería.
Si metes el cálculo en el system prompt, estás pidiendo poesía con uniforme. Si metes las reglas solo en el user, estás apostando a que la conversación no las diluya.
Pieza del harness: H-01 — instrucciones y políticas
En qué es un harness de IA, el arnés se describe como el marco con el que trabaja el modelo: herramientas, instrucciones, chequeos y tu firma. El system prompt es una pieza de ese marco —H-01: instrucciones / políticas—. No es el taller entero.
Tres límites que evitan el autoengaño:
- Un system prompt no ejecuta. Puede decir «usa la tool de Revit», pero sin un enchufe real (por ejemplo MCP u otra mano) no abre nada.
- Un system prompt no es memoria de proyecto. No recuerda el RFI de la semana pasada salvo que el harness lo cargue.
- Un system prompt no firma. «Actúa como ingeniero senior» no transfiere matrícula ni responsabilidad.
Por eso la frase del harness sigue siendo la brújula: el modelo razona y propone; el harness conecta, ejecuta, verifica y limita; el profesional decide y firma. El system prompt ayuda a que el razonamiento respete políticas. No sustituye tools, motores ni firma.
Conclusión
Pegaste las reglas y a la tercera ya no las tenías. Esa escena no es un meme: es el síntoma de confundir un mensaje con políticas de empresa.
El chat no se vuelve ingeniero por un párrafo. El system prompt es la instrucción persistente del harness: rol, límites y forma de trabajar. Escríbelo, audítalo y sácalo del pedido. El cálculo y la firma siguen siendo otra cosa.
Si quieres el marco completo alrededor del modelo, lee qué es un harness de IA. Para el pedido del día, sigue con prompt engineering. Para por qué dos corridas pueden diferir, el rol del LLM.
Fuentes
- Anthropic — documentación sobre system prompts (instrucciones de sistema vs entrada del usuario; consulta la documentación oficial de la plataforma).
- OpenAI — Prompt engineering: distinción entre instructions e input (consulta la guía oficial de prompt engineering).
Evaluación y limitaciones
Trata las notas siguientes como contexto de evaluación, no como un cálculo o una revisión verificados.
Revisa el system prompt junto con tools y aprobaciones. El texto de política es H-01; no es el sistema completo.