Cómo gestionar la memoria de GitHub Copilot entre licencias personales y de organización (Guía 2026)

Copilot Memory almacena dos tipos de información. Los datos a nivel de repositorio cubren "convenciones de codificación, decisiones arquitectónicas, comandos de compilación y reglas específicas del proyecto". Las preferencias a nivel de usuario son "preferencias personales implícitas o declaradas sobre cómo quiere interactuar un usuario con Copilot".

Ambos tienen un alcance diferente.

Los datos del repositorio pertenecen al repositorio. GitHub explica que "esos datos solo se pueden usar en operaciones en el mismo repositorio" y que solo se crean "en respuesta a acciones de usuarios con acceso de escritura al repositorio que tienen habilitado Copilot Memory". Cualquier persona con acceso a Copilot Memory en ese repositorio se beneficia de ellos. También se verifican antes de su uso: "Los datos a nivel de repositorio se almacenan con citas que apuntan al código que los respalda", y cuando uno parece relevante, Copilot verifica esas citas con la rama actual. "Solo se utilizan los datos validados".

Las preferencias de usuario te siguen, pero con un propietario asociado. Este es el pasaje clave: "Las preferencias pertenecen a la entidad de facturación, que es la organización o empresa que otorga la licencia al usuario". Cuando se crea una preferencia, "se almacena en la entidad de facturación activa para el uso actual del usuario". And cuando Copilot crea el contexto para una sesión, "vuelve a mirar la entidad de facturación activa actual del usuario y solo recupera las memorias que pertenecen a esa entidad de facturación".

Por lo tanto, una preferencia que Copilot aprendió mientras tu licencia provenía de tu empleador pertenece a la organización o empresa de tu empleador. Cuando trabajas bajo una licencia diferente, Copilot recupera en su lugar las preferencias que pertenecen a esa otra licencia.

Si tienes más de una fuente de acceso, hay un requisito adicional: "Si recibes acceso a Copilot a través de múltiples empresas u organizaciones, debes seleccionar una entidad de facturación predeterminada para generar preferencias a nivel de usuario con Copilot Memory". Esa opción predeterminada decide qué cuenta puede gestionar y eliminar las preferencias generadas para ti.

La propiedad también tiene efectos prácticos para los administradores. En los planes Business y Enterprise, las preferencias a nivel de usuario "pueden ser visualizadas y eliminadas por un administrador de la organización o de la empresa". La guía de administración de GitHub añade que los administradores "pueden exportar o eliminar todas las preferencias a nivel de usuario que se generaron con su organización como la entidad de facturación activa", en formato JSONL. Esas acciones se registran: "Los eventos aparecen en el registro de auditoría de tu organización o empresa cuando un administrador exporta o elimina memorias, y cuando un usuario opta por no participar en Copilot Memory".

Dos reglas más definen lo que conservas. La disponibilidad depende del plan: para los planes individuales, Copilot Memory está activado por defecto, mientras que "para las suscripciones de Copilot gestionadas por empresas y organizaciones, Copilot Memory está desactivado por defecto y debe habilitarse en la configuración de la empresa u organización". Y las memorias caducan: "cualquier dato o preferencia almacenada que no se utilice se elimina automáticamente después de 28 días". Copilot Memory también se encuentra en vista previa pública, por lo que los detalles pueden cambiar.

Asumir que Copilot Memory es una sola memoria por persona. Es un conjunto de preferencias por entidad de facturación. Un plan personal y una licencia de empresa tienen cada uno el suyo propio.

No elegir nunca una entidad de facturación predeterminada. Al tener acceso desde más de un lugar, GitHub requiere una predeterminada antes de generar preferencias a nivel de usuario para ti. Si tu página de Memory no muestra ninguna preferencia, esto es lo primero que debes verificar.

Esperar que las preferencias aparezcan en la revisión de código. GitHub afirma que "la revisión de código de Copilot utiliza únicamente datos a nivel de repositorio. Las preferencias a nivel de usuario no se aplican durante la revisión de código". La CLI es diferente: "Copilot CLI aplica datos a nivel de repositorio y las preferencias a nivel de usuario del usuario que inició la operación".

Confiar en la memoria para las reglas que el equipo necesita. Los datos del repositorio son útiles, pero Copilot los infiere y caducan cuando no se usan. Las reglas del equipo deben estar en archivos de instrucciones, como explica cómo resuelve Copilot el orden de sus archivos de instrucciones.

