OpenAI actualizó la GPT-5.5 prompting guide en su documentación de API. Lo más valioso de esta guía no es que ofrezca otra plantilla de prompt más larga, sino que recuerda algo importante: al migrar a GPT-5.5, muchos prompts antiguos deberían hacerse más cortos.

Documentación oficial: https://developers.openai.com/api/docs/guides/prompt-guidance

En una frase, la dirección para prompts en GPT-5.5 es: escribir menos proceso y más resultado; apilar menos reglas y definir mejor los criterios de aceptación; usar menos instrucciones de tipo “siempre debe” y explicar cuándo detenerse, cuándo validar y cuándo buscar más evidencia.

Por qué hay que reescribir prompts antiguos

Muchos prompts de producción se construyen por capas. Si el modelo es inestable, se añade una regla. Si falla una llamada a herramientas, se añade una prohibición. Si la salida es demasiado larga, se añade otro párrafo de formato. Con el tiempo, el system prompt se convierte en un manual de operaciones pesado.

Ese estilo podía ser útil con modelos antiguos, porque el modelo necesitaba más restricciones paso a paso para no desviarse. Pero con GPT-5.5, la recomendación de OpenAI es clara: no migres el prompt stack antiguo tal cual.

Especificar demasiado el proceso trae varios efectos secundarios:

• Más ruido: el modelo tiene que encontrar las restricciones importantes dentro de muchas reglas viejas.
• Espacio de búsqueda más estrecho: el modelo se atreve menos a elegir soluciones más eficientes.
• Salida mecánica: parece ejecutar un guion, no resolver un problema.
• Reglas antiguas que se contradicen: tanto las tool calls como la respuesta final pueden empeorar.

GPT-5.5 funciona mejor con prompts que describen el estado objetivo, las restricciones, la evidencia disponible y la salida final, en lugar de codificar cada paso.

outcome-first: definir primero qué significa terminado

La documentación oficial insiste en una dirección: GPT-5.5 funciona mejor con prompts outcome-first.

Eso significa que el prompt debería definir primero:

• Cuál es el resultado objetivo.
• Qué cuenta como éxito.
• Qué restricciones no se pueden cruzar.
• Qué contexto está disponible.
• Qué campos o secciones debe incluir la respuesta final.
• Qué hacer cuando falta evidencia.

Un estilo menos recomendable:

1

Primero revisa A, luego revisa B, después compara todos los campos, piensa en todas las excepciones, decide qué herramienta llamar, llama la herramienta y finalmente explica todo el proceso.

Un estilo más adecuado para GPT-5.5:

1
2
3
4
5

Resuelve el problema del usuario. Criterios de éxito:
- Tomar la decisión con base en la política y los datos de cuenta disponibles
- Si la acción está permitida, completarla antes de responder
- La salida final incluye completed_actions, customer_message, blockers
- Si falta evidencia clave, preguntar solo los campos mínimos necesarios

Esto no vuelve el prompt ambiguo. Traslada el control desde el “orden del proceso” hacia el “resultado y los límites”. El modelo puede elegir su ruta de búsqueda, razonamiento y uso de herramientas, pero debe cumplir los criterios de éxito.

Usar menos reglas absolutas y más reglas de decisión

Los prompts antiguos suelen contener muchos ALWAYS, NEVER, must y only. No están prohibidos, pero deberían reservarse para restricciones que realmente no se pueden violar, como reglas de seguridad, campos obligatorios y acciones prohibidas.

Para decisiones como “cuándo buscar”, “cuándo preguntar al usuario”, “cuándo seguir iterando” y “cuándo detenerse”, GPT-5.5 funciona mejor con reglas de decisión.

Por ejemplo, no escribas solo:

1

Siempre busca tres veces primero.

Mejor:

1

Empieza con una búsqueda que cubra la pregunta central. Si los primeros resultados ya soportan los hechos clave, deja de buscar y responde. Continúa buscando solo si la evidencia es contradictoria, falta o no basta para sostener la conclusión.

Este estilo da margen de juicio al modelo y también una condición de parada. Para productos que usan web search, retrieval, file search o consultas de base de datos, esto es clave, porque cada tool call adicional añade latencia y coste.

Añadir un retrieval budget

Una clase de regla que vale la pena añadir a prompts de GPT-5.5 es el retrieval budget.

No es un presupuesto de dinero. Es una regla para detener la recuperación de información. Le dice al modelo cuándo la evidencia es suficiente, cuándo debe seguir buscando y cuándo debe reconocer que falta evidencia.

Una formulación práctica:

1

Para preguntas normales, empieza con una búsqueda amplia usando palabras clave cortas y distintivas. Si los primeros resultados ya soportan la solicitud central, responde con base en esos resultados y no sigas buscando. Añade más retrieval solo si los resultados entran en conflicto, falta un hecho clave o la conclusión no queda soportada.

