El verdadero trabajo está antes del prompt
El taller de prompts que empezó demasiado tarde
El taller se reservó para mejorar los prompts. Ese era el título en el calendario, con un alegre icono de varita mágica que alguien lamentó después. Un grupo de directivos, analistas, operadores e ingenieros se sentó alrededor de una mesa con un documento compartido. El prompt actual estaba en la pantalla. Pedía a un modelo de lenguaje que revisara las solicitudes de los clientes, identificara la política correcta, redactara una respuesta y marcara los riesgos. Era educado, estructurado y mucho más largo de lo que nadie quería admitir. Tampoco era el problema principal.
El primer caso de prueba fue un cliente que solicitaba una excepción tras un retraso en la entrega. El modelo produjo una respuesta aceptable. Entonces alguien de operaciones dijo que la política de origen en la pantalla ya no era la que el equipo usaba los viernes, porque una regla temporal del transportista se había prorrogado dos veces pero nunca se había integrado en la página principal de políticas. Alguien de legal dijo que las excepciones por encima de cierta cantidad requerían aprobación, pero el umbral dependía de la categoría del producto. Finanzas preguntó dónde se registraban los créditos de buena voluntad. Soporte dijo que el tono del modelo estaba bien, pero que el cliente volvería a llamar porque la respuesta no mencionaba el evento de seguimiento que faltaba. El prompt permaneció allí con aspecto inocente.
Ninguno de esos problemas se resolvería con un mejor párrafo de instrucciones. El modelo no podía deducir qué página de política era la autorizada. No podía saber que una regla temporal se había convertido en la realidad operativa. No podía decidir quién tenía autoridad de aprobación. No podía ver que el evento de seguimiento que faltaba era la causa real del siguiente contacto. Se pedía al prompt que compensara un trabajo poco claro. Este es un error común. La gente llega al prompt con una cesta de ambigüedad de procesos y pide al modelo que sea elegante al respecto.
El trabajo real está antes del prompt. Es el trabajo de nombrar la tarea, definir el límite, seleccionar las fuentes, fijar la autoridad, preparar ejemplos, decidir las vías de fallo, dar forma a la salida, medir la calidad y hacer posible la corrección. Los prompts importan. Un mal prompt puede hacer torpe una buena configuración. Pero un prompt bonito sobre una operación poco clara es solo confusión bien redactada. El modelo puede sonar mejor. El trabajo no será más seguro, más barato ni más comprensible por accidente.
Un prompt no es un mapa de procesos
Un prompt puede indicar a un modelo cómo comportarse en un contexto. No puede crear el contexto si la organización no lo ha hecho. Puede pedir brevedad, estructura, humildad y citas. Puede describir un rol. Puede especificar un formato. Puede advertir al modelo que no adivine. Todo esto es útil. Pero también es poco en comparación con las preguntas de proceso que determinan si un sistema de IA ayuda o simplemente habla con seguridad cerca del trabajo.
¿Cuál es la tarea? ¿Es clasificación, extracción, resumen, redacción, enrutamiento, recomendación, verificación o acción? ¿Qué parte está automatizada? ¿Qué parte sigue siendo humana? ¿Qué estado cambia si se acepta el resultado? ¿A quién afecta? ¿Qué registros se tocan? ¿Qué política se aplica? ¿Qué evidencia es obligatoria? ¿Qué ocurre cuando falta la evidencia? ¿Qué errores son tolerables? ¿Qué errores causan daño? Estas preguntas deciden la forma del sistema. Un prompt que no se apoya en respuestas claras se convierte en una suposición educada con una etiqueta de nombre.
Muchos pilotos de IA fallidos comienzan con un prompt porque el prompt es el asidero más visible. Se siente creativo e inmediato. Puedes editarlo en una reunión. Puedes probar una versión nueva antes de que se enfríe el café. El diseño de procesos es más lento. La limpieza de datos es más lenta. El mapeo de autoridad es más lento. La creación de conjuntos de evaluación es más lenta. Desafortunadamente, lento no es lo mismo que opcional. Las partes que se omiten antes del prompt regresan después como alucinaciones, retrabajo, desconfianza, excepciones de política y una hoja de cálculo enorme llamada incidencias.
La secuencia mejor no es glamorosa. Escribe el trabajo. Recorre casos reales. Identifica los sistemas de origen. Marca qué campos deciden los resultados. Separa las reglas del juicio. Decide dónde entran los humanos. Define los contratos de salida. Construye ejemplos. Acuerda el rechazo. Prueba con las personas que convivirán con el resultado. Solo entonces el prompt se convierte en una palanca útil. Antes de eso, es un volante decorativo sobre un escritorio.
La tarea necesita un límite lo bastante nítido para probarse
El trabajo con IA a menudo comienza con verbos demasiado amplios. Ayudar con el servicio al cliente. Apoyar la revisión legal. Mejorar la planificación. Asistir en las compras. Hacer que los informes sean más inteligentes. Estas son ambiciones, no tareas. Un modelo no puede evaluarse contra una ambición. Puede evaluarse contra una tarea con entradas, salidas, restricciones, criterios de éxito y rutas de fallo. La descripción más estrecha puede parecer menos emocionante. También es el primer momento en que el trabajo se vuelve construible.
Un límite de tarea nítido dice qué puede ver el sistema y qué puede cambiar. Dice si el modelo está leyendo material de origen, generando un borrador, extrayendo campos estructurados, recomendando una acción o llamando a una herramienta. Dice qué salidas son definitivas, cuáles son consultivas y cuáles deben revisarse. Dice qué rechaza el sistema. Dice cuándo el modelo debe pedir más evidencia en lugar de completar la respuesta. Dice qué queda fuera del alcance, porque fuera del alcance es donde los pilotos ambiciosos se convierten en informes de incidentes.
Los límites hacen posible la evaluación. Si la tarea es redactar una respuesta usando estas fuentes y esta política, la calidad puede probarse. Si la tarea es mejorar la calidad del servicio con IA, cualquier resultado puede explicarse como progreso por alguien con suficientes diapositivas. Un límite también protege a los usuarios de una escalada accidental. Una herramienta que comienza redactando puede adquirir un botón que envía. Un clasificador puede convertirse en un enrutador. Un enrutador puede convertirse en una decisión. Sin un límite nombrado, esta deriva parece adopción. Con un límite, se convierte en una solicitud de cambio.
El límite debe redactarse en lenguaje operativo, no solo técnico. El responsable de soporte debe entenderlo. Legal debe entenderlo. El propietario de los datos debe entenderlo. El ingeniero debe poder probarlo. Si el prompt es el único lugar donde vive el límite, el límite es frágil. Los prompts son importantes, pero no son documentos de política con peso normativo. Se parecen más a instrucciones para un trabajador temporal muy talentoso que nunca vio el organigrama.
Las fuentes no son un montón de documentos
Muchos equipos descubren durante el prompting que no saben qué fuentes son las autorizadas. Tienen páginas de políticas, PDFs, instrucciones por correo, material de formación, manuales antiguos, mensajes de chat, macros de tickets, hojas de cálculo de seguimiento y la memoria de una operadora a la que todos llaman porque ella sabe cómo funciona de verdad. Luego se le pide al modelo que responda desde la base de conocimiento. Qué conocimiento. Qué base. La frase puede estar haciendo una cantidad heroica de ocultación.
La preparación de fuentes no es glamurosa, por eso suele llegar tarde. Implica decidir qué documento gana cuando las fuentes discrepan, cómo se comprueba la frescura, cómo caducan las reglas temporales, cómo se representan las excepciones, cómo se excluye el material confidencial, cómo se conservan las versiones de las fuentes y cómo sobreviven los identificadores de cita en la respuesta del modelo. Esto no es papeleo. Es la diferencia entre recuperar y revolver.
La IA hace que la disciplina de fuentes sea más importante porque el modelo puede hacer que las malas prácticas de fuentes parezcan aceptables. Puede coser fragmentos en prosa fluida. Puede suavizar contradicciones. Puede producir una respuesta plausible a partir de material obsoleto. Un resultado de búsqueda con huecos visibles parece incompleto. Una respuesta generada con los mismos huecos puede parecer completa. Cuanto mejor es la prosa, más importante es la procedencia. No se debe permitir que la confianza blanquee una cadena de fuentes débil.
Una buena preparación de fuentes también reduce la complejidad del prompt. Un prompt lleno de advertencias sobre políticas en conflicto, documentos obsoletos, campos faltantes y excepciones especiales suele ser síntoma de abandono en fases anteriores. Si la capa de recuperación ya filtra por autoridad y frescura, el prompt puede ser más corto. Si la fuente lleva metadatos estructurados, el modelo no necesita inferirlos de los títulos de los párrafos. Si las excepciones se representan como reglas, el modelo no tiene que convertirse en detective con límites de tokens. La mejor mejora de un prompt a veces es un mejor índice.
Los ejemplos son pequeñas piezas de gobernanza
Los ejemplos suelen tratarse como material de apoyo para el entrenamiento, pero también son gobernanza. Un buen ejemplo define qué significa la calidad en una situación concreta. Muestra cómo la organización gestiona la incertidumbre, la falta de pruebas, los conflictos entre políticas, el tono delicado, la escalada y la negativa. Enseña al modelo y al equipo cómo es una buena respuesta, pero también cómo es una buena no-respuesta. Esto importa porque muchos sistemas serios fallan al responder cuando deberían pausar.
Crear ejemplos obliga a tomar decisiones que el debate abstracto evita. Tome veinte casos reales. Marque el resultado correcto. Marque las alternativas aceptables. Marque los atajos inaceptables. Explique el porqué. Incluya casos límite que hicieran dudar a los profesionales con experiencia. Incluya también casos ordinarios, porque los sistemas que solo se entrenan con drama aprenden malos modales. Pida a los expertos de la materia que discrepen y registre el desacuerdo. Esto es más lento que pedirle al modelo que sea cuidadoso. También produce un lenguaje compartido para definir lo que es ser cuidadoso.
Los ejemplos deben incluir casos negativos. No se encontró la fuente. Conflicto entre fuentes. El usuario no tiene autoridad. Solicitud fuera del propósito. El cliente pide algo que suena simple pero que activa una política. El modelo debe aprender cuándo negarse, escalar, preguntar o devolver una incertidumbre estructurada. Si los ejemplos solo muestran respuestas exitosas, el prompt tenderá hacia la finalización. Finalizar no siempre es éxito. A veces la mejor respuesta es que no hay pruebas suficientes, algo difícil de celebrar en una demostración pero útil en un sistema en funcionamiento.
Los ejemplos también son el comienzo de la evaluación. Pueden convertirse en casos de prueba, casos de regresión, material para formar revisores y muestras de supervisión. Cuando ocurre un incidente, un caso corregido puede convertirse en un nuevo ejemplo. Esto le da memoria al sistema. Sin ejemplos, los cambios en el prompt se convierten en cambios de humor. Alguien dice que la respuesta se siente mejor. Otro dice que se siente peor. El modelo sonríe en medio de todo, imperturbable ante la evidencia.
La forma de la salida es una decisión operativa
Los debates sobre prompts suelen dedicar demasiado tiempo al tono y muy poco a la forma de la salida. El tono importa, especialmente en la comunicación con clientes o con el público. Pero la forma de la salida determina si la respuesta se puede verificar, enrutar, almacenar, aprobar, impugnar o utilizar por otro sistema. Un párrafo puede ser agradable. Una salida estructurada puede ser operativa. El trabajo serio con IA a menudo necesita ambas cosas: prosa legible para las personas y campos que las máquinas puedan verificar.
La forma de salida incluye campos obligatorios, referencias a fuentes, confianza o incertidumbre, motivos de rechazo, indicadores de escalado, registros afectados, acciones propuestas y estado de aprobación humana. Indica si el modelo puede dejar un campo en blanco. Indica si debe citar un identificador de política. Indica si puede inventar categorías o debe elegir de una lista controlada. Indica qué ocurre cuando la entrada es ambigua. Estas decisiones no son cosmética del prompt. Son diseño del flujo de trabajo.
La salida estructurada también mantiene al modelo en su terreno. Si el sistema requiere un campo separado para la evidencia, las afirmaciones sin respaldo se vuelven visibles. Si requiere un tipo de acción de una lista permitida, el uso creativo de herramientas se vuelve más difícil. Si requiere que la incertidumbre sea explícita, los revisores pueden hacer triaje. Si requiere un motivo de rechazo, los casos bloqueados se pueden analizar. El prompt puede solicitar estas cosas, pero el sistema que lo rodea debería validarlas. Pedir amablemente no es un control. Es una sugerencia con formato.
Hay un lado humano. Las personas necesitan una salida que se ajuste a su ritmo de trabajo. Un abogado puede necesitar cláusulas de la fuente y notas de riesgo. Un agente de soporte puede necesitar un borrador listo para el cliente además de códigos de motivo internos. Un planificador puede necesitar una recomendación de ruta y la restricción que la motivó. Un gestor puede necesitar motivos agregados, no prosa individual. Si la forma de salida ignora al usuario, el prompt puede ser técnicamente correcto y operativamente irritante. Eso es un logro común, pero no uno útil.
La autoridad no se puede implicar con la amabilidad
Un modelo servicial invita a la confianza. Eso es bueno hasta que la amabilidad se confunde con autoridad. Si el modelo redacta una respuesta, quién puede enviarla. Si recomienda un reembolso, quién puede aprobarlo. Si clasifica el riesgo, quién puede actuar según la clasificación. Si extrae un campo, quién lo corrige. Si no encuentra evidencia, quién decide si se continúa. Estas preguntas deben responderse antes del prompt, porque el prompt no puede otorgar autoridad institucional.
El diseño de la autoridad incluye roles, umbrales, colas de revisión, derechos de anulación, rutas de escalado y registros de auditoría. Distingue la sugerencia de la decisión. Distingue la decisión automatizada de la decisión humana respaldada por automatización. Indica cuándo una persona debe ver el material de origen y no solo la prosa del modelo. Indica cuándo se permite una llamada a una herramienta y cuándo se bloquea. Indica quién asume el daño, el retraso, la corrección y la comunicación. El modelo puede ayudar dentro de ese diseño. No debería ser el diseño.
Esto es especialmente importante cuando se añade IA a flujos de trabajo existentes. La autoridad existente puede ser informal. Un senior aprueba excepciones porque todos saben que hay que preguntarle a él. Un líder de equipo interpreta la política porque ha visto los casos límite. Una hoja de cálculo contiene una regla temporal porque el sistema no puede. Cuando entra la IA, la autoridad informal se vuelve frágil. El modelo puede escalar la antigua ambigüedad más rápido de lo que las personas pueden detectarla. El trabajo previo al prompt es hacer que la autoridad sea lo bastante explícita para que el escalado no escale simplemente la confusión.
Vale la pena decir que la autoridad no es enemiga de la velocidad. Una autoridad clara a menudo hace que el trabajo sea más rápido porque las personas saben qué puede avanzar sin debate, qué debe pausarse y quién puede decidir. La autoridad vaga parece flexible hasta que se encuentra con el volumen. Entonces cada caso difícil se convierte en una pequeña crisis constitucional, con hilos de chat como jurisprudencia. Ese no es un sistema legal recomendable.
La evaluación no es una comprobación de impresiones
Muchas iteraciones de prompts se juzgan por sensaciones. Esta versión suena mejor. Esa es más concisa. Esta otra es menos autoritaria. Esos juicios pueden ser útiles, pero no bastan. Las operaciones de IA necesitan una evaluación que siga la tarea. ¿Usó el modelo la fuente correcta? ¿Omitió campos obligatorios? ¿Se negó cuando faltaba evidencia? ¿Escaló los casos de alto riesgo? ¿Conservó los identificadores de política? ¿Intervinieron humanos? ¿Los clientes hicieron menos preguntas de seguimiento? ¿Los equipos posteriores vieron menos retrabajo?
La evaluación debe incluir casos ordinarios, casos límite, casos adversarios, fuentes desactualizadas, datos faltantes, políticas en conflicto y ejemplos de negativa aceptable. Debe ser repetible. Debe distinguir el fallo del modelo del fallo de la fuente, del fallo del prompt, del fallo de la interfaz y del fallo del proceso. De lo contrario, todo problema se convierte en un problema de prompt porque el prompt es la parte que todos pueden ver. La parte visible no siempre es la culpable. Esto es cierto tanto en el software como en las reuniones.
La evaluación también decide cuándo detenerse. Sin un conjunto de pruebas y criterios de publicación, el trabajo con prompts puede continuar para siempre porque el lenguaje siempre se puede mejorar. Siempre habrá otro adjetivo, otra instrucción, otro ejemplo, otro ajuste de formato. La pregunta no es si el prompt es perfecto. La pregunta es si el sistema realiza la tarea dentro de los límites acordados de riesgo, costo y calidad. La perfección es una mala gestora de publicaciones. No lleva un localizador.
El trabajo posterior al prompt comienza antes de la publicación
Las vías de corrección deben diseñarse antes de que el primer usuario de producción informe de un problema. ¿Cómo señala un usuario una respuesta incorrecta? ¿A dónde va ese aviso? ¿Quién lo revisa? ¿Cambia la fuente? ¿Cambia el banco de ejemplos? ¿Cambia el prompt? ¿Cambia una regla? ¿Cambia un umbral? ¿Recibe un humano retroalimentación? ¿El caso corregido se convierte en una prueba de regresión? Si la corrección no está diseñada, la retroalimentación se convierte en un montón. Los montones son donde el aprendizaje se va a echar una siesta larga.
La supervisión también debe decidirse antes de la publicación. No solo se debe rastrear la latencia y el costo, sino también las tasas de negativa, las tasas de fuentes faltantes, los motivos de anulación, la carga de escalado, el retrabajo posterior, los temas de quejas, las citas desactualizadas y la deriva en la combinación de tareas. La calidad de la respuesta del modelo es solo una parte de la calidad operativa. Un sistema puede responder bien y aun así derivar demasiado trabajo a los humanos. Puede responder rápido y aun así aumentar las correcciones. Puede reducir los tickets y aun así crear tickets más difíciles. La supervisión debe ver el trabajo, no solo los tokens.
El trabajo previo al prompt nunca termina de verdad. Aparecen nuevas políticas. Los sistemas de origen cambian. Los usuarios encuentran atajos. El modelo cambia. El negocio cambia. Un prompt que funcionaba en mayo puede estar mal en septiembre porque el trabajo se ha movido por debajo. Esto no significa que todo sea frágil. Significa que las operaciones de IA necesitan una propiedad clara. Alguien debe mantener la definición de la tarea, las fuentes, los ejemplos, la evaluación, la autoridad y la reparación. De lo contrario, el prompt se convierte en un fósil con una gramática excelente.
La lección
El trabajo real está antes del prompt porque el prompting es el borde visible de un sistema operativo más amplio. El modelo necesita una tarea que pueda realizar, fuentes en las que pueda confiar, límites que no pueda cruzar, resultados que puedan comprobarse, ejemplos que codifiquen el criterio, autoridad que diga a las personas y a las herramientas qué pueden hacer, y una evaluación que pueda distinguir la mejora de una prosa más bonita. Sin eso, el prompt asume responsabilidades que no puede cumplir.
Esta visión no resta valor al prompting. Lo hace más valioso. Un prompt dentro de una operación preparada puede ser breve, claro, comprobable y mantenible. Puede centrar el modelo en lugar de compensar la ambigüedad. Puede evolucionar con ejemplos y evidencia. Puede cambiarse con confianza porque el equipo sabe qué significa hacerlo bien. Eso es mejor que el misticismo del prompt, que sobre todo produce prompts más largos y dudas más silenciosas.
Antes de preguntar cómo hacer el prompt al modelo, pregunta qué trabajo ya ha hecho la organización para el modelo. ¿Está nombrada la tarea? ¿Son autoritativas las fuentes? ¿Están marcados los ejemplos? ¿Está estructurada la salida? ¿Es explícita la autoridad? ¿Es seguro el fallo? ¿Es real la evaluación? ¿Está diseñada la reparación? Si esas respuestas son débiles, empieza ahí. El prompt más útil de la sala puede ser el que hace que todos admitan que el prompt no es donde empieza el trabajo.