Confundir Copilot Memory con la herramienta de memoria local de VS Code. Son funciones independientes con almacenamiento y ciclos de vida diferentes, detallados en cómo configurar la memoria de Copilot en VS Code.

Paso 1: Comprueba qué entidad de facturación es propietaria de tus preferencias hoy

Abre la configuración de Copilot en GitHub y ve a Memory. GitHub señala que "los usuarios pueden ver todas sus preferencias almacenadas y los propietarios correspondientes en su configuración personal". Léelas y anota el propietario de cada una. GitHub añade que "los usuarios pueden ver y eliminar sus propias preferencias a nivel de usuario independientemente de su plan de Copilot", así que aprovecha para eliminar cualquier cosa desactualizada mientras estás allí.

Si obtienes Copilot de más de un lugar, ve a la configuración de funciones de Copilot y selecciona una entidad de facturación predeterminada. Elige la que uses para la mayor parte de tu trabajo. GitHub hace de esta selección una condición para generar preferencias a nivel de usuario cuando tu acceso proviene de más de un lugar.

Mientras estás allí, comprueba si Copilot Memory está habilitado. En un plan gestionado por una organización, un administrador debe habilitar la política primero; después de eso, los usuarios se incluyen y pueden optar por no participar individualmente. GitHub describe la función como desactivada para las suscripciones gestionadas por la organización hasta que la organización o empresa la active, así que consulta con tu administrador si tus sesiones de trabajo no muestran memorias.

Por último, haz una lista de las preferencias que te importan: las elecciones de estilo de codificación, los hábitos de revisión y los detalles del flujo de trabajo que desearías que cualquier Copilot, bajo cualquier licencia, conociera.

Paso 2: Coloca el conocimiento del equipo en el repositorio y mantén tus preferencias personales en tus propias palabras

Separa los dos tipos de contexto y dale a cada uno un hogar que coincida con su propietario.

El conocimiento del equipo pertenece al repositorio. Las convenciones, decisiones de arquitectura, comandos de compilación y reglas del proyecto deben vivir en .github/copilot-instructions.md, archivos de instrucciones específicos de la ruta o AGENTS.md. Los datos de repositorio de Copilot Memory pueden complementar esto, pero las instrucciones escritas no caducan después de 28 días de desuso y no dependen de que Copilot las infiera correctamente. Si los datos de repositorio que Copilot almacenó son útiles, úsalos como base para escribir la regla. En los casos en que Copilot sigue perdiendo la estructura de la base de código, por qué GitHub Copilot olvida el contexto de la base de código cubre las soluciones más amplias.

Las preferencias personales son tuyas para reformularlas. Escribe una lista corta en tus propias palabras: cómo te gusta estructurar el código, hábitos de nomenclatura, preferencias de pruebas, cómo quieres las explicaciones. Esta es tu descripción de ti mismo, no una copia de nada almacenado bajo la entidad de facturación de un empleador. Puedes decirle estas cosas a Copilot bajo cualquier licencia y las aprenderá de nuevo.

Tén cuidado con la línea que separa ambas cosas. Las preferencias generadas bajo la licencia de tu empleador pertenecen a tu empleador, y los administradores pueden exportarlas o eliminarlas. Trátalas como datos de la empresa. Si quieres algo de ellas, pídeselo a tu administrador; no intentes copiarlas tú mismo.

Paso 3: Prepárate para los cambios de licencia antes de que ocurran

Los cambios de licencia son predecibles: un nuevo trabajo, un equipo que se traslada a una cuenta de empresa, un plan personal que agregas o cancelas. Planifica para ellos.

Antes de dejar una organización, asegúrate de que el contexto de equipo que aportaste esté en los archivos de instrucciones del repositorio, no solo en la memoria. Los datos del repositorio permanecen con el repositorio, pero pueden caducar, y las instrucciones escritas mantienen el conocimiento disponible para quien venga después. La versión más amplia de este traspaso se cubre en cómo mantener el contexto de IA cuando alguien se va.

Cuando comiences bajo una nueva licencia, dale a Copilot tu lista personal pronto. Cuéntale tus preferencias en las primeras sesiones en lugar de esperar a que las infiera, y revisa la página de configuración de Memory después de una semana para ver qué guardó y quién es el propietario.