Este tipo de regla reduce dos problemas frecuentes:

• Buscar demasiado poco y responder sin evidencia.
• Buscar demasiado y desperdiciar tiempo en un bucle de herramientas.

Más importante aún, la documentación recuerda que no encontrar evidencia no debería convertirse automáticamente en un “no” factual. A veces la conducta correcta es decir que la evidencia es insuficiente o acotar la pregunta y seguir revisando.

No subir reasoning effort demasiado pronto

GPT-5.5 es más eficiente al razonar, así que OpenAI recomienda reevaluar low y medium, en lugar de subir reasoning effort cada vez que la calidad no parezca suficiente.

Un orden más estable:

1. Primero confirma si el prompt define claramente objetivo, formato de salida y condiciones de parada.
2. Añade un ciclo de validación, como pruebas, citas, revisión o render checks.
3. Añade reglas de persistencia y criterios de finalización para el uso de herramientas.
4. Solo entonces sube reasoning effort si aún hace falta.

En otras palabras, reasoning.effort se parece más a una perilla final de ajuste. No debería sustituir un prompt bien diseñado.

Si la tarea es clasificación corta, extracción de campos, enrutamiento de tickets o conversión de formato, empieza con bajo coste de razonamiento. Si se trata de síntesis de documentos largos, juicio entre fuentes conflictivas, escritura estratégica o investigación compleja, considera medium o más.

text.verbosity controla la salida, no el pensamiento

GPT-5.5 permite controlar muy bien el formato de salida. La documentación oficial recomienda usar text.verbosity junto con los requisitos de salida dentro del prompt.

El valor por defecto de text.verbosity es medium. Si el producto necesita respuestas más cortas y limpias, se puede usar low. Pero eso no significa que todo tenga que ser corto.

Una pauta típica:

• Mantener breves las actualizaciones de estado y el resumen final para el usuario.
• Seguir exigiendo legibilidad cuando se genera código, configuración o resultados estructurados.
• No sacrificar campos completos, citas o caveats necesarios solo por ser “breve”.

Esto es especialmente útil en productos de código. Las respuestas de chat pueden ser más cortas, pero el código generado puede seguir exigiendo nombres legibles, estructura clara y comentarios necesarios.

preamble y phase: hacer visibles las tareas largas

En tareas complejas, GPT-5.5 puede razonar, planificar o preparar tool calls antes de emitir texto visible. En productos con streaming, el usuario nota la espera hasta el primer token.

La recomendación oficial es: para tareas de varios pasos, intensivas en herramientas o de larga duración, deja que el modelo emita primero un preamble breve. No tiene que explicar todo el plan; basta con decir qué hará primero.

Por ejemplo:

1

Primero revisaré los archivos relevantes y la configuración existente, y luego propondré los cambios.

En workflows largos o intensivos en herramientas con Responses API, también hay que prestar atención al phase del assistant item. Si la aplicación usa previous_response_id, la API conserva automáticamente el estado anterior del assistant. Si la aplicación reproduce manualmente la salida del assistant, debe conservar el valor original de phase.

Convenciones comunes:

• phase: "commentary": actualización intermedia de estado.
• phase: "final_answer": respuesta final.
• No añadir phase a user messages.

Parece un detalle de implementación, pero importa en productos con tool calls, actualizaciones de estado y respuestas finales. Perder phase durante una reproducción manual puede hacer que el modelo confunda progreso intermedio con conclusión final.

Pedir al modelo que revise su propio trabajo

Otro punto muy práctico de la guía GPT-5.5: en tareas verificables, dale al modelo herramientas y reglas de validación.

Para agentes de código, se puede pedir explícitamente:

• Ejecutar unit tests relevantes después de modificar.
• Ejecutar type check o lint cuando corresponda.
• Ejecutar build si el paquete afectado es grande.
• Si la validación completa es demasiado cara, hacer al menos el smoke test mínimo.
• Si no se puede validar, explicar por qué y cuál es la siguiente mejor comprobación.

Para resultados visuales o páginas, se puede pedir renderizar primero y luego comprobar layout, recortes, espaciado, contenido faltante y consistencia visual.

Para planes de ingeniería, se puede pedir que incluyan relación con requisitos, archivos/API/sistemas afectados, transiciones de estado, comandos de validación, comportamiento ante fallos, privacidad y seguridad, y preguntas abiertas que realmente afectan la implementación.

Estas reglas son mucho más efectivas que “sé cuidadoso”. Convierten “cuidado” en comprobaciones ejecutables.

Un esqueleto de prompt más adecuado para GPT-5.5

