Entio holds information about people connected to Latvian companies — company owners, board members, beneficial owners, prokūrists and representatives. Almost everyone in it has never contacted us, has no account, and did not give us their data. This page explains what we hold about you, where it came from, who can see it, and how to object.
Counted in our register store on 29 July 2026.
Entio is operated by KairoLab SIA, registration number 50203727101, registered at Rūpniecības iela 18C-16, Madonas nov., Madona, LV-4801, Latvia. You can reach us at support@kairolab.ai.
the controller identity for this processing, and whether KairoLab SIA is sole controller or a joint controller with the customer organisations that decide whom to look up
Factually: KairoLab SIA operates Entio and runs the collection from the registers. Customers choose which companies and people they query, and (where enabled) whom they monitor.
the registered postal address to publish for data-subject correspondence
whether a Data Protection Officer must be appointed and, if so, their contact details
No DPO has been appointed as of the date above.
Not every person has every category below — most people have the first three and nothing else. Each card names the store the data lives in, so that this page can be checked against the system rather than trusted.
Your forename and surname, and your Latvian personal identity code in full. We also store the masked display form of that code (DDMMYY-*****), your citizenship as a country code where the register gives it, and — for people registered as foreign nationals — a date of birth and the identity number the register assigned you. Whatever identity-document details the register returns are stored as received.
Stored in NaturalPerson
Every connection the register records between you and a company: whether you are a member or shareholder, an officer, a prokūrists, a beneficial owner or a representative; which company, by registration number; your shareholding percentage; and the dates the role started and ended. Historic roles are kept after they end.
Stored in NaturalPersonInvolvement
We compute and store totals you will not find in the register itself: how many companies you are currently connected to, how many in total, how many of them have failed, your highest-authority current role, your largest shareholding, the combined revenue and combined employee count of those companies, their combined tax debt, the date you were first appointed anywhere, the date of your most recent change, and your year of birth derived from the first six digits of your personal code.
Stored in NaturalPersonStats
Whether the State Revenue Service’s public PNP database lists you; if it does, the qualifying positions it names; and the family members and close associates it links to you, by name and relationship — including where the person listed is your relative and not you. The raw response is retained as the audit record of the check.
Only visible to customers who hold the AML-screening entitlement.
Stored in NaturalPersonPepStatus
Whether your identity number matches a sanctions record carried by the register, and which record. The match is made on the identity number alone — never on your name or date of birth — because a wrong sanctions flag is a serious harm. A person named on a sanctions list without an identity number cannot be matched this way and will show as unmatched.
Only visible to customers who hold the AML-screening entitlement.
Stored in NaturalPersonSanction
Insolvency and legal-protection proceedings the register connects to you: the type, the start and end dates, and whether the proceeding was annulled.
Stored in NaturalPersonInsolvency
Where the commercial-pledge register names you as a party to a pledge — as pledgor, pledgee or debtor — with the pledge number and the registration and removal dates.
Stored in NaturalPersonPledgeInvolvement
Where a customer has paid to reveal them, business contact details obtained from a third-party contact-enrichment provider: work and personal email addresses, phone numbers, a professional-network profile link, a job headline and summary, location, photo, years of experience, skills, education, employment history, languages and certifications.
Only exists where a customer has separately requested and paid for it — it is not collected for the whole register.
Stored in Contact-enrichment profile / contact records
We log which of our customers viewed your full personal code and when, and — where person monitoring is switched on — every time an organisation added you to or removed you from a monitored list. These records exist so that access to your data is accountable.
Stored in ActivityLog (_audit_unmasked_pid_view, _audit_person_watchlist_change)
The register’s own record about you is kept as it was returned to us, so that what we show can always be traced back to what the register said.
Stored in NaturalPerson.payload
None of this came from you. That is precisely why this page exists: where personal data is not obtained from the data subject, the GDPR requires the controller to tell them anyway.
These are the purposes the product actually serves, described by the people who built it. Whether the law permits each of them, and on what basis, is a separate question that is marked below rather than answered.
the lawful basis under Article 6(1) for each purpose above, assessed separately — the contact look-up and the company-assessment collection are not the same case
Engineering states the purposes; which of them the law permits, and on what basis, has not been settled.
the Article 9 condition for the politically-exposed-person data and the Article 10 basis for the sanctions and insolvency indicators
Entio has a built feature that would let a customer save a list of named people and be alerted whenever something about one of them changes in the registers. It is off by default and has to be switched on deliberately, per environment, by setting a server configuration value; while it is off, every part of it answers "not found" — to our own staff as well, because this is not a permission that anyone can be granted around. It was built behind that switch on purpose, because monitoring named individuals is the kind of processing that requires a formal impact assessment before it starts. That assessment is being written now.
Customers can still follow companies, and a change of officer or owner is a company change. So a change involving you can reach a customer’s alerts today — through the company, not through a list with your name on it.
confirmation, per live environment, that the person-monitoring switch is actually off — and a standing check that says so, rather than a sentence on this page
What we can state from the code: the feature is off unless a server configuration value is explicitly set to turn it on, and nothing in our deployment configuration sets it. The value itself lives in the hosting environment, so this page cannot read it back and will not claim to.
What is visible depends entirely on who is looking. The public website shows the least; a signed-in customer sees the most.
the published sub-processor list — the hosting provider, the AI language-model service, the contact-enrichment provider, the credit bureau, the open-banking provider and the analytics tooling all need naming, with their locations and transfer safeguards
Engineering can enumerate them; which are named publicly, and under what transfer mechanism, is a legal and contractual decision.
We should give you a retention period here, and we cannot yet, so here is what is actually true instead. Your register record is refreshed from the source and kept — including roles that have ended. There is no scheduled deletion for it. The only automatic deletion the system performs on register data is a 90-day clear-down of the register’s change-feed log, which is a record of updates, not a record about you.
the retention period for register person records, for the roles that have ended, for the screening results, and for the access audit trail — and the deletion schedule that enforces it
Nothing in the system deletes person records today. This is a gap in the product, not a description of a policy.
You can object to all of it, or to any of these on its own. Each row says what the system does today — including the two where a person has to confirm which records are yours before it takes effect.
You stop appearing in the person search on the public site, and in the owner and person listings on public company pages — the surfaces anyone can reach without signing in, and the ones a search engine reads.
The public listing tables do not store your identity code, only a masked form and a name. So we search for the rows that look like you, a person checks each one, and we remove the confirmed ones. Until that check is done we report the page as still public rather than as clean — and namesakes are not swept up with you.
You stop appearing in the signed-in person directory, in its search results and in the counts it shows — so a customer cannot find you there, and cannot see a total that implies you.
You are removed from every customer’s monitored-person list, and — this is the part that makes it stick — the nightly job that rebuilds those lists is refused permission to put you back.
We stop re-checking you against the state’s politically-exposed-person database — no request leaves our systems and no new answer is stored. And a customer can no longer pay to reveal business contact details for you: the request is refused, nothing is charged, and we do not ask our supplier about you.
Our contact supplier’s record of you carries no identity code either, so as with the public pages a person has to confirm which supplier profile is yours before that half takes effect. The PEP half needs no confirmation — it is keyed on your identity code and stops immediately.
the standard of identity verification to require before acting on a request, and what proof is proportionate to ask a person to send by email
This page deliberately does not ask you to email us your full personal identity code. Sending an identity code by email is itself a risk, and we would rather ask you for more only once we know we need it.
the response deadline we publish, and whether public-register data can be erased at all or only suppressed
One refusal ground is already implemented rather than merely proposed: an erasure that would destroy an active sanctions link or a live insolvency is refused and escalated to a human decision. Whether that is the right and complete set of grounds is not an engineering call.
the supervisory authority’s name, address and contact details as they should be published here
whether this notice must be published in Latvian — and, if so, who signs off the translation
The people this page is written for are overwhelmingly Latvian residents. A Latvian translation is now available; the legal questions marked here remain open.
Write to support@kairolab.ai with the subject “Data subject request”. A person reads it — there is no self-service button here, and this page will not pretend otherwise.
Please include
Do not email us your full personal identity code. The masked form — the first six digits and five stars — is enough for us to find you, and if we need more we will ask.
Email support@kairolab.ai