Technical Annex

Automated processing components of the annotation pipeline

Version 1.3 — Effective 11 September 2026

Controller: EgoVista SAS, 47 rue Vivienne, 75002 Paris, France — SIREN 106 489 735

1. Purpose and scope

This annex lists the software components and machine learning models used by EgoVista in the processing of collected video sequences, together with the cryptographic components applied to contributor data outside that pipeline. For each component it states the processing category it belongs to, its identifier, its version, where it is executed, and whether it entails any transmission outside EgoVista's infrastructure.

It is referenced by the following documents, which do not restate this information in their own body text: the data protection impact assessment, the legitimate interest assessment, the privacy policy, the Contributor Terms of Service, and the dataset card supplied to the acquirer.

This separation is deliberate. Those documents state stable legal facts, namely who processes, on what legal basis, for what purpose and in what place. Model identifiers and versions change at the pace of software development. Replacing a model with a more recent version, with the processing category, supplier and place of execution unchanged, gives rise to a new version of this annex and entails no modification of the documents that reference it.

2. Versioning rule

Any modification of this annex gives rise to an increment of the version number and to its own effective date. Earlier versions are retained and remain binding for the processing carried out under them. A batch of data delivered to an acquirer carries the reference of the version of the annex in force when the annotations it contains were produced, and not the version in force on the delivery date.

A change affecting the processing category, the supplier, the place of execution, or the existence of a transmission outside EgoVista's infrastructure is not a mere modification of the annex. It requires revision of the data protection impact assessment and, where applicable, of the privacy policy.

3. Components in service

Storage of sequences and of the artefacts produced is provided by Cloudflare R2. Computation of the components executed on EgoVista's infrastructure takes place within the European Union.

4. Execution order and guarantee of prior blurring

The execution order of the stages is not defined by a written sequence but by a dependency graph declared in the code, each stage being unable to start before completion of those it depends on.

It follows from this graph that the only stage entailing a transmission outside EgoVista's infrastructure, action label generation, depends on face blurring and on video re-encoding. The sequence transmitted is therefore, by construction, the sequence re-encoded from frames whose faces have been blurred. This guarantee is structural and not conventional: it does not rest on an execution instruction but on a constraint of the graph, the violation of which would prevent the processing from completing.

4-bis. Container inspection

This stage reads the technical metadata carried by a submitted file and records it alongside the submission: verified duration, dimensions, frame rate, codec, stream count, object fingerprint as returned by the storage provider, and the creation timestamp written by the recording device where the container carries one.

It produces no inference and takes no decision: it writes observed values and neither creates a quality verdict nor changes the state of a submission. Its purpose is to establish that what was declared about a file corresponds to the file itself, which the Contributor Terms describe at section 7.11.

⚠️ Two statements of fact rather than of intent. The creation timestamp field is present and is not populated at the date of this version. And this stage is not a verification of the place of recording: a container timestamp is not a location, and no component listed in this annex reads location metadata of any kind. EgoVista does not extract, store or infer geographic coordinates from a submitted file.

5. Action label generation

This stage is the only one that involves a third-party service. It calls a multimodal language model hosted by Google Cloud, by way of the Vertex AI service, to produce a timestamped textual description of the actions observed in the sequence.

5.1 European region guarantee

The project and the region are read from the runtime configuration and are not written into the code. Their value is not left to the discretion of the operator: the region is subject to a check that interrupts processing when it is not European. This check applies at two distinct points, on loading the configuration and on constructing the client, so that a single modification is not sufficient to neutralise it. A further check rejects any client not constructed in Vertex AI mode.

The consequence is that an execution outside the European Union fails rather than producing a result. This property is structural: it does not rest on the correctness of a parameter, but on the impossibility of processing with an incorrect parameter.

5.2 Fate of the intermediate file

The sequence is placed in a staging area before the model is called. That file is deleted at the end of processing. The outcome of that deletion is recorded in the annotation artefact, including where it fails. EgoVista is thereby able to establish, for each sequence processed, that the deletion was carried out, rather than relying on a statement of principle.

5.3 A single path

Version 1.1 of this annex described two implementations of this stage: a reference path, that of the platform, and a secondary path arising from the development of the annotation chain, which reached the same model through the supplier's direct interface without region determination. That second path has been aligned on the first.

A single implementation now remains, described at 5.1 and 5.2: access through Vertex AI with a service account, project and region read from the runtime configuration, region check interrupting processing when the region is not European, and deletion of the intermediate file with the outcome recorded in the artefact.

