Dominio 6 — Configurar privacidad, exclusiones y salvaguardas

Peso en el examen: 10-15%

¡Holi! 🌸 Llegamos al broche final. Este dominio enlaza con cosas que ya has visto en los Dominios 2 (content exclusions) y 3 (filtro de código público), pero aquí bajamos al detalle de configuración, límites y resolución de problemas, que es justo donde el examen esconde sus trampas más finas. Es un dominio donde los matices lo son todo: quién configura qué, dónde, con qué límites, y qué hacer cuando algo no funciona. Vamos a cerrar con nota. 💛

Un consejo antes de empezar: este dominio distingue mucho entre lo que una salvaguarda promete y lo que realmente puede garantizar. Igual que en la IA responsable, aquí abundan las opciones que suenan a "protección total y absoluta" — y esas casi siempre son la trampa, porque toda salvaguarda tiene sus límites.

La explicación en profundidad

Las content exclusions permiten a los administradores evitar que archivos, directorios o repositorios concretos se usen para informar las sugerencias de Copilot, manteniendo seguro el contenido sensible. Es la herramienta principal para decirle a Copilot "de estos archivos, ni mires".

La configuración se hace a dos niveles:

• Repositorio: en Settings → Copilot del repo, indicando los repos y las rutas/patrones a excluir.
• Organización: en Settings → Copilot de la organización, aplicando exclusiones más amplias.

Y sobre quién puede configurarlas: administradores de repositorio, propietarios de organización y propietarios de empresa. No pueden hacerlo colaboradores externos, ni el rol Maintain, ni contributors normales — es una decisión administrativa.

En cuanto a la granularidad, se puede excluir a nivel de repositorios, rutas/directorios, tipos de archivo y patrones (estilo fnmatch, sin distinguir mayúsculas). Un límite importante: no se pueden excluir "líneas sueltas" de un archivo — la unidad mínima es el archivo entero.

Cuando un contenido queda excluido, los efectos son:

• No hay code completion en los archivos afectados.
• Ese contenido no informa las sugerencias en otros archivos.
• Ese contenido no informa las respuestas de Copilot Chat.

Un detalle sobre cómo se combinan: las exclusiones se acumulan, no se sobrescriben. Las heredadas de organización/empresa aparecen como cajas grises de solo lectura, y las políticas impuestas a nivel de empresa tienen prioridad y no se pueden anular más abajo.

Content exclusion NO es lo mismo que .gitignore

Una confusión típica: .gitignore controla lo que Git rastrea (qué archivos entran al control de versiones). Content exclusion controla lo que Copilot puede ver como entrada. Son cosas independientes: un archivo puede estar perfectamente versionado en Git y, aun así, estar excluido de Copilot. No mezcles los dos conceptos.

🎯 Puntos clave que caen en el examen

• Disponible solo en Business y Enterprise.
• Se configura en repositorio u organización, nunca por usuario en el IDE.
• La configuran admins de repo, org owners y enterprise owners.
• No se pueden excluir líneas sueltas: mínimo, archivo entero.
• Las exclusiones se acumulan; las de empresa tienen prioridad.
• Distinta de .gitignore.

⚠️ Trampas típicas

• "Se configuran en el IDE o por usuario" → no, solo en repo u organización.
• Confundir content exclusion con .gitignore.
• Creer que puedes excluir líneas concretas → mínimo archivo entero.

📝 Mini-repaso

1. ¿En qué dos niveles se configuran las content exclusions y quién puede hacerlo?
2. ¿En qué se diferencia content exclusion de .gitignore?
3. ¿Puedes excluir solo unas líneas de un archivo?

La explicación en profundidad

Este subtema es, probablemente, el que más preguntas trampa genera de todo el dominio, porque revela que las exclusiones no son una protección hermética. El examen quiere que sepas dónde tienen fugas, para que no marques la opción de "protección total y absoluta" (que siempre es falsa). Vamos con los "agujeros" oficiales:

Agujero 1 — Información semántica indirecta. Aunque un archivo esté excluido, Copilot puede seguir usando información semántica de él si un archivo no excluido la expone. ¿Cómo? A través del propio IDE: cuando código no excluido referencia algo del excluido (tipos, definiciones que aparecen al pasar el ratón, símbolos, firmas de funciones), el language server filtra esos metadatos. No es que Copilot "lea" el archivo prohibido, es que se entera de su forma "de oídas" a través de sus vecinos. Ojo con esto: @workspace tampoco salta una exclusión, pero la fuga semántica sí puede colarse por esta vía indirecta.

