Diseñar prompts para producción: capas del sistema, del desarrollador y del usuario

Un prototipo puede empezar con una cadena en línea. La presión de producción aparece cuando el prompt necesita una persona responsable, revisión, reversión, tratamiento de datos, varias funciones o idiomas, o un comportamiento medible; puede ocurrir antes del lanzamiento y no tiene un plazo universal.

Necesitarás cambiar una parte de las instrucciones sin alterar las demás. Necesitarás comportamientos distintos según el nivel del cliente, comparar versiones mediante pruebas A/B, volver atrás cuando algo falle y saber cuándo se modificó el prompt por última vez y por qué.

Un diseño de prompts de producción hace explícitas esas decisiones. El texto del prompt es un artefacto dentro de un sistema gobernado de publicación y ejecución.

Este artículo usa una arquitectura editorial de tres capas para explicar la responsabilidad y el ritmo de cambios, y después muestra cómo adaptarla a las API de los proveedores. Es un diseño de referencia, no un formato de transporte universal. Para el límite de seguridad, utiliza la guía de OWASP sobre inyección de prompts: separar instrucciones y datos facilita la revisión y la evaluación, pero ninguna plantilla crea un límite de autorización o aislamiento.

El trabajo con prompts de producción tiene dos artefactos separados: plantillas reutilizables y datos por solicitud. Versiona las plantillas como código. Trata los prompts renderizados y las respuestas del modelo como registros sensibles siempre que contengan datos del usuario, del cliente o internos.

Tres capas editoriales adaptadas a una API

Este diseño separa tres responsabilidades editoriales:

Capa del sistema. Comportamiento, identidad y restricciones relativamente estables. Pertenece al equipo responsable del comportamiento de IA común a varias funciones.

Capa del desarrollador. Instrucciones específicas de la función, política de uso de herramientas y requisitos de salida. Pertenece al equipo de la función.

Capa del usuario y de ejecución. La solicitud del usuario y el contexto dinámico, como datos autorizados del cliente, historial de conversación y conocimiento recuperado. Se construye para cada solicitud o turno.

Mezclar propiedad, política estable, instrucciones de la función y datos de ejecución puede dificultar la revisión, evaluación, caché y reversión. Sepáralos cuando mejore el control; no fuerces tres campos de API si el proveedor o la aplicación los representa de otra manera.

La autoridad de las instrucciones y la ubicación de los datos están relacionadas, pero no son lo mismo. La jerarquía de confianza determina qué instrucción prevalece en caso de conflicto. La ubicación indica dónde transporta la aplicación el contenido dinámico o no fiable. Colocar texto recuperado en un campo de usuario o de contexto no lo hace autorizado, correcto ni seguro. Aplica fuera del modelo la identidad, el acceso por tenant, la minimización de datos, los permisos de herramientas y la validación de salidas.

Separarlas es fundamental:

┌─────────────────────────────────────┐
│ Capa del sistema (relativamente estable) │  Identidad, comportamiento, intención de política
├─────────────────────────────────────┤
│ Prompt de desarrollador (función)   │  Instrucciones de la función, herramientas, formato
├─────────────────────────────────────┤
│ Prompt de usuario (por llamada)     │  Consulta, contexto, conversación
└─────────────────────────────────────┘

Las API de los modelos expresan estas distinciones de formas diferentes:

• OpenAI: en la API Responses, utiliza el parámetro de nivel superior instructions o un mensaje developer para las instrucciones de la aplicación y un mensaje user para la entrada del usuario. No des por hecho que las instrucciones de una respuesta anterior se conservan cuando gestionas un flujo de varios turnos.
• Anthropic: adapta el diseño a la API Messages de Claude, su mecanismo de instrucciones del sistema, los roles de mensajes y las definiciones de herramientas; la ubicación admitida de los roles puede variar según el modelo y la plataforma.
• Gemini: adáptalo a system_instruction y el contenido de la solicitud, además de la configuración separada de herramientas de la API elegida.

Usa un adaptador específico por proveedor y pruebas de integración. No copies los nombres de los roles entre API dando por equivalentes su precedencia, persistencia o comportamiento de herramientas.

Capa 1: El prompt del sistema

