1 · Dónde usar ChatGPT

Web, aplicación de escritorio y móvil. Parte de la configuración está asociada a tu cuenta o a tu espacio de trabajo, pero la interfaz, los permisos locales y algunas funciones cambian según la superficie y el dispositivo. Para seguir esta guía, anota desde dónde estás trabajando.

2 · Comprueba qué cuenta y plan tienes

Lo que ves puede cambiar según tu cuenta, tu plan, tu espacio de trabajo, la aplicación y el despliegue gradual de funciones. No memorices nombres de modelos ni rutas como si fueran permanentes: aprende qué función buscas y qué decisión controla.

3 · Reconoce la interfaz

Ubica estos elementos antes de tocar nada:

• Chat — preguntar, buscar, generar ideas y ayuda rápida.
• Work — llevar una tarea con un resultado definido hasta una entrega revisable: investigar, analizar y crear documentos, hojas, presentaciones o informes. Su disponibilidad depende de tu plan, superficie y workspace.
• Nuevo chat — abrir una conversación limpia.
• Proyectos — agrupar trabajos continuados con sus chats, archivos, fuentes e instrucciones.
• Biblioteca — conservar y recuperar archivos cuando la función esté disponible (entrega posterior).
• Ajustes — se abre desde el menú de perfil; reúne Personalización, Memoria, Controles de datos y otras preferencias.
• Selector de modelo — el que tengas disponible en tu cuenta.

‹ ›

Chat, Work y Codex · documentación oficial de OpenAI

4 · Deja preparada la configuración básica

Localiza —todavía sin rellenar— dónde vive cada ajuste:

• Ajustes > Personalización
• Instrucciones personalizadas
• Acerca de ti
• Memoria
• Ajustes > Controles de datos

5 · Haz una primera prueba

Antes de configurar nada, elige un microencargo real de tu trabajo y guarda el mensaje y la respuesta completos. No añadas todavía el contexto que ChatGPT no podría conocer. Anota la fecha, si estabas en Chat o Work y qué falló. Al terminar el nivel 20 repetirás el mismo caso para comparar.

El ejemplo siguiente está incompleto a propósito: no indica cliente, fecha, canal ni tono. Sirve para observar qué presupone el modelo cuando todavía no conoce tu trabajo.

6 · Elige tu ruta

• «Nunca he configurado ChatGPT» → sigue aquí y continúa al nivel 20.
• «Ya conozco la interfaz» → salta a nivel 20 · Configúralo para ti.
• «Ya tengo instrucciones» → audítalas y pruébalas en el paso 5 antes de pasar a Proyectos.
• «Trabajo con otras personas» → completa primero tu capa personal; el trabajo compartido es el nivel 80.

Durante un tiempo prohibí utilizar IA en las comunicaciones de un equipo comercial que coordino.

La decisión llegó después de revisar correos que sonaban correctos y estaban mal resueltos: mensajes genéricos, condiciones comerciales no confirmadas y respuestas que contestaban las palabras del cliente sin entender qué necesitaba realmente.

ChatGPT estaba ahorrando minutos. También estaba introduciendo errores que después tenía que detectar otra persona.

El equipo no era el problema. Les habíamos dado acceso a una herramienta sin preparar el terreno. Cada persona abría una cuenta casi vacía, escribía como podía y esperaba que el modelo conociera su función, la empresa, las tarifas, los límites y la forma correcta de responder. No conocía nada de eso.

Yo tampoco estaba tan lejos. Había acumulado instrucciones sobre mi trabajo, Mugen AI, mi tono, mis proyectos y mis reglas dentro de una misma capa. Algunas respuestas salían clavadas. Otras parecían escritas por un folleto corporativo. Había personalizado ChatGPT, pero no había organizado un sistema de trabajo.

Copiar mi configuración al resto del equipo tampoco servía. Compartimos empresa y algunas fuentes, pero cada puesto produce resultados distintos, maneja riesgos distintos y necesita permisos distintos.

Este playbook nace de ese choque.

Dar acceso a ChatGPT no equivale a enseñar a un equipo a trabajar con él.

Por eso está escrito para la persona que tiene que usarlo dentro de un equipo —ventas, soporte, marketing, operaciones, administración o dirección—, no para «el empresario» que mira desde fuera. Puede intervenir dirección, pero quien lo mantiene es el equipo. Lo he dividido en dos fases.

Fase 01 · Preparar ChatGPT para trabajar en equipo

Es la fase que estamos desarrollando y publicando por entregas. Construye la base sobre la que se sostiene todo lo demás:

• Configuración personal de cada miembro.
• Proyectos y contexto compartido.
• Fuentes y orden de autoridad.
• Chats separados por resultado.
• Skills, Plugins y Library.
• Configuración común del equipo.
• Control: límites, aprobaciones y pruebas.

Fase 02 · Pasar del trabajo manual al sistema

Llegará después. Solo la anuncio para que sepas hacia dónde vamos: procesos repetidos, Codex trabajando sobre archivos y procedimientos, Skills operativas, integraciones, automatización, aprobaciones y mantenimiento.