La estructura de la documentación de OpenAI puede simplificarse así:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

Role:
Qué rol tienes y en qué contexto trabajas.

# Personality
Tono, forma de colaborar, si hace falta calidez o punto de vista.

# Goal
El resultado visible para el usuario.

# Success criteria
Condiciones que deben cumplirse antes de la respuesta final.

# Constraints
Límites de seguridad, negocio, evidencia, permisos, coste y efectos secundarios.

# Output
Estructura, longitud, tono y campos requeridos.

# Stop rules
Cuándo continuar, reintentar, degradar, preguntar o detenerse.

El punto no es que todos los prompts deban tener todos estos títulos. La idea real es que un prompt para tareas complejas debe decirle al modelo destino, límites y entregable, no codificar cada paso.

Orden práctico para migrar prompts antiguos

Si ya tienes prompts antiguos para GPT-4.1, GPT-4o, GPT-5.2 o GPT-5.4, no conviene reescribir todo de una vez.

Un orden más estable:

1. Cambia primero el modelo, manteniendo fijo el reasoning effort y los parámetros de salida actuales.
2. Ejecuta evals existentes o ejemplos reales para detectar cambios de comportamiento.
3. Elimina reglas de proceso claramente obsoletas, repetidas o contradictorias.
4. Convierte “requisitos de pasos” en “criterios de éxito” y “condiciones de parada”.
5. Añade retrieval budgets, reglas de cita y comportamiento ante falta de evidencia.
6. Añade ciclos de validación para tareas con herramientas.
7. Ajusta reasoning.effort y text.verbosity al final.

Si no tienes evals, al menos prepara un conjunto de tareas típicas: Q&A simple, retrieval complejo, uso de herramientas, salida formateada, rechazo/degradación y finalización de tareas largas. No juzgues la calidad del prompt con un único demo case.

Checklist para migrar prompts antiguos

Al migrar un prompt antiguo, empieza con esta lista. El objetivo no es hacerlo más corto sin más, sino borrar restricciones inútiles y convertir las restricciones importantes en algo verificable.

Si solo puedes hacer una cosa, prioriza “sin condición de parada” y “sin comando de validación”. Son las dos vías más fáciles para convertir GPT-5.5 en un bucle infinito de herramientas, o en un modelo que da respuestas pulidas pero no verificadas.

Ejemplos de prompts GPT-5.5: viejo vs nuevo

Estos no son system prompts completos, sino reescrituras parciales comunes durante una migración.

Ejemplo 1: Q&A con retrieval

Viejo:

1

Antes de responder, debes buscar al menos 3 veces. Debes leer todos los resultados relevantes. Debes dar una explicación completa.

Nuevo:

1

Empieza con una búsqueda que cubra la pregunta central. Si los primeros resultados ya soportan los hechos clave, deja de buscar y responde. Si los resultados entran en conflicto o faltan hechos clave, añade otra búsqueda. En la respuesta final, explica la base; si la evidencia es insuficiente, dilo claramente.

La versión nueva cambia “número de búsquedas” por “si la evidencia es suficiente”. Da al modelo una razón para seguir y una razón para detenerse.

Ejemplo 2: cambios de código

Viejo:

1

Modifica el código con cuidado. No rompas la lógica existente. Al terminar, dime qué cambió.

Nuevo:

1
2
3
4
5

Haz el cambio de código mínimo necesario solicitado por el usuario. Criterios de éxito:
- Modifica solo archivos relacionados con la tarea
- Conserva la compatibilidad de la API pública existente salvo que el usuario pida cambiarla explícitamente
- Ejecuta unit tests relevantes después del cambio; si no pueden ejecutarse, explica por qué y cuál es la siguiente mejor validación
- El resumen final incluye cambios, resultado de validación y riesgos restantes

La versión nueva no pide “cuidado” de forma vaga. Lo concreta en alcance de archivos, compatibilidad de API, pruebas y reporte de riesgos.

Ejemplo 3: salida estructurada

Viejo:

1

Devuelve JSON. No devuelvas contenido extra. Los campos deben estar completos.

Nuevo:

1
2
3
4
5
6

Devuelve JSON estricto sin Markdown. Campos requeridos:
- status: "ok" | "needs_more_info" | "blocked"
- answer: string
- evidence: string[]
- missing_info: string[]
Si la evidencia es insuficiente, usa status "needs_more_info" y no inventes evidence.

La versión nueva no solo pide JSON. También define una ruta válida cuando falta evidencia, para que el modelo no tenga que inventar información para cumplir “campos completos”.

Cómo combinar parámetros

reasoning.effort y text.verbosity no deberían verse de forma aislada. El primero influye en cuánto razonamiento invierte el modelo; el segundo, en cuán detallada es la salida. Un error común es subir reasoning.effort cuando la calidad no alcanza, o endurecer el prompt cuando la salida es larga. Es más estable configurarlos por tipo de tarea.