Dentro de este patrón editorial, la capa del sistema define el rol y el comportamiento comunes a varias funciones. Procura cambiarla con menos frecuencia que las instrucciones de cada función, pero versiónala y evalúala siempre que cambie.

Un buen prompt del sistema cubre:

Identidad. Rol declarado. «Eres un asistente de IA de [Company], especializado en [domain]».

Voz y estilo. Cómo debe sonar. Características específicas, no descripciones vagas.

Restricciones de comportamiento obligatorias. Qué debe rechazar, derivar, revelar o formatear el modelo. Aplica los controles de seguridad, permisos y acciones irreversibles en el código de la aplicación y los sistemas posteriores, no solo en este texto.

Patrones de comportamiento. Cómo debe gestionar situaciones habituales: rechazos, derivaciones e incertidumbre.

Seguridad y cumplimiento normativo. Avisos obligatorios, requisitos regulatorios y políticas de contenido.

Lo que no debe contener:

• Instrucciones específicas de funcionalidades («para los correos de ventas, haz X»).
• Contexto dinámico («el historial de pedidos del usuario es…»).
• Descripciones de herramientas (van a otro lugar).
• Cosas que cambian con frecuencia.

Un prompt del sistema debe ser tan largo como exija el comportamiento evaluado, y no más. Uno breve puede ser suficiente y uno largo puede seguir omitiendo reglas críticas; mide los conflictos entre instrucciones, la calidad de la tarea, la latencia y el coste de tokens en lugar de perseguir un intervalo de palabras.

Una plantilla que funciona:

Eres [name], un asistente de IA para [company / context].

## Tu función
[2-3 sentences on what you do]

## Voz y estilo
- [Specific trait 1]
- [Specific trait 2]
- [Specific trait 3]
- No uses [anti-pattern 1]
- No uses [anti-pattern 2]

## Restricciones estrictas
- Nunca [hard rule 1]
- Nunca [hard rule 2]
- Siempre [hard rule 3]

## Cómo gestionar la incertidumbre
- Si no conoces un dato, dilo de forma explícita.
- Si alguien pide algo fuera del alcance, ofrece la ayuda que sí puedas prestar.
- Si una solicitud podría causar daño, recházala y explica el motivo.

## Requisitos de formato
- Texto sin formato de manera predeterminada
- Usa Markdown al mostrar código o datos estructurados
- Sé conciso; no rellenes las respuestas con contenido superfluo

Este es el armazón por el que pasa cada interacción. Sus cambios deben ser deliberados y poco frecuentes.

Capa 2: El prompt del desarrollador

El prompt del desarrollador es específico de cada funcionalidad. Cada funcionalidad utiliza el suyo.

Un prompt del desarrollador para una función de resumen:

Tarea: resume el documento que aparece a continuación.

Requisitos:
- 3-5 viñetas
- Cada viñeta debe ser una oración completa
- Céntrate en hechos y afirmaciones concretas, no en impresiones
- Si el documento contiene cifras, incluye las más importantes
- No incluyas lenguaje comercial ni especulaciones
- Si el documento es ambiguo sobre algo importante, indícalo

Formato: viñetas simples en Markdown, sin introducción.

Un prompt del desarrollador para una función de revisión de código:

Tarea: revisa el siguiente diff de código.

Devuelve un objeto JSON con:
- summary: resumen del cambio en 1-2 oraciones
- concerns: array de problemas concretos (cada uno con file, line, severity y description)
- suggestions: array de mejoras (cada una con file, line y suggestion)
- approved: valor booleano (true si no hay problemas bloqueantes)

Niveles de gravedad:
- "blocker": debe corregirse antes de la fusión
- "warning": conviene corregirlo, pero no bloquea la fusión
- "nit": observación de estilo, opcional

Presta especial atención a:
- Errores lógicos
- Problemas de seguridad
- Problemas de rendimiento
- Falta de cobertura de pruebas
- Nombres o estructuras poco claros

Omite:
- Formato (lo gestiona el formateador)
- Preferencias de estilo subjetivas

Cada funcionalidad tiene su propio prompt del desarrollador. Cada uno se almacena, versiona y evalúa por separado.

Capa 3: El prompt del usuario

La capa del usuario es dinámica. Normalmente incluye:

La solicitud real del usuario. «Resume este documento».

El contexto recuperado por el sistema. Documentos de RAG, historial del cliente e historial de la conversación.

Variables por llamada. Nombre del usuario, zona horaria, preferencia de idioma, nivel de cuenta.

Esta capa se construye mediante código en el momento de la llamada. Suele presentar una estructura como esta:

{conversation_history_summary}

{retrieved_context}

Solicitud del usuario: {user_query}

Contexto adicional:
- Nombre del usuario: {name}
- Zona horaria del usuario: {timezone}
- Nivel del usuario: {tier}

La estructura exacta depende de la funcionalidad. El principio es sencillo: los datos se incluyen aquí, no en los prompts del sistema ni del desarrollador.

Disciplina de plantillas

Los prompts de producción se construyen a partir de plantillas. Concatenar cadenas directamente en el código puede servir en un prototipo, pero no escala.

Un sistema de plantillas simple:

from string import Template

SUMMARIZE_TEMPLATE = Template("""
$conversation_summary

Document to summarize:
$document

User's specific instructions: $user_instructions
""")

prompt = SUMMARIZE_TEMPLATE.substitute(
    conversation_summary=summarize_conversation(history),
    document=document_text,
    user_instructions=user_query,
)

En sistemas más sofisticados, puede utilizarse una biblioteca de plantillas (Jinja2, Handlebars) con condicionales y plantillas parciales.

{% if user_tier == "enterprise" %}
You have access to advanced analysis features.
{% endif %}

{% if retrieved_context %}
Relevant context from your knowledge base:
{{ retrieved_context }}
{% endif %}

User's request: {{ user_query }}

Las plantillas mantienen una estructura coherente, permiten aplicar lógica condicional y facilitan delimitar o escapar la entrada del usuario. Por sí solas no detienen la inyección de prompts: trata el texto no fiable como datos, nunca como instrucciones.

Elige una fuente de verdad gobernada

Trata los prompts de producción como artefactos de publicación versionados. La fuente de verdad puede ser un repositorio, un registro o servicio propio, o un producto gestionado con una interfaz de edición. Elige según las necesidades de gobernanza y operación, no suponiendo que un patrón de almacenamiento sirve para todos los equipos.

Para prompts gestionados como código, un directorio prompts/ con un archivo por prompt es un punto de partida claro:

prompts/
  system/
    main.txt
    customer-support.txt
    code-assistant.txt
  features/
    summarize.txt
    classify-ticket.txt
    generate-email.txt
  templates/
    base.j2

Cada archivo puede conservar su propio historial y revisión mediante PR, mientras los despliegues de producción hacen referencia a una versión conocida del código.

Por qué esto importa:

• Visibilidad de los cambios. Cuando se modifica un prompt, el diff queda en la PR y los revisores pueden ver exactamente qué ha cambiado.
• Reversión. Si un cambio rompe algo, puedes revertirlo.
• Historial. «¿Cuándo cambiamos la política de reembolsos del prompt?» «¿Por qué está aquí este párrafo?» Son preguntas que pueden responderse mediante git blame.
• Herramientas. Linters, validadores, suites de evaluación se integran con prompts basados en archivos.

Compara explícitamente las opciones principales:

Las cadenas en línea sirven para un prototipo pequeño, pero son más difíciles de descubrir y publicar por separado. Una interfaz de edición puede ser adecuada si sus permisos, revisión, procedencia, despliegue y reversión satisfacen el riesgo del flujo. Los prompts copiados de chats deben seguir el mismo proceso de revisión, saneamiento y evaluación que cualquier otro candidato.

No incluyas en el repositorio conversaciones de producción, registros de clientes, tickets de soporte, documentos internos ni prompts renderizados que contengan variables sensibles. El control de versiones debe contener plantillas reutilizables, fixtures y ejemplos de evaluación saneados. Las trazas reales deben guardarse en un sistema de observabilidad con políticas de retención, control de acceso y anonimización.

Registros y servicios en tiempo de ejecución

Cuando las publicaciones de prompts necesitan un ritmo distinto al de la aplicación, o personas autorizadas necesitan una interfaz controlada, un repositorio puede no bastar. Un registro o servicio puede seleccionar una versión aprobada en tiempo de ejecución.

