Todos en tu oficina le piden algo distinto a la misma inteligencia artificial.

Marketing la usa para resumir juntas. Ventas para armar propuestas. Alguien en finanzas descubrió que también hace fórmulas de Excel si se le explica bien.

El problema no es que cada quien use IA a su manera. Es que cuando esa persona se va de vacaciones, cambia de puesto o simplemente se le olvida cómo le hizo, el conocimiento se va con ella.

Esa es la falla real que resuelve saber cómo crear prompts reutilizables para equipos de trabajo: no es un truco de productividad, es evitar que tu operación dependa de la memoria de una sola persona.

Anthropic lo confirmó sin querer queriendo el 10 de septiembre de 2026, cuando presentó Smart Reports para Claude Enterprise: una función en beta que analiza cómo usa la IA un equipo y detecta patrones repetidos que podrían convertirse en habilidades compartidas.

Traducido: hasta las plataformas ya se dieron cuenta de que la gente reinventa la rueda todos los días, nada más que con distinta redacción. Aquí va el método completo para dejar de hacerlo.

Todos en la oficina le piden algo distinto a la misma IA

Esto me recuerda a cuando en las oficinas de los noventa cada quien tenía su propia plantilla de Excel para lo mismo.

El “presupuesto_final_v3_YA.xls” que solo esa persona entendía, con macros que nadie más se atrevía a tocar.

Treinta años después seguimos haciendo lo mismo. Nada más que ahora la plantilla es un prompt guardado en las notas del celular.

Un prompt mal armado no solo produce un resultado mediocre. Produce un resultado distinto cada vez que otra persona lo intenta replicar, porque nadie documentó qué contexto llevaba, qué formato pedía o qué reglas tenía.

Eso es exactamente lo que describe NIST en su perfil de IA generativa (AI 600-1, julio 2024): la variación de calidad y la dependencia de “quien sabe pedirle bien a la máquina” son riesgos operativos, no anécdotas de oficina.

¿Qué tareas merecen convertirse en una habilidad y cuáles no?

No todo prompt exitoso merece jubilarse como proceso oficial. Antes de invertir tiempo en documentarlo, aplícale esta prueba:

Si una tarea cumple al menos cuatro de estos cinco puntos, ya no es un prompt: es un proceso que alguien tiene que dueñar.

Convertir transcripciones en minutas, transformar una entrevista en esquema de artículo, extraer datos de facturas o adaptar un texto a tres formatos distintos son ejemplos típicos.

“Ayuda a marketing con la IA” no califica para nada. Es tan vago como pedirle a alguien que “sea más productivo”.

La ficha que convierte un prompt en un proceso real

Aquí está el error que veo repetirse en consultoría: la gente cree que documentar un prompt es copiar y pegar el chat que funcionó.

No. Una habilidad real necesita una ficha con estos elementos:

• Nombre orientado a resultado, no a la herramienta. “Minuta accionable de reunión con cliente”, no “prompt de Claude para juntas”.
• Propósito — qué problema resuelve y cuándo se usa.
• Usuario previsto — quién puede ejecutarla.
• Disparador — qué insumo necesita (transcripción, brief, CSV).
• Instrucciones base — rol, secuencia, reglas explícitas.
• Variables editables — cliente, tono, idioma, plazo.
• Formato de entrega — tabla, correo, esquema.
• Criterios de aceptación — qué hace que la salida sea buena.
• Límites — qué no debe hacer y cuándo debe detenerse a preguntar.
• Ejemplo de entrada y salida ya aprobada.
• Responsable y fecha de revisión.

Sin ejemplo de entrada y salida aprobada, la ficha es teoría. Con él, cualquiera en el equipo puede comparar su resultado contra uno que ya funcionó.

Cómo crear prompts reutilizables para equipos de trabajo

La instrucción base no debe depender de frases mágicas. Tiene que reducir ambigüedad y obligar al modelo a trabajar con evidencia, no con suposiciones. Esta es la estructura que uso con clientes, lista para copiar y adaptar:

Objetivo: [resultado de negocio o de trabajo].
Contexto: [audiencia, producto, canal, restricciones].
Material fuente: [documentos, enlaces aprobados, transcripción o datos].
Tarea: realiza [acciones concretas y ordenadas].
Reglas: no inventes datos; señala faltantes; distingue hechos de inferencias; conserva [tono/terminología].
Formato: entrega [estructura exacta].
Control de calidad: antes de finalizar, verifica [lista breve de requisitos].
Escalamiento: si falta evidencia o la solicitud implica [riesgo], detente y formula preguntas.

Un ejemplo real para un equipo editorial, con la misma estructura ya llena:

“A partir exclusivamente de la entrevista y las fuentes adjuntas, crea un esquema de artículo. Separa: tesis, datos verificables, citas textuales, afirmaciones que requieren comprobación adicional y preguntas pendientes. No atribuyas declaraciones sin fuente. Entrega una tabla con las columnas: sección, idea principal, evidencia disponible, enlace o cita de origen, verificación requerida.”

Nada de esto depende de qué modelo uses. Funciona igual en Claude, ChatGPT o Gemini, porque la habilidad vive en el proceso, no en la plataforma.

Aquí entra una objeción que ya escuché varias veces en llamadas de diagnóstico: “¿para qué documentar esto si hay tutoriales gratis en YouTube?”

Un tutorial te enseña a pescar una vez. Una habilidad documentada le permite a cualquiera en tu equipo pescar igual de bien sin que tú estés ahí explicando por quinta vez lo mismo.

Antes de soltarla al equipo, pruébala con estos cinco casos

Una habilidad que solo se probó con el caso perfecto no está lista. Antes de publicarla, corre estos cinco escenarios:

• Un caso típico, el que se repite todos los días.
• Un caso incompleto, al que le falta un dato.
• Un caso largo o desordenado, sin estructura clara.
• Un caso con instrucciones contradictorias dentro del mismo archivo.
• Un caso donde la respuesta correcta sea “no hay información suficiente”.

Si la habilidad recibe documentos, páginas web o archivos externos, esa quinta prueba es la que más importa. NIST advierte sobre la inyección de instrucciones: cuando alguien manipula el contenido que el modelo va a leer para inducir un resultado distinto al que pediste.

La regla que evita esto: el contenido recuperado de fuera es dato, nunca instrucción. Si tu habilidad no distingue eso, cualquier documento externo puede secuestrar el resultado.

¿Quién es dueño de una instrucción que usa todo el equipo?

Publicar una habilidad no es mandarla por WhatsApp para que cada quien la copie a su manera. Ya vimos a dónde lleva eso.

La regla que funciona: todos pueden usar una habilidad aprobada, pocos pueden editarla, y una sola persona decide si se modifica, archiva o se retira.

Sin esa gobernanza mínima, terminas con la misma carpeta llena de archivos “final_v7_ahora_sí” que ya conocíamos antes de que existiera la IA. Solo que ahora son instrucciones, no hojas de cálculo.

Cómo saber si de verdad sirvió, sin adivinar

Antes de lanzar cualquier habilidad, registra una línea base: cuánto tarda la tarea hoy, cuántas rondas de corrección necesita normalmente, qué tan distinto sale el resultado entre dos personas distintas.

Después, mide durante cuatro a seis semanas:

• Adopción — cuánta gente la usa y cuántas veces.
• Eficiencia — minutos ahorrados frente al método anterior.
• Calidad — porcentaje de entregables aceptados sin reescritura mayor.
• Retrabajo — número de rondas de corrección.
• Riesgo — si hubo algún dato expuesto o una salida que necesitó corrección factual.

La pregunta que importa no es cuántos prompts guardaste. Es cuántas tareas dejaron de depender de que alguien “le sepa pedir bien” a la máquina.

Si tu equipo ya llegó al punto de que documentar procesos les gana tiempo, pero no saben por dónde empezar a estructurarlo sin que se les caiga en la implementación, ahí es exactamente donde trabajo con organizaciones. Puedes revisar cómo lo abordamos en consultoría.

Para quien quiera profundizar en la lógica detrás de por qué un prompt mal armado sigue produciendo resultados inconsistentes, ya lo desarrollé con más detalle en esta guía sobre IA generativa.

Supervisado por Santiago González y Musi.