Agujero 2 — Alcance limitado a la organización (scope). Las exclusiones aplican solo a los miembros de la organización donde se configuran. Si otra persona tiene acceso a esos mismos archivos desde fuera de tu organización, sí puede recibir sugerencias y respuestas que los referencien. La cortina solo la respetan los de tu casa, no las visitas de otras casas.

Agujero 3 — Limitaciones por IDE, función y versión. El soporte de exclusiones varía según el editor, la función y la versión. Ejemplos concretos que caen:

• En Visual Studio 2022 (v17.11+), Copilot respeta las exclusiones, pero solo en el repositorio raíz donde vive tu solución: no aplica reglas de submódulos git ni de archivos que no estén bajo un repositorio git.
• Las exclusiones no aplican en ciertos contextos como Copilot CLI, la app de Copilot, GitHub Mobile, ni en los modos Edit y Agent del chat en editores (según la implementación).
• No aplican a symlinks ni a repos en sistemas de archivos remotos.

Y un dato de propagación: los cambios en las exclusiones pueden tardar hasta 30 minutos en llegar a los IDEs con sesión ya cargada (puedes forzarlo recargando la ventana en VS Code, o reabriendo en Visual Studio/JetBrains).

⚠️ Trampa mortal

• Afirmar que las content exclusions garantizan protección total y absoluta → falso. Recuerda los tres agujeros: fuga semántica vía archivos no excluidos, scope limitado a la organización, y limitaciones según IDE/función/versión.

🎯 Lo que cae en los tests reales

• ¿Aplica content exclusion en todas las superficies? Si las opciones son del tipo "solo VS Code / solo GitHub.com / solo JetBrains / sí", la respuesta que dan por buena los tests es sí: define el límite del contexto de entrada sea cual sea la superficie. Las excepciones de arriba son la letra pequeña de la documentación; úsalas cuando la pregunta vaya de limitaciones.
• Quién la gestiona: administradores de repositorio, org owners y enterprise owners. ❌ No el rol Maintain, ni colaboradores externos, ni contributors.
• Qué se puede excluir: repositorios, rutas o directorios, tipos de archivo y patrones. ❌ Ni líneas sueltas ni ramas.
• Riesgo de que secretos o lógica propietaria viajen como contexto → la respuesta es content exclusion sobre esos repos, rutas o tipos de archivo (no desactivar el chat, ni code referencing).

📝 Mini-repaso

1. ¿Cómo puede Copilot "enterarse" de un archivo excluido a pesar de la exclusión?
2. Si alguien de fuera de tu organización tiene acceso al archivo, ¿le aplica tu exclusión?
3. ¿Sobre qué respeta las exclusiones Visual Studio 17.11+?

La explicación en profundidad

Ya conociste este filtro en el Dominio 3 desde el ángulo del flujo de datos; aquí lo vemos como salvaguarda configurable. Es un filtro opcional que bloquea las sugerencias que coincidan estrechamente con código público de GitHub (recuerda: actúa en el outbound, umbral ~150 caracteres).

Se configura a dos niveles:

• Individual (Pro): en los ajustes personales de Copilot de la persona.
• Organización (Business/Enterprise): lo controla la política de la organización.

Y aquí entra un concepto que se confunde con frecuencia: el code referencing. Son las dos caras de la misma moneda:

• Si bloqueas el código público (filtro activado en modo bloqueo), Copilot simplemente no te muestra sugerencias que coincidan.
• Si permites el código público (con referencias), Copilot sí te muestra la sugerencia, pero te notifica cuando coincide con un repositorio público y te da información de licencia y atribución, para que decidas con conocimiento de causa.

⚠️ Trampa típica

• Confundir bloquear código público (la salvaguarda que lo impide) con code referencing (que aparece cuando lo permites, para informarte de la coincidencia y su licencia).

🎯 Lo que cae en los tests reales

• "Allow + show references" → Copilot puede mostrar la sugerencia con enlaces a las fuentes públicas. No desactiva el filtro de duplicados ni ignora las content exclusions.
• Dónde se configura code referencing: a nivel de cuenta individual y mediante políticas de organización o empresa. ❌ No solo en el IDE, ni solo por repositorio.
• Si la empresa impone "bloquear código público", ni la organización ni el repo pueden anularlo.
• Exacto vs parecido: coincidencia exacta y larga (≈150+ caracteres) → la bloquea duplication detection. Sugerencias parecidas → las gobierna code referencing.
• Content exclusion vs code referencing: exclusion limita lo que Copilot ve como entrada; referencing gobierna las salidas que se parecen a código público. 🧠 Entrada = exclusion · Salida = referencing.
• ¿Miedo a que Copilot reproduzca código open source tal cual? → los controles de duplication detection / matching public code, no content exclusion.

📝 Mini-repaso