Una solución consiste en utilizar una base de datos o un servicio que almacene versiones de los prompts junto con sus metadatos.

prompt = prompt_service.get(
    name="summarize",
    version="v3",
    locale="en",
    user_tier="enterprise",
)

El servicio debe mantener:

• Versiones actuales e históricas de cada prompt.
• Metadatos: cuándo se añadió, por quién, por qué.
• Puntajes de evaluación adjuntos a cada versión.
• Capacidad de reversión.

El motor de almacenamiento es solo una parte del diseño. Compara acceso por roles, historial de auditoría, acceso autenticado en ejecución, promoción entre entornos, coherencia del despliegue, reversión, exportación, cifrado, tratamiento de datos, disponibilidad y coste operativo. Una base de datos pequeña solo basta cuando los controles que la rodean cumplen los requisitos.

Define quién puede redactar, revisar, aprobar, publicar, revertir y leer prompts renderizados. El permiso de edición no implica el de publicación en producción. Los flujos sensibles pueden exigir roles separados, vistas previas saneadas, aprobación doble o una interfaz que nunca muestre datos reales de clientes.

Cambios sujetos a evaluación

Los cambios de prompt que puedan afectar a resultados del usuario, uso de herramientas, tratamiento de datos, cumplimiento de políticas o decisiones posteriores deben someterse a revisión y evaluaciones proporcionales al riesgo antes del despliegue. Un cambio de texto de bajo riesgo puede necesitar un pequeño conjunto de regresión; uno que influya en pagos, cuentas o decisiones reguladas exige casos offline más sólidos, pruebas adversarias, aprobación y despliegue gradual. Define una vía de emergencia con alcance limitado, supervisión, aprobación y reversión en lugar de eludir el control.

El flujo:

1. Una persona del equipo, sea técnica o no, prepara un cambio en el prompt.
2. El cambio se ejecuta contra la suite de evaluación.
3. Los resultados de la evaluación se revisan junto con el cambio.
4. Si las evaluaciones se superan —sin regresiones y, preferiblemente, con mejoras—, el cambio puede aprobarse.
5. Los cambios aprobados se despliegan.
6. La monitorización posterior al despliegue detecta lo que las evaluaciones hayan podido pasar por alto.

Para los prompts relevantes, conserva un conjunto de evaluación representativo y ejecuta en CI los controles estables y automatizables cuando la señal sea suficientemente fiable para bloquear un cambio. Usa revisión experta o humana cuando el criterio no pueda reducirse a una puntuación automatizada. Registra qué se probó, el umbral, quién revisó y la incertidumbre residual.

Este control no demuestra que todo sea correcto. Hace inspeccionable la decisión de publicación y aporta una referencia para detectar regresiones tras el despliegue.

Lista de verificación práctica para una publicación

Antes de que una versión de prompt vaya a producción, exige una breve lista de verificación:

La lista complementaria enlazada desde este artículo convierte estas comprobaciones en un proceso de publicación repetible.

Pruebas A/B en producción

Para prompts aptos para experimentación online, una comparación gradual con la versión actual puede aportar señales reales adicionales a las evaluaciones offline. No uses tráfico real como primera prueba de seguridad ni expongas a las personas a un tratamiento sustancialmente más arriesgado solo para obtener datos.

Patrón ilustrativo, no reparto predeterminado:

• El 95% del tráfico usa el prompt de producción v3.
• El 5% recibe la versión candidata v4.
• Mantén el acceso al modelo, los permisos de herramientas y los límites de acciones dentro de la frontera aprobada de producción.
• Mide el éxito de la tarea, los errores de seguridad y política, los comentarios de usuarios, las métricas posteriores y las evaluaciones revisadas sobre tráfico elegible.
• Define antes de empezar la muestra mínima, las condiciones de parada, la persona responsable y una reversión en un solo paso.
• Cuando haya evidencia suficiente, decide si ampliar, revisar o detener la versión candidata.

Los mecanismos de entrega incluyen indicadores propios de funcionalidad, configuración de despliegue, un registro de prompts aprobado o enrutamiento personalizado.

Limitaciones:

• Las pruebas A/B solo capturan las señales que se miden. Si no dispones de comentarios de usuarios ni de métricas de conversión posteriores, aportarán poca información.
• La significancia estadística requiere volumen. Para funciones de bajo volumen, las pruebas A/B son difíciles.
• Los experimentos simultáneos pueden interactuar y confundir la atribución; controla de forma deliberada los solapamientos.
• Considera las obligaciones de aviso, consentimiento, exclusión y revisión según el producto, la población y la jurisdicción. Las acciones de alto impacto o irreversibles suelen exigir más aprobación y reversibilidad que una simple división del tráfico.

Observabilidad de prompts

Define telemetría respetuosa con la privacidad para cada flujo de producción. En llamadas que afecten a resultados relevantes, registra la información suficiente de los campos siguientes para identificar el comportamiento desplegado y reconstruir fallos:

• Qué plantilla de prompt se usó (nombre, versión).
• Qué variables se sustituyeron, utilizando nombres permitidos y valores anonimizados cuando sea necesario.
• El prompt final renderizado, pero solo cuando la política lo permita; de lo contrario, una representación anonimizada, muestreada o resumida mediante un hash.
• La respuesta del modelo, anonimizada o muestreada en los flujos de trabajo sensibles.
• Latencia, tokens y coste.
• Señales posteriores: comentarios de los usuarios y métricas de éxito.

El objetivo es responder qué versión se ejecutó, qué evidencia autorizada recibió, qué salida validada produjo, qué herramientas o políticas intervinieron y qué ocurrió después. No registres razonamiento oculto como sustituto de esos hechos.

Almacenamiento: una tabla de base de datos o una herramienta de observabilidad. Registrar todo tiene un coste real —volumen de llamadas × cantidad de tokens × almacenamiento— y también supone un riesgo para la privacidad. Decide en cada flujo de trabajo qué campos pueden almacenarse de forma segura, anonimiza por defecto los secretos y los datos personales y aplica periodos de retención cortos, salvo que exista un requisito normativo para conservar las trazas durante más tiempo. Algunos equipos solo guardan una muestra.

Define la frecuencia y el muestreo según el volumen, el riesgo, el ritmo de cambios, los incidentes y los límites legales. Revisa trazas anonimizadas o aprobadas, incluye casos límite conocidos e incorpora a las evaluaciones los fallos confirmados. Una muestra semanal puede servir a un flujo y ser inadecuada o insuficiente para otro.

Antipatrones de prompts

Algunos patrones a evitar:

Antipatrón 1: un prompt multipropósito sin responsable. Un prompt grande que combina funciones, políticas, ejemplos y supuestos de ejecución no relacionados puede ser difícil de revisar, evaluar y revertir. La longitud por sí sola no es el defecto; lo es la complejidad no medida.

Solución: separa componentes por responsabilidad y límite de cambios cuando resulte útil, elimina instrucciones duplicadas u obsoletas y compara el diseño revisado en evaluaciones representativas.

Antipatrón 2: concatenación directa de cadenas.

prompt = "You are helpful. " + (
    "The user is a paid customer. " if user.tier == "paid" else ""
) + f"Their name is {user.name}. " + ...

Es frágil y difícil de leer. La concatenación también dificulta inspeccionar los límites entre instrucciones y datos, pero trasladar los mismos valores a una plantilla no neutraliza instrucciones maliciosas.

Solución: sistema de plantillas.

Antipatrón 3: el mismo prompt para demasiados casos de uso.

Un único prompt general se utiliza para redactar correos, revisar código, prestar soporte al cliente e investigar. Son tareas diferentes y un solo prompt no estará optimizado para ninguna.

Solución: utiliza prompts del desarrollador específicos para cada funcionalidad sobre un prompt del sistema compartido.

Antipatrón 4: prompts codificados de forma rígida.

response = openai.chat.completions.create(
    messages=[
        {"role": "system", "content": "You are a helpful assistant..."},
        {"role": "user", "content": query}
    ]
)

El prompt queda enterrado en el código. No puede editarse sin realizar un despliegue, compararse mediante pruebas A/B ni versionarse de forma independiente.

Solución: extrae a un archivo de prompt o servicio.

Antipatrón 5: ausencia de cobertura de evaluación.

