No, por defecto no. Todos los tribunales federales de EE. UU. que se han pronunciado directamente sobre la cuestión desde 2021 han sostenido que un hipervínculo a un archivo alojado en la nube no es un adjunto tradicional, y que los archivos vinculados no heredan la relación de familia documental del mensaje que los contiene. Ese criterio se mantiene porque la resolución masiva de vínculos se ha considerado inviable o desproporcionada, no porque los archivos vinculados sean irrelevantes. Siguen siendo susceptibles de exhibición ante una solicitud dirigida, y el criterio se invierte por completo en cuanto pactas lo contrario en un protocolo ESI. Dos partes productoras ya lo aprendieron por la vía cara.
Un adjunto moderno (también llamado adjunto en la nube, adjunto vinculado o puntero) es una URL dentro de un correo, una publicación de Teams o un mensaje de Slack que resuelve a un archivo alojado en SharePoint, OneDrive, Google Drive o Box. Los bytes nunca viajan con el mensaje. Lo que recibió el destinatario fue un puntero y un permiso, y como el archivo de destino sigue vivo y editable después de enviarse el vínculo, el documento que el remitente compartió realmente puede que ya no exista cuando alguien lo recolecte.
Lo que no es
Un adjunto moderno no es un adjunto tradicional. Un adjunto tradicional es una copia: congelada en el momento del envío, transportada dentro del mensaje y unida a él por una relación padre-hijo que toda plataforma de revisión entiende. Un adjunto moderno es una referencia sin copia congelada y sin relación de familia inherente, que es exactamente el hueco sobre el que la jurisprudencia lleva cinco años discutiendo.
Tampoco es lo mismo que un enlace a una página web pública. Un enlace a una nota de prensa o a la página de precios de un proveedor está fuera de tu posesión, custodia o control, así que no genera obligación de producción. La prueba que convierte un enlace en adjunto moderno es si el archivo vinculado reside en un sistema que la parte productora controla. Y no son datos de mensajería corta, aunque ambos viajan juntos, porque los mismos protocolos ESI hoy rigen los dos, y los mensajes de Slack y Teams son donde los adjuntos modernos son más densos.
Por último, no se resuelve recolectando el Drive entero. La recolección del repositorio de archivos del custodio te entrega los archivos; no te dice qué mensaje apuntaba a qué archivo, que es justamente la asociación que la parte solicitante está pidiendo.
Lo que han resuelto los tribunales
| Caso | Tribunal / fecha | Resolución |
|---|---|---|
| Nichols v. Noom Inc., 2021 WL 948646 | S.D.N.Y., 11 mar 2021 (Parker, M.J.) | Se negó a ordenar archivos de Google Drive hipervinculados como adjuntos; la propuesta de recolección de los demandantes no era proporcional |
| In re Meta Pixel Healthcare Litig., No. 22-cv-03580-WHO | N.D. Cal., 2 jun 2023 (DeMarchi, M.J.) | El protocolo ESI debe establecer que los documentos hipervinculados no son adjuntos convencionales a efectos de familia; las solicitudes dirigidas se evalúan caso por caso |
| In re Uber Techs. Passenger Sexual Assault Litig., 2024 WL 1772832 | N.D. Cal., 23 abr 2024 (Cisneros, M.J.) | El protocolo define los adjuntos modernos, pero exime de producir la versión contemporánea cuando resulta inviable |
| In re StubHub Refund Litig., 2024 WL 2305604 | N.D. Cal., 20 may 2024 | El protocolo exigía los hipervínculos como adjuntos; el cumplimiento era imposible; se modificó el protocolo y se denegaron las sanciones |
| In re Insulin Pricing Litig., 2024 WL 2808083 | D.N.J., 28 may 2024 (Singh, M.J.) | Los hipervínculos no son adjuntos tradicionales; las herramientas disponibles “no son viables en absoluto o resultan indebidamente gravosas” |
| James v. Cerebras Systems Inc., No. 4:25-cv-09361-AMO | N.D. Cal., 7 jul 2026 | Los documentos hipervinculados “no se considerarán parte de una familia documental”; fija un mecanismo de solicitud dirigida con un tope y un plazo |
El hilo conductor no es que los archivos vinculados no importen. Es que los tribunales se han negado sistemáticamente a imponer a las partes productoras la reconstrucción masiva de familias mientras la tecnología no puede entregarla, y han empujado a las partes hacia un intercambio dirigido. Meta Pixel es la formulación más clara de la división: el protocolo dice que no hay familias, y por separado las partes atienden solicitudes específicas razonables según surjan.
StubHub es el caso que hay que leer antes de firmar nada. StubHub pactó un protocolo que definía los archivos hijos incluyendo los hipervínculos a documentos internos, luego descubrió que no podía cumplirlo e incumplió la orden desde su primera producción en adelante. El tribunal modificó el protocolo y denegó las sanciones, pero fue contundente sobre el origen del daño: el perjuicio “fue causado por la insensata decisión de StubHub de pactar el requisito de los hipervínculos en primer lugar”. Un pacto convierte un límite técnico en una orden judicial que ya estás incumpliendo.
La plantilla Cerebras
James v. Cerebras Systems (N.D. Cal., 7 de julio de 2026) es el primer protocolo ESI pactado que trata los adjuntos modernos y la gobernanza de la revisión con IA generativa en una sola orden, y sus disposiciones sobre hipervínculos son lo más copiable que hay hoy en el expediente:
- Los documentos hipervinculados no son miembros de la familia documental a efectos de producción de adjuntos.
- La parte solicitante identifica documentos producidos concretos que contienen vínculos relevantes y pide esos archivos, con un tope de 100 hipervínculos pertinentes y no privilegiados para recolección dirigida.
- La parte productora tiene 14 días para producir la versión tal como existía en el momento de la recolección, o la versión tal como existía cuando se envió el hipervínculo cuando eso sea posible.
Esa asignación es el punto clave. El solicitante carga con el costo de decidir qué importa; el productor carga con el costo de recuperarlo. A ninguna de las dos partes se le pide la recolección de todo por defecto que volvió intratable este asunto. La misma orden fija además la validación de la revisión con IA en un nivel de confianza del 95% para el muestreo del conjunto nulo, con una tasa de elusión que no supere el 3%, y exige los datos de mensajería corta en lotes de conversación de al menos 24 horas, algo cubierto en la entrada de eDiscovery.
Lo que las herramientas realmente pueden hacer
La respuesta jurídica está suficientemente asentada. Donde los equipos siguen saliendo lastimados es en la respuesta operativa, porque ambas suites principales recolectan adjuntos modernos y ambas lo hacen con límites fáciles de pasar por alto.
Microsoft Purview eDiscovery recolecta adjuntos en la nube en el nivel eDiscovery Premium, que requiere Microsoft 365 E5 o el complemento E5 Compliance y se licencia por cada custodio cuyos datos recolectas. Puede recolectar la versión en vivo, la versión existente en el momento de compartir, o todas las versiones, y agrupa el archivo vinculado con su mensaje padre mediante un GroupID compartido más una propiedad Is modern attachment.
El problema es que la versión compartida solo existe si la configuraste de antemano. Por defecto, el flujo recolecta la versión en vivo actual. Recuperar la versión que realmente se envió exige una etiqueta de retención configurada para aplicarse automáticamente a los adjuntos en la nube, que hace una instantánea de la copia en el momento de compartir. Si esa etiqueta no estaba activa antes de que ocurriera el envío, la versión enviada nunca se preservó y ninguna opción de recolección la traerá de vuelta.
Límites documentados de Purview, vigentes a su revisión del 11 de junio de 2026:
| Límite | Efecto |
|---|---|
| Los primeros 50 vínculos por mensaje | Los vínculos posteriores al 50 se ignoran en silencio |
| URLs de más de 2.048 caracteres | Se omiten |
| Cuerpo del mensaje de más de 100.000 caracteres | Los vínculos más allá de ese punto no se consideran |
| Tamaño total de propiedades superior a 1 MB | Se descarta |
| Solo correos HTML | Los correos de texto plano no se procesan |
| Correos y mensajes cifrados | Sin extracción de adjuntos modernos |
| Reenvíos y respuestas | Los vínculos en la parte citada no se extraen: hay que recolectar el mensaje original |
| Canales compartidos de Teams | No compatible; hay que añadir manualmente el sitio del canal compartido |
| Vínculos a carpetas y a OneNote | No se recolectan; solo archivos individuales |
| Indexación avanzada y OCR | No se aplican al contenido del archivo vinculado |
La atribución de custodio además funciona al revés: el archivo vinculado se atribuye al custodio del mensaje, no a quien es dueño del archivo. Si el usuario A comparte un archivo del OneDrive del usuario C con el usuario B, y recolectas desde el buzón del usuario B, el archivo queda bajo el usuario B.
Google Vault exporta archivos de Drive vinculados mediante la opción Export linked Drive files en las exportaciones de Gmail. Devuelve únicamente la versión actual: Vault no tiene un equivalente de versión al momento del envío como la instantánea por etiqueta de retención de Purview. Los hipervínculos públicos, como páginas publicadas de Google Sites y enlaces a formularios de Google enviables, no se pueden exportar, ni tampoco algunos formatos heredados de enlaces de Drive, ni los enlaces dentro de mensajes cifrados. Los archivos exportados llegan separados de sus mensajes padre, así que la asociación debe reconstruirse después a partir del mapeo de drive-links exportado, antes de la revisión.
Cómo negociarlo antes de la recolección
Haz esto en el protocolo ESI, antes de recolectar a un solo custodio:
- Declara la regla de familia de forma explícita. Escribe que los archivos hipervinculados no son miembros de la familia documental, con la formulación de Meta Pixel / Cerebras. El silencio es peor que cualquiera de las dos respuestas, porque deja la pelea para un momento en el que ya has producido.
- Fija el mecanismo de solicitud dirigida con un número y un plazo. Cerebras te da 100 hipervínculos y 14 días. Elige cifras acordes al asunto, pero elige cifras: “solicitudes razonables” sin tope reproduce el problema de la recolección masiva con otro nombre.
- Nombra qué versión se debe. La de la fecha de recolección o la de la fecha de envío. No prometas la de envío salvo que el etiquetado de retención de adjuntos en la nube ya estuviera activo en todos los sitios en alcance cuando se enviaron los mensajes. Verifica la fecha de configuración, no el documento de política.
- Recorta las exclusiones que realmente tienes. Copia al protocolo los límites reales de tu plataforma: el techo de 50 vínculos, los mensajes cifrados, las partes citadas de los reenvíos, los canales compartidos de Teams. “En la medida en que sea técnicamente viable” es una frase que tendrás que litigar; una lista enumerada es una que puedes señalar.
- Haz el tope recíproco. En un asunto con dos partes con mucha documentación, la parte solicitante pasa a ser la parte productora en la reconvención.
- Haz la prueba de viabilidad antes de firmar. Toma una muestra de unos cientos de mensajes en alcance, pásalos por la plataforma que vas a usar de verdad y cuenta cuántos vínculos resuelven a un archivo que puedas producir. Ese número, y no la ficha técnica del proveedor, es contra lo que negocias.
Errores frecuentes
- Pactar hipervínculo-como-adjunto sin probarlo. Este es exactamente el fallo de StubHub, y la comprensión del tribunal no alcanzó al pacto en sí. Guardia: trata cualquier cláusula sobre hipervínculos como un compromiso técnico que exige una recolección de muestra antes de la firma, al mismo nivel que aceptar un formato de producción.
- Suponer que la versión enviada es recuperable. Tanto Purview como Vault devuelven por defecto la versión en vivo actual, y la instantánea al momento del envío de Purview solo existe donde se aplicó una etiqueta de retención de forma prospectiva. Guardia: activa el etiquetado de retención de adjuntos en la nube como control permanente de preparación para retenciones, no como paso del momento de recolección: para entonces la cuestión ya está decidida.
- Leer un informe de recolección limpio como si fuera completo. El techo de 50 vínculos, el corte de 2.048 caracteres de URL y la exclusión de las partes citadas descartan vínculos sin dar error. Guardia: marca durante el procesamiento los mensajes con más de 50 vínculos y derívalos a revisión manual; concilia el recuento de vínculos en el cuerpo de los mensajes contra los vínculos efectivamente resueltos.
- Retener el buzón pero no el archivo. Una retención sobre el buzón de un custodio no congela un archivo vinculado que está en el OneDrive de otra persona, y la atribución de custodio de Purview no te dirá de quién era realmente. Guardia: define el alcance de la retención legal sobre ubicaciones de archivos además de custodios, y preserva las colecciones de sitios desde las que comparten realmente los equipos en alcance.
- Producir archivos vinculados que nunca pasaron por el filtro de privilegio. Un archivo vinculado entra porque su padre coincidió con un término de búsqueda, incluso, según la documentación de Purview, cuando el propio archivo no habría coincidido y aunque esté fuera del límite de cumplimiento. Guardia: pasa el corpus de archivos vinculados por la revisión de privilegio como población propia y con sus propios términos de búsqueda, antes de que se una al conjunto de producción.
Relacionado
- eDiscovery — el proceso que lo rodea, las etapas del EDRM y el resto del protocolo Cerebras
- Proceso de retención legal — donde hay que decidir la preservación de adjuntos en la nube
- Revisión de privilegio — el filtro que los archivos vinculados esquivan por defecto
- Microsoft Purview eDiscovery — el lado de recolección para tenants de Microsoft 365
- Relativity — donde aterrizan para revisión las familias reconstruidas