Con mi propio sistema persigo un objetivo muy concreto: quitarme de encima hasta el 75 % del trabajo repetitivo que hoy depende de mí. Es una meta interna, no una promesa de resultados para quien lea esta guía. Cada equipo deberá medir su punto de partida, sus tareas y lo que realmente consigue reducir.

Y si vienes buscando un prompt maestro para copiar y pegar, aquí vas a encontrar algo menos rápido y bastante más útil: una configuración que el equipo pueda mantener, probar y explicar.

Ahora mismo están publicadas las Entregas 01 y 02. La Entrega 03 reunirá Skills, Plugins, Library, configuración común, control, pruebas y el cuaderno de implantación. La Fase 02 será un recorrido posterior, separado de este playbook.

La configuración por capas no es una jerarquía técnica oficial. Es una forma práctica de decidir dónde debe vivir cada dato para que resulte útil, comprobable y mantenible.

No des por supuesto que todas las capas se suman, se sustituyen o tienen siempre la misma prioridad. La interfaz y el comportamiento pueden cambiar según la cuenta, el workspace y la superficie. Una regla crítica debe vivir en el ámbito que controla el trabajo y superar una prueba allí.

Este es el mapa completo. No vas a construirlo todo en esta entrega, pero necesitas verlo para no meter la empresa entera dentro de tus instrucciones personales.

Decídelo con seis preguntas

1. ¿Debe influir en casi cualquier conversación? Instrucciones personales.
2. ¿Es contexto útil, pero no una obligación? Memoria.
3. ¿Lo compartirán varios resultados del mismo ámbito? Proyecto, instrucciones o fuentes del Proyecto.
4. ¿Solo hace falta para este resultado? Chat o archivo adjunto al chat.
5. ¿Describe un método que repetirás? Skill.
6. ¿Necesita consultar o actuar en otro servicio? Plugin, con los permisos mínimos necesarios.

Cuando dos capas puedan chocar, no adivines

Crea una prueba pequeña con dos instrucciones incompatibles y observa cuál se aplica en la cuenta, el Proyecto y el chat concretos que vas a utilizar. Guarda la fecha y el resultado. No conviertas ese experimento en una ley universal: úsalo para validar tu configuración actual.

En esta primera entrega solo construiremos la capa personal. El resto aparece porque necesitas reconocer lo que todavía no debe entrar en tus instrucciones personales.

Proyectos y chats · Memoria · documentación oficial de OpenAI.

No todo debe estar en todas partes. Repetir la misma norma en cinco capas no la hace cinco veces más fuerte. La hace cinco veces más difícil de mantener.

El error más frecuente empieza antes de abrir los ajustes. Antes de tocar un solo control vas a definir el trabajo, y no para todo el equipo de golpe: para una sola persona, tú. Este capítulo sirve para reunir materia prima. No vas a pegarla entera en Personalización: en el paso siguiente extraerás solo las preferencias y reglas que deban acompañarte entre chats.

Yo también lo metí todo junto

Yo no empecé de cero. Venía de trabajar sobre todo con Claude y ya tenía unas instrucciones personales que había ido corrigiendo sobre la marcha, en producción. Funcionaban. Pero estaban construidas como un cajón de sastre.

En el mismo sitio convivían quién soy, Mugen AI, el producto (Elio), miliperez.com, mi despliegue en GitHub → Netlify, mi forma de escribir y hasta un procedimiento de aprobación. Algo así:

## Quién soy
Mili Pérez.
Construyo sistemas de automatización de voz
e integración de agentes de IA.
Empresa: Mugen AI.
Marca personal: Mili Pérez.
Producto: Elio.
Web: miliperez.com.
GitHub → Netlify.

Todo era verdad. Ese era justo el problema.

Que una instrucción sea cierta no significa que deba vivir en tus instrucciones personales.

No necesitaba escribir un prompt todavía más largo. Necesitaba separar.

Abre el archivo que va a mandar

No escribas tus instrucciones directamente dentro de ChatGPT. Todavía no. Abre un archivo de texto:

MIS-INSTRUCCIONES-PERSONALES.md

Yo uso Markdown porque es texto limpio y portable. En mi caso acabó así:

MILI-IA/
└── 00-PERSONALIZACION/
    ├── MILI-PEREZ-INSTRUCCIONES-PERSONALES.md
    └── MILI-PEREZ-PERSONALIZACION-IA.md

El primero es mi versión maestra; el segundo, una versión comprimida para pegar donde haya menos espacio. No necesitas copiar mi estructura de carpetas. Lo importante es que tus instrucciones existan fuera de ChatGPT: van a cambiar, y si viven solo dentro de una caja de texto de una plataforma, mantenerlas se vuelve un pequeño infierno.

Tu .md es la fuente de verdad. ChatGPT recibe una copia adaptada.

Registra quién mantiene el archivo

Antes del contenido, añade un control mínimo. Si no sabes qué versión está instalada o quién debe corregirla, no tienes una fuente de verdad: tienes otra copia suelta.

## Control del documento
Responsable: [nombre o función]
Versión: 0.1
Última revisión: [AAAA-MM-DD]
Ámbito: preferencias personales entre chats
Versión instalada en: [cuenta y superficie]

Quién eres y qué necesita saber la IA

