# Privacidad y manejo de datos

Un build local no envía nada. Un build en la nube ofusca en memoria y no conserva nada, excepto el Protection Map que le pediste que almacenara, que puedes desactivar. La telemetría está activada de forma predeterminada, informa cuando un build reporta un diagnóstico de nivel de error, nunca en un build limpio, y se desactiva con una variable de entorno.

Source: https://www.afterpack.dev/es/docs/privacy

El producto de ofuscación de AfterPack maneja tu código y los datos de tu cuenta como se describe a continuación. Las cookies y los análisis de este sitio se cubren por separado, en la [Política de privacidad](https://www.afterpack.dev/es/privacy).

> **La versión breve**
>
> Un [build local (Free)](https://www.afterpack.dev/es/docs/deployment-modes) nunca envía tu código fuente a ningún sitio. Un build en la nube (Pro) ofusca en memoria y descarta el código fuente al final de la solicitud. Se almacena un artefacto: el **[Protection Map](https://www.afterpack.dev/es/docs/protection-map)** para el [panel](https://www.afterpack.dev/es/docs/dashboard). Está delimitado por [espacio de trabajo](https://www.afterpack.dev/es/docs/dashboard/workspaces), expira, y puedes desactivarlo por proyecto. La telemetría está activada de forma predeterminada, informa cuando un build reporta un diagnóstico de nivel de error (un build rechazado o parcial), nunca en un build limpio, y se desactiva con [`AFTERPACK_telemetry_enabled=false`](https://www.afterpack.dev/es/docs/config#telemetry-enabled). Un DPA y la lista completa de subprocesadores están disponibles bajo solicitud.

## Un build local no envía nada

Un [build local](https://www.afterpack.dev/es/docs/deployment-modes) ejecuta AfterPack como un binario nativo en tu máquina. Nada sale de tu sistema de archivos, así que las secciones sobre la nube que siguen no le aplican. La única llamada de red que hace un build local es el informe de telemetría descrito abajo, que se dispara solo cuando un build reporta un diagnóstico de nivel de error (un build rechazado o parcial), no lleva código fuente, y se puede desactivar.

## Un build en la nube ofusca en memoria y no conserva nada

Cuando un [build Pro](https://www.afterpack.dev/es/docs/pro) envía código fuente a `api.afterpack.dev` para ser ofuscado, se procesa **solo en memoria**, durante la duración de esa única solicitud, y luego se descarta:

- **La solicitud se ejecuta dentro de un isolate de Cloudflare Worker en sandbox** que se destruye al terminar la solicitud. Nada sobrevive más allá de la respuesta.
- **Los registros nunca llevan código fuente.** Las líneas de log llevan un id de build, cantidad de archivos, totales de bytes, códigos de diagnóstico y la ruta de un archivo que falló. Nunca llevan el contenido de los archivos, nombres de identificadores ni valores de constantes.

Esto se cumple igual si llamas a la API directamente, a través de [la CLI](https://www.afterpack.dev/es/docs/cli) con [`AFTERPACK_key`](https://www.afterpack.dev/es/docs/config#key) definida, o a través de un [plugin de framework](https://www.afterpack.dev/es/docs/frameworks). Todos hablan el protocolo descrito en la [referencia de la API en la nube](https://www.afterpack.dev/es/docs/cloud-api).

Se almacena un artefacto: el Protection Map, descrito abajo, escrito después de que termina la ofuscación. El código fuente que subes para ofuscar sigue desapareciendo al final de la solicitud.

### Qué llevan y qué no llevan los registros

| Se registra | Nunca se registra |
| --- | --- |
| Marcas de tiempo (solicitud recibida, respuesta cerrada) | Contenido de los archivos |
| Códigos de estado HTTP | Nombres de identificadores |
| Id de build, cantidad de archivos, totales de bytes de entrada/salida | Valores de constantes, incluidos los secretos que estuvieran en el código fuente |
| [Códigos de diagnóstico](https://www.afterpack.dev/es/docs/diagnostics) (`DIAG_*`) | *Texto del mensaje* de diagnóstico en la telemetría |
| IP del cliente, para limitar la tasa de solicitudes | `sources` / `sourcesContent` del source map |
| Nivel del espacio de trabajo, para medición | Cualquier cosa que pudiera revelar tu lógica de negocio |

Las métricas agregadas (conteos de solicitudes por día, bytes medidos por espacio de trabajo, tiempos de build) se guardan como contadores y no contienen código.

## La telemetría está activada de forma predeterminada, y solo informa los diagnósticos de nivel de error de un build

El cliente puede informar diagnósticos de build anónimos para que los errores del motor se encuentren y se corrijan. Está activada a menos que la desactives. Un build limpio no tiene nada que informar:

- **Solo un build que emite un diagnóstico `error` o `critical` envía algo.** Un build limpio no envía nada en absoluto: ningún ping periódico, ningún tiempo de fase, ninguna estadística de uso para un build que simplemente funcionó.
- **Desactívala con [`AFTERPACK_telemetry_enabled=false`](https://www.afterpack.dev/es/docs/config#telemetry-enabled)**, [`--telemetry.enabled=false`](https://www.afterpack.dev/es/docs/config#telemetry-enabled) en la CLI, o [`telemetry: { enabled: false }`](https://www.afterpack.dev/es/docs/config#telemetry-enabled) en la configuración de tu integración. Esa es toda la superficie.
- **Se ejecuta igual en CI.** Ninguna verificación de TTY o CI cambia el valor predeterminado ni omite el informe; el payload simplemente registra `ci: true`, leído de la misma variable `CI` que tu pipeline ya define.
- **Nunca hay un prompt.** El primer build después de instalar imprime un aviso único (qué se recopila, qué no, cómo desactivarlo) y continúa. Nunca se bloquea esperando una respuesta. El estado (un id de instalación aleatorio que rota cada 30 días, y si el aviso ya se imprimió) vive en `~/.afterpack/telemetry.json`.
- **Las ejecuciones de prueba están exentas.** `NODE_ENV=test` y el propio marcador `VITEST` de Vitest desactivan la telemetría.

### Qué se recopila, cuando un build informa un diagnóstico de nivel de error

- El **código** del diagnóstico que falló, su severidad y el rango de desplazamiento en bytes, más una lista corta de campos tipados elegidos según el tipo de diagnóstico, nunca su mensaje de texto libre
- Las **versiones** del motor, del cliente y de Node, el sistema operativo/arquitectura, y el framework detectado
- Si el build se ejecutó en **CI**
- El nivel de complejidad: un [preset](https://www.afterpack.dev/es/docs/presets) con nombre, o `custom` para un valor directo de [`complexity`](https://www.afterpack.dev/es/docs/config#complexity)
- La cantidad de archivos y la duración del build, **agrupadas en rangos** (`5-20`, `1-5s`) en vez de exactas; un número exacto permite identificar un proyecto concreto
- Un **id de instalación** aleatorio que rota cada 30 días, nunca derivado de tu máquina o proyecto

### Qué nunca se recopila, ni en telemetría ni de otra forma

- Código fuente o contenido de archivos
- Nombres de archivos y rutas de archivos en la telemetría. El log del lado del servidor de un build en la nube lleva una ruta, la del archivo que falló dentro del lote, como se describió arriba
- El **texto del mensaje** de diagnóstico, en ningún caso; solo su `code` estable
- Claves de API o credenciales
- Valores de constantes
- Las decisiones de codificación de cadenas
- Cualquier información que identifique al usuario más allá de lo que ya contiene tu cuenta

La telemetría tiene una forma fija.

## Los Protection Maps de los builds en la nube se almacenan, y puedes desactivarlo

Un [Protection Map](https://www.afterpack.dev/es/docs/protection-map) *es* tu código fuente original, coloreado según cuánta transformación recibió cada token. En un build en la nube, AfterPack lo genera en el servidor que hizo la ofuscación y lo conserva, así que puedes abrir el mapa de cualquier build reciente desde el [panel](https://www.afterpack.dev/es/docs/dashboard/builds).

> **Este es el único lugar donde tu código fuente permanece en reposo**
>
> Almacenar Protection Maps está **activado de forma predeterminada, por proyecto**, y un mapa almacenado puede ser leído por **todos los miembros del [espacio de trabajo](https://www.afterpack.dev/es/docs/dashboard/workspaces) que posee el proyecto**. Si tu código fuente no debería ser legible para todo el espacio de trabajo, un administrador del espacio de trabajo [desactiva la opción](https://www.afterpack.dev/es/docs/protection-map#turning-it-off) en los ajustes de ese proyecto.

- **Qué se almacena:** los datos del mapa de cada build, tu código fuente original más las métricas por token detrás de los colores, compactados y comprimidos con gzip en Cloudflare R2, cifrados en reposo, más una fila de números de resumen para el panel. Tu salida ofuscada no se almacena.
- **Delimitado a un proyecto**, el proyecto al que está vinculada la [clave](https://www.afterpack.dev/es/docs/dashboard/api-keys) del build.
- **Legible solo por los miembros de ese espacio de trabajo.** No es público, no está indexado, no tiene enlace para compartir.
- **Retención: un año, y los últimos 500 builds por proyecto, lo que se cumpla primero.** Un trabajo cada hora elimina lo que supere cualquiera de los dos límites. Para un proyecto que hace builds con frecuencia, el conteo es el límite que se alcanza primero. Esto limita cuántas copias de tu código fuente existen en un momento dado.
- **Un mapa puede almacenarse parcial.** Cuando un build tarda mucho, la captura se detiene antes que la ofuscación. El registro almacenado indica qué fragmentos se omitieron y por qué.
- **Desactivarlo** hace que los nuevos builds dejen de almacenar nada para ese proyecto. Los mapas ya almacenados caducan bajo la retención descrita arriba en vez de eliminarse de inmediato. Los builds locales no se ven afectados: el Protection Map que un build local [escribe en `.afterpack/`](https://www.afterpack.dev/es/docs/cli#files) nunca sale de tu máquina.
- **Qué se sigue registrando con esto desactivado:** los números del build (cobertura, inflación, complejidad, tiempos), para que los [gráficos del panel](https://www.afterpack.dev/es/docs/dashboard/builds) del proyecto sigan funcionando. Estos son agregados derivados de un build. No contienen código, y nada en ellos se puede leer de vuelta como código.

## Subprocesadores

Un build en la nube involucra a estos procesadores. El código fuente pasa por Cloudflare **solo en memoria** mientras se ofusca; Cloudflare también es el único que llega a retener código fuente en reposo, como el Protection Map descrito arriba:

| Subprocesador | Función |
| --- | --- |
| **Cloudflare** | Workers / R2 / D1: cómputo en el borde, enrutamiento, almacenamiento del Protection Map y la base de datos de cuentas |
| **Creem** | Solo [facturación](https://www.afterpack.dev/es/docs/dashboard/usage), como comerciante registrado; nunca recibe código fuente |
| **Proveedores de email / autenticación** | Email de magic-link y transaccional para eventos de cuenta y del ciclo de vida de las claves; nunca reciben código fuente |
| **Anthropic** (vía Cloudflare AI Gateway) | Impulsa el asistente del sitio ("Ask AfterPack"); recibe lo que escribes en él y las páginas de documentación que lee para responder, nunca tu código fuente |

## Residencia de datos

Las secciones anteriores responden si el código fuente se almacena. La residencia es la pregunta separada de dónde se procesa mientras una solicitud está activa, y dónde reside el mapa almacenado.

Ninguna de las dos está fijada a una región. Cloudflare enruta un build en la nube a una región cercana, y bajo failover o carga puede terminar en otra. No hay una región fija por solicitud, y el almacenamiento en R2 no está bloqueado a una región. **Si necesitas una garantía firme de residencia, usa un [build local](https://www.afterpack.dev/es/docs/deployment-modes).** AfterPack se ejecuta enteramente en tu propia infraestructura, así que no surge ninguna pregunta de residencia.

## DPA y cumplimiento

Un Acuerdo de Procesamiento de Datos (DPA) está disponible bajo solicitud. El DPA que firmas es el contrato legal y exigible, y remite a la lista de subprocesadores y al comportamiento de residencia descritos arriba.

## Siguiente

- [Referencia de la API en la nube](https://www.afterpack.dev/es/docs/cloud-api): el protocolo de red al que aplican estas garantías.
- [Modos de despliegue](https://www.afterpack.dev/es/docs/deployment-modes): local frente a nube, y qué envía cada uno.
- [Protection Map](https://www.afterpack.dev/es/docs/protection-map): qué muestra el mapa almacenado, y dónde vive el interruptor por proyecto.
- [Pro](https://www.afterpack.dev/es/docs/pro): qué obtienes en realidad al ejecutar en la nube.
- [Espacios de trabajo y proyectos](https://www.afterpack.dev/es/docs/dashboard/workspaces): quién puede leer qué, y cómo se delimita una clave.
- [Panel](https://www.afterpack.dev/es/docs/dashboard): dónde se muestran un mapa almacenado y su registro de build.