Five processes that decide what happens to data
ExploreWorldAI is an EU regulatory intelligence platform for companies, not a travel service.
Most of what protects a customer is not a promise, it is a routine that runs the same way every time. These five processes decide what is allowed in, how long it stays, how it is separated from a person, how it is protected and what is written down about every access. Each one carries the article it answers to and the way it is checked.
This page describes our own processing as a controller and as a processor for our customers. Customer content processed on instruction is covered by the data processing agreement, which sets the same limits in contract form.
Reviewed: 2026-08-08
Data minimisation
- Legal basis
- Article 5(1)(c) and Article 25(2), Regulation (EU) 2016/679
- Purpose
- The cheapest way to protect a person is to never hold the record in the first place, so every field has to earn its place before it is collected.
- How it works
- An account is created without a name and without an email address; the identity is a generated code that only points to a balance and a set of keys
- Public company information read on request is stored as findings and figures, not as copies of pages about named individuals
- Free-text fields sent to the service are read for the answer and discarded, never kept as a customer archive
- Every new field in a form or a report has to name the decision it supports before it is added
- Fields that stopped serving a decision are removed at review instead of being kept in case they become useful
- Hard limit
- No special category data under Article 9 and no data about children is collected anywhere in the service. If such content arrives in an upload it is discarded rather than processed.
- Control
- Field inventory reviewed each quarter against the purpose it was added for; a field without a current purpose is removed in the same review.
Retention
- Legal basis
- Article 5(1)(e), Regulation (EU) 2016/679; Chapter 7, Swedish Accounting Act (1999:1078)
- Purpose
- A retention period is a decision made in advance, so that no record is kept simply because nobody remembered to delete it.
- How it works
- Every category has a written period, set by the purpose it serves or by an accounting duty, not by available storage
- Deletion runs on a schedule and does not wait for a request; a request only moves a deletion forward
- Support conversations are masked after seven days and deleted after thirty
- Accounting records are kept for seven years because bookkeeping law requires it, and are not used for anything else during that time
- A deletion that is blocked by a legal duty is answered with the duty and the date the duty ends
- Hard limit
- No category is kept indefinitely. Where a period cannot be shortened because of accounting law, the record is locked to that purpose only.
- Control
- Scheduled deletion is monitored as part of daily operations; a failed run raises an alert and is handled the same day.
Pseudonymisation
- Legal basis
- Article 4(5), Article 25(1) and Article 32(1)(a), Regulation (EU) 2016/679
- Purpose
- Separating a record from the person behind it means a leak of the record alone does not identify anyone.
- How it works
- The customer identity is a generated code, so usage, balance and receipts never carry a name
- Analysis records are stored against that code, and the code is not resolvable to a person from inside the service
- Names and contact details that appear in a report are shown to the customer and are not stored on our side
- Operational records keep counts and outcomes, never the text a customer wrote
- Recovery uses a code the customer holds, which means access can be restored without us storing an email address
- Hard limit
- Pseudonymisation is treated as a protective measure, not as anonymisation: records are still handled as personal data and still carry rights.
- Control
- Sampled review of stored records each quarter to confirm no direct identifier has entered a table that is meant to hold only the code.
Encryption
- Legal basis
- Article 32(1)(a), Regulation (EU) 2016/679
- Purpose
- Data has to be unreadable to anyone who gets hold of it outside the service, both while it travels and while it sits still.
- How it works
- All traffic to and from the service runs over TLS 1.2 or higher; plain connections are refused, not redirected silently
- Databases, file storage and backups are encrypted at rest by the hosting provider
- Access credentials and partner keys are stored as hashes or in a secret store, never as readable values in code or in a report
- A customer key is shown in clear once at creation; after that only a fingerprint and a prefix remain
- Keys can be rotated by the customer at any time, and an old key stops working the moment the new one is issued
- Hard limit
- No customer content is written to a location outside the encrypted stores, including temporary files used while an answer is produced.
- Control
- Transport settings and certificate validity are checked in operations monitoring; key handling is reviewed at each release that touches it.
Logging
- Legal basis
- Article 5(2), Article 30 and Article 32(1)(d), Regulation (EU) 2016/679; Article 12, Regulation (EU) 2024/1689
- Purpose
- A process only counts as controlled if you can show afterwards what happened, who reached the data and on what basis.
- How it works
- Every read and every export writes a record with time, purpose, jurisdiction and the identity code behind the request
- Every automated analysis writes its own record so a result can be traced back to the run that produced it
- Logs hold counts, outcomes and references, not the content of what a customer wrote
- Log records are protected against editing and are kept for a fixed period, then deleted with everything else
- A personal data breach is logged with time, scope and measures, so the seventy-two hour report can be filed with facts rather than estimates
- Hard limit
- Logs are never used to profile a person or to build a picture of an individual's behaviour; they exist to prove control and to investigate incidents.
- Control
- Access logs are reviewed monthly for unexpected patterns; the review itself is recorded so an absent review is visible.
Retention at a glance
Each category, the period it is kept, and what happens when the period ends. A shorter period always wins over a longer one when a record fits two categories.
| Category | Period | At the end of the period |
|---|---|---|
| Account and key records | For as long as the account is active, then twelve months | Deleted; keys stop working immediately when the account is closed |
| Analysis results and reports | Twelve months from the run | Deleted; only aggregated counts without a customer reference remain |
| Support conversations | Masked after seven days, deleted after thirty | Deleted; only the count of errands and the outcome remain |
| Access and operations logs | Twelve months | Deleted on a schedule; incident records follow the incident file |
| Accounting records and receipts | Seven years | Deleted; locked to the accounting purpose for the whole period |
| Uploaded documents | Read and discarded within the session | No copy is kept; only the fields the customer chose to save remain |
The rules these processes serve
Five processes, five sentences that decide when a process needs to change. If a change makes one of these sentences untrue, the change does not ship.
- Less data beats better protection
- A field that is never collected cannot leak, cannot be over-kept and cannot be misread. Removing a field is always considered before adding a control around it.
- A period is set before the data arrives
- No category enters the service without a written retention period. Storage is never the reason a record is still there.
- The identity stays outside the record
- Usage, balances and results are held against a generated code. A name is shown to the customer, it is not our copy to keep.
- Unreadable in transit and at rest
- Anything that is stored is encrypted, and anything that moves runs over a protected connection. There is no third state.
- What cannot be shown did not happen
- Access, analysis and incidents are written down as they occur, so a supervisor gets records rather than recollection.
Related pages
ExploreWorldAI is operated by Valkiv Ventures AB (Reg. no. 556995-1311), Kungsgatan 8, 111 43 Stockholm, Sweden. EU-hosted, with data processing assessed against the GDPR. Contact: hello@exploreworldai.com.
Machine-readable summaries for AI agents: /llms.txt and /llms-full.txt.
