> For the complete documentation index, see [llms.txt](https://docs.eximee.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.eximee.com/documentation/documentation-en/budowanie-aplikacji/model-danych/rodo-zarzadzanie-danymi-osobowymi.md). # GDPR in the data model ## Page purpose This page contains a practical guide for low-coders on how to configure personal data handling in the low-code platform's data model. ## General configuration principles To enable the Eximee Platform to handle personal data correctly, the low-coder must indicate the data model fields containing such data. This is done by selecting the type **Person** when adding an object to the data model. {% hint style="warning" %} ## TODO Screenshots from the Designer. {% endhint %} * An object of type **Person** contains fields defined at the organization level, e.g. `first_name`, `last_name`, `email`, `phone_number`, `date_of_birth`, `residential_address`, etc. * An object of type person also contains other objects, e.g. **Address** * Do not change the structure of the object of type **Person** locally in a single application. {% hint style="success" %} Adding an object `Person` instead of individual fields reduces the risk of omitting important personal data. {% endhint %} ## Configuration example {% hint style="warning" %} ## TODO Example structure of a data model with a person {% endhint %} ## GDPR handling mechanisms The platform automatically applies personal data processing mechanisms. Field handling differs depending on whether the field value is stored in the data model or is dynamically retrieved using providers. | Mechanism | Data stored in the data model | Dynamically retrieved data | | --------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **depersonalization** | performed automatically for marked personal fields | no action | | **retention** | the personal data retention period is configured globally | no action | | **audit** | access to personal data is automatically logged by the platform, see Eximee Audit Trail | access to personal data is automatically logged by the platform, see Eximee Audit Trail | | **access control** | access control is provided by the platform; the low-coder can additionally control access permissions to data in the application logic | access control should be provided by an external service; if such a mechanism is not available on the service side, the low-coder can control access permissions to data in the application logic | | **export** | personal data can be exported in a secure format, see Eximee Audit Trail | values of data read within the application can be exported in a secure format, see Eximee Audit Trail | | **deletion** | the platform supports deletion of personal data in accordance with the retention policy and GDPR requirements | no action | {% hint style="warning" %} Depersonalization and deletion of personal data are performed automatically. The low-coder does not need to configure this mechanism, but must ensure the correct markings. {% endhint %} ## Best practices * Use objects of type `Person` at the data model design stage. * Do not modify the structure of the object `Person` locally in a single application. * **Do not store values retrieved from external services in the data model.** Unless there is an important reason to do so. ## Related information * [Personal data and GDPR](/documentation/documentation-en/wprowadzenie/rodo-zarzadzanie-danymi-osobowymi.md) — a general overview of functionality and architecture. * [Data model](/documentation/documentation-en/budowanie-aplikacji/model-danych.md) — information about the data model in the platform. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.eximee.com/documentation/documentation-en/budowanie-aplikacji/model-danych/rodo-zarzadzanie-danymi-osobowymi.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.