No escribas una biografía. La pregunta no es ¿qué cosas son ciertas sobre mí?, sino:

¿Qué necesita saber una IA sobre mí para trabajar mejor conmigo?

Esto aporta prácticamente nada:

Soy comercial.

No cambia una sola respuesta. Prueba con esto:

Trabajo en el equipo comercial de una empresa SaaS B2B.
Cualifico oportunidades, preparo propuestas
y hago seguimiento de clientes.
Trabajo con pymes y grandes cuentas.
Conozco CRM, automatización y herramientas comerciales.
No necesito explicaciones básicas sobre estos temas.
No puedo inventar precios, condiciones técnicas,
plazos ni disponibilidad de servicios.

Ahora sí hay información que puede modificar una respuesta. No intentamos impresionar al modelo, le damos información operativa.

Mi caso real. Mi primera capa quedó así:

## Quién soy
Soy Mili Pérez.
Trabajo en automatización, telecomunicaciones,
marketing, ventas e IA aplicada a negocio,
especialmente agentes de voz, telefonía, APIs,
integraciones y automatización de procesos.
Dirijo Mugen AI.
Tengo un perfil híbrido: negocio + tecnología + comunicación.
No simplifiques automáticamente los temas técnicos;
sé claro sin perder profundidad.

Fíjate en lo que no he puesto: mi NIF, mis precios, mis clientes, mis productos concretos, cómo despliego la web. No porque sean secretos, sino porque no hacen falta para que ChatGPT sepa trabajar conmigo en cualquier conversación. Eso vive en otras capas.

Los resultados que produces de verdad

No listes todo lo que algún día podrías llegar a hacer con ChatGPT. Escribe lo que haces de verdad, cada semana.

## Para qué uso IA habitualmente
- Preparar correos comerciales.
- Analizar oportunidades.
- Revisar documentación técnica.
- Crear propuestas.
- Investigar normativa.
- Preparar artículos.
- Auditar procesos.

Este inventario nos sirve después. Pero primero necesitamos saber qué trabajo existe de verdad.

Dónde está la verdad

En el capítulo anterior vimos por qué «no inventes» no basta: una regla crítica necesita fuente vigente, comportamiento ante el hueco, evidencia y aprobación. Aquí no copiamos precios ni datos de clientes; documentamos qué tipo de fuente manda y qué debe hacer ChatGPT cuando no pueda consultarla.

Para cada tipo de dato que no puedes permitirte inventar, apunta de dónde sale y qué debe pasar si no aparece:

## Fuentes y datos que no puedo inventar

Precios y condiciones:
- Fuente: [documento, sistema o persona responsable].
- Si el dato no aparece: [comportamiento].

Procesos:
- Fuente: [documento, sistema o persona responsable].
- Si existe una contradicción: [comportamiento].

Información que puede cambiar:
- Debe verificarse antes de utilizarla: [sí / no].
- Fuente prioritaria: [completar].

Acciones con consecuencias:
- Deben quedar como borrador: [completar].
- Persona que aprueba: [completar].

Los límites: qué no puede hacer

Aquí tampoco sirven «sé riguroso» o «sé prudente»: no definen ninguna acción. Mucho mejor:

No presentes estimaciones como hechos confirmados.
No envíes comunicaciones sin mi aprobación.
No mezcles información de clientes distintos.
Si una decisión excede la información disponible,
indica exactamente qué falta.
Cuando trabajes con información legal, económica
o técnica que pueda haber cambiado,
verifica fuentes actuales cuando tengas acceso.

Si no puedes imaginar qué hará el modelo cuando aparezca el problema, la regla es un adjetivo disfrazado.

Filtra antes de convertirlo en instrucciones

Revisa cada línea de tu borrador con estas cuatro preguntas:

1. ¿Debería afectar a muchas conversaciones, no solo al encargo de hoy?
2. ¿Cambia de forma observable una respuesta?
3. ¿Seguirá siendo cierta dentro de tres meses?
4. ¿Puede estar aquí sin exponer información que pertenece a un cliente, un Proyecto o una fuente controlada?

Si alguna respuesta es «no», no la pegues todavía. Muévela a la capa correcta o déjala como contexto del encargo.

Con esto protegemos primero el contenido. En el siguiente paso convertiremos la materia prima que ha pasado el filtro en comportamiento y voz.

Ya tienes la materia prima

Tu archivo todavía no son unas instrucciones terminadas. Es el material con el que vamos a construirlas: quién eres, qué produces, dónde está la verdad y qué no puede romperse.

La capa personal explica quién eres y cómo quieres trabajar normalmente.

El Proyecto responde a otra pregunta:

¿Qué contexto debe compartir ChatGPT cada vez que trabajamos en esta área?

Según la documentación oficial de OpenAI, conviene crear un Proyecto cuando el trabajo va a continuar en el tiempo, producirá más de un resultado o depende de los mismos archivos y fuentes. Si el encargo es independiente y no necesita contexto compartido, un chat sin proyecto puede ser suficiente.

Un Proyecto mantiene juntos:

• Los chats relacionados.
• Las instrucciones que deben aplicarse dentro de ese ámbito.
• Los archivos subidos.
• Las fuentes conectadas que deben estar disponibles para sus chats.