The version of this annex attached to a batch makes it possible to establish, for each annotation, the implementation that produced it. Annotations produced under version 1.1 by the secondary path are not delivered to an acquirer.

6. Cryptographic components applied to payment details

This section is new in version 1.3. It exists because version 2.4 of the Contributor Terms undertakes that bank details are held encrypted with the key residing outside the database, and because an undertaking of that kind is only worth what its implementation is.

Where the cryptography runs. Both components run in the application layer, in the Node.js runtime, and never in the database. The database receives a ciphertext and a fingerprint; it never receives the key, never receives the secret, and holds no function capable of producing either. This is not a preference of style: a key passed as an argument to a database function travels to the server on every call and may be retained in server logs, in an error message or in query statistics, which would make the undertaking in the Contributor Terms untrue while leaving it written.

Encryption. AES-256-GCM, an authenticated mode, so that a ciphertext modified after the fact fails to decrypt rather than yielding altered plaintext. A distinct initialisation vector is drawn for each record. The key is supplied to the application by its runtime environment.

Fingerprint. HMAC-SHA-256 computed over the identifier after normalisation, for one purpose only: detecting that two contributor accounts designate the same bank account, which the Contributor Terms prohibit. It is a one-way function: the identifier cannot be reconstituted from it. The secret is distinct from the encryption key and, once set, is never changed — changing it would make every existing fingerprint incomparable with every new one, and would silently disable the detection rather than break it visibly.

Scope. These two components apply only to the payment method under which EgoVista holds bank details, which is the SEPA transfer described in the sub-processor list. Under the other two methods, the beneficiary supplies his or her details directly to the payment provider, or is paid at an electronic address, and neither component has anything to operate on.

What is not claimed. This section describes measures applied to data at rest in EgoVista's database. It says nothing about the security of the payment providers' own systems, which is governed by their contracts and by their own regulatory obligations.

7. Classification of the components under Regulation (EU) 2024/1689

The components listed at section 3 are AI systems within the meaning of Article 3(1) of Regulation (EU) 2024/1689, with the exception of ffmpeg and ffprobe, which perform no inference, and of the two cryptographic components of section 6, which perform none either. EgoVista uses them under its own authority in a professional activity and is therefore a deployer within the meaning of Article 3(4). It develops none of them, places none on the market under its own name and modifies none substantially, and is therefore not a provider within the meaning of Article 3(3). What EgoVista places on the market is a dataset, which is not an AI system.

This section states the classification of each component. The reasoning supporting it, and the events that would reopen it, are set out in EgoVista's combined data protection and AI Act assessment, Part III, which is not restated here.

No component deployed falls within Annexes I or III. The obligations of Articles 26 and 27, which bear on deployers of high-risk systems, are therefore not applicable. Article 4, on AI literacy, applies irrespective of risk level and is satisfied by the measures set out in EgoVista's AI literacy policy, of which this annex constitutes the register of systems.

A change of component, of supplier or of purpose requires this classification to be re-examined before the change takes effect, on the same footing as the revision required by section 2.

8. Provenance of model weights

The weights of the models executed on EgoVista's infrastructure are obtained from public sources, respectively the MediaPipe distribution repositories and Hugging Face. The weights of the hand-object segmentation model are obtained from third-party hosting not governed by EgoVista. Verification of an expected checksum on download is identified as a measure reinforcing the provenance chain, and is not in place at the date of this version.

The licence attached to each set of weights, and in particular whether it permits commercial use and whether it carries an acceptable-use restriction bearing on the production of a dataset supplied to a third party, is a distinct question from the provenance of the file. A component whose weights carry a licence excluding commercial use has already been set aside on that ground. A verification of the licence of each variant actually loaded, read from the model repository rather than from memory, is identified as a measure and is not complete at the date of this version.

9. Terminology

Face blurring constitutes a pseudonymisation measure within the meaning of Article 4(5) of the General Data Protection Regulation. It does not render sequences anonymous and does not take them outside the scope of the Regulation. The technical identifier of a stage in the source code does not amount to a legal qualification of the processing it performs.

The fingerprint described at section 6 is likewise a pseudonymisation measure and not an anonymisation: it is computed with a secret, which places it outside the reach of a dictionary attack on the space of identifiers, but the data it stands for remains personal data within the meaning of Article 4(1).

10. Version history

Document drafted with the assistance of an artificial intelligence system and validated by EgoVista SAS.