Para la mayoría de aplicaciones, empieza con low o medium. Sube reasoning.effort solo cuando el prompt ya define criterios de éxito, condiciones de parada y reglas de validación, y aun así el modelo omite restricciones clave.

text.verbosity tampoco mejora siempre al bajar. Low verbosity sirve para actualizaciones de estado, respuestas cortas de soporte y resúmenes de operación. Pero para código, configuración, planes de migración o explicaciones de auditoría, una salida demasiado breve dificulta la revisión.

Qué reglas conviene conservar

Migrar a GPT-5.5 no significa borrar todo el prompt antiguo. Las siguientes reglas suelen conservarse, y conviene escribirlas con más precisión.

• Reglas de seguridad: acciones que no se pueden ejecutar, contenido que no se puede generar, casos que requieren rechazo o degradación.
• Reglas de cumplimiento: políticas de industria, restricciones regionales, límites de edad, auditoría, aprobaciones.
• Reglas de privacidad: manejo de datos personales, redacción de datos sensibles, límites de logging, prohibición de transferir datos.
• Campos de salida: respuestas de API, JSON schema, columnas de tabla, estructuras fijas requeridas por componentes frontend.
• Límites de negocio: reglas de reembolso, permisos de cuenta, niveles de servicio, alcance contractual, escalado a soporte humano.
• Límites de permisos de herramientas: qué herramientas se pueden llamar, cuáles requieren confirmación y cuáles están prohibidas.
• Reglas de citas y evidencia: cuándo se requieren fuentes y cómo manejar evidencia conflictiva.

Estas reglas no son lastre viejo. Son contratos del producto. La diferencia es que, durante la migración, deben pasar de eslóganes largos a restricciones ejecutables.

Por ejemplo:

1

No filtres privacidad del usuario.

Puede convertirse en:

1

No incluyas números de teléfono completos, documentos de identidad, access tokens, API keys ni IDs internos de usuario en la respuesta final. Si hace falta referenciarlos, muestra solo una versión redactada, como conservar los últimos 4 dígitos del teléfono.

Qué no se debe borrar por error

El mayor peligro al recortar prompts no es borrar texto inútil, sino borrar límites reales del sistema. Lo siguiente no debería eliminarse a la ligera, aunque parezca viejo.

• Requisitos de privacidad y tratamiento de datos: especialmente reglas de logs, exportación, transferencia entre sistemas y tool calls de terceros.
• Límites de seguridad y permisos: confirmaciones para borrar datos, transferir dinero, enviar correos, cambiar permisos o ejecutar shell commands.
• Formato de citas: si el producto depende de citas, notas, listas de fuentes o trazas de auditoría, no lo borres solo porque ocupa espacio.
• Límites de tool calls: qué herramientas son solo lectura, cuáles pueden escribir y cuáles requieren confirmación del usuario.
• Comportamiento ante fallos: cómo degradar cuando hay timeouts de API, datos faltantes, fallos de retrieval o permisos insuficientes.
• Reglas duras de negocio: precios, reembolsos, bloqueos, control de riesgo y revisión de compliance que el modelo no debe improvisar.

Una regla simple: si borrar una regla solo cambia un poco el estilo de salida, puedes considerar borrarla. Si borrarla puede causar exceso de privilegios, filtración, mala operación, promesas falsas o ruptura de auditoría, consérvala y reescríbela con más precisión.

Resumen

El núcleo de la guía de prompting para GPT-5.5 no es “escribir prompts más avanzados”, sino quitar de los prompts antiguos las partes que especifican demasiado el proceso.

Un prompt más adecuado para GPT-5.5 debería:

• Priorizar objetivos, no pasos.
• Definir criterios de éxito, no pedir de forma vaga “hacerlo bien”.
• Incluir condiciones de parada, no búsquedas o tool loops infinitos.
• Tener presupuesto de evidencia, no responder sin evidencia ni buscar para siempre.
• Incluir reglas de validación, no depender solo de que el modelo sea cuidadoso.
• Ajustar parámetros al final, no subir reasoning effort desde el inicio.

Si tu system prompt antiguo ya es largo, el primer paso para migrarlo a GPT-5.5 quizá no sea añadir contenido, sino eliminarlo. Conserva las reglas realmente no negociables y convierte los detalles de proceso en resultados, límites y checks. Eso suele ser más efectivo que seguir acumulando prompts.

Referencias

• OpenAI Prompt guidance: https://developers.openai.com/api/docs/guides/prompt-guidance
• OpenAI Using GPT-5.5: https://developers.openai.com/api/docs/guides/latest-model