1. ¿Dónde configura el filtro de código público un usuario Pro? ¿Y una organización?
2. ¿Qué diferencia hay entre bloquear código público y el code referencing?

La explicación en profundidad

¿De quién es el código que genera Copilot? ¿Y qué pasa si una sugerencia acaba pareciéndose a código con licencia? Aquí entran las protecciones contractuales que ofrece GitHub.

GitHub ofrece a sus clientes de pago una indemnización (una cobertura legal) frente a ciertas reclamaciones de propiedad intelectual derivadas de las sugerencias de Copilot. Pero — y este es EL matiz que cae — esa protección tiene una condición: solo aplica si tienes activado el filtro de código público. Tiene toda la lógica: GitHub te cubre siempre que hayas activado la salvaguarda que precisamente reduce el riesgo de coincidencias. Si desactivas el filtro, pierdes la cobertura.

Además, hay principios de responsabilidad que ya conoces del Dominio 1: la persona desarrolladora es responsable de revisar, probar y validar el output. Y Copilot puede generar sugerencias similares para distintos usuarios — no garantiza que tu código sea único ni exclusivo.

⚠️ Trampa típica

• Asumir que la protección contractual aplica siempre → requiere el filtro de código público activado.
• Pensar que desactivar el filtro te da la protección → es al revés, te la quita.

📝 Mini-repaso

1. ¿Qué condición debe cumplirse para tener la indemnización de GitHub?
2. ¿Garantiza Copilot que tu código generado sea único?

La explicación en profundidad

Este bloque enlaza con la administración del Dominio 2, pero desde el ángulo de la privacidad: es fundamental entender qué información exponen estas herramientas y, sobre todo, qué NO exponen.

REST API de Copilot. Permite tareas de administración y métricas: listar los asientos (seats) asignados en una organización, obtener métricas de uso (número de sugerencias aceptadas, actividad del chat…). Lo que NO permite, por privacidad: ver las sugerencias o el código concreto de un usuario, medir la calidad de su código, ni dar feedback de estilo. La regla de oro: la API es administración + métricas de uso, nunca el contenido de lo que Copilot sugiere.

Audit logs. Registran eventos administrativos y de configuración: cambios en la configuración de content exclusion, gestión de seats, y actividad de Copilot (quién usó qué y cuándo), en Business y Enterprise. Lo que NO registran: el contenido de las sugerencias, ni "sugerencias aceptadas/bloqueadas" como tal.

⚠️ Trampa típica

• Pensar que la REST API o los audit logs pueden mostrar el contenido del código o de las sugerencias → nunca; solo administración y métricas/eventos.

📝 Mini-repaso

1. ¿Qué puede y qué no puede hacer la REST API de Copilot?
2. ¿Registran los audit logs el contenido de las sugerencias?

La explicación en profundidad

El examen incluye escenarios de "algo no va, ¿qué haces?". La clave es reconocer el síntoma y aplicar la solución correcta, sin irte a soluciones drásticas innecesarias.

Los casos más frecuentes y sus soluciones:

Fíjate en dos discriminaciones que el examen adora:

• "Copilot bloquea mi pom.xml" → la reacción incorrecta es "es un bug, reinstala". La correcta es entender que el pom.xml se parece a código público y el filtro lo está frenando → habilita las coincidencias con código público.
• "No hay sugerencias solo en un archivo" → no es un fallo general; sospecha de una content exclusion sobre ese archivo.

⚠️ Trampas típicas

• Responder "reinstala la extensión" a un bloqueo por código público → la solución es habilitar el matching de código público.
• Olvidar que la ausencia de sugerencias en un archivo puntual suele ser una content exclusion.

🎯 Lo que cae en los tests reales

• Recoger diagnósticos en VS Code: Ctrl/Cmd+Shift+P → escribe "Collect Diagnostics" → "GitHub Copilot: Collect Diagnostics".
• Dónde están los logs en VS Code: los de Copilot y la extensión, en el panel Output (y la carpeta de logs de extensiones); los de Electron, en Developer Tools.
• ¿Está excluido este archivo? Lo indica el icono de Copilot en la barra de estado del editor. Una exclusión no es un error, así que no aparece en el panel de errores.
• Acabas de cambiar una exclusión y no se nota: puede tardar hasta 30 minutos; en VS Code se fuerza con Developer: Reload Window.

📝 Mini-repaso

1. Si Copilot bloquea tu pom.xml, ¿cuál es la solución?
2. Si no hay sugerencias solo en un archivo, ¿qué sospechas?

• Configurar y auditar exclusiones de contenido (GitHub Docs)
• Consideraciones de administración y personalización — Microsoft Learn
• Controles de administrador para GitHub Copilot en Visual Studio