Eso no significa que todo el contenido del negocio deba vivir dentro de un único Proyecto llamado «Empresa».

Un Proyecto funciona bien cuando representa un perímetro de trabajo reconocible: tiene un objetivo estable, unas reglas comunes, unas fuentes relacionadas y una frontera que evita contaminarlo con información ajena.

Qué problema resuelve un Proyecto

Imagina que una persona trabaja durante una semana en cinco encargos distintos de marketing:

• Redactar un artículo.
• Preparar una newsletter.
• Revisar una página web.
• Crear un guion para un vídeo.
• Responder comentarios de LinkedIn.

Todos necesitan parte del mismo contexto: posicionamiento, público, tono, productos, términos prohibidos y ejemplos aprobados. Sin un Proyecto, ese contexto tendrá que adjuntarse, explicarse o recuperarse en cada chat.

Con un Proyecto bien configurado, los cinco chats pueden utilizar las mismas instrucciones y fuentes sin convertirse en una conversación infinita.

La diferencia es importante:

• El Proyecto conserva el terreno común.
• Cada chat persigue un resultado concreto.

No abras un chat eterno llamado «Marketing» para meter dentro artículos, campañas, informes, reuniones y ocurrencias. Crea un Proyecto de marketing y abre dentro un chat para cada resultado. OpenAI recomienda precisamente separar los chats por resultados distintos para mantener enfocados sus mensajes y entregables.

Cuándo crear un Proyecto y cuándo no

Utiliza estas tres preguntas:

1. ¿Este trabajo continuará durante varias sesiones o semanas?
2. ¿Generará varios resultados relacionados?
3. ¿Esos resultados necesitan las mismas instrucciones, archivos o fuentes?

Si respondes sí a una o varias, probablemente necesita un Proyecto.

La prueba del intruso

Antes de añadir algo a un Proyecto, pregunta:

¿Sería razonable que cualquier chat nuevo de este Proyecto pudiera utilizar esta información?

Si la respuesta es no, probablemente ese contenido pertenece a un chat concreto, a otro Proyecto o no debería subirse.

Una transcripción privada de un cliente no debe acabar en el Proyecto general de ventas porque «también tiene información comercial». Una tarifa interna no debe aparecer en un Proyecto editorial abierto a personas que no necesitan verla. Y la documentación de netelip no debe mezclarse con la de Mugen AI solo porque una misma persona trabaja en ambas áreas.

La frontera del Proyecto también es una frontera de contexto y de acceso.

Cómo separar los Proyectos del equipo

No existe una estructura universal. Debe seguir la forma real en la que se divide el trabajo y la información.

Para un equipo como el nuestro, una estructura inicial podría ser:

Esto es un ejemplo organizativo, no una orden para crear cinco Proyectos ahora mismo. Primero hay que confirmar qué personas necesitan cada contexto, quién mantendrá las fuentes y si las fronteras coinciden con los permisos reales del equipo.

No dividas por organigrama si el trabajo no se divide así

Crear Proyectos llamados «Marketing», «Ventas», «Soporte» y «Dirección» parece ordenado. Pero puede ser una mala estructura si todos necesitan la misma documentación o si cada cliente exige un aislamiento completo.

La unidad correcta no es necesariamente el departamento. Es el conjunto de trabajos que comparten:

• Las mismas reglas.
• Las mismas fuentes.
• Las mismas personas autorizadas.
• El mismo nivel de sensibilidad.
• Una continuidad real.

Señales de que un Proyecto es demasiado amplio

• Sus instrucciones están llenas de excepciones: «para este cliente sí, para aquel no».
• Contiene documentos que se contradicen porque pertenecen a áreas diferentes.
• La mayoría de los chats solo necesita una pequeña parte de sus fuentes.
• Hay personas con acceso a información que no necesitan.
• Resulta difícil explicar en una frase para qué sirve.

Señales de que has creado demasiados Proyectos

• Repites las mismas instrucciones y archivos en todos.
• Nadie sabe dónde abrir el siguiente chat.
• Una misma tarea salta continuamente entre varios Proyectos.
• Cada Proyecto contiene un único chat y no volverá a utilizarse.
• Mantener una tarifa o una guía exige actualizar diez copias.

Separar bien no significa fragmentarlo todo hasta convertir la barra lateral en un trastero con etiquetas.

Comprueba el contexto y los permisos disponibles

Antes de compartir el Proyecto, separa dos preguntas que suelen mezclarse:

1. ¿Qué contexto puede utilizar un chat de este Proyecto?
2. ¿Qué personas pueden ver o utilizar cada fuente y cada herramienta?

La documentación oficial confirma que un Proyecto reúne chats, archivos, fuentes e instrucciones relacionadas. También puede conservar contexto útil entre sus chats cuando la memoria correspondiente está disponible. Las opciones exactas pueden cambiar según la cuenta, el espacio de trabajo, la superficie y el despliegue de la función: comprueba lo que aparece realmente en tu interfaz antes de documentar el procedimiento del equipo.

No confundas pertenecer a un Proyecto con tener acceso automático a todo. El Proyecto, el espacio de trabajo, una fuente conectada y el entorno local aplican controles distintos.

