Question 1

Which risks are handled, and how?

Accepted Answer

Risk is treated as a short, named list rather than a document nobody reads. Each risk has an owner, a control that runs in the product, and a review date. A risk without a control in the code is not closed. A wrong answer to a customer: fixed answer registers and a closed source list, never a free-running model. An answer outside our mandate: the policy layer stops it and hands over to a person. Personal data in a place it does not belong: masking on read, short retention, deletion on schedule. Provider outage or rate limit: queues, retries with delay and a cached answer instead of a broken page. Runaway cost: spend caps per tenant, measured cost per run, and a hard stop before the cap is passed. Vendor dependency: EU hosting, no US-run production interfaces, and an own codebase that can be moved. The list is reviewed at least twice a year and after every incident. What this means for you: You can ask for the risk list in a procurement review and check each line against behaviour in the product. (Basis: EU 2024/1689 · internal risk register)

Question 2

What happens when something goes wrong?

Accepted Answer

An incident is detected, classified, contained and reported on a fixed path. Operational health is measured every fifteen minutes and an alert is written to a log, not only sent to a chat. Detection: automated checks on job health, error rate and queue length, plus reports from customers. Classification: service disruption, data incident or model incident, decided within the first hour. Containment: the affected function is stopped rather than left running in a degraded state. Notification: an affected customer is informed without undue delay, in plain language. A personal data breach is reported to the supervisory authority within 72 hours where the regulation requires it. Every incident closes with a written cause, a fix and a change to the risk list. Alerts and outcomes are kept in an operational log that can be shown on request. What this means for you: You get a named cause and a fix, not a status page that turns green without an explanation. (Basis: EU 2016/679 Art. 33-34 · operational log)

Question 3

How are the models reviewed?

Accepted Answer

Most answers are produced by deterministic code from our own registers. A language model is used for the long tail only, and every call is logged with which model, which purpose and which cost. Model identifiers live in one central registry, never hardcoded in a feature. Every model call writes a log row: purpose, model, tokens and cost. A new or changed model is compared against the previous one on a fixed set of questions before it is used. Deterministic output is preferred; the model path is a fallback, and the share is measured. Output passes a quality gate that repairs tone and blocks forbidden claims before it ships. Training on customer data does not happen; customer text is not used to train any model. A change to scoring or to a score algorithm bumps a version number so old results stay traceable. What this means for you: You can see which part of an answer came from a register and which came from a model, and when it last changed. (Basis: EU 2024/1689 · model registry and call log)

Question 4

Where does a person decide instead of the system?

Accepted Answer

The platform observes and calculates. It does not decide anything that affects a person's rights, money or employment. Where a decision has consequences, the system hands the case to a person with the material attached. Legal, financial and identity questions are handed over rather than answered. Candidate matching produces a ranked list with a visible calculation; the hiring decision stays with the employer. Capital and loan matching produce a list of counterparties, never a recommendation or advice. A handover carries the conversation, the sources and the reason, so the person does not start from zero. A person can override any calculated result, and the override is recorded. Uncertainty is shown rather than hidden: missing fields are printed as missing. No automated decision with legal or similar significant effect is made by the platform. What this means for you: Nothing in the platform decides about a person on its own. A human is always the last step. (Basis: EU 2024/1689 Art. 14 · EU 2016/679 Art. 22)

Question 5

Who answers for what between us and you?

Accepted Answer

We answer for the platform, its security and how it is operated. You answer for the addresses you submit, the purpose you use the output for and the decisions you take on it. We are the controller for account, billing and support data. We are the processor for the material you run through the platform, on your written instruction. You are the controller for candidate, customer and prospect data you bring into the platform. You choose the legal basis for your own use and can be asked to show it. Subprocessors are listed publicly and bound by the same duties as us. Hosting and processing stay inside the EU; there is no transfer to a third country in normal operation. The data processing agreement is the binding text; this page only explains it. What this means for you: You know exactly which duties are ours before you sign, and which stay with you. (Basis: EU 2016/679 Art. 24-28 · data processing agreement)

Question 6

Which role holds each duty?

Accepted Answer

Duties sit on named roles, not on a department. A small company cannot hide behind an org chart, so each role below has one owner and one duty that can be checked. Every role has a deputy, so a duty does not stop when one person is away. Role holders are appointed by the board and recorded in the board minutes. A change of role holder is noted here at the next review of the page. No data protection officer is appointed; the criteria in Article 37 are not met, and the duty sits with the privacy owner. External counsel is used for regulatory assessments rather than in-house opinion. The board reviews governance at least once a year and after any serious incident. What this means for you: You have a named counterpart for each duty instead of a shared inbox. (Basis: EU 2016/679 Art. 37 · board decision)

Role	Owner	Duty
Executive responsibility	Managing director, Valkiv Ventures AB	Answers for the platform as a whole, signs the risk list and reports to the board.
Privacy	Privacy owner	Legal basis, retention, requests from data subjects and breach reporting.
AI compliance	AI compliance owner	System classification, transparency, model review and the model call log.
Security	Security owner	Access, keys, logging, and containment when an incident is declared.
Operations	Operations owner	Health checks, alerts, queues and the written cause after every incident.
Board oversight	Board of Valkiv Ventures AB	Annual review of governance, appointment of role holders, decisions after serious incidents.

EU governance at ExploreWorldAI

01 Risk handling

Which risks are handled, and how?

02 Incident process

What happens when something goes wrong?

03 Model review

How are the models reviewed?

04 Human oversight

Where does a person decide instead of the system?

05 Split of responsibility

Who answers for what between us and you?

06 Compliance roles

Which role holds each duty?

Roles and owners

Where to send a governance question

Binding texts