What is TalentService?+
The agentic HR AI orchestrator and governor. Orchestration moves the work; governance decides who may act, on whose data, under which policy — and proves it afterwards to someone who does not have to trust us. Architecturally it is a control plane. Every organisation is about to run agents — ones they buy, ones they build, ones their ATS ships, ones we provide — against the most regulated data they hold. TalentService is the layer where those agents, the systems of record they read from, and the people who stay accountable meet on one surface: one place where an agent is switched on or off per organisation, one broker through which every connected system is reached, and one append-only, hash-chained ledger where every action lands the moment it happens. Your ATS stays the system of record. We become the record of what was done, by whom, and under what authority.
Does TalentService replace our ATS or RPO?+
No, and it is not designed to. We do not compete for the system of record — we are the layer above it. Your ATS keeps the requisitions and applications, your RPO or internal team keeps its workflow, and TalentService adds the control surface: which agents may act, which systems they may reach, which decisions only a named person may take, and the evidence trail underneath all of it.
How do agents get access to our HR systems?+
They do not. An agent never holds a vendor credential — it may hold only a grant against the control plane, and the control plane holds the credential. Credentials live in one encrypted per-organisation store, and nothing reaches an outside system unless five independent conditions all positively hold: the global switch is on, your connection row is active and holds a credential, your organisation has accepted the current terms version, a usable credential resolves, and you are within your allowance. There is no default-allow path — an unknown provider, a missing row and an unreadable database all land on the same refusal.
Which systems do you integrate with?+
Twenty-three HR systems are held to the same standard before anything is connected to them: the vendor’s legal seat, where it stores customer data, where our requests would land, and how a customer obtains a credential. Every entry is browsable inside the product, on its own record. EU-native systems come first — that is a strategy, not a queue. And no system may be reached at all until its record exists and your organisation has authorised it, so the catalogue is a permission surface rather than a promise.
Where does our data live?+
On EU infrastructure we run ourselves: AWS eu-central-1 (Frankfurt) for compute, database and artifact storage, with the identity provider self-hosted on that same infrastructure rather than rented from a third party. Every processor that can touch TalentService data is named in our processor register together with what it actually sees, and we hand that register over rather than promising one. Systems you connect stay wherever their vendor runs them — each vendor’s record in our catalogue states where that is, so nothing is implied about a system we do not host.
How does the evidence log work?+
Every event is appended to a hash-chained ledger, and append-only is a database permission rather than an application promise: the writing role holds INSERT and SELECT only — UPDATE, DELETE and TRUNCATE were never granted, so they are impossible rather than forbidden — and the application role holds SELECT alone. Each row carries a SHA-256 hash of its canonical payload plus a chain hash over a domain-separated, length-prefixed preimage, so any alteration breaks the chain and the whole history recomputes from the rows alone. Verification returns a verdict and counts, never payloads. A stolen application credential still cannot rewrite history. Neither can we.
Does the evidence log hold our candidates’ personal data?+
No. The ledger has never held a person. It holds decisions and pointers to records: subjects are opaque ids, and no payload has ever carried a name or an email address. Most products that prove they governed a person do it by logging the person — and having logged them once, they cannot un-log them. Content hashes go on the chain; the content itself lives in erasable side-stores. So a person’s right to erasure and the chain’s inability to forget never have to fight.
Who decides — the agent or a person?+
A person. Nine actions — advancing or returning a gate, approving, overriding, extending an offer, rejecting an application, assigning scrutiny, flagging fraud and attesting a contractual constraint — may only ever be written by a named person, and no agent lane may write one. That is not a setting an administrator can turn off; it is the vocabulary the system is built from. And the reason the person gives is hashed onto the chain beside the decision, so what is permanent is the basis, not merely the name.
Is TalentService ready for the EU AI Act?+
Annex III classifies systems used to recruit and select people as high-risk, and the narrow-task derogation in Article 6(3) closes wherever a system profiles a natural person — which evaluating a candidate against a role’s requirements does. So we design to the obligation, not to the calendar. Record-keeping under Articles 12 and 19 is the hash-chained append-only ledger. Human oversight under Articles 14 and 26 is the nine human-only actions. Accuracy and robustness under Article 15 is a closed 25-action vocabulary with no free text reaching the chain. Article 50 has applied since 2 August 2026: no step may put a person in front of an AI system without telling them, and the notice a person is shown is designed as a versioned, hashed artefact, so the record can carry which version they saw. Emotion inference in the workplace has been prohibited since 2 February 2025 at the top penalty tier; we will not build it.
Are you certified?+
We are not yet certified, and we do not wear compliance as a badge. What we offer instead is mechanism you can inspect: the grants on the database, the closed action vocabulary, the tenancy policies that fail closed in both directions, and the processor register.
What about EUDI Wallet timing?+
Under Reg. (EU) 2024/1183, member states are to make EUDI Wallets available by the end of 2026. The TalentService identity gate is designed wallet-first, with a documented fallback route that does not depend on a wallet, so no candidate is stranded by a member state’s timetable. The actions the gate may write are fixed, and the design admits no candidate on a claim nobody verified.
What counts as a verified hire?+
The operating model runs five gates — sourced, identity verified, structured interview, human approved, evidence sealed — and a hire is verified when it has passed all five with the record to show it. Which gates a pilot runs, which are ours and which stay yours, and the contractual billing definition, are agreed with each client before the pilot starts.
We hire fewer than 20 people a year — is this for us?+
Yes — the Pilot tier is designed for exactly this: two roles, 60 days, fixed fee, and success criteria agreed up front. You get the same control surface and the same evidence trail as a high-volume client, without committing to a volume model.
