Security and privacy
What we hold, and where it sits
None of the following is a configurable option; each is a design decision. It is written at the level of detail your IT and legal teams can check as it stands.
Storage and encryption
Where the interview audio lives
- Recordings stay on servers we operate
- No external object storage. We keep the companies that handle recordings to the ones an interview actually needs.
- Each recording is encrypted with its own key
- AES-256-GCM per recording. The data key is itself encrypted with a master key and stored apart from the audio, on the interview session's database row. The audio file, the wrapped key and the master key live in three different places.
- Backups carry ciphertext only
- The master key needed to decrypt is not in a backup. If a backup location were ever exposed, what it holds cannot be decrypted.
- Interview links are not stored in the clear
- Only a hash is kept. A leaked database cannot yield working interview links. The trade-off is that a link already sent cannot be read back on screen later.
Processors
Interview processing runs outside Japan
Speech recognition, question generation, speech synthesis and report writing use the API of OpenAI, L.L.C., a US company. Because a company outside Japan handles the interview data, under the APPI this is a provision of personal data to a third party in a foreign country.
So before the interview begins, the consent screen names the recipient as OpenAI, L.L.C., with its country (the US) and what it does (speech recognition, speech synthesis, question generation and answer evaluation), says that this includes a provision to a third party abroad, and asks the candidate to tick a box to consent. The interview runs only on that consent. The version of the consent wording and the processor list are stored as they were when the candidate consented. Adding a processor later never rewrites what somebody consented to earlier.
In-region processing was considered and has not been adopted. We would rather say so than describe something we do not do.
Retention and deletion
No scheduled expiry
Interview data is deleted from the live system when you ask. Encrypted database backups keep it for up to about five weeks, until they rotate out. A mechanism that expires data after a set period is not implemented, and we do not describe a mechanism we have not built as a policy — so this page says exactly that.
Deletion covers the recording, the camera video, the transcript and the quoted answers in the report. The scores and their written justifications remain as the decision record, and the deletion itself is written to the audit log. In the console, only an account holder with the owner role can run it, and the screen shows what will be destroyed and how much before it does. Our operators can also run a deletion on request. A retention period can be set by contract.
Audit log
A record that cannot be rewritten
Each customer has one audit log: append-only, hash-chained row to row. The database refuses to change or remove a row, and a tampered row fails verification. The one exception is erasing a row's contents on a deletion request, and an erased row verifies as erased. What it records:
Consent wording version and processor list
What the candidate actually read
Rubric version, prompt-pack hash, model version
What the assessment was made against, and with what
Scores and override reasons
The model's numbers and, where a person overrode one, their number and reason
Questions discarded before being spoken
The discard itself is the record
Who exported what as CSV
Printing a report or saving it as PDF is not logged
Who deleted what
Deleting does not delete the fact of deletion
How interview questions are checked against MHLW's fair-selection guidance is described on its own page.
Certifications
We list none we do not hold
ISO/IEC 27001, SOC 2, Privacy Mark and other third-party certifications are not held at present. Plans are discussed in conversation. Security questionnaires are answered individually — send yours to hello@hitoshiru.com.