Si trabajas con un plan personal y una licencia de empresa, sé deliberado sobre cuál usas para cada trabajo. GitHub almacena cada preferencia en la entidad de facturación que estaba activa cuando se creó, así que presta atención a qué licencia estás usando cuando Copilot aprenda algo que te importa.

La solución mantiene las reglas del equipo en el repositorio y las preferencias personales en tus propias palabras. Cierto contexto se sitúa entre ambos y sobrevive a cualquier licencia: decisiones que tomaste en varios proyectos, las razones detrás de tus convenciones, lecciones que se aplican en cada base de código que tocas. MemoryLake es un lugar para mantener esa capa, independientemente de quién pague por tu asiento de Copilot.

Tú mismo escribes las entradas, en tus propias palabras. No se lee, escribe ni elimina nada de Copilot Memory, tus repositorios o el almacenamiento de ningún proveedor. Antes de agregar algo sobre el código o las decisiones de un empleador, consulta la política de tu organización.

Paso 1: Crear una clave API

Inicia sesión y genera una clave desde el panel de control. La clave pertenece a tu espacio de trabajo de MemoryLake, de forma independiente a cualquier organización o licencia de GitHub.

Paso 2: Sube tus primeras memorias

Comienza con la lista personal del Paso 2 y las razones de múltiples proyectos que desearías tener en cualquier sesión. Una preferencia o decisión por entrada, con fecha.

Paso 3: Conecta tu IA y agentes

Conecta Copilot y los otros agentes de codificación que utilices. Tus preferencias estarán disponibles independientemente de la licencia o herramienta con la que estés trabajando.

La primera diferencia es que las preferencias que faltan dejan de ser un misterio. Sabes qué entidad de facturación es propietaria de qué memorias y por qué una sesión bajo una licencia no muestra lo que otra aprendió.

La segunda es que el conocimiento del equipo sobrevive a la rotación de personal. Las reglas viven en archivos de instrucciones que lee cualquier interfaz de Copilot, por lo que sobreviven tanto a la caducidad de 28 días como a las personas que las explicaron por primera vez. Para saber cómo se cargan esos archivos en la terminal, consulta cómo conectar las instrucciones de Copilot CLI.

La tercera es que un nuevo trabajo no significa empezar de cero. Tus propias preferencias escritas ponen al día a un nuevo Copilot en una o dos sesiones.

La cuarta es una línea clara entre el contexto de la empresa y el personal. Las preferencias propiedad de la empresa se quedan con la empresa, bajo el control de sus administradores, y tu conocimiento portátil es lo que escribiste tú mismo.

Establece una entidad de facturación predeterminada. Es obligatorio cuando tienes acceso desde más de un lugar.

Comprueba los propietarios en tu configuración de Memory. Cada preferencia muestra quién es su propietario.

Escribe las reglas del equipo en archivos de instrucciones. La memoria se infiere y caduca cuando no se usa.

Reformula las preferencias personales en tus propias palabras. Mantén la lista corta y actualizada.

Trata las memorias propiedad del empleador como datos de la empresa. Pregunta a un administrador en lugar de copiarlas.

Recuerda dónde se aplica cada memoria. La revisión de código utiliza únicamente datos del repositorio; la CLI utiliza ambos.

Utiliza también otras fuentes de contexto. Un espacio curado puede albergar conocimientos del proyecto que la memoria no tiene, como muestra cómo crear un espacio de Copilot que se mantenga actualizado, y los equipos que cambian de herramienta pueden comparar enfoques en cómo migrar de Copilot a Codex.

GitHub Copilot Memory almacena datos de repositorio que permanecen con el repositorio y preferencias personales que pertenecen a la organización o empresa que otorga tu licencia. Copilot solo recupera las preferencias que pertenecen a tu entidad de facturación actual, los administradores pueden exportar o eliminar las que pertenecen a su organización y las memorias no utilizadas caducan después de 28 días.

Ese diseño tiene sentido para las organizaciones, y significa que tu memoria de Copilot no es algo continuo. Elige una entidad de facturación predeterminada, comprueba quién es el propietario de qué, coloca las reglas del equipo en archivos de instrucciones y mantén tus preferencias personales en tus propias palabras.

Haz eso, y un cambio de licencia se convertirá en una breve presentación en lugar de un nuevo comienzo.