Diseñar sistemas de negocio que cumplan los requisitos de protección de datos

La Ley de Protección de Datos Personales B.E. 2562 (2019) se aplica a las organizaciones que recopilan, utilizan o divulgan datos personales de personas en Tailandia. Distingue entre el responsable del tratamiento, que decide por qué y cómo se tratan los datos, y el encargado del tratamiento, que los trata por cuenta del responsable, y su supervisión corresponde al Comité de Protección de Datos Personales (PDPC). La ley establece las bases legales del tratamiento, los derechos de los titulares de los datos, las obligaciones de seguridad, los deberes de registro y la obligación de notificar las brechas de seguridad.

Esta guía tiene carácter informativo y no constituye asesoramiento jurídico. La ley, sus reglamentos de desarrollo y las directrices del PDPC cambian con el tiempo; su delegado de protección de datos o su asesor jurídico deben confirmar cómo se aplican a su organización. Lo que sigue es la perspectiva de ingeniería: cuando la ley exige que la organización pueda hacer algo, esta guía describe lo que necesita el sistema para hacerlo.

Cuando la base es el consentimiento, el sistema debe poder demostrar que una persona concreta aceptó un uso concreto, con una redacción concreta, en un momento concreto, y de qué manera. Almacene un registro de consentimiento con el identificador del titular de los datos, la finalidad, la versión del aviso o del texto de consentimiento que vio, la marca de tiempo, el canal (formulario web, aplicación, papel escaneado, llamada) y cualquier evidencia, como el ID del formulario. Conserve cada versión del texto de consentimiento; un registro que remite a un texto que se ha reescrito después no demuestra nada.

Retirar el consentimiento debe ser tan fácil como otorgarlo y debe surtir efecto en todos los sistemas que actuaron en función de él. Diseñe el consentimiento como un estado central que los sistemas posteriores (una plataforma de marketing, un sistema de envío de boletines, un pipeline de analítica) consultan en el momento de usarlo, y no como un indicador que se copia una vez y se olvida. El boletín de nuestro propio sitio web es un pequeño ejemplo de este patrón: doble confirmación por correo electrónico, un enlace para darse de baja en cada mensaje y una lista de exclusión que se aplica antes de cada envío.

El consentimiento no es la base adecuada para todo. Tratar los datos de un empleado para la nómina o los de un cliente para entregarle una compra se basa en un contrato o en una obligación legal; pedir el consentimiento en esos casos crea un derecho de retirada que la organización no puede respetar. Cuando la base se elige con precisión, los registros de consentimiento son menos numerosos y más significativos.

La ley exige medidas de seguridad adecuadas. En términos de sistemas, eso empieza por el mínimo privilegio: un acceso basado en roles en el que cada rol ve los campos que su trabajo requiere y nada más. Un modelo de Propietario/Administrador/Miembro/Lector es una buena base para un espacio de trabajo; las aplicaciones de negocio suelen necesitar roles más detallados, de modo que un operario de almacén vea las direcciones de entrega pero no los números de documento de identidad, y un agente de soporte vea los cuatro últimos dígitos de una tarjeta pero nunca el número completo. El enmascaramiento a nivel de campo, aplicado en la capa de API para que ningún cliente pueda eludirlo, compensa el esfuerzo en los campos personales y sensibles.

La minimización se aplica en la recopilación y en cada copia. Recopile solo los campos que necesita cada finalidad; no copie datos personales de producción en los entornos de pruebas y desarrollo, y genere o anonimice en su lugar los datos de prueba; limite las exportaciones y descargas masivas a los roles que las necesiten y registre cada una de ellas. Una autenticación robusta lo protege todo: inicio de sesión único con el proveedor de identidad de la organización, autenticación en dos pasos, llaves de acceso (passkeys) cuando sea posible y tiempos de expiración de sesión proporcionales a la sensibilidad de los datos.

Los encargados del tratamiento en los que se apoya la organización (alojamiento, correo electrónico, analítica, servicios de IA) necesitan contratos que los obliguen a cumplir los mismos estándares, y la arquitectura debe dejar claro qué datos personales fluyen hacia cada uno.