Auditoría mínima antes de compartirlo

1. Enumera las personas que necesitan trabajar en el Proyecto.
2. Lista cada archivo, fuente conectada y herramienta que utilizarán.
3. Confirma qué necesita cada persona y para qué.
4. Haz la prueba con una cuenta miembro, no solo con la cuenta propietaria o administradora.
5. Retira el acceso o la fuente que no sea necesaria.
6. Registra quién hizo la comprobación y en qué fecha.

Con el perímetro claro, en el siguiente capítulo escribimos las instrucciones del Proyecto: las reglas que se aplican solo dentro de ese ámbito.

Las instrucciones personales acompañan a la persona entre trabajos. Las instrucciones del Proyecto se aplican a los chats de ese Proyecto y deben explicar cómo trabajar dentro de ese perímetro.

Aquí no hace falta volver a escribir toda tu biografía profesional. Tampoco debes pegar un procedimiento de cuarenta pasos para una tarea concreta. El objetivo es declarar las reglas comunes que cualquier chat de ese Proyecto necesita conocer.

Una instrucción de Proyecto útil debería responder a siete bloques.

Antes de escribir: controla la versión

Anota al principio quién mantiene las instrucciones, qué versión estás utilizando, cuándo se revisaron y a qué Proyecto o equipo se aplican. Sin esos cuatro datos, una regla antigua puede seguir pareciendo válida.

1. Identidad y objetivo del Proyecto

Explica qué área representa y para qué se utilizará.

No hace falta incluir aquí toda la historia de la empresa. Solo el contexto que permite situar el trabajo.

2. Resultados incluidos

Enumera qué trabajos pertenecen al Proyecto.

Por ejemplo:

• Artículos y guías.
• Newsletters.
• Páginas web.
• Correos de campañas.
• Argumentarios y materiales comerciales.
• Adaptaciones para redes sociales.

También puedes señalar expresamente qué resultados no pertenecen a este entorno.

3. Público

Una misma empresa no habla igual a un CEO, a un técnico y a un cliente que intenta resolver una incidencia.

Define:

• A quién se dirige normalmente.
• Qué sabe esa persona.
• Qué necesita entender.
• Qué decisión debería poder tomar después.

Si el público cambia en un encargo, se concreta en ese chat.

4. Reglas de contenido

Aquí viven los límites estables del área:

• No inventar precios, funciones, condiciones, casos o resultados.
• No convertir una estimación en un hecho.
• Mantener los nombres de marca con su grafía aprobada.
• Distinguir información pública, interna y confidencial.
• Señalar cuándo una afirmación necesita validación técnica, legal o comercial.
• No reutilizar datos de un cliente en el trabajo de otro.

Evita las órdenes abstractas. «Sé preciso» es más débil que «si una cifra no aparece en la fuente vigente, indica que falta y solicita confirmación».

5. Voz y vocabulario del ámbito

La persona puede tener una preferencia general, pero una marca o un área necesita sus propias reglas.

Incluye:

• Tono habitual.
• Nivel técnico.
• Vocabulario aprobado.
• Expresiones prohibidas o desgastadas.
• Convenciones de marca.
• Muestras que deben utilizarse como referencia estilística.

No intentes reproducir una voz humana solo con adjetivos. Añade muestras aprobadas a las fuentes y explica para qué sirven. Un ejemplo real de un buen artículo enseña más que «escribe con autenticidad, energía y cercanía».

6. Fuentes y orden de autoridad

Las instrucciones deben señalar qué clases de fuentes existen y cuál manda si aparecen discrepancias.

Ejemplo:

Esta parte evita uno de los fallos más caros: utilizar como fuente factual un documento que solo se había subido como ejemplo de estilo.

7. Incertidumbre, evidencia y aprobación

Define qué hacer cuando falta información, qué evidencia debe acompañar al resultado y qué acciones necesitan aprobación humana.

Plantilla de instrucciones de Proyecto

CONTROL DEL DOCUMENTO
- Responsable: [persona o función].
- Versión: [número].
- Última revisión: [fecha].
- Alcance: [Proyecto, equipo y superficies en las que se ha probado].

NOMBRE Y OBJETIVO
Este Proyecto reúne [área, cliente o iniciativa]. Se utiliza para [resultados].

TRABAJOS INCLUIDOS
- [Resultado 1]
- [Resultado 2]
- [Resultado 3]

PÚBLICO
Nos dirigimos principalmente a [público].
Su nivel de conocimiento es [nivel].
Necesita comprender [decisión o problema].

REGLAS DE CONTENIDO
- No inventes [datos especialmente sensibles].
- No presentes como confirmado [tipo de información].
- Mantén [convenciones de marca o vocabulario].
- Solicita validación cuando [situaciones].

VOZ Y FORMATO
- Tono: [descripción concreta].
- Nivel técnico: [nivel].
- Utiliza: [vocabulario].
- Evita: [vocabulario].
- Empieza por: [conclusión, problema, contexto].
- Formatos habituales: [formatos].

FUENTES Y PRIORIDAD
1. [Fuente canónica para cifras y hechos].
2. [Fuente oficial para procesos o producto].
3. [Fuentes secundarias].
4. [Ejemplos de estilo, sin autoridad factual].