Una funcionalidad se publica con un prompt que nunca se ha probado de forma sistemática. La calidad se basa en impresiones y no es posible detectar su degradación.

Solución: añade una cobertura de evaluación proporcional al riesgo para los comportamientos relevantes, incluidos los fallos y las derivaciones.

Antipatrón 6: mezclar datos con el prompt del sistema.

Eres un asistente para John, un cliente prémium que se registró en 2023, vive en Tallin y tiene 47 tickets abiertos.

El prefijo de instrucciones reutilizable cambia en cada llamada, lo que puede reducir el uso de la caché y ocultar la distinción entre política y datos del cliente.

Solución: transporta los datos dinámicos mediante la entrada o el mecanismo de contexto del proveedor, con procedencia, autorización y minimización. No infieras confianza a partir del rol del mensaje.

Antipatrón 7: instrucciones enterradas en el cuerpo del prompt.

Ayuda al usuario con su solicitud. Sé educado. Formatea la salida como JSON. No uses Markdown. El usuario pregunta por precios, así que cita las cifras con cuidado. La salida debe tener 1-2 oraciones. Ayúdalo ahora.

Los requisitos críticos son más difíciles de descubrir para quien revisa y pueden entrar en conflicto con el texto cercano.

Solución: agrupa las instrucciones críticas en un bloque claramente etiquetado, expresa cada regla una sola vez y prueba si el modelo elegido las sigue en contextos largos y adversarios representativos.

Patrones para funcionalidades habituales

Estos son algunos patrones específicos:

Clasificación

Tarea: clasifica el siguiente texto en una de estas categorías:
- billing: pago, reembolso, suscripción
- technical: fallo, error, problema de integración
- account: inicio de sesión, contraseña, cambios de perfil
- feature_request: solicitudes de nuevas funciones
- complaint: insatisfacción general sin un problema concreto sobre el que se pueda actuar

Devuelve un objeto JSON: {"category": "<one of above>", "confidence": "<high|medium|low>", "reasoning": "<1 sentence>"}

Texto que se debe clasificar:
{text}

Patrones: categorías enumeradas con definiciones, salida estructurada y campos de confianza y razonamiento.

Extracción

Tarea: extrae datos estructurados del documento que aparece a continuación.

Esquema:
- vendor_name: empresa que emitió la factura
- invoice_number: tal como aparece en el documento
- date: formato ISO 8601
- line_items: array de {description, quantity, unit_price, total}
- subtotal, tax, total: números

Reglas:
- Si un campo no está presente, usa null
- Los números deben ser valores numéricos, no cadenas
- En los casos ambiguos, establece "needs_review": true y explícalo

Documento:
{document}

Patrones: esquema explícito, tipos esperados, tratamiento de datos ausentes y derivación de casos ambiguos.

Generación con estilo

Tarea: escribe un contenido en formato {format} sobre {topic}, dirigido a {audience}.

Estilo:
- {Specific style trait 1}
- {Specific style trait 2}
- Evita: {anti-pattern 1}, {anti-pattern 2}

Restricciones:
- Extensión: {N} palabras
- Incluye: {required elements}
- Excluye: {forbidden elements}

Referencia de voz:
[Provide a sample of the desired voice]

Salida: solo el contenido en formato {format}, sin introducción ni comentario final.

Patrones: rasgos de estilo concretos —no genéricos—, restricciones explícitas y una voz anclada mediante una muestra de referencia.

Bucle de un agente

Tienes acceso a las siguientes herramientas:
{tool_descriptions}

En cada turno:
1. Determina qué debes hacer.
2. Decide si necesitas una herramienta. Si es así, llámala.
3. Tras observar el resultado, decide si necesitas más herramientas o ya puedes responder.
4. Cuando tengas suficiente información, prepara la respuesta final.

Restricciones:
- Un máximo de 5 llamadas a herramientas por solicitud.
- Si no puedes completar la tarea después de 5 llamadas, explica qué falta.
- Nunca inventes nombres de herramientas ni argumentos.
- Verifica los resultados de las herramientas antes de actuar en función de ellos.

Solicitud del usuario:
{user_query}

Patrones: procedimiento por etapas para usar herramientas, presupuesto de herramientas, validación explícita y gestión acotada de fallos.

El aspecto del equipo