Los datos personales solo pueden conservarse durante el tiempo que exija la finalidad o que imponga la ley. Convierta este principio en un calendario de retención por categoría de datos, con un plazo y una justificación legal o de negocio: los registros contables, durante el plazo que exige la legislación tributaria; los datos de los candidatos a un empleo, durante un tiempo definido tras la decisión; las cuentas de clientes inactivas, tras un período de inactividad definido; las transcripciones de chats de soporte, tras un tiempo definido. Después, automatice el calendario. Una política de retención que depende de que alguien ejecute un script una vez al año no es un control.

Decida cómo funciona técnicamente la eliminación. La eliminación lógica oculta los datos pero los conserva; solo es aceptable como un breve período de gracia antes de la eliminación definitiva o la anonimización. La anonimización, que elimina o transforma de forma irreversible los identificadores sin perder las estadísticas, permite a la organización conservar el historial del negocio sin conservar a las personas. Las copias de seguridad requieren el mismo tratamiento: defina cuánto tiempo se conservan, confirme que están cifradas y asegúrese de que los datos restaurados queden sujetos a las eliminaciones realizadas después de crear la copia.

Los titulares de los datos pueden preguntar qué información tiene la organización sobre ellos, solicitar copias y rectificaciones, pedir la eliminación, oponerse al tratamiento o limitarlo, y retirar su consentimiento, y el responsable del tratamiento debe actuar dentro del plazo que fijan la ley y sus reglamentos. El requisito para el sistema es que un empleado capacitado pueda atender estas solicitudes sin ayuda de ingeniería: localizar todos los registros de una persona en los distintos módulos, generar una exportación legible de sus datos personales, rectificar un campo dejando constancia en la auditoría y ejecutar la eliminación o la anonimización respetando las reglas de retención aplicables (una factura no puede eliminarse porque el cliente lo haya pedido; puede conservarse con una base legal registrada).

Lleve un registro de solicitudes: quién la presentó, cuándo, cómo se verificó su identidad, qué se hizo y cuándo se completó. Este registro demuestra el cumplimiento y, a la vez, muestra dónde los procesos son lentos.

Un registro de auditoría deja constancia de quién hizo qué con qué datos y cuándo: inicios de sesión, cambios de permisos, consultas y exportaciones de datos personales, modificaciones y eliminaciones, y cambios de configuración. Debe escribirlo la aplicación en el momento de la acción, almacenarse separado de los datos del negocio con acceso de escritura restringido y conservarse durante un período fijado de forma deliberada. Unos registros que se guardan en la misma base de datos y con los mismos administradores no protegen frente a una amenaza interna.

Haga que los registros, además de existir, sean útiles: que puedan buscarse por persona y por registro, que se revisen periódicamente y que generen alertas ante patrones inusuales, como exportaciones masivas o accesos fuera del horario laboral. Los registros de auditoría contienen a su vez datos personales y deben figurar en el calendario de retención.

La ley obliga a los responsables del tratamiento a notificar al PDPC una brecha de datos personales sin demora indebida y, cuando sea posible, en un plazo de 72 horas desde que tengan conocimiento de ella, salvo que sea improbable que suponga un riesgo para los derechos y libertades; cuando el riesgo es alto, también deben informar a los titulares de los datos afectados. Setenta y dos horas pasan rápido. Desde el punto de vista del sistema, estar preparado significa detectar: contar con registros y monitorización que revelen un acceso no autorizado, y con la capacidad de determinar con rapidez qué datos se vieron afectados, de quién y durante qué período.

Desde el punto de vista organizativo, se necesita un proceso de incidentes por escrito: a quién se informa primero, quién evalúa el riesgo, quién redacta la notificación, quién habla con los clientes, y plantillas preparadas de antemano en cada idioma en el que trabaja la organización. Realice cada año un simulacro de mesa con un escenario realista, para que el runbook no se utilice por primera vez durante una brecha real.