SI FALTA INFORMACIÓN
- Indica exactamente qué dato falta.
- No lo estimes salvo que el encargo pida expresamente una estimación.
- Formula una pregunta concreta antes de cerrar el resultado.

CONTROL ANTES DE ENTREGAR
- Verifica [cifras, fechas, enlaces, nombres, alcance].
- Separa hechos, inferencias y propuestas.
- Indica las fuentes utilizadas cuando el encargo lo requiera.

APROBACIÓN Y ACCIONES
- Puedes preparar [borradores o análisis].
- Necesitas aprobación antes de [publicar, enviar o modificar].
- La aprobación corresponde a [persona o función].

Prueba las instrucciones antes de darlas por buenas

1. Abre un chat nuevo dentro del Proyecto.
2. Plantea un encargo pequeño al que le falte un dato crítico.
3. Comprueba que señala el hueco, consulta la fuente correcta y no inventa la respuesta.
4. Pide un resultado con el tono y el formato definidos.
5. Introduce una preferencia de formato que contradiga de forma inocua una regla del Proyecto y observa qué ocurre.
6. Registra el mensaje completo, la respuesta y el resultado: cumple, no cumple o no concluyente.
7. Si corriges una regla, cambia solo una variable y repite la misma prueba.

Esta prueba no demuestra que ChatGPT «nunca fallará». Demuestra si esta versión de las instrucciones funciona en la cuenta, superficie y condiciones que has probado.

Qué no meter en las instrucciones del Proyecto

• Contraseñas, claves o credenciales.
• Información personal innecesaria.
• El contenido completo de documentos que ya existen como fuentes.
• Un encargo temporal que solo afecta a un chat.
• Procedimientos enormes que deberían mantenerse como documento o convertirse después en una Skill.
• Reglas contradictorias sin explicar cuál tiene prioridad.
• Promesas imposibles como «nunca te equivocarás» o «cero alucinaciones».

Las instrucciones no deben intentar contener el conocimiento. Deben enseñar a utilizarlo.

Ya tienes las reglas del ámbito. Falta la materia sobre la que trabajan: en el siguiente capítulo montamos las fuentes del Proyecto.

OpenAI denomina Sources al espacio donde se añaden archivos y contexto conectado que deben estar disponibles entre los chats de un Proyecto. Un archivo que solo afecta a un encargo puede adjuntarse directamente a ese chat; una fuente que deben reutilizar varios chats pertenece al Proyecto.

Esta distinción parece pequeña, pero evita que cada documento temporal acabe formando parte del contexto estable.

Y aquí conviene desmontar una idea peligrosa:

Subir muchos archivos no crea automáticamente una buena base de conocimiento.

Crea una colección de archivos. Para que esa colección resulte útil necesita selección, limpieza, autoridad, vigencia, límites y mantenimiento.

Antes de subir: inventario documental

No empieces arrastrando PDF. Empieza con una tabla.

La columna más importante es para qué se utilizará. Un documento no es «útil» en abstracto. Puede ser autoridad para precios, evidencia para un caso, referencia de tono o simple archivo histórico. Si no defines su función, ChatGPT puede utilizarlo para algo que nunca pretendiste.

Paso 1. Elimina lo que no debería entrar

No subas:

• Versiones obsoletas sin marcar.
• Borradores que puedan confundirse con documentos aprobados.
• Duplicados en formatos distintos.
• Exportaciones enormes cuando solo necesitas una parte.
• Información confidencial ajena al propósito del Proyecto.
• Documentos que nadie se responsabiliza de mantener.
• Archivos cuyo origen no puedes explicar.

Si un documento tiene valor histórico, puedes conservarlo fuera del Proyecto. «Quiero guardarlo» y «quiero que ChatGPT lo utilice» no son la misma decisión.

Paso 2. Limpia cada fuente

Una fuente de trabajo debería poder responder:

• Qué contiene.
• Quién la aprobó.
• Desde cuándo está vigente.
• Qué sustituye, si sustituye algo.
• Para qué preguntas tiene autoridad.
• Qué partes no deben utilizarse como información actual.

Cuando el propio documento no lo deja claro, añade una portada o una nota de control antes de incorporarlo.

Ejemplo:

ESTADO: [VIGENTE / BORRADOR / SUSTITUIDO / ARCHIVADO]
PROPIETARIO: [persona o función responsable]
APROBADO: [AAAA-MM-DD]
USO: [tema para el que tiene autoridad]
SUSTITUYE A: [versión anterior o «ninguna»]
NO UTILIZAR PARA: [usos excluidos]

No hace falta decorar la documentación. Hace falta que no mienta por omisión.

Paso 3. Nombra los archivos para que una persona pueda gobernarlos

Un nombre como final_definitivo_ahora_si_3.pdf no ayuda a nadie.

Utiliza una convención sencilla:

[AREA]-[CONTENIDO]-[ESTADO]-[AAAA-MM-DD].[extensión]

Ejemplos:

VENTAS-Tarifas-VIGENTE-[AAAA-MM-DD].pdf
MARCA-Guia-de-voz-APROBADA-[AAAA-MM-DD].pdf
PRODUCTO-Referencia-tecnica-[AAAA-MM-DD].pdf

