Tratar datos personales y de salud
Qué datos de esta API son sensibles y qué obligaciones trae recibirlos.
Casi todo lo que lee esta API es un dato personal de alguien. Un nombre, un teléfono, un correo, la hora a la que alguien va a pasar por una sucursal. La ley chilena 21.719 regula ese tratamiento y rige desde diciembre de 2026. Esta página dice qué parte nos toca a nosotros y qué parte te toca a ti.
Esto no es asesoría legal
Es la descripción de lo que hace el sistema y de lo que trae aparejado usarlo. Las obligaciones concretas de tu organización dependen de qué hagas con los datos, y eso solo lo sabes tú.
Los dos papeles
El workspace es el responsable del tratamiento: son sus clientes, su base y sus decisiones sobre qué hacer con ellos. Vitrina es el encargado: trata esos datos por cuenta del workspace, bajo sus instrucciones y para prestarle el servicio.
Cuando tu integración lee la API con una credencial del workspace, actúa dentro de ese tratamiento. No eres un tercero que recibe una base de datos: eres una herramienta más del responsable.
Lo que saques de la API y lleves a otro sistema sí sale de nuestro perímetro. Ahí las obligaciones viajan contigo: seguridad, retención, derechos de las personas.
Qué está marcado como sensible
La ley 21.719 distingue los datos personales sensibles (artículo 2 g) y les pone un régimen más estricto. Los datos de salud y el perfil biológico están ahí, con reglas propias en el artículo 16 bis.
El contrato lo dice por operación. Cada operación del openapi.json que publicamos lleva la extensión x-vitrina-sensitive: true cuando lo que devuelve o recibe es un dato sensible:
{
"x-vitrina-tier": "interna",
"x-vitrina-sensitive": true
}Un dato de contacto ordinario no está marcado. Un contacto entero llega así:
{
"data": {
"id": "5f3a9c1e-2b7d-4e8a-9c0f-1d2e3f4a5b6c",
"external_id": null,
"name": "María González",
"email": "[email protected]",
"phone": "+56912345678",
"lifecycle_stage": "prospect",
"job_title": "Gerente de operaciones",
"company_id": "9a1b2c3d-4e5f-4a6b-8c7d-8e9f0a1b2c3d",
"origin_channel": "manual",
"email_consent": false,
"email_status": "subscribed",
"merged_into_contact_id": null,
"created_at": "2026-09-21T14:03:11.000Z",
"display_name": "María González",
"named": true,
"channels": ["whatsapp"],
"lead_sources": ["website"]
}
}Nombre, correo, teléfono y comuna son datos personales, con todas las obligaciones que eso trae, pero no son sensibles. Qué sí lo está depende de tu vertical:
Ninguna operación está marcada como sensible. Un auto no es una persona, y lo que la API devuelve sobre él (marca, año, kilometraje, precio) no es un dato personal de nadie.
La excepción a vigilar está en los archivos. El expediente de una unidad guarda
documentos de identidad de personas reales: la cédula de un consignante, un
contrato firmado. Y el filename que alguien escribió suele traer el nombre de
otra persona:
{
"data": [
{
"id": "b0f998b5-eb80-42ea-be16-8356dbbd0643",
"tenant_id": "00000000-0000-4000-8000-000000000001",
"vehicle_id": "5d00f5cf-ebe3-4e8b-a456-8d783daed0be",
"kind": "cedula",
"storage_bucket": "vehicle-registry",
"storage_path": "00000000-…/5d00f5cf-…/1fee60f8-…-cedula_consignante.pdf",
"filename": "cedula_consignante.pdf",
"mime_type": "application/pdf",
"byte_size": 610,
"subject_contact_id": "01a0c68e-4a0c-7bb4-888d-2cd0c3b5ff25",
"uploaded_by": "20000000-0000-4000-8000-000000000001",
"uploaded_at": "2026-09-22T00:40:34.958Z",
"created_at": "2026-09-22T00:40:34.958Z"
},
{
"id": "44173198-bd20-40ea-b08d-8f36dbf5c5df",
"tenant_id": "00000000-0000-4000-8000-000000000001",
"vehicle_id": "5d00f5cf-ebe3-4e8b-a456-8d783daed0be",
"kind": "padron",
"storage_bucket": "vehicle-registry",
"storage_path": "00000000-…/5d00f5cf-…/a0d1a414-…-padron_RJKL48.pdf",
"filename": "padron_RJKL48.pdf",
"mime_type": "application/pdf",
"byte_size": 610,
"subject_contact_id": null,
"uploaded_by": "20000000-0000-4000-8000-000000000001",
"uploaded_at": "2026-09-22T00:37:29.063Z",
"created_at": "2026-09-22T00:37:29.063Z"
}
]
}subject_contact_id dice de quién es ese documento. El contrato no marca estas
operaciones, y aun así son datos personales con todas las obligaciones de esta
página. Está advertido en Expediente.
Qué hace el sistema por su cuenta
- Un evento nunca lleva un dato sensible en el cuerpo. Aunque la suscripción pida «Incluir datos del recurso», un evento sobre un dato sensible llega siempre como aviso, con
data_omitted: "sensitive". Para leerlo hay que llamar a la API con una credencial. Esa llamada pasa por los permisos, la visibilidad y el registro de accesos (Webhooks). - El permiso que abre la capa sensible es propio y no se hereda. El permiso de la capa de afuera no abre la de adentro; hay que pedirlo aparte. Y una credencial no puede repartirse a sí misma uno que no tenga (Autenticación, Scopes).
- Cada lectura de un dato sensible queda registrada, con quién la hizo y cuándo. Ese registro es el que permite responder a una persona qué se hizo con sus datos.
- Una aplicación conectada no alcanza la capa sensible, ni por MCP ni por la API. El perfil del conector no incluye ninguna de esas herramientas: no es que respondan que no, es que no existen (MCP).
Y si la misma credencial llama la operación directamente, recibe 403 CONNECTED_APP_SENSITIVE_DATA:
{ "error": { "code": "CONNECTED_APP_SENSITIVE_DATA", "message": "Esta operación entrega datos personales sensibles (…). Una aplicación conectada no puede leerlos: úsala con una API key o un token personal del workspace, emitido para este fin. …", "requestId": "7d0b3c2e-5a41-4f7e-9c11-2b8e6f0a4d93" } }La marca del contrato es la que decide. Una operación marcada queda cerrada para una aplicación conectada desde el día en que existe, esté publicada o no.
Qué te toca a ti
Si tu integración saca datos personales de esta API y los guarda en otro sistema:
- Ten una razón. El tratamiento necesita una base de licitud. Para un dato sensible el estándar es más alto: consentimiento expreso, salvo las excepciones del artículo 16 bis.
- Saca solo lo que necesitas. Pide los permisos mínimos que alcancen para el trabajo.
- Guarda el
idy no la copia entera. El modo por defecto de los eventos es el aviso con unaurl, y existe para esto. Tu sistema guarda la referencia y lee el dato cuando lo necesita, en vez de acumular una segunda copia de la base. - Ten un plazo de retención y cúmplelo. Un dato que ya no necesitas es riesgo sin contraparte.
- Ten cómo borrar. Cuando una persona ejerce su derecho de supresión frente al workspace, el workspace tiene que poder cumplirlo también en tu sistema.
- Cifra en reposo y en tránsito. No dejes datos personales en los logs de depuración ni en mensajes de error que se van a un tercero.
- Avisa rápido si algo se filtra. La notificación de brechas tiene plazos, y el workspace no puede cumplirlos si se entera tarde.
Cómo ve a las personas una aplicación conectada
Una aplicación conectada es un asistente o un cliente que alguien del workspace autorizó por OAuth. No es el workspace: es un tercero al que el workspace le abrió una puerta. Qué ve de las personas depende de la vertical:
Ve los contactos como los ve el miembro que la autorizó, dentro de sus scopes: nombre, teléfono, correo. Son datos personales ordinarios, y las obligaciones de «Qué te toca a ti» viajan con ellos igual.
Una API key del workspace o un token personal no pasan por esto: actúan dentro del tratamiento del workspace, como una herramienta más suya.
Qué permisos tocan datos sensibles y quién los lleva está en Scopes.