# Mokuji DPIA support pack

Vendor-side input to a controller's Data Protection Impact Assessment
under GDPR Article 35. Not a completed DPIA, and not legal advice.

Current version published at https://neurotik.io/mokuji/trust/dpia.md
Questions: hello@neurotik.io

---

## 0. What this document is

This is the vendor-side input to your Data Protection Impact Assessment. It is not a completed DPIA and it is not legal advice.

A DPIA is the controller's obligation, and for Mokuji the controller is you: the system runs on your infrastructure, on footage you already hold, and we never receive any of it. The one optional exception, cloud processing, sends GPU work to a provider you choose rather than to us; it is described in sections 1 and 3. What we can supply is the half of the assessment that describes the system: the processing, the data categories, the retention mechanics and the technical measures. That is the part your team cannot write without us.

Sections 1 to 5 are ours and are written to be pasted into your template. Section 6 lists what remains yours, because it depends on your purpose, your lawful basis and your data subjects rather than on the software.

> Why a DPIA is likely mandatory here: face embeddings and voiceprints used to identify a person are biometric data, and therefore special category under GDPR Article 9. Processing special-category data on a large scale is one of the triggers listed in Article 35(3). Most deployments of this product will meet it.

---

## 1. Systematic description of the processing

Mokuji indexes video and audio that the controller already holds. On ingest it segments each asset into shots, produces a natural-language description of each shot, transcribes speech and attributes it to speakers, detects objects and on-screen text, and detects faces, estimating the apparent age and sex of each. Signals are fused into a single searchable index so a user can retrieve a timecoded moment by describing it.

Identification of a specific person occurs only where a user of the controller's organization has explicitly enrolled that person, by supplying a reference image or a marked audio segment. The system holds no reference population of its own, and face and voice recognition cannot identify a person who has not been enrolled. Descriptions, transcripts and on-screen text can still contain a name that was said, shown or widely known. Once a person is enrolled, the system may add further voice samples to their profile as it finds them.

In the standard install all processing happens on infrastructure operated by the controller, and no component transmits media or derived data to the vendor or to any third party. Mokuji sends no telemetry, and bundled third-party components ship with their usage reporting switched off. The system is designed to run with no internet connection once installed, with models staged locally; a formal offline acceptance test is not yet part of the release.

Cloud processing is optional and off by default. If an administrator of the controller's deployment turns it on for a catalog (the agreement is recorded with who and when), that catalog's GPU work goes, encrypted end to end, to a cloud GPU provider the controller chooses. What is sent: frames, the clips' audio, short transcript passages, on-screen text, captions, the names and places already found, and search queries. What comes back: text, boxes, and face and voice embeddings. The relay that routes the work cannot read it, and the worker keeps it in memory (or sealed with a key that exists only in memory) and drops it when each job ends. Databases, identities and voiceprints never leave; matching people stays on the controller's server.

| | |
|---|---|
| **Nature** | Automated analysis of audiovisual material to produce a searchable index |
| **Scope** | The controller's own media library; volume is set by the controller |
| **Context** | Retrospective search of stored material, not live monitoring |
| **Purpose** | Retrieval of specific moments; determined by the controller |
| **Automated decision-making** | None. The system ranks candidates for a human; it takes no action |
| **Real-time biometric identification** | Not supported |
| **Retrospective identification** | Supported, of people enrolled by the controller's users only |
| **Emotion or intent inference** | Not performed |
| **Estimated attributes** | Apparent age and sex are estimated for each detected face. They are shown to reviewers to help tell unnamed faces apart and are not offered as a search filter. A gender entered by the controller's users on a person's profile is used to word scene descriptions |

---

## 2. Categories of data and data subjects