La fecha no sustituye el control de vigencia, pero ayuda a detectar anomalías. Si hay dos documentos marcados como vigentes para lo mismo, el nombre ya está avisando de que existe un problema.

Paso 4. Define qué fuente manda

La jerarquía no tiene por qué ser única para todo. Una fuente puede mandar sobre precios y otra sobre tono.

No escribas simplemente «prioriza la documentación más reciente». Lo más reciente puede ser un borrador. La autoridad debe depender del estado y del responsable, no solo de la fecha.

Paso 5. Separa verdad, estilo y ejemplo

Esta es una de las reglas más importantes de todo el playbook.

Un caso de éxito publicado puede servir para aprender estructura y tono, pero no necesariamente para obtener precios actuales. Una propuesta antigua puede mostrar cómo se presenta un servicio, pero sus condiciones pueden haber caducado. Una conversación real puede enseñar el lenguaje del cliente, pero no convertirse en política de empresa.

Etiqueta las fuentes por función:

• Canónica: contiene el dato que manda para un tema concreto.
• Operativa: explica un procedimiento vigente.
• Evidencia: demuestra qué ocurrió en un caso.
• Referencia: aporta contexto útil, pero no decide.
• Estilo: enseña voz, estructura o formato; no autoridad factual.

Esta clasificación debería aparecer en el inventario y, cuando sea necesario, dentro del propio documento.

Paso 6. Protege la información antes de compartirla

Antes de incorporar fuentes, revisa:

• Si contienen datos personales.
• Si incluyen información de clientes.
• Si muestran precios o acuerdos confidenciales.
• Si todas las personas con acceso al Proyecto necesitan consultarlas.
• Si el administrador del espacio de trabajo ha definido restricciones.
• Si existe una versión anonimizada suficiente para el trabajo.

El principio es sencillo: no añadas una información porque ChatGPT pueda utilizarla. Añádela solo si el trabajo la necesita y las personas autorizadas deben poder acceder a ella.

Paso 7. Asigna un propietario y una revisión

Una base documental sin mantenimiento envejece en silencio.

Cada fuente importante necesita:

• Una persona responsable.
• Un estado: borrador, aprobado, vigente, sustituido o archivado.
• Una fecha de revisión.
• Una regla para retirar o reemplazar la versión anterior.

No hace falta revisar cada semana una guía de tono estable. Sí hace falta revisar inmediatamente una tarifa cuando cambian los precios.

La frecuencia depende del riesgo de que el documento caduque y del daño que provocaría utilizarlo mal.

Qué hacer cuando dos fuentes se contradicen

No le pidas a ChatGPT que «use el sentido común». Dale un protocolo:

1. Identificar las dos afirmaciones incompatibles.
2. Nombrar los documentos y su estado.
3. Aplicar la fuente canónica si está definida para ese tema.
4. Si ninguna tiene autoridad explícita, no elegir en silencio.
5. Solicitar validación a la persona responsable.
6. Corregir o retirar la fuente que haya quedado obsoleta.

Resolver la respuesta puntual sin limpiar la documentación solo garantiza que la misma duda volverá a aparecer.

Prueba el inventario antes de confiar en él

Abre un chat nuevo del Proyecto y elige tres fuentes: una canónica, una de estilo y una sustituida o excluida. Pide que explique para qué puede utilizar cada una y plantea una pregunta que enfrente dos versiones. Conserva el mensaje y la respuesta completos.

La prueba cumple si identifica la función de cada fuente, aplica la que tiene autoridad y muestra la contradicción cuando no puede resolverla. Si falla, corrige el inventario, el documento o las instrucciones; no tapes el problema con una aclaración que solo vive en ese chat.

Con instrucciones y fuentes en su sitio, en el siguiente capítulo montamos el Proyecto entero y lo sometemos a una prueba de fuego.

Móntalo en pantalla

Esta es la ruta de trabajo, en orden. Los nombres exactos y las opciones pueden variar según la cuenta, el espacio de trabajo, la superficie y el despliegue. Utiliza las capturas de la cuenta real con la que prepares la guía; no fuerces una ruta que tu interfaz no muestra.

1. Abre Proyectos y selecciona Nuevo proyecto.
2. Asigna un nombre que describa su perímetro; utiliza icono o color solo si ayudan a reconocerlo.
3. Abre los detalles del Proyecto y entra en Configuración del proyecto. Pega en Instrucciones la versión controlada que has preparado.
4. Revisa Memoria y Acceso a la biblioteca si aparecen en esa cuenta y registra qué opciones están disponibles.
5. Abre la pestaña Fuentes y utiliza Añadir fuentes o Añadir archivos para incorporar únicamente el núcleo mínimo que ha pasado el inventario.
6. Vuelve a Chats y abre un chat nuevo dentro del Proyecto para ejecutar las siete pruebas de este capítulo.
7. Utiliza Compartir solo si va a trabajar más de una persona.
8. Asigna el acceso mínimo que permita el trabajo utilizando las opciones que muestre la interfaz real.
9. Compruébalo con una segunda cuenta autorizada: verifica qué puede ver, utilizar y modificar.

Antes de compartir: qué podrán ver y hacer

