La mayoría de los malos resultados con IA no vienen del modelo: vienen de pedirle trabajo sin darle contexto. Un Project resuelve eso. Es el contenedor donde guardas los documentos que explican cómo se hace bien el trabajo y las instrucciones que fijan el criterio, para no repetirlos en cada conversación.
Esta guía es el manual completo: qué es y qué no, cuándo usarlo frente a una conversación suelta, qué documentos entran, cómo nombrarlos, cómo escribir las instrucciones con plantilla copiable, cómo versionar el conocimiento, seis estructuras por área, higiene mensual, límites reales y cuándo dar el salto a la API o a los agentes. Todo lo citado procede de documentación oficial consultada en septiembre de 2026.
Respuesta corta: Un Project de Claude es un espacio de trabajo con historial propio, una base de conocimiento de documentos y unas instrucciones fijas que se aplican a todas las conversaciones dentro de él. Sirve para el trabajo que se repite con el mismo criterio y el mismo material. Una conversación suelta sirve para lo puntual. La diferencia práctica: en un Project no tienes que volver a explicar quién eres, qué vendes y cómo quieres las cosas.
- ¿Qué es un Project en Claude y qué no es?
- ¿Cuándo usar un Project y cuándo basta una conversación suelta?
- ¿Qué documentos van a la base de conocimiento y cuáles no?
- ¿Cómo se ordenan y se nombran los documentos para que funcionen?
- Instrucciones del proyecto: la plantilla completa, lista para copiar
- ¿Cómo se escriben instrucciones que Claude siga de verdad?
- Control de versiones del conocimiento: que nadie use la lista de precios vieja
- Seis estructuras de proyecto por área, listas para copiar
- Compartir, permisos y visibilidad: qué cambia en Team y Enterprise
- Higiene: ¿qué hay que revisar en la base de conocimiento cada mes?
- Límites reales y errores frecuentes con Projects
- ¿Cuándo un Project se queda corto y toca pasar a skills, API o agentes?
- Trucos que no vienen en el manual
- Qué hacer esta semana con tu base de conocimiento
¿Qué es un Project en Claude y qué no es?
Un Project es un espacio con tres piezas: su propio historial de conversaciones, una base de conocimiento con los documentos que subes y unas instrucciones de proyecto que se aplican a todo lo que ocurre dentro. No es una carpeta de archivos, no es un chatbot entrenado con tus datos y no es una base de datos: es contexto persistente que evita repetir lo mismo veinte veces.
La documentación oficial de Projects lo define como un espacio con historial y base de conocimiento propios. Tres consecuencias prácticas que conviene entender antes de montar nada:
- Los documentos persisten entre conversaciones. En un chat normal, lo que subes sirve solo para esa conversación; en un Project, el material está disponible en todas las del proyecto.
- Las instrucciones del proyecto son la memoria de criterio. Ahí escribes quién eres, a quién te diriges, qué tono usas, qué nunca hay que hacer y cómo quieres las salidas. Es la diferencia entre un becario que ya lleva seis meses y uno que llega hoy.
- En planes de pago funciona con recuperación de información. Cuando la base de conocimiento se acerca al límite de contexto, Anthropic documenta el uso de RAG para Projects, que amplía la capacidad hasta diez veces. Cabe más de lo que crees, pero no cabe todo tu Drive y la calidad baja con ruido.
Y ahora lo que no es, porque aquí es donde se genera la frustración:
| Lo que la gente espera | Lo que realmente pasa |
|---|---|
| «Le subo todo y ya sabe todo de mi empresa» | Cuanto más ruido subas, peor responde. La base se cura, no se vacía dentro |
| «Aprende de mis correcciones y se queda así» | Lo que no escribas en las instrucciones o en un documento, no queda |
| «Consulta mi inventario en tiempo real» | Eso necesita un conector o una integración, no un documento subido |
| «Es un entrenamiento del modelo con mis datos» | No hay entrenamiento: es contexto que se recupera al responder |
| «Sustituye al CRM o al gestor documental» | Es una capa de trabajo encima de ellos, no un reemplazo |
En la guía de implementación por fases, los Projects son la fase 1: la primera base de conocimiento del piloto.
¿Cuándo usar un Project y cuándo basta una conversación suelta?
Usa un Project cuando la tarea se repite, cuando el criterio de calidad es estable y cuando hace falta material de referencia. Usa una conversación suelta para lo puntual, lo exploratorio y lo que no vas a repetir. La regla rápida: si vas a explicar el contexto por tercera vez, ya deberías tener un Project.
Anthropic no publica una comparativa con ese título, así que la regla se construye desde lo documentado: los Projects tienen base de conocimiento e instrucciones persistentes y los chats normales no retienen los documentos. De ahí sale esta tabla.
| Situación | Conversación suelta | Project |
|---|---|---|
| Redactar un correo puntual | Sí | Innecesario |
| Entender un documento que no volverás a ver | Sí | No |
| Propuestas comerciales con plantilla y catálogo | No | Sí |
| Respuestas de soporte con tono y políticas propias | No | Sí |
| Análisis mensual con el mismo formato de reporte | No | Sí |
| Trabajo que hacen varias personas con el mismo criterio | No | Sí, y compartido |
| Material confidencial que debe tener permisos claros | No | Sí, con visibilidad controlada |
Hay un tercer caso que confunde: la memoria y la búsqueda de chats, que recupera contexto de conversaciones anteriores (documentación oficial). Es una comodidad personal, no una base de empresa: no tiene curaduría, no se comparte con criterio y nadie la mantiene.
Regla de las tres veces. La primera vez que haces una tarea, conversación suelta. La segunda, guarda el prompt que funcionó. La tercera, crea el Project con ese prompt convertido en instrucciones y con los dos o tres documentos que tuviste que pegar. Casi todos los Projects útiles nacen de ese tercer intento, no de una planificación previa.
¿Qué documentos van a la base de conocimiento y cuáles no?
Entra lo que explica cómo se hace bien el trabajo: plantillas aprobadas, políticas, catálogos vigentes, ejemplos reales de salidas buenas, glosario interno y preguntas frecuentes de clientes. No entra lo que cambia a diario, lo que es puro dato tabular masivo, lo duplicado, lo obsoleto ni lo que no puedes subir por política interna.
La base es una biblioteca curada, no un disco duro. El criterio de admisión es una pregunta: ¿esto ayuda a decidir cómo hacer la tarea? Si la respuesta es «no, pero por si acaso», no entra.
| Sí entra | Por qué | No entra | Por qué no |
|---|---|---|---|
| Plantilla aprobada de propuesta | Fija estructura y tono de la salida | Veinte propuestas antiguas sin marcar | El modelo no sabe cuál era buena |
| Catálogo con precios vigentes y fecha | Evita inventar precios | Lista de precios de hace dos años | Contradice a la vigente y genera errores |
| Política de descuentos y condiciones | Es criterio puro | Hilos de correo internos completos | Ruido, contradicciones y datos personales |
| Dos o tres ejemplos marcados como «salida buena» | Enseña el estándar mejor que cualquier descripción | Base de datos de 40.000 filas | Eso es analítica, no contexto |
| Preguntas frecuentes reales de clientes | Lenguaje real del mercado | Manual de 300 páginas sin índice | Mejor extraer las 10 páginas que importan |
Tres reglas de curaduría que ahorran meses
- Un documento, un propósito. Nada de un archivo «varios» con política de descuentos, plantilla y datos de contacto. Cuando se contradigan entre sí, no sabrás dónde corregir.
- Todo documento lleva fecha de vigencia dentro. La primera línea del archivo dice desde cuándo es válido y quién lo mantiene. Sin eso, en seis meses nadie sabrá cuál manda.
- Prefiere el extracto al archivo completo. Diez páginas relevantes valen más que un manual de trescientas: el modelo recupera mejor y tú detectas antes lo que falta.
Sobre formatos, la documentación de subida de archivos detalla qué admite. Práctico: texto plano o documentos con texto seleccionable. Un PDF escaneado sin capa de texto es una imagen, y una imagen de un catálogo es un mal catálogo.
Plantilla copiable — encabezado obligatorio de cada documento.
DOCUMENTO: [nombre claro de qué es]
ÁREA: [ventas / finanzas / soporte / operaciones]
VIGENTE DESDE: [fecha] · REVISAR EN: [fecha]
MANTIENE: [puesto, no nombre de persona]
QUÉ CONTIENE: [una frase]
QUÉ NO CONTIENE: [una frase, para evitar que se use mal]
SUSTITUYE A: [documento anterior, si aplica]
Hablemos de tu caso concreto
Diagnóstico gratuito de 30 minutos. Uniamos es una agencia remota de automatización con IA (Austin y Ciudad de México) que trabaja por videollamada y WhatsApp.
¿Cómo se ordenan y se nombran los documentos para que funcionen?
Con una convención de nombres de tres partes —área, tipo de documento y fecha de vigencia— y con un documento índice al principio de la base que explique qué hay y para qué sirve cada cosa. El orden importa menos que la claridad del nombre: el nombre del archivo es la primera pista de cuándo usarlo.
La convención que mejor aguanta el paso del tiempo es esta:
AREA_TIPO_TEMA_AAAA-MM.extensión
- VTA_PLANTILLA_propuesta-estandar_2026-09.docx
- VTA_POLITICA_descuentos-y-plazos_2026-07.md
- VTA_CATALOGO_precios-lista-publica_2026-09.xlsx
- SOP_FAQ_preguntas-frecuentes-clientes_2026-08.md
- ALL_GLOSARIO_terminos-internos_2026-06.md
- VTA_EJEMPLO_propuesta-buena-industria_2026-05.docx
No es burocracia: el nombre ya dice si el documento es criterio, dato o ejemplo; la fecha revela lo caducado sin abrir nada; y cuando pidas «usa la política de descuentos vigente», sabrá cuál es.
El documento índice: el archivo más importante de todos
El primer documento de cada base debe ser un índice que explique la biblioteca. Es lo que evita que el modelo —y las personas nuevas— usen el archivo equivocado.
Plantilla copiable — 00_INDICE_base-conocimiento.md
Para qué sirve este proyecto: [una frase]
Quién lo mantiene: [puesto] · Revisión mensual: [día fijo]
Documentos y cuándo usar cada uno:
· VTA_PLANTILLA_propuesta-estandar — estructura obligatoria de toda propuesta. Úsalo siempre.
· VTA_POLITICA_descuentos — límites de descuento y plazos. Consúltalo antes de ofrecer condiciones.
· VTA_CATALOGO_precios — precios vigentes. Es la única fuente de precios; si no está aquí, se pregunta.
· VTA_EJEMPLO_propuesta-buena — ejemplo de salida aprobada. Imita su nivel de detalle, no su contenido.
Qué NO hay aquí: datos de clientes individuales, contratos firmados, información de costes internos.
Si falta algo: pídelo a [puesto] y no lo inventes.
Ese último renglón parece de adorno y no lo es: forma parte de las instrucciones implícitas y reduce mucho la probabilidad de que rellene huecos por su cuenta.
Instrucciones del proyecto: la plantilla completa, lista para copiar
Las instrucciones del proyecto son un texto corto que define contexto, audiencia, criterios de calidad, prohibiciones y formato de salida. Bien escritas, ahorran una explicación en cada conversación. Mal escritas —vagas o contradictorias— generan resultados peores que no tener ninguna.
Esta plantilla cubre los siete bloques que importan. Cópiala, rellénala y borra lo que no aplique. Debe caber en una pantalla: si ocupa tres, nadie la mantiene y empieza a contradecirse sola.
Plantilla copiable — instrucciones de proyecto (7 bloques).
1. QUIÉN SOY. Trabajo en una [tipo de empresa] de [sector] en [México / Paraguay], de [tamaño] personas. Vendemos [qué] a [a quién]. Nuestro diferencial real es [uno, concreto].
2. QUIÉN LEE LO QUE PRODUCES. Normalmente [perfil del destinatario: comprador técnico, dueño de pyme, gerente de compras]. Su nivel de conocimiento sobre nosotros es [bajo/medio/alto] y le importa sobre todo [precio / plazo / soporte / cumplimiento].
3. QUÉ HACES AQUÍ. En este proyecto trabajamos [tarea concreta: propuestas comerciales / respuestas a soporte / análisis de cierre mensual]. Otras tareas van en otro proyecto.
4. CÓMO DEBE SER UNA BUENA SALIDA. Extensión: [rango]. Tono: [descripción en tres palabras]. Estructura: [secciones fijas]. Siempre incluye [elementos obligatorios]. El estándar de calidad está en el documento VTA_EJEMPLO_propuesta-buena.
5. QUÉ NO HACER NUNCA. No inventes precios, plazos ni referencias: si no están en la base de conocimiento, dilo y pregunta. No uses [palabras vetadas]. No prometas [compromisos que no podemos cumplir]. No incluyas datos personales de clientes en los ejemplos.
6. QUÉ HACER CUANDO FALTE INFORMACIÓN. Antes de redactar, dime qué te falta y haz como máximo tres preguntas. Si aun así falta un dato, déjalo marcado como [PENDIENTE: qué falta] en vez de rellenarlo.
7. FORMATO DE ENTREGA. Devuélvelo como [texto listo para pegar / tabla / documento]. Al final, añade una línea con las fuentes internas que usaste y con lo que no pudiste verificar.
El bloque 6 es el que más cambia los resultados y el que casi nadie escribe. Obligar a preguntar antes de redactar convierte al modelo en alguien que pide el brief en vez de inventarlo, y elimina de golpe buena parte de los datos fabricados.
¿Cómo se escriben instrucciones que Claude siga de verdad?
Con cuatro técnicas documentadas por Anthropic: explicar el porqué de cada regla, dar de tres a cinco ejemplos diversos, separar las partes con etiquetas y poner el material largo antes de la pregunta. La prueba de calidad también es oficial: enseña tus instrucciones a un compañero con poco contexto; si se confunde, el modelo también.
Las buenas prácticas oficiales de prompting recomiendan pensar en el modelo como «un empleado brillante pero nuevo, que no conoce tus normas ni tus flujos». Eso se traduce en cuatro movimientos.
- Explica el motivo, no solo la regla. El ejemplo de la propia documentación es claro: en vez de «nunca uses puntos suspensivos», escribir «esto lo leerá un motor de voz que no sabe pronunciar los puntos suspensivos, así que no los uses». Versión comercial: en vez de «no menciones plazos», escribe «no menciones plazos porque producción los confirma caso por caso y un plazo equivocado nos cuesta el pedido».
- Da de tres a cinco ejemplos. La guía oficial recomienda ese número, con ejemplos diversos que cubran casos límite: uno solo produce imitación literal, cinco producen criterio. En un Project viven como documentos marcados «salida buena» y se citan desde las instrucciones.
- Separa las partes con etiquetas. Envolver contexto, instrucciones y datos en etiquetas tipo <contexto>, <instrucciones> y <datos> evita que confunda un ejemplo con una orden. Sirve igual dentro de las instrucciones del proyecto que en cada conversación.
- Material largo arriba, pregunta al final. Para contextos largos, la documentación indica que poner las consultas al final puede mejorar la calidad de la respuesta hasta un 30 % en sus pruebas. Si pegas un pliego de 60 páginas, la instrucción va después.
Los cinco vicios que arruinan unas instrucciones
- Adjetivos sin criterio. «Profesional», «cercano» y «potente» no significan nada. Sustitúyelos por reglas verificables: «frases de menos de 25 palabras», «nada de superlativos», «tratamiento de tú».
- Contradicciones acumuladas. Al añadir reglas durante meses acabas con «sé breve» y «desarrolla cada punto». Revisa el texto entero, no solo el párrafo nuevo.
- Instrucciones que repiten el documento. Si la política ya está en la base, apunta al documento en vez de copiarla: dos copias garantizan dos versiones.
- Prohibiciones sin alternativa. «No inventes datos» funciona mucho mejor como «si no está en la base, escribe [PENDIENTE] y dime qué falta».
- Un proyecto para todo. Unas instrucciones que cubren ventas, soporte y finanzas terminan siendo genéricas: mejor tres proyectos afilados.
El equivalente aplicado al día a día comercial está en prompts de Claude para equipos comerciales.
Control de versiones del conocimiento: que nadie use la lista de precios vieja
Se controla con tres mecanismos simples: fecha de vigencia dentro de cada documento, un único documento vigente por tema —el anterior se borra de la base, no se deja «por si acaso»— y un registro de cambios en el índice donde se anota qué se cambió, cuándo y quién lo pidió.
El fallo más caro no es que falte información: es que sobre información caducada. Si conviven la lista de precios de julio y la de septiembre, la respuesta será plausible y estará mal, y nadie lo notará hasta que el cliente reclame.
| Mecanismo | Cómo se hace | Qué evita |
|---|---|---|
| Fecha dentro del documento | Primera línea: vigente desde, revisar en, quién mantiene | Usar un criterio derogado |
| Un solo vigente por tema | Al subir la nueva versión, se elimina la anterior de la base | Contradicciones silenciosas |
| Registro de cambios en el índice | Tres columnas: fecha, qué cambió, quién lo pidió | Discusiones sobre «quién cambió esto» |
| Archivo histórico fuera del proyecto | Carpeta en tu gestor documental, no en la base | Perder el histórico sin ensuciar el contexto |
Plantilla copiable — registro de cambios del proyecto.
| Fecha | Documento | Qué cambió | Quién lo pidió (puesto) | Versión anterior archivada en |
| 2026-09-15 | VTA_CATALOGO_precios | Subida de 4 % en línea industrial | Dirección comercial | Drive/archivo/2026 |
| 2026-09-02 | VTA_POLITICA_descuentos | Nuevo tope de 12 % sin autorización | Dirección general | Drive/archivo/2026 |
Regla: ninguna entrada nueva en la base sin línea en este registro.
Advertencia para Enterprise: los registros de auditoría recogen eventos de creación, borrado y cambio de visibilidad de proyectos, pero no el contenido. La trazabilidad de tu conocimiento la aporta tu registro de cambios, no la plataforma.
Seis estructuras de proyecto por área, listas para copiar
Un proyecto por área y por tarea, no uno por empresa. Estas seis estructuras —ventas, marketing, soporte, finanzas, operaciones y recursos humanos— cubren el 90 % de las necesidades de una pyme y se pueden montar en una tarde con documentos que ya tienes.
1. Ventas: propuestas y seguimiento
Base: plantilla de propuesta aprobada, catálogo con precios vigentes, política de descuentos y plazos, dos ejemplos de propuesta buena, preguntas frecuentes de compradores, ficha técnica. Instrucciones: perfil del comprador tipo, tono, prohibición de inventar precios y plazos, formato listo para enviar. Permisos: lectura para todo el equipo comercial.
2. Marketing: contenidos y campañas
Base: manual de marca o, si no existe, un documento de tono con diez frases correctas y diez incorrectas; posicionamiento; glosario de producto; tres contenidos publicados marcados como estándar. Instrucciones: audiencias, palabras vetadas, longitudes por formato y obligación de proponer tres titulares antes de redactar.
3. Atención al cliente y soporte
Base: catálogo de respuestas aprobadas, políticas de garantía y devolución, escalamiento (qué se resuelve y qué se pasa a una persona), preguntas frecuentes reales con el lenguaje del cliente. Instrucciones: tono, longitud máxima, regla de no comprometer plazos y obligación de marcar los casos que deben escalar. Cuando el volumen crece, este proyecto es el paso previo natural a un agente: ver chatbots y agentes de IA.
4. Finanzas y administración
Base: catálogo de cuentas y centros de coste, política de gastos, calendario de obligaciones, formato del reporte mensual, definición de cada indicador. Instrucciones: qué se analiza y qué no se decide aquí, y obligación de citar la cifra de origen y marcar los supuestos. Ver finanzas.
5. Operaciones y logística
Base: procedimientos vigentes, tiempos estándar, condiciones de entrega por zona, checklist de calidad e incidencias típicas con su resolución. Instrucciones: prioridad de seguridad sobre velocidad y obligación de señalar cuando un dato depende de un sistema en vivo.
6. Recursos humanos
Base: descripciones de puesto, manual de bienvenida, política interna de uso de IA, preguntas frecuentes del personal. Instrucciones: tono institucional, prohibición absoluta de incluir datos personales de empleados y aviso de que ninguna decisión laboral se toma aquí. La política que debe vivir ahí está en política de uso de IA y gobernanza.
| Proyecto | Documentos mínimos | Señal de que está bien montado |
|---|---|---|
| Ventas | 6 | Una propuesta sale en 15 minutos y pasa revisión a la primera |
| Marketing | 5 | Dos personas distintas producen el mismo tono |
| Soporte | 4 | Las respuestas no prometen nada fuera de política |
| Finanzas y operaciones | 5 | Nadie pide al proyecto datos que solo están en el ERP |
| RR. HH. | 5 | Cero datos personales en las conversaciones |
El catálogo de qué pedir a cada proyecto, tarea por tarea, está en casos de uso por área en pymes.
Compartir, permisos y visibilidad: qué cambia en Team y Enterprise
En los planes individuales los proyectos son personales. En Team y Enterprise se pueden compartir con personas concretas, en modo ver o editar, con un grupo o con toda la organización. Esa elección es una decisión de gobernanza, no de comodidad: define quién puede cambiar el criterio de trabajo de un área entera.
La documentación de visibilidad y compartición describe los modos disponibles. La traducción a política interna es esta:
| Modo | Cuándo usarlo | Riesgo si te equivocas |
|---|---|---|
| Personal | Borradores y experimentos individuales | El conocimiento muere con la persona |
| Compartido, solo ver | Proyectos de área con criterio estable | Ninguno relevante; es el modo por defecto recomendado |
| Compartido, con edición | Dos o tres responsables que mantienen la base | Alguien sube un documento obsoleto y nadie se entera |
| Toda la organización | Glosario, manual de marca, política de uso | Exposición de material que no todos deberían ver |
Tres reglas que evitan los líos más comunes:
- Edición para dos, lectura para todos. Un proyecto con quince editores acaba con dos plantillas distintas y tres políticas de descuento.
- El dueño es un puesto, no una persona. Escribe en el índice «mantiene: jefatura comercial». Cuando esa persona cambie de rol, el proyecto no se queda huérfano.
- La retención se decide arriba. En Enterprise se pueden fijar períodos propios de retención para chats y proyectos, con mínimo de 30 días, frente al comportamiento por defecto de conservación indefinida: controles de retención personalizada. Decidirlo antes de montar diez proyectos es más barato que después.
Team y Enterprise incluyen además una búsqueda empresarial para conocimiento unificado. No sustituye a los proyectos: resuelve el «¿dónde estaba ese documento?», no el «¿cómo se hace bien esta tarea?».
Higiene: ¿qué hay que revisar en la base de conocimiento cada mes?
Media hora al mes, día fijo, con cinco comprobaciones: documentos caducados, precios y políticas cambiados, documentos que nadie usó, preguntas que el proyecto no supo responder y instrucciones contradictorias. Una base sin mantenimiento se degrada en unos tres meses y empieza a dar respuestas plausibles y equivocadas.
- Caducidad. Abre el índice y revisa la columna «revisar en». Todo lo vencido se actualiza o se saca de la base ese mismo día.
- Cambios del mes. ¿Cambió algún precio, plazo, condición o responsable? Si cambió en la realidad y no en la base, la base está mintiendo.
- Documentos muertos. Si un documento no se usó ni se citó en tres meses, o sobra o nadie sabe que existe. Las dos causas se arreglan en el índice.
- Huecos detectados. Recoge las tres preguntas que el proyecto no pudo responder por falta de material. Esa lista es tu plan de contenidos interno.
- Instrucciones. Léelas enteras en voz alta. Si algo se contradice o ya no aplica, se corrige en ese momento, no «cuando haya tiempo».
Plantilla copiable — acta de higiene mensual (10 líneas).
Proyecto: ___ · Fecha: ___ · Responsable (puesto): ___
1. Documentos caducados encontrados: ___ · Actualizados: ___ · Retirados: ___
2. Cambios de negocio no reflejados: ___
3. Documentos sin uso en 3 meses: ___
4. Preguntas sin respuesta detectadas este mes: ___
5. Contradicciones en instrucciones: ___
6. Altas nuevas en la base: ___
7. Personas con permiso de edición: ___ (¿siguen siendo las correctas?)
8. Incidencias reportadas por el equipo: ___
9. Próxima revisión: ___
Señal barata de que la higiene falla: el equipo empieza a pegar documentos a mano en vez de confiar en la base. Cuando veas eso, revisa la base: tienen razón.
Hablemos de tu caso concreto
Diagnóstico gratuito de 30 minutos. Uniamos es una agencia remota de automatización con IA (Austin y Ciudad de México) que trabaja por videollamada y WhatsApp.
Límites reales y errores frecuentes con Projects
Los límites que importan: en el plan gratuito hay un máximo de cinco proyectos; la base de conocimiento no es infinita, aunque en planes de pago la recuperación de información amplía la capacidad hasta diez veces; y nada de lo que hay dentro se actualiza solo. Los errores frecuentes son de curaduría, no de tecnología.
El límite de cinco proyectos en el plan gratuito aparece en la página de precios —a septiembre de 2026, confirma en su web—. En planes de pago, la recuperación de información amplía la capacidad hasta diez veces al acercarse al límite de contexto. Eso no significa «sube lo que quieras»: el cuello de botella deja de ser el tamaño y pasa a ser la calidad.
| Error frecuente | Cómo se manifiesta | Corrección |
|---|---|---|
| Subir carpetas enteras | Respuestas genéricas o contradictorias | Curar a diez o quince documentos con propósito claro |
| Dejar versiones antiguas «por si acaso» | Precios o políticas mezclados | Un vigente por tema; el resto, fuera |
| Instrucciones de tres páginas | Ignora parte de las reglas | Una pantalla, reglas verificables |
| Un proyecto para toda la empresa | Nada se hace especialmente bien | Un proyecto por área y tarea |
| Esperar datos en vivo | «No sabe mi inventario» | Conector o integración, no documento |
| Nadie lo mantiene | Degradación silenciosa en tres meses | Dueño por puesto y revisión mensual |
| Datos personales sin criterio | Riesgo de cumplimiento | Clasificación previa de qué puede entrar |
Sobre cumplimiento, sin ánimo de asesoría legal: en México rige desde marzo de 2025 la Ley Federal de Protección de Datos Personales en Posesión de los Particulares, con la autoridad en la Secretaría Anticorrupción y Buen Gobierno; en Paraguay, la Ley 7593/2025, con 24 meses de adecuación. Una base con datos personales dentro es un tratamiento como cualquier otro: base legal, finalidad declarada y control de accesos. Detalle en la guía de implementación.
¿Cuándo un Project se queda corto y toca pasar a skills, API o agentes?
Cuando la misma tarea se repite cientos de veces al mes, cuando hace falta consultar sistemas en vivo o cuando el proceso debe ejecutarse sin que una persona lo inicie. Mientras el volumen sea moderado y el criterio cambie a menudo, el Project sigue siendo la opción más barata y más fácil de mantener.
Hay tres escalones por encima del Project y conviene subirlos en orden.
Escalón 1: skills
Las skills son «carpetas de instrucciones, scripts y recursos» que Claude carga cuando hacen falta. Se escriben en Markdown, están en todos los planes y requieren la ejecución de código activada; en Team y Enterprise los propietarios pueden aprovisionarlas a toda la organización, y Enterprise añade análisis frente a contenido malicioso. Caso típico: un procedimiento de pasos fijos copiado hoy en cinco proyectos. Guía: cómo crear skills personalizadas.
Escalón 2: conectores
Si lo que falta es dato en vivo —inventario, estado de pedido, ficha del cliente—, no se arregla subiendo documentos, sino con un conector a tu almacenamiento, correo o CRM, o con un conector propio mediante MCP remoto contra tus sistemas.
Escalón 3: API y agentes
Con volumen alto, entrada estructurada y criterio estable, conviene pasar a integración por API o a un agente. Ahí cambian el coste, las pruebas necesarias y el perfil de quien lo mantiene: ver integraciones y APIs y automatización de procesos.
| Volumen mensual | Criterio | Solución |
|---|---|---|
| Menos de 20 repeticiones | Cambiante | Conversación suelta con buen prompt |
| 20 a 200 | Estable | Project compartido |
| Más de 200, pasos fijos | Muy estable | Skill sobre el Project |
| Cualquiera, con dato en vivo | — | Conector o MCP |
| Cientos o miles, entrada estructurada | Estable y medible | API o agente |
Para equipos técnicos: en Claude Code, el archivo CLAUDE.md de la raíz del repositorio cumple el papel de las instrucciones de proyecto y se lee al inicio de cada sesión, según la documentación de memoria de Claude Code. Misma idea, distinto envase.
Trucos que no vienen en el manual
Los atajos que marcan la diferencia entre un Project decorativo y uno que el equipo usa a diario.
- Nombra el proyecto por la tarea, no por el área. «Propuestas comerciales industria» funciona; «Ventas» acaba siendo un cajón de sastre.
- Empieza por el ejemplo bueno, no por las reglas. Sube primero dos salidas aprobadas y marca en el índice que son el estándar. Un ejemplo real enseña más que dos párrafos de instrucciones.
- Escribe las instrucciones en primera persona del plural: «nosotros vendemos…», «nuestros clientes suelen…». El texto queda más natural y el resultado también.
- Añade un documento de «cómo hablamos». Diez frases correctas y diez incorrectas, en columnas. Resuelve el problema del tono mejor que cualquier adjetivo.
- Pide siempre el plan antes del entregable. «Antes de redactar, dime tu enfoque en cinco líneas y qué te falta.» Treinta segundos que evitan descartar tres páginas.
- Obliga a citar de dónde salió cada dato. Añade a las instrucciones: «al final, lista qué documentos de la base usaste y qué afirmaciones no pudiste verificar». Convierte la revisión en un vistazo.
- Guarda dentro del proyecto las conversaciones que salieron bien. Son el mejor material de formación para quien entre nuevo.
- Un documento «preguntas que no supimos responder», alimentado cada mes en la higiene: es el plan de mejora de la base.
- Fecha de caducidad en la primera línea, no en el pie. Lo que está al principio pesa más y lo leen las personas al abrir.
- Duplica el proyecto antes de reformarlo. Para cambiar instrucciones a fondo, copia y prueba una semana. Cambiar en caliente el proyecto que usa todo el equipo es la forma más rápida de perder su confianza.
- Revisa cada trimestre quién tiene permiso de edición y prohíbe el proyecto «pruebas»: todo el mundo acaba trabajando en él y nadie lo mantiene.
Plantilla copiable — primer mensaje al entrar a un Project nuevo.
Vas a ayudarme con [tarea]. Antes de trabajar:
1. Lee el documento 00_INDICE y dime en tres líneas qué material tienes disponible.
2. Dime qué documentos te faltarían para hacer esta tarea bien.
3. Hazme como máximo tres preguntas sobre este caso concreto.
No empieces a redactar hasta que responda.
Qué hacer esta semana con tu base de conocimiento
Crea un solo proyecto, el de la tarea que más repite tu equipo. Reúne entre cinco y ocho documentos, escribe el índice y las instrucciones con las plantillas de este artículo, pruébalo tú tres veces, ajústalo y solo entonces compártelo. Un proyecto que funciona convence más que diez a medio montar.
- Elige la tarea más repetida de la semana, que alguien pueda verificar en cinco minutos.
- Reúne de cinco a ocho documentos que expliquen cómo se hace bien. Si tienes más de quince, sobran.
- Pon a cada uno el encabezado de vigencia y responsable, y renómbralos con la convención de área, tipo, tema y fecha.
- Escribe el índice con la plantilla: qué hay, cuándo usar cada cosa y qué no hay.
- Escribe las instrucciones con los siete bloques, en una sola pantalla.
- Pruébalo tú tres veces con casos reales de esta semana y corrige lo que falle. No compartas antes de esto.
- Compártelo en modo lectura con el equipo y fija el día de la revisión mensual en el calendario.
Con dos o tres proyectos funcionando, el paso siguiente es formar al equipo —programa de formación en ocho semanas— y medir si cambian los tiempos de trabajo, con el método de medición de adopción y retorno.
Preguntas frecuentes
¿Cuántos documentos debe tener una base de conocimiento?
Entre cinco y quince para un proyecto de tarea concreta. Menos de cinco suele indicar que el criterio sigue en la cabeza de alguien; más de veinte, que estás subiendo material por si acaso. El límite real no es el tamaño: es la contradicción. Dos documentos que dicen cosas distintas hacen más daño que diez que faltan.
¿Puedo subir toda la carpeta de mi Drive al proyecto?
Puedes, pero empeorará los resultados: cada documento irrelevante compite con los relevantes. Si necesitas buscar dentro de todo tu almacenamiento, eso se resuelve con un conector o con la búsqueda empresarial de Team y Enterprise, no metiendo el Drive completo en un proyecto.
¿Cuántos proyectos puedo crear?
El plan gratuito tiene un máximo de cinco, según la página de precios de Anthropic a septiembre de 2026; confirma en su web. Los planes de pago no publican ese límite. En la práctica lo marca el mantenimiento: cada proyecto necesita un dueño y media hora al mes, así que diez sin dueño valen menos que tres bien cuidados.
¿Las instrucciones del proyecto sustituyen al prompt de cada conversación?
No: lo acortan. Las instrucciones fijan lo que no cambia —quién eres, a quién te diriges, qué tono, qué nunca hacer— y el prompt aporta lo específico del caso. Si repites la misma frase en cada conversación, esa frase debería estar en las instrucciones; si algo cambia en cada caso, no debe estar ahí.
¿Puede el equipo editar la base de conocimiento?
Puede, pero conviene que no: edición para dos o tres responsables y lectura para el resto. Una base con quince editores termina con dos plantillas y tres políticas de descuento conviviendo, y el error se detecta cuando ya salió una propuesta equivocada.
¿Qué pasa con los datos personales que hay en los documentos?
Aplican las mismas obligaciones que a cualquier tratamiento: base legal, finalidad declarada, control de accesos y plazos de conservación. Lo práctico es anonimizar antes de subir, clasificar en tres niveles y dejar fuera todo lo sensible. Orientación general, no asesoría legal: consúltalo con tu responsable de cumplimiento.
¿Cada cuánto hay que revisar la base de conocimiento?
Una vez al mes, día fijo, media hora. El riesgo no es que falte información, sino que sobre información caducada: una lista de precios vieja conviviendo con la nueva produce respuestas plausibles y equivocadas. Si cambias precios con más frecuencia, la revisión sigue el ritmo del cambio.
¿Un Project sirve para atender a clientes automáticamente?
Por sí solo, no. Un Project es trabajo interno: alguien abre una conversación y pide algo. Para responder a clientes sin intervención humana hacen falta canal integrado, reglas de escalamiento y pruebas. Lo habitual es usar el proyecto para generar borradores que una persona aprueba y, cuando el volumen lo justifique, pasar a un agente.
¿Qué diferencia hay entre un Project y una skill?
El Project aporta contexto persistente y criterio para un tipo de trabajo. Una skill, según la documentación de Anthropic, es una carpeta de instrucciones, scripts y recursos que Claude carga cuando hace falta, y empaqueta un procedimiento de pasos fijos reutilizable. Lo normal es empezar por el Project y extraer la skill cuando ese procedimiento se repite en varios proyectos.
¿Se pierde el conocimiento si la persona que montó el proyecto se va?
Solo si el proyecto era personal y el dueño estaba definido por nombre. Compártelo desde el principio en Team o Enterprise, escribe el dueño en el índice como puesto y mantén el registro de cambios. Con eso, una baja es un cambio de responsable y no una pérdida de conocimiento.
Artículos relacionados
- Cómo implementar Claude en tu empresa: guía por fases
- Prompts de Claude para equipos comerciales
- Casos de uso de Claude por área en pymes
- Política interna de uso de IA y gobernanza
- Programa de formación en IA para equipos, en 8 semanas
- Integraciones y APIs
- Automatización de procesos con IA
- Más artículos del blog