---
id: KB-IN-012
url: https://app.codecontract.io/ayuda/integraciones/que-datos-salen-cuando-integrais
idioma: es
categoria: integraciones
audiencia: administrador
nivel: avanzado
actualizado: 2026-08-13
tambienEn: [en]
relacionados: [KB-IN-003, KB-IN-011]
citadoPor: [KB-IN-015]
---

# Qué datos salen cuando integráis

_Una integración abre una puerta. Conviene saber qué cabe por ella antes de abrirla._

**Responde a:** qué datos comparte una integración · seguridad de una integración con otro sistema · limitar qué puede leer una clave de acceso · riesgos de conectar dos plataformas

Una integración no es solo una comodidad: es una vía por la que la información sale de aquí y entra en otro sitio con sus propias reglas, sus propios accesos y su propia copia de seguridad. Conviene decidir a conciencia qué pasa por ahí.

## Las tres preguntas antes de conectar

1. **¿Qué puede leer esa conexión?** — Lo mínimo que necesite para su caso, no todo por comodidad.
2. **¿Dónde acaba lo que sale?** — Si el otro sistema está en otro país o lo lleva un tercero, eso cambia vuestras obligaciones.
3. **¿Quién puede usar esa llave?** — Una clave que circula por un chat de equipo ya no es una clave.

> [!IMPORTANT]
> La segunda es la que más se olvida y la que tiene consecuencias fuera de lo técnico. Los datos personales que salgan hacia otro sistema siguen siendo vuestra responsabilidad, aunque el problema ocurra allí.

## Qué conviene que NO salga

| Dato | Por qué |
| --- | --- |
| Documentos completos, si basta el estado | Casi ningún ERP necesita el PDF: necesita saber si está al día |
| Datos personales que el otro sistema no usa | Si no los usa, solo añade riesgo |
| Todo el histórico, si solo hace falta lo vivo | Lo cerrado casi nunca se consulta desde fuera |

> [!WARNING]
> La primera fila ahorra la mitad de los problemas de una integración. «Este proveedor está al día / le falta el seguro» es una frase; mandar el PDF del seguro es exportar documentación a un sistema que quizá no la protege igual.

## Cómo se cuida una llave de acceso

**En corto**

- Una llave por integración, no una compartida para todo.
- Con el permiso más bajo que funcione.
- Guardada donde se guardan las contraseñas, no en un documento ni en un chat.
- Y revocable en un minuto, sabiendo quién la usaba.

Ese último punto es el que hace falta el día malo. Si no sabéis qué integración usa qué llave, revocar por precaución rompe algo y nadie sabe qué.

> [!NOTE]
> Todo lo que hace una integración queda en el registro de actividad igual que lo que hace una persona. Si algo sale de aquí, se puede saber cuándo y por qué vía.

**¿Se puede limitar a solo lectura?**

Sí, y para la mayoría de los casos es lo correcto.

**¿Y si el proveedor de la otra plataforma cambia?**

Se revoca y se emite una llave nueva; por eso conviene una por integración.

**¿Hace falta contrato con el otro proveedor?**

Si van a tratar datos personales vuestros, sí. No es opcional.

## Ejemplos

**Una empresa quiere volcar toda la documentación de proveedores a su ERP.**

- Manda solo el estado documental y la fecha de caducidad
- Emite una llave de solo lectura para esa integración

→ El ERP muestra lo que necesita compras y ningún documento sale de la plataforma.

**Se integra y salen más datos de los que hacían falta.**

- Limita la integración a los campos que se usan

→ Lo que viaja es lo justo.

**Un cliente pregunta qué datos suyos salen hacia otro sistema.**

- Consulta qué campos incluye la integración

→ La respuesta es concreta y verificable.

**Salen datos personales sin que nadie lo decidiera.**

- Revisa el contenido con el asesor antes de activar

→ La decisión se toma antes y no después.

**Los datos llegan a un sistema con menos control de acceso.**

- Comprueba quién verá esos datos al otro lado

→ El nivel de protección no baja por el camino.

**Nadie sabe qué salió el mes pasado.**

- Consulta el registro de llamadas

→ Lo enviado es auditable.