No publiques una tabla universal de permisos basada en otra cuenta o en una captura antigua. La fuente de verdad para este procedimiento es la combinación de documentación oficial, políticas del espacio de trabajo y opciones que aparecen en la cuenta real.

• No deduzcas el alcance por el nombre del permiso: comprueba las acciones reales.
• No pruebes con información sensible: utiliza archivos y acciones de ensayo.
• No confundas acceso al Proyecto con acceso a una fuente conectada: valida ambas capas.
• No documentes una opción que no aparece: anota cuenta, espacio de trabajo, superficie y fecha.
• Asigna una persona responsable: alguien debe revisar miembros, fuentes y configuración.

El sentido común detrás de cada clic

1. Define el perímetro

Completa una frase:

Si no puedes escribirla con claridad, todavía no sabes qué Proyecto estás creando.

2. Decide quién necesita acceso

Revisa función, responsabilidad y sensibilidad. No concedas acceso general «por si acaso».

3. Redacta las instrucciones

Utiliza la plantilla anterior. Empieza con lo mínimo que sea estable y comprobable. Añade reglas cuando un fallo real demuestre que faltan.

4. Prepara el inventario de fuentes

No subas nada hasta decidir su uso, autoridad, estado, propietario y sensibilidad.

5. Añade solo el núcleo fiable

Empieza por pocas fuentes claras:

• La guía de trabajo del área.
• La fuente canónica para hechos sensibles.
• El procedimiento vigente.
• Dos o tres ejemplos aprobados de estilo, si son necesarios.

La calidad del núcleo importa más que el volumen.

6. Abre un chat de validación

No utilices todavía un encargo crítico. Primero prueba si el Proyecto entiende su terreno.

7. Corrige el sistema, no solo la respuesta

Si el fallo nace de una instrucción ambigua, corrige la instrucción. Si nace de dos documentos contradictorios, limpia las fuentes. Si el dato solo era necesario para esa tarea, muévelo al chat.

Prueba de fuego de la capa de proyecto

Abre un chat nuevo dentro del Proyecto y ejecuta estas pruebas con las mismas condiciones. Registra: fecha, cuenta y espacio de trabajo, aplicación o web, versión de instrucciones, fuentes instaladas y modelo si la interfaz lo muestra. Guarda el mensaje y la respuesta completos; una captura recortada sirve para publicar, no para auditar.

Prueba 1. Alcance

Pregunta:

¿Para qué trabajos debe utilizarse este Proyecto y qué trabajos quedan fuera?

Debe describir la frontera sin inventar funciones nuevas.

Prueba 2. Fuentes

Pregunta:

Enumera las fuentes disponibles, para qué sirve cada una y cuál tiene autoridad sobre precios, procesos, producto y estilo.

Si no puede distinguirlo, la documentación o las instrucciones todavía no están preparadas.

Prueba 3. Información ausente

Solicita un resultado que necesite un dato que no existe en las fuentes. Debe señalar el hueco y preguntar, no completarlo con una cifra plausible.

Prueba 4. Contradicción

Presenta en el chat un dato que contradiga una fuente canónica. Debe detectar la diferencia, explicar qué fuente está aplicando y pedir confirmación si el encargo pretende sustituirla.

Prueba 5. Límite de las fuentes

Pregunta por un dato ficticio que sabes que no existe en las fuentes del Proyecto, sin utilizar el nombre ni la información real de otro cliente. Debe indicar que no puede sostenerlo con las fuentes disponibles; no debe atribuir al Proyecto una cifra o un caso inventados.

Prueba 6. Voz

Solicita un texto breve y compáralo con dos ejemplos aprobados. Revisa vocabulario, ritmo, nivel técnico y estructura. No evalúes solamente si «suena bien».

Prueba 7. Trazabilidad

Pide:

Separa los hechos confirmados, las inferencias y las propuestas. Indica qué fuente sostiene cada hecho relevante.

Esta prueba no garantiza que todo sea correcto, pero muestra si el Proyecto puede explicar de dónde está sacando el trabajo. Clasifica cada prueba como cumple, no cumple o no concluyente. Si cambias una regla o una fuente, repite la misma prueba y conserva ambas versiones.

Cuándo está lista esta capa

La capa de proyecto puede darse por preparada cuando:

• Su finalidad cabe en una frase.
• Sus usuarios y límites están definidos.
• Las instrucciones describen reglas estables, no encargos puntuales.
• Cada fuente tiene una función, un estado y un propietario.
• Existe un orden de autoridad por tipo de información.
• Los documentos obsoletos o contradictorios se han retirado o marcado.
• En las pruebas registradas, señala los huecos críticos en lugar de completarlos sin fuente.
• Un chat nuevo puede utilizar el contexto común sin que tengas que volver a explicarlo entero.

Eso sí es configurar un Proyecto.

Crear una carpeta, subir quince PDF y escribir «actúa como experto en nuestra empresa» es otra cosa. Más rápida, sí. También bastante más cara cuando el PDF equivocado acaba dentro de una propuesta real.

El Proyecto ya entiende su terreno. En el último capítulo de esta entrega trabajamos dentro de él: chats enfocados, un resultado por conversación.