Los prompts de producción suelen involucrar a varias personas:

• Ingeniería integra los prompts en el sistema, mantiene las plantillas y gestiona los despliegues.
• Producto define los resultados que deben lograr los prompts.
• Contenido/marketing es responsable de la guía de voz y estilo.
• Especialistas del dominio determinan qué es correcto en casos de uso específicos: lenguaje jurídico, terminología médica, etc.

Un patrón útil es establecer un proceso de «revisión de prompts» similar a la revisión de código, con las personas adecuadas para cada ámbito. El equipo de contenido revisa los cambios de voz; ingeniería, los cambios de lógica; y los especialistas, el contenido propio de su dominio.

En casos de uso sensibles —jurídicos, médicos o financieros—, los prompts pueden requerir una revisión y aprobación formales. Diseña el proceso en consecuencia.

Plan de madurez de prompts con validación por etapas

Para los equipos que quieren pasar de «los prompts son cadenas dentro del código» a «los prompts son infraestructura gestionada»:

Etapa 1: Fundamentos.

• Haz un inventario de los prompts que influyen de forma sustancial en el comportamiento y del código que los construye.
• Define el modelo de autoridad de las instrucciones, el límite de los datos en tiempo de ejecución, las personas responsables y cómo se adapta el diseño a cada proveedor.
• Elige una fuente de verdad gobernada y un enfoque de plantillas adecuado para el flujo de publicación.
• Configura una telemetría respetuosa con la privacidad que identifique la versión desplegada y el resultado sin conservar contenido sensible innecesario.

Etapa 2: Evaluación.

• Construye primero suites de evaluación para los prompts de mayor riesgo y volumen.
• Ejecuta evaluaciones representativas cuando haya cambios sustanciales en los prompts, con la revisión de especialistas cualificados del dominio cuando sea necesario.
• Incorpora comprobaciones automatizadas estables a la CI y mantén visibles en el registro de revisión las decisiones de aceptación que no puedan automatizarse.

Etapa 3: Operaciones.

• Implementa el versionado de prompts en el repositorio, registro o servicio elegido.
• Añade un mecanismo de despliegue gradual y detención; usa pruebas A/B solo en los flujos de trabajo que cumplan los requisitos para ello.
• Configura la supervisión de la calidad, la seguridad, el cumplimiento de políticas, la latencia, el coste y las señales posteriores que necesite el flujo de trabajo.
• Establece un proceso de revisión para los cambios en los prompts.

No prometas este resultado en un calendario. Sal de la secuencia solo cuando las pruebas demuestren que el inventario de prompts está completo, los cambios críticos están versionados y sujetos a controles, la reversión funciona, la telemetría identifica la versión desplegada y las personas responsables pueden ensayar la respuesta a un incidente.

Prompts como infraestructura

Los prompts de producción pueden almacenarse como cadenas, pero funcionan como componentes versionados del sistema, con controles a su alrededor para el ensamblaje, la evaluación, la publicación, el acceso y la observabilidad.

Una jerarquía de instrucciones define la autoridad; no protege los datos en tiempo de ejecución ni las acciones de las herramientas. Las plantillas pueden reducir los errores de ensamblaje, pero no evitan la inyección de prompts. Una fuente de verdad gobernada proporciona un historial de versiones. Las evaluaciones proporcionales al riesgo orientan las decisiones de publicación, y la telemetría comprueba si el comportamiento previsto se mantiene fuera del conjunto de evaluación.

El rigor necesario depende del riesgo y el alcance, pero todo control omitido necesita una justificación registrada. Las afirmaciones que se publiquen deben mostrar la evidencia de versionado, evaluación, despliegue gradual, reversión y telemetría que se haya implementado realmente.

La capacidad de control prevista sigue siendo una hipótesis hasta que las evaluaciones y la telemetría de producción demuestren que el modelo, la versión del prompt, la ruta de los datos, las herramientas y las políticas seleccionados se comportan dentro de los umbrales de aceptación. Conserva esa evidencia junto con la versión publicada, investiga los fallos por versión y mantén operativa la reversión.

Empieza con la arquitectura mínima que haga explícitas la responsabilidad, la autoridad, la gestión de datos, la evaluación, el despliegue, la reversión y la evidencia.