Proteger, conservar y demostrar

🌐 También en 28 idiomas

English · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Imagen generada con IA

Traducido con IA. Aún no revisado por la comunidad. Leer en inglés

Módulo 6 de 6 del capítulo Calidad y gobierno de datos, capítulo 5 del curso Data Architect. Cada módulo se sostiene por sí solo. Anterior: El consentimiento y el derecho al olvido · Siguiente: el próximo capítulo, Datos maestros e identidad

La pregunta que responde este módulo: ¿Cómo proteges los datos, los conservas el tiempo que se exige y lo demuestras?

Hemos fijado dueños y políticas, mantenido fuera los datos malos, escrito el diccionario, rastreado el linaje, clasificado lo que importa, aprendido las leyes y modelado el consentimiento. Ahora tenemos que ponerlo en marcha. Los datos llegan, se usan, se copian y se cambian, envejecen y, al final, algunos tienen que irse. Y algún día alguien preguntará: demuestra lo que pasó.

El gobierno sigue a los datos

No pienso en el gobierno de datos como una sola función. Pienso en lo que les pasa a los datos desde que entran hasta que terminamos con ellos:

Capturar → Clasificar → Proteger → Usar → Conservar → Eliminar → Auditar

No son siete procesos técnicos: son siete preguntas que la arquitectura tiene que responder. Capturar y clasificar ya los cubrimos: mantener fuera los errores costosos (módulo 2) y saber qué datos son sensibles (módulo 3). La clasificación decide lo que pasa en cada etapa posterior, así que este módulo sigue desde ahí.

Click to enlarge

Siete preguntas a lo largo de la vida de los datos. Las herramientas apoyan la política; no la definen.

Proteger: ajusta el control a los datos

¿Quién puede verlos, cambiarlos, recibirlos? ¿Deberían estar cifrados, enmascarados fuera de producción, poder exportarse, estar al alcance de un agente? Aquí es donde la seguridad de Salesforce pasa a formar parte del gobierno de datos: el uso compartido, los permisos de objeto y de campo, el cifrado, el enmascaramiento, el acceso de las integraciones. Esos temas llenan cursos enteros, así que no los volveré a enseñar. La idea de gobierno: la protección sigue a la clasificación y a la política. No todo campo necesita la misma protección, no todo usuario el mismo acceso, no todo sistema posterior cada campo.

El cifrado es un control, no el cumplimiento

Para los datos regulados, el cifrado en reposo puede ser obligatorio, y mi posición es que Shield es la respuesta para requisitos regulatorios clave como ese. Shield Platform Encryption cifra los campos y los archivos en reposo. Pero “lo ciframos, así que cumplimos” está mal por partida doble. El cifrado es un control entre muchos: acceso, retención, auditoría, consentimiento, monitoreo, minimización y eliminación. Y tiene compensaciones funcionales para las que hay que diseñar desde el principio. Con el esquema probabilístico predeterminado, un campo cifrado no puede usarse en las cláusulas SOQL WHERE, GROUP BY u ORDER BY ni en los filtros de gestión de datos; el cifrado determinista renuncia a un poco de solidez para que puedas filtrar por el campo. Los campos cifrados no pueden determinar reglas de uso compartido basadas en criterios, y no puedes ordenar las vistas de lista por ellos (General Shield Platform Encryption Considerations (opens in a new tab); Filter Encrypted Data with Deterministic Encryption (opens in a new tab), en inglés). Así que el cifrado no es una casilla al final. Es una decisión de arquitectura. El capítulo de seguridad de datos profundiza.

No copies el riesgo de producción al sandbox

Producción está bien protegida. Luego alguien actualiza un sandbox completo, y desarrolladores, probadores, contratistas e integraciones de prueba tienen ahora copias de datos personales reales que nunca necesitaron. El entorno cambió; la sensibilidad de los datos no. Las herramientas de enmascaramiento de Salesforce existen precisamente para esto. Fíjate en un cambio: el paquete gestionado Data Mask llega al fin de su servicio el 31 de diciembre de 2026, y su sucesor es Data Mask & Seed (Data Mask (Legacy) (opens in a new tab), en inglés). Pero la herramienta sostiene la política, y la pregunta va primero: ¿necesita este entorno datos sensibles reales en absoluto? Si datos realistas y no sensibles sirven para las pruebas, esa es la mejor respuesta.

Usar: el permiso no trata solo de personas

Los usuarios, las integraciones, la analítica, los socios, la automatización y los agentes usan los datos. El consentimiento (módulo 5), la propiedad (módulo 1) y la clasificación (módulo 3) se encuentran aquí en tiempo de ejecución. ¿Debería este usuario ver el número de teléfono del destinatario? ¿Debería recibirlo esta integración, o Snowflake, o este agente como base? La respuesta no puede ser “bueno, técnicamente puede”. Esa es la diferencia entre la capacidad y el gobierno: la arquitectura decide si debería.

Conservar: guardarlo todo para siempre no es neutral

Muchas organizaciones tienen una política de retención accidental: para siempre. Nadie la decidió; había almacenamiento disponible, así que los datos se quedaron. Pero guardar datos cuesta almacenamiento y rendimiento, amplía la exposición de privacidad y de seguridad, agrega obligaciones de búsqueda y te da más lugares que revisar cuando alguien pide que lo olviden. Para cada categoría importante: ¿por qué conservarla, cuánto tiempo, qué pone en marcha el reloj, hay un mínimo legal o un máximo de privacidad, y qué pasa al final: archivar, eliminar, desidentificar?

Y archivar no es lo mismo que resolver la retención. “Lo archivamos”. ¿Desapareció el requisito de retención? ¿El de privacidad? ¿La seguridad? Cambiaste dónde viven los datos, no lo que son. Un archivo necesita controles de acceso, reglas de retención y de eliminación, búsqueda y auditoría. Mueve datos personales a un archivo del que todos se olvidan, y el gobierno acaba de empeorar.

Eliminar: el ciclo de vida necesita una salida

La eliminación no es solo para las solicitudes de privacidad individuales. Los datos llegan al final de su período de retención; los registros temporales sobreviven a su uso; los archivos caducan; un proceso desidentifica pasado un tiempo fijado. Diga lo que diga la política, la arquitectura necesita una salida, no capturar → guardar → guardar más → guardar para siempre. Y como mostró el módulo 5, eliminar el registro de Salesforce no basta cuando hay copias en otros lugares.

El historial también son datos

A veces el valor actual no basta. El nombre legal de un socio, la clasificación de un cliente, un estado de consentimiento, un atributo financiero: el negocio o un regulador puede necesitar saber qué valor tenía antes, cuándo cambió y quién lo cambió. Ese historial son datos, y necesita su propia decisión de retención.

El seguimiento del historial de campos estándar sigue hasta 20 campos por objeto y conserva los cambios hasta 18 meses, y hasta 24 meses solo a través de la API, con Data Loader o queryAll() (Field History Tracking Overview (opens in a new tab), en inglés). Y en los campos de texto largo solo registra que el campo se editó, no lo que decía: un hueco si esa es tu evidencia. Field Audit Trail, parte de Shield o comprado por separado, sigue hasta 200 campos por objeto y conserva el historial hasta que lo eliminas, en un archivo al que accedes a través de la API (Field Audit Trail (opens in a new tab), en inglés). Mi posición: el historial de campos estándar es lo predeterminado; usa Field Audit Trail cuando una regulación o una obligación de cumplimiento exige un historial más largo y demostrable. No porque “auditoría suene bien”.

Auditar y monitorear no son lo mismo

El historial de campos responde preguntas sobre los cambios en campos seleccionados. Las preguntas más amplias (quién inició sesión, quién exportó datos, qué API se llamaron, quién vio qué) son monitoreo, y eso es Event Monitoring. En mi experiencia suele necesitarse con los clientes más regulados, y aquí va mi posición más firme de este capítulo: configúralo antes de necesitarlo, y envía los eventos a un repositorio, como Splunk u otro SIEM, por adelantado.

Esta es la razón. Los archivos de registro de eventos se conservan 1 día sin el complemento, y solo para algunos tipos de evento; 30 días de forma predeterminada con Shield o el complemento de Event Monitoring, y hasta 365 días si amplías la retención (Event Monitoring FAQ (opens in a new tab), en inglés). Todo lo anterior desaparece a menos que lo hayas exportado. Y los registros de pago no se pueden recuperar para ningún período anterior al inicio de tu contrato (misma FAQ): comprar el complemento después del incidente no trae de vuelta el pasado. Así que una de las peores conversaciones que puede tener un arquitecto es: “¿Podemos ver qué pasó hace seis meses?”. “No”. “¿Por qué no?”. “No lo estábamos capturando”. No quieres toparte con un problema y descubrir entonces que no has estado capturando ni guardando esos eventos. Para entonces, la respuesta simplemente ya no existe.

Click to enlarge

Configúralo antes de necesitarlo.

Pero no pases al otro extremo de “registrarlo todo”. ¿Qué intentas demostrar? ¿Qué eventos importan, quién los necesita, durante cuánto tiempo, quién puede leer los registros, y podrían los propios registros contener datos sensibles? Registrar crea datos, y esos datos también necesitan gobierno. Y la evidencia necesita un dueño: ¿quién es dueño del repositorio, revisa las alertas, comprueba que la retención funciona, se da cuenta de que la alimentación falló en silencio hace tres meses? La tecnología sin dueño no es gobierno; volvemos al dueño, el responsable y el custodio del módulo 1.

Demuestra el control, no solo la configuración

“Los datos del destinatario solo están disponibles para los equipos asignados a la parada”. ¿Cómo lo sabemos? La configuración de seguridad muestra lo que debería pasar. La evidencia operativa (quién accedió realmente, exportaciones inusuales, una integración que los extrae, controles de acceso que cambiaron) muestra lo que pasó. Un buen gobierno a menudo necesita las dos cosas.

Más allá del examen: lo que cambia la IA. A medida que los agentes pasan de responder a actuar, el gobierno necesita evidencia de lo que vio el agente, de lo que decidió o generó y de lo que hizo, y de quién o qué lo puso en marcha, con qué política. Los mecanismos de registro cambiarán; el requisito no: si una acción autónoma importa, diseña ahora cómo la reconstruirás después.

Steve Trucking: el ciclo de vida en un solo campo

Toma el número de teléfono del destinatario. Capturar: llega en el manifiesto del socio; comprueba que se puede usar donde lo necesita el proceso. Clasificar: datos personales. Proteger: solo lo reciben las personas y los sistemas con una necesidad operativa, y los equipos lo ven solo para sus propias paradas, ese día. Usar: el equipo coordina la entrega; la mensajería lo usa para un propósito aprobado; un agente lo usa solo si la política lo permite. Conservar: tanto tiempo como diga la política de negocio y de privacidad aprobada. Eliminar o desidentificar: cuando termina ese período o llega una solicitud válida, en cada copia del panorama. Auditar: conserva la evidencia de que los controles y las acciones ocurrieron.

Ahora toma un código de centro de distribución. Captúralo con exactitud, clasifícalo como dato de referencia no sensible, protégelo con un acceso operativo normal, úsalo ampliamente, consérvalo según lo necesite el negocio y audita los cambios si importan. El mismo ciclo de vida, controles distintos. Para eso es la clasificación.

El gobierno de datos nunca termina

Aparece una regulación nueva. Un sistema o una integración nuevos crean otra copia. Un equipo inventa otro campo. Una plataforma nueva sale a producción. Un agente obtiene acceso. Cambia una regla de retención. Llega un socio minorista nuevo. La arquitectura se mueve, y el gobierno se mueve con ella. El objetivo no son datos perfectos, controles infinitos ni un documento de gobierno que nadie lee. Son decisiones deliberadas sobre los datos, construidas dentro de la arquitectura.

Lo que decide aquí un arquitecto

• Qué controles de protección recibe cada categoría de datos, según la clasificación, la política y el uso real, incluidas las compensaciones del cifrado.
• Cuánto tiempo se conservan los datos y su historial, qué pone en marcha el reloj y qué pasa al final.
• Cuándo basta el historial de campos estándar y cuándo una regulación pide Field Audit Trail.
• Qué eventos se capturan, dónde se guarda la evidencia más allá de la retención de la plataforma y quién es su dueño.
• Cómo demuestra la arquitectura, después de los hechos, las acciones importantes de las personas, las integraciones y los agentes.

Este capítulo empezó con una idea: el gobierno de datos se diseña dentro de la organización, no se escribe al lado. Los dueños fijan la política y los arquitectos la hacen cumplir. Mantén fuera los datos malos donde importa. Sabe qué significan tus datos, de dónde vinieron y qué tan sensibles son. Respeta las leyes, modela el consentimiento, controla adónde van los datos personales. Protege, conserva y elimina según la política. Y captura la evidencia antes de que nadie la pida, porque seis meses después de un incidente es un pésimo momento para descubrir que la evidencia solo existió durante treinta días.

Explora

• Ayuda de Salesforce, General Shield Platform Encryption Considerations (opens in a new tab) y Filter Encrypted Data with Deterministic Encryption (opens in a new tab) (en inglés), consultado el 2026-10-14.
• Ayuda de Salesforce, Field History Tracking Overview (opens in a new tab) (en inglés), consultado el 2026-10-14.
• Ayuda de Salesforce, Field Audit Trail (opens in a new tab) (en inglés), consultado el 2026-10-14.
• Ayuda de Salesforce, Salesforce Event Monitoring Frequently Asked Questions (opens in a new tab) (en inglés), consultado el 2026-10-14.
• Ayuda de Salesforce, Secure Your Sandbox Data with Salesforce Data Mask (Legacy) (opens in a new tab) (en inglés), consultado el 2026-10-14.