| | |
|---|---|
| **Ordinary personal data** | Names attached to enrolled identities; speaker attributions; any personal data incidentally present in the source footage or in a transcript |
| **Special category (Art 9)** | Face embeddings, face crops and voiceprints, where used to uniquely identify a person |
| **Derived, non-identifying** | Scene descriptions, shot boundaries, object and logo detections, on-screen text, scene embeddings |
| **Data subjects** | Anyone appearing or speaking in the controller's footage. Typically employees, contributors, interviewees, performers, attendees or members of the public, depending on the archive |
| **Children's data** | Only where present in the controller's source material. The system estimates apparent age for detected faces but does not treat children's data differently |
| **Source of the data** | The controller's own existing media. No external enrichment, no third-party lookup, no vendor-supplied reference database |

---

## 3. Recipients, transfers and retention

| | |
|---|---|
| **Recipients** | Users of the controller's deployment. Any signed-in user can view the library; roles govern what each user can change. No one else, unless the controller turns on cloud processing (see below) |
| **Vendor access to personal data** | None by default. See the support model in section 5 |
| **Sub-processors** | None of the vendor's. In the standard install, none at all. If the controller turns on cloud processing, the cloud GPU provider it chooses processes that work for the controller and is the controller's sub-processor, not the vendor's. If the controller asks the vendor to host the relay that routes that work (an added service), the vendor processes encrypted work it cannot read, under a processing agreement that names where the relay runs |
| **International transfers** | None arising from the standard install. Data remains wherever the controller's infrastructure is. With cloud processing on, transfers depend on the region of the provider the controller chooses |
| **Optional cloud processing** | Off by default and enabled per catalog by an administrator, with the agreement recorded (who, when, wording). Sends frames, the clips' audio, short transcript passages, on-screen text, captions, names and places already found, and search queries, encrypted end to end; returns text, boxes, and face and voice embeddings. Kept in memory on the worker (or sealed with a key that exists only in memory) and dropped when each job ends. Databases, identities and voiceprints never leave |
| **Retention** | Determined entirely by the controller. The system imposes no retention period and keeps nothing for the vendor. Administrators get a search log of queries (not who ran them), which rotates after 90 days by default |
| **Erasure** | Deleting an asset removes its face crops, face embeddings, transcripts, descriptions and index entries. Voice data taken from the asset and its proxy files are not yet removed with it. Deleting an enrolled person removes their record, but their reference faces and voice samples are kept until removed separately. Both gaps are being fixed. Copies in the controller's backups and sidecar files written beside the media follow the controller's own retention |
| **Erasure exception** | The audit log is not cascaded. A record of who deleted what is worth little if deleting the subject removes the record. Controllers should account for this in their retention schedule |

---

## 4. Technical and organizational measures (Article 32)

| | |
|---|---|
| **Data minimization by architecture** | In the standard install media and derived data never leave the controller's infrastructure; there is no vendor-side copy to secure. Optional cloud processing is described in section 3 |
| **Access control** | Role-based permissions govern what each user can change, checked by the services rather than only in the interface. Collections can be shared with a team or named users. Any signed-in user can view the whole library; per-asset viewing restrictions are on the roadmap |
| **Authentication** | Signed bearer tokens carrying user and role, configurable lifetime defaulting to seven days; passwords with a per-user salt and PBKDF2-HMAC-SHA256 at 200,000 rounds, with no user-enumeration timing oracle; failed sign-ins throttled per client address and per username; sign-in enforced by default; disabling or deleting an account, or changing or resetting its password, ends its existing sessions within about thirty seconds |
| **Media access** | Signed URLs rather than open file paths, each covering one file and expiring after six hours by default, configurable. Collections shared by link are reachable without signing in by anyone holding the link, until sharing is turned off |
| **Encryption in transit** | TLS terminated at the entry point with the controller's certificates; control traffic between nodes mutually authenticated and encrypted; work sent to relayed or cloud workers encrypted end to end |
| **Encryption at rest** | The controller's disk encryption. Backups the software writes are encrypted to the controller's public key, with the private key kept off the box. The software's own secrets live in its environment file on the host, which the controller should protect as a credential |
| **Network exposure** | A single reverse-proxied entry point; the standard install publishes no internal service ports. The optional add-ons for multiple nodes and GPU captioning publish further ports without authentication of their own and belong on a private network segment |
| **Audit** | Every change made by a person or an integration key, including corrections to transcripts and speakers, recorded with actor, route, target and time in the controller's own database, as is every change refused for lack of permission and every failed sign-in. Views are not logged yet, so a consolidated per-asset access log is not yet implemented |
| **Erasure** | Asset and person deletion as described in section 3, including its current gaps |
| **Secure development** | Automated tests cover the services and the web interface. A gated release pipeline with static analysis and dependency vulnerability checks is being built |
| **Air-gap capability** | Designed to run with no internet connection once installed, with models staged locally, for controllers whose risk assessment calls for it. A formal offline acceptance test is not yet part of the release |

---

## 5. Vendor support access

The vendor holds no standing access to any deployment: no support tunnel, no VPN, no phone-home channel and no credential. A deployment to which access has never been granted is not reachable by the vendor at all.

Where support is needed, it escalates in three steps and the controller decides which step applies:

| | |
|---|---|
| **1. Diagnostics** | The controller builds a diagnostics bundle from the admin screen in one click and sends it. Secrets are redacted, but it includes recent logs and search queries, which can contain personal data such as names, so the controller should review it before sending. Resolves most issues. Requires granting the vendor nothing |
| **2. Granted network access** | For issues diagnostics cannot resolve, the controller grants access to the deployment across its own network, scoped, time-limited and revoked afterward, under the controller's own controls |
| **3. On-site attendance** | Where the support tier provides for it, vendor personnel attend the controller's premises and work on the system under supervision. Nothing leaves the site |

> Controllers should treat step 2 as a disclosure of personal data to the vendor for the duration of the access, and record it accordingly. It is the controller's decision each time, not a standing arrangement.

---

## 6. What remains yours to complete

The following cannot be answered by the vendor because they depend on your purpose, your material and your data subjects rather than on the software. They are listed so nothing is missed, not to suggest they are difficult.

| | |
|---|---|
| **Lawful basis** | Your Article 6 basis, and your Article 9(2) condition for the biometric processing. Self-hosting does not supply either |
| **Necessity and proportionality** | Why indexing is necessary for your purpose, and why a less intrusive alternative would not achieve it |
| **Transparency** | How data subjects are informed. Note that US state law may additionally require written notice and a written release before collection, and a published retention and destruction schedule |
| **Risk assessment** | The risks to the rights and freedoms of your data subjects, their likelihood and severity |
| **Data subject rights** | How you will handle access, rectification and erasure requests in practice. Asset and person deletion support erasure, with the gaps listed in section 3; the process around it is yours |
| **Retention schedule** | Your periods, and who decides when something is removed |
| **Consultation** | Whether your DPO, and where residual high risk remains your supervisory authority, need to be consulted under Article 36 |
| **Sign-off** | Who owns the assessment and when it is reviewed |

---

## 7. Residual risks we consider real

Stated because a DPIA that identifies no residual risk is one a regulator will not believe.

| | |
|---|---|
| **Misidentification** | Recognition is a ranked hint with a match score and a breakdown of why it matched, not a determination. Treating a match as fact without human confirmation is the most likely way this system causes harm to an individual |
| **Demographic variance** | Face recognition accuracy is known to vary across demographic groups. We have not independently audited ours and do not claim to have done so |
| **Scope creep** | An index built for retrieval can be repurposed for monitoring. The control for this is organizational (access policy and purpose limitation), not technical |
| **Administrator reach** | An administrator of the deployment can reach the material and the derived data. The permission model constrains users, not the people who operate the system |
| **Incidental subjects** | People appear in footage who were never the subject of it. Indexing makes them findable in a way the raw archive did not |
| **Library-wide visibility** | Any signed-in user can view the whole library, including footage of enrolled people. Until per-asset restrictions exist, control who holds an account |
| **Incomplete erasure** | Until voice data, proxies and a person's reference samples are removed with their asset or person, an erasure request covering a person's voice needs follow-up beyond the standard deletion |
| **Retention drift** | Because the system imposes no retention period, derived biometric data persists until the controller removes it. Absent a